测试人员需要参加需求评审，我想大部分测试人员都接受了这个观点，同时也是这么做的。但测试人员为什么需要参加需求评审，恐怕不是每一个人都知道个中道理。本文从作者多年从事软件测试和过程管理的经验出发进行论述，供同行们参考。
关键词：测试 测试人员 需求评审正文：我们知道，在项目的生命周期中，需求、设计、编码、测试等活动往往是由不同的专业技术人员协同完成的。这样，由于下游技术人员对上游技术人员工作产出物的理解偏差，将导致不同阶段的产出物之间不一致的现象出现，这也是导致项目可能不成功的重要风险之一。
基于以上的观点，需求人员编写的《用户需求说明书》、系统设计人员编写的《系统设计说明书》、编码人员实现的系统、测试人员编写的《测试用例》之间不可避免地存在不一致的现象。
由于测试工作的主要面向对象是《用户需求说明书》和可运行系统，为便于分析，我们先用图来表述一下三者之间的关系：从理论上讲，上图中“需求”（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、从测试人员的角度努力发现《用户需求说明书》中的不完整性，从而提醒需求分析人员及时补充遗漏掉的这部分用户需求。