敏捷迭代下的测试新基建

01 敏捷迭代呼唤测试敏捷化

近几年，随着敏捷迭代和DevOps的出现，逐步改变了传统的软件开发模式。

在敏捷开发流程中，测试不再是瀑布式开发流程中的其中一环，项目阶段界限变得模糊，测试需要全程参与整个开发流程，持续测试，持续反馈开发质量。

不论是常见的Scrum，还是其他的敏捷开发模式，如“测试驱动开发”、“行为驱动开发”，都离不开测试的支持。这些敏捷开发模式对测试人员提出了更高的挑战和更多要求。

将敏捷开发迭代和传统瀑布开发模式的流程进行比对，可以很直观的看到在传统的瀑布开发模式下，测试只是一个阶段，在开发人员将程序编写完成后进入测试阶段，如下图所示：

在敏捷迭代模式下，测试不止是一个阶段，而是一个活动。每一个Sprint里面都包含测试活动，并且测试在每一个迭代下面都需要进行单元测试、功能测试、用户故事验收测试、性能测试、安全测试、兼容性测试等专项测试。

后续Sprint在交付之前需要进行一次将所有用户故事串联起来进行一次相对全面的测试，例如从业务流程出发，完成端到端（end-to-end，E2E）的测试。如下图所示：

02 敏捷迭代，测试思维随需而变

与传统测试相比，在敏捷迭代中测试思维需要进行一定的转变，在意识上从发现Bug转变为预防Bug出现，从越多发现Bug转变为越早发现Bug，即“全程测试”和“持续测试”。

这对测试团队来说，战线拉长了，事情变多了，任务变重了，因此如何框定测试内容及范围，如何制定测试策略成为了首要问题。

在这里可以参考“敏捷测试四象限”，从业务和技术的角度，以及程序和产品的角度将测试的内容进行划分，如下图：

常见的敏捷迭代结构为Epic-Feature-Story-Task的四层结构.

敏捷开发的过程是由迭代组成的，Epic是由若干个迭代完成，通常为集成测试和端到端的测试，Feature是由若干个迭代来实现，通常会进行功能测试、UAT测试、场景测试；Story则是在迭代内完成，通常会进行功能测试、用户故事测试；Task也是迭代内的测试，通常进行单元测试，模块测试、集成测试。

性能测试、安全测试、可靠性测试等非功能型测试会覆盖到Story、Featrue、Epic层级。以上这些仅作为一些参考，具体落地可以根据公司业务和产品特点进行调整。

测试策略制定好后又将面临另外一个问题：执行效率。

通过上面四象限不难发现，测试在敏捷开发中需要承载的工作职责比传统测试更为宽泛。为了能够更好地配合敏捷开发的小步快跑、尽早交付的模式，自动化能力必不可少。

测试业内也为此提出了“分层自动化测试”的解决方案.

通过分层策略使得自动化在不同层级的测试中都能发挥其作用，提升整体测试执行效率同时降低测试的脆弱性和复杂性。

对于分层自动化测试如何分层，不同公司不同团队都有不同的理解，但大多数都是基于Mike Cohn的测试金字塔模型进行的拓展。为了让大家对分层自动化有一个相对直观的理解，可以参考下图：

这里可能会有人疑惑为什么会有“性能测试”和“测试环境&测试数据自动化”？

“性能测试”在上文中也说到是在Story级别就开始有的，因此“性能测试”在敏捷迭代中也需要通过脚本+数据驱动的方式让其变成常态化，从而形成性能基线，辅助与整个项目的稳定性。

对于“测试环境&测试数据自动化”则更好理解，分层测试不仅仅只是关注测试执行过程中的自动化，还应该需要关注包括测试环境、测试数据准备上的自动化。

有数据统计分析表明，测试环境和数据的准备时间占据了整个测试过程的30%以上，所以通过自动化来解决测试环境和数据则会提高整个测试的效率。

03 测试新基建赋能测试敏捷化，提升敏捷迭代

敏捷迭代下测试敏捷化的解题思路已经有了，接下来就是考虑如何通过技术手段赋能敏捷迭代。

上文也说到通过分层自动化来提高敏捷迭代的测试效率和测试质量，但是如果每一层自动化都是通过独立的小工具或者框架来实施，则会很割裂，效果上也会打折扣。

对于复杂的软件系统，需要搭建一套完整的自动化测试平台。这个自动化测试平台是持续测试基础设施的核心，不仅要支持自动化测试的执行，而且还需要支持其他测试服务，包括测试环境的调度、测试数据的准备、测试报告的生成和管理以及项目在测试环境的准入准出等，平台的设计思路如图：

自动化测试平台除了管理“测试脚本”、“测试数据”、“应用实例”以外，还需要有对测试“测试项目”、“测试文档”、“测试缺陷”具备管理能力。

为了更好的服务敏捷迭代，除了基础自动化以外，还需要引入精准测试能力实现“测试左移”。通过精准测试在代码提交后即刻进行静态扫描获取代码变更点，随后依靠测试脚本与代码的映射关系为测试人员推荐需要测试的脚本，对没有建立映射关系的代码则展示需要补充脚本的接口名称。

在测试脚本执行时，通过链路追踪能力对代码问题进行捕获，直接定位到问题代码行，从而降低开发和测试的沟通成本，缩短开发修复缺陷的时间。

测试用例集执行完成后，通过精准测试的的代码染色能力，可以分析本次测试集的覆盖率，包括类覆盖、分支覆盖以及行覆盖，辅助测试人员对本次测试质量进行判断。

纵观整个测试过程不难发现，精准测试不应该是一个独立的平台，而是应该作为辅助测试的能力贯穿在整个测试流程中才能发挥最大的价值。

随着敏捷迭代的快速推广，近几年Devops也随之兴起，如果要这两者进行比较的话，那么相似之处在于二者都是软件开发技术，两者都追求软件的快速开发，理念都基于如何在不伤害客户和运维利益的情况下快速开发出可以交付的软件。

不同之处，敏捷流程在开发、测试、部署之后会终止，而DevOps还包括了后续的运维，DevOps会持续的监控软件运行情况和进行持续的开发。

为了适应这种更宽泛的模式，测试行业也快速响应，“测试右移”的概念应运而生，比如全链路压测技术，是指模拟真实业务场景中的海量用户请求和数据访问生产环境，对整个业务链路进行全方位、真实的压力测试，提前找到性能瓶颈点并进行持续调优的实践。

全链路压测的核心要素是：流量发起、数据构造、流量染色、数据隔离和在线监控。全链路压测体系如下图所示：

全链路监控告警，在大型分布式系统中，大量的软硬件通过网络通信进行节点间的协作配合，但如果一个节点出现问题极有可能导致整个业务系统出现故障，因此亟需一个监控系统可以对分布式系统进行多维度的监控，这其中就包括了基础设施监控、中间件监控、应用监控、业务监控等等，从功能上来说，监控系统包含3个核心模块：数据收集、数据处理和数据应用。监控告警系统如下图所示：

混沌工程，对于大规模、高复杂度的服务器系统来说，仅在测试环境进行常规测试已经无法满足质量需求，在生产环境下进行测试必将会在现在和未来占据重要位置，混沌工程及其基于故障注入的测试提供了在生产环境中进行破坏性测试的方法和技术。

在分布式系统中，常见的故障类型有很多，大体可以分为应用故障、网络故障、系统故障和硬件故障，混沌工程则是具备通过平台将这些故障引入测试/生产环境来测试系统的弹性能力。

当然，除了故障的注入能力，混沌工程的管理平台还需要具备演练的能力，自动创建、运行、以及对运行过程中的自动监控和结果分析，并及时感知风险，根据情况中断演练并快速恢复系统。混沌工程管理平台如下图所示：

测试左移和测试右移充分体现了测试敏捷化在软件生命周期中每一个阶段的价值，但是在敏捷迭代中，每一项测试活动都会产生测试结果，通过测试结果来评估产品的质量体现了测试的目的和价值，而通过测试结果评估测试工作本身的质量也非常重要，因此质量度量体系也是在敏捷测迭代中需要搭建的基础建设。

从理论上来说，可以用来度量测试质量和测试效率的指标很多，如果所有的指标都进行度量，那么不仅分析的工作量巨大，也容易让管理失去重点。

因此质量度量应该根据测试团队的人员成熟度、流程成熟度、技术成熟度进行适当的选择，核心原则就是：当前阶段看重什么就度量什么，想提高什么就度量什么，这也符合敏捷思维。质量度量体系如下图：

以上是笨马网络对敏捷迭代下测试新基建的一些思考，核心是通过技术手段赋能测试团队，让测试能够在敏捷迭代模式下具备更高的价值，希望能够为正在实践测试敏捷化转型的团队提供一些思路。