应该说这不是一篇文章，这应该属于是一个讨论的话题吧，无论观点是否正确，希望大家能够在论坛里面可以发表自己的见解。尤其在这方面深有感触的朋友。

　　提起这个话题的原因是因为现在一个项目里面测试人员的介入是到开发后期阶段??编码工作完成之后介入的，我认为很不合理，所以提出这个问题。从大的方面来考虑的话，现在流程的测试模型有三种： V模型，W模型，H模型。而在这三种模型里面，无论哪一种模型，测试的介入都是在软件开发过程的前期介入的。测试工作在这时介入，无论从哪方面考虑，都比我们直到开发过程的后期才介入更有好处。

　　从成本方面来看：前期介入也许增加了测试人员的成本，但是相对于后期的投入和项目的风险方面，这个成本显然远远小于后期的投入，前期发现的Bug的修改代价比后期的修改代价小多了，如果把成本投入跟介入时间进行比较的话，那么应该可以得到如下的结论：介入时间越早，成本投入越小，反之越大。在需求调研阶段，设计阶段，编码阶段，测试阶段，产品出货阶段我们都会发现bug，但是处理bug的代价在这几个阶段却是截然不同的，越往后代价越高。做过项目的人应该都有体会的。

　　从项目风险来看：如果把编码阶段作为风水岭的话，编码阶段之前的工作为前期工作，编码阶段包括编码之后的工作为后期工作。一个问题在开发过程的前期被发现，则可以很大程度上降低项目的风险问题，如果在后期发现一个问题，将不可避免地要面对项目风险问题。很多时候一个项目后实施的失败大部分都是在后期发现的问题所致的。当然这不是实施失败的全部因素。

　　从其他方面来考虑，都是前期介入比后期介入的情况好的。但是目前所遇到的情况是：等需求调研完成之后测试人员一起进行需求整理，这个时候我觉得很迷糊的一点是测试人员都没有参加过需求调研，让测试人员进行需求调研整理，那不是需要重复一次工作吗？很多问题测试人员还是要去问进行调研的人的。我觉得效率不是很高。而且经过中间的一道程序很多时候会发生一种曲解需求的现象。

　　所以测试人员的介入从有些方面来说还是值得一个项目小组的负责人考虑的，不能只是从投入成本来考虑，而且如果要从成本方面考虑的话那么请考虑整个项目周期的成本。项目风险是项目负责人必须面对的一个问题，而在这个问题上重要的一个环节是测试人员来进行把关的，当然有的公司在测试人员之后还有QA来负责质量的。其实关于这个话题要详细展开的话不是三言两语可以说完的。只是有感而发。更何况有时候很多公司的规定都是不一样的。有时候有些流程不一定往日的经验是很好的总结，该改新的时候还是需要动手术的。一成不变只能固步自封。墨守成规只能停滞不前。

　　我希望我们的测试人员不只是在程序员写好程序之后直接把程序交付我们，并且附上一些应该算不上垃圾的但是并不很完整的文档交付成功了，然后我们按照流程说明进行键盘输入，鼠标点击的动作。我希望我们能更早的介入到项目当中。了解更多，做到更多，同时也学到更多。不要当一个廉价的可有可无的角色。那是一种悲哀！！！

　　其实有时候觉得测试也可以进行分阶段，比如需求调研时候了解需求，然后等开发人员进行设计时候我们对需求进行剖解，然后提交代码之后再开始执行测试，中间可以根据需求和设计做很多测试计划，测试设计策略等方面的事情，主要包括测试计划，测试用例的设计，产出，并且准备相关测试数据。然后主要的一点是要对自己进行的项目测试有一个很可观，比较全面的测试风险等的评估。

　　以下是几个同行的跟帖，供大家参考：

　　吕不为：程序开发人员进行的是创造代码的活动，所以，很多初级程序员在写代码之前，很明白自己在要做什么，该怎么做。但是，当开始写代码时，随着时间的流逝，目的不再那么清晰了，也偏离了原先自己的思路，只是顾全自己的部分逻辑，而对整体的业务逻辑不是很清楚。所以，为了保证程序员的正确航向，测试人员应该在程序员写代码前，先写出测试用例，因为测试人员关心的是代码运行的结果是否符合用户的业务流程以及是否实现了预定的目标。相对来说，测试人员比开发人员更了解用户对软件的需求。因为测试是面向业务流程的，而软件开发是按模块分工的。所以，我们的做法是，在调研用户需求的时候，首先写出测试用例，用来规范程序开发人员的工作范围，使他们能在正确的道路上前进而不会偏离用户需求太远。当用户需求变化时，测试人员更改用例，开发人员修改代码，以通过用例为准。

　　周舟：提到介入阶段，做了这么多项目我倒以为这不是该有很严格界定的，也确实真的很难界定，因为不论是需求，设计，永远不变的是一切都在变，甚至上线应用之后，用户认为不满意，那也还得再变。

　　所以依据需求分析，概要设计......写出来的测试用例也很难一成不变。所以只要需求，设计都要变，测试是有风险的。算一切都是安装需求和设计写出来的，但那些不是用户终要求，终这样白忙活了一场。

　　我以为测试不论什么时候介入，了解和理解用户的终需求是必须和万无一失并适合中国国情的。

　　当然若是需求分析和设计能够很好的了解和理解需求，那测试的工作到是可以减轻许多，并风险也会小很多。只要测试“实现的功能是否正确”行了，而不必费心于“系统是否实现了正确的功能”的测试。

　　逐渐的行业背景知识竟也成了对测试人员的一种竟聘要求。

　　Leveret：To 周舟：“逐渐的行业背景知识竟也成了对测试人员的一种竞聘要求。”这句话正在被越来越多的企业应用到，不仅仅是测试知识，相关的行业背景知识也是很重要的，需求很难被固定，用例总是在改动，这都是很正常的。思考了很久，也真的很难总结出真正的一个介入的分水岭。还是活学活用吧，根据自己的实际，不要脱离科学的轨迹。路漫漫其修远兮，偶们将上下而求索。