【如何低成本修bug？测试左移给你答案】

一、为什么要测试左移？　　众所周知，软件工程原则：问题发现得越早，修复问题的代价越低。在《代码大全》一书中，从软件工程实践角度说明一个Bug的成本在产品需求分析阶段、开发阶段、测试阶段、生产阶段有着天壤之别，在修复难度、引入新问题的可能... 一、为什么要测试左移？ 图1 代码门禁  代码门禁通过缩短测试反馈弧尽早发现缺陷，阿里云块存储团队代码门禁单日有效拦截百余次Case，拦截多个业务逻辑缺陷、百余次进程Crash、数据安全性缺陷、CPU/Mem资源使用缺陷等。如若没有代码门禁，将导致问题被掩盖，不断积累。 二、何时进行测试左移？ RethinkDB与MongoDB在竞争中失利。技术上，RethinkDB比MongoDB更追求完美，但是比MongoDB发布稳定版本晚了三年，错过了NoSQL的黄金时机，详细内容可以阅读《RethinkDB：why we failed》 。如下图所示，ABC三家公司关于技术债和业务先行的时间之间的平衡： ·A公司：只关注业务，不关注技术债；  · 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覆盖。 在测试左移的实践过程中，总结了如下三个阶段：  对于IaaS的底层块存储分布式系统，单个单元测试即达到4 Core Cpu和6GB Mem的资源需求，单机无法满足近万个门禁Case测试的及时性。业界和公司内的系统无法满足分布式编译构建和分布式测试的需求，块存储基于Kubernetes+Jenkins自研实现了门禁系统。    "If it hurts, do it more often"，高频测试是治理不稳定Case的法宝，越低频复现的问题越难调查，尽量多的暴露不稳定的失败，降低问题调查的门槛。通过分布式并发运行、提高构建速度（增量编译/分布式编译）、分层测试提

升测试运行速度。

河南省电子规划研究院有限责任公司（河南电子规划院）软件测试,安全性,功能性测试,I信息电子产品研究信息电子产品研究、软件测评软件测评、两化融合管理体系贯标服务两化融合管理体系贯标服务、信息化咨询设计服务信息化咨询设计服务、信息系统集成信息系统集成、建筑智能化工程建筑智能化工程,出具软件评测报告,全国通用,联网可查。