系统重构类改造的测试总结

目录

我经历过的一些重构

我理解的系统重构的关注点

过程中QA要做的事情

---

我经历过的一些重构

• 三维建筑设计类PC桌面软件。

背景：使用了上古语言Delphi，共计300W行（包括底层3D引擎）代码，为了跟上新时代技术栈，需要整体切换到C++语言。集团内部提供了已验证的新版C++引擎，业务线需要将各自业务代码迁移至C++。

重构过程：

1. 业务决策。从产品战略维度允许全力投入重构，接受至少1-2年无新产品迭代。
2. 执行重构。按模块翻译代码，最终持续了2年+时间，投入开发团队30+人才完成。
3. 任务估时。整体估时采用单纯的代码行数来评估工作量，比如模块A有50W行代码，需要多久，模块B有**行代码，需要多久。拍脑袋决定的。
4. 技术评估。由于底层核心技术集团以提供，业务团队主要任务是翻译业务逻辑（Delphi -> C++）。

过程中的问题：1、任务估时逻辑不对，太过乐观。2、团队开发人员C++经验较少。3、按单个模块顺序重构，测试介入时间太晚，不可测性太高。4、历史功能逻辑梳理不够，开发中有很多漏需求的情况。

• 单体应用的微服务架构改造

背景：一个极其庞大的单体PHP应用，由于业务数据量增长和性能需求，需要将其中核心业务拆解到JAVA微服务框架。

重构过程：

1. 业务决策。从产品战略维度允许大部分精力投入重构，接受至少半年无新产品迭代。
2. 开发过程。相对顺利，业务测试+接口维度的灰度发布+性能测试 保障了线上稳定性。
3. 技术评估。PHP -> JAVA，业务逻辑重新实现，保证前端无感知。小黑屋封闭开发，中间有几次技术架构调整，导致返工。

过程中的问题：1、对于微服务涉及的知识储备不够，开发中的技术调整的补全导致返工。2、产品需求list缺失，大多数历史逻辑是靠资深开发和测试确认和补回。3、虽然保障了web端的对外接口协议不变，可以通过自动化覆盖大部分改动，但是对于移动端api保障不足。4、中间遇到几次由于对java技术栈不熟导致的故障。

• PC端的文件同步系统重构

背景：网盘的PC端文件同步系统，由于历史遗留bug太多+逻辑庞杂，难以继续堆砌业务逻辑，决定重构。

重构过程：

1. 业务决策。业务上同意重构，但是由于历史负担实在太重，开发团队还是需要分一部分精力同时间处理线上旧版本反馈，且心理负担极大。
2. 开发过程。开发进度缓慢，前面用了很多时间搞Electron，实际核心底层逻辑估时严重不足。bug太多了，测试2、3个月版本无法稳定。
3. 技术评估。底层使用C++ 检测操作系统层级数据变更，业务层用Python实现同步操作，展示层由QT迁移到Electron框架。技术方案评估时由于技术栈特殊性，技术TL无法给予足够指导

过程中的问题：1、心态上负担大，历史名誉不好导致患得患失。2、前期重构规划不足，同时把从底层到前端全部重构，工作量大，新技术多。3、研发团队中缺少相关技术栈沉淀和人员储备4、开发质量太差，同一份用例每次执行都有很多bug（表现重复但底层原因各不相同）。5、缺少有效的测试手段，桌面客户端历史自动化沉淀太少，纯手工。6、产品只给了文件同步大原则逻辑，很多细节是边开发边确认的，导致有很多追加的工作量。

• 某媒体资源管理系统的服务迁移

背景：公司有新旧两套媒资数据管理系统，基于统一研发应用+节省资源的需求，将业务系统中数据管理模块从旧应用迁移到新应用。

1. 业务决策。涉及的上层业务众多，各自迁移节奏不同，花了很多精力推动各方改动
2. 开发过程。整体进度缓慢，走走停停。过程中多次涉及补充兼容逻辑。整体耗时近一年。
3. 技术决策。这个改造方案对于上游业务+前端都有感知，需要配合改造。这次的改造和普通的重构改造还有个区别是，新的媒资系统实际也已经运行了很久且有上层业务衍生逻辑，无法和旧媒资系统完全保持一致。

过程中的问题：1、本身改造复杂度大，需要兼容的点多。2、前后端都有变更，测试手段有限，历史积累自动化无法应用，绝大部分纯手工。3、历史产品逻辑细节较多，重构团队这方面缺少输入，经常出现漏处理的业务逻辑。4、缺少更细粒度的灰度发布手段（只能应用级别灰度）

我理解的系统重构的关注点

1、重构狭义上看是技术层面的，业务逻辑无需改动，甚至上层应用都应该无感知。在重构规划时，应该尽可能往这个方向上靠拢，如果实在无法做到，那么风险极大。

2、重构另一个维度来看，也是业务的一个妥协，但也背着业务债。业务会有新的期待，新的要求，在技术规划时就要考虑到。

3、重构需要依赖功能清单（加粗）

        重构前，已有能力清单应该明确并用来确认重构方案是否支持；

        重构过程中，也可以根据这个清单评估工作量和进度；

        测试时也要按照这个清单逐项验证。

        这个清单应该足够细化，产品+测试+技术同学统一参与进来梳理。

4、可能会受影响的上下游应用都要评估到。关注他们的业务诉求和改造进度诉求。

5、引入新技术、新框架要提前做好知识储备+人员储备。边学边开发是一件要命的事情。

6、重构是一定一定需要测试介入的事情，从前期准备阶段就需要。可测试性需要从改造范围+技术方案+进度计划多个维度考虑。

7、重构期间尽可能专注，别受线上问题、业务压力影响，其他团队/职能帮忙分担些。

过程中QA要做的事情

1、协助梳理历史需求和能力。

这个大多数情况旧系统都缺少文档沉淀、知识积累，甚至连当初设计的人员都不在了。测试大概率是最熟悉这个系统的角色，重构方案制定前，测试需要花较多时间来梳理、确认历史需求和能力，输出给研发，同时支撑自己的测试方案计划。

2、重构方案的可测试性评估和稳定性要求。

        判断改造范围来确定可采用哪些测试手段，尽可能复用之前的自动化，也可以提测试需求（留后门接口、单测覆盖度要求）

        尽早提出稳定性要求，比如灰度发布逻辑，可回滚逻辑，数据备份要求。

        尽可能早的介入测试，可以提一些分阶段测试要求

3、提前准备好功能基线（功能清单）+非功能基线（性能表现），来评估重构后的质量表现。

4、如果发现上面有提到的可能导致质量风险的特征，要及时调整投入的测试资源，充分测试。

5、新技术的引入和使用。流量回放、灰度发布+监控、数据埋点