系统重构类改造的测试总结-创新互联
目录
我经历过的一些重构
我理解的系统重构的关注点
过程中QA要做的事情
我经历过的一些重构
- 三维建筑设计类PC桌面软件。
背景：使用了上古语言Delphi，共计300W行（包括底层3D引擎）代码，为了跟上新时代技术栈，需要整体切换到C++语言。集团内部提供了已验证的新版C++引擎，业务线需要将各自业务代码迁移至C++。
重构过程：
- 业务决策。从产品战略维度允许全力投入重构，接受至少1-2年无新产品迭代。
- 执行重构。按模块翻译代码，最终持续了2年+时间，投入开发团队30+人才完成。
- 任务估时。整体估时采用单纯的代码行数来评估工作量，比如模块A有50W行代码，需要多久，模块B有**行代码，需要多久。拍脑袋决定的。
- 技术评估。由于底层核心技术集团以提供，业务团队主要任务是翻译业务逻辑（Delphi ->C++）。
过程中的问题：1、任务估时逻辑不对，太过乐观。2、团队开发人员C++经验较少。3、按单个模块顺序重构，测试介入时间太晚，不可测性太高。4、历史功能逻辑梳理不够，开发中有很多漏需求的情况。
- 单体应用的微服务架构改造
背景：一个极其庞大的单体PHP应用，由于业务数据量增长和性能需求，需要将其中核心业务拆解到JAVA微服务框架。
重构过程：
- 业务决策。从产品战略维度允许大部分精力投入重构，接受至少半年无新产品迭代。
- 开发过程。相对顺利，业务测试+接口维度的灰度发布+性能测试 保障了线上稳定性。
- 技术评估。PHP ->JAVA，业务逻辑重新实现，保证前端无感知。小黑屋封闭开发，中间有几次技术架构调整，导致返工。
过程中的问题：1、对于微服务涉及的知识储备不够，开发中的技术调整的补全导致返工。2、产品需求list缺失，大多数历史逻辑是靠资深开发和测试确认和补回。3、虽然保障了web端的对外接口协议不变，可以通过自动化覆盖大部分改动，但是对于移动端api保障不足。4、中间遇到几次由于对java技术栈不熟导致的故障。
- PC端的文件同步系统重构
背景：网盘的PC端文件同步系统，由于历史遗留bug太多+逻辑庞杂，难以继续堆砌业务逻辑，决定重构。
重构过程：
- 业务决策。业务上同意重构，但是由于历史负担实在太重，开发团队还是需要分一部分精力同时间处理线上旧版本反馈，且心理负担极大。
- 开发过程。开发进度缓慢，前面用了很多时间搞Electron，实际核心底层逻辑估时严重不足。bug太多了，测试2、3个月版本无法稳定。
- 技术评估。底层使用C++ 检测操作系统层级数据变更，业务层用Python实现同步操作，展示层由QT迁移到Electron框架。技术方案评估时由于技术栈特殊性，技术TL无法给予足够指导
过程中的问题：1、心态上负担大，历史名誉不好导致患得患失。2、前期重构规划不足，同时把从底层到前端全部重构，工作量大，新技术多。3、研发团队中缺少相关技术栈沉淀和人员储备4、开发质量太差，同一份用例每次执行都有很多bug（表现重复但底层原因各不相同）。5、缺少有效的测试手段，桌面客户端历史自动化沉淀太少，纯手工。6、产品只给了文件同步大原则逻辑，很多细节是边开发边确认的，导致有很多追加的工作量。
- 某媒体资源管理系统的服务迁移
背景：公司有新旧两套媒资数据管理系统，基于统一研发应用+节省资源的需求，将业务系统中数据管理模块从旧应用迁移到新应用。
- 业务决策。涉及的上层业务众多，各自迁移节奏不同，花了很多精力推动各方改动
- 开发过程。整体进度缓慢，走走停停。过程中多次涉及补充兼容逻辑。整体耗时近一年。
- 技术决策。这个改造方案对于上游业务+前端都有感知，需要配合改造。这次的改造和普通的重构改造还有个区别是，新的媒资系统实际也已经运行了很久且有上层业务衍生逻辑，无法和旧媒资系统完全保持一致。
过程中的问题：1、本身改造复杂度大，需要兼容的点多。2、前后端都有变更，测试手段有限，历史积累自动化无法应用，绝大部分纯手工。3、历史产品逻辑细节较多，重构团队这方面缺少输入，经常出现漏处理的业务逻辑。4、缺少更细粒度的灰度发布手段（只能应用级别灰度）
我理解的系统重构的关注点1、重构狭义上看是技术层面的，业务逻辑无需改动，甚至上层应用都应该无感知。在重构规划时，应该尽可能往这个方向上靠拢，如果实在无法做到，那么风险极大。
2、重构另一个维度来看，也是业务的一个妥协，但也背着业务债。业务会有新的期待，新的要求，在技术规划时就要考虑到。
3、重构需要依赖功能清单（加粗）
重构前，已有能力清单应该明确并用来确认重构方案是否支持；
重构过程中，也可以根据这个清单评估工作量和进度；
测试时也要按照这个清单逐项验证。
这个清单应该足够细化，产品+测试+技术同学统一参与进来梳理。
4、可能会受影响的上下游应用都要评估到。关注他们的业务诉求和改造进度诉求。
5、引入新技术、新框架要提前做好知识储备+人员储备。边学边开发是一件要命的事情。
6、重构是一定一定需要测试介入的事情，从前期准备阶段就需要。可测试性需要从改造范围+技术方案+进度计划多个维度考虑。
7、重构期间尽可能专注，别受线上问题、业务压力影响，其他团队/职能帮忙分担些。
过程中QA要做的事情1、协助梳理历史需求和能力。
这个大多数情况旧系统都缺少文档沉淀、知识积累，甚至连当初设计的人员都不在了。测试大概率是最熟悉这个系统的角色，重构方案制定前，测试需要花较多时间来梳理、确认历史需求和能力，输出给研发，同时支撑自己的测试方案计划。
2、重构方案的可测试性评估和稳定性要求。
判断改造范围来确定可采用哪些测试手段，尽可能复用之前的自动化，也可以提测试需求（留后门接口、单测覆盖度要求）
尽早提出稳定性要求，比如灰度发布逻辑，可回滚逻辑，数据备份要求。
尽可能早的介入测试，可以提一些分阶段测试要求
3、提前准备好功能基线（功能清单）+非功能基线（性能表现），来评估重构后的质量表现。
4、如果发现上面有提到的可能导致质量风险的特征，要及时调整投入的测试资源，充分测试。
5、新技术的引入和使用。流量回放、灰度发布+监控、数据埋点
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
网页题目：系统重构类改造的测试总结-创新互联
当前链接：http://pwwzsj.com/article/dscpop.html
