简介：闲鱼交易品质自动化
背景
闲鱼作为一款垂直交易社区 APP，领有简单多样的业务场景：波及 c2c、回收寄卖、租房租赁、见面交易、验货担保等，复杂多变的交易模式。比方验货流程：
- 波及 39 个状态机节点
- 横跨 10+ 利用零碎
- 波及 6 个业务部门的单干
- 波及接口几十个
须要保障每个接口、每个场景切实可行，略微有一点点问题，就会波及到人民币的滋味，理论工作中，咱们遇到各种各样的问题，比拟辣手的问题如下：
问题
业务先赢的疾速迭代模式下，全靠人工主力进行测试验证，测完新性能，还得回归老性能，一个小需要也须要好几个人日，版本 PTM 也要回归好几遍，ROI 并不乐观，以下 2 个问题比较突出：
- 交易业务强依赖中台，沟通老本高，跨团队合作难，迭代效率低，测试环境下如何自洽？
- 简单多样交易模式下，如何撑持需要稳步迭代上线以及日常回归验证？
测试策略 - 自动化
闲鱼品质基建正在快马加鞭进行中，针对闲鱼多样的交易模式，全靠人力是不可行的，累不说，改变、危险漏评估也时有发生。对此，咱们依据接口 -> 链路的策略，摸索比照了几个不同的计划，在保障每个接口 OK 的根底上，保障全链路。
接口层
对于每一个大型应用程序来说，接口数量会一直减少，代码变更频率越来越大、零碎不定期重构，这个接口的品质怎么来保障？传统编写脚本来进行的形式，投入的人力、工夫老本过大，在理论的测试过程中咱们摸索了一些接口测试的新想法。目前业界公认的无效形式是基于引流回放的自动化测试，实现计划业内七嘴八舌各有其词，但万变不离其中，援用上面这段总结，简单明了
一种是黑盒测试思路，它在线上接口申请时采集线上流量（次要是申请参数和后果），而后应用和线上环境雷同的环境（数据库共用等）下用采集到的流量从新触发申请，而后断言被申请的返回值是不是和录制时的统一。这种办法比拟适宜对 Get 类型的接口进行测试，而对于写操作的申请容易造成数据净化，再加上所采集流量的数据状态（数据时效性）、环境依赖性（各种中间件、接口外部申请的 RPC 调用）等因素，所以这种测试形式具备一些局限性，不能满足理论测试场景中简单的需要。
另一种思路绝对白盒，次要是通过智能化的 Mock 伎俩，流量采集时采集代码运行过程中所依赖的内部中间件或者 RPC 调用的返回后果，当流量回放时，可能 Mock 本机程序对外的依赖中有可能产生变动的内容，使测试更关注本地接口的代码逻辑。
阿里团体外部，基于流量回放的思维，次要实现了 2 种不同的流量录制回放计划，一种是基于 doom 的天启 / 暴雪，一种是基于 JVM-Sandbox 的凤凰，两种实现都借力于 JVM AOP。
- 天启 / 暴雪
天启 / 暴雪，其底层采纳的是 doom 进行流量录制，其原理如下
doom 原理图
次要流程是：
- 通过 Java agent 挂在 JVM 中的 client 以 ASM 的 AOP 形式采集主调用（采集或回放时的入口办法）的入参、返回值、子调用（利用执行过程中的一次办法调用，采集机器会采集该办法的入参和返回值用于回放时执行到该办法进行 mock）的入参和返回值，而后将采集到的数据上传至 server（离线模式）；
- 回放时，client 收到接口回放申请后，会执行该接口的本地逻辑，对于子调用则用采集的入参和后果进行 mock；
- 将采集的流量和回放的后果数据进行比照。
doom 形式，业务利用零碎须要引入 Jar 包，批改启动类，批改 JVM 挂载 agent，有局部的业务侵入性。
- 凤凰
凤凰，也是采纳 JVM AOP 实现的流量录制计划，理念和 doom 差不多，凤凰整体架构底层基于 JVM-Sandbox（阿里开源的一款 JVM 平台非侵入式运行期 AOP 解决方案，通过字节码加强实现办法级别的 AOP 性能）输出模块原子能力。录制时，记录了产生调用的办法，入参、返回值和调用产生的程序，以链式数据结构存储，回放时进行接口逻辑执行和子调用 mock。<br /><br /> 凤凰录制回放 <br /> 凤凰无需代码侵入批改，不须要批改利用启动参数，相对来说，对业务代码影响小，然而有利用构造要求。思考老本和危险，以及咱们的利用构造，闲鱼采纳基于 Sandbox 的凤凰流量录制回放进行保障，变更上线流程卡点。<br /> 研发过程中，也会遇到各种各样的流量回放问题，比方用例过期，须要人工分明从新录制。咱们当初是采纳定时工作主动革除从新录制的形式解决。<br /> 上面是咱们的一个场景例子：<br /><br /><br />链路层
在基于流量录制、回放比对的接口测试过程中，咱们发现这种机制对于单利用的品质保障比拟实用，然而对于跨利用的链路验证、外围写操作、外调用，以及零碎重构类、计划革新等大需要就有些有余，链路级的解决解决方案接踵而至。
- Thub + 微服务
测试环境下，对于全链路上下游的强依赖，措施之一是开发测试服务化能力，建设自洽能力，测试环境下解藕对于外界诸如交易中台、菜鸟裹裹的依赖，测试环境能进行全链路闭环。
落地首要任务是梳理业务全链路节点：
- 骨干链路上的每一个 MTOP 接口，以及接口的上下游依赖
- 外部利用、中台利用、内部商家的依赖
- 数据流以及 TDDL 梳理
业务梳理残缺，进行测试服务化接口开发。上面是咱们截取的一部分链路 case：
同时，诸如测试环境因为依赖方测试环境不稳固 block 测试的状况，咱们提供测试服务化接口进行封装，裸露成下单、验货等服务化能力内置于闲鱼品质平台，用于开发、测试在研发过程中应用。
- 天算平台
天算平台，利用影子库，全链路压测的模式，线上业务数据和测试数据隔离，测试库 copy 线上库一部分数据。次要实现的形式是将线上的场景进行固化仿真，全链路执行，并且在执行的过程中进行所有数据变更的比对，用户能够抉择任何代码版本的基线和变更版本进行比照。
大抵流程
天算能力根本能满足闲鱼的交易链路，闲鱼建设了主链路相干影子库，影子链路正在调试中，用于交易服务端的全链路巡检。同时，影子链路有诸如业务变更导致影子数据过期的问题，这个计划则次要是用于业务比较稳定的业务，新业务或者一直迭代更新的业务并未 all in 这个计划。
总结
综上，目前闲鱼交易，接口层用基于 jvm-sandbox 的流量录制计划, 日常巡检利用影子链路，研发过程自测、链路自动化用业务编排服务化能力。
瞻望
在基建欠缺的根底上，咱们将持续摸索 flutter 以及服务端的全端智能化方向的测试解决方案，心愿让更多技术小二从重复劳动中释放出来，从治、防、控，三层品质网，保障闲鱼交易，让用户在闲鱼释怀的卖卖卖、买买买。期待和大家一起交换业内的不同测试计划！同时感激 doom、sandbox、凤凰、天启、暴雪、全链路压测、Thub 等团队提供的能力反对！
原文链接
本文为阿里云原创内容，未经容许不得转载。