1、随着中国软件市场的不断发展和成熟,软件市场的竞争越来越激烈,客户对软件产品质量的要求也逐步提高。目前各个企业所面临的挑战主要是体现在:满足客户持续升高的期望、缩短产品上市时间和提高产品/系统/ 软件的质量。质量永远是检验一个产品是否合格的参照物,而测试又是检验一个产品质量的重要环节。一个合格的软件产品,后期在测试它的质量时所耗费的精力、时间与开发它相差无几。因此,做好测试工作也是提升一个企业竞争力的重要因素。 本文概述了需求驱动测试的优点;需求驱动测试组合了需求管理和测试管理在流程方面的最佳实践。还将查看用于指导集成流程的原则,并简介经典的 V 模型的演进版 W 模型。首先给大家阐述几个相关的
2、概念: 什么是需求管理? 需求是必须通过产品或流程满足的声明。 需求多种多样,而且用于描述需求的词语也非常丰富。例如,下列词语都可看作需求:目标、志向、条件、合同、限制、终点、要求、需要、目的、责任、规定、必要条件、规则、规格和指标。选用词语“需求 ”作为所有这些概念的同义词,并将之用于表示个人声明、条款或条目(而非整个需求文档) 。 需求管理由一套规范和活动组成。是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。 很多人错误地认为仅在项目定义阶段才开展需求管理。事实上,需求以一种形式或另一种形式存在于开发的各个阶段。尤其在测试的各个阶段(甚至开发的最后阶段) ,需求起着至关重要的作用
3、 需求管理中的三个关键规范与本文关系非常密切: 如何表述需求。需求不仅应该精简和明确,而且还应该具有可测试性。通常意在确保可以适当量化需求和明确识别测试标准。这些测试标准提供测试阶段使用的必要信息。 如何分类需求。所有需求天生并非平等。有些需求远重要于其它需求。为有效管理开发,必须以最适合应用程序的方式分类每个需求声明,这样在分配资源的时候可以制定工程和管理方面的决策。 如何跟踪需求。创建跟踪是需求管理的重要组成部分。通过沿着开发阶段的正方向和逆方向跟踪需求、向前和向后跟踪测试至相关需求的功能,能够以各种方式报告项目进度和分析变更影响。什么是测试? 测试是任何以发现缺陷为目的的活动。 这是测试
4、的故意宽泛定义。它覆盖各种早期活动(如评审需求、检查设计、概览结构和从建模进行分析)和传统的单元测试、系统测试和验收测试阶段。 就很多人而言,这个定义太宽泛,因为它偏离测试的传统定位(肯定位于 V 模型的右侧) 。但是该定义承认:在真正构建和编码之前,可以“测试” (评审、核实、验证、限定和评估)需求和设计本身。 为符合该定义的宽度,我们选用词语“限定 ”来涵盖测试、核实、验证和评估。因此“测试标准”变为“限定标准” , “测试计划”变为“限定计划” 。 缺陷是任何偏离需求的事项。 理想状态下,通过参考需求即可识别缺陷。有些需求直接针对产品(源于客户) ,而有些需求则针对开发流程(标准和程序)
5、 。后者将封装最佳实践,而最佳实践又是专门为减少引入和传播缺陷而设计的。 需求驱动测试的原则 以上为大家介绍了三个与本文相关的概念,需求,需求管理和测试,下面我们将这三点关联到一起,通过三者之间的联系进一步阐述本文的观点。测试有一些应该被重视的原则。它们从更高的层面上表示最佳实践(关于需求驱动测试方面)的元素。 尽早计划和执行测试 撰写需求时就为每个需求计划测试。 捕获需求的同时考虑测试,可以通过如何量化需求来改进表达需求这种方式。对于每个需求,可以询问如下问题:我们将如何知道此需求是否将被或已被满足? 注意这个问题既用了未来时态又用了过去时态。早测试(如检查设计)可以检查如下内容:当根据设计
6、构建产品的时候,产品是否满足需求。晚测试可以检查如下内容:需求是否通过构建的内容得到满足。 上述问题应该导致每个需求的限定 战略。因为有大量的限定活动可用,所以每个需求将导致多个测试(覆盖开发的所有阶段) 。例如,根据需求检查设计就是早期限定的一个机会。另外,还有一个或多个系统测试以确保最后构建的内容能真正满足需求。而一组所选的测试可以形成限定的战略。 问题还可以为每次测试确定限定标准。对于每次测试规范化了什么样的结果可以被看作是成功的。限定标准也是随着需求特性和计划测试的不同而变化的。 在开发过程中,要尽早执行测试。 缺陷本身会从一个阶段传播到另一个阶段,所谓“小洞不补,大洞吃苦” 。而修正
7、它们的成本将随着开发流程的推进呈几何倍数增长。鉴于此,通过尽早识别和修正缺陷可以尽量减少开发成本和项目日程,从而最大程度的减少后续阶段高成本的返工工作。 因此,每个需求的限定计划应该考虑可能发现缺陷的最早方法,比如评审、检查和概览。将测试关联到需求 跟踪测试至需要检查的需求。 跟踪是在开发过程中记录工件之间关系的一种方法。跟踪的最通用形式是不同层之间的需求达标 关系。但是捕获需求和测试(显示需求已被满足)之间的限定 关系也很重要。通过跟踪,可以执行如下两种分析: 覆盖率分析 用于确保每个需求至少计划了一个限定活动并最终执行限定活动。它还可以确保每个限定活动都拥有相关需求,从而获得收益。 影响分
8、析 用于在需求发生变更的时候决定需要修改的限定活动。在接受需求变更之前,将考虑重新定义和重新执行相关限定活动的成本。同理,在测试失败之后,可以从需求的角度查看失败的影响。 我们通过分析达标 和限定 的关系就可以确定潜在的返工工作。例如,如果组件测试失败,则受影响的不仅仅是组件的相关需求(通过限定 关系) ,还影响那些组件需求应该要满足的子系统需求(通过达标 关系) ,还将影响系统和客户需求。 仅仅通过测试子系统的组件是无法达到全面测试子系统的需求的;这与需求管理中涌现性质 的概念是一致的:系统不只是各个部件的总和,有些行为是需要组件之间进行交互才能出现。因此在每一层都执行测试是很有必要的。 将
9、缺陷关联到需求 跟踪缺陷至显示尚未被满足的需求。 当测试发现异常行为或测试标准未能实现的时候,缺陷就产生了。以下三种情况可能导致产生缺陷: 测试的定义中含有错误 需求的表达或需求的限定标准中含有错误 产品中含有真正的缺陷 在上述的任何一种情况下,都可以通过跟踪缺陷至显示尚未被满足的需求的方式来识别缺陷。因为缺陷被定义为偏离需求的事项,所以这是一个好的规范。因为每个测试都会被跟踪至多个需求,所以需要分析每个缺陷来确定哪些需求受到了影响。根据需求测量进度 从那些显示已被满足或尚未满足的需求的角度设定测试目标和测量测试进度。 开发过程中,最难决策之一便是测定何时已执行了足够测试。在资源有限的情况下,
10、测试经理需要知道将工作集中到何处才能最有效。当测试从需求隔离出来之后,测试经理无法获得关于系统不同方面的相对重要性的信息,这样就难分配资源和评估失败的影响。 通过在相应的地方提供相应跟踪,可以根据需要,将每个测试的相对重要性和测试的成与败关联到相应层上受影响的需求(客户需求、系统需求等)。可以从需求的角度设定测试(已完成)的目标。测试经理知道将资源应用于何处,并可以生成报告以从需求的角度显示测试的进度。 到这里,我们就不难看出,需求在测试过程中占有着多么重要的地位,通过对需求和测试二者合理的关联,应用,对软件产品的质量,开发的周期以及成本都有着不可估量的价值。下面通过图形对比,介绍一下经典的
11、V 模型的演进版 W 模型。 W 模型 当我们考虑如何最有效地实施这些原则的时候,一种流程和数据模型应运而生,即所谓的 W 模型,它是 V 模型的演进版。经典的 V 模型如图 1 所示,其中圆形方框表示生命周期中的各种活动。(此模型不应解释为“瀑布”模型,因为所有这些活动都可以并行开展,并持续获得反馈。) 图 1:经典的 V 模型图 2 添加了由活动产生的数据(长方形表示)和数据之间的跟踪(粗箭头表示)。此模型将限定计划放置在 V 模型左轴上与需求平行的地方。限定计划是只包含计划的“限定活动”和“限定标准”。在开发的相应阶段开展活动的同时,就会收集活动的实际结果。 跟踪用于记录下列两种关系:
12、不同层需求之间的满足关系 计划的限定活动和需求之间的限定 关系 可以制定由限定计划确定的每个限定活动(评审、检查、单元测试、集成测试等)的执行时间表,以便在开发的相应阶段执行。综合起来,它们为整个项目形成了“限定时间表”。 图 2:含有限定计划的 V 模型因为计划测试的同时,没有足够的信息用于设计测试的精确细节。所以图 3 将各个层上的测试设计作为单独活动进行显示。这些活动被放置在与开发轴相平行的轴上。根据它的基本形状,我们称之为 W 模型。 测试设计使用限定计划来设计被跟踪至计划的特定测试。可以为每个计划设计多个测试,也可以单个测试覆盖多个计划。 图 3:含有测试设计的 V 模型(或 W 模
13、型)我们现在可以把执行测试所获得的数据添加到模型。我们对测试状态和测试中发现的缺陷比较感兴趣,如图 4 所示。 因为无法规范地将缺陷分配到开发的各个层上,因此所有缺陷都被放置在单个的存储库中。测试的执行活动包括分析缺陷,通过分析缺陷可以确定产品是否存在真正的缺陷以及缺陷涉及哪些需求。通过跟踪缺陷至受影响的需求,来记录该分析的结果,如图 5 所示。图 4:含有测试结果的 W 模型图 5:含有缺陷(跟踪至需求)的 W 模型此方法采纳了上文所述的三个原则: 尽早计划测试。通过在撰写需求的时候编写限定计划,实现在撰写需求的时候考虑测试。 尽早执行测试。将限定计划映射到“限定时间表”可以鼓励考虑尽早限定
14、和测试(可以针对每个需求执行限定和测试)。 测试与缺陷识别,跟踪至需求。通过这种跟踪模型,可以维护和分析这些关系。 注意,要确定个人需求是否被完全实现,则需要同时使用达标关系和限定关系来收集一组完整的测试结果。 最后,测试趋向于具有高可迭代性。执行测试之后发现并修正缺陷,接着在重复测试。图 6 显示的是根据同一标准多次运行测试所得到的结果。通过按序运行测试,可以确定测试结果的发展情况和进度。 图 6:含有多次测试运行的 W 模型Telelogic 需求驱动测试解决方案 Telelogic DOORS 是市场和技术都领先的需求管理解决方案。通过改进需求的沟通和协作,从而提高系统工程和关键业务的
15、IT 项目的质量。 DOORS 通过增加业务目标、客户需求、技术规格和规定的可见性来提高质量。 通过下列各种强大功能(捕获、链接、分析和管理需求变更及其跟踪) ,DOORS 可以确保遵从要求和遵守规定/标准。 DOORS 提供用于管理需求和测试用例的集成环境。通过 DOORS 中的“Test Tracking Toolkit”(测试跟踪工具包) ,企业可以创建从需求至测试的链接,所以您可以: 定义测试用例并将它们链接至原始需求 策划和记录测试运行的结果 比较不同测试运行的结果,以查看发生变更的内容 询问需求以了解需求覆盖率和测试状态 Telelogic Change 是基于 Web 的工作流和
16、变更管理解决方案,不仅简化变更管理流程,还能够使企业以一致的方式跟踪缺陷和错误。通过 Telelogic Change,企业可以有条不紊地响应所有类型的变更。这样将在整个开发生命周期中改进整个企业的沟通和协作,帮助企业积极响应持续不断的变更、提高生产率和缩短上市时间。 结论 本文主要探讨了如何将需求管理和测试集成到需求驱动的测试流程中。 因为测试的原则/关键实践与需求息息相关,所以我们对此重点进行了说明。然后我们对经典的“V”模型进行扩展,在 “V”模型的基础上添加了测试流程和测试信息,使其可以显示各种数据(应该以集成方式进行管理)之间的关系。并将之命名为“W”模型。 当今,在提高个人生产率和
17、实施点解决方案方面,开发产品、系统和软件的企业无法得到满足。为了能够保持住竞争优势,分析师、开发人员和测试人员必须一同帮助企业发挥它的全部潜能。在集成工具的支持下,需求驱动测试为应用程序的生命周期管理 (ALM) 方法的关键部分提供了解决方案,这也必将成为企业在市场竞争中的一项优势。 本 文 节 选 自 Telelogic 公 司 产 品 市 场 总 监 Dominic Tavassoli 先 生的 技 术 文 章 , 有 删 节 。 Dominic Tavassoli 在 国 防 、 汽 车 、 金 融 等 行 业拥 有 多 年 需 求 管 理 、 变 更 管 理 及 应 用 系 统 生 命 周 期 管 理 软 件 解 决 方 案 的经 验 , 是 一 位 资 深 的 行 业 专 家 。