探秘解析：接口测试详解

Posted 2021-04-24 易研家

背景接口测试，软测体系中非常重要的一个测试环节，以保证系统的正确性和稳定性为核心，将bug提前暴露出来能极大降低修复成本，提升测试效率， 并增强团队的交付信心。关于接口测试在分层测试设计和“测试左移”管理中的重要性，相信测试圈子的人都清楚，本文会重点讲述盛天测试团队的接口测试在项目中的实践思路和经验。

接口测试“平台化”早期时候，我们做得接口测试并不复杂，基本都是针对单个接口做得自动化测试，可通过一些工具（例如soapUI、jmeter、Fiddler、Postman等），根据相应接口的入参和业务逻辑设计测试用例。

测试内容主要集中在接口的功能验证和性能评估，但随着产品功能逻辑的日益复杂，系统体量的愈益庞大，我们对接口测试赋予的质量目标也越来越多，我们需要的接口测试不仅要自动化，还需要持续集成；除了能看到单次执行的测试报告，还可以对运行结果做统计分析，可以通过某个时间段的分析找到需要改进的测试用例或系统功能；具备对线上核心接口巡检的能力，确保业务处于“健康稳定”的状态，能尽可能的早于用户发现问题，避免故障面积的扩散。基于以上种种需求，我们决定将接口测试“平台化”，并集成到盛天的评测中心后台做统一管理。

那么，在这个后台开发过程中，我们又遇到了哪些问题呢?

实践首先是工具的选择，上面也介绍过，我们日常接口测试用到的工具还比较多，出于团队对接口层的测试需求评估，我们最终选择了soapUI和jmeter两款工具的集成。这里有人可能会问，为啥不统一选一套工具集成呢？的确，对于平台来说，可能会存在双跑的问题，不过考虑到已存在的历史测试用例和不同测试小组的使用习惯（比如web方向习惯使用soapUI，互娱方向则更偏爱jmeter），再加上两款工具确实很匹配各自使用群体的测试需求，我们决定将他们都集成到评测中心后台，大家按需选用。

SoapUI的实现思路：

1、在windows的测试机上部署一个web服务器，安装好soapUI后，在本地建立bat文件调用soapUI的bin目录下的testrunner.bat工具去执行各业务线的用例集，并把最终的结果存到指定路径（因为soapUI在linux上面部署后，只能在视图模式下运行soapui.sh来模拟发送报文，略坑）。

本地调试脚本用例时，bat可参考下面的模式：

但在实际项目中，如果我们要执行指定的某些用例、或用例集，需要对其做变量处理，参数在批处理中可以使用百分号作为引导符，其后跟0-9中的一个数字构成参数引用符，引用符和参数之间的关系类似于变量指针与变量值的关系，例如：

后面的%1 %2%3等就可以传testrunner.bat的命令参数和相关项目名，用例名称等。

2、评测中心后台通过http协议访问测试机的测试报告并网页展示。我们的任务列表支持手动执行和定时任务两种模式，其中定时任务得到的测试结果会被爬出来，并保存到数据库，方便做进一步统计分析。手动执行则只会显示单次的测试报告，结果数据暂不存库。

评测中心后台集成效果：

单次执行的测试报告：

3、由于工具和测试机的web服务器之间不支持相互通信，脚本用例需通过线下方式拷贝到指定目录，

各目录和文件的命名规则和规划结构需提前做好规范（团协任务在使用规范上要尽快达成一致）。

关于项目、用例集和单个用例的命名规则和规划结构可参考：

 

另外，SoapUI实现模式中需要注意的地方：

A、SoapUI不支持分布式，所以做接口的性能测试时，负载不会很高，建议超过5K并发的接口压测就不要用这个工具去做了，本身SoapUI的线程管理也做得不算很好（GUI模式做压力测试效果太差，负载完全起不来，本地资源消耗得太多）

B、相同的测试用例集合若需要在不同环境（测试环境、预发布环境、生产环境等）下做持续集成，务必做好hosts管理。建议生产环境的巡检任务最好部署在单独的物理机上，不要和其他环境混用。另外，多地部署的测试机web服务器版本建议保持一致（不同的web服务容易导致在取值解析时出现问题）。

C、SoapUI每个project都是一个xml文件，可以通过配置将每个Case、每个Suite变成独立的文件，这样可以通过SVN/Git进行多人协同管理。但关于Suite的范围需要约定清楚，可以基于用户使用场景划分testSuite，也可以基于某个功能模块去划分。

D、在SoapUI通过脚本方式连接数据库的时候，脚本如下：

这里，通过soapUI执行程序直接运行时不会报错，但用testrunner.bat运行时会报错，需要在这段代码块前面加上：com.eviware.soapui.support.GroovyUtils.registerJdbcDriver("com.mysql.jdbc.Driver")

后续在完善的内容：

1、统计分析报告的优化

目前，定时任务的测试结果会存入到数据库，关于数据的展示，准备对接公司数据部的olap平台（毕竟是测试团队内部开发的项目，自己做得前端效果有点粗糙，这块还是交给专业的平台去做，看得也舒服些）

2、考虑接入Swagger

说到API测试，就不得不提到API的文档了，我们知道每更新一个 API，开发同学需要在两个地方进行修改，一是 API 代码，二是 API 文档，关于文档的更新可能是绝大多数研发同学最头疼的事，但这个任务又不能不做，所以有没有办法只需要在一个地方修改，即可满足代码和文档的更新呢？选择使用 Swagger 来编写文档，按照 Swagger 的规范，在 API 上加一些描述性的 Annotation 就可以了。而且

SoapUI的5.2.1版本就开始支持SwaggerHub，目前研发有自己的接口管理平台做日常API的管理，但也有部分项目在使用Swagger，后期若有机会，我们会考虑SoapUI+ Swagger的模式，这样用例的管理会更加灵活。

Jmeter的实现思路：

1、基于maven + jenkins + jmeter的持续集成模式，在测试服务器上面部署一个tomcat，安装相应的jdk、maven、jenkins和jmeter（jmeter我们用得是3.1的版本）

2、在工作机（windows）开发接口脚本和用例，调试通过后再拷贝至测试服务器（linux）的指定路径，通过jenkins和maven控制需要执行的用例集、执行次数、执行时间。

3、对线上业务线的核心接口做定时巡检，主要针对功能验证和系统稳定性表现的监控，通过返回值检查和RT值对比，判断当前系统是否处于正常运营状态。

4、最终的测试报告会在评测中心后台能以网页的方式展示。

5、Jmeter工具版本我建议JDK7的环境就考虑用v3.1，JDK8可以用v3.2，在3.X的版本中，Jmeter的测试报告做过一次大更新，之前测试报告一直是Jmeter被大伙吐槽的地方，虽然后续jmeter补充了一些plugin（例如PerfMon），或者通过jenkins的Performanceplugin做到了图形化展示，但Jmeter本身在html页面格式的图形化报告上依然缺失，好在3.0以后的版本中，Jmeter引入了Dashboard Report，很好的解决了这个问题，有兴趣的同学可以去官网上面下下来试试。

Jmeter实现模式中需要注意的地方：

1、工作机和测试服务器的jmeter版本一定要保持一致，包括相应的plugin、第三方jar包等也都保持相同。

2、在Jmeter中，一个TestPlan就是一个jmx文件，无法分割，但Jmeter允许多文件合并，所以每个团队成员需要自己先建立一个TestPlan，划分模块进行测试，最后做整理合并。

3、有些项目需要引用自己写的自定义jar包，在maven的pom文件中关于引用jar包确实需要注意：

第一种类似Jmeter插件的jar包，可以通过maven的中央仓库中找到。

引用到jmeter的指定路径：

第二种属于项目中自己写的jar包，需要先在本地仓库中通过install命令安装该jar包。

比如我在工程中的配置如下：

mvn install:install-file-Dfile=/jmeter-web-jenkins/jmeter_jar/usercenter-common-1.0.jar-DgroupId=com.stnts.jmeter -DartifactId=usercenter-common -Dversion=1.0-Dpackaging=jar

然后在pom.xml文件中添加：

4、持续集成的服务环境上不要做压力测试，单独部署集群压测环境，测试结果也出单独的性能报告。3.1的版本可以使用Jmeter自带生成的HTML报告。

生成报告运行的命令：jmeter -n-t source.jmx -l result.jtl -e -o /tmp/ResultReport

或者通过Jmeter + Grafana + InfluxDB实现数据的展示，需要在在jmeter添加BackendListene

r，如下

5、资源存放路径（报告模版、CSV、引用的图片等，一般放在resources下面）和用例的存放位置的管理。如果有需要读取CSV等外部文件的，注意在用例中修改读取文件的路径。

规划:

1、完善用例覆盖率，对线上核心接口做巡检

测试环境：针对基础平台类项目与核心业务项目，服务端侧的接口尽量做到全覆盖测试，客户端侧至少满足对重要接口的覆盖。

生产环境：对线上核心接口做巡检，验证接口功能的正确性和稳定性；对性能要求较高的接口，通过截流（截取部分生产环境的流量）到内测环境回放来对核心接口做进一步的验证。

2、建立关键接口的线上运营基线

A、筛选出各系统的关键接口并执行测试脚本，测试计划一般设置10个并发线程数，执行5分钟。

B、准备关键接口的基准数据，在线上相对稳定的情况下，对每个接口脚本执行10次，并将这10次执行的RT值作为基准数据保存到数据库中。

C、在生产环境对关键接口做巡检，并将这些结果与之前的基准数据进行对比，检查服务链路的性能表现是否正常，如果结果落在基线区间或者未超过最大基准数据的10%（根据不同接口的响应时间这个百分比不一样），则认为这次测试通过，反之则需要对异常数据做排查和原因分析，并考虑是否调整基准数据。另外，测试通过的结果也作为基准数据日常维护的重要依据。

关于接口“平台化”的体验和总结暂时就介绍这么多（若有需要，我会考虑在后面另起文章做补充），希望通过本次讲述，对碰到同样问题或考虑尝试去做的同伴们有所帮助，同时也算是抛砖引玉，毕竟盛天评测体系中，接口测试管理只是其中一个部分，评测中心后台基于质量控制和质量保证还集成了很多其他功能。那么这些功能又包括了哪些？设计思路是怎样的？在实现过程中我们又遇到了哪些坑？