前言
在当前软件开发过程中，如何保证系统的稳定性和质量一直是一个重要的挑战。特别是对于复杂的业务系统，涉及多个流程和多个端，如何全面验证其功能和性能，并发现和解决潜在问题，成为了一个关键需求。因此，构建一个能够串联多个业务流程、覆盖多个端的全流程自动化测试平台，对于提高系统的稳定性和质量是至关重要的。本文将介绍背景、现状分析、具体实现和运营机制等方面，帮助读者全面了解和理解该平台的重要性和实现原理。
一、定义
（一）背景
1.故障分析：报价发布，导致儿童票购买失败率上涨到 80%
先简单介绍一下我们机票的业务流程，机票的业务流程主要分为搜索流程和交易流程。搜索流程包含 list 和 product，用于提供航班信息；交易流程包含 booking 和生单，用于完成机票预订。
在业务层级上，报价系统在搜索流程给主系统提供航班信息，当用户在主系统中进行航班搜索时，主系统将向报价系统发送请求，请求获取符合用户搜索条件的航班信息和相应的价格。
故障改动主要是对报价进行数据精简，并更换了传递儿童报价信息的节点。因此，根据目前的自动化验证接口结果来看，不返回老节点数据是符合开发预期的。同时，该问题在搜索流程的验证中也没有问题。然而，在生单环节，购买儿童票时使用了搜索流程传递的老节点数据，由于老节点没有数据，导致儿童票购买失败。因此，报价精简字段项目发布后，儿童票购买失败率上涨到80%。
（二）现状分析
1.分析现有接口自动化
经过对我们现有的接口自动化进行分析，发现目前业务流程之间是独立验证的，而每个业务模块也是相互独立验证的。然而，实际上我们的业务流程是相互依赖的，并且存在参数传递的情况。
独立验证的方式无法全面捕捉到各业务之间的依赖关系及其相互影响。特别是在参数传递方面，若某个业务模块传递的参数与其他业务模块的预期不符，会导致错误和异常的发生。
2.分析历史整体故障
在分析我们机票 22 年代码问题导致的故障中，发现其中25%的故障是由于流程验证不全所引起的。进一步细分，其中 67% 的流程验证不全问题是在 APP 端导致的，而剩下的 33% 则是在非 APP 端导致的。
从这个数据可以看出，流程验证不全是一个重要的大类问题。
（三）目标&范围
根据对故障的详细分析，我们明确了全流程自动化平台的目标：构建一个能够串联流程、覆盖多个端，并且能够自动化验证国内机票主流程的 P1/P2 服务的平台。
通过实现这个目标，我们将实现业务流程的全面验证，从而提高系统的稳定性和可靠性，减少故障和线上问题的发生。
二、测量
1. 衡量指标
在搭建完成平台后，为了验证其有效性，我们主要参考了现有的接口自动化数据来进行衡量，主要关注了以下指标：
通过对上述指标的衡量，我们能够全面了解平台的性能和效果，并为后续的优化和改进提供依据。在实际使用中，我们将持续监测和评估这些指标，并根据结果来优化平台的功能和性能。
三、具体实现
在实现全流程自动化时，分为两个主要方面：平台搭建和达成测量目标。下面将详细介绍这两个方面。
（一）完成平台搭建
平台搭建是实现全流程自动化测试建设的第一步，主要包括四个部分的完成：用例获取、流程串联、结果验证和质量门禁。
整体方案：
1.第一部分：case 获取
为了真实还原用户场景，我们选择从线上获取 case，在主系统模拟用户进行覆盖多个端的流程串联，以实现完整的流程串联。
那么，我们应该从哪个流程开始匹配 case ？如何筛选满足条件的 case ？找到的 case 应该如何进行存储？
1）Case匹配
在机票的业务流程中，所有的用户都会经过完整的流程并最终访问 order 页。order 页会汇总主流程的所有信息，例如用户在 list 页选择的航班以及在 booking 过程中购买的商品，都会在 order 页上体现出来。
并且，在我们的业务请求参数中添加了一个名为 preqtrace 的字段，用于记录每个核心接口的前序请求的 qtrace（一个标识符）。
因此，我们可以在 order 页面，通过匹配前序请求的 qtrace ，来串联一次用户请求的关键数据。
2）Case 筛选
有了 case 匹配的对象，必然少不了对 case 匹配对象的筛选。我们提供了一个页面给用户填写需要对 case 筛选的规则。在不同的场景下可以创建不同的规则，一个场景下的所有规则将会又乘起来形成 checklist，只有 case 满足此场景的 checklist 时才认为是符合此场景的 case。通过对日志中的请求参数和返回节点配置过滤条件，可以适配不同业务接入，涵盖不同的业务场景和端。同时，也为不同的业务场景提供定制化的逻辑处理。这样的灵活性使得系统能够适应多样化的业务需求。
3）case 存储
case 存储主要分为三部分，包括过滤规则存储、流程日志存储和满足匹配条件后的流程参数存储。
在过滤规则存储中，我们将不同场景的规则进行存储，以便后续进行匹配和处理。
而流程日志存储部分则是将每个流程的请求参数按照 qTrace 作为 key，存储到 MongoDB 中。考虑到数据量庞大的情况，我们会对数据进行过期处理，即删除超过用户操作最长路径时长 2 小时的数据。
而满足匹配条件后的流程参数存储，则是在用户进入 order 页面时，通过判断是否满足规则配置，如果满足，则根据前序 qTrace 去流程日志存储的 MongoDB 中，获取前序每个流程的请求参数，并存储到 es 中进行进一步处理和使用。
以上就是 case 存储的主要流程和存储机制
2.第二部分：流程串联
在实现了全业务流程和多端覆盖之后，我们的系统也能够灵活地支持不同的业务流程串联。
1）覆盖全业务流程
在软路由环境串联流程，我们能够无需 mock 数据即可串联整个流程，实现了全业务流程的高稳定性。
2）覆盖多端
无论用户是 APP 端，pc 端还是其他方式发送请求，它们都将通过主系统进入流程。主系统将解析请求的参数、路径等，并根据这些信息来确定需要执行的具体业务逻辑。
通过从主系统作为入口，我们可以覆盖多种不同的端和模拟用户请求。同时主系统能够提供一致的请求处理流程，可以方便地对不同的端进行扩展和添加新的功能。
3）灵活支持不同业务流程
通过配置，我们可以根据具体的业务需求，组合和串联不同的业务流程。每个流程的参数传递和执行逻辑都可以通过接口进行自定义。这意味着，我们能够根据实际需求，完全自主地调整和配置流程的执行规则和顺序，将简单的业务流程或者复杂的多环节流程组装成一个完整的流程。
3.第三部分：结果验证
1）常用验证方式
断言和 diff 是常用的结果验证方式，它们各有优劣势。
断言的优势在于其简单直观、精准验证结果的准确性的特点。然而，断言依赖具体值，维护成本高。相比之下，Diff 的优势在于其灵活自适应、可视化展示以及动态比较的能力。然而，Diff 的复杂度较高，可读性有限。
2）全流程自动化验证
机票业务的复杂和迭代速度快，我们需要采用 diff 的方式，然而，diff 工具有时会出现问题，当基准环境中的失败是由流程串联引起的，而软路由环境中的失败是由代码问题引起的时候，两个失败的 diff 结果可能会得到一个一致的结果。因此我们需要先验证流程串联是否成功，再验证代码逻辑修改是否有问题；所以全流程自动化结果验证采用 diff+ 断言的方式。
4.第四部分：质量门禁
在质量门禁方面，我们的目标是通过关联项目进行质量控制，并实现可主动或手动触发的自动化流程。为了实现这一目标，我们需要进行以下步骤：
-
关联项目：将质量门禁与相关项目进行关联，确保每个项目都能进行质量控制。
-
主动触发：为了确保项目质量，我们可以主动触发自动化流程。例如，开发完成或提测项目后，会自动执行质量门禁流程。这样可以及时发现和解决质量问题。
-
手动触发：除了自动触发外，还应该提供手动触发的选项，以便开发人员在需要时可以手动运行质量门禁流程。这样可以满足特定需求或针对个别问题进行质量控制。
-
结果主动通知：当质量门禁完成后，系统可以自动发送通知给相关人员，这样，可以及时了解门禁结果，以便采取相应的措施。
（二）达成测量目标
在平台搭建完成后，我们的重点是进行稳定性维护，以实现我们的衡量目标。为了达成这个目标，我们主要关注以下几个方面：case 有效性、流程稳定性和 diff 降噪。
1.case 有效
随着业务变化，存储的 case 发生变化后是不可用的；主要的应对策略是 Case 稳定性提高和新鲜度保障
1）Case 稳定性提高
case 稳定性的提高是从业务维度和数据维度两方面来做的：
2）Case 新鲜度保障
先保证 case 量足够，再使用滑动时间窗口实现 case 的新鲜度
2.流程稳定
为了流程的稳定性，从系统维度采取了以下措施：
- 失败重试机制：在执行 Case 时，如果遇到失败的情况，可以进行自动的重试操作。重试机制可以通过设定重试次数和重试间隔来避免单次失败影响整个测试流程的稳定性。
- 流量并发限制：对系统的相关接口或功能进行流量并发限制，防止过多的并发请求导致系统崩溃或性能下降。可以通过调整并发限制策略、增加缓存策略等方式来提高系统的稳定性。
同时也有异常反馈：设置监控系统，实时监测 Case 执行的状态和结果。通过监控系统的反馈，可以及时发现 Case 执行过程中的失败和异常情况，并及时采取措施进行处理。
3.diff 降噪
对于数据干扰的问题，可以通过降噪操作来降低干扰率，以提高结果 Diff 的准确性。以下是几种降噪的方法：
- 忽略特定差异：如果已知某些特定的差异不会对比较结果产生重大影响，可以将其标记为可忽略的，同时支持项目维度的忽略。
- 通过率设置：根据具体情况和业务场景配置其通过率，以满足不同场景下结果 Diff 的准确性要求
四、运营机制
（一）运营方式
为了保证全流程自动化测试平台的正常运行和不断提升，我们需要建立一套完善的运营机制。主要包括日常关注平台使用情况，每周进行数据统计，并与开发团队密切合作，以推动平台的改善和提升。
（二）运营指标
运营指标主要是根据我们衡量标准来运营维护的
（三）全流程自动化测试平台运营数据
以下是我们全流程自动化测试平台目前的运营数据
五、未来计划
为了提升我们的全流程自动化平台的功能和效能，我们制定了以下的后续计划，主要包括持续提高 case 覆盖率和执行并发性能、简化和可视化流程配置，以及支持国际主流程串联。
总结
构建全流程自动化测试平台对于提高系统的稳定性和质量具有重要意义。通过实现全流程自动化测试，我们能够全面验证业务流程的功能和性能，发现和解决潜在问题，并提升系统的稳定性和可靠性。在实施过程中，我们需要关注 case 的有效性、流程串联的稳定性和结果验证的准确性，并建立合理的运营机制来推动平台的不断改善和提升。通过全流程自动化测试平台的运行，我们相信我们能够提供更稳定和可靠的系统服务，为用户带来更好的体验。
