2008年12月15日星期一06:37

我可以拥有我的要求并测试它们吗?

由Sammy Wahab撰写

詹姆斯马丁研究, 信息系统宣言 (ISBN 0134647696)得出的结论是,在要求阶段引入了56%的所有误差,主要归因于书面差,暧昧,不明确或错过的要求 基于需求的测试(RBT)通过验证要求来清除任何歧义或识别空白来解决此问题。基本上,在这种方法下,您在任何设计或实现开始之前启动测试案例开发。

基于要求的测试不是软件工程中的新概念 - 事实上,您可能会将其作为要求驱动测试或完全某些其他术语 - 并且已经在几种软件工程方法和质量管理框架中灌输。 在其基本形式中,它意味着在从需求和设计阶段开始在生命周期开始测试活动,然后通过实现一直集成它们。将业务用户,域专家,要求作者和测试人员组合的过程;并获得验证要求的承诺为所有开发活动构成了基线。 

通过要求作者审查测试用例,并且在某些情况下,通过最终用户确保您不仅构建合适的系统(验证),而且还要构建系统权利(验证)。 随着开发过程沿软件开发生命周期移动,测试活动然后集成在设计阶段。由于测试用例在原因和效果方面重述了要求,因此可用于验证设计及其能力以满足要求。这意味着必须在软件生命周期中仔细集成要求,设计或测试用例的任何变化。

那么这在你自己的软件开发生命周期或总体方法方面是什么意思?这是否意味着您必须抛出软件开发生命周期(SDLC)流程并采用RBT?答案是不!。 RBT不是SDLC方法,而只是一种可以嵌入任何方法的最佳实践。如果要求是用作用例,如统一进程,或场景/用户故事中,如在敏捷开发模型中,在提前测试要求的实践有助于创建清晰,明确和可测试的要求工件。这不仅使测试组织效益,而且是整个项目团队。然而,RBT的实施是基于正式的瀑布或瀑布派生方法的更清洁,并且在较少的正式瀑布中可以更具挑战,如敏捷或基于迭代的模型。即使在最极端的敏捷方法,例如XP,持续验证的要求是以“客户”或客户的语音与开发人员并排的形式授权。

为了说明这一点,让我们采取迭代开发方法的情况,其中要求并在多次迭代中实现实施。高风险要求,如非功能性或架构要求,通常在初始迭代中。 迭代就像一个完整的软件开发项目的上下文中的子项目。为了获得验证的测试用例,通过以下三组活动组成的团队组成的要求作者,领域专家和测试人员周期。

  • 验证业务目标,执行歧义分析。要求 - 测试用例映射。
  • 定义和正式化要求和测试用例。
  • 要求作者和领域专家对测试用例进行审查。
 canihave1.png.
 

任何反馈或更改都会快速合并,并纠正要求。遵循此过程,直到所有要求和测试用例都完全验证。

简单地将核心RBT原理纳入您的方法并不意味着在需求阶段将引入更少的错误。在开发过程中,它将做的是捕获更多的错误。您必须通过确保构建集成和版本控制的要求和测试管理存储库来补充任何RBT练习。您还必须具有检测,自动化和报告对高度相互依存的工程工件的改进功能的功能。 这意味着适当的配置和更改管理实践,以促进在团队中及时分享此信息。例如,如果设计更改,必须向要求作者和测试团队通知此更改的影响,以便更改并重新验证适当的工件。

RBT的自动化关键方面还为挖掘代码和需求覆盖范围提供了挖掘度量的基础,并且可以成为您要求质量和测试用例的领先指标。 RBT的真正福利需要一定程度的组织成熟和自动化。业务效益增加了软件质量和可预测的项目交付时间表。 因此,通过将测试与您的需求和设计活动集成,可以降低整体开发时间,大大降低项目风险。


Sammy Wahab. 是MKS Inc.的ALM和流程顾问帮助客户使用MKS完整性评估,自动化和优化应用程序交付。 Wahab先生帮助组织SDLC和ITSM流程和方法支持质量框架,如CMMI和ITIL。他在包括Microsoft Tech-ed,Java One,PMI,CA-World,STC,CIPS,SSTC(DOD)的几个行业事件中介绍了软件过程自动化。 Wahab先生从软件开发人员到首席技术官的技术,咨询和管理角色都花了超过20年的公司,其中包括Tenrox,Osellus,American Express,Parsons,Isopia Compo和Iciniti等公司。 Wahab先生举办了来自西部安大略大学的工商管理硕士学位。

©ba time.com 2021

MacGregor Logo White Web