代码变更风险可视化系统建设与实践
总第575篇
2023年 第027篇
1 软件系统风险与变更
2 代码变更风险可视化（后羿）系统建设
3 代码变更风险可视化（后羿）系统实践
4 未来规划与展望
5 Q & A
1 软件系统风险与变更
基础设施变更：主要包括基础硬件变更、运营商网络变更、云服务容器变更、开发语言变更、操作系统变更以及机房集群的变更，这些基础设施迭代极大提升了系统底层的服务能力，一旦变更引发系统风险，其影响面通常也比较大。 系统外部变更：比如用户流量突增、用户需求变化以及相关三方服务及三方组件变更，这些帮助系统不断衍生出新的迭代能力，同时也增加了系统稳定性风险的发生。 系统内部变更：比如技术人员迭代、新功能发布以及系统整体架构的升级等，这是驱动系统软件进化的核心变更因子，也是最频繁的变更风险发生地。
外部变更所引发的线上问题，某地的光缆被挖断导致整个服务有很大的影响。 代码变更典型问题，谷歌Gmail系统在发布新功能时产生的副作用而引发的功能上问题。 代码变更典型问题，Knight公司在升级一段很老的代码时引发的异常逻辑功能发生。 配置变更引发的问题，所引发的“薅羊毛”事件。 人员操作变更，研发误操作引发的整个核心数据删除；
可以看到，在实际的工作中，由变更所引发的风险，对业务的冲击非常大。结合美团亿级流量的到家业务形态看，系统变更引发风险可能性进一步放大，变更风险的“蝴蝶效应”更加凸显，某个单点问题都有可能给整个到家核心业务带来极大的影响。
第一，从到家业务接入方看，美团内部业务包括外卖、闪购、医药等等，外部有众多的企业客户。 第二，系统参与相关方较多，包括C端用户、商家、配送骑手及各个平台。 第三，业务基于微服务架构模式，各个业务间调用关系复杂，核心链路非常长。另外，业务强依赖配置，一旦某个环节发生变更问题，相关方都会受到影响。
所以对研发与测试来说，洞察与规避变更引入的质量风险变得至关重要。
那么，关于变更风险，质量建设核心做功点在哪里？我们对历史线上问题分析发现，系统内部变更引发故障的占比较高，且变更与代码变更有直接或间接关系。因此，我们开始围绕代码变更这个核心变更因子，构建了质量建设的做功点。
随后，我们思考了两个关键问题：
代码变更风险是否可被可视化，提升测试和研发感知能力。 围绕代码变更风险，是否能够构建一套质量保障防御体系。
通过分析发现，结合下图的代码特征树，我们就可以更好地感知代码变更的可视化能力。然后通过各叶子节点，将所有相关特征很好地识别，并且做对应的质量防御策略。
2 代码变更风险可视化（后羿）系统建设
传统测试模式存在两个典型问题：第一，对于研发开发的代码，缺少全面可视化分析能力；第二，对于代码变更所产生的影响范围有多大，实际上更多地依赖研发人员和QA的经验。所以，在这样的传统测试模式的典型问题情况下，我们希望从3个维度做质量保障建设方案：
第一阶段是代码变更的感知能力，重点解决对于不同的代码形态和不同的代码工程模式，如何能够最大范围地覆盖到所有的代码变更情况； 第二阶段重点做代码特征刻画，将所有变更代码抽离出不同的特征，打上作用标签； 第三阶段基于前两个建设能力，构建对应的应用场景生态圈，在不同测试流水线阶段，都能够将代码变更风险的刻画能力嵌入，不断做质量防御。
而代码变更风险的质量保障建设方案最终的落地形态，是打造一个代码可视化分析系统，在到家内部我们将其命名为后羿系统。顾名思义，我们希望该系统能像“后羿射日”一样，在质量风险评估和拦截层面能够做到更加精准，同时提升质量防御能力。该系统架构主要分为四层：
第一层是基础组件层。 第二层是代码分析层，重点解决对不同的代码形态都能够做到精准的代码变更分析和识别。 第三层做特征刻画层，核心解决整个代码的结构化标注和特征化标注。 第四层负责构建业务应用层，在不同的场景和环节下，将代码变更可视化能力嵌入到这个环节中，构建一个完备的质量风险拦截能力。
除此之外，我们也会引入智能化手段，赋能整个系统。同时，我们也将核心能力通过开放Open API方式，输出到其他的质量效率相关的工具平台上，赋能美团内部的其他工具平台。
当然，在整个建设过程中，我们也遇到了一些技术层面的挑战。
第一个挑战是代码分析技术。在系统建设初期，通过AST单分析能力做代码分析和识别，但存在Lambda表达式识别问题和Java泛型识别问题，在此基础上引入了ASM字节码分析技术解决了前面的问题，但ASM也会有自己的Java反射特性相关问题无法识别。所以我们希望未来引入动态化代码分析技术，来解决反射类问题。
第二个技术难点是海量关系数据存储问题。在建设之初，通过关系型数据库做存储，但随着系统的广泛应用，存储了大量调用链路拓扑关系数据，但它的查询性能非常差。所以在此基础上，我们通过探索引入图数据库的存储方式，解决了在海量数据关系存储数据的查询性能。
第三个技术难点是代码风险特征多样性，像个性化特征跟我们的业务有强相关性，比如资损特征、对应的分页特征和多线程特征。针对这种风险特征，我们之前的开发模式是系统开发者和业务QA深度沟通对应的识别策略，但这样的方式沟通效率和开发周期都比较长。
因此我们做了整体能力改进，通过开发一套组件化开发框架，将整个开发框架开放给各业务线QA，他们可以自己开发定制化开发组件，加载到后羿系统，完成多样性特征的快速识别能力。
3 代码变更风险可视化（后羿）系统实践
接下来，我们重点给大家介绍系统的实践应用落地情况。如下图所示，该图为后羿质量保障应用场景生态全景图。目前后羿系统整体建设了八个核心应用场景：
技术方案层面校准诊断 在Code Review阶段能力的增强 变更影响面评估 接口级的用例推荐 配置变更风险诊断能力 兼容性风险诊断能力 代码特征风险预警 开放Open API能力
首先技术方案缺失项诊断，在项目测试过程中，主要包含以下2个痛点：
研发写技术方案时，标准化程度较低。 中间反馈的问题对于技术方案更新时效性较差，但我们发现技术方案对QA来讲是一个关键性的依赖输入，从而导致QA在写测试用例时，往往会遗漏掉一些关键性的变更信息，比如接口定义变更缺失、配置项定义变更缺失、定时任务变更缺失、异步消息变更缺失以及DB表字段变更缺失，这些信息往往在技术方案里更新不全面。
基于这样的情况，后羿系统通过对代码的识别，能够真正拿到在本次代码层面上，真正变更了哪些信息，再拉取对应的技术方案做解析，再做关键变更信息项的Diff，从而生成一份技术方案的缺失项诊断报告给到对应的QA，QA可以根据此报告做对应的诊断项卡点拦截，同时做测试用例的完善补充。
第二个应用场景是增强版的Code Review评审新模式，传统的Code Review也面临几个痛点问题：
研发在整个Review过程中更多地聚焦在编码规范和架构设计合理性上。 常态化的Code Review模式基于纯文本，它也有几个痛点：第一是无法针对Review的过程做变更方法的上下游快速跳转查看；第二无法做到对变更方法、改动方法的跳转或调用链路的业务逻辑呈现。
基于这样痛点问题，后羿系统打造了基于变更链路场景驱动Code Review新模式，核心解决在Code Review阶段能够更早地感知质量风险。其核心做法是后羿系统在Review一个变更文件时，能够快速提炼出变更文件里对应的变更方法、变更变量以及这些变更方法和变量上都具备哪些风险特征，从而让QA和RD快速抓到变更的重点信息。
在此基础上，我们也提供了变更方法的上下游快速跳转能力，基于Review过程中做变更方法的快速跳转，理解整个业务的上下游关系，同时在跳转过程中，能够将跳转的逻辑点实时绘制成调用拓扑图，感知变更方法之间的业务逻辑关系，更好地从整个链路视角评估本次代码变更的影响情况，很好地解决在Code Review阶段的痛点问题。
第三个应用场景是变更影响范围评估，目前后羿系统构建了六大变更影响范围评估能力：
代码基本属性，比如变更了哪些方法； 能够支持到HTTP、RPC以及JAR包等不同形态代码工程类型； 能够对通用风险特征做识别，比如事物递归兼容性问题； 可以对定制化风险特征做识别，比如权限、算法特征； 可以支持单服务影响，包括方法调用链路，接口特征、消息特征、任务特征等等； 跨端服务的影响面评估，比如一个服务内部的调用链路和在不同的微服务之间的跨端变更点之间的链路影响是什么样子的，都能够做到更精准地影响范围评估能力。
影响面评估示例：
一个变更接口被影响到了，那么它的下游到底是哪些变更方法影响的？我们能够很直观地看到这个变更接口下面有哪些新增的和变更方法所影响到的。 下游所变更的影响方法之间的链路调用拓扑关系是什么样子？我们能够通过链路拓扑图，快速绘制出来对于这个接口下面所有变更方法之间的调用链路。 对应的变更方法对于接口中间所有方法的调用链路详情，我们也能够通过这个能力快速做评估和刻画。 对于一个接口下面所有方法的链路调用关系是什么样子？我们也提供了一个全方法链路的视图分析能力。
第四个应用场景是配置变更的风险诊断，在比较复杂的大型业务上，整个系统对配置往往有强依赖关系，比如典型的灰度配置、降级配置以及内部逻辑相关控制配置项，对于整个系统的影响比较大，但往往QA和研发人员对于配置风险的把控实际上比较缺失，认为代码可能更多的是质量保障的重点，所以由于配置所导致的线上问题比较多，造成的结果比较严重。
基于这样的核心痛点问题，后羿系统重点从三个层面做了关于配置变更风险的核心能力建设：
在配置的变更识别分析层，我们能够很好地对各种类型配置做精准识别：是新增还是变更。 通过后羿影响面评估能力，拿到配置所影响的接口、影响链路以及对应影响的异步消息和定时任务。 有了影响面评估后，我们能够更好地通过测试，将变更场景做到覆盖，由此构建了配置变更测试覆盖度量。因为我们在配置测试过程中对于测试结果的感知能力不强，因此通过基于流量挖掘、流量录制能力构建了实时感知配置测试的覆盖情况。在整个流水线层面，通过关键配置变更卡点能力更好地防御配置变更所引发的一些问题。
下图是我们目前所建设的应用功能页面：
第五个应用场景是服务端兼容性的风险诊断。我们通过对线上问题做汇总分析发现，新老兼容性这类典型问题占比较高，我们尝试通过后羿系统解决，QA能够做简单的兼容性问题识别，比如一个接口的入参返回值有明显的字段新增或类型变化会明确判断出来。
但在兼容性问题分析上，有一类不太明显的变化导致了兼容性问题，比如入参层面有一些约束条件、由可选字段变成了必选字段，这类变化实际上在整个代码定义层面很难感知到；另外一类是变更参数是通过内部间接调用VO类直接组装出来的，实际上对于QA也很难感知内部间接VO类变化的兼容性风险影响。
所以后羿系统基于这样的痛点，构建了反射和序列化，从而快速拿到对应的底层变更VO类所导致的对接口影响能力，给出兼容性接口预警，QA根据这样的分析诊断报告，进一步评估对应的兼容性和上线顺序的合理性安排。
第六个是接口级自动化用例推荐，对于到家的复杂业务，我们沉淀的很多自动化用例怎么用，是全量回归还是选择性筛选，也是比较大的痛点问题。因此后羿系统基于所具备的识别变更方法、分析影响链路以及对应的接口能力，打通和到家智能代码覆盖率平台所具备的历史流量覆盖情况，能够快速拿到变更接口和方法，再借助一体化平台，拿到对应的自动化用例，做精准的自动化用例推荐，从而构建了用例推荐整体解决方案。
第七个典型的应用场景是代码质量风险特征预警，我们在质量建设过程中，往往会遇到一类比较特殊的场景需要验证，比如资损类场景，除了验证功能外，还需要对资损做个性化风险功能场景验证、异常场景验证、特殊分页逻辑、重试场景验证，但这些场景在整个代码过程中，我们往往很难发现这些特征风险，从而忘记验证特殊场景情况。
针对这个问题，后羿系统从两个方面构建了特征风险识别功能：一是系统会自己构建通用风险特征识别策略模型，二是各业务方也会自己打造对应的风险特征识别策略。
如下图所示（最下侧），是目前已经具备和未来将要建设的特征识别能力。有了核心识别能力后，我们再将对应的特征在所要验证过程中相应上下游的依赖平台做工具能力整合，对于不同特征构建出相对应具体测试策略的推荐策略，将这几个能力打通后构建出一套基于代码质量风险特征的体系化质量保障方案。
第八个应用场景的能力是开放Open API的赋能能力，我们希望将后羿系统分析识别的信息，通过开放API的方式透露出去，能够给到对应相关工具平台使用。目前在到家范围内已经将整个能力开放给了接口管理平台、智能代码覆盖率平台、全息系统、异常测试平台、自主工程交付系统以及一体化自动化平台这六个核心的效能工具建设平台。
4 未来规划与展望
结合具体的实践，以及此前总结的经验。未来，我们将从四个方向做未来质量保障建设：
代码分析技术的增强，希望能够通过动态链路分析技术，提升整体的分析准确性。 风险特征识别技术，希望能够基于大语言模型相应能力对风险特征的分析和对应测试策略做推荐。 进一步丰富应用场景生态圈，探索在不同测试环节、不同测试场景下，将后羿能力做更好的整合，赋能到具体的业务质量建设中。 长期来讲，希望将系统的核心能力，通过开源共享方式赋能给相关测试领域。
5 Q & A
6 本文作者
---------- END ----------