敏捷测试价值观、方法和实践读书笔记（4）

第4 章 敏捷测试执行

1 敏捷中的测试需求

为什么会使用用户故事

传统软件开发方法论的假设是基于“用户认知不会发生变化”和“软件系统设计人员能够正确理解”这两个假设建立的

敏捷软件开发的核心思想就是使用较短的时间交付一个有价值的 (Valuable)工作中(Working)的软件，基于已经构建的客观基础进行增量开发。

1. 人类自身就是由用户故事驱动的动物：牛顿被苹果砸到头 VS 万有引力
2. 传统的文档本身就是一种结构化的指述，这和描述缺乏实践序列的因果关系，不能使开发人员产生代入感，也不便于于记忆。

• As········(作为一名用户/客户)
• I want to·········(我想要达到的目标是什么)
• so that········(以及达成目标的原因)
• 作为一名银行用户
• 我需要拥有一个账户
• 以便我可以存钱、取钱，并且显示当前余额

用户故事的INVEST 原则

1.Independent (独立的)

1. 用户故事粒度太细
2. 依赖用户故事错序
3. 团队成员太多
4. 迭代长度太长

2.Negotiable (可协商的)

简短描述，可以有描述，但是不能有过多的注释

DDD：(Deadline Driven Development，截止时间驱动开发)

质量、时间和范围 三角形

3.Valuable (有价值的)

1. 用户迫切想要解决的问题，这是一个以时间为参数的函数
2. 可以根据价值大小和紧急程度进行排序（风险驱动）

4.Estimable (可估计的)

• 完成的定义 (Definition of Done，DOD)
• 验收标准(AcceptanceCriteria，AC)

(1)在团队刚成立或接收了新需求的时候，可采用T恤的型号作为衡量单位

• XS:一天之内可以完成
• S:一天可以完成
• M:一周可以完成
• L: 两周可以完成
• XL: 超过两周可以完成

(2)可以根据更加细节的内容进行精细化估计

斐波那契数列来表示，用数字代表人天:0.5,1,2,3,5,8,13.··

(3)如果团队比较成熟，估计会比较稳定，人日, man-hour

5.Small (小的)

6.Testable (可测试的)

将验收标准转化为验收测试

• 验收标准是用户的语言
• 验收测试是开发团队的语言

1. 业务代表未必是最终负责验收的人。这往往会导致信息失真
2. 让验收人参与用户故事讨论
3. 促使提出人和验收人之间达成验收一致。如果他们之间存在矛盾，那么开发团队不承担责任
4. 若验收标准变更，则重新开始。

用户故事不是一个新的需求，而是开发人员和用户讨论需求的一种沟通工具

2 测试视角下的用户故事生命周期

用户故事生命周期测试的关注点

2 种状态:

• 当用户故事还在产品待办列表中时
• 当用户故事被放到一个 Sprint 待办列表中时
  • 已定义: 是指该用户故事被确定在本次 Sprint 中开发
  • 处理中:是指该用户故事被开发和测试的过程
  • 已完成:是指该用户故事已经被开发和测试完成
  • 已接受:是指该用户经过产品负责人和利益干系人的验收

基于用户故事生命周期的测试关注点

用户故事相关术语比较

1） AC(Acceptance Criteria，验收标准用户故事验收测试和用户验收测试的区别

真正在做验收测试的测试用例数量比验收标准要多得多，因为还需要设计很多异常测试用例，而这些是产品负责人不知道的

用户验收测试是内部测试通过后，在最终用户或最终用户代表验收前进行的测试，它是从最终用户的角度进行的测试，验证产品是否满足用户的真正需要。

2）DOR 和 DOD 的区别

DOR (Definitionof Ready,准备就绪的定义):应该确保产品待办列表顶端的用户故事已准备就绪，可以随时放入 Sprint 中让开发团队进行任务拆分和研发

检查表：

• 是否有足够的细节？
• 是否识别出依赖关系？
• 验收标准是否清晰可测试？
• 性能标准(如果有) 是否已定义且可测试？

DOD(Definition of Done 完成的定义)

• 版本发布(Release)的DOD
• Sprint 迭代的 DOD
• 针对用户故事的 DOD

3）DOD 和AC 的区别

DOD主要针对我们在 Sprint 期间正在开发的产品增量。

AC(Acceptance Criteria，验收标准)，AC 是对 DOD的补充。多个DOD后定义AC。

3 敏捷测试计划

敏捷测试计划策略

传统测试方法会在项目前期就开始制订非常细致的测试计划、把测试中的各种因素都考虑进去

敏捷测试根据产品待办列表的粗粒度需求(如史诗、特性等）定成粗粒度的概要测试计划，不做详细计划

敏捷测试计划过程

传统测试计划是一次性的计划（Plan），敏捷测试计划是一个过程（Planning）

敏捷中的测试任务

测试任务管理与跟踪

某用户故事:

• 第一个是开发功能的任务-->开发人员
• 第二个是编写此用户故事的验收测试用例->Sprint 内测试工程师
• 第三个是开发自动化测试验收脚本的任务->测试开发工程师
• DOD:这个用户故事下面所有的任务是否都已完成。不能只以开发完成为

1. 标准
2. 可见性:看板
3. 可跟踪性:JIRA

通过看板可视化任务

Kanban: 20世纪 40 年代初由大野耐一为日本的丰田汽车公司开发的。2004 年，DavidJ.Anderson 第一个将其应用于 IT 软件开发

看板的核心要素始终植根于以下 4 个原则。

1. 可视化
2. 限制在制品：“Stop Starting”和“Start Finishing”
3. 管理“流”
4. 持续改进

看板3列:

1. To DO :这一栏列出了尚未开发的任务
2. Doing : 送一栏列出了正在进行的任务
3. Done : 这一栏列出了已完成的任务

4 某大型客户的测试活动日历

1. Sprint 的起始时间。最后一天不在周末，防止最后一天发布出现问题，周末没人维护。
2. 产品负责人在第一周结束时和团队有一个接触点。及时纠偏
3. 在第二周周中会进行下一次 Sprint 的用户故事梳理活动，确保在下一个 Sprint 计划到来时，用户故事已经变得比较具体详细，以及已满足 DOR 的条件。
4. 在整次 Sprint 中，测试活动和 DevOps 活动是紧密联系的。

5 敏捷中的测试度量

1. 度量团队目标而不是度量个人绩效
2. 看全局性的指标组合，而不是单个指标

参考指标

(1)代码覆盖率

Martin Fowler 等众多专家都认为追求 100%的代码覆盖率是没有意义的，一般能够达到 80%以上就已经很好了。

(2)验收测试通过率

总体质量 = 缺陷数/当次版本用户故事点的总数×100%

(3)每用户故事点缺陷率

通过自动化测试来验收的用户故事数/总用户故事数×100%