将测试关联到需求
跟踪测试至需要检查的需求。

        跟踪是在开发过程中记录工件之间关系的一种方法。跟踪的最通用形式是不同层之间的需求达标 关系。但是捕获需求和测试（显示需求已被满足）之间的限定 关系也很重要。
通过跟踪，可以执行如下两种分析：

 • 覆盖率分析 用于确保每个需求至少计划了一个限定活动并最终执行限定活动。它还可以确保每个限定活动都拥有相关需求，从而获得收益。

 • 影响分析 用于在需求发生变更的时候决定需要修改的限定活动。在接受需求变更之前，将考虑重新定义和重新执行相关限定活动的成本。同理，在测试失败之后，可以从需求的角度查看失败的影响。
        我们通过分析达标 和限定 的关系就可以确定潜在的返工工作。例如，如果组件测试失败，则受影响的不仅仅是组件的相关需求（通过限定 关系），还影响那些组件需求应该要满足的子系统需求（通过达标 关系），还将影响系统和客户需求。

        仅仅通过测试子系统的组件是无法达到全面测试子系统的需求的；这与需求管理中涌现性质 的概念是一致的：系统不只是各个部件的总和，有些行为是需要组件之间进行交互才能出现。因此在每一层都执行测试是很有必要的。

将缺陷关联到需求

        跟踪缺陷至显示尚未被满足的需求。 
        当测试发现异常行为或测试标准未能实现的时候，缺陷就产生了。以下三种情况可能导致产生缺陷：
 • 测试的定义中含有错误
 • 需求的表达或需求的限定标准中含有错误
 • 产品中含有真正的缺陷
        在上述的任何一种情况下，都可以通过跟踪缺陷至显示尚未被满足的需求的方式来识别缺陷。因为缺陷被定义为偏离需求的事项，所以这是一个好的规范。因为每个测试都会被跟踪至多个需求，所以需要分析每个缺陷来确定哪些需求受到了影响。

根据需求测量进度
        从那些显示已被满足或尚未满足的需求的角度设定测试目标和测量测试进度。

        开发过程中，最难决策之一便是测定何时已执行了足够测试。在资源有限的情况下，测试经理需要知道将工作集中到何处才能最有效。当测试从需求隔离出来之后，测试经理无法获得关于系统不同方面的相对重要性的信息，这样就难分配资源和评估失败的影响。

        通过在相应的地方提供相应跟踪，可以根据需要，将每个测试的相对重要性和测试的成与败关联到相应层上受影响的需求（客户需求、系统需求等）。可以从需求的角度设定测试（已完成）的目标。测试经理知道将资源应用于何处，并可以生成报告以从需求的角度显示测试的进度。

        到这里，我们就不难看出，需求在测试过程中占有着多么重要的地位，通过对需求和测试二者合理的关联，应用，对软件产品的质量，开发的周期以及成本都有着不可估量的价值。下面通过图形对比，介绍一下经典的 V 模型的演进版 W 模型。

W 模型

        当我们考虑如何最有效地实施这些原则的时候，一种流程和数据模型应运而生，即所谓的 W 模型，它是 V 模型的演进版。经典的 V 模型如图 1 所示，其中圆形方框表示生命周期中的各种活动。（此模型不应解释为“瀑布”模型，因为所有这些活动都可以并行开展，并持续获得反馈。）