《成为测试主管第一步——制定测试流程》.doc

成为测试主管第一步——制定测试流程 刚接到这个题目的时候也有一些犯难：测试流程在不同的公司都会有微小的差异，而这些差异就有可能会决定测试流程是否是真正适用。在不同公司，不同的现状情况引入适合的测试流程，就好像如同在《寻秦记》中提到的剑圣，他的三个徒弟剑法的风格类型完全不一样同，这一点上，因材施教是非常重要的。其实在动笔撰写本文的时候之前，我一直觉的感受到很大压力很大，这其中最重要的原因莫过于怕误人子弟了。测试流程的制定不是一门科学，而有时看起来，它更像一门艺术，一个好的测试管理者其实在面对不同的公司，不同的研发阶段，会采用不同的测试流程，或是而同样的测试流程，为了真正达到执行的效果，执行的方法也可能不一样。 　　实施测试流程一般都是有两个原因：一是软件质量出现的了问题，虽然在某种程度上已经得到解决，但仍需要通过测试，把预防措施的方法找到并固化下来；还有另一个原因则种是软件研发的规模壮大，要求做的在流程上更加清晰，可靠更好。我个人从我自己的角度出发最怕以下一某些情况是让人非常头疼的：一种情况是，是今天刚看了一本书，被告知说这样做是规范应该这样制定的，而明天就要引入进来，完全不考虑公司的实际情况；另一种情况是“苏联模式”，二是那种即某某大公司的测试流程如此制定是这样做的，我们也要采用相同的方法这样。其实流程没有最好的，只有适合自己的，规范的测试流程不一定会帮助研发成功，反而在某些情况下会弄不好羁绊到自己自己的工作。 　　● 现在大多数测试人会犯一个共同的错误，往往——把流程设计的得很完美，但没有可操作性很差，无法帮助对于软件公司真正的目的——研发，并没有起到应有的作用成功，久而久之测试的重要性就无从谈起，测试团队也渐渐在公司变成次要部门，成为打杂的得不到应有的重视。 　　● 在流程的设计过程中，最重要的问题在于是目当前项目的特点是什么，产品经常出什么样的哪些问题，需要做什么怎样的调整，现有测试团队能不能做这样的能否做作出调整，研发团队是不是会不会能接收接受？ 　　首先谈谈项目特点，按照项目特点，大致可以一般来说分成两类： 　　● 一种是长期进行的项目，这种项目有基本的框架，有核心的技术，应用比较稳定，这种项目要注重测试用例的积累与复用，同时也适合做单元测试，自动化测试的积累； 　　● 另一种是变更频度更高，灵活，规模不大的项目，如果做自动化测试则会出现二次开发的时间大于手工测试的时间，而且项目结束后测试用例在长期中也没有任何复用，在自动化测试人员普遍成本比较高的情况下，所以反而更适做功能测试。 　　● 虽然这两者可能在长远的目标上并不一致，但是引入测试管理平台，从测试需求、测试设计、缺陷管理等方面入手则是测试团队必备的技能。一个好的测试流程必需要有好的系统平台的支撑，如果你把测试流程设计的得很完美，跟如同小学语文教科书一样，但执行这样的流程在起来现有的资源的情况下是未免不现实，倒并非说详细的流程是洪水猛兽，只是对于一家软件公司来说，资源的限制仍然是瓶颈所在的，那流程也就没有意义，一般来说一个执行的得好的测试流程必然会有好的平台，就像我以前所在国内的几家很有声名的软件公司，其测试平台要不是么是采购的，就要么是自己开发的，但最主要是要适合自己一套适合自身特点的流程平台起了非常积极的作用。在这里也给大家建议一些好的测试平台，比如Mercury Interactive的Test Director，、IBM的TestManager，、Silk的一些缺陷管理平台，这些平台大多都能充分满足测试团队的要求其实都能满足大家的要求。，当然，还有一些免费的开源工具也是可用的。但从长远的角度看，我还是更建议大家读者使用那些不仅仅只是满足缺陷管理的工具，而是要应该选择能集成测试需求、测试设计、测试用例、缺陷管理的工具，最好也能满足自动化的集成的，什么样的产品能满足就不多说了，免得有打广告之嫌J，而商业软件，如MI或IBM的产品在这些方面都有较好的表现。 　　● 项目特点决定流程的长期目标，但对于不同产品类型的公司，可能出现的问题往往会不一样同。比如说在金蝶的EAS-BossBOSS、或是在金山做的游戏软件、亦或还是在阿里巴巴做电子商务，作为测试管理者，就要具体的问题都应该区别对待。 　　对于EAS-Boss这样大型的软件产品，团队的规模比较大，核心技术比较稳定。但对于这样的这样的产品有以下一些特点： 　　● 由于产品比较大，手工测试时重复的工作量特别大； 　　● 引擎与产品框架比较稳定； 　　● 编译与发布的流程比较固化； 　　● 由于团队的规模比较大，接口特别多，集成测试风险特别高。 　　这样种产品的测试，主要是把大量的重复频度比较高的功能测试转化为自动化测试角本脚本，在开发过程中要注意，核心引擎与稳定的产品部分，尽可能使用测试框架形成单元测试集；同时由