编写并选择测试用例是实现自动化验证的核心。合理的用例设计，既保证自动化的效益和可靠性，又便于测试集的维护和扩展。对于业务场景多、操作多样化的闲鱼交易域，在自动化测试集设计上，需要确认的问题是：
通过接口流量录制回放、定海神针场景链路验证的方式，形成自动化测试任务集，在交易核心应用发布过程中，新增发布流水线的测试验证节点，当应用完成安全生产环境部署后，自动化触发执行关联的测试任务。测试任务执行后，验证当前的自动化结果情况、应用核心测试集校验情况。根据应用预先配置的卡点阀值来判断卡点校验是否通过。如果卡点校验通过，则可以继续进行后续的发布流程。如果卡点校验未通过，需要立即定位自动化失败的具体原因，避免将变更问题带到线上，以及发布流程的长时间阻塞。基于此，来看看闲鱼交易下的自动化体系建设思路：
带着这些问题，闲鱼交易链路自动化回归采用接口+链路的验证，在应用交付的全生命周期内，在发布流水线中不断运行自动化测试，保障全链路，把控发布质量，成为应用真正上线的最后一道防线。
在用例编写前，需要准备有效的测试数据，使用例能够真正地执行起来。不同类型的商品数据、买/卖家用户身份及账号数据、交易资金等都作为生成交易订单的预置数据，需要和用例编写分开，不仅减少用例执行成本，更减少用例之间的耦合度。此方案设计中采用闲鱼测试设计的测试数据构造平台进行数据生成和获取。
准备好测试数据后，在编写场景用例时需要注意：
用例编写
•合理分解：拆分复杂交易场景和业务逻辑，区分原子场景，避免测试失败时阻断其他功能用例的执行，快速得到测试结果，提高用例执行稳定性。•简化用例：根据交易链路节点可复用的性质进行用例简化。例如在场景分解后，验证发货场景时，不需要重复构造订单数据，复用上一节点的订单即可。复杂的执行和校验可能影响发布节奏，给理解、调试和维护带来更大的成本和挑战。•多层校验：设计合理的断言，避免由于用例原因造成的随机失败。校验规则覆盖接口契约、订单数据、业务规则各层次。并学会从线上问题里找反思，补充校验点。•体现业务特性：了解用户和应用的交互，在用例编写时体现用户使用系统的实际端到端的历程，而不只是自动验收标准的集合，片面强调覆盖率。在交易场景用例中覆盖领域交互的验证，增加对交易状态流转后，买/卖家系统异步消息通知卡片的校验、资金流向校验等。
方案说明
数据预置
发布流水线卡点
下是以闲鱼内基础c2c交易为例，进行业务测试用例拆分：
总结及展望
基于以上的考量，进行接口链路的编排，并借助接口测试工具来实现交易场景的自动化覆盖。借助集团的定海神针平台，进行链路自动化用例编写，包括以下两个方面：
自动化测试集设计
交易链路质量稳定性保障的测试难点包括：
想要实现自动化验证最大产出，在开始实施时，应该选择哪些用例加入自动化测试任务集？对于预先定义的一组或多组输入、输出数据，自动化结果具备可预测性吗？
集团内开放Aone平台，提供完整的产品全生命周期管理和协作能力。在应用发布内，Aone整合了产品部署发布、持续集成服务和测试执行实验室，升级流水线能力，关联研发流程中的各个阶段，实现了自动化的构建、部署、测试与发布，确保让代码能够快速、安全的部署到产品生产环境中，提升整个研发体系的效率。
改动点涉及的业务范围广、评估难度高：交易承接着10余种复杂多样的业务场景和交易模式，一次改动往往涉及所有业务场景的验证。更糟糕的是，一次看似不起眼的线上开关值变更，往往依赖业务经验来评估其影响范围，给业务验证和变更带来巨大风险。新老链路需要双重保障：链路上的数据结构变动，需要保障新老版本下调用链路切换的问题。交易链路上订单标的正确性：一笔交易订单主订单上就有超过100个标；这些订单标以及根据这些标衍生出的业务场景如何快速校验？
文章为作者独立观点，不代表股票交易接口观点
股民评论