51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 765|回复: 0
打印 上一主题 下一主题

[转贴] 交易链路自动化回归,半年经验总结

[复制链接]
  • TA的每日心情
    擦汗
    13 小时前
  • 签到天数: 1048 天

    连续签到: 1 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-8-3 10:10:34 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    背景
      闲鱼交易链路作为应用中关键链路的一环,具有多业务、多状态、多操作的特征。以订单操作举例:不同的订单类型、订单状态包含不同的操作;不同操作下触发的业务行为、领域服务的交互行为也各不相同。
      问题
      交易链路质量稳定性保障的测试难点包括:
      改动点涉及的业务范围广、评估难度高:
      交易承接着10余种复杂多样的业务场景和交易模式,一次改动往往涉及所有业务场景的验证。更糟糕的是,一次看似不起眼的线上开关值变更,往往依赖业务经验来评估其影响范围,给业务验证和变更带来巨大风险。
      新老链路需要双重保障:
      链路上的数据结构变动,需要保障新老版本下调用链路切换的问题。
      交易链路上订单标的正确性:
      一笔交易订单主订单上就有超过100个标;这些订单标以及根据这些标衍生出的业务场景如何快速校验?
      带着这些问题,闲鱼交易链路自动化回归采用接口+链路的验证,在应用交付的全生命周期内,在发布流水线中不断运行自动化测试,保障全链路,把控发布质量,成为应用真正上线的最后一道防线。
      方案说明
      通过接口流量录制回放、定海神针场景链路验证的方式,形成自动化测试任务集,在交易核心应用发布过程中,新增发布流水线的测试验证节点,当应用完成安全生产环境部署后,自动化触发执行关联的测试任务。 测试任务执行后,验证当前的自动化结果情况、应用核心测试集校验情况。根据应用预先配置的卡点阀值来判断卡点校验是否通过。如果卡点校验通过,则可以继续进行后续的发布流程。如果卡点校验未通过(即自动化验证失败),需要立即定位自动化失败的具体原因,避免将变更问题带到线上,以及发布流程的长时间阻塞。 基于此,来看看闲鱼交易下的自动化体系建设思路:

    自动化测试集设计
      编写并选择测试用例是实现自动化验证的核心。合理的用例设计,既保证自动化的效益和可靠性,又便于测试集的维护和扩展。对于业务场景多、操作多样化的闲鱼交易域,在自动化测试集设计上,需要确认的问题是:
      1. 想要实现自动化验证最大产出,在开始实施时,应该选择哪些用例加入自动化测试任务集?
      2. 对于预先定义的一组或多组输入、输出数据,自动化结果具备可预测性吗?
      基于以上的考量,进行接口链路的编排,并借助接口测试工具来实现交易场景的自动化覆盖。借助集团的定海神针平台,进行链路自动化用例编写,包括以下两个方面:
      数据预置
      在用例编写前,需要准备有效的测试数据,使用例能够真正地执行起来。不同类型的商品数据、买/卖家用户身份及账号数据、交易资金等都作为生成交易订单的预置数据,需要和用例编写分开,不仅减少用例执行成本,更减少用例之间的耦合度。此方案设计中采用闲鱼测试设计的测试数据构造平台进行数据生成和获取。

    用例编写
      准备好测试数据后,在编写场景用例时需要注意:
       **合理分解:**拆分复杂交易场景和业务逻辑,区分原子场景,避免测试失败时阻断其他功能用例的执行,快速得到测试结果,提高用例执行稳定性。
       **简化用例:**根据交易链路节点可复用的性质进行用例简化。例如在场景分解后,验证发货场景时,不需要重复构造订单数据,复用上一节点的订单即可。复杂的执行和校验可能影响发布节奏,给理解、调试和维护带来更大的成本和挑战。
       多层校验:设计合理的断言,避免由于用例原因造成的随机失败。校验规则覆盖接口契约、订单数据(订单标/ 订单状态/ 订单操作)、业务规则各层次。并学会从线上问题里找反思,补充校验点。
       **体现业务特性:**了解用户和应用的交互,在用例编写时体现用户使用系统的实际端到端的历程,而不只是自动验收标准的集合,片面强调覆盖率。在交易场景用例中覆盖领域交互的验证,增加对交易状态流转后,买/卖家系统异步消息通知卡片的校验、资金流向校验等。
      下图是以闲鱼内基础c2c交易为例,进行业务测试用例拆分:

    发布流水线卡点
      完成自动化测试用例沉淀后,将接口、链路质量验证能力与应用发布关联。基于变更管控,完成自动化回归验证、发布卡点。利用发布流水线将开发、测试、发布、验证等关键活动串接在一起,没有间断和跳过,流畅优雅。首先简单介绍:
      集团内开放
      Aone平台,提供完整的产品全生命周期管理和协作能力。在应用发布内,Aone整合了产品部署发布、持续集成服务和测试执行实验室,升级流水线能力,关联研发流程中的各个阶段,实现了自动化的构建、部署、测试与发布,确保让代码能够快速、安全的部署到产品生产环境中,提升整个研发体系的效率。

    依赖Aone发布流水线能力,可以在Aone发布流程中平稳地支持测试校验,自动触发和运行测试任务:在交易核心应用变更代码部署完成后,自动执行指定的测试任务校验测试,更新用例回归结果并自动决策研发流程的执行,直观体现质量信息。在自动化验证失败时阻断发布,进行100%通过率强卡点,即卡点校验项未通过时,无法继续进行后续的发布流程,若想继续需进行特殊审批。

    总结及展望
      目前交易链路自动化回归已经覆盖了交易内核心应用的接口质量验证,同时覆盖了基础C2C业务下场景链路质量验证能力。基础C2C交易回归验证由原先的手工耗时半小时频繁账号切换和点击操作,缩短至一分钟内自动完成,极大减少手工验证的重复性,提供更优的质量保障能力和执行效率。 本着没有适当的测试策略,不给予自动化测试的基本原则,闲鱼交易域内的自动化体系建设,是建立在基建完善的基础上,比如解决了数据构造问题、应用环境隔离、发布流水线引擎的基建统一等,进而助推质量保障、降低发布风险。后续我们将持续推进基建,沉淀更多核心业务场景下的自动化测试任务集,最终实现向用户持续高效地交付价值。





    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-18 22:48 , Processed in 0.067118 second(s), 24 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表