第4 章 敏捷测试执行
1 敏捷中的测试需求
为什么会使用用户故事
传统软件开发方法论的假设是基于“用户认知不会发生变化”和“软件系统设计人员能够正确理解”这两个假设建立的。
敏捷软件开发的核心思想就是使用较短的时间交付一个有价值的 (Valuable)工作中(Working)的软件，基于已经构建的客观基础进行增量开发。
- 人类自身就是由用户故事驱动的动物：牛顿被苹果砸到头 VS 万有引力
- 传统的文档本身就是一种结构化的指述，这和描述缺乏实践序列的因果关系，不能使开发人员产生代入感，也不便于于记忆。
- As········(作为一名用户/客户)
- I want to·········(我想要达到的目标是什么)
- so that········(以及达成目标的原因)
- 作为一名银行用户
- 我需要拥有一个账户
- 以便我可以存钱、取钱，并且显示当前余额
用户故事的INVEST 原则
1.Independent (独立的)
- 用户故事粒度太细
- 依赖用户故事错序
- 团队成员太多
- 迭代长度太长
2.Negotiable (可协商的)
简短描述，可以有描述，但是不能有过多的注释
DDD：(Deadline Driven Development，截止时间驱动开发)
质量、时间和范围 三角形
3.Valuable (有价值的)
- 用户迫切想要解决的问题，这是一个以时间为参数的函数
- 可以根据价值大小和紧急程度进行排序（风险驱动）
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 (可测试的)
将验收标准转化为验收测试
- 验收标准是用户的语言
- 验收测试是开发团队的语言
- 业务代表未必是最终负责验收的人。这往往会导致信息失真
- 让验收人参与用户故事讨论
- 促使提出人和验收人之间达成验收一致。如果他们之间存在矛盾，那么开发团队不承担责任
- 若验收标准变更，则重新开始。
用户故事不是一个新的需求，而是开发人员和用户讨论需求的一种沟通工具
2 测试视角下的用户故事生命周期
用户故事生命周期测试的关注点
2 种状态:
- 当用户故事还在产品待办列表中时
- 当用户故事被放到一个 Sprint 待办列表中时
- 已定义: 是指该用户故事被确定在本次 Sprint 中开发
- 处理中:是指该用户故事被开发和测试的过程
- 已完成:是指该用户故事已经被开发和测试完成
- 已接受:是指该用户经过产品负责人和利益干系人的验收
基于用户故事生命周期的测试关注点
用户故事状态 |
测试关注点 |
在产品待办列表中 |
当用户故事正在定义/开发中，或者还没有确定优先级并分配给 Sprint 时:·测试人员需制订验收标准，以及确定如何测试用户故事·测试人员可以向产品负责人或用户询问真实世界的场景示例 |
当用户故事被分配到一个 Sprint 待办列表中时 |
|
已定义 |
当用户故事已经被排序并准备开发时:·测试人员必须确保验收标准适当且完整·测试人员开始设计验收测试·若有需要。则应开始准备测试数据·测试人员应着手开发自动化测试脚本 |
处理中 |
当开发人员已经开始为用户故事编写代码时，测试人员应继续开发测试用例和自动化测试脚本当开发人员已完成单元测试时:·测试人员应开始执行测试(自动和手动)·缺陷根据需要被提出、修复和重新测试 |
已完成 |
当用户故事的验收测试已经完成时:·在产品负责人的许可下，剩余的缺陷已被添加到产品待办列表中·准备好 Sprint 演示和产品负责人、利益干系人的验收工作·回归/发布/集成AT测试工程师应考虑如何将用户故事集成到端到端测试环境中进行集成回归测试 |
已接受 |
当用户故事已被演示且被产品负责人接受时，回归/发布/集成/UAT 测试工程师开始将用户故事的功能合并到端到端回归测试套件中并进行测试 |
用户故事相关术语比较
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:这个用户故事下面所有的任务是否都已完成。不能只以开发完成为
- 标准
- 可见性:看板
- 可跟踪性:JIRA
通过看板可视化任务
Kanban: 20世纪 40 年代初由大野耐一为日本的丰田汽车公司开发的。2004 年，DavidJ.Anderson 第一个将其应用于 IT 软件开发
看板的核心要素始终植根于以下 4 个原则。
- 可视化
- 限制在制品：“Stop Starting”和“Start Finishing”
- 管理“流”
- 持续改进
看板3列:
- To DO :这一栏列出了尚未开发的任务
- Doing : 送一栏列出了正在进行的任务
- Done : 这一栏列出了已完成的任务
4 某大型客户的测试活动日历
- Sprint 的起始时间。最后一天不在周末，防止最后一天发布出现问题，周末没人维护。
- 产品负责人在第一周结束时和团队有一个接触点。及时纠偏
- 在第二周周中会进行下一次 Sprint 的用户故事梳理活动，确保在下一个 Sprint 计划到来时，用户故事已经变得比较具体详细，以及已满足 DOR 的条件。
- 在整次 Sprint 中，测试活动和 DevOps 活动是紧密联系的。
5 敏捷中的测试度量
- 度量团队目标而不是度量个人绩效
- 看全局性的指标组合，而不是单个指标
参考指标
(1)代码覆盖率
Martin Fowler 等众多专家都认为追求 100%的代码覆盖率是没有意义的，一般能够达到 80%以上就已经很好了。
(2)验收测试通过率
总体质量 = 缺陷数/当次版本用户故事点的总数×100%
(3)每用户故事点缺陷率
通过自动化测试来验收的用户故事数/总用户故事数×100%
