究竟什么是敏捷测试-InfoQ

时至今日，还讨论这样一个老话题，是否感觉老调重弹？因为两年前（2010 年底）时任谷歌中国测试经理的段念先生就写了一篇文章《什么是敏捷软件测试》（刊登在 InfoQ 网站上 [1]），就已经谈到这个话题，“敏捷软件测试更多的是一种理念，而非过程”。在 2011 年，我自己也写了一篇文章《敏捷测试的思考和新发展》，刊登在《程序员》杂志上，谈到“在 BDD、ATDD 和 TDD 最根本的、共同的思想基础上，构成一个全新的、更完善的敏捷测试框架”[2]。而更早的时候（2010 年 10 月），写了一篇《敏捷测试的方法和实践》（也刊登在《程序员》杂志上），开始的那一小节就在讨论 “什么是敏捷测试”，简单地说，“敏捷测试就是持续地对软件质量问题进行及时地反馈”[3]。不过，篇幅不多、匆匆而过，说得还不够明朗。如果再往前，早在 2009 年，Lisa Crispin 和 Janet Gergory 就写了一本书《Agile Testing: A practical Guide for testers and Agile Teams》, 国内在 2010 年出了它的中文版本 [4]，在第 1 章就论述了敏捷测试的定义，侧重从测试的敏捷形式和“敏捷测试”的实践等来彰显敏捷测试，对敏捷测试和传统测试的区别进行了分析（虽然作者把传统测试局限于瀑布模型，这显然是不对的），让我们看到一些敏捷测试的特点，如图 1 所示。但作者也承认“敏捷测试对不同的人意味着不同的含义”。

图 1 传统测试与敏捷测试 [4]

这样看来，“敏捷测试（Agile Testing）”就不是一个新概念了，但为什么不少人还是不理解什么敏捷测试呢？现在偶尔还看到一些文章或微博帖子还在讨论什么是敏捷测试，但似乎云里雾里、不知所云，感觉“敏捷测试”在许多人的心目中还是比较模糊。估计是以前的文章，包括我的文章，没有把“敏捷测试”说透，所以有了再写一篇文章的想法，尽量一次把“敏捷测试”这个内涵给大家说清楚。以后，有机会再讨论传统测试团队如何转型、敏捷文化下测试团队如何建设等。

首先，可以明确的是，敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）。因为在敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法；在敏捷中也可以采用探索式测试（exploratory test），也可以采用基于脚本的测试（scripted test）。那敏捷测试是什么？敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。就像 Scrum 一样，Scrum 可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。简单地说，敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。让我们看看 Wikipedia 是如何描述敏捷测试的：

Agile testing is a software testing practice that follows the principles of agile software development . Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace.

它强调敏捷测试是遵守敏捷开发方法原则之下的软件测试实践，由跨功能敏捷团队的所有人员参与（包括测试人员以其专业特长的特殊贡献）以保证持续的、快速的业务价值交付。所以要理解敏捷测试，我们还是要回过头来仔细看一下“敏捷宣言”背后所蕴含的 12 条原则。我相信，大家都已熟悉敏捷宣言，如果不熟悉，可以先认真阅读以下完整的敏捷宣言，不仅仅是那四句话。

1. 方法论上的敏捷测试

先从敏捷开发这一方法论层次来讨论什么是敏捷测试，即敏捷测试有什么具体特征，或有哪些主要实践，然后再就目前非常热的敏捷具体框架 Scrum 来讨论 Scrum 中的敏捷测试（或称为 Scrum Testing）。先研究一下敏捷宣言背后所蕴含的12条原则[5]：

1) 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

2) 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

3) 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

4) 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5) 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

6) 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

7) 可工作的软件是进度的首要度量标准。

8) 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9) 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10) 以简洁为本，它是极力减少不必要工作量的艺术。

11) 最好的架构、需求和设计出自自组织团队。

12) 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

这 12 条原则中没有一条直接谈到测试，那是否说明没有敏捷测试呢？有开发就有测试，只是原来参加敏捷宣言的 17 人，基本是清一色程序员，没有在原则中单独阐述一下测试的原则。但其中一些原则和测试的关联性很强，例如：

1) 软件测试如何支撑或协助“持续不断地及早交付有价值的软件”？如何在非常有限的时间内进行充分的测试？这就是我们经常在敏捷测试中强调的“自动化测试”，如果没有自动化测试，就没有敏捷，就不能持续不断地及早交付有价值的软件，而且还要“使客户满意”。

2) “欣然面对需求变化，即使在开发后期也一样”和传统的开发原则是不同的，传统的开发希望有严格的需求变更控制，越到后期控制越严。而敏捷开发拥抱变化，那么测试如何适应这种变化？如何快速地完成回归测试？这可能要依赖于开发做好单元测试，或全员参与测试，以及全面支持系统级的、端到端的回归测试的自动化测试执行。

3) 传统的开发也要求“业务人员和开发人员必须相互合作”，但存在一定的阶段性，例如前期需求评审、期间产品走查（product walk-through）、后期验收测试等要求有紧密的沟通与协作。但敏捷开发更强调“项目中的每一天都不例外”，在这样的原则下，如何去做敏捷测试？这样可以减少测试文档，刚开始也没必要把测试计划写得很详细，而是写一页纸测试计划就可以，将来再持续的完善和调整。

4) “可工作的软件是进度的首要度量标准”，不再是测试计划完成情况、完成的测试用例数目、测试脚本量等，而是如何及时验证每天完成的功能特性。开发的工作量也不能按代码行来衡量，而是看多少个具体的用户故事（功能特性）被实现了（done）。某个开发说已完成了某个用户故事，要么是通过他自己的验证，要么是通过测试人员的验证，谁做的测试不重要，关键是要有准备好的测试，随时验证已完成的工作。

5) “坚持不懈地追求技术卓越和良好设计”，一方面要求测试的技术要不断提高，在处理每个测试任务时，都应该找到最有效的办法；另方面，在前期要更多地参与设计评审，及时发现设计的问题。只有良好的设计，才能更好地支持系统的功能扩充和不断的重构。

基于这些原则，我们就可以概括一下敏捷测试的一些特点：

1) 敏捷测试一定是敏捷开发方法的一部分，应符合敏捷测试宣言的思想，也遵守上面所列的敏捷开发的原则，强调测试人员的个人技能，始终保持与客户 / 用户、其它成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化，更关注被测系统的本身而不是测试文档（如测试计划、测试用例等）。

2) 敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发（TDD）、验收测试驱动开发（ATDD），可以见我的另一篇文章《敏捷测试的思考和新发展》所讨论的。测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的快速变化、也无法实现持续的交付。这也说明，在敏捷测试中，开发人员承担更多的测试，这也就是我们说的，在敏捷测试中，是整个团队的共同努力。在敏捷测试中，可以没有专职的测试人员，每个人都可以主动去取设计任务、代码任务做，也可以去拿测试任务来做。在敏捷测试中，也可以像开发人员的结对编程那样，实践结对测试——一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员。

3) 敏捷测试无处不在、无时不在。在传统测试里也提倡尽早测试，包括需求和设计的评审；在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些，例如，需求评审，意味着先让产品人员去写需求，但需求文档写好之后，测试人员再参加评审。而在敏捷测试里，团队每一天都在一起工作，一起讨论需求、一起评审需求。在敏捷测试中，这种持续性更为显著一些。

4) 敏捷测试是基于自动化测试的，自动化测试在敏捷测试中占有绝对的主导地位。在传统测试中也提倡自动化测试，但由于传统开发的周期比较长（几个月到几年），即使没有自动化测试也是可以应付的，一般来说，回归测试能够获得几周时间，甚至 1-2 个月的时间。而敏捷测试的持续性迫切要求测试的高度自动化，在 1-3 天内就有完成整个的验收测试（包括回归测试）。没有自动化，就没有敏捷。

2. Scrum 的敏捷测试

下面就以流行的敏捷框架 Scrum 来讨论敏捷测试，会更具体一些，会更具可操作性。我们通过下面图 2 再复习一下 Scrum 的模型，但这里就不详细介绍了。

图 2 Scrum 过程示意图

从图中可以看出，除了最后“验收测试”阶段，其它过程似乎没有显著的测试特征，但隐含的测试需求和特征还是存在的。

1) Product Backlog （需求定义阶段），在定义用户需求时测试要做什么？测试需要考虑客户的价值大小（优先级）、工作量基本估算之外，需要认真研究与产品相关的用户的行为模式（如 BDD），产品的质量需求，哪些质量特性是我们需要考虑的？有哪些竞争产品？这些竞争产品有什么特点（优点、缺点等）？

2) Sprint Backlog（阶段性任务划分和安排），这时候需要明确具体要实现的功能特性和任务，作为测试，这时候要特别关注“Definition of Done”，即每项任务结束的要求——即任务完成的验收标准，特别是功能特性的设计和代码实现的验收标准。ATDD 的关键一步也体现在这里，在设计、写代码之前，就要将验收标准确定下来。一方面符合测试驱动开发思想，第一次就要把事情做对，预防缺陷；另方面持续测试和验收测试的依据也清楚了，可以快速做出测试通过与否的判断。

3) 在每个迭代（Sprint）实施阶段，主要完成 Sprint Backlog 所定义的任务，这时除了 TDD 或单元测试之外，应该进行持续集成测试或通常说的 BVT（Build Verification Test）。而且开发人员在设计、写代码时都会认真考虑每一组件或每一代码块都具有可测试性，因为测试任务可能由他们自己来完成。如果有专职的测试人员角色，一方面可以完善单元测试、集成测试框架，协助开发人员进行单元测试；另方面可以按照针对新实现的功能特性进行更多的探索式测试，同时开发验收测试的脚本。如果没有专职的测试人员角色，这些事情也是要完成，只是由整个团队共同完成。虽没有工种的分工，但也存在任务的分工。

4) 验收测试可以由自动化测试工具完成，但一般情况下，不可能做到百分之百的自动化测试。例如易用性测试就很难由工具完成。即使对性能测试，是由工具完成，但还需要人来设计测试场景，包括关键业务选择、负载模式等。敏捷的验收测试，和传统的验收测试不同，侧重对“Definition of Done”的验证，但基本的思想和传统开发是一致的，任何没有经过验证的产品特性是不能直接发布出去的。