本文分享一些技术改进类项目（以下简称“技改项目”）的质量保障思路。

1. 技改项目的质量挑战

何为技改项目？ 即目标是服务于技术改进或架构升级，而非服务于常规的业务功能更新。常见的技改项目有：大规模的前端重构或后端重构、技术架构升级、数据库拆分、数据迁移、系统上云和云迁移、非对客的支撑性项目等。（非对客：不直接面对前端用户的功能，通常是系统的支撑性需求）

为什么这类项目的质量保障思路值得单独讨论？ 区别于常见的业务功能更新，这类项目往往都是在保持原有业务的基础上进行的底层支持或改造，与以往业务功能测试的角度不同，更多的是针对非功能需求的测试。而团队整体缺乏业务视角，或对非功能需求的质量认知不足，可能会引发大量的质量风险或缺陷，破坏已有功能的正常运转。

另外，技改项目面临的情况往往比较复杂，缺失的大量业务上下文，难以偿还的技术债遗产，项目人员往往面临着一边做技改、一边理业务的困境。难上加难的是，还可能同步进行着现有业务的扩充或变更，这就更为技术改进类项目的质量保障过程雪上加霜。

因此，这类项目的质量保障任重而道远，需要特别对待，从长计议。

2. 兵马未动，策略先行

♦ 风险驱动整个过程

技改项目好比暗潮涌动的平静海面，平时不出事，一出就是大事。因此，风险分析和干预应贯穿始终。

常见的质量风险盘点如下：
1）低估工作量或研发过程中的工作量膨胀，不能如期上线
2）上线过程不可逆，有失败风险
3）破坏既有稳定功能
4）影响外部集成系统
5）不可抗力导致上线时间变动，提前或延后
6）质量较差造成的大量返工

我们把这些风险放到风险状态矩阵中，可针对不同等级的风险制定不同程度的干预或响应机制。

风险状态矩阵：尽早分析 Over 走一步看一步

♦ 构建质量防护网

按理来说技改类的代码变动，类比重构，应保证原有功能不被破坏。但现实往往是“动一行、挂一片”，“动两段，修半年”。

在做大规模的技改前，构建质量防护网尤为重要。 设计良好的自动化测试能被频繁执行，这就构成了质量保障的基础。我们诟病于自动化测试的投资回报率低，通常是因为用错了地方。自动化测试应用于需要大量回归测试的场景，如业务变量较少的技改类项目，会比应用于频繁开发新功能的场景更见效也更经济。

除了自动化测试给代码质量的保障，还需要人工干预的流程保障。 测试人员应坚守质量门禁，即使是一张技术卡或任务卡，也要像对待用户故事一样，坚持开结卡的流程，明确验收标准和完成定义，确保已经做了的事情都是有效且高质量的。

质量门禁的意义：破坏引入问题的回路

♦ 为“不可逆”而设计和预演

试想这样的场景：常规的功能发布，经过紧锣密鼓的上线部署和验证，突然发现存在重大问题，来不及临时修复，只能回滚。于是相关的服务回滚后，测试人员又进行了回归验证，确保服务回滚不会造成重大的影响。为了不影响业务运转，往往只能在非工作时间进行部署，折腾完这一圈可能都是后半夜了，好在有惊无险。大家盯着转危为安的软件，露出了欣慰的笑容。

如果是技改类项目呢？一样的过程，上线→发现问题→回滚？无法回滚！若此时遇到问题，内心只有两个字：“绝望”。技改类项目的特点决定了上线过程基本都是不可逆的一锤子买卖，很少具备有多套生产备份或灾备的条件。因此，技改类项目的开发、测试、部署、基础设施、上线过程等等一系列研发活动，都需要为“不可逆”而设计，**并且应在类生产环境进行多轮具备多样性的部署预演。** 不能事后补救，只能事前预防。

3.业务视角不能丢

技术改进，并不只是技术范围内的事。 除非这部分代码完全不会在生产环境运行（当然这种情况也不需要上线），否则都需要带着业务视角来看待技术改进。在改进过程中，如何边改边保持业务的稳定运行，如何确保迁移后的数据能在业务系统里顺利流转，如何保证非对客项目的架构设计满足业务系统的支撑性需求？这些问题的探讨都不能独立于技术范围，而需要更多业务侧的输入。

♦ 业务输入与业务评审

业务人员天然具备业务视角，可以从保证业务连续性的角度给技改类项目两类输入，一类是业务知识本身，项目背后的业务沉淀和业务重点；另一类是为了保证业务连续性，需要提供的支撑性需求，如可追踪/留痕、容错性、高可用需求等。

在技改过程中，识别到任何可能影响本系统业务或集成系统业务的改动内容，都需要组织业务评审，充分理解业务背景，再评估改动范围和风险。

♦ 基于风险的业务优先级判断

资源总是受限，以追求经济的投资角度来看，应基于风险来判断业务优先级，给不同风险等级的业务，投入与之匹配的质量资源。 如下图，呈现了基于业务优先级的自动化测试设计。

基于业务优先级的自动化测试设计

♦ 业务集成要趁早

如有可能，尽早集成。 应从设计时就进行思考，验收时依赖的内部服务尽量不用mock。盘点改进点或迁移数据的业务含义；所需覆盖的业务场景，尽量以端到端的视角去做技改部分的验证。如果早期不考虑集成相关的问题，后期可能面临的就是大量返工，甚至推倒重来。这个沉没成本是不情愿也不应该付出的。

4.技术实现，应知其所以然

♦ 深入技术细节

因技改类项目需维持业务连续性，且通常底层变化难以从外部观测，可测性不高，因此在做技改类项目的测试和质量评估时，需要深入技术细节，对具体的实现过程刨根问底。只有深入技术细节，才能有效避免“错误的输入经由处理后，阴差阳错地返回了正确的、或看上去正确的输出”。

♦ 重视非功能需求

非功能需求，也称跨功能需求或支撑性需求（Non/Cross-functional requirement），是指按照一些条件判断系统运作情形或其特性，而不是针对系统特定业务行为的需求。——维基百科

测试非功能需求的两大质量目标：一是保证系统稳定运行，二是保证系统可持续发展。

• 运行质量：可在系统运行时观察到的质量，如安全、性能、可用性等
• 发展质量：与软件系统结构和开发过程有关的质量，如可维护、可扩展等

技改类项目应更加重视非功能需求： 整个改进过程是否破坏了系统原本支持的非功能需求；干系人或用户对改进后系统的非功能需求预期是否发生了变化；对已经捕捉到的非功能需求，应能清晰描述验收标准和期望的系统运行状态。

非功能需求示例：针对不同系统特性，应形成相应的非功能需求重点

5.一些经验教训

♦ 1+1<2

由于技改类项目的特殊性，承担这类项目研发工作的大都是研发骨干，这对项目经理提出管理上的挑战。需警惕“1+1<2”的陷阱，避免频繁陷入漫无边际的无意义的技术讨论中。同时兼顾技术决策的投资回报和改进效率，以及核心骨干人员的工作体验。陷于类似困境的同事们都能深刻意识到团队梯队的重要性，全是资深同事并不利于工作的快速推进和高效管理。

♦ 全局视角

影响技改或被其影响的干系方很多，技改类项目需要更宏观的全局视角。不只关注技术，更关心业务；不只关心自己的业务，也关心是否影响外部集成方的业务；不仅关注当下的运行质量，也关心未来的业务或架构演进。一句话总结，这个全局视角需要横跨技术和业务、团队和干系人，还有时间上的现在和未来。

♦ 业务沉淀的必要性

具备高业务复杂度的项目一定要做好知识管理，再忙也别忘了抽空做业务沉淀和知识传递。业务沉淀的必要性就好比人的软实力，平时可能看不出差距，持续做也似乎成效甚微。但凡遇到复杂度上升或面临艰难挑战，管理人员就会发现，在平时点点滴滴的实践过程中，业务上下文的构建和业务视角的赋能，已经在团队中悄无声息的完成了。关键时刻方见奇效。