背景当业务任务多且人力资源不充足的情况下，不同业务的同学可能需要去不同的业务进行临时支援，可能在时间方面可能有长有短，但是如何迈出第一步是很多人需要关心的一件事。本文以实际跨业务测试经验（订单业务测试人员如何测试售后业务），讲述在两周内如何快速的上手售后业务并进行测试需求，写下此篇文章作为经验分享。在转业务之前，我在交易订单促销回收单业务，那么先简单介绍一下订单业务。其目的在于了解一下订单和售后之间的关系。订单涵盖的内容非常广泛，从商品加购，再到确认下单页，再到下单，整个订单流程，包括正向订单流程以及逆向订单流程等多场景。外部对接B2C，C2C，B2B，POP，3C等诸多业务。内部对接基础服务，商品，支付，物流，仓储，售后等业务。日常测试中，可能也或多或少的了解了售后的一些后台操作步骤或流程。从而对测试售后业务有一定的基础流程上的了解。

例如：占用资源时间长的操作，允许适当延迟的操作，最好使用异步经常访问的数据做好缓存：内存初始化/存放Redis，缓存更新批量查询场景是否需要设计分页，分页条件和break结束是否生效d.

xxxx_server可用xxxx服务查看命令，这个也是别名如第3点），并执行上面拼接的debug路径，就可以开始debug了5、总结1）快速定位找到问题解决

背景电商行业，整个购物流程，离不开跟钱打交道，系统内也是门门道道，例如打款，对账等等业务，一旦涉及到钱的业务出现问题，都有可能造成严重的线上事故。这部分的测试验证存在很多痛点，验证的过程主要依靠人工校验，涉及多个系统查询比对，耗时较长；此外在跨部门协作项目中，常常由于彼此对专业术语理解不一致，导致沟通成本较高。本文重点分享转转QA在涉及钱款方面的业务场景测试中是如何解决上述测试痛点的？我们为什么要设计一套涉及打款校验的工具？它在实际应用中效果如何？需求分析1、业务现状在进行工具开发之前，我们首先针对目前线上回收的业务现状进行了梳理整合，其中涉及到打款的核心业务有三部分，这里以回收1、回收2、回收3代替。回收1和回收2业务的打款类型主要有：A类出款和B类的出款。其中，A类的出款又包含各种加价和补贴，这些不同的出款类型都对应不同的账户。目前线上回收业务有15+条业务线，每条业务线对应的账户配置信息都不相同。回收3业务对应的打款类型更复杂一些，有售出、A类出款、B类出款三大类，都有不同的抽佣计算逻辑，而且还有不同回收类型相互转换的场景。测试过程中除了要覆盖到业务场景之外，账户的核对也是一项非常耗费精力的工作。2、需求调研经过沟通发现门店侧对于打款相关的验证也有同样的痛点，所以我们将线上回收和线下门店涉及到的打款场景和校验内容进行初步调研，结果如下图：从图中可以看出我们测试打款相关的需求时，重点关注的内容主要是账户、打款金额和计算公式等这些关键信息，针对这个结论我们明确了打款工具的需求设计。3、需求设计打款校验工具核心功能主要包含以下三部分：（1）展示回收单和订单基本信息主要返回订单或回收单的状态、订单编号、业务线等关键信息，方便快速定位问题。（2）关键信息的结果比对返回所有对账记录的预期结果和实际结果，例如：打款类型、账户、金额等关键数据展示到页面上，及预计结果与实际结果的比对结果。一方面可以直观的看到各条记录的结果，另一方面也能看到每条记录的校验结果，可以快速定位校验不通过的数据。（3）对账明细每一条打款明细点击可以展开详细的计算过程，含文字的计算公式说明及各个字段的计算过程取值，不了解业务的人也可以通过说明快速上手了解计算过程，计算结果有差异的可以更快速的定位问题。系统设计1、系统框架系统整体设计分为三层：前端UI层、展示层、业务层。前端UI层：主要是前端页面的渲染。展示层：主要是页面基本信息的获取。业务层：对账打款逻辑实现，整合订单、回收单、售后服务的信息，作为基础信息来源，进行各个价格计算，然后进行对比校验，并返回比对的结果。核心功能1、打款信息校验用户在前端页面选择业务线和场景后，输入订单id或者回收单id，首先调用中台接口拿到订单的关键信息，作为基础数据进行预期结果计算，用支付结果作为实际运行结果，两者进行比对。如果一致则校验通过，反之则校验失败。核心校验逻辑：根据不同的业务线来设定不同Map的key值，从中台获取到实际结果list和自己计算的预期结果list转换为两个Map，遍历Map中的值并塞入新的Map中，再将需要对比的金额、收支、账号进行对比输出对比结果。一个Map遍历完之后再对另外一个Map进行遍历，返回结果为两个Map的合集。2、泛化调用打款工具上线后，如果服务之间是通过普通的接口调用方式进行通信的，无论是调用方还是服务方请求都只能发送到线上，我们也就只能校验线上的数据。在实际测试过程中，不仅需要校验线上环境的真实单据信息，还要校验测试环境的打款信息。所以，我们通过泛化调用的方式指定调用方和服务方的运行环境，从而在线上也能请求到测试环境的服务和数据。如图所示，用户先在前端选择服务方ip，并发送http请求给web层，web层获取到前端用户发送的请求后，调用zzjava_test服务的接口，zzjava_test又调用zzjava_scf服务的接口。具体是怎么实现的呢？首先，指定服务名、接口名、方法名、参数类型和参数值等；然后，指定zzjava_test的运行环境，并把服务方ip指定为zzjava_test的目的ip；最后，通过对zzjava_test服务中的接口进行泛化调用，将请求发送给目的ip中的zzjava_scf服务。提效效果1、人工校验在开发校验工具之前，校验方式主要是根据所测场景自行计算出抽佣和打款金额，再和交易工具箱中查询到的结果一一进行比对。2、自动校验有了校验工具之后，只需要输入订单或回收单就可以自动地计算出各项打款记录和比对结果，省去了我们在多个系统中查询和手动计算的过程，对于不了解业务抽佣规则的同学来说更是省去了了解的成本，大大提高了测试效率。3、项目中的应用打款工具的目的就是为了在日常的测试工作中帮助我们提高效率，现在距离上线已经一个多月，目前已经在以下几类项目中得到实践，详细使用情况如下：（1）扩品类需求品类扩充，抽佣打款信息需要回归，线上功能可以直接使用，提高了测试效率。（2）计算逻辑变更需求代码兼容开发后，并推给RD自测使用，简化了测试过程，提高了效率。（3）打款类型多的需求品类多、账户多、流程多打款类型多，利用打款工具做了基础校验，项目上线后补充完成所有校验。展望打款工具的应用场景应该不仅仅只在我们单个业务中，可以应用于涉及订单&打款相关的其他业务。打款工具校验的内容也可以更加丰富，提高打款测试效率的方法也不止这一种，更希望借此可以抛砖引玉，发现更多好的方法来帮助我们日常工作提效。想了解更多转转公司的技术实践，点击关注下方的公众号吧！

1、zzcase嵌套另一个平台页面，动态加载页面和数据，存在响应慢的问题2、zzcase调用自动化平台接口数据存在不稳定性，需要动态加载3、脑图用例页面暂时不支持进行接口调试后续计划

作者：邹德龙编稿：庄锦弟前言：要做好UI自动化测试，做好元素定位很重要，也经常收到反馈说定位难，但是有些东西是可以提炼出来共同点的。接下来简单看看android和ios可以分别怎么定位，以及实践UI自动化以来提炼的思想：一、Android定位前置：

作者|孙敏背景随着业务的发展，转转除了转转APP外，开发了越来越多的独立APP去满足业务；作为转转最早的客户端团队，除了满足自身业务需求外，也需要提供公司级通用的APP持续交付基础能力。可快速扩展到其他APP使用，提高整体工作质量和效率。鲁班在持续交付的整体流程中，主要承担：APP版本流程、包构建、APP专项测试等能力。鲁班的构建管理APP的持续交付尽可能的将整体项目流程串了起来。开发阶段的代码分支由beetle进行管理，详见文档《转转客户端持续集成--分支管理》本次主要给大家分享鲁班的包构建管理相关能力。开发测试阶段，包构建频次非常高，整个阶段经历：提测-测试-修复-测试的一个反复过程，构建管理提供了这个环节的基础能力，需要提供稳靠，尽可能自动化，减少人工重复消耗的能力。结合背景和我们的目标需求，在设计鲁班的构建管理模块时，主要包含了以下几个点：1、通用性，可扩展构建能力不仅仅是给转转APP，需要可快速扩展到公司其他APP；并支持各业务自定义自己的打包脚本。构建脚本将通用配置和脚本内容提供公共打包模板，提供可视化的操作，方便用户操作。满足基础的构建要求。除了公共构建参数外，又提供了自定义的扩展参数，便于各业务在基础构建脚本外扩展自己的业务逻辑。2、构建参数模板化鲁班支持将不同参数组成一个个构建模板，方便构建人员根据不同的场景打出不同用途的包。除了提供的基础测试包、发版包外，支持各业务根据自己的需求定制个性化的构建模板。模板可以简化构建填写内容，有效避免人为填写出错等情况。通过模板，可减少用户操作，只填写可变的部分，避免一些关键信息填写错误的问题出现。3、触发构建机制目前触发机制有两种：自动触发或手动触发自动触发：开发提交tag自动触发，减少人的介入手动触发：包括开发在beetle上触发编译操作或在鲁班平台上手动构建需要的包beetle上编译触发：和整体开发流程结合，只构建有效版本，避免一些不必要的tag过多占用构建资源鲁班平台构建：适用需要特殊场景的包，手动创建两种方式，满足了各业务的不同的场景需求，根据自身业务特性去选择触发方式。4、构建结果数据存储包含构建历史和打包结果的存储。分别记录构建信息和打包结果的信息，结果可查询，另外会存储包大小等信息，可生成报表查看阶段包大小变化等。构建结果存储为二维码，方便用户扫码安装。5、串联发版能力当选择发版模板时，会触发android和ios的发版功能，自动完成发版操作发版的同时保存版本数据结果，记录版本历史节点，便于后续版本追溯。其他构建管理还关联了APP的一些自动化、检查项等配置。例如静态代码扫描，冒烟，UIcase等，本次就不详细介绍了。后续静态代码扫描等基础能力进一步完善后，会设定指标对整体APP的流程做一个控制，对APP的交付有一个准入准出规范标准。

作者|庄锦弟背景原ZLJ卖场的压测流程，是依托于阿里云PTS工具，团队自身缺乏性能测试能力自建，缺少性能分析和数据沉淀，测试场景单一，只有单接口和多接口压测，缺少场景和链路压测，不能相对合理的评估系统性能承载能力，机器扩容只凭借经验进行增加调整，缺乏评估依据。什么是全链路压测当接手ZLJ卖场所有业务性能测试后，重新调整性能测试流程和规范，每个项目进行登记，不再是单一接口压测，都需要制定对应的压测场景，后续在双十一、双十二大促的时候，也把全链路压测场景补充进来。在此之前，自已也有了解过一些大厂的全链路压测相关资料，感觉大同小异，差不多都是根据业务特性进行全场的压测，各场景流量大小配置，数据模型，性能分析等等。业内通用标准：基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。要精准衡量业务承载能力，全链路压测就需要做到保持跟生产环境一样：用户规模、业务场景、业务量级和流量来源，目的是让服务系统提前进行峰值承载能力演练，从而达到精准衡量业务实际处理能力的目标，其关键核心：压测环境、测试数据、压测流量（模型）、流量发起、问题定位、分析并调优。介入全链路压测的时机在可以预期的一段时间（如双十一、双十二），业务会有较快速的发展，线上机器必须要大幅度扩容机器扩容以倍数增长，评估机器性能是否翻倍继续扩容后，服务能力不一定翻倍增长，有可能会受限于其他的依赖关系，如

自动打包并检测版本分支是否落后关联的功能分支，检测到落后情况会进行微信通知测试通过，开始灰度灰度完成，上线成功，合回master分支新问题

diff作为第一个工具。下图是工具实现的一个简单流程图：以下是工具实际页面的截图：接口列表页：接口新增页：diff结果页：基于视觉效果的UI自动化：HTTP

diff文件的所有提交人（当然如果可以精准到问题内容的直接提交人就更好了，嘿嘿～自己的问题，当然要自己解决了，甭想赖掉哦)。当然，RD同学辛辛苦苦的优化了一些问题，如果有删除、修改

作者|侯盼林初识测试不知不觉，我在测试部的实习已经快三个月了，入职第一天的场景仿佛还在昨天。在实习之前，我对测试的认识仅仅停留在一些软件测试和测试方法的理论知识上，在学生阶段项目中的测试，最多也是对自己的代码进行一些单元测试。我之前所理解的测试是与开发分开，测试人员只需要“鼠标点点点”，根据需求寻找bug，不需要写代码、看代码。然而，通过项目实践，我对测试工作有了真正的认识和见解，认识到测试前置的重要性，依据W测试模型，在需求和设计阶段就介入测试，尽早发现缺陷，如需求文档、设计可行性，也需要提前编写接口用例，例如在测试交易链路时，提前设计用例以覆盖链路的每个分支。除此之外，还需要深入代码的设计逻辑才能更好地测试。项目实践与成长实习第一周，安装测试常用软件和平台，做好测试前的预备工作：Xmind：思维导图软件，用于编写测试用例。SwitchHosts：hosts管理利器，用于管理、快速切换Hosts小工具。Fidder：抓包工具，将手机的网络设置手动代理，连接电脑端的IP与端口，可以抓取手机访问的URL以及一些参数。注意，要抓取https请求时需要安装Fiddler证书，下载方式“http://电脑IP:端口”。Fidder与SwitchHosts一般配合使用。Git、SourceTree：在gitlab上下载分支，使用SourceTree切换分支。IDEA、Maven：使用IDEA配置Maven，导入gitlab上的项目。Xshell：访问远端的服务器，主要进行一些日志的查看，学会日志查看的相关命令，如tail、grep等。TestNG：用于单元测试，学会常用注解。例如，@Test、@BeforeTest、@AfterTest、@DataProvider。TAPD平台：敏捷项目管理平台，用于创建需求、项目跟进、提交bug等。环境管理平台：用于申请环境、管理机器、管理服务调用关系。Beetle平台：转转测试部主导研发的CI/CD分支管理平台，集成了code

作者|赫英明近几年直播迅速崛起，电商直播相较于传统的图文卖场具有互动社交属性，其优点是流量转化率高，可以让观众充分了解商品，所以直播已经成为电商业务的重中之重。转转自6.9版本上线直播功能，首先将文玩玉翠作为直播的第一批类目，上线后有显著效果，后续又扩展到手机，奢侈品等，推出直播间鉴定能力，为用户提供更加全面的直播服务。业务介绍首先介绍下整个直播的架构，直播简单来说，就是录制->编码->网络传输->解码->播放的过程，主播端负责推流，观众端负责拉流。转转的直播是使用Native的直播基础能力+M页面提供业务能力的形式，Native给用户带来更好的直播体验，M页更方便业务拓展。下图是转转直播主播开播和观众进入直播间的流程图：测试重点现在市场上绝大多数直播间，大致可以分为三个关注点，直播流，直播间消息，直播间业务功能。这三点也是转转直播测试最重要的测试点。1、直播流，我们需要关注以下几点：秒开展示直播页面(1s左右)，清晰度(流畅，标清，高清)的切换，网络状况，切换对于流的影响，直播的延迟等，以及异常断流，来电等特殊情况的考虑。2、直播间消息，使用IM进行发送，主要有两部分，一是直播间弹幕消息，二是直播间展示信息，例如：直播间观看人数，点赞数等，对于其边界情况需要特别注意，因为会产生UI和功能上的问题，对于直播间弹幕要关注弹幕的滑动以及弹幕数量的并发、弹幕对于直播间商品卡片的影响等。3、直播间业务，首先要完成PM的需求，其次还需要关注需求对于直播间基础功能的影响，比如分享直播间到微信后再回到直播间是否会出现断流的情况，以及观众或主播点击跳转到全屏M页面，其直播流的处理；正在观看直播的观众进入到短视频时，两个视频流的处理逻辑等等。解决方案我们的解决方案，也是主要针对上面三个测试重点进行的。1、直播流解决方案，目前还是使用人工的方式去检查和回归，就现在来看回归成本不是特别大，不过这部分的自动化测试已经提上日程。2、直播间消息，测试难点主要是直播间消息无法模拟，直播间内的消息是socket消息，其不像接口数据，可以修改返回值，从而可以关注直播间前端的展示逻辑和样式。所以我们需要测试人员自己主动发送和控制消息，这样就可以覆盖到更多场景，比如：直播间观看人数过多、点赞数过多等对于Native的展示问题弹幕的数量，我们正常发送弹幕最快估计也要一秒一条，但是大量的弹幕并发，对于测试人员来说不是很好模拟。所以急需一个可以发送直播间消息的服务，于是开发了一个模拟向直播间发送消息的功能，可以很方便的模拟场景和构造直播间消息数据。3、直播间业务流程，对于基本和复杂的场景，开发了直播间的数据构造，例如：将一个普通用户变成一个主播、修改直播间的状态、发送直播间的商品等，这些数据构造现在已经满足我们日常测试的需要，提高了测试效率。针对于直播间内的M页，因为我们的M页是主要承接业务的，所以M页的质量也非常重要，项目前期会出现修改直播间外的M页功能影响直播间内的M页，或者底层方法的修改对直播间内M页产生影响，这些都是我们不能接收的。针对这些问题，我搭建了一套基于Python+Pupptter框架的前端自动化巡检，针对直播间内的M页项目，在其上线时，触发任务自动化检查，主要检查：直播间内M页是否有空白页，M页的基本展示，输入框的输入以及按钮的点击等，从而提高直播间内M页的质量。后续优化加强对Native的自动化测试，包括直播流的检测，以及直播基础能力的检查。接口层测试比较弱，需要对单接口进行更多测试，积累更多接口测试场景，从一个单接口变成一个测试场景，实现接口自动化流程，从而提高整体直播质量和效率。往期精彩回顾App测试，安装包走过的一生RPC服务接口测试自动化初探H5页面多端兼容测试与监控移动端自动化测试-远程设备调度电商业务测试方案与实战落地（转转）IOS远程真机控制实践Java字节码增强技术介绍RPC服务测试新思路MQ消息构造--学会分解问题浅谈IM与相关测试方法CodeDiff实现方案简述抓包工具wireshark的使用移动端H5性能测试平台(上)欢乐送小程序自动化探索实践1分钟了解转转小程序测试体系转转测试环境平台解决方案效能提升的江湖路--转转Beetle平台百天记Xmind

作者|申言方引言目前测试行业提起接口自动化测试，一般都默认是HTTP/HTTPS接口自动化测试，我想主要原因有两点：1、HTTP/HTTPS请求比后端服务更贴近实际用户；2、Java、Python都有丰富的第三方扩展，可以方便快速的搭建一套HTTP/HTTPS测试框架，并且还可以拓展到功能回归、线上监控等场景。近些年微服务的兴起让更多的人了解到RPC框架，当然不同的RPC框架，在设计、实现和使用上存在巨大差异，这也让RPC服务在接口测试方面具有一定的难度，针对每一个RPC接口都编写对应的测试代码是最直接的方式，在实际实施过程中会有两个主要问题：1、测试代码需要花费大量时间开发，容易拉长项目节奏；2、测试代码需要大量人力来维护。在本篇文章中，我们交流一下在RPC服务接口测试的自动化方向上的一些尝试。整体流程在实现RPC

前言H5自动化测试的往期分享《基于图片比对的UI自动化测试在运营系统中的应用》中，提到如何通过selenium+chrome(headless)测试框架进行H5页面的轻量级自动化回归测试；但是在效果显著，释放部分人力的同时，小编发现chrome始终不是真实的运行环境，有些H5页面问题无法通过此种测试手段完全暴露，比如最常见的问题：在转转app端内展示没有问题，但是投放到其它端会出现样式兼容问题、以及不同手机分辨率下页面内容样式存在展示异常等问题，显然通过往期我们介绍的方案已无法完全满足测试需求。思考基于以上问题，很显然我们需要将H5页面在真实运行环境上实施自动化测试，并期望达到：

Store。怎么让人在整个流程中解放？优化思路不变，工具能自动实现的，就别人工做了。iOS比较简单，使用xcode提供的工具命令直接上传到App

自动化任务可能有因误操作/临时任务变动/设备急用等需要立刻中断设备占用&中断自动化执行的情况出现，所以需要MCP提供中断自动化任务接口，及时结束正在执行的自动化任务、释放设备。任务分工：

作者|田西西测试方案首先要了解业务特性、测试痛点，才能定制合理的测试方案，使得方案即可以满足当前业务形态的测试，又满足对未来可期需求的支持甚至对未来系统重构做提前打算。对于微服务架构的系统也有个比较初始的阶段，虽说不是all

作者|赵新源简介移动端的远程控制是为了将手机资源更好的分配，提高利用率，可以提供给用户更丰富的选择。现阶段我们完成了Android的stf搭建，并做了一些二次开发，以适应我们的移动端管理平台（MCP）。在IOS方面，由于相关技术一直比较封闭，没有非常成熟的开源技术可供选择，所以我们经过一段时间调研以及试错，还有客户端组同学的帮助下，完成了IOS远程控制的基本功能，目前可以提供给用户使用。方案调研远程控制就是用户通过浏览器实现远程ios设备的查看和操作，所以我们有以下几个主要目标：远程真机画面可以实时在用户浏览器上流畅显示用户可以在浏览器上实时操作远程真机提供常用的功能以方便用户便捷使用（比如实时日志和安装应用）尽可能的减少硬件资源占用

agentArgs);agentArgs为命令行中options的内容，代理中通过agentArgs获取options中的内容来获取配置信息，并根据配置的内容执行配置对应的逻辑。2）Manifest

作者|申言方引言为了保证RPC服务的稳定，最大可能的防止BUG带到线上，测试过程中对RPC服务做接口测试是必要的步骤。目前的通用做法是在测试框架中引入被测服务的contract

作者|赵力新各位亲爱的朋友，本文小编将抛砖引玉，谈一谈在工作中遇到问题的处理思路，希望给遇到迷惑的朋友一点指引。RocketMQ简介--技术背景RocketMQ是阿里向Apache贡献的消息中间件，是一个开源的分布式消息传递和流式数据平台。随着公司的体量、业务呈现指数式增长，技术层面开始面临着数据采集、数据异构、系统整合等诸多问题。由于RPC采用同步处理技术，在性能、健壮性、可扩展性上都存在着诸多缺点，消息队列以异步处理，非阻塞调用的技术模型悄然登场，并迅速成为分布式架构的宠儿。在消息队列的诸多模型中，RocketMQ以其消息不丢失、架构优势、高可用、高吞吐量等诸多优势被广泛应用。其架构图如下：主要分以下几个模块：nameserv是基于服务注册发现功能的无状态组件，支持独立部署。在RocketMQ架构体系中，属于重中之重。生产者从namesrv中获取可用的broker地址，将消息发送至broker；消费者从namesrv中获取可用的broker地址，从broker中拉取消息；broker定时向naemsrv发送心跳信息，维护可用broker地址。broker是基于高性能和低延迟的文件存储的无状态组件，支持独立部署。在RocketMQ架构体系中，属于核心级组件，负责存储所有的消息相关文件（包括消息文件，日志文件等等）。生产者及消费者是我们在实际编码过程中直接接触到的，也是RocketMQ直接暴露给编码人员的API接口，生产者和消费者支持分布式部署。生产者，产生消息的实例；消费者，接收消息进行消费的实例。应用背景在开发自测或者测试工作中，经常会遇到这种情况，待测方处于消费者下游，需要收到一个RocketMQ消息（订单状态变更/商品状态变更），才能触发要测的流程（例子：订单状态变更为已收货->给买卖双方发送验机评价消息，商品状态变更为风控下架->给卖家发送退回商品的信息等）。为了更好的模拟待测业务场景，又避免构造太多和本次测试无关的数据，我们需要一个模拟生产MQ消息的工具。OK，来搞一个模拟生产MQ消息的工具吧。接到任务的时候先不要瑟瑟发抖，来跟小编做几个思考题~思考：1.MQ消息是什么样子的？从日志中抓取一个被包装后的MQ消息如下：MQ

作者|赵里京背景目前转转的所有业务都在快速增长，支撑其用户服务的客服系统也同样在快速发展，以承接用户每天大量的问题。最开始转转的客服系统体系如IM，工单以及机器人等都是使用第三方的产品。但第三方产品对于转转的业务，以及客服的效率等都产生了诸多限制，所以我们决定自研替换第三方系统。下面主要说一下IM系统以及相关测试方法，先来了解一下IM系统和WebSocket。WebSocket？WebSocket是HTML5出的一种在单个TCP连接上进行全双工（通信允许数据在两个方向上同时传输）的通信协议。WebSocket与http协议区别：简单的说跟HTTP协议基本没有关系，WebSocket只基于HTTP，或者说借用了HTTP的协议来完成握手动作。WebSocket与Socket区别：WebSocket是应用层协议，Socket是传输控制层协议，即WebSocket建立了Socket连接。下图可直接说明两者区别。IM系统常用的实现方案：http短轮询：循环发送request请求，有没有新消息都会发送http长轮询：Client端发送request请求，server端收到后保持住此次请求x秒，x秒过程中有消息立刻返回。没有新消息就等待x秒，x秒后放开请求，Client端再发送请求，

作者|黄莹前言CodeDiff-从字面上理解就是代码差异的比较，其实我们的测试工作从某种程度上可以理解为针对代码逻辑的测试。因此CodeDiff可以作为一种补充测试的手段，辅助我们在测试过程中通过代码内容更好地判断测试范围，以及加深对技术实现的理解，使得我们能够从内到外更好地把控项目的风险与质量。CodeDiff的意义在日常工作中大家进行CodeDiff所用的工具和方式多样化，但其目的都是通过两个版本的比对拿到差异内容，通过差异内容进行流程性或者模块化的梳理从而得出此次提测的改动点，然后再对其进行需求/业务相关性评估。CodeDiff需要测试人员熟悉原有业务流程与新需求所涉及的范围，对所涉及模块之间上下游的调用关系、数据流向、状态变化等有一定程度的了解，通过了解开发设计方案、接口改动等等方面来综合评估影响面以及测试/回归范围。为什么要自研？1、CodeDiff工具方式多样化，希望提供一个统一、简易的平台（支持SVN/Git两种模式、省去打开IDE、反复拉代码、查看无权限等繁琐操作），让每个人能快速进行Diff，培养同学diff代码的习惯；2、目前公司开发模式统一切成Git，相比Git平台提供的能力，我们希望实现任意两个CommitId/分支之间进行diff的方式（两种Diff模式的优缺点）；3、参考业界其他互联网公司自研案例，自研的方案拓展性更强，且方便接入公司项目管理流程之中，使其能够平台化、提升效能；CodeDiff接入到beetle中，与每一次编译做结合，开发人员可以增量查看每次编译的diff结果，测试人员可以看到每次提测基于首次编译的增量diff，也支持自主选择版本。4、可以为所有基于代码差异的测试方法所使用，如CodeReview、代码覆盖率统计、代码静态检测、语法检测等。设计实现1、基本思路自研的CodeDiff平台支持SVN、Git两种模式，虽然这两种版本控制系统存在诸多不同（集中式/分布式、用法思想上等），但CodeDiff实现的基本思路是一致的：基于任意两个版本/分支进行代码比对，得出差异结果，再将差异结果进行解析并进行展现。2、实现方案SVN-SVNKit纯Java的SVN版本连接库，整个连接底层由Java实现。一共提供两个层次的API，通过这两个API就可以基本实现与客户端相同效果的操作，不需要额外的支持：

作者|刘宝成一前言在我们日常的测试工作中，无论是做客户端还是服务端测试，都会经常用到抓包工具，以验证客户端和服务器之间发送的数据包是否正确等。Fiddler由于其入门简单，功能强大，已经成为了目前最主流的Web调试工具。但Fiddler采用的是web代理的方式捕获数据包，并且只支持Windows平台，导致其使用场景受到一定的限制。而Wireshark是一款开源和跨平台的抓包工具。它通过调用操作系统底层的API，直接捕获网卡上的数据包，因此捕获的数据包更加详细，功能更加强大，但操作也相对繁琐一些。可以作为对Fiddler的一个较好的补充。二Wireshak的安装和基本使用安装：直接通过官方下载对应的安装包即可https://www.wireshark.org/download.html使用：左上角为几个最常用的按钮：开始捕获、停止捕获、重新捕获、捕获选项中间为捕获过滤器，用于过滤需要捕获的数据包捕获过滤器下面可以选择需要捕获的网络连接下图是用Wireshark捕获的数据包。可以看到，数据包结构是与OSI的七层模型相对应的，会详细显示每层的信息。三过滤器由于Wireshark直接捕获底层网络数据包，导致其捕获的数据包数量通常较大。为了便于筛选数据包，Wireshark提供了两种过滤器。1、捕获过滤器：用于设置什么样的数据包保存在捕获结果中，避免产生过大的日志文件。需要在开始捕获之前设置，相对简单捕获过滤器语法如上，一般用于过滤协议、IP、端口等基本信息。例如：

作者|申言方背景随着业务的增长，转转QA团队开发了一系列测试工具，随着代码量的增加和工具的增多，商业测试平台应运而生。平台的愿景是提高QA测试效率，帮助RD实现自测，但实际使用发现了一些问题：测试平台只能加载一个rpc服务的配置文件；测试平台加载的rpc服务配置文件无法实时变更，做到因人而异；测试平台不能够并发调用不同机器上的rpc服务，“各用个的”互不影响。以上3个问题，究其根本原因是作为测试平台的WF站点，不能根据需要调用指定机器上的RPC服务，即rpcclient在线下环境不能动态调用不同机器上的RPC服务。

、手机配置代理1、设置手机服务器以及端口，端口就上mitmproxy监听的端口2、访问mitm.it，下载证书如果安装失败就需要手动上传证书，证书在安装的服务器下面~/.mitmproxy/。

作者|伊星宇什么是直播一句话：服务端推流，客户端拉流，两者结合，变成直播实现流程第1步：通过摄像头，话筒采集主播的视频和音频信息；第2步：本地通过代码，根据房间号，生成推流地址；第3步：本地OBS直播软件，将音频和视频封包，通过推流地址传递给腾讯云媒体服务库；第4步：观众进入直播间，前端获取房间号，根据房间号去平台server端获取播流地址；第5步：获取到播流地址后，前端调用腾讯云接口，获取实时直播流信息；第6步：观众可以看到直播画面了。推流推流也就是英语中的publish/push，或者up

作者|田西西前言测试框架的设计需要适合被测试系统，要依据当前测试问题和系统后续的发展合理设计，避免过度设计导致维护成本徒增。同时被测系统也要依据测试方法提供适当的便利，以提高被测系统的可测性。本文讲述的是基于动态代理的接口测试设计，在思考如何测试之前需要先了解下被测系统。简单介绍两个被测系统一、交易订单系统交易订单系统基于状态机实现，包括正向流程状态机、逆向流程状态机，下图为正向流程其中的一条链路：订单经由特定条件触发，通过执行某个动作由当前状态转移到下一状态。动作执行前由前置校验逻辑判断当前请求是否可执行，当条件为真才会触发后续操作。订单操作以订单上下文为纽带，订单上下文持有订单当前状态及所有信息，订单操作将上下文由A状态变更至B状态并最终落库，同时处理一些UI渲染、消息发送等事物。二、支付中心账户系统支付中心账户系统中不存在状态变更，但所有的操作基本都是对账户余额的操作。所以账户系统可以理解为以账户上下文为纽带对账户金额进行操作的系统，如充值操作使账户可用余额增加，提现操作使账户可用余额减少。上面两个系统有一个共性，被测系统都可以抽象为由某个特定条件下触发某个操作引起某个主体发生特定变化的系统，如订单操作引起订单状态变化，对账户的操作引起账户金额变更。如何自动化测试类似系统呢？我们早期接口用例实现方式：早期我们编写了很多校验方法用于不同属性的校验，如校验订单状态的方法、校验订单按钮的方法、校验订单服务窗内容的方法。在每个订单操作后依次调用该操作对应的校验方法并传入期望值。早期单条用例可读性可接受，从用例即可知道当前做了什么操作，引起了什么变化，期望值是什么。但也存在一些问题，如：同样操作会出现在不同用例中，如不同种类的订单需要调用的校验方法基本相同，导致在不同的用例中重复调用相同校验方法，冗余且容易漏掉。当交易系统更新后，需要到各个用例中更新或替换这些校验方法。当系统复杂到一个操作下需要调用五个左右的校验方法且每个操作还会定制一些个性校验，用例编写和维护会十分痛苦。那么如何解决这些问题呢？仅仅解决眼前的问题就能满足吗？我们先看下订单系统的一个特点：一组明确的条件可以定义当前订单所处的状态、UI展示等信息。如买家在已发货状态下操作确认收货，上述条件可以确定订单当前处于已收货状态、订单详情展示为已收货状态下的UI。如订单处于发货状态且买家N天未操作订单导致离线触发，上述条件也可以确定订单同样变为已收货状态。账户系统如何描述呢：操作充值，导致了余额增加，且条件和结果相对于订单要更加简单。

作者|肖恒转转欢乐送是转转孵化的处理闲置小程序，闲置直接送给更需要的人，一口价，24小时送出，无需沟通，快递上门取件。送出闲置得星星，星星领取好物。领取人还可以发出感谢。有爱，简单，欢乐。本文主要介绍转转欢乐送分享到微信群场景的自动化实践。小程序自动化准备工作1、

作者|陈秋简介Beetle是转转公司测试部主导研发的一款基于gitlab，jenkins，maven为主的轻量级效率平台，主要解决编译部署测试发布流程中的效率问题，详细介绍请参考《效能提升的江湖路--转转Beetle平台百天记》。背景

按照这个思路，下面介绍一下用例管理平台一、命名规则配置前面提到我们的思路是兼容各方的特点，以配置的形式存储。所以依据目前接入平台的各方业务特点，配置如下：工程名称

作者|孙敏在测试过程中，我们需要各种各样的测试数据如果依赖纯手工的方式去构造数据，花费时间长、重复性工作量大，是非常低效的。所以各式各样的数据构造工具应运而生。

作者|郭胜君互联网高速发展的时代，敏捷开发已被各公司广为使用，其核心是MVP（最小可行性产品）、快速试错、小步快跑。在转转也如此，转转的项目采用MVP短平快为核心快速试错。大多数团队在追求效率的同时，流程规范往往被忽视，即使遇到让团队很不爽的问题，考虑到优先保证效率，也只能一忍再忍，导致团队士气低落。但是，转转做到了在快速交付产品的同时，不断优化规范流程，帮助团队进行过程改进，使团队协作更加高效，项目运转更快。本文主要通过具体案例，分享如何通过数据驱动团队进行过程改进，欢迎大家一起探讨交流。依据什么进行过程改进？过程改进要从痛点驱动，如何获取团队痛点呢？方法有很多，比如：深入团队去观察、和一线人员沟通了解、分析项目数据等，最有效的方法是分析项目数据，用数据反映团队的真实情况，有理有据。转转平时收集项目中比较关注的数据（主要从质量和效率两个维度），并定期分析总结，重点分析异常数据，对于共性问题进行优化改进，主要采用PDCA原则。开发自测让团队转的更快开发自测可以提高开发人员的质量意识，提升代码质量，减少对测试人员的依赖，减少沟通成本，节省测试工作量，因此，很多公司都在实践开发自测，转转是如何推广此实践的呢？数据为依据，选择合适的试点团队，试点ok后逐步推广，定期分析数据，不断优化改进。具体如下：1、

作者|曹巧晖功能测试、自动化测试以及测试开发的发展与选择，似乎一直存在着诸多争论，那怎样的测试才能带来成就感呢？测试一直都处于下游阶段，如何打破被动姿态？摒弃传统测试的角色，怎样被更多赋能？不破不立，怎么打破测试的局限，转换角度，多方面保证质量，达到目的，建立能力壁垒树立信心？本文分享测试介入项目过程，如何打破测试被动姿态，从下至上保证项目质量。1、别把自己看成测试面试或者被面试的时候，都会问到：你觉得测试是什么？测试，保证质量。那测试扮演着一个什么样的角色呢？看似一个送分题，实则是试图通过这个问题来获得对方的亮点。你心中的答案是什么呢？我认为首先，测试不仅要有产品具备的业务感其次，还要有研发人员的逻辑设计能力然后，你不仅要成为测试工程师，还要站在用户的角度去构造场景，让自己成为产品的用户最后，在整个项目上下游，测试一直隐形的扮演着一个项目管理者的角色，细想后你会发现，由于测试的强势介入，整个项目变得规范化。由此可见，保证质量，就是保证项目的质量，保证产品过程的质量，保证产品优化的质量。你不是一个简单的测试工程师。2、测试的核心作用是润滑剂测试所面临的困扰：1）项目目标是什么？2）计划赶不上变化3）没有成就感打破传统，转换思路，如何主动出击？项目是什么，就是一件事，这件事的目标是什么，可以从测试角度出发，提前明确测试目标，需要快速试错的产品，我们关注进度，如果该项目目标是需要完善产品体验，我们则更需要关注的是各个环节的交互体验。项目周期是多久，大概什么时候需要交付。测试可以作为监控方存在，主动参与计划的制定过程，以更细粒度拆分项目计划，将进度透明化，而计划意味着所有参与者的一个约定，在这个约定实现的时间段内，测试同学需要不断监控计划的执行情况，识别风险，及时呈现项目状态，应对各种变更。测试人员经常遇到，过程中被动接受任务，往往会出现几种情况，提测质量差，提测时间晚，测试加班消化问题，以加班和时间紧迫为借口来推卸过程改进，最终导致没有成就感，所以，不被动接受测试任务，从测试角度带好项目节奏，张弛有度，配合项目的同学就会很舒服。测试就是整个项目过程中的润滑剂。综上所述，不管是自动化也好，还是功能测试也好，通过技能能够扩充我们的宽度，如果需要树立我们的能力壁垒，我们需要打破对过程的局限性以及个人的局限性，提升自己的高度。从测试角度出发，可以通过自己的力量来提高每个参与者的效率，完善推进整个项目流程，降低风险。项目推动很简单，也会很难，这是一个漫长的过程，但是我们需要保持乐观的心态，内心一定要坚持，我们就是每个项目每个需求的小小守护者。往期精彩回顾日志插桩工具快速搞定接口测试转转APP专项测试——静态代码扫描从性能分析角度谈拆分组件1分钟了解转转小程序测试体系基于codediff的差异代码覆盖率统计实现转转

背景测试童鞋们，有没有在测试过程中遇到这样的问题：想要测试一个接口，没有足够的测试用例，手动构造用例耗时劳力，造出的数据场景单一，怎么办？调用了其他业务线的接口，不知道对方接口返回值长啥样子，有几种形式，怎么办？常常接到服务报警，处理问题被动，想要长期监控接口性能变化趋势，怎么办？遇到了上述问题，并且想在不影响RD大神们的代码逻辑的基础上，解决它们。由此萌生了做个日志插桩工具的想法。日志插桩工具日志插桩工具是透明于上、下游服务，基于AOP思想，利用javassist类库实现的获取接口入参&出参&性能数据的工具。工具的设计如下图，为集群加装代理，由代理接收上游服务的请求，并转发对下游服务的请求，获取的信息存入日志及数据库中。名词科普为了更好的理解工具，稍稍科普下两个英文词儿：AOP

背景为防止转转App发生内存泄露、crash等问题，需要对项目代码进行CodeReview，发现代码中的内存泄露、空引用、资源泄露等问题，提高代码质量，减小以后上线的风险。静态代码扫描它是指在软件工程中，程序员在写好源代码后，无需经过编译器编译打包，而直接使用一些扫描工具对其进行扫描，找出代码当中存在的一些语义缺陷、安全漏洞的解决方案。工具选取因为转转安卓与iOS端都有，所以挑选了四款静态扫描工具进行对比，其中两款只支持iOS项目（Clang、Oclint），一款只支持安卓项目（Lint），一款双端项目都支持（Infer）。1、Clang：Clang作为LLVM编译器框架的前端，最主要的任务是词法分析、语法分析，中间代码生成。源代码通过clang语法分析后，生成了语法分析树(AST)后，可作为静态分析工具对AST进行分析。使用方式：配合xcodebuild编译命令以命令行方式运行，而且xcode已经内置Clang，还可以通过xcode手动运行或者xcodebuild+analyze命令运行可分析语言：Objective-C、C特点：提供html格式的输出报吿和xml格式的结果文件方便集成到Jenkins上进行展示2、Oclint：Oclint是针对C、C++和Objective

引言还记得前段时间关注度火爆的转转beetle吗，在惊叹着如此美妙又巧夺天工的产品思路的同时，有没有被她独特养眼却又熟悉的页面风格所吸引，在保持了页面清晰可依赖的同时我们更加追求流畅不卡顿的使用效果。转转测试部工程效率组在快速迭代开发过程中不断探索如何对组件进行合理的拆分以减少render的次数，从而提高渲染效率。采用技术栈

2017年1月9号微信小程序正式上线，小程序无须安装就能使用，依托微信强大的生态环境，能做到很多H5所不能做的事情。目前转转已有小程序11个，但对于小程序如何做测试，依然没有一个相应完整的操作文档。这里将从四个方面简单介绍如何对小程序进行测试。小程序相关介绍小程序发布审核发布前需申请外网域名，并在微信web开发者工具里找到项目，设置好服务器的域名。开发完上传代码后，在微信公众平台—》登录小程序管理后台—》点击开发管理—》点击提交版本审核即可。审核通过后会有相应提示，接着把审核通过的小程序发布线上；若未审核通过可做相应修改继续提审。第一次提交小程序审核时，需先上线后端，一般第一次审核时间比较久（3d左右）。小程序的限制页面层级跳转不能超过10层。用户本地缓存不能超过10MB。小程序代码包不能超过3M，所以部分图片资源需上传CDN。小程序发布需提交微信审核通过才可发版。提交审核前，外网域名需申请（除微信域名之外）。层级问题小程序原生页面存在10层限制问题，即超过10层时便无法打开新页面，而业务流程或者访问形成闭环时，很容易陷入10层问题。为避免层级限制导致的无法打开页面和层级限制带来的交互路径限制，内部提出了【层级策略】以解决层级限制问题。【层级策略】将页面路径存储到storage，返回时则刷新拉取存储的页面路径，目前只保存页面路径，不保存表单等数据。服务通知基于微信的通知渠道，为开发者提供了可以高效触达用户的模板消息能力，以便实现服务的闭环并提供更佳的体验。模板推送位置：服务通知。模板下发条件：用户本人在微信体系内与页面有交互行为后触发。模板跳转能力：点击查看详情仅能跳转下发模板的该帐号的各个页面。小程序给用户推送服务通知，依赖用户的formId。更多服务通知详情戳一戳https://mp.weixin.qq.com/debug/wxadoc/dev/api/notice.html基础库版本小程序的能力需要微信客户端来支撑，每一个基础库都只能在对应的客户端版本上运行，高版本的基础库对应的api不支持低版本，所以在使用这些新能力的时候需要做兼容。由于微信版本和基础库版本不是一一对应关系，且小程序api是基于各个基础库版本进行发布的，所以在测试过程中需要提前获悉当前基础库版本号。目前可在zeye后台查看基于转转用户使用的基础库、微信版本、手机型号覆盖率等数据。目前我们主要通过日志的方式自动获取到版本号，可通过两种途径拿到：1.体验版进入首页时通过console查到；2.通过我的功能页面拿到。更多https://mp.weixin.qq.com/debug/wxadoc/dev/framework/client-lib.html开发版、体验版、线上版小程序并不像服务端那样区别线上和线下版本，而是有开发版、体验版、线上版。如果只是开发后端逻辑功能，可在三个版本中任意一个进行测试；如果是开发前端功能则需在相应的开发版/测试版进行测试。三者具体区别如下：（1）

已覆盖的差异代码行数/总的差异行数；取改动代码的行号，解析jacoco覆盖率报告会累加以前版本的测试覆盖情况；7、Jacoco覆盖率报告解读提供多维度的计数器指令级（Instructions,C0

量越来越多，单设备全量Case的执行时长越来越长，多设备分配Case执行，可以提高执行效率、缩短整体耗时根据Case列表筛选出每台设备都需要执行的初始化Case及

Yuntestin以云架构为核心，基于Jmeter作为性能引擎的轻量级压测平台。它集脚本生成、修改、多执行机并发、报告展示以及结果对比为一体，是一个能快速低成本实施压测，帮助用户分析性能瓶颈的测试平台。降低了入门使用成本，让开发和测试都可以方便的执行性能压测。一、系统架构1、分布式集群压测，压力可观，总样本数

一、引言对每一个前来公司面试的同学笔者都会有“工作过程中遇到过哪些影响产品质量和工作效率的事情？”这样一个问题与其交流探讨，发现绝大数同学都会向我抱怨“测试环境不好用最影响工作效率，时常导致联调不充分引起线上Bug，但是一直都没有什么改善”这样一个问题，笔者所在的转转公司之前也深受此问题所困扰和折磨，出现此问题的根源是每一家互联网公司，都会不断的为了适应变化的市场做出业务的调整，这就需要项目不断的快速迭代上线提供相应的功能，在整个迭代过程中，不仅需要相关的PM、RD和QA高超的技术及良好的配合，也需要可用和稳定的测试环境提供最基础的保障，接下来笔者将会带领读者详细的分析一下这个问题及笔者所在公司最终是怎么解决的，提供给各位读者一个解决此问题的一个思路。二、问题分析下面就以上面这个比较典型的互联网公司技术分层架构为例说明（笔者所在公司也是采用这样的架构），搭建这样一套环境不仅需要了解整个系统包含的所有的组件（例如Nginx等）、服务（Tomcat及Rpc服务等）、缓存（Redis缓存等）、数据库（Mysql数据库等），知道各个服务模块的依赖关系、部署和启动顺序，最后需要申请服务器资源，开通各种访问权限，安装基础组件，部署服务，调试环境。整个搭建过程不仅需要熟悉整个系统而且还要熟悉公司的工作流程，最后可能还会花费大量的时间进行调试。由于数据的唯一性，我们通常会对tomcat及rpc服务有以下几种环境搭建方案：1、共用一套测试环境优点：只需要有一个同学熟悉整个系统和公司的工作流程即可搭建环境。缺点：由于每个服务都可自由的部署不同的测试分支，如果某些服务部署了有Bug的分支，就会导致依赖服务不可用，从而导致整个测试环境不能用的问题。

一、概述转转服务器侧的环境维护程序，简单可以理解为agent+cmd工作模式。Agent承上的任务是完成与平台远程命令和调度的交互，启下的任务是完成参数处理和对注册的命令执行具体的维护脚本。Cmd是完成在服务器上具体的操作，并对执行的过程、结果进行控制、标记。CMD

转转新测试环境，在每台测试服务器都部署了一套HttpAgent(以下简称agent)，由eig测试环境管理平台下发命令，agent完成命令接收、解析和响应，实现并发和调度控制，异步调用环境维护脚本。之所以自己开发一整套agent，是因为转转测试环境由多业务组成，复杂度非常高，我们可以根据自己的业务高度定制，做一套适合我们转转的，好用的系统。概述agent可以理解为一个轻量级的web服务，技术选型是python2.7+tornado，并开放统一的监听端口。主要工作流程为：接收平台下发的执行请求，agent按照命令进行解析和拆分子任务，并执行相应的脚本，在当前服务器上实现同步与部署的功能，并返回给平台执行结果与日志。除此之外，agent与服务器紧密结合，还承担了服务器性能信息采集、服务状态监控、jacoco数据采集等多种定制化功能。优点与现有的ssh直连方式执行命令相比，httpAgent优点在于：ssh本身需要建立ssh-key授权和kerberos互信，连接成本较高，稳定性也有局限。agent以http模式接收下发命令，并发支持会更好，而且可控，省时省力；自更新，自重启，进程守护，安全可靠；和服务器紧密结合，支持服务器信息采集任务和多种定时任务，定制化程度更高。agent整体架构agent整体架构分为install、agent、config、modules、script、util、console、test几部分。本文主要介绍agent作为http

前言挣钱是每一个公司的目标，为了完成这一目标，几乎在每一个互联网公司都有传说中的一个团队——商业团队，一般情况下他们主要负责在线广告业务，包括广告投放、广告检索、广告策略等系统的开发和维护。而在转转，我就在这样一个从无到有，快速成长的团队中。随着业务的逐渐成熟，对测试方法和工具也有了更高的要求，本篇简单介绍一下商业测试平台目前包含的功能，以及未来的规划。广告展示简略流程

题外话效能提升是个火热的话题，CI，容器技术，DevOps，还有很多笔者不知道的热门技术和话题，无非是希望通过技术手段来加强产品的研发效率及发布质量。简单明了的目标，却需要长期的学习探索，实践，总结，和修正，在这个过程中逐步的定义管控目标，流程和方法，最终实践。在转转，高发布频率及高并行开发是常态，这使得自动化效率提升显得更为重要。Beetle简介Beetle是转转公司测试部主导研发的一款基于gitlab，jenkins，maven为主的轻量级效率平台，平台主要功能包含源码的版本管理，编译管理及发布管理，同时提供代码的diff，codereview，测试覆盖率等功能；目前支持公司所有研发团队的日常发布工作；beetle平台用流水式发布的交互设计，简单的后台处理逻辑以实现简单快速发布的目标。1Beetle内嵌的开发流程从源码到上线的全链路生命周期管理各节点均实现自动化开发模式闭环流程2Beetle平台的工程管理新建工程调用gitlab

简介当开发人员或者测试人员在开发或者测试接口中，去获取到接口返回的结果值时，都要通过JSONObject和JSONArray解析json结构，然后再通过For循环遍历相应的Key，最后把value值进行App展示或者校验是否预期结果，编写的代码较多，如果返回的结果结构相对复杂(多层结构，对象套数组，数组套对象，对象套对象等等数据结构)，那么使用For循环以及IF使用的话，代码量则是以2的米次方码的。所以为了解决这个问题而开发出的这款插件，一键解决复杂JSON

apici目前的应用接口diff数据源性能测试平台接口数据源部分上线需求的业务回归自动化测试数据源立意高远，决胜千里，站在上帝视角看待问题，更多好玩有趣的等你探索！

1背景随着业务量和业务复杂度度增加，每次业务迭代都需要考虑业务影响域进行回归，效率低业务重构导致覆盖度一定程度上不完全，质量不高tcp接口众多，http接口更接近业务场景因为上述业务特点，故选择了接口diff的方式改进测试过程中效率和质量问题2实现目标根据环境数据配置进行接口数据对比，找出结果中的差异用例集成，使用csv文件管理用例case，支持不同业务线用例统一管理jenkins集成，自动化下载代码、执行用例、生成测试报告入口集成，统一集成到开放平台中形成数据闭环，可选择具体业务线执行对应的用例集，报告产生后可在平台统一查看3技术实现因为是通过jenkins集成部署到服务器中执行用例，故选择兼容的csv文件类型来做用例管理，每个业务有对应的csv文件用例集，主要维护用例接口名、要比对的配置环境、接口请求参数、接口请求cookie、cookie用到的uid等，其中接口请求参数可以通过数据平台初始化，更多接口定制化的数据就需要通过业务场景中抓包获取接口数据集初始化，通过平台选择具体的业务线数据集以读取对应的csv文件中的接口case，通过数据平台获取uid对应的ppu为cookie准备数据，并组装单测框架所需的参数化数据使用pytest单测框架执行用例，将参数化的用例数据进行接口请求，其中通过环境配置请求出json结果并传给服务平台进行diff比对，根据对比信息使用断言比较结果的差异（默认是线上同沙箱结果数据的比对）在用例执行中发现服务器不稳定导致接口比对失败，故使用pytest-rerunfailures插件实现用例失败重试机制用例执行后产出报告文件并发送邮件，平台页面可查看具体结果4经验分享&思考接口diff更多针对的是读数据的请求，也可以根据具体情况做写数据的diff，但要注意写数据会在线上产生脏数据，其中写数据之后的验证一定要有对应读数据结果验证的配合cookie中的数据要根据实际接口进行配置，如客户端会根据v、t值不同有不同的逻辑接口diff与接口测试无异，更多需要接口覆盖度（要是接口参数组合和异常情况的覆盖），与功能业务测试相辅相成接口diff主要的使用场景：接口功能重构、功能快速迭代、沙箱验证回归接口diff是对两个不同环境进行数据比对，那么环境的数据源就必须一致，因此比对时源数据的正确性就很重要接口diff对新增接口的对比验证有一定的局限性目前主要针对接口返回的全部数据进行比对，只对变化的字段进行过滤（如metric），后续用例量不断增加，diff比对的耗时也会递增，这样就要提前考虑比对数据字段中要过滤的部分和增加代码并发执行策略用例执行过程中因为服务的不稳定经常发生接口异常的情况，故加入重试机制长按，识别二维码，关注转转QA团队