我将我的经历写出来，希望能够给予众多"环境不理想"的测试工作者们一点借鉴，同时也请版主和经验丰富的测试管理者指出我在工作中的不足。

　　我是三月一日进入公司的，至今有三个半月的时间，具体工作情况如下：

　　一、公司测试工作环境(刚进公司时)

　　我们公司在河南，和大多数河南的软件企业一样，测试工作都是开发的附属工作，在公司里面，都是开发人员说的算。

　　二、测试组成员

　　我们目前的测试人员总共有四人，其中一个是行业专业人员(我们的部门经理)，另两个是其他专业的，我是唯一一个计算机专业并且接受过软件测试培训的。

　　三、工作经历

　　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、声明无论结果如何，测试人员保留原意见。

　　然后把这个报告拿到公司例会上，主送总经理，抄送各部门负责人。使命结束。

　　四、总结

　　以上是我在公司三个半月的工作经历，尽管学习测试已经有一段时间了，但是真正能站到测试岗位上专职做测试也就这三个半月的时间。工作中的不足，还请大家指正。我之所以写出来，一方面是给那些在"环境不理想"的公司工作的测试人员一点借鉴;一方面也是对自己工作的一个总结，让大家来讨论一下，以弥补自己在工作中的不足。

　　鉴于好多朋友提出的需要我写的部分资料的问题，说实话我也想拿出来，但是涉及公司的保密制度，我确实没有办法拷贝出来原稿。另外，把一个公司的管理制度应用到另一个公司去，显然是不合适的，并且也是不实用的。因此，在这里我把编写规范的提纲列出来，给大家一个参考思路。同时，把自己的编写的体会拿出来和大家分享。

　　第一章软件测试流程管理

　　第一节：软件测试的术语定义

　　第二节：软件测试工作总体流程

　　第三节：公司测试流程管理模式

　　第二章：测试阶段性工作重点极其原则和标准

　　第一节：测试阶段性工作重点

　　第二节：公司软件测试的基本原则

　　第三节：公司测试的标准要求

　　第三章：软件测试标准管理

　　第一节：软件测试工作相关制度

　　第二节：公司项目的等级划分极其测试标准

　　第三节：公司测试工具应用管理

　　第四章：测试工作实施与协作管理

　　第一节：测试工作实施对象及对象发布

　　第二节：测试工作实施流程标准

　　第三节：测试退出标准

　　第四节：Bug管理平台的流程权限管理

　　附录一：《软件界面测试标准》

　　一、引言

　　二、界面标准。

　　2。1有效性检查：

　　2。2易用性检查：

　　2。3规范性检查：

　　2。4帮助设施检查：

　　2。5合理性检查：

　　2。6美观与协调性检查：

　　2。7菜单位置检查：

　　2。8独特性检查：

　　2。9快捷方式的组合检查：

　　2。10安全性检查：

　　2。11：多窗口的应用与系统资源检查：

　　附录二：《Bug等级划分及响应》

　　附录三：《软件测试通知书范例》

　　附录四：《需求变更说明书范例》

　　附录五：《软件修改通知书范例》

　　附录六：《URTracker工具定制权限说明》

　　提纲有了，但是最关键的不是有多么完善的管理制度，而是管理制度有多少能够被顺利的执行下去。没有执行力的管理规范，最多也就是一些文字而已。因此，建议在推行制度之前，一定要做好老板或者公司高层的思想工作，告诉他这样做会有一定的风险，也会遭到一些来自开发部门的阻力，但是这样执行下去之后又会有什么样的好处，改善公司目前的哪些不良现象或现状等等。总之就是要找到一个强有力的推行制度实施的领导做你的后盾。

　　版权声明：本文出自 fengxuelian 的51Testing软件测试博客：http://www.51testing.com/?225315

　　原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。