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

我也可以有自己的要求并进行测试吗?

由Sammy Wahab撰写

詹姆斯·马丁(James Martin)的一项研究, 信息系统宣言 (ISBN 0134647696)得出结论,所有错误的56%是在需求阶段引入的,并且主要归因于书写不佳,模棱两可,不清楚或遗漏的需求 基于需求的测试(RBT)通过验证需求以消除任何歧义或找出差距来解决此问题。本质上,根据这种方法,您可以在开始任何设计或实现之前启动测试用例开发。

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

需求作者以及在某些情况下最终用户对测试用例的审查,确保您不仅在构建正确的系统(验证),而且还在构建正确的系统(验证)。 随着开发过程沿着软件开发生命周期发展,测试活动将集成到设计阶段。由于测试用例在因果关系上满足了需求,因此可以用来验证设计及其满足需求的能力。这意味着对需求,设计或测试用例的任何更改都必须仔细集成到软件生命周期中。

那么,对于您自己的软件开发生命周期或总体方法而言,这意味着什么?这是否意味着您必须放弃软件开发生命周期(SDLC)流程并采用RBT?答案是不!。 RBT不是SDLC方法论,而仅仅是可以嵌入任何方法论的最佳实践。无论是将需求捕获为用例(例如在Unified Process中)还是将场景/用户故事捕获(在敏捷开发模型中),将需求与测试进行早期集成的做法都有助于创建清晰,明确且可测试的需求工件。这不仅使测试组织受益,而且使整个项目团队受益。但是,在基于瀑布的正式方法或从瀑布派生的方法中,RBT的实现要干净得多,而在诸如敏捷或基于迭代的模型之类的非正规方法中,RBT可能更具挑战性。即使在最极端的敏捷方法(例如XP)中,也要求以“客户”或“客户的声音”形式与开发人员并肩坐下来,对需求进行持续验证。

为了说明这一点,让我们以一种迭代开发方法为例,在该方法中,对需求进行了切片并确定了优先级,以便在多个迭代中实施。高风险需求(例如非功能需求或体系结构需求)通常在初始迭代中确定。 迭代就像整个软件开发项目中的子项目。为了获得经过验证的测试用例,由需求作者,领域专家和测试人员组成的团队将通过以下三组活动进行循环。

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

任何反馈或更改都会迅速纳入,并且要求会得到纠正。遵循此过程,直到所有需求和测试用例都得到充分验证。

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

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


萨米·瓦哈卜(Sammy Wahab) 是MKS Inc.的ALM和流程顾问。该服务使用MKS Integrity帮助客户评估,自动化和优化应用程序交付。 Wahab先生曾帮助组织采用SDLC和ITSM流程和方法,以支持CMMI和ITIL等质量框架。他在多个行业活动中介绍了软件过程自动化,包括Microsoft Tech-Ed,Java One,PMI,CA-World,SPIN,CIPS,SSTC(DoD)。从软件开发人员到首席技术官,Wahab先生已经在技术,咨询和管理领域任职20多年,曾在Tenrox,Osellus,American Express,Parsons,Isopia Compro和Iciniti等公司任职。 Wahab先生拥有西安大略大学的工商管理硕士学位。

©BA Times.com 2020

麦格雷戈徽标白色网站