上文说完了敏捷测试思维，本文我们来介绍下流程，那为什么要先介绍流程呢？因为流程也可以理解为实施框架，容易让人看到研究对象完整的概貌并了解实施的全过程，知道从哪里开始、如何结束，不至于陷入“一片茫然”的境地。例如:在敏捷开发中，有众多的落地模式，比如水晶方法、极限编程、Scrum、自适应软件开发、动态系统开发方法等，但scrum 给了一个清晰、简单的流程，很容易理解Scrum是如何运作的，所以就很容易被大家所接受。今天我们谈敏捷，你肯定会想起Scrum ,我们就从大家熟悉的，相对简单的Scrum开始。
Scrum 中没有瀑布模型那样将研发周期分为需求、设计、编程、测试、运维等明显的阶段，但需求阶段是隐含存在的，就是发布计划（Release Planning）产生Product backlog这个过程，包括梳理需求、优先级排序、估算基本工作量等。而后续迭代的过程可以理解为：持续设计、持续编程、持续构建（持续集成）、持续测试、持续交付、持续部署的过程。在Scrum迭代中，我们强调持续测试，但如果只说持续测试，你一定很迷茫，不知道在Scrum中如何具体的去做测试，这边设计了敏捷测试的流程图，下面就来详细讲解这张图的具体含义。
Scrum 模式下的测试流程
图 1 Scrum 模式下的敏捷测试流程
从图中可以看出，Scrum模式下的敏捷测试流程有7项主要活动，需求分析与定义、测试计划、测试设计、BVT、持续测试、版本验收测试、测试交付与反思等，但不能将他们理解为7个阶段，许多活动都是并行的，包括计划设计都是贯穿整个迭代。
测试需求分析与定义
对用户故事（User Story,US）、Epic等进行评审，为每一个用户故事建立验收标准，确保它具有可测试性，并从业务需求出发，了解要做哪些测试，初步界定测试的范围等。
测试计划
这里主要指的是当前迭代的测试计划，包括进一步明确具体的业务要求和质量要求、制定测试目标、明确测试范围和测试项，分解测试任务，识别出测试风险并制定测试策略等。计划是一个覆盖整个迭代的过程，通常用Planning，也就是前面说的要基于上下文不断调整或优化测试计划，只是在Sprint Planning 时先写出初步的测试计划，按这个计划开始执行后续的测试过程。
测试设计
这里强调的是大颗粒度或粗颗粒度的测试设计，包括测试模型设计，如事件流图、状态图等的设计，而不是指测试用例的设计。（后面讲到的探索测试，就完全不用写测试用例）
BVT
版本构建（Build）的验证测试，即只要有版本构建，不管是每日构建，还是代码提交触发的软件版本构建，都需要对软件版本进行自动验证，因为只有高成功率的持续集成才有意义。这里的BVT不仅仅包含传统的冒烟测试，即对当前软件版本实现的基本功能进行验证，而且包括对代码进行扫描，检测代码的规范性，安全性等，即通常所说的代码静态分析
持续测试
是迭代中主要的活动，根据前面案例所讲的，测试的问题常常出在这里，让测试成为持续交付的瓶颈，就是没能做到持续测试。究竟什么是持续测试，本文后面会有说明，这里主要包括设计评审、单元测试、用户故事实现的验证、集成测试等，包含持续的新功能测试和持续的回归测试，也包括性能测试、安全性测试、兼容性测试等专项测试
版本验收测试
敏捷中的验收测试通常是指对用户故事验收标准的验证，但是，我觉得还得在交付前增加这样一个环节----将所有的用户故事串起来进行相对全面的测试。例如从业务流程触发，完成端到端的测试，相当于许多团队在Beta环境、准生产环境上进行一轮完整的测试或试用一段时间。因为之前的测试具有一定的局限性，一个单元一个单元的测，一个故事一个故事的验证，比较零碎，缺少系统全面的测试，而且代码一直在修改。
测试交付与反思
即使通过验收测试，并不意味着测试结束了，就像Scrum 迭代后期还有两个会议：迭代评审会议和反思会，虽然测试报告、缺陷分析等可以自动完成，但也是要做的事情，就像BVT是自动进行的，也把它定义为一项重要的活动。除了测试报告、缺陷分析之外，测试交付还包括质量分析，并要回归、审视整个测试过程，找到做的不好的地方 ，在下一个迭代版本中进行改进。
敏捷测试的通用流程
可能会有人没有用Scrum，而是用例其他的敏捷开发模式，如BDD、FDD 等，那么敏捷测试流程是怎么样的呢？
BDD是测试驱动开发（Test Driven Development,TDD）的具体落地，或者准确的说是验收测试驱动开发（Acceptance Test Driven Development,ATDD）的落地，TDD 有区别于以往的“先编码、后测试”的开发过程，而是在编程之前，先写测试脚本或者设计测试用例，在敏捷开发中被称为“测试优先的编程（Test-First Programming）”，无论是TDD还是ATDD，都强调"测试先行"，使得我们对所作的设计和所写的代码有足够的信心，同时也有勇气快速重构和设计代码，这将有利于快速迭代和持续交付。重构的前提就是测试就绪，这样的前提下，重构的风险会很低，否则会很高。TDD也确保了单元测试是持续的，必须先写测试脚本，再写代码，只要编程是持续的，单元测试、集成测试也是持续的。但更重要的是第一次把事情做对，更好地保证代码质量，研发的成本也就降到了最低，即前面强调的“质量是构建出来的”，预防缺陷比发现缺陷更有价值。
如果在代码层实现TDD有困难，那我们就将TDD移动到需求层来落地，这就产生了ATDD和BDD，这个会在后续讨论。
如果是FDD，可以参考Scrum，延伸过去，建立适合自己的流程，并不是一成不变的。
现实中，不少敏捷团队还保留提测这样的环节，开发写好代码，在某一天达到了某一个标准就提交给测试团队，测试团队开始全面测试，这其实还是传统测试，不是敏捷测试，相当于第一讲所描述的那样，开发测试被分为两个阶段，还没有真正跨入敏捷测试，的确有不少敏捷团队只是交付的节奏快了，但执行的流程还是传统的，即我们通常说的“小瀑布，伪敏捷”。
持续测试没有“提测”环节，持续测试也不等于持续集成，持续集成里只包含了BVT，持续测试也不等于自动化测试，虽然会向自动化测试借力。
持续测试就是从产品发布计划开始，直到交付、运维，测试融于其中，并与开发形影不离，随时暴露出产品的质量风险，随时了解产品质量状态，从而满足持续交付对测试、质量管理所提出的新要求。可以类比赛车，在比赛过程中需要加油，或者在比赛时，车出现了故障，都是在现场处理，处理结束了再继续比赛。
目前我们也开始关注测试右移，而做更多的在线监控，在线测试，这个后续文章会有提及。
敏捷测试流程闭环与持续测试
根据持续测试给数字化业务赋能这个调查结果的数据显示，持续测试所带来的收益非常明显，速度提高到1.9倍，质量上升到2.4倍，产出投入比提高到3.9倍，如图2所示。
图 2 Continuous Testing as a Digital Business Enabler 调查结果
对于不同的敏捷开发模式，敏捷测试流程也可以抽象成如图 3 所示的闭环。敏捷团队成员（包括开发、测试）需要拥有敏捷测试思维方式，以加强协作，提倡测试驱动开发，尽早开始测试并能实现持续测试，包括及时地、持续地对需求、设计、代码等进行评审，以便能够及时、持续地揭示需求、设计、代码、系统中存在的质量风险，及时反馈给团队和项目的相关利益者（干系人）。 就像我经常说的，不仅仅是把 bug 报给开发，而是要透过 bug 看到质量风险、看到问题的本质，比如开发对需求的理解不正确、某个技术方面存在短板等风险。
图3 敏捷测试流程闭环
敏捷项目管理角度看测试流程
上面主要从软件开发过程即工程过程这个角度来展示敏捷测试流程，如果从敏捷项目角度看测试流程，可以描述成图示所示的流程。
图 4 敏捷项目管理中的测试流程
项目管理角度流程主要强调：
- 尽可能写出简单的测试计划，能写一页就不写两页，能写两页就不写三页
- 没有测试用例的设计，而只是粗颗粒度的测试设计，前文有说明
- 测试执行的双支撑，不仅需要自动化测试，而且还需要探索式测试
- 强调质量文化，基础设施等重要性，并贯穿整个测试周期