【IT168 技术文章】
刚接到这个题目的时候也有一些犯难：测试流程在不同的公司都会有微小的差异，而这些差异就有可能会决定测试流程是否是真正适用。在不同公司，不同的现状情况引入适合的测试流程，就好像如同在《寻秦记》中提到的剑圣，他的三个徒弟剑法的风格类型完全不一样同，这一点上，因材施教是非常重要的。其实在动笔撰写本文的时候之前，我一直觉的感受到很大压力很大，这其中最重要的原因莫过于怕误人子弟了。测试流程的制定不是一门科学，而有时看起来，它更像一门艺术，一个好的测试管理者其实在面对不同的公司，不同的研发阶段，会采用不同的测试流程。或是而同样的测试流程，为了真正达到执行的效果，执行的方法也可能不一样。
实施测试流程一般都是有两个原因：一是软件质量出现的了问题，虽然在某种程度上已经得到解决，但仍需要通过测试，把预防措施的方法找到并固化下来；还有另一个原因则种是软件研发的规模壮大，要求做的在流程上更加清晰，可靠更好。我个人从我自己的角度出发最怕以下一某些情况是让人非常头疼的：一种情况是，是今天刚看了一本书，被告知说这样做是规范应该这样制定的，而明天就要引入进来，完全不考虑公司的实际情况；另一种情况是“苏联模式”，二是那种即某某大公司的测试流程如此制定是这样做的，我们也要采用相同的方法这样。其实流程没有最好的，只有适合自己的，规范的测试流程不一定会帮助研发成功，反而在某些情况下会弄不好羁绊到自己自己的工作。
现在大多数测试人会犯一个共同的错误，往往——把流程设计的得很完美，但没有可操作性很差，无法帮助对于软件公司真正的目的——研发，并没有起到应有的作用成功，久而久之测试的重要性就无从谈起，测试团队也渐渐在公司变成次要部门，成为打杂的得不到应有的重视。
在流程的设计过程中，最重要的问题在于是目当前项目的特点是什么，产品经常出什么样的哪些问题，需要做什么怎样的调整，现有测试团队能不能做这样的能否做作出调整，研发团队是不是会不会能接收接受?
首先谈谈项目特点，按照项目特点，大致可以一般来说分成两类：
一种是长期进行的项目，这种项目有基本的框架，有核心的技术，应用比较稳定，这种项目要注重测试用例的积累与复用，同时也适合做单元测试，自动化测试的积累；
另一种是变更频度更高，灵活，规模不大的项目，如果做自动化测试则会出现二次开发的时间大于手工测试的时间，而且项目结束后测试用例在长期中也没有任何复用，在自动化测试人员普遍成本比较高的情况下，所以反而更适做功能测试。
虽然这两者可能在长远的目标上并不一致，但是引入测试管理平台，从测试需求、测试设计、缺陷管理等方面入手则是测试团队必备的技能。一个好的测试流程必需要有好的系统平台的支撑，如果你把测试流程设计的得很完美，跟如同小学语文教科书一样，但执行这样的流程在起来现有的资源的情况下是未免不现实，倒并非说详细的流程是洪水猛兽，只是对于一家软件公司来说，资源的限制仍然是瓶颈所在的。那流程也就没有意义，一般来说一个执行的得好的测试流程必然会有好的平台，就像我以前所在国内的几家很有声名的软件公司，其测试平台要不是么是采购的，就要么是自己开发的，但最主要是要适合自己一套适合自身特点的流程平台起了非常积极的作用。在这里也给大家建议一些好的测试平台，比如Mercury Interactive的Test Director、IBM的TestManager、Silk的一些缺陷管理平台，这些平台大多都能充分满足测试团队的要求其实都能满足大家的要求。当然，还有一些免费的开源工具也是可用的。但从长远的角度看，我还是更建议大家读者使用那些不仅仅只是满足缺陷管理的工具，而是要应该选择能集成测试需求、测试设计、测试用例、缺陷管理的工具，最好也能满足自动化的集成的，什么样的产品能满足就不多说了，免得有打广告之嫌，而商业软件，如MI或IBM的产品在这些方面都有较好的表现。
项目特点决定流程的长期目标，但对于不同产品类型的公司，可能出现的问题往往会不一样同。，比如说在金蝶的EAS-BossBOSS，、或是在金山做的游戏软件，、亦或还是在阿里巴巴做电子商务，作为测试管理者，就要具体的问题都应该区别对待。
对于EAS-Boss这样大型的软件产品，团队的规模比较大，核心技术比较稳定。但对于这样的这样的产品有以下一些特点：
由于产品比较大，手工测试时重复的工作量特别大；
引擎与产品框架比较稳定；
编译与发布的流程比较固化；
由于团队的规模比较大，接口特别多，集成测试风险特别高。
这样种产品的测试，主要是把大量的重复频度比较高的功能测试转化为自动化测试角本脚本，在开发过程中要注意，核心引擎与稳定的产品部分，尽可能使用测试框架形成单元测试集；同时由于编译与发布固化，适合做每日编译, 自动化的执行单元测试集与自动化的测试角本。在做这种测试流程时，同时还要注意引入强大的分析统计工具，比如代码覆盖与评审工具，内存检查与性能函数分析工具，出错表统计模块，达到发布、测试执行与评估自动化、一体化。由于进行每日集成，接口的问题可以尽早的暴露出来，避免了后期集成的风险。
这一点每日集成对于大型项目非常重要。同时，由于测试的自动化，大部分的自动化测试角本在空闲的时间运行，测试组可以在进入手工测试时得到比较稳定的版本，及大极大的提升了团队开发与测试的执行效率。但然而在这样的情况下，缺陷点是整个团队对研发，测试体系的技术要求特别高，其本上不亚于有时甚至难过做一个大型的项目。这样的测试流程在，在中小团队比较难以实现比较困难，而关键就在于无法降低的成本比较高。下图就是一个稳定项目的测试流程图。
游戏软件产品的测试流程又有不同。当你去带领这个测试团队一个游戏团队时，可能游戏核心引擎应该是比较相对稳定的，而游戏内部的故事情节可能会不断的变化。这时你可把一些更加稳定的程序做成比较稳定的自动化回归测试，同时加强对不断变化的游戏情节的功能测试，同时注意这些功能是不是否会影响到其它相关的模块。同时在因此，游戏测试的过程中还有一些比较有其特殊性，主要表现以下几点：
服务器的稳定性，网络流量，与安全是游戏最至关重要的，（往往有很多游戏不是不好玩，而是太不稳定）；
游戏由于有及时的即时更新，会经常在同时修改缺陷的时候，还在同一模块下增加新功能；
好的网络游戏开发，其的功能必然会是迎合玩家的需求(游戏性分析)。
对于游戏软件产品来说，这些需要特别注意重点控制的点关键，要求测试团队必需要加强以下几个方面，性能测试，代码的融合、相关性影响面的判断、版本的变更与控制，还有游戏性的分析与测试。性能测试主要加强以下几点，则需要注意在并发下服务器的稳定性监控，网络流量与游戏客户端在大场面下的表现。而版本控制在游戏软件的过程中，其意义更多——则会避免已经改了的问题重复出现，或是改了更新上去问题还是存在，如何高效的合并代码，合成游戏资源、图片与角本脚本还是一个比较难度很高的事情，尤其涉及到多个部门。而游戏性测试主要是避免那种些与游戏风格相背的情况，或是开发团队累死累活拼命完成得功能性任务做出的功能没有可延续性。
性能测试与版本控制，在大多数软件的测试流程中都会涉及，但是在不同的软件产品/项目中都有其特点。一般属于通用软件测试流程的部分，但而游戏性测试则需要对游戏感觉很好有比较深刻的了解，并由真正懂懂得的玩家的人来担任，。某些时候，他甚至可以不是一个很好的软件测试人员，但他一定是一个真正懂游戏的人，这里有一些扯远，但这里，本文稍后一节，将我会在后面会强调人的因素也决定了流程的实施。
下图是游戏迭代开发模型图
如果你去做电子商务，或是做门户，这些项目的适时性，高性能，复杂的功能会给你更高的技术要求，更高强的时间性效率挑战，对测试的设计、执行，与性能测试提出更高的要求。其实在大多数互联网公司经常会出现这样的情况：刚出去的功能又撤下来修改，或是性能达不到要求仍需要又要调优。许多一些人都会犯这样一个错，认为测试的时间不够，就只要测试执行，而忽略了其他几个环节就可以了，不做细致的分析与设计，为后续工作带来很大压力。其实，一个充分测试过的有质量保证的产品，可以减轻客服、市场等各方面很多的压力。产品在用户和研发之间，反复，几次不如晚一些上提供给用户。从另外一方面看，这还需要测试主管能顶住某些压力。时间紧迫当然这不是理由，如何在流程上保证测试的需求分析，用例的设计与研发在开发时同步进行是最重要的，这时你要加强早期的测试介入，明确卡住需求确认这一部分，。这样，在研发进入开发阶段时，测试团队也能进入测试设计。当研发开发完成时，你测试团队事实上已经其本基本上完成了大部分的测试设计，并准备进入测试执行。不要在开发提交后再去想如何测测试，抱怨之声也就不绝于耳了。这样才可能测试好一个时间比较紧的项目不管在用于测试的时间上，还是测试的质量上都无法满足要求。
同时测试设计的很好，不仅可以节约测试执行的时间，也可以在反复提交的过程中，由于用例执行的一致性，保证了测试在多次的执行中的质量。同时也有发布的标准，一是缺陷的情况，二是用例的执行与覆盖。同时由于研发给的测试时间比较紧，所以有两件事情就必需作做好：一是明确产品提交测试时间，并在研发延迟时给自己争取时间；二是在质量达不到要求的情况下，时间及时的做出反应，不要到最后在研发不了解项目质量的情况下建议研发延迟项目。为了达到上面的要求你必需要一个很好的测试平台，把设计，测试用例管理，执行与用例的联动，缺陷管理与报表统计打通，尽可能的利用平台解决事务性工作，降低流程执行的成本。也就是说，既让测试人员可以集中精力去测试，同时又能够让研发管理人员随时获取正在进行测试的进度与质量。当这些工作做到透明化时以后，就算让研发延迟发布，研发部门也会接收接受。下图是这一阶段的大致流程:
在这里可以跟大家说一下，我就曾经在产品发布权限不在测试这里部门的情况下，成功的让研发决定推迟发布了大约一半以上的项目,。大多数的测试部门主管，很难顶住来自项目/技术经理的压力是有理由的，因为他们根本不了解你做了哪些工作。有时候一些情况下，看似不可能的事情任务要想做成完成，关键要看在于事情的技巧。流程表示了只是一个大方向的东西，而且，你永远也无法将责任推卸给流程也许是对的，更多情况下，作为测试主管，需要但将做事的方法与风格可以影响到推广到测试流程的推广中。
在测试互联网项目时，还有一个更重要的就是如何保证性能。
也许大家会说不就是性能测试并不是单独存在的。其实不是完全正确，如果有充足的优秀高手人力资源做性能测试当然很好，但性能测试也不能完全保证所有的项目完全没有性能问题都完美无缺，因此，项目投入期间，同时性能测试是一个这个费时费力的工作，所以往往都是一般在资源不足的情况下开展的。作为测试主管，更应该，要学会判断那些相对更加重要的问题项目影响面会更广，需要集中做性能测试。这时你也许会问，那么会有人问其它相对不太重要的项目与问题怎么办？其实做过性能调优的人都知道，大部分的性能问题都是由于一两个弱智的SQL语句导致的，所以可以从流程上加强对SQL查询语句在I/O问题的跟踪与评审,，从而避免大部分性能问题。
上面分析了不同公司根据上文的分析，不同类型的产品在测试流程上的是有很大差异的。这时，也许大家你也许可以把握测试流程大的方向了，但真正是否适合现有的测试团队与研发团队，则仍需要精心的调整。当我遇到问题的时候，第一时间往往有时候不是去寻找流程不对的问题，而是通过现有资源与执行的方法可能需要着手来微调一下你的测试流程，直到发现问题的所在，并纪录下来，最后整合到原来设定的流程中。
这样的情况大概常常发生：比如说在需求上的处理，可能会有很多的测试人员会经常指责需求人员撰写的文档非常粗糙不详细，无法进行测试。好像在我的记忆中，需求人员常常就是被骂的得灰头土脸，但是经过这些年在测试岗位上的工作，我才渐渐发现，其实有时候需求人员更需要鼓励鼓励是比职责更加有效的工作方式。这可能是一个放之四海皆准的工作态度。，指责只能加深对立。其实在验收需求时，由于当时大家也只是知道一个大概我们的需求人员也只能从大致上把握核了解，可能大多数情况下是：原则上没有问题就通过了。但然而，这种不负责任的态度却是给我们在做的测试工作带来相当多的麻烦。也只有在这样的时候，这些问题才能真正暴露出来，从而使测试设计时就会发现很多问题并没有写清楚。一般情况下，很多测试人员这时就多半会放弃手边的工作，并消极地认为认为无法做工作无法继续下去，等东西出来，并将问题最终归结到是需求给的不详细，而大加指责。
从我对测试主管工作的记事以来，就在印象中保留了这样的一幕。记的刚进一家公司时，我团队中的人员就开始经常会有下属跟我说抱怨，公司的需求工程师让我们太失望了。需求如何如何不好，然而，多少有些经验的我，当时我是把几家国内我服务过的顶尖公司情况作了一个简单的对比，的需求跟公司的需求人员的需求做了比较这时才发现，原来我们公司的需求人员还是做的得不错的。让测试人员把心态调整过来是测试主管的另外一件事。试问，如果是你做需求作为需求工程师，是否会比他们做的好吗得更好？有了这样的基调，就可以让然后建议测试人员去总结不清楚的地方，给需求人员一个相对比较具体和明确的意见，这样顺利的了解了需求。
其实有时候不是流程不对流程在这其中并没有太多值得指责的地方，而是相互的理解与支持,换位思考而对流程的执行态度，却是更加关键的。我们不得不学会如何换位思考，并更多地从他人的角度来看待这些问题。
同样的问题还出现在还有需求变更上，很多测试人过不了这一关。总是他们指责研发人员，让研发那些本来就已经恼火的软件工程师更加火冒三丈。换位思考一番，其实不难了解，其实需求变更对研发工程师来说是更大的麻烦。他们需要修改设计、代码，相较而测试只要需改测试用例，他们的工作确实更加麻烦。简单来说，就ok了，其实大家要分析什么样的需求变更最可怕，而不是眉毛胡子一把抓,其实测试对需求变更并不可怕，怕的是只有在提交时才发现，导致测试时间不够，才会真正让测试人员心慌。这时需要从研发流程上保证变更及时的通知到测试就可以了行。也许有人会说你也需要说，说的倒很容易，如果研发不按照你的要求做怎么办！其实这里你只要用我所采用的方法是用数据说话，在项目进行时统计发生过多少次这样的事情，让研发管理层知道，让项目组之间有一个比较。一方面，如果是一家公司重视质量的公司，必然会引起重视；另一方面，从质量管理部门角度本身出发，也应该推动公司重视质量，随着时间的增加，需求变更给测试人员的反馈一定会有下降的趋势。关键是测试不能抓住鸡毛就一直揪着不放宽容一些来看待身边的同事，要允许别人他们犯错，对于解决问题本身来说会大有裨益。只要趋势是好的就可以了。同时如果出现这样的情况并且极大影响到了测试进度，则要与研发部门沟通清楚，如果研发不认可的情况下还可以请上级进行评估一下。
上面说的是不同态度在同样流程下的实现不同结果,下面主要讲一下关于自身资源是否胜任做流程上规定的事情，某些工作，也许并不一定是测试部门的优势，而另外一些，则需要根据测试团队的基本能力和资源进行评估。比如像性能测试、SQL的trace、自动化功能测试、单元测试集成、游戏性测试。其实这些流程上的关键点，可能大多数从功能测试上来一路走来的测试人员是无法做的到，这时要善于利用资源，不一定要测试做，可以从通过流程上保正有人来做积极调动其它部门的同事，或是找有能力的人来做，测试可以进行监控。其实这种技术含量高一点的测试，对人的因素要求更大高，可以借助研发团队一起来做会有更好的效果。记的第一次做Oracle数据库性能监控时，就是请的Oracle的DBA专家帮助设计了性能参数，成功的地进行了关于Oracle应用的性能测试。现在国内的测试人员普遍的技术水平不高，严重的限制了测试的发展，希望测试的同行能真正的提升测试技术水平，把这些高难度的测试做起来，而不是仅仅只是工具上玩玩。只有真正提升测试团队的技术含量，这样别人才会更信赖你，这也是我这么多年来的一点经验。如果你对开发很精通，、同时又精通对测试颇有研究，善于诊断性能与架构上的问题，经常会帮助研发部门解决一些他们无法解决的事情，同时又还懂的如何做测试管理，并了解研发人员的心态，那就真得的找不出你还有不成功的理由了任何理由让人不对你刮目相看了。
