敏捷测试漫谈

    在聊敏捷测试之前，有必要先聊聊敏捷。最近几年，XXOps不断的提起，被不断的赋于新的含义，DevOps，TestOps，SafeOps等等。现在的软件工程不说敏捷都不好意思提。在早期的瀑布式研发模式下，软件工程定义好了研发环节的各种要求，引入了比如PMP项目管理，比如CMMi成熟度模型等内容，这是很明显的“工程思维”。工程思维要求我们必须按既定的规划（需求文档），根据工程设计图（概要设计、详细设计）进行施工（编码），然后进行严格的验收（测试），最后交付（发布运维）。看着好像没有什么问题，也一直执行了好多年，对吧（类比如下图）。

但是，软件研发和工程研发是不一样的。比如建筑工程，必须严格按照设计图纸来施工，出现偏差后果很严重，但是软件一定要按概要设计来么？在编码过程中如果发现了更好的设计模式，更优秀的框架，为什么不能引入呢？后来，有一群开发人员聚在一起讨论和研究这个问题，倒腾出来了敏捷宣言（本文不展开讲，有兴趣的自行查找），以服务的思维重新梳理了研发模式。服务思维的核心是：用户满意。在服务的过程中，我们需要的是拥抱变化、持续反馈并加以修正。最终让用户满意，让市场满意。需要注意的是，敏捷的最终目标不是快，而是持续反馈（一个典型的例子，就是之前有人说汉武建方仓，是敏捷实践的最佳案例，看完就想打人，那是标准化的威力）

     回到敏捷测试，敏捷测试并不是一种新的测试方法（白盒测试、性能测试之类的），也不是一种新的测试技术（探索性测试）。在我看来，敏捷测试更多的是一种思维上的转换，而不是实施层面的问题。原来的测试方法和测试技术，在敏捷测试中一样可以应用，并没有区别。我对敏捷测试的理解有以下三点：

Vol.1

敏捷测试是一种有效的反馈，越早越好

     我们都知道问题越早暴露越好，所以我们提倡测试左移，推行ATDD，BDD等等，都是为了更早的发现问题，并快速反馈，让团队减少返工和浪费。

在需求澄清阶段，需要注意：以终为始，确保需求输入质量，首先要讲解业务目标，其次操作及操作流程，再次是业务规则。需求不是方案，而是用户的价值。只有我们从价值开始，层层分解，从业务到实现层面充分沟通，才能保证后面交付的质量。有人会觉的测试人员无法接触到真正的客户，无法理解什么真正的用户价值，认为这是产品经理需要做的事。在这个阶段，测试人员可以做两件事：

1.    尽可能多的参与产品的规划，了解需求背后客户真实的想法（用户群反馈、竞品分析、自己真实使用感受等等都可以获取价值）

2.    协助产品经理完成业务流程的梳理，评估需求对现有流程的影响，是否存在互斥的因素，新业务对原有业务是否有影响。是否有遗漏的场景等等。

如果TDD（Test Driven Development）在团队的落地可能会存在困难，我们可以尝试使用验收测试驱动开发（ATDD，Acceptance Test Driven Development）在需求分析时就确定需求（如用户故事）的验收标准，并记录在故事卡片上。从需求的角度去准备验收标准和测试用例。同样可以保障从开发的开始就有较高的质量

Vol.2

自动化测试是敏捷测试的一种必要手段

    想要做到快速反馈，必然要依靠大量的自动化测试。

     新模式的测试金字塔下，除了顶端的探索性测试、体验测试等活动外，其它的测试均可做到自动化测试。最好能够做到端到端的自动化测试，保证更多的覆盖面。如果暂时做不到，至少接口测试和服务间集成测试需要保障，否则无法保障交付质量。需要警惕的是不要让自动化测试流于形式（如没有断言，不可被CI集成，事后补用例 等等）。持续多个迭代后，好的自动化自动化测试ROI会让你感到惊喜。

Vol.3

敏捷测试必须是一种可持续的活动

      在开展测试活动（不管哪类测试）时，我们可能会受制于各类客观因素，如无法快速构建测试环境（特别是微服务的框架下，如何快速构建对应分支的测试环境成为很大的一个痛点），无法快速生成测试数据（业务链路长，前置数据准备要求多，数据结构复杂等）。这些问题需要整个研发团队一起努力解决，业内现在也有比较成熟的解决方案可供参考（如环境标签、链路配置等方案解决环境问题，数据工厂、数据中台等解决全平台的数据生成问题）。

同时，我们要保证在任意节点，都可以快速开展测试（自动化脚本能够区分颗粒度的被不同研发阶段调用），只有可持续的测试，才能持续的反馈，比如开发提交代码后，就能触发单元测试，进行分支合并后，进行接口测试。

    综上，敏捷测试不是测试手段的创新，是思维的转换，需要我们更早的参与测试，更早的提出反馈。基于以上三点理解，我们就可以有效的构建起团队的质量文化，也就是所谓的内建质量，当每个环节的产出都能够得到有效的保障，就可以减少等待，让研发环节尽快的流动起来，最终交付到用户手中，得到最终的反馈。

补充：全文多处提到反馈。这是敏捷思维中非常核心的观点。如果不能及时反馈，我们就无法修正问题，交付的价值就可能产生偏差。敏捷最大的好处就是缩短了反馈路径。其实生活中，我们也要尽可能的做到快速反馈，这样才能更好的解决问题。