我将我的经历写出来，希望能够给予众多"环境不理想"的测试工作者们一点借鉴，同时也请版主和经验丰富的测试管理者指出我在工作中的不足。
我是三月一日进入公司的，至今有三个半月的时间，具体工作情况如下：
一、公司测试工作环境(刚进公司时)
我们公司在河南，和大多数河南的软件企业一样，测试工作都是开发的附属工作，在公司里面，都是开发人员说的算。
二、测试组成员
我们目前的测试人员总共有四人，其中一个是行业专业人员(我们的部门经理)，另两个是其他专业的，我是唯一一个计算机专业并且接受过软件测试培训的。
三、工作经历
3.1、刚进公司，当然要先熟悉公司软件了，同时也要学习行业相关的业务知识，并开始熟悉公司的环境。(此时的我是多做少说话，因为毕竟是初来乍道，好多事情是祸从口出的道理我还是明白的。再说了，这个时候说话也没资格啊，没人听哦！ )
3.2、在公司熟悉一段时间，和各个部门员工以及公司领导都比较熟了之后，就经常给领导们灌输测试思想(当然不是介绍专业知识啊，说了也白说的)。因为我们公司是做行业软件的，所以需要开发公司自己的"产品"。因此，每当和领导谈起测试工作的时候，我就问他们对测试工作有什么要求。当然，大多数的答复都是：只要不报错就行。这个时候，我就把公司的"项目"分了两个级别：产品级项目和项目级项目。然后告诉领导，作为项目级项目达到领导要求的标准当然可以了，但是公司是需要长远发展的，必须要有合格的产品级项目才行啊！要达到产品级项目标准，仅仅是不报错，是远远不够的。
3.3、前边已经给领导灌输过测试标准过低，影响公司产品质量的思想了；当然，咱也不能光说不练吧，那样你将失去信任的。正好公司有一个项目级的项目，我就打算拿这个项目开刀，去验证我所说的不足，于是和同事们协商过之后，决定选取该项目中的几个模块做"产品级测试"。测试结果就不描述了，在这个公司已经认为相对比较成熟的项目上，测出来N多的问题，这是必然的结果。
3.4、测试结果出来了，我们测试组没有选择直接上报公司领导，而是从BUG管理工具里面选择了一个比较类似的事物管理工具URTracker。把所有问题都上传到这个工具上边，并且把浏览评论权限分配给了所有的部门(以前仅技术部门内部通报，现在连办公室、企划部、市场部都参与进来了)。这样做的效果是十分明显的，问题暴露出来之后才会得到客观的评价，此时的非技术部门是测试部门的强力后盾啊。开发部门也找不到合适的理由来反驳我们，只能接受现实，踏踏实实的去修改他们以前不愿意修改的程序！
3.5、通过这件事情，公司领导也意识到了测试的重要性。公司总经理亲自找我谈话，让我谈谈对目前的测试工作的看法。我在作了充分的准备之后，把公司的测试工作概括了以下几点：
A、测试计划写出来了，但是没有按照计划去执行，那就是一张白纸，有那时间不如去执行测试好了；
B、没有给予编写测试用例充足的时间。老是程序开发完了才交给测试，并限制多长时间内完成。为了完成这样的任务，测试部门就只能放弃编写测试用例了，直接投入测试。但是这样的效果又是什么呢？这样的测试是可以发现一些问题，但是这是靠测试人员的测试经验和专业经验才发现的，在说明软件质量是如何得到保障的时候缺乏有力的依据！这样的测试是盲目的、随意的、没有计划的，软件测试的功能覆盖率根本无据可查。结论只有一个----无效的测试！
C、缺少用例评审制度；
D、缺少对BUG等级的划分；
E、缺少对BUG的响应方式、响应时间的约定；
F、缺少BUG的评审制度；
G、缺少对测试过程的跟踪制度；(咱不能光照别人不照自己，也得给自己部门提点建议)
H、缺少独立的测试服务器(测试和开发共用一台服务器，晕了)、缺少。。。。。(都是硬件设施，这里不提了)
当我把这些给总经理汇报之后，看的出来总经理的脸色已经变了。当即给了我一个任务：整理标准的测试流程、测试制度、管理方案结合公司现有技术力量和实际情况，制订<公司测试工作管理办法>(这点我比较庆幸，因为碰到了一个开明的老总，换个人估计会用各种各样的理由来拒绝你，或者干脆认为你不切合实际)。
3.6、剩下的事情就是按照上边所说的逐一落实了。不过中间又出了一个小插曲。事情是这样的：有一个问题，我认为它违反了易用性和一致性的原则，当我去找技术总监协商这个问题需要解决时，他给我来了一个"不予处理"(因为这个模块是他设计的，他说设计思路就是这样~~)我说："按照标准的话，这里我还是建议修改的。"他却说："你说的话就是标准？？。"我当时就生气了，我说："我的技术不行，但是我会去参考人家的标准，并把人家的标准应用到我的工作中去。"不过，通过这件事情，也让我意识到：我应该把"人家"的标准整理出来。于是，就去找总经理谈话，建议在<公司测试工作管理办法>上增加<测试标准>、<测试交接手续>，并得到了总经理的支持。当没有"游戏规则"时，那么你就考虑制定出来"游戏规则"，让别人去遵守。
3.7、经过努力，我先后编写了<测试工作(暂行)规范>、<公司测试工作管理办法(与各部门之间协作模式)>、<界面测试标准>、<测试工作开始、结束标准>、<提交测试手续>等等。测试部在公司的地位也发生了改变-----既独立于所有部门，又与各个部门展开协作，目的是测试工作绝对不能受任何外界影响。
3.8、最后，我想谈一下工作方法问题。作为公司的一员，尤其是测试人员，必定要和其他部门人员打交道，不可避免的会发生一些意见不统一的事情。这个时候应该尽量避免正面冲突，毕竟你又不是对方部门的领导，人家也没必要听你的。但是测试人员要坚持原则性，这时候就需要你坚持把组织流程走完，之后，如果还没有得到让你满意的结果，那么你就需要打一份报告，大概内容如下：
A、对问题的统计数字；
B、对问题的描述；
C、对问题的危害性描述；
D、对问题的开发人员意见；
E、对问题的测试人员意见；
F、声明无论结果如何，测试人员保留原意见。
然后把这个报告拿到公司例会上，主送总经理，抄送各部门负责人。使命结束。
