摘要：

　　测试人员越早介入项目工作越好的观点已经被越来越多的测试人员所接受。在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵的论断也已经成为了大家的共识。

　　测试人员需要参加需求评审，我想大部分测试人员都接受了这个观点，同时也是这么做的。但测试人员为什么需要参加需求评审，恐怕不是每一个人都知道个中道理。本文从作者多年从事软件测试和过程管理的经验出发进行论述，供同行们参考。

　　关键词：

　　测试 测试人员 需求评审

　　正文：

　　我们知道，在项目的生命周期中，需求、设计、编码、测试等活动往往是由不同的专业技术人员协同完成的。这样，由于下游技术人员对上游技术人员工作产出物的理解偏差，将导致不同阶段的产出物之间不一致的现象出现，这也是导致项目可能不成功的重要风险之一。

　　基于以上的观点，需求人员编写的《用户需求说明书》、系统设计人员编写的《系统设计说明书》、编码人员实现的系统、测试人员编写的《测试用例》之间不可避免地存在不一致的现象。

　　由于测试工作的主要面向对象是《用户需求说明书》和可运行系统，为便于分析，我们先用图来表述一下三者之间的关系：

　　从理论上讲，上图中“需求”(S圆表示)、“可运行系统” (P圆表示)和“测试用例” (T圆表示)应该是重合，但实际上这三个圆很难重合。

　　从上图可以看出：可能会有没有测试到的已描述行为(区域2和区域5);经过测试的已描述行为(区域1和区域4);对应未描述行为的测试用例(区域3和区域7);可能会没有测试的程序行为(区域2和区域6);经过测试的程序行为(区域1和区域3);对应于未通过程序实现的行为(区域4和区域7)。

　　由于我们今天讨论的主题是“测试人员为什么需要参加需求评审”，因此我们重点来看看与这一问题关系密切的区域2和区域5、区域3和区域7。

　　区域2和区域5这两部分是测试用例没有覆盖到的需求，即“没有正确的测试用例与该部分需求对应”。出现这种情况本人认为有三种可能：

　　1、 设计测试用例的测试人员对需求理解不完整，出现了应该被测试的需求而没有被测试用例覆盖到的现象;

　　2、 《用户需求说明书》中区域2和区域5对应的需求，具有不可测试性，测试人员无法设计用例;

　　3、 《用户需求说明书》中区域2和区域5对应的需求，不是用户的需求，是需求分析人员凭空增加的，测试人员无须设计与这部分需求对应的测试用例。

　　区域3和区域7这两部分是需求没有覆盖到的测试用例，即“没有正确的需求与该部分测试用例相对应”。出现这种情况本人认为有两种可能：

　　1、设计测试用例的测试人员对需求理解不充分，从而设计出了多余的测试用例;

　　2、《测试用例》中区域3和区域7的测试用例所对应的需求，是用户的真实需求，只是《用户需求说明书》中没有描述到而已。

　　从上面的分析可以看出，如果测试人员参加了“需求评审”，则上面出现的问题可以最大程度地避免，因为测试人员参加“需求评审”的重要作用正是针对产生这些问题的因素而进行的。

　　由此总结出，测试人员参加“需求评审”活动所需要达到的目标包括如下三个方面：

　　1、充分地理解需求，确保对需求的理解与需求分析人员是一致的;

　　2、从可测试的角度，努力发现《用户需求说明书》中不可测试的需求，从而提醒需求分析人员尽早修改;

　　3、从测试人员的角度努力发现《用户需求说明书》中的不完整性，从而提醒需求分析人员及时补充遗漏掉的这部分用户需求。