谈完敏捷测试思维方式之后，为何先谈流程呢？因为流程也可以理解为实施框架，容易让人看到研究对象完整的概貌，并了解实施的全过程，知道从哪里开始、如何结束，不至于陷入“一片茫然”之境地。例如，在敏捷开发中，有众多的落地模式，比如水晶方法、极限编程、Scrum、自适应软件开发、动态系统开发方法等，但 Scrum 给了一个清晰、简单的流程，很容易理解 Scrum 是如何运作的，所以就容易被大家所接受。今天我们谈起敏捷，你肯定会想到 Scrum。

Scrum 模式下的测试流程

那么，我们就先从大家所熟悉的、相对简单的 Scrum 模式讲起。Scrum 中没有瀑布模型那样将研发周期分为需求、设计、编程、测试、运维等明显的阶段，但需求阶段是隐含存在的，就是发布计划（Release Planning）产生 Product Backlog 这个过程，包括梳理需求、优先级排序、估算基本工作量等，而后续迭代的过程可以理解为持续设计、持续编程、持续构建（持续集成）、持续测试、持续交付、持续部署的过程。

在 Scrum 迭代中，我们强调持续测试，但如果只说“持续测试”，你一定很迷茫，不知道在 Scrum 中如何具体去做测试，所以我设计了一张敏捷测试的流程图，如图 1 所示。

             

图 1 Scrum 模式下的敏捷测试流程

下面就来详细讲解这张图的具体含义。从图中可以看出，Scrum 模式下的敏捷测试流程有 7 项主要活动——测试需求分析与定义、测试计划、测试设计、BVT（Build Verification Test）、持续测试、版本验收测试、测试交付与反思等，但不能理解为 7 个阶段，许多活动都是并行的，包括计划、设计都是贯穿整个迭代。

（1）测试需求分析与定义，对用户故事（User Story，US）、Epic 等进行评审，为每一个用户故事建立验收标准，确保它具有可测试性，并从业务需求出发，了解要做哪些测试，初步界定测试的范围等。

（2）测试计划，这里指的是当前迭代的测试计划，包括进一步明确具体的业务要求和质量要求、制定测试目标、明确测试范围和测试项、分解测试任务、识别出测试风险并制定测试策略等。计划是一个覆盖整个迭代的过程，通常用 Planning，也就是前面所说的，要基于上下文不断调整或优化测试计划，只是在 Sprint Planning 时先写出初步的测试计划，按这计划开始执行后续的测试过程。

（3）测试设计，这里强调的是大颗粒度或粗颗粒度的测试设计，包括测试模型设计，如事件流图、状态图等的设计，而不是指测试用例的设计，因为后面第 32、38 讲会讨论探索式测试，完全可以不写测试用例。

（4）BVT，版本构建（Build）的验证测试，即只要有版本构建，不管是每日构建，还是代码提交触发的软件版本构建，都需要对软件版本进行自动验证，因为只有高成功率的持续集成才有意义。这里的 BVT，不仅包含传统的冒烟测试，即对当前软件版本实现的基本功能进行测试，而且包括对代码进行扫描，检查代码的规范性、安全性等，即通常所说的代码静态分析。

（5）持续测试，是迭代中主要的活动，根据前面案例所讲的，测试的问题常常出在这里，让测试成为持续交付的瓶颈，就是没能做到持续测试。究竟什么是持续测试，本讲后面会有进一步的说明。这里包括设计评审、单元测试、用户故事实现的验证、集成测试等，包含持续的新功能测试和持续的回归测试，也包括性能测试、安全性测试、兼容性测试等专项测试。

（6）版本验收测试，敏捷中的验收测试通常是指对用户故事验收标准的验证，但是我觉得还得在交付前需要增加这样一个环节——将所有的用户故事串起来进行相对全面的测试。比如，从业务流程出发，完成端到端（End-to-End，E2E）的测试，相当于许多团队在 Beta 环境、准生产环境上进行一轮完整的测试或试用一段时间。因为之前的测试具有一定的局限性，一个单元一个单元的测、一个故事一个故事的验证，比较零碎，缺少系统、全面的测试，而且代码一直在修改。

（7）测试交付与反思，即使通过验收测试，并不意味着测试结束了，就像 Scrum 迭代后期还有两个会议：迭代评审会和反思会。虽然测试报告、缺陷分析等可以自动完成，但也是要做的事，就像 BVT 是自动进行的，我们也把它定义为一项重要的活动。除了测试报告、缺陷分析之外，测试交付还包括质量分析，并要回顾、审视整个测试过程，找到做的不好的地方，在下一个迭代版本中改进。这些内容，将会在第 46、47、49 讲中讨论。

敏捷测试的通用流程

如果你说，我们没有用 Scrum，而是用了其他的敏捷开发模式，如 BDD、FDD 等，那敏捷测试流程是怎么样的？

像 BDD 将在第 24 讲中讨论，它是测试驱动开发（Test Driven Development, TDD）的具体落地，更准确地说，是验收测试驱动开发（Acceptance Test Driven Development , ATDD）的落地。

TDD 有别于以往的“先编码、后测试”的开发过程，而是在编程之前，先写测试脚本或设计测试用例，在敏捷开发中被称之为“测试优先的编程（Test-First Programming）”。

无论是 TDD 还是 ATDD，都是强调“测试先行”，使得我们对所做的设计或所写的代码有足够的信心，同时也有勇气快速重构设计或代码（敏捷中经常要做的事），这将有利于快速迭代、持续交付。重构的前提就是测试就绪（Testing is Ready），在这样的前提下，重构的风险会很低，否则风险会很高。

TDD 也确保了单元测试是持续的，必须先写测试脚本、再写代码，只要编程是持续的，单元测试、集成测试也是持续的，但更重要的是第一次把事情做对，更好地保证代码质量，研发的成本也就降到了最低，即我们前面所强调的“质量是构建出来的”，预防缺陷比发现缺陷更有价值。如果在代码层实施 TDD 有困难，那我们就将 TDD 移到需求层来落地，这样就产生了 ATDD、BDD，这些将会在第 20 讲中详细讨论，虽然那里侧重讨论用户故事的可测试性。

如果是 FDD，就可以参考上面的 Scrum，延伸过去，建立适合自己的流程。一般来说，流程都需要根据上下文——开发模式、产品、行业、团队进行调整或剪裁，找到适合自己的流程，并不是一成不变的。

现实中有不少敏捷团队还保留着“提测”这样的环节——开发写好代码，在某一天达到某个标准，就可以提交给测试团队，然后开始全面测试。这其实还是传统测试，不是敏捷测试，相当于第 1 讲案例中所描述的那样，开发和测试被分为两个不同的阶段，还没有真正跨入敏捷测试。的确，有不少敏捷团队只是交付的节奏快了，但执行的一套流程还是传统的，即我们通常说的“小瀑布”、伪敏捷。

持续测试没有“提测”环节，持续测试也不等于持续集成，持续集成里只包含了 BVT；持续测试也不等于自动化测试，虽然会向自动化测试借力。持续测试就是从产品发布计划开始，直到交付、运维，测试融于其中、并与开发形影不离，随时暴露出产品的质量风险，随时了解产品质量状态，从而满足持续交付对测试、质量管理所提出的新要求。甚至可以想想 F1 赛车，在比赛时需要加油或比赛中出现故障，都是场修处理，处理完了再继续比赛。

敏捷测试流程闭环与持续测试

今天，我们也开始关注测试右移，做更多的在线监控、在线测试，这方面内容将会在第 45 讲中详细讨论。根据“持续测试给数字化业务赋能（Continuous Testing as a Digital Business Enabler）”调查数据显示，持续测试带来的收益非常明显，速度提高到 1.9 倍、质量上升到 2.4 倍，整个产出投入比提高到 3.9 倍，如图 2 所示。

图 2  Continuous Testing as a Digital Business Enabler 调查结果

对于不同的敏捷开发模式，敏捷测试流程也可以抽象成如图 3 所示的闭环。敏捷团队成员（包括开发、测试）需要拥有敏捷测试思维方式，以加强协作，提倡测试驱动开发，尽早开始测试并能实现持续测试，包括及时地、持续地对需求、设计、代码等进行评审，以便能够及时、持续地揭示需求、设计、代码、系统中存在的质量风险，及时反馈给团队和项目的相关利益者（干系人）。 就像我经常说的，不仅仅是把 bug 报给开发，而是要透过 bug 看到质量风险、看到问题的本质，比如开发对需求的理解不正确、某个技术方面存在短板等风险。

图3 敏捷测试流程闭环

敏捷项目管理角度看测试流程

上面主要是从软件开发过程（即工程过程）来展示敏捷测试流程，如果从项目管理角度来展示测试流程，可以描述成如图 4 所示的流程。这个流程主要强调：

尽可能写出简单的测试计划，能写一页纸就不写两页纸、能写两页就不写三页……

没有测试用例的设计，而只是粗颗粒度的测试设计，前面有说明；

测试执行的双支撑，不仅需要自动化测试，而且还需要探索式测试；

强调质量文化、基础设施等重要性，并贯穿整个测试周期。

详细内容在本专栏的第五、六 部分中讨论。

图 4 敏捷项目管理中的测试流程

最后，给你出一道思考题：敏捷测试流程与传统测试流程相比，你认为最大的不同在哪里？像图 3 和图 4 这样的设计，会给敏捷测试的实施带来什么好处？欢迎留言讨论。

-– ### 精选评论 ##### **荣： > 不太同意持续测试没有提测的环节，敏捷迭代里每个角色都应该为自身的产出质量负责，测试在这个过程中要做的更多的是监控开发过程，提测不代表不做前期测试活动，提测更多的是标记可以转入集成测试阶段。 ##### *达： > 敏捷测试流程中，我觉得应该开发提测环节；目前我们公司就是这样去做的，开发提测不仅仅是提交代码，而是在测试环境做好功能主流程的冒烟测试，保证环境可用，主流程能正常，这样测试接手以后，就可以直接进行测试，这样会避免测试同学因一些环境问题，配置问题，主流程不通而测试阻塞；这个点更好体现敏捷测试中开发与测试协同测试的原则 ######     讲师回复： >     如果设立“开发提测”的里程碑或环节，就违背了持续测试的原则。而且在敏捷测试中，提倡“团队对测试负责”，像微软那样的许多公司已经没有专职的测试工程师，如果强调“开发提测环节”，也是逆历史潮流的，不符合未来趋势。 ##### **乐： > 虽然我们也是走的敏捷迭代模式，但是测试还没真正实现前移，还有提测环节，看来还是老师说的伪敏捷啊😀 ##### *鑫： > 现在想想，我们团队或多或少也用了一些敏捷的流程，这过程中也是不断磨合和不断试错后改变的。 ##### *五： > 一下提到 BDD、TDD、ATDD、FDD 这么多，感觉慌的一地…… ######     编辑回复： >     不积跬步无以至千里，努力学习吧 少年 ##### 潘： > 敏捷测试流程图总结得非常清晰明了，很有用👍 ##### **芸： > “没有测试用例的设计，而只是粗颗粒度的测试设计”难道不会有漏测的情况么，如果多人协作测试，怎么分配每个人的工作 ######     讲师回复： >     有详细测试用例也会有漏测。可以按SBTM来安排任务，就是把测试计划的目标分解成多个子目标，每个子目标再分解成合适的测试任务（session），可以参考第33、34讲 ##### **5721： > 提测肯定是要有的。提测前的测试是怎么进行的？ ######     讲师回复： >     真正的敏捷测试是持续测试，是没有“提测” 这样的里程碑或时间节点的，开发每天都有代码提交，每天都有2-3次构建，测试人员就针对这些新构建的版本进行测试。如果最迟几天，没有新的版本，测试人员可以熟悉新特性、做测试需求分析，同时为上一个迭代已实现的特性开发自动化测试脚本 ##### *达： > 我觉得传统测试流程与敏捷测试流程最大不同：传统测试流程没有去持续测试 ##### **0907： > 端到端（End-to-End，E2E）的测试也应该包括在BVT里面吧，如果完全依靠最后发布之前的版本验收测试，是不是太晚了 ######     讲师回复： >     BVT一般希望几十秒钟到几分钟就能完成，不宜放在BVT中，但可以在图1 的“持续测试”中做一些回归测试对应的E2E测试，只是版本验收测试是比较彻底全面的E2E的测试。