随着中国软件市场的不断发展和成熟，软件市场的竞争越来越激烈，客户对软件产品质量的要求也逐步提高。目前各个企业所面临的挑战主要是体现在：满足客户持续升高的期望、缩短产品上市时间和提高产品/系统/软件的质量。质量永远是检验一个产品是否合格的参照物，而测试又是检验一个产品质量的重要环节。一个合格的软件产品，后期在测试它的质量时所耗费的精力、时间与开发它相差无几。因此，做好测试工作也是提升一个企业竞争力的重要因素。

        本文概述了需求驱动测试的优点；需求驱动测试组合了需求管理和测试管理在流程方面的最佳实践。还将查看用于指导集成流程的原则，并简介经典的 V 模型的演进版 W 模型。首先给大家阐述几个相关的概念：

什么是需求管理？

        需求是必须通过产品或流程满足的声明。
        需求多种多样，而且用于描述需求的词语也非常丰富。例如，下列词语都可看作需求：目标、志向、条件、合同、限制、终点、要求、需要、目的、责任、规定、必要条件、规则、规格和指标。选用词语“需求 ”作为所有这些概念的同义词，并将之用于表示个人声明、条款或条目（而非整个需求文档）。

        需求管理由一套规范和活动组成。是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。
        很多人错误地认为仅在项目定义阶段才开展需求管理。事实上，需求以一种形式或另一种形式存在于开发的各个阶段。尤其在测试的各个阶段（甚至开发的最后阶段），需求起着至关重要的作用
需求管理中的三个关键规范与本文关系非常密切：

 • 如何表述需求。需求不仅应该精简和明确，而且还应该具有可测试性。通常意在确保可以适当量化需求和明确识别测试标准。这些测试标准提供测试阶段使用的必要信息。

 • 如何分类需求。所有需求天生并非平等。有些需求远重要于其它需求。为有效管理开发，必须以最适合应用程序的方式分类每个需求声明，这样在分配资源的时候可以制定工程和管理方面的决策。

 • 如何跟踪需求。创建跟踪是需求管理的重要组成部分。通过沿着开发阶段的正方向和逆方向跟踪需求、向前和向后跟踪测试至相关需求的功能，能够以各种方式报告项目进度和分析变更影响。

什么是测试？

        测试是任何以发现缺陷为目的的活动。
        这是测试的故意宽泛定义。它覆盖各种早期活动（如评审需求、检查设计、概览结构和从建模进行分析）和传统的单元测试、系统测试和验收测试阶段。

        就很多人而言，这个定义太宽泛，因为它偏离测试的传统定位（肯定位于 V 模型的右侧）。但是该定义承认：在真正构建和编码之前，可以“测试”（评审、核实、验证、限定和评估）需求和设计本身。
        为符合该定义的宽度，我们选用词语“限定 ”来涵盖测试、核实、验证和评估。因此“测试标准”变为“限定标准”，“测试计划”变为“限定计划”。

缺陷是任何偏离需求的事项

        理想状态下，通过参考需求即可识别缺陷。有些需求直接针对产品（源于客户），而有些需求则针对开发流程（标准和程序）。后者将封装最佳实践，而最佳实践又是专门为减少引入和传播缺陷而设计的。

需求驱动测试的原则

        以上为大家介绍了三个与本文相关的概念，需求，需求管理和测试，下面我们将这三点关联到一起，通过三者之间的联系进一步阐述本文的观点。测试有一些应该被重视的原则。它们从更高的层面上表示最佳实践（关于需求驱动测试方面）的元素。

尽早计划和执行测试

        撰写需求时就为每个需求计划测试。

        捕获需求的同时考虑测试，可以通过如何量化需求来改进表达需求这种方式。对于每个需求，可以询问如下问题：我们将如何知道此需求是否将被或已被满足？

        注意这个问题既用了未来时态又用了过去时态。早测试（如检查设计）可以检查如下内容：当根据设计构建产品的时候，产品是否满足需求。晚测试可以检查如下内容：需求是否通过构建的内容得到满足。

        上述问题应该导致每个需求的限定 战略。因为有大量的限定活动可用，所以每个需求将导致多个测试（覆盖开发的所有阶段）。例如，根据需求检查设计就是早期限定的一个机会。另外，还有一个或多个系统测试以确保最后构建的内容能真正满足需求。而一组所选的测试可以形成限定的战略。

        问题还可以为每次测试确定限定标准。对于每次测试规范化了什么样的结果可以被看作是成功的。限定标准也是随着需求特性和计划测试的不同而变化的。

        在开发过程中，要尽早执行测试。

        缺陷本身会从一个阶段传播到另一个阶段，所谓“小洞不补，大洞吃苦”。而修正它们的成本将随着开发流程的推进呈几何倍数增长。鉴于此，通过尽早识别和修正缺陷可以尽量减少开发成本和项目日程，从而最大程度的减少后续阶段高成本的返工工作。
因此，每个需求的限定计划应该考虑可能发现缺陷的最早方法，比如评审、检查和概览。

将测试关联到需求

        跟踪测试至需要检查的需求。

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

通过跟踪，可以执行如下两种分析：

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

 • 影响分析 用于在需求发生变更的时候决定需要修改的限定活动。在接受需求变更之前，将考虑重新定义和重新执行相关限定活动的成本。同理，在测试失败之后，可以从需求的角度查看失败的影响。

        我们通过分析达标 和限定 的关系就可以确定潜在的返工工作。例如，如果组件测试失败，则受影响的不仅仅是组件的相关需求（通过限定 关系），还影响那些组件需求应该要满足的子系统需求（通过达标 关系），还将影响系统和客户需求。
        仅仅通过测试子系统的组件是无法达到全面测试子系统的需求的；这与需求管理中涌现性质 的概念是一致的：系统不只是各个部件的总和，有些行为是需要组件之间进行交互才能出现。因此在每一层都执行测试是很有必要的。