接上篇：https://developer.aliyun.com/article/1225735?spm=a2c6h.13148508.setting.31.595d4f0eudDbz0
三、 方案说明
通过接口流量录制回放、定海神针场景链路验证的方式，形成自动化测试任务集，在交易核心应用发布过程中，新增发布流水线的测试验证节点，当应用完成安全生产环境部署后，自动化触发执行关联的测试任务。测试任务执行后，验证当前的自动化结果情况、应用核心测试集校验情况。根据应用预先配置的卡点阀值来判断卡点校验是否通过。如果卡点校验通过，则可以继续进行后续的发布流程。如果卡点校验未通过（即自动化验证失败），需要立即定位自动化失败的具体原因，避免将变更问题带到线上，以及发布流程的长时间阻塞。基于此，来看看闲鱼交易下的自动化体系建设思路：
1. 自动化测试集设计
编写并选择测试用例是实现自动化验证的核心。合理的用例设计，既保证自动化的效益和可靠性，又便于测试集的维护和扩展。对于业务场景多、操作多样化的闲鱼交易域，在自动化测试集设计上，需要确认的问题是：
• 想要实现自动化验证最大产出，在开始实施时，应该选择哪些用例加入自动化测试任务集？
• 对于预先定义的一组或多组输入、输出数据，自动化结果具备可预测性吗？
基于以上的考量，进行接口链路的编排，并借助接口测试工具来实现交易场景的自动化覆盖。借助集团的定海神针平台，进行链路自动化用例编写，包括以下两个方面：
1) 数据预置
在用例编写前，需要准备有效的测试数据，使用例能够真正地执行起来。不同类型的商品数据、买/卖家用户身份及账号数据、交易资金等都作为生成交易订单的预置数据，需要和用例编写分开，不仅减少用例执行成本，更减少用例之间的耦合度。此方案设计中采用闲鱼测试设计的测试数据构造平台进行数据生成和获取。
2) 用例编写
准备好测试数据后，在编写场景用例时需要注意：
• 合理分解：拆分复杂交易场景和业务逻辑，区分原子场景，避免测试失败时阻断其他功能用例的执行，快速得到测试结果，提高用例执行稳定性。
• 简化用例：根据交易链路节点可复用的性质进行用例简化。例如在场景分解后，验证发货场景时，不需要重复构造订单数据，复用上一节点的订单即可。复杂的执行和校验可能影响发布节奏，给理解、调试和维护带来更大的成本和挑战。
• 多层校验：设计合理的断言，避免由于用例原因造成的随机失败。校验规则覆盖接口契约、订单数据（订单标/订单状态/订单操作）、业务规则各层次。并学会从线上问题里找反思，补充校验点。
• 体现业务特性：了解用户和应用的交互，在用例编写时体现用户使用系统的实际端到端的历程，而不只是自动验收标准的集合，片面强调覆盖率。在交易场景用例中覆盖领域交互的验证，增加对交易状态流转后，买/卖家系统异步消息通知卡片的校验、资金流向校验等。
下图是以闲鱼内基础C2C交易为例，进行业务测试用例拆分：
2. 发布流水线卡点
完成自动化测试用例沉淀后，将接口、链路质量验证能力与应用发布关联。基于变更管控，完成自动化回归验证、发布卡点。利用发布流水线将开发、测试、发布、验证等关键活动串接在一起，没有间断和跳过，流畅优雅。首先简单介绍：
集团内开放Aone平台，提供完整的产品全生命周期管理和协作能力。在应用发布内，Aone整合了产品部署发布、持续集成服务和测试执行实验室，升级流水线能力，关联研发流程中的各个阶段，实现了自动化的构建、部署、测试与发布，确保让代码能够快速、安全的部署到产品生产环境中，提升整个研发体系的效率。
依赖Aone发布流水线能力，可以在Aone发布流程中平稳地支持测试校验，自动触发和运行测试任务：在交易核心应用变更代码部署完成后，自动执行指定的测试任务校验测试，更新用例回归结果并自动决策研发流程的执行，直观体现质量信息。在自动化验证失败时阻断发布，进行100%通过率强卡点，即卡点校验项未通过时，无法继续进行后续的发布流程，若想继续需进行特殊审批。
四、 总结及展望
目前交易链路自动化回归已经覆盖了交易内核心应用的接口质量验证，同时覆盖了基础C2C业务下场景链路质量验证能力。基础C2C交易回归验证由原先的手工耗时半小时、频繁账号切换和点击操作，缩短至一分钟内自动完成，极大减少手工验证的重复性，提供更优的质量保障能力和执行效率。
本着没有适当的测试策略，不给予自动化测试的基本原则，闲鱼交易域内的自动化体系建设，是建立在基建完善的基础上，比如解决了数据构造问题、应用环境隔离、发布流水线引擎的基建统一等，进而助推质量保障、降低发布风险。后续我们将持续推进基建，沉淀更多核心业务场景下的自动化测试任务集，最终实现向用户持续高效地交付价值。
