测试流程在不同的公司都会有这样那样的差异，而这些差异就有可能会决定测试流程是否是真正适用。在不同公司，不同的现状情况引入适合的测试流程，就好像如同在《寻秦记》中提到的剑圣，他的三个徒弟剑法的风格类型完全不一样同，这一点上，因材施教是非常重要的。

　　实施测试流程一般都是有两个原因：一是软件质量出现的了问题，虽然在某种程度上已经得到解决，但仍需要通过测试，把预防措施的方法找到并固化下来，也就是经验的固化;还有另一个原因则种是软件研发的规模壮大，要求做的在流程上更加清晰，可靠更好。

　　在流程的设计过程中，最重要的问题在于是当前项目的特点是什么，产品经常出什么样的哪些问题，需要做什么怎样的调整，现有测试团队能不能做这样的能否做作出调整，研发团队是不是会不会能接收接受?

　　首先谈谈项目特点，按照项目特点，大致可以一般来说分成两类：

　　一种是长期进行的项目，这种项目有基本的框架，有核心的技术，应用比较稳定，这种项目要注重测试用例的积累与复用，同时也适合做单元测试，自动化测试的积累;

　　另一种是变更频度更高，灵活，规模不大的项目，如果做自动化测试则会出现二次开发的时间大于手工测试的时间，而且项目结束后测试用例在长期中也没有任何复用，在自动化测试人员普遍成本比较高的情况下，所以反而更适做功能测试。

　　项目特点决定流程的长期目标，但对于不同产品类型的公司，可能出现的问题往往会不一样同。比如说微软的windows7、亦或还是在阿里巴巴做电子商务，作为测试者，就要具体的问题都应该区别对待。

　　对于windows7这样大型的软件产品，团队的规模比较大，核心技术比较稳定。但对于这样的产品有以下一些特点：

　　● 由于产品比较大，手工测试时重复的工作量特别大，有些模块基本无法手工测试;

　　● 引擎与产品框架比较稳定;

　　● 编译与发布的流程比较固化;

　　● 由于团队的规模比较大，接口特别多，集成测试风险特别高。

　　这种产品的测试，主要是把大量的重复频度比较高的功能测试转化为自动化测试角本脚本，在开发过程中要注意，核心引擎与稳定的产品部分，尽可能使 用测试框架形成单元测试集;同时由于编译与发布固化，适合做每日编译，自动化的执行单元测试集与自动化的测试角本。在做这种测试流程时，同时还要注意引入 强大的分析统计工具，比如代码覆盖与评审工具，内存检查与性能函数分析工具，出错表统计模块，达到发布、测试执行与评估自动化、一体化。由于进行每日集 成，接口的问题可以尽早的暴露出来，避免了后期集成的风险。

　　这一点每日集成对于大型项目非常重要。同时，由于测试的自动化，大部分的自动化测试角本在空闲的时间运行，测试组可以在进入手工测试时得到比较稳定 的版本，及大极大的提升了团队开发与测试的执行效率。然而在这样的情况下，缺陷点是整个团队对研发、测试体系的技术要求特别高，其本上不亚于有时甚至难过 做一个大型的项目，当年我做windows7的测试时，从测试框架到测试case，再到测试资源的控制，dump文件收集分析，报表的生成等等的开发量不 亚于一个大型的项目。这样的测试流程在，在中小团队比较难以实现比较困难，而关键就在于成本比较高。

　　如果你去做电子商务，或是做门户，这些项目的适时性，高性能，复杂的功能会给你更高的技术要求，更高强的时间性效率挑战，对测试的设计、执行、与性 能测试提出更高的要求。其实在大多数互联网公司经常会出现这样的情况：刚出去的功能又撤下来修改，或是性能达不到要求仍需要又要调优。一些人都会犯这样一 个错，认为测试的时间不够，就只要测试执行，而忽略了其他几个环节就可以了，不做细致的分析与设计，为后续工作带来很大压力。其实，一个充分测试过的有质 量保证的产品，可以减轻客服、市场、等各方面的很多的压力。产品在用户和研发之间，反复，几次更改晚一些提供给用户。从另外一方面看，这还需要测试人能顶 住某些压力。时间紧迫当然这不是理由，如何在流程上保证测试的需求分析、用例的设计与研发在开发时同步进行是最重要的，这时你要加强早期的测试介入，明确 卡住需求确认这一部分。这样，在研发进入开发阶段时，测试团队也能进入测试设计。当研发开发完成时，你测试团队事实上已经其本基本上完成了大部分的测试设 计，并准备进入测试执行。不要在开发提交后再去想如何测测试，抱怨之声也就不绝于耳了。这样才可能测试好一个时间比较紧的项目，不管在用于测试的时间上， 还是测试的质量上。

　　注重测试用例的设计，测试设计的很好，不仅可以节约测试执行的时间，也可以在反复提交的过程中，由于用例执行的一致性，保证了测试在多次的执行中的 质量。同时也有发布的标准，一是缺陷的情况，二是用例的执行与覆盖。同时由于研发给的测试时间比较紧，所以有两件事情就必需作做好：一是明确产品提交测试 时间，并在研发延迟时给自己争取时间;二是在质量达不到要求的情况下，时间及时的做出反应，不要到最后在研发不了解项目质量的情况下建议研发延迟项目。为 了达到上面的要求你必需要一个很好的测试平台，把设计，测试用例管理，执行与用例的联动，缺陷管理与报表统计打通，尽可能的利用平台解决事务性工作，降低 流程执行的成本。也就是说，既让测试人员可以集中精力去测试，同时又能够让研发管理人员随时获取正在进行测试的进度与质量。当这些工作做到透明化时以后， 就算让研发延迟发布，研发部门也会接收接受。

　　在测试互联网项目时，还有一个更重要的就是如何保证性能。

　　也许大家会说不就是性能测试并不是单独存在的。其实不是完全正确，如果有充足的优秀高手人力资源做性能测试当然很好，但性能测试也不能完全保证 所有的项目完全没有性能问题都完美无缺，因此，项目投入期间，同时性能测试是一个这个费时费力的工作，所以往往都是一般在资源不足的情况下开展的。作为测 试者，更应该，要学会判断那些相对更加重要的问题项目影响面会更广，需要集中做性能测试。这时你也许会问，那么会有人问其它相对不太重要的项目与问题怎么 办，?其实做过性能调优的人都知道，大部分的性能问题都是由于一两个弱智的SQL语句导致的，所以可以从流程上加强对SQL查询语句在I/O问题的跟踪与 评审，从而避免大部分性能问题。

　　根据上文的分析，不同类型的产品在测试流程上的是有很大差异的。这时，也许大家你也许可以把握测试流程大的方向了，但真正是否适合现有的测试团 队与研发团队，则仍需要精心的调整。当我遇到问题的时候，第一时间往往有时候不是去寻找流程不对的问题，而是通过现有资源与执行的方法可能需要着手来微调 一下你的测试流程，直到发现问题的所在，并纪录下来，最后整合到原来设定的流程中。

　　这样的情况大概常常发生：比如说在需求上的处理，可能会有很多的测试人员会经常指责需求人员撰写的文档非常粗糙不详细，无法进行测试。好像在我 的记忆中，需求人员常常就是被骂的得灰头土脸，但是经过这些年在测试岗位上的工作，我才渐渐发现，其实有时候需求人员更需要鼓励鼓励是比职责更加有效的工 作方式。这可能是一个放之四海皆准的工作态度，指责只能加深对立。其实在验收需求时，由于当时大家也只是知道一个大概我们的需求人员也只能从大致上把握核 了解，可能大多数情况下是：原则上没有问题就通过了。但然而，这种不负责任的态度却是给我们在做的测试工作带来相当多的麻烦。也只有在这样的时候，这些问 题才能真正暴露出来，从而使测试设计时就会发现很多问题并没有写清楚。一般情况下，很多测试人员这时就多半会放弃手边的工作，并消极地认为无法做工作无法 继续下去，要等东西出来，并将问题最终归结到是需求给的不详细，而大加指责。

　　其实有时候不是流程不对，流程在这其中并没有太多值得指责的地方，而是相互的理解与支持，换位思考而对流程的执行态度，却是更加关键的。我们不得不学会如何换位思考，并更多地从他人的角度来看待这些问题。

　　同样的问题还出现在还有需求变更上，很多测试人过不了这一关。总是他们指责研发人员，让研发那些本来就已经恼火的软件工程师更加火冒三丈。换位思考 一番，其实不难了解，其实需求变更对研发工程师来说是更大的麻烦。他们需要修改设计、代码，相较而测试只要需改测试用例，他们的工作确实更加麻烦。简单来 说，就ok了，其实大家要分析什么样的需求变更最可怕，而不是眉毛胡子一把抓，其实测试对需求变更并不可怕，怕的是只有在提交时才发现，导致测试时间不 够，才会真正让测试人员心慌。这时需要从研发流程上保证变更及时的通知到测试就可以了行。