从这一讲开始就进入了第 6 部分的学习“敏捷测试设计与执行”，测试设计指的是测试用例的设计、自动化测试脚本的设计，以及探索式测试中的设计。在敏捷测试里，测试计划仍然是测试设计的基础，测试设计仍然是测试执行的基础。计划和设计都必须在测试的执行中得到贯彻体现，并且几乎总是需要在执行过程中根据上下文不断地调整和完善。因此，测试执行是和计划、设计循环交替进行的。

我先从 DoD 和验收测试开始讲起。

什么是 DoD

理解 DoD（Definition of Done）并没有什么难度，字面意思是任务完成的定义，它通常以清单（Checklist）的形式定义一项任务完成的准则是什么。在敏捷开发里 DoD 最初应用在 Scrum 流程中的 Sprint。就像图 1 所示，是为一个迭代或冲刺任务定义的 DoD，可以称之为 Sprint DoD，或者迭代 DoD。它在一次迭代的计划阶段由团队一起制定。在验收阶段对照着 DoD 清单中的每一项检查完成情况，如果都完成了，这个迭代才可以说是完成。

但就是这样一个简单的任务清单，它在敏捷开发里起到了非常重要的作用，甚至 “没有定义 DoD 或错误的定义 DoD” 被认为是导致敏捷实践失败的最为重要的原因之一。

这也并不奇怪，有一本值得阅读的书《清单革命》，作者是一名外科医生，他收集了大量案例证明了清单工作法在许多行业的价值，特别是在临床医学、航空业和建筑业这些对安全操作要求极高的行业。作者认为，今天人类掌握了越来越多的知识，很多挑战来自如何持续地、正确地运用这些知识，人们总是不可避免地犯错，有些错误是因为我们不懂，没有掌握相关的知识。但更多的错误往往是因为我们明明知道，可是该做的时候却没有做。航空业每一次安全飞行的背后都是清单的胜利。

2009 年全美航空的萨伦伯格机长将飞机成功地迫降在哈得孙河上，背后是整个机组集体创造的奇迹，他们在危急时刻严格执行各自的操作清单，在几分钟内完成了所有该做的事情，挽救了所有人的生命。对于个人也是一样，一名基金管理人花了 65 万美元拍下了与巴菲特共进午餐的机会，事后他说，巴菲特的脑子里有一张清单，他用这张清单对潜在的投资机会进行评估。后来这个人也在投资决策中坚持使用清单，这让他的基金表现优异。

同时作者也说：“清单从来不是大而全的操作手册，而是理性选择后的思维工具。”由此可知 Sprint DoD 的清单并不复杂，但体现了简单却有效的敏捷思维。

DoD 的作用可以概括为以下 3 点。

帮助团队明确目标，提高效率。在计划阶段制定 DoD，可以帮助团队检查是否所有的主要目标都已经考虑到了。《高效能人士的7个习惯》这本书里介绍的第二个习惯就是以终为始，希望达到什么目标，那么一开始就要首先明确目标。

一种促进团队协作的机制。在敏捷团队里每个人的角色不同，承担的任务也不同，很容易造成只关心自己要完成的任务，而整个团队对要完成的任务缺乏统一的认识。如果在团队里有专职的测试，一个典型的情况就是，开发认为一个 Feature Done 就是编码完成，顶多再加上单元测试完成；而对于测试来说，Feature Done 则意味着编码完成加所有测试通过。DoD 能够帮助团队统一对目标和任务的认识，大家都有全局观，因此可以互相支持，共同完成目标。

一种避免犯低级错误的工具。在执行阶段用于提醒团队哪些任务需要执行。在一次迭代开发中，要让 DoD 对每个团队成员来说都能够可见，包括每一项的进度。在验收阶段在按照清单检查一次是否所有的任务都完成了，尽可能地保证在每一次迭代中团队都在持续地做正确的事情。

如何创建 DoD

Sprint DoD 是 DoD 最开始应用的地方，后来又扩展到很多其他的节点，比较典型的是针对每个用户故事、每次迭代，和研发团队要交付出去的一个软件版本制定相应的 DoD。如图 3 所示，是用户故事、Sprint，以及与 Release 之间的关系。

以 Sprint DoD 为例，应该在 Sprint 计划阶段由团队成员一起讨论决定，DoD 的每一项都是可验证的，一经制定，就应该成为团队共同承诺要完成的目标。但同时，DoD 需要团队根据具体情况制定合适的清单并且根据变化进行及时的更新。比如，在这一个 Sprint，团队采用了 BDD，就把 BDD 添加到 DoD 中；到了下一个 Sprint，团队目标是加强单元测试，那 DoD 中就需要体现新的、要求更高的代码覆盖率目标。

下面分别是用户故事 DoD、Sprint DoD 以及 Release DoD 的任务清单示例。

1. 用户故事 DoD

用户故事采用 BDD 描述验收标准

通过了用户故事验收测试

新增代码通过了代码静态分析和代码评审

代码都提交到了版本管理系统

单元测试覆盖率达到了 70%

通过了所有的单元测试

通过了功能测试和功能交互测试

产品负责人批准了用户故事通过验收

2. Sprint DoD

Sprint DoD 在所有用户故事通过了其 DoD 的基础上，增加了功能测试、非功能测试、回归测试等测试项以及对缺陷状态的检查：

所有用户故事通过了其 DoD

执行了功能测试和非功能性的测试，需求覆盖率达到了 100%

执行了回归测试

没有未解决的严重缺陷（P1/P2）

3. Release DoD

Release DoD 在所有的 Sprint 通过了 Sprint DoD 的基础上，增加了类生产环境的测试、文档评审，以及对市场、运维人员的培训：

所有 Sprint 通过了 Sprint DoD

通过了在类生产环境上的回归测试

没有未解决的严重缺陷（P1/P2）

产品文档已全部更新并通过了评审

对运维、市场、客服的新功能培训已完成

相关干系人批准了版本的交付

DoD 和敏捷验收测试的关系

每一个用户故事、Sprint、Release 都要通过验收测试才能结束，而验收遵循的原则就是 DoD，DoD 可以看作是对敏捷验收测试提供了验收标准。从 DoD 的清单里可以看出，DoD 和测试的关系非常密切，其中每一项几乎都和测试相关，如静态测试、持续集成、持续测试，以及各种测试活动的结果是 DoD 任务清单中不可缺少的检查项。如果敏捷团队中有专职的测试人员，对市场人员的培训通常也是由测试人员来负责，并且在文档评审中发挥重要的作用。这是因为测试人员最了解业务场景层面的细节。

敏捷中验收测试可以简单理解为用户故事的验收测试。而在建立了上述 3 个层次的 DoD 基础上，敏捷测试流程（如 Scrum）中的验收测试可以理解为：根据 DoD 对用户故事、Sprint 或要发布的版本进行验收。在 Sprint 验收阶段，先是一个个用户故事的验收，再是对整个 Sprint 的可交付软件进行验收。几个 Sprint 形成一个要发布的版本，并对这个要交付出去的软件版本进行一个总的验收。

用户故事的验收侧重各个用户故事的功能和功能交互的测试。在用户故事验收测试的基础上，Sprint 的验收侧重对整个系统端到端的业务测试，包括系统的非功能性测试和全面的回归测试（取决于系统，包括之前讨论的精准测试）。Release 的验收测试是在类生产环境中进行系统的验证，包括基于用户数据的业务测试和性能、兼容性等验证，部署、回滚和备份等专项测试，以及伴随软件从研发团队交付出去的其他交付物（如用户手册等）。这样就可以建立一个系统的验收测试体系。

如何验证 DoD

验证 DoD 在敏捷开发里是一个持续的过程，不仅发生在验收阶段，在开发过程中需要持续跟踪每一项的进度。团队的测试基础设施的建设以及和 CI/CD 环境的集成会为 DoD 的验证提供良好的支持。持续集成和持续交付让许多结果持续可得并可见，比如单元测试，代码静态分析、代码评审，以及 BDD 自动化验收测试、自动化回归测试等。

我们经常听到有人说一项任务完成了 80% 或 90%，对于 DoD 来说，这种说法是不可取的，只有 DoD 里的每一项都完成了，整个任务才算完成，才可以交付。否则，只差一点儿也是没做完。“行百里者半于九十”说的就是这个道理。 因此，在验收阶段对 DoD 的验证首先要遵循这样的行为准则，团队坐在一起认真的检查每一项内容是否已经完成，才能促使每一个人重视 DoD 的存在。

今天这一讲到这里就结束了，我来总结一下：

DoD 是一个定义任务完成准则的工作清单，可以让团队明确目标，促进协作并减少犯低级错误的几率；

在三个层次创建 DoD，即用户故事 DoD、迭代（Sprint）DoD、要交付的软件版本（Release）DoD；

DoD 对敏捷验收测试提供了验收标准，而各项敏捷测试活动的结果是 DoD 任务清单极为重要的组成部分；

验证 DoD 是一个持续的过程，并且作为验收标准需得到严格的执行。

最后留一个思考题给你：如果你的团队需要建立一个每日 DoD，用来检查大家日常工作的完成情况，包括代码、测试、缺陷处理等，你认为应该怎么制定？

-– ### 精选评论