敏捷软件开发中用户故事与验收测试的现状研究

马秀颖

(北方工业大学,北京 100144)

0 引言

敏捷开发是一种非常流行的软件开发和管理方法。它的特性之一是在项目分析阶段使用用户故事来表达需求。用户故事的广泛使用使得它们变得越来越重要,而判断它们是否被实现和满足尤其重要。验收测试用于解决这个问题。本项研究工作从用户故事和验收准则两方面讨论了最新的研究工作方法,希望为相关研究者提供参考。

1 相关概念

1.1 用户故事

在敏捷开发中,用户故事(user story)是软件系统最终用户用来描述系统所做或需要做的工作的若干句描述。它是软件需求的传统方法——软件需求说明书或用例等的一种轻量级,更灵活的替代品。实际上,可以说用户故事是敏捷开发最重要的工件。Cohn 认为用户故事包括三个部分:(1)简短的书面描述;(2)关于故事的对话,以详细说明故事;(3)用于验收测试的验收准则。用户故事的书面描述遵循一个简单的模板:As a ,I want so that 。其中,Role是与系统交互的真实用户,Function是系统的行为或操作。Benefit是所取得的结果,它一般用来表述非功能性的或系统外部的作用。

1.2 用户故事验收测试

验收测试是极限编程的核心实践之一,对于验收测试到底是什么有很多不同的解释。R.Owen Rogers等人[1]对它做了简单的定义:验收测试是客户定义的,用来验证一个故事是否完整和正确的测试。为了强调客户在定义这些测试中的中心作用,验收测试也称为用户测试(Customer Tests)。因此,验收测试是验证系统功能是否符合客户期望的关键机制。

2 用户故事研究现状

尽管用户故事已经是一种半结构化的自然语言,但它仍不能完全摆脱自然语言的模糊性等特点,再加上用户对需求表达的非专业性、需求采集的多样性等,使得基于用户故事的敏捷需求实践充满了挑战。等人[2]在2015年的综述中,基于用户故事的敏捷需求实践将用户故事的关注点总结为用户故事收集,角色建模,验收测试,评估、发布计划和迭代开发,追踪和交互,并对用户故事管理工具做了详细分类和总结。我们在他们工作的基础上进行了相关研究工作的补充。为了方便展示,我们制作了表1。表1描述了近几年的主要研究工作。

表1 主要研究工作Tab.1 Main Research

3 户故事验收测试

用户故事验收测试是一个将验收测试与领域用户故事相结合的过程,简单来说可以包括验收测试的表达、测试用例的生成和验收测试的执行。

3.1 验收测试表示

用户故事的验收测试需要依据验收标准进行展开。在验收测试中有两种常见的表示形式。第一种为文本场景表示法(Gherkin Language),他运用了Gherkin语法,使用该格式可以很好的与Cucumber这一BDD(Behavior-Driven Development)的自动化测试框架进行衔接。Duc-Man Nguyen等人[3]就在其工作中使用了这种表示。第二种为前面提到的checklist表示法,多用于书面笔记。此外,还有一种表格表示法(Fit tables),该表示依托于fit家族得到了广泛使用。Ernani Cé sar dos Santos等人比较了表格表示法和文本场景表示法,结果表明没有足够的证据来确认一种技术更容易指定测试场景或者更好地沟通软件需求。在此之前,Melnik 等人进行了一个实验,表明非技术用户与软件工程师一起工作时,可以使用验收测试场景作为沟通和验证软件业务需求的一种方式。实验指出,非技术用户可以使用Fit表清楚地指定软件需求,但它指出用户在学习如何使用这种符号指定测试场景时有困难。此外,这项研究表明,一些非技术用户不允许使用Fit表作为指定需求的工件。

3.2 测试用例生成

传统的用户故事验收测试是全手工的,而为功能需求手工编写测试用例是一项耗时的任务。这样的测试用例不仅难以编写,而且维护起来也很有挑战性。此外,手工测试用例生成效率低下,并且容易出错,于是众多学者围绕自动化验收测试展开研究。自动生成测试用例需要对用户故事和验收准则有较好的解析能力,然而用户故事和验收准则均为自然语言,因此要想较好的支持自动解析需要对他们进行较为细致的约束。

Mahawish Massod 等人定义了受限制的用户故事模板,模板中的验收准则由前置条件和满足条件(Conditions of Satisfaction)组成。满足条件由执行路径和后置条件组成。执行路径的表达受自然语言限制规则的约束,并使用规定的关键字。他们给出了常用的数据类型以及相关属性的选择,通过这些约束生成测试用例。他们的方法对用户友好且对Selenium IDE有很好的支持。Duc-Man Nguyen等人也对用户故事及验收准则的表达进行了规范。验收准则的书写格式是采用了When I Xan dY,I will check for Z as a result.他们将其按照预定义的myDSL 模板进行二次书写以将其转换为Z3 SMT格式,然后使用求解器进行求解生成测试用例。该方法还支持添加启发式规则,这一方面有利于检查和优化测试用例输出,另一方面也弥补了Z3 对字符串处理的缺陷。

为了适应通用的敏捷过程模型,Pallavi Pandit等人[4]提出了一个UAT过程模型,它旨在基于验收标准,用自然语言生成详尽的测试用例。模型分为三部分,分别是迭代前规划、迭代中和迭代结果。在迭代前的规划阶段输入用户故事和验收准则,对于验收准则的表示,他们采用了Given [input |preconditions]When [actions | triggers]Then [output | consequences]格式。在迭代过程中,首先使用MoSCoW(Must,Should,Could and Would)对用户故事进行优先级排序。其次提取用户故事元素以便生成测试用例图,测试用例图就像是用户验收测试(UAT)的基础。最后将验收准则转换为验收测试(积极的、消极的和非功能性的)。在迭代结果阶段可以查看报告、追溯性和缺陷日志。针对该过程模型,他们开发了AgileUAT、工具以百分比值表示是否满足验收标准,并通过使用DOM树说明了史诗、用户故事、验收标准和验收测试用例之间的可追溯性。

3.3 验收测试执行

验收测试执行的方法和工具有很多。Fit是用于指定和执行验收测试的最成熟的技术框架。使用这个框架,验收测试以表格的形式编写,称为Fit表。Fit表除了用于表示测试场景外,它们还用于报告测试的结果。由程序员制作的用于执行业务逻辑表的fixture将表内容映射到软件系统中。测试结果以三种不同颜色显示测试的不同状态:绿色表示测试通过;黄色表示无法执行的测试,红色表示测试失败。表的第一列和第二列表示输入,而第三列(名称后面跟着括号)表示预期输出。当测试失败时,预期的和实际的输出值将显示给用户。

Agile Planner with Fit对Fit-table做了改进。Agile Planner with Fit的实现依赖于两个插件:Agile Planner和Fitclipse。Agile Planner是一种基于卡片的规划工具。Fitclipse是一个扩展Fit和FitLibrary的Eclipse插件,允许用户在Eclipse IDE环境中执行项目计划,并将项目计划保持在与代码相同的位置。除了Fit和FitLibrary附带的功能之外,Fitclipse还可以跟踪测试结果的历史,支持多模态测试执行,并添加验收测试重构功能。FitLibrary是Fit中fixture的扩展集。除了Fit提供的测试样式之外,它还支持测试网格和图像。FitNesse是一个Wiki前端测试工具,支持创建和编辑验收测试的团队协作。FitNesse使用Fit框架通过web浏览器运行验收测试。它还集成了用于编写和运行验收测试的FitLibrary。还有一些其他的Eclipse插件也使用Fit或FitNesse,包括FitRunner、conFIT和AutAT。FitRunner为Eclipse提供了一个Fit启动配置,使人们能够运行自动化验收测试。ConFIT使用一个FitNesse服务器来执行验收测试,该服务器可以本地运行,也可以远程运行。AutAT 允许非技术用户使用用户友好的图形化编辑器编写和执行web应用程序的自动化验收测试。Haugset等人对常用验收测试工具做了总结,比较了Fit、FitNesse和Selenium。其中Fit及其衍生物通常直接与业务层集成,而Selenium则与用户界面层集成。

4 结论与展望

本文描述了与用户故事和验收测试相关的实践现状并提出了可能的未来研究趋势。随着敏捷方法的广泛使用,用户故事和验收测试的重要性也在增加,通过研究现状我们发现了以下研究趋势:

(1)借助自然语言处理技术提取用户故事信息、进行聚类分组与降重、重用。

(2)借助自然语言处理,挖掘用户故事间的关系,包括从属关系、交互关系等。借助关系的挖掘,进行模型转换、迭代管理。

(3)借助机器学习技术,研究模型自动生成与转换,自动进行验收测试与生成验收测试用例。

(4)相信随着机器学习和自然语言处理的发展,用户故事的应用与管理将会取得长足进步。