第04讲：敏捷测试流程解析

谈完敏捷测试思维方式之后，为何先谈流程呢？因为流程也可以理解为实施框架，容易让人看到研究对象完整的概貌，并了解实施的全过程，知道从哪里开始、如何结束，不至于陷入"一片茫然"之境地。例如，在敏捷开发中，有众多的落地模式，比如水晶方法、极限编程、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 这样的设计，会给敏捷测试的实施带来什么好处？欢迎留言讨论。