【IT168 技术文章】
软件测试V模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中，7 0 %～8 5 %的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，这是一件及其痛苦的事情。因此我们要求在项目的源头（需求）就开始测试。这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这些工具会要求我们按照某个固定的格式进行需求的表述（例如形式化的方法），因此在适用性上会受到限制。通过静态手工方法进行需求测试中最常使用的手段是同行评审。
通过评审来测试需求
同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中，使用最多的也是同行评审（Peer Review），尤其是正规检视（Inspection）。正规检视是由Michael Fagan 在I B M 制定出来的一种非常严格的评审过程。
需求评审的参与者当中，必须要有用户或用户代表参与，同时还需要包括项目的管理者，系统工程师和相关开发人员、测试人员、市场人员、维护人员等。在项目开始之初就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏掉某些人员的意见，导致今后不同程度的返工。
好的需求应当具有的特点
一个良好的需求应当具有一下特点：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（f i n e - g r a i n e d ）的方式编写并单独标明，而不是大段大段的叙述。
另外应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度
通过用例设计来测试需求
我们从V模型上可以知道，验收测试是以系统需求为基础的，系统测试是以功能测试为基础。每个开发阶段的活动都与相应的测试活动是并行进行的。在需求阶段进行系统（验收）测试计划和设计，除了能指导最终的系统测试和验收测试执行外，其本身也是对需求的一个验证过程。
通过阅读软件需求规格说明书，通常很难想象在特定环境下的系统行为。以功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系统的行为。虽然没有在运行系统上执行测试用例，但是设计测试用例的简单动作可以解释需求的许多问题。如果你在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。
设计概念性测试用例可以发现需求的错误、二义性、不可测性、遗漏等方面问题，为了获得最大的效果，要求测试人员能够独立的去对需求进行思维，从一个不同于开发的角度上进行分析，这可能会是一个逆向的思维过程，在这个过程中，测试人员可能会设计出不同于需求的测试用例，而这最终可能会有两个解释：
1、需求不完整或者需求有错；
2、遗漏了测试用例或者测试用例本身有错误；
不管是哪种解释，最终肯定会提高整个系统的质量。但这个质量的获得是通过冗余的人员来完成的，即：开发人员在对系统需求进行进一步分析的时候，有一组独立的测试人员也在对系统需求进行独立的思维，并从中获取测试用例。尽管这两种思维可能会出现重复，但由于思维的方式不同，最终肯定会使得需求变得更清晰和更完善。
需求建模测试
需求的建模包括把需求转换成图形模型或形式化语言模型。需求的图形化分析模型包括数据流图（Data Flow Diagram，DFD）、实体关系图（Entity-Relationship Diagram，ERD）、状态转化图（State-Transition Diagram，STD）、对话图（Dialog Map）和类图（Class Diagram）。这些图形化模型一般都需要借助一定的CASE（Computer-Aided Software Engineering）工具。这样就可以借助于自动化分析工具本身提供的检测手段来对需求进行测试，而这类检测主要可以提供描述上的完整性检查，需求项之间的不一致性检查等方面的功能。同时，使用这类自动分析工具有助于获得需求的质量特性，包括：有效性、一致性、可靠性、可存活性、可用性、正确性、可维护性、可测试性、可扩展性、可交互性、可重用性、可携带性等。
