一、为什么要测试左移？ 众所周知，软件工程原则：问题发现得越早，修复问题的代价越低。在《代码大全》一书中，从软件工程实践角度说明一个
Bug的成本在产品
需求分析阶段、开发阶段、测试阶段、生产阶段有着天壤之别，在修复难度、引入新问题的可能性、沟通成本等方面计算，集成测试阶段修复一个Bug的成本是编码阶段的40倍。 什么是测试左移？即测试向左扩展，让测试介入代码提测之前。比如，扩展到开发阶段，在架构设计时考虑产品的可测试性，进行开发自测。测试左移是一个理念，代码门禁是测试左移的典型实践，即提交代码自动触发编译和测试，构建失败则阻塞代码提交。
图1 代码门禁 代码门禁通过缩短测试反馈弧尽早发现缺陷，阿里云块存储团队代码门禁单日有效拦截百余次Case，拦截多个业务逻辑缺陷、百余次进程Crash、数据安全性缺陷、CPU/Mem资源使用缺陷等。如若没有代码门禁，将导致问题被掩盖，不断积累。
二、何时进行测试左移？ 在系统最初阶段建立严格的代码准入标准和CICD系统是否是最好的时机呢？从质量保证的单一维度考虑，答案是肯定的。但从业务整体效益来看并非全局最优。理性看待
技术债，技术债像贷款，有好也有坏，可以超前消费变现贷款买房，但相应的，有利息，利滚利，开发难度越来越大。 RethinkDB与MongoDB在竞争中失利。技术上，RethinkDB比MongoDB更追求完美，但是比MongoDB发布稳定版本晚了三年，错过了NoSQL的黄金时机，详细内容可以阅读《RethinkDB：why we failed》 。如下图所示，ABC三家公司关于技术债和业务先行的时间之间的平衡：
·A公司：只关注业务，不关注技术债；
· B公司：持续关注技术债，但对业务时机不敏感；
· C公司：持续关注业务和技术债。对业务机会很敏感，最初放手借贷，控制技术债并在合适的时候偿还。
图2 技术债 （来源：《质量与速度的均衡：让“唯快不破”快得更持久》葛俊） 阿里云块存储在2018年初发布ESSD [3] 邀测，业界首个百万IOPS的云盘服务，性能上有50倍的飞跃，在真实业务场景中，PostgreSQL数据库的写入速度快了26倍。透支了大量的技术债抢先了市场之后，团队内部集中偿还技术债，进行质量建设，一年后ESSD达到规模铺量的质量标准并进行了商业化。
三、测试左移的原则和实践 提前透支大量技术债后，团队养成了“糙快猛”的研发习惯，对于改变习惯和测试左移将面临落地的挑战，需要从上至下调整预期，测试左移的前期必然带来项目交付周期的放缓，长远来看，整体效率更高。 测试左移原则不等同于测试原则，实践总结了三条测试左移的原则如下：
表1 测试左移原则 原则一：左移标准共识 建立左移标准并在团队内达成共识是测试左移最基础的原则，在代码门禁系统中要求代码覆盖率卡点、静态代码质量扫描，业务覆盖率 [4] 要求是所有
功能测试均需在代码门禁阶段添加相应的测试Case覆盖。 例如，块存储的云盘是一个分布式存储系统，通过建立了Cluster in Docker的一键秒级构建集群环境实现Function Test测试脚手架，使得全链路E2E测试在代码门禁阶段有了落地的土壤。新Feature评审时功能测试不接受手工测试报告，只接受Function Test List的Code Review，以避免手工测试无自动化沉淀，相同问题重复出现。
原则二：坚持快速反馈 早发现早治疗，越早治疗修复成本越低。对于架构设计、编码实现和测试不足遗漏到生产环境的缺陷，不断反问，该问题是否可以在更早的测试阶段拦截？ 例如，分布式系统下的级联雪崩故障，RPC Timeout不合理 + 无限重试 + 无并发Queue Depth限流造成错误的循环持续运转，负反馈机制压崩了分布式系统。全链路的极限压测是必须的，同时对于单一功能测试验证也必须在代码门禁环节添加自动化Case，让自动化验证限流、重试和超时机制符合设计实现预期。
原则三：持续分解问题 持续分解问题是测试左移最核心的原则，把一个系统拆解为多个子系统，用抽象和分层的方法，让每个同学开发时只面对有限的信息，并且能够有条理的深入到每一个子系统中查看细节。 例如，将复杂问题拆分成具体到每个模块松耦合的功能语义，各模块补充各自的契约测试覆盖。对于分布式系统Server热升级（热升级，即不影响服务的升级），需在升级前，中心管控节点Master将Server进程服务调度走，Server进程之间负责服务迁移（老进程Unload，新进程Load），Client需从Master/Server感知到服务已被调度走，需更换Location进行访问，拆解成Client/Master/Server的多个模块内Case覆盖。 在测试左移的实践过程中，总结了如下三个阶段：
阶段一：建立测试脚手架 简单可依赖的CICD的测试框架是基建保障。业界有很多开源的CI测试框架，例如Jenkins、GitlabCI、Travis-CI、Tekton等，阿里的Aone和蚂蚁的LinkIn等。 对于IaaS的底层块存储分布式系统，单个
单元测试即达到4 Core Cpu和6GB Mem的资源需求，单机无法满足近万个门禁Case测试的及时性。业界和公司内的系统无法满足分布式编译构建和分布式测试的需求，块存储基于Kubernetes+Jenkins自研实现了门禁系统。
图3 EBS CI门禁系统 通过Kubernetes实现Case资源隔离，每个Case独占容器，容器运行过程中CPU/Mem资源设置Limit，避免Case之间打架（例如：某个Case内存泄漏导致内存不足，发生争抢，CGroup可能误杀了其他Case），Case运行环境用完即抛确保环境一致性，提交代码即自动触发测试（Test as a Service），确保有了土壤可以落地后，门禁系统负责测试运行，开发者负责Case编写和不稳定Case的问题解决。
阶段二：高频测试，快速测试 "If it hurts, do it more often"，高频测试是治理不稳定Case的法宝，越低频复现的问题越难调查，尽量多的暴露不稳定的失败，降低问题调查的门槛。通过分布式并发运行、提高构建速度（增量编译/分布式编译）、分层测试提升测试运行速度。 块存储门禁系统基于Kubernetes实现，即具备测试并发度横向扩展能力，白天CI系统进行代码门禁卡点和自助构建任务，夜间高频百轮回归门禁Case和E2E回归。高频测试大大增加了低概率时序Bug的暴露频次，在门禁系统中通过CPU资源超卖，相当于模拟CPU主频降频，多次发现低概率的数据安全性、进程Crash等缺陷问题。
图4 EBS 各级测试运行轮数 阶段三：不稳定Case治理 不稳定Case治理可能是门禁系统中挑战最大的部分，若不治理将导致破窗效应，测试左移则前功尽弃。不稳定Case治理的慢性病更适合小步快跑高频反馈，在具体实践中，首先，通过组织会议脑爆，共同吐槽门禁的不稳定，建立自发的共识、原则和标准进行公示，发动群众的主观能动性；其次，找到推动变革的关键人物，Team Leader和核心成员高度配合，建立红黑榜，每月树立效能之星，做的差的同时也有相应的惩罚；最后，找到推动变革的行动抓手，不稳定Case发现的数据安全性、Crash的严重缺陷团队内强调Case质量和该同学切身利益手头项目的强相关性，建立硬性标准：5%以上概率的失败commmit一天内revert等。关于不稳定Case的治理
Google和
微软在2016年和2017年相继发表了论文，Google论文 [5]，微软论文 [6] 。 块存储治理不稳定Case主要通过高频测试和文化布道。块存储门禁系统是全量卡点，即任一Case失败则阻塞代码提交，随着Case的增加，对Case的稳定性要求与日俱增。门禁系统上万个Case中如若有3个Case通过率为90%，则整体通过率为72%；一周内不稳定的Case的每日运行轮数是稳定Case的权重5倍，未修复Case更高频的暴露复现，对于已修复的Case以验证修复效果。团队内从上至下达成一致共识：生产问题优先级 > 不稳定Case优先级 > 新Feature项目研发优先级。下图是块存储近半年不稳定Case Top15的回归失败轮数，分子是失败轮数，分母是单日运行轮数，失败比例越高颜色越深。
图5 EBS 门禁Top15不稳定Case通过率 在测试左移的实践落地过程中会遇到很多挑战，知行合一很难，整个团队遵守相同的标准规范落地更难。块存储系统有百万行代码，在近一年中生产代码行数增加约20%，测试代码行增加约100%，近万个门禁Case，持续治理不稳定Case，门禁通过率从4.7%提升至70%，后续计划通过精准测试来进一步提升门禁通过率。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
21天更文挑战，赢取价值500元大礼，还有机会成为签约作者！
