变更是软件系统进化的推动力，同时也是孕育风险的温床。如果一个系统没有了相应的迭代和变更，那这个系统就会逐渐失去了活性和价值。不过，随着系统进行了变更迭代，软件风险也会慢慢衍生，而规避变更引发的软件风险在质量保障领域是一个较大的挑战。通过对下面典型软件系统架构图分析，我们可提炼出3大类变更维度：
在这里，我们先列举了一些比较常见的、因变更风险所引发的典型线上事故：
可以看到，在实际的工作中，由变更所引发的风险，对业务的冲击非常大。结合美团亿级流量的到家业务形态看，系统变更引发风险可能性进一步放大，变更风险的“蝴蝶效应”更加凸显，某个单点问题都有可能给整个到家核心业务带来极大的影响。
所以对研发与测试来说，洞察与规避变更引入的质量风险变得至关重要。
那么，关于变更风险，质量建设核心做功点在哪里？我们对历史线上问题分析发现，系统内部变更引发故障的占比较高，且变更与代码变更有直接或间接关系。因此，我们开始围绕代码变更这个核心变更因子，构建了质量建设的做功点。
随后，我们思考了两个关键问题：
传统测试模式存在两个典型问题：第一，对于研发开发的代码，缺少全面可视化分析能力；第二，对于代码变更所产生的影响范围有多大，实际上更多地依赖研发人员和QA的经验。所以，在这样的传统测试模式的典型问题情况下，我们希望从3个维度做质量保障建设方案：
而代码变更风险的质量保障建设方案最终的落地形态，是打造一个代码可视化分析系统，在到家内部我们将其命名为后羿系统。顾名思义，我们希望该系统能像“后羿射日”一样，在质量风险评估和拦截层面能够做到更加精准，同时提升质量防御能力。该系统架构主要分为四层：
总的来说，对于后羿可视化系统的关键流程，在应用层的透出是通过两个入口进行感知：一是后羿主站；二是工程交付平台。我们通过异步消息感知分析任务和源码下载，获取对应的变更文件、变更方法和变更行号；同时再借助字节码解析能力，解析对应的调用链路变更情况，存储到图数据库里；再对变更代码做特征打标和识别；最后会产生一份可视化分析报告，直接给到对应的QA使用。
当然，在整个建设过程中，我们也遇到了一些技术层面的挑战。
第二个技术难点是海量关系数据存储问题。在建设之初，通过关系型数据库做存储，但随着系统的广泛应用，存储了大量调用链路拓扑关系数据，但它的查询性能非常差。所以在此基础上，我们通过探索引入图数据库的存储方式，解决了在海量数据关系存储数据的查询性能。
因此我们做了整体能力改进，通过开发一套组件化开发框架，将整个开发框架开放给各业务线QA，他们可以自己开发定制化开发组件，加载到后羿系统，完成多样性特征的快速识别能力。
接下来，我们重点给大家介绍系统的实践应用落地情况。如下图所示，该图为后羿质量保障应用场景生态全景图。目前后羿系统整体建设了八个核心应用场景：
首先技术方案缺失项诊断，在项目测试过程中，主要包含以下2个痛点：
基于这样的情况，后羿系统通过对代码的识别，能够真正拿到在本次代码层面上，真正变更了哪些信息，再拉取对应的技术方案做解析，再做关键变更信息项的Diff，从而生成一份技术方案的缺失项诊断报告给到对应的QA，QA可以根据此报告做对应的诊断项卡点拦截，同时做测试用例的完善补充。
第二个应用场景是增强版的CodeReview评审新模式，传统的CodeReview也面临几个痛点问题：
基于这样痛点问题，后羿系统打造了基于变更链路场景驱动CodeReview新模式，核心解决在CodeReview阶段能够更早地感知质量风险。其核心做法是后羿系统在Review一个变更文件时，能够快速提炼出变更文件里对应的变更方法、变更变量以及这些变更方法和变量上都具备哪些风险特征，从而让QA和RD快速抓到变更的重点信息。
在此基础上，我们也提供了变更方法的上下游快速跳转能力，基于Review过程中做变更方法的快速跳转，理解整个业务的上下游关系，同时在跳转过程中，能够将跳转的逻辑点实时绘制成调用拓扑图，感知变更方法之间的业务逻辑关系，更好地从整个链路视角评估本次代码变更的影响情况，很好地解决在CodeReview阶段的痛点问题。
第三个应用场景是变更影响范围评估，目前后羿系统构建了六大变更影响范围评估能力：
影响面评估示例：
基于这样的核心痛点问题，后羿系统重点从三个层面做了关于配置变更风险的核心能力建设：
下图是我们目前所建设的应用功能页面：
第五个应用场景是服务端兼容性的风险诊断。我们通过对线上问题做汇总分析发现，新老兼容性这类典型问题占比较高，我们尝试通过后羿系统解决，QA能够做简单的兼容性问题识别，比如一个接口的入参返回值有明显的字段新增或类型变化会明确判断出来。
但在兼容性问题分析上，有一类不太明显的变化导致了兼容性问题，比如入参层面有一些约束条件、由可选字段变成了必选字段，这类变化实际上在整个代码定义层面很难感知到；另外一类是变更参数是通过内部间接调用VO类直接组装出来的，实际上对于QA也很难感知内部间接VO类变化的兼容性风险影响。
所以后羿系统基于这样的痛点，构建了反射和序列化，从而快速拿到对应的底层变更VO类所导致的对接口影响能力，给出兼容性接口预警，QA根据这样的分析诊断报告，进一步评估对应的兼容性和上线顺序的合理性安排。
第六个是接口级自动化用例推荐，对于到家的复杂业务，我们沉淀的很多自动化用例怎么用，是全量回归还是选择性筛选，也是比较大的痛点问题。因此后羿系统基于所具备的识别变更方法、分析影响链路以及对应的接口能力，打通和到家智能代码覆盖率平台所具备的历史流量覆盖情况，能够快速拿到变更接口和方法，再借助一体化平台，拿到对应的自动化用例，做精准的自动化用例推荐，从而构建了用例推荐整体解决方案。
第七个典型的应用场景是代码质量风险特征预警，我们在质量建设过程中，往往会遇到一类比较特殊的场景需要验证，比如资损类场景，除了验证功能外，还需要对资损做个性化风险功能场景验证、异常场景验证、特殊分页逻辑、重试场景验证，但这些场景在整个代码过程中，我们往往很难发现这些特征风险，从而忘记验证特殊场景情况。
针对这个问题，后羿系统从两个方面构建了特征风险识别功能：一是系统会自己构建通用风险特征识别策略模型，二是各业务方也会自己打造对应的风险特征识别策略。
如下图所示（最下侧），是目前已经具备和未来将要建设的特征识别能力。有了核心识别能力后，我们再将对应的特征在所要验证过程中相应上下游的依赖平台做工具能力整合，对于不同特征构建出相对应具体测试策略的推荐策略，将这几个能力打通后构建出一套基于代码质量风险特征的体系化质量保障方案。
结合具体的实践，以及此前总结的经验。未来，我们将从四个方向做未来质量保障建设：
Q1：单次分析报告耗时是多久？同一个工程代码的报告间是独立的还是有关联的？
A：目前1-2min可产生分析报告。报告是基于迭代任务维度生成的服务级报告，比如一个项目迭代里有5个工程代码变更，那么这5个工程代码变更关系会作为一个整体分析，体现到报告里。
Q2：链路的拓扑关系是怎么实现的？
A：链路的拓扑关系基于AST技术和ASM技术进行分析，同时，结合线上Mtrace链路关系作为补充。
Q3：微服务多模块之间的服务调用链路可识别出关联性吗？如HTTP接口后续调用多RPC服务接口
A：微服务多模块之间的服务调用链路可识别出关联性，比如HTTP的下游会调用了哪些RPC接口，目前具备可识别能力。
Q4：底层方法的调用链非常多，这种有推荐策略吗？DB变更是扫描Mapper吗？
A：目前对于调用链路会进行风险特征打标处理，比如：链路包含资损特征、配置特征等，通过特征风险标签能够更好的让用户感知到链路风险等级，为后续测试策略提供关键信息推荐。目前DB变更是通过扫描Mapper进行识别的，基于Mybatis整体DB开发框架做变更扫描。
Q5：关于用例推荐，是推荐单例接口还是会组合成场景接口？
A：目前是推荐单接口用例，比如这个变更接口关联了10个自动化用例，我们会把这10个自动化用例推荐出来。
Q7：实际应用中，主要收益是什么？
A：主要收益是基于八大应用场景落地应用，所有应用场景都会给质量与效率带来价值收益，比如在兼容性问题上已成功拦截多起兼容性质量问题；在配置变更风险评估上，已成功拦截多起因配置默认值编码错误、线上线下配置不一致问题。
Q8：这套平台是否会对线上服务可用性带来影响？
A：目前这个平台对于线上服务可用性不会造成影响，针对线上环境进行分析时，核心操作是拉取线上对应的部署JAR包，不会对现实服务造成可用性影响。
Q9：这个系统有护城河吗？这个系统收益是什么？对业务有什么帮助吗？在业务上有什么体现吗？
A：说到“护城河”，变更分析底层技术上主要还是基于AST和ASM通用技术，核心是对各种业务代码编写方式的兼容支持、业务场景特征识别精度等维度上有一定的技术挑战。
在业务帮助上，一是八大应用场景能够给整个质量和效率带来提升；二是可提升对业务理解的效率，比如通过接口下游调用链路可视化能力，可很快理解这个业务链路关系。
Q10：链路拓扑过大，怎么解决，不同服务使用语言不同，字节码技术有啥推荐吗？
Q11：可以分析出对上下游服务的影响吗？
A：是的。
Q12：分析代码变更，如何识别有效变更和无效变更？
A：比如变更了一段代码，它有可能没有调用方，我们叫做预埋类代码。类似这种代码在测试过程中很难用业务场景进行验证，而且未来上线后很可能会引入潜在风险，目前通过链路变更分析可有效识别此类预埋代码风险。
Q13：系统使用的阶段都是什么？准入阶段还是准出阶段？
A：目前系统在准入和准出阶段都可以使用，没有做严格限制。
Q14：识别出的问题噪音干扰多吗？
A：从噪音干扰层面讲，我们做了很多提升识别率的策略优化，比如HTTP/RPC接口识别率目前已达到98%以上，噪音干扰可做到很好的控制。