技术服务之道——京东移动端接口测试自动化演进

Posted 2021-04-24 手机京东技术团队

作者简介

张伟——测试架构师

10多年测试及自动化相关经验。2015年加入京东，一直从事后台服务接口相关的测试、工具开发及测试构架设计方面的工作，参与多次618、双11大促备战压测，在接口测试领域有较深的实战经验。

写在前面

移动互联网时代，移动App越来越多，更新也越来越频繁，这些产品的背后必须依赖大量的后台接口来提供服务才能确保用户的极致体验。为了加快产品的迭代速度，确保产品投放万无一失，复杂的业务逻辑功能逐渐放到了后台处理，所以就要求测试人员对后台接口必须进行充分完整快速的验证。

手机京东作为移动互联网产品的代表，其后台接口的测试方法也在不断演进，简单来讲我们经历了脚本化历程、平台化发展以及持续化改进三个重要的阶段，不断加速移动端接口测试自动化的转型。

脚本化历程

记得我刚到京东的时候，是没有专门的团队来承担后台接口测试工作的，客户端同学在测试APP的时候会通过代理（比如Fiddler）拦截的方式进行抓包（下图），通常是当发现客户端展示或者逻辑有问题的时候，才会去实时查看拦截到的接口返回值来确定是否是由于接口原因导致的问题。

随着业务量的快速增长，服务端接口数量不断增加，更多的业务逻辑开始向接口迁移，调用方从原来的APP独有扩充到M站、PC、SDK等多方调用，上线的频率变得更加频繁，系统的性能指标也开始被随时关注，压力测试也逐渐成为研发人员的家常便饭。

很显然单纯通过抓包检查接口返回的方式已经无法满足快速增长的业务需求以及越来越复杂的服务端接口逻辑，为了应对这种变化，我们必须改变现有的测试模式和方法，组建新的后台测试团队专门对接服务端开发，通过工具进行独立的接口测试成为必然。

那么需要测试哪些内容？用什么测试工具？

 》业务功能、业务规则、参数规则、场景规则相关的通过性测试。

 》接口的响应时间、吞吐量、并发数等相关的性能测试。

 》权限验证，是否绕过验证，是否加密，是否满足信息安全的规则的安全测试。

 》接口是否能够可靠运行的稳定性测试。

经过对以上测试内容的综合分析，结合移动端接口普遍采用的HTTP协议，还有少量的自研JSF协议，我们选择了Apache Jmeter作为测试工具，因为它不仅可以满足多种协议的测试，而且支持复杂逻辑的脚本化执行，并且可以方便的进行性能测试。

业务逻辑测试的脚本化

为满足日常业务测试的需求，需要设计如下类型的脚本：

基础的脚本模板

制定脚本编写规范，针对参数化，统一登录，统一校验全部模板化；

业务功能相关的脚本

满足各个版本、各个模块业务功能的需求，分别继承模板并建立对应的脚本；

回归测试相关的脚本

为满足快速上线原则，构建生产环境与测试环境数据对比脚本，确保功能上线后不影响生产环境的正常运行；

监控相关的脚本

对生产环境的核心接口通过脚本进行实时监控，确保线上服务的正常运行。

如上图，我们把所有Jmeter编写的脚本通过git进行管理，便于测试人员的开发和维护。按照业务模块根据生产环境的接口形态创建相应的脚本模板，比如搜索、商品详情，购物车等模块都有各自对应的脚本模板，当有新的功能开发完成时，测试人员会根据功能点创建对应的功能测试脚本，在开发分支进行功能点验证，测试通过后开发人员将功能合并到集成分支或者待上线分支，测试人员在该分支进行回归测试以及对比测试，测试通过后可以就可以进行上线。当上线完成后，业务核心功能的监控脚本将会实时进行监控，确保生产环境功能的正常运行。

对测试人员而言，只要维护好各自的脚本，覆盖相关的功能点，回归测试到位，通常上线质量是可以做到保证的，所以在相当长的一段时间内，写脚本成为接口测试人员的代名词。

性能压测脚本化

性能压力测试随时可能开展，相应的脚本需要随时具备。

早期的压测模型也非常简单，公司办公网与线上机是隔离的，压力机又是单独的集群，与办公网也是隔离的，访问压力机需要借助代理服务器，这样才能将测试脚本启动，从而将压力传递到线上待测服务器（下图）。

记得第一次参加618大促备战压测，提前准备好了压测脚本及所使用的数据文件，申请了大概20台压力机，当时需要测试人员对每台机器分别控制，启动测试脚本，将压力发到被测集群，如果单纯是这样一个过程，到还简单了，但是中途有时候需要调整压力机的脚本及数据文件，调整完就需要重新上传到压力机，来来回回几次就非常头疼了，最后测试完成，需要到逐个压力机上去收集测试结果数据，整理报告。虽然脚本帮助发出了压力，但是整个过程还是手动操作，耗人耗力，体验非常不好。

正是这一次的切身经历，加速了我们向平台化方向发展的决心。不仅要解决接口业务逻辑功能的自动化，也要解决压力测试的自动化。

实际上脚本化的改革给接口业务逻辑测试带来了很多收益，测试脚本基本上等价于测试用例，只要将脚本写好，就可以清晰的展示测试用例，按照脚本进行自动化执行，对结果进行自动化检查，即使再复杂的业务逻辑，通过脚本编程都能够轻易实现。

平台化发展

为了更好的进行自动化执行，接口测试平台和性能压测平台的发展成为必然。

接口测试平台

充分调研现有的接口测试平台和相关的测试框架后，我们决定将接口测试框架与管理平台打通，既满足本地设计脚本，执行脚本的需求又能满足统一化管理和统一化执行需求。

如上图，本地框架基于TestNG+OkHttp封装，为兼容京东自研JSF协议，也封装了对JSF的调用，管理平台是标准的webapp，本地框架与管理平台之间通过HTTP服务完成数据打通与测试用例的打通。

在本地框架中按照TestNG的规范编写测试用例并进行测试执行，产生的测试记录（包括接口请求，数据，接口返回）将会被收集并上传到管理平台，管理平台可以对测试记录进行归纳分类，以测试用例的维度进行展示，并支持自定义分组，便于后续进行按需回归执行。

在以上思想的指导下，大黄蜂接口测试平台诞生了。下图是管理平台的主界面，主要的功能点包括接口管理，用例管理，数据管理，报告管理等重要模块，用于实现在本地框架之外的平台端功能。实际上本地框架与管理平台之间是相互依赖，相互补充的。

下图为大黄蜂接口测试平台测试用例管理部分，针对本地框架上传的测试记录经归纳分类后按照接口维度进行展示，并可以根据需求选择特定的用例在管理平台上完成回归执行。

大黄蜂接口测试既解决了在本地快速编写脚本用例，快速执行的需求，又满足了测试过程的可跟踪，可追溯，可重复使用的需求，在很大程度上提升了接口测试相关的管理和执行效率。

性能压测平台

接下来我们看下如何解决快速增长的压力测试需求，既然要平台化就需要满足压测脚本的统一管理，资源（压测数据，压力机）的统一管理，在压测过程中能够实时监控压力机状态及被测服务的状态，测试结束后自动输出压测报告并逐步完成可量化评估的模型。

基于以上想法，我们对压测平台进行了统一规划，形成如下图所示的基础框架结构：

大体上分为几个核心模块：

管理端平台

管理端平台是面向用户的，也是唯一暴露给用户的操作界面，所有和压测有关的操作行为全部通过平台管理端完成；

中转服务

该服务负责将压测脚本及数据同步到指定的压力机，同时也负责测试数据，测试脚本的维护；

压力机01~n

负责产生压力并发送给被测服务，同时收集相关的日志信息形成对压测效果的评估指标；

数据持久化

测试过程中产生的有效数据将会持久化到数据库，并由此生成可追溯的数据报表及将来测试报告的生成。

在以上思想的指导下，大象性能测试平台应用而生。

下图为大象性能测试平台的主界面，我们看到通过平台可以完成测试计划管理，资源管理，HTTP及JSF协议的压测，数据的实时监控及测试报告的生成。

平台自上线以来已经历过4次618大促备战，3次双11大促备战以及上万次日常调优压测的支持活动，过程中平台也在不断更新改进，力求提供高质量的压测服务。下图是某次压测过程中的实时截图，我们看到单个压测任务超过了百万级别的QPS，非常棒。

流量复制平台

不管是大黄蜂接口测试平台，还是大象性能测试平台，都是主动式的测试行为，需要测试人员去获取测试数据，构造测试链接才能完成测试，那么是否可以利用生产环境的流量，复制到测试环境中协助我们完成被动行为的测试呢？

如下图，将线上服务器的流量或者日志实时导入到一个转发服务器，转发服务器根据流量来源，将这些信息再分发到指定的回放服务器，回放服务器可以将这些流量或者日志进行放大或缩小后发往被测服务，从而完成功能测试或者性能压力测试等相关需求。

基于以上框架，我们搭建了狙击手流量复制平台（下图），平台通过将线上服务器的流量定期的复制到待测试的机器中，完成常态化的性能压力测试。平台自上线以来已经完成了近200次常态化压测任务，形成了对服务评估的趋势性数据积累。

平台化建设实现了测试脚本、测试数据，测试用例的统一化，让测试执行自动化完成，并形成可追溯的测试记录积累，节省了测试执行人员不少宝贵的时间。

持续化改进

通过平台化建设我们逐步实现了测试执行过程的自动化（下图），大黄蜂接口测试平台，大象性能测试平台，狙击手流量复制平台在这个过程中扮演了非常重要的角色。但是秉承DevOps的核心理念，只有交付流程自动化，才是持续测试的最终目的，而不仅仅是自动化执行。

公司内部有自研的持续集成打包平台，单元测试框架，静态代码扫描平台，自动化测试执行平台，如何将这些平台相互打通，形成高效的平台链，是我们逐步向持续交付过程迈进的重要途径。

如下图，将测试活动加入到Jenkins的构建流程中

 》将单元测试，静态代码扫描编排到打包环节，确保在打出测试包之前单元测试与静态代码扫描测试全部通过；

 》测试包通过部署平台部署到测试环境/生产环境进行自动化测试，测试结束后会得到通过率与代码覆盖率的评估指标，评估合格后，该测试包可以作为产品交付；

 》交付的测试包根据产品需要进行按需部署，部署后启动线上监控。

基于以上原则，如下图构建自动化交付流程的平台链，通过将自研平台加入Jenkins流水线，逐步完成自动化的交付过程。

代码管理平台

代码通过Git/GitLab进行管理，并设置必要的版本控制及权限管理，同时进行代码检查；

打包平台

CI平台检查代码库分支的更新状态，根据调度规则进行按需构建，并触发对应的代码安全扫描，单元测试，静态扫描（食蚁兽平台）等；

测试用例管理平台

所有自动化测试用例通过与用例管理平台打通并进行管理；

自动化测试平台

根据选择的测试用例，进行自动化回归测试（大黄蜂接口测试平台），自动化性能测试（大象性能测试平台），测试完成后进行通过率与覆盖率的分析评估，确定是否可以进行交付；

部署平台

交付的包可以使用线上配置进行灰度部署，通常情况下，为确保部署的安全性，持续交付的包根据实际需求选择部署时间，需要通过提交申请，评估后才可以完成。

接口测试通过持续化的改进，将自研的测试平台编排进Jenkins流程中，形成平台链，正在向着持续测试，持续交付的方向发展。

写在最后

移动端的接口自动化测试经历了脚本化，平台化，持续化三个重要的过程，当然也正是平台化建设的发展，才逐渐奠定了持续测试及交付的基础，让接口测试不断向持续化的方向迈进，在持续化改进的路上，我们还有更多的工作要做，同时也将建立好反馈机制，让DevOps实践的三步原则逐步落地实践是我们最终的目标。

后续我们还将专题介绍大黄蜂接口测试平台，大象性能测试平台，以及狙击手流量复制平台，沿着技术服务之道，依托盖亚平台的大舞台在提升自身能力的同时，也将逐步对外开放赋能。

长按识别图中二维码立即关注