需求阶段测试可以做哪些事情？

MILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">测试人员不是在开发人员代码实现后才开始介入一个项目的，而是在一个项目开始立项后就开始介入，这个已经是个不争的问题了。那么，测试在项目的早期可以做哪些工作呢？测试前移是个很大的话题，今天只讨论一下需求阶段测试人员如何介入？

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

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

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

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

当然，这个阶段的实践经验目前应该比较少，至少测试业界还没有形成完整的理论体系，欢迎网友分享经验。

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

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

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

当然，除了上面提到的以外，测试在早期的任何时候都可以针对开发的各种分析输出件给予很好的评审检视，我们都知道缺陷越早暴露成本越低。