测试应该在需求阶段介入

　　测试人员不是在开发人员代码实现后才开始介入一个项目的，而是在一个项目开始立项后就开始介入，这个已经是个不争的问题了。那么，测试在项目的早期可以做哪些工作呢？测试前移是个很大的话题，本文只讨论一下需求阶段测试人员如何介入？以下所讨论的测试可以做的具体事情，无论是在V模型下还是在敏捷模式下都适用，只不过在不同的上下文中，这些事情做的程度和方式有所不同。

　　首先，需求阶段如何定义？比较完整的需求阶段至少包括两个部分：一是初始包需求（OR－Offered Requirement）确定阶段，这个阶段的参与人员会直接和市场、用服、客户沟通交流、调研，确定产品开发的初始需求；二是初始需求交给研发团队，系统工程师进一步分析，结合产品原有基础、收集内外部需求，得出产品要实现的包需求，并采用系统分析的工程方法开展对包需求的深入分析，得出更细化的需求描述，输出可以被实现的设计需求，交给软件实现人员。如果按照CMM流程，前面一个阶段CMM貌似涉及 不多，对应Charter之前的工作；后面一个阶段对应TR2之前的工作。

　　一般而言测试的前期介入大多指介入后面一个阶段，其实前面一个阶段测试也应该参与，当然，参与前面一个更早的需求分析阶段，对测试人员的要求会更高一些，需要对系统层面有较好的把握。

　　（1）测试参与早期需求分析

　　这个阶段收集到的需求都是比较粗的，测试更多的可以从系统验证的角度考虑问题，即这些粗的需求如果实现后，后期交给客户时，是否可验收，有哪些验收场景、验收的思路是什么、具体的商用使用场景、需求验收是否需要特殊的验证平台、有哪些验收难点等等。可以输出《需求验收分析报告》。这样做的好处，一是测试人员通过早期参与，更清楚需求的来源和目的，有利于后期更好的从用户的角度开展测试活动；二是可以为后期设计验收测试用例提供很好的分析依据。

　　如果您在这个阶段的测试介入有很多实践经验的话，欢迎回复本文分享！

　　（2）测试参与TR2之前的需求分析

　　这个阶段的需求仍然比较粗，至少开发人员拿到这些OR直接去实现难度还是很大的。系统工程师会从全系统的层面开展稍微细一些的需求分析，得到具体的设计需求，其主要的思路主要是针对每个OR开展场景分析，测试介入的主要工作就是重点参与场景分析工作，因为开发的SE和测试的TSE分析问题的思路是不同的，可以做到很好的互补，所以理想的方式是SE和TSE一起完成场景分析工作：SE偏向从功能、实现的角度分析，TSE更多的考虑非功能属性方面，比如可靠性、可测试性等，还会考虑用户分类、异常场景、组网的不同等，这样二者合作的结果，使得设计需求更易于实现，也一定程度消弱了需求由于分析不充分导致后期的频繁变更的问题。在敏捷项目中，测试参与的结果经常以“验收条件（Acceptance Test Conditions）”的形式体现在需求文档中，每一条需求都对应其验收条件。

　　另外，这个阶段测试还应该发挥测试的优势，提出产品的可测试性需求，以便开发在实现阶段就考虑进去。

　　当然，除了上面提到的以外，测试在早期的任何时候都可以针对开发的各种分析输出件给予很好的评审检视，缺陷越早暴露成本越低。测试在需求阶段参与的更大的意义在于实施preventive testing，这与简单的文档review是不一样的，preventive testing强调的是测试人员用他的测试知识/领域知识去challenge需求和设计，去提前验证他的idea，去explore需求，可见，探索性测试的思想完全可以在需求阶段应用。

　　此外，Richard Bender所提的基于需求的测试（ReqBT）也是一套可行的方案，在需求写作初稿阶段，ReqBT人员与需求分析人员并行交错开展工作，一点点地完成需求的模糊度分析、需求的业务逻辑分析、需求的建模以及测试条件生成等工作。

　　测试在需求阶段还可以做哪些，欢迎各位补充！