摘要

说说常见遗留系统的变更难、系统脆的问题，并提出若干手段。

正文

功能测试是盾，只有它的保护，我们才能放心地对遗留系统动刀；而单元测试是刃，它撬动的不仅是遗留系统，更是遗留团队。

遗留系统问题

• 系统晦涩难懂，可读性可理解性很差。理解原有系统往往占据了进行一个修改的大部分时间。
• 系统设计僵化，改动困难，一个小修改，会迫使系统做很多部分的改动。
• 系统难以重用，大多软件单元缺乏可重用性。
• 系统脆弱，引入一个小功能会引入几个缺陷，修复一个缺陷又引起几个新缺陷。
  投入大量人力，产生的价值却微乎其微。

测试ROI金字塔

如下图所示: 从上至下分别是验收测试、API 测试、集成测试和单元测试。

• 越往下测试粒度越来越小，测试数量越来越多。
• 越往上悲观路径覆盖率越来越低
  通过提高验收测试的覆盖率，可以快速将系统的质量提升到 及格线以上。但是想要更高的质量保证, 需要更靠近"金字塔底层"。
  -> 集成测试在功能保护上体现效果更快；而单元测试不仅仅有保证质量的能力, 还会驱动内部质量的提升。

搭建手段

手段: 快起效, 让测试-质量闭环跑起来

必须投入到短期最有价值的地方，才能让团队尽快看到效果和建立信心。
通过前置阶段的测试基础， 未之后的更完善的测试做准备。

快速建立稳定性较高的功能测试防护墙

• 快速，要选择可以快速建立的测试，让一定的价值在短期之内就能得到体现。
• 稳定，指的是测试本身的稳定——不因系统变化而对测试产生太大的冲击，因而维护成本也就相对较低。

这里的功能测试可以是验收测试、API 测试或集成测试。

手段: 针对热点区域 重点攻坚

热点区域(包括需求热点和缺陷热点等）添加测试。
我们无法为整个系统一下子建立完善的测试，但为某一个区域，是有可能的。

• (需求热点区域) 需求变更不频繁, 稳定的暂时不需要补充
• (缺陷热点区域) 遗留系统的脆弱性往往体现在「Bug 重复出现」、「解决一个 Bug，出现两个 Bug」等情形

手段: 价值观、纪律

价值统一
日常管理、人士任免中, 将质量挂靠在公司价值观上

• 以测试为荣，推崇TDD测试，周会日会点名夸奖
• 重视质量的行为: 补测试、推重构，公共夸奖
• 以返工为耻

纪律推动
针对「热点」区域，我们一般会在团队中建立类似「完成新需求必须同时完成测试」、「修复缺陷必须添加测试」这样的纪律。

总结

从本文描述的手段里, 可以重点关注下 "实现快速闭环" 、 "重点攻坚" 、 "价值观、记录"这三个手段。

• 通过快速搭建起一个闭环, 建立起团队的信心，用较为容易实现的测试手段(API测试、功能测试、验收测试), 撬动大家对测试的认知和行为。
• 通过"重点攻坚" 在重点的需求点、bug点区域推动测试的覆盖、深刻质量的认识。
• 在日常管理、人事变动时 体现出对质量的看中----非管理者可以往公司价值观上靠靠, 比如说"追求卓越" 啥的, 大家都知道写测试是政治正确的事情。

敏捷是一场质量游戏， 没有快而脏的代码, 逢脏必慢。

在笔者的工作经验里, 程序员是都知道测试重要的，但是总是由于对于测试的认知不够深刻， 导致总是不小心就欠下了技术债，一债接着一债, 导致最后的系统再也难以变更, 进而不得不进行重写。
在常见的敏捷工作流程里, 总是忽视了对质量的看重。

世上本没有捷径，绕弯路的人多了, 走直路成了捷径。

参考链接: 以自动化测试撬动遗留系统 - qileilove - BlogJava

---

更多文章, 微信公众号 陈浩learning。
希望对您有用。
祝进步。