您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 测试用例 > 正文

验收标准不是测试用例

发表于:2022-05-10 作者:Thoughtworks洞见 来源:Thoughtworks洞见

作者 | 于晓南

敏捷质量实践中提倡测试左移,测试人员要尽早介入需求阶段,越早越好。测试人员需要关注需求的有效性,以及在需求产生和传递的过程中,交付价值是否被准确的描述、理解和对齐。在这个过程中很容易遇到一个常见问题:验收标准是验收测试要测的吗?验收标准到底是不是测试用例?这两者之间有什么区别和联系?本文主要想解决的就是这个具体的困惑。

验收标准是确保需求实现的最小集合

验收标准是什么

回顾一下需求由厚厚的《软件需求规格说明书》演化为一张用户故事卡片的过程,在这个过程中我们舍弃了大量的细节描述,突出了需求需要交付的客户/用户价值。在需求交付的过程中,我们会一直关注价值,在保证价值的前提下,实现方式和技术细节都是可以讨论的。

那么问题来了,既然很多内容都是可以讨论的,我们怎样确定一个用户故事被实现完成了呢?验收标准就是用户故事实现完成的试金石。可以这样说,一个用户故事能否被标记为开发完成并进入测试阶段,很大程度上取决于验收标准是否全部通过。

通常来说,验收标准就是一系列可以接受的条件或者业务规则,且与功能或特性相互匹配和满足,同时也能被产品负责人和相关干系人接受。

敏捷实践中,推荐使用行为驱动开发(Behavior-driven development,缩写BDD)的方式来写验收标准,即使用GWT格式。

  • Given (在什么样的情景或条件下)
  • When (采取了什么行动)
  • Then (得到什么结果)

举个例子:

  • Given (假设) 我在搜索界面
  • When (当) 我填写入住城市,选择住宿时间
  • Then (于是) 我可以浏览该城市和该时间段内空闲酒店的名字和价格

在编写验收标准时,应重点关注可以验证需求实现的用户场景上,更多的是正向验证用户需求实现完成,切忌将验收标准写成测试点。

验收标准在什么时候用

(1) 故事启动(Story Kickoff)

在故事启动时,需求涉及的全部角色:需求分析师、开发、测试、体验设计师,大家需要坐在一起进行需求澄清,确保所有人对需求的理解一致,并约定好故事验收时的验收标准都有哪些。在这个过程中,任何人都可以针对验收标准进行提问,或者补充更多的验收场景。

(2) 故事验收(Desk Check)

当开发人员完成代码实现后,做一些基本的自测工作,并准备好验收场景和数据,就可以约大家进行故事验收了。验收时,也需要需求设计的全部角色,大家坐在一起,听开发讲解实现细节,并逐一演示验收场景。如果验收标准全部验证通过,大家也没有其他问题,这个用户故事就可以被标记为开发完成,准备进入测试阶段了。

(3) 用户验收测试(User Acceptance Test)

除了研发团队的测试外,迭代的交付还需要一定的用户验收测试。用户验收测试的设计和执行者有时是PO、或是提出需求的客户及相关干系人,有时是小范围内测或公测的真实用户。在用户验收测试时,执行者也会在一定程度上参考验收标准,检验验收标准是否完备,是否都能满足用户预期的验证通过。

验收标准不是验收测试

从上文的讨论中,可以得出结论:验收标准是定义用户故事完成的标准。而验收测试分为两部分,一部分发生在用户故事开发完成后,是研发团队内部的验收,另一部分是在测试完成后上线前,由客户或真实用户进行验收。由此可见,验收标准并不等于验收测试,验收标准是验收的最小集,而验收测试的范围要更广。

测试用例验证了软件功能的有效性

测试用例是什么

测试用例是指为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。简单来说,测试用例就是用文字来描述以怎样的步骤测试一个测试点,以及期望的测试结果是什么。

测试用例通常会包括:描述、优先级、前提条件、执行步骤、期望结果、实际结果和备注等信息。根据项目各自的特点,测试用例包含的信息不尽相同。

测试用例在什么时候使用

(1) 用例设计和评审

在测试设计阶段,测试人员根据需求,采用多种设计思路来编写测试用例,并提交至测试组或项目组进行用例评审。此时,测试用例承载了业务需求的测试点,以及测试人员基于专业经验识别出的非业务需求类的验证点。

(2) 测试执行

在测试执行阶段,测试人员(有时也是用例编写者)按照用例的详细描述执行测试用例,并根据实际执行结果与预期结果是否一致,来判定该测试用例是否通过测试。不通过的用例需要分析原因,报缺陷或以其他方式进行跟进。

(3) 回归测试

开发对用例相关的功能进行改进,或者修复了相关缺陷,就需要对指定用例进行回归,确保功能没有被改坏,或者缺陷确实被修复了。另外,有时在重大上线前,也需要按优先级选取一定量的测试用例来进行回归测试,以确定主线业务流程功能正常。

(4) 沟通测试点

测试用例还有个很重要的作用,记录具体的实现细节以及框定需求的测试范围。多个迭代过去,大家在需要翻看历史需求时,可能故事卡不足以还原全部的实现细节,测试用例集在这个时候就能够完整的告诉大家:软件是怎么实现的,当执行某些操作时,程序有什么表现,以及当时这个需求的测试范围是什么。尤其在团队成员上下文不足时,良好设计并编写的用例集可以完美补齐这些知识。

验收标准不是测试用例

以上我们讨论了验收标准和测试用例分别是什么,以及在什么阶段使用。容易得出,验收标准与测试用例是完全不同的两件事,两者的相同点在于它们都是可判定的用户使用场景,可以根据预期来判断是否通过,而两者的区别体现在下表中的各个维度上。

本文我们还讨论了验收标准不是验收测试。仅从覆盖范围来看,验收标准、验收测试、测试用例的关系可以参考下图:

  • 测试用例:覆盖范围最大,应该是确保软件功能正常、满足用户预期的测试全集
  • 验收测试:覆盖范围比测试用例小,只覆盖验收需要的测试用例
  • 验收标准:覆盖范围比验收测试小,只覆盖验证需求实现完成的测试用例

当然,验收标准和测试用例除了使用时机外,两者的区别也体现在不同的责任人和使用范围。验收标准的责任人是需求分析师,在团队协作过程中使用,是多角色合作的基础;而测试用例的责任人是测试人员,属于测试专业上下文的内容。但在不同的组织结构下,对角色的定义会存在一定模糊的界限,因此,“全团队为需求的验收和质量负责”是比较推荐的理念。

相信经过本文的澄清,我们已经搞懂了验收标准和测试用例到底是怎么回事。随着行业的发展,为了测试左移,将有越来越多的测试人员需要懂需求;相应的,为了高效产出高质量的需求,也有越来越多的需求分析人员需要懂测试。需求分析人员与测试人员一起打造高质量的需求,将为交付高质量高价值的软件奠定坚实的基础。