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

目录

我经历过的一些重构

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

过程中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、新技术的引入和使用。流量回放、灰度发布+监控、数据埋点

你可能感兴趣的:(java,开发语言,测试工具,软件工程,重构)