本文介绍由南开大学、华为云及清华大学共同合作的论文:基于多源数据的微服务系统失败测试用例诊断。该论文已被FSE 2024（The ACM International Conference on the Foundations of Software Engineering） 会议录用，论文标题为: Fault Diagnosis for Test Alarms in Microservices Through Multi-source Data。

 

作者：张圣林，朱俊，郝博文，孙永谦，聂晓辉，朱静雯，刘喜临，李小倩，马宇驰，裴丹

随着微服务系统规模的扩张，保障微服务系统的稳定性愈发重要，大量的测试用例被设计用于检测微服务系统相关功能的可靠性，随之而来的是测试用例失败产生的大量测试告警。手动诊断这些告警对测试人员来说非常耗时耗力，因此自动化的测试告警故障诊断应运而生。测试告警中的故障诊断包括测试失败的故障分类和根因定位，能够帮助测试人员更加高效地处理日益增多的失败测试用例。然而，由于微服务系统的复杂性，已有的诊断测试告警的方法无法满足测试人员对于诊断准确度和精度的要求。

 

因此，文章提出了一种针对微服务测试告警的新型故障诊断框架 SynthoDiag ，通过知识图谱联合分析微服务系统测试过程中产生的多源日志（执行机日志、Trace日志和测试用例信息等）进行故障诊断。同时提出了根因关联和位置价值（EFA-PV）算法，用于定位与测试告警相关的日志行，减少测试人员的分析量。此外，文章采用一种高效的基于日志块的过滤方法，筛除测试过程中与故障无关的日志内容，显著提升了故障诊断的整体性能。SynthoDiag在来自华为云的大规模数据集上进行了系统评估。结果显示，SynthoDiag在故障分类的Micro-F1和Macro-F1评分上分别比基线方法提高了21%和30%，并且在故障定位的Top-5准确率达到了81.9%，显著超过了之前的方法。

 

系统集成测试（SIT）阶段的测试用例，包括一系列操作及其相应的检查点，每个测试用例用于测试系统的特定功能或面对特定情况的处理能力。在SIT中，当测试操作的结果与预期不符时，测试用例视为失败并会触发告警。测试失败可能是由于不同的因素导致的，包括但不限于：网络环境不稳定、测试步骤设计错误或系统故 障等。而针对不同的失败原因，存在相应的处理方案，因此将失败的测试用例按照失败的原因进行分类， 能够帮助测试人员快速确定处理优先级和选择解决方案。

 

按照失败原因可以将失败测试用例分为四个类别：环境问题、脚本缺陷、工具缺陷和服务问题。环境问题涉及外部环境因素导致的故障，而脚本缺陷是由测试脚本设计的不合理引起的，而工具缺陷主要是由于测试工具的故障，这里三类问题并不会暴露系统自身的潜在问题，通常需要调试测试环境、更正测试脚本、更新测试工具等方式进行处理。服务问题是最关键的类别，主要是由于微服务系统本身的缺陷所导致的，深入分析这类失败测试用例，有助于发现潜在的服务问题并采取预防措施以避免严重事件。

 

微服务系统中的多源日志在诊断过程中起着关键作用，因为它们提供了有关服务和操作的信息。每个测试用例会生成三种来源的日志，如图1所示：位于用户侧的执行机日志、位于服务器侧的 Trace 日志和测试人员预先编写的测试用例信息。有效地对这三种来源的日志进行联合分析，将能够更加全面有效地对失败测试用例进行建模，并在此基础上实现更加精准的故障诊断。本文的故障诊断包含对失败测试用例进行故障分类和定位，其中故障分类是确定新用例属于哪一个现有的故障类别，而故障定位是识别和突出显示最有可能与根本原因相关的特定日志内容，从而帮助测试人员快速识别和解决故障。

 

图片图1：多源日志样例

 

挑战1：日志格式不统一

 

不同格式的多源日志使得之前的方法在利用这些日志上效果不佳，尤其是在整合半结构化的执行机日志与具有跨度的树结构化的 Trace日志时。

 

 

在失败的测试用例的日志中，并非所有日志内容都与测试失败相关。这些与测试失败无关的日志内容占了很大比例，会干扰提取故障特征。而现有方法不能有效地过滤掉这些无关的日志内容的同时保留相关的日志内容。

 

 

由于微服务系统及其测试脚本频繁的软件升级和配置变更，即使是同一故障类别的测试用例，其故障日志的内容也可能不同。因此，历史测试用例中的故障日志内容可能与新失败的测试用例中的不同，导致现有方法无法提供足够的参考信息，以便在新失败的测试用例中定位故障日志。

结构设计 
 

SynthoDiag框架包括三个主要组成部分：日志过滤、用例嵌入和故障诊断，如图2所示。在解析失败测试用例的日志时，SynthoDiag首先基于日志块过滤掉与测试失败无关的日志内容（解决挑战2）。然后，基于过滤后与测试失败相关的日志内容构建失败测试用例的知识图谱，有效整合不同来源的日志内容（解决挑战1）。接下来，SynthoDiag利用语义信息通过知识图嵌入技术将每个失败的测试用例嵌入到一个向量中，并将历史失败的测试用例的向量和标签将存储在用例分类库中。当需要诊断新的失败测试用例时，SynthoDiag使用相同的步骤获取该测试用例的用例向量和知识图谱，然后输出故障类别并定位测试用例中指示故障的日志内容（解决挑战3）。

 

 

图2：SynthoDiag整体工作流程

实验评估  
 

文章将提出的 SynthoDiag 与四种基线方法在华为云某产品数据集上的应用进行比较分析，以评估方法的有效性。图3展示了 SynthoDiag与基线方法在F1分数、Top-5准确率方面的差异。总体来说，SynthoDiag 在所有基线方法中表现最佳，Micro-F1分数为 0.872，Macro-F1分数为0.891。这些分数比最佳基线方法分别高出21%的Micro-F1分数和30%的Macro-F1分数。具体而言，尽管 CAM 的 Micro-F1 分 数为 0.761，其Macro-F1分数为 0.587 较低，其他三个基线方法在 Macro-F1 分数上的表现也较 差，这显示了SynthoDiag在故障分类工作上的优越性。同时，SynthoDiag 在故障定位上也展示出最佳性能，Top-5 准确率为0.819，说明基于模板或基于字符串的定位方法不适合在微服务系统的失败测试用例中定位故障日志内容。

 

图3：实验结果

 

为了提高针对微服务系统测试的测试用例失败告警故障诊断能力，文章提出的新型故障诊断框架SynthoDiag，利用测试过程中产生的多源日志进行故障分类和定位。SynthoDiag利用知识图谱整合执行机日志、Trace日志和测试用例信息，通过根因关联和位置价值（EFA-PV）来精确定位故障指示日志内容。该框架还采用了基于日志块的过滤策略来过滤掉与故障无关的日志内容，显著提升了故障诊断的整体性能。在华为云的一个大规模实际数据集上进行的系统评估显示，SynthoDiag在故障分类上的Micro-F1和 Macro-F1分数分别比基线方法提高了21%和30%，并且在故障定位的Top-5准确率达到了81.9%，显著优于以前的方法。总体而言，SynthoDiag通过创新地使用知识图谱技术联合分析测试过程中产生的多源日志，为微服务系统中的测试用例故障诊断提供了有效的解决方案。