最近总结了一下在接口测试方面的知识与心得,在这里与大家分享一下,如有说的不对的地方请多多指正。
API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps).
WIKI 定义:接口测试作为集成测试的一部分,通过直接控制 API 来判断系统的功能性,可靠性,性能与安全性。API 测试是没有界面的,执行在通讯层。API 测试在自动化测试中有着重要的地位,因为 API 一般是应用逻辑的主要接口,而 GUI 测试在敏捷开发和 DevOps 的快速迭代和频繁变更中很难维护。
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。接口测试大体分为两类:模块接口测试和 web 接口测试。
模块接口测试是单元测试的基础。它主要测试模块的调用与返回。经常需要编写一些桩模块与驱动模块。
主要测试要点如下:
检查接口返回的数据是否与预期结果一致。
检查接口的容错性,假如传递数据的类型错误时是否可以处理。
接口参数的边界值。例如,传递的参数足够大或为负数时,接口是否可以正常处理。
接口的性能,接口处理数据的时间也是测试的一个方法。牵扯到内部就是算法与代码的优化。
接口的安全性
web 接口测试又可分为两类:服务器接口测试和外部接口测试。
服务器接口测试:是测试浏览器与服务器的接口。用户输入的数据是输入到的前端页面上,怎样把这些数据传递的后台的呢?通过 http 协议的 get 与 post 请求来实现前后端的数据传递。这也可认为是接口测试。
外部接口测试:这个很典型的例子就是第三方支付,比如在我们应用中在充流量时,交话费时,都会调用第三方支付接口。
主要测试要点如下:
请求是否正确,默认请求成功是 200,如果请求错误也能返回 404、500 等。
检查返回数据的正确性与格式;json 是一种非常常见的格式。
接口的安全性,一般 web 都不会暴露在网上任意被调用,需要做一些限制,比如鉴权或认证。
接口的性能,这直接影响用户的使用体验。
SOAPUI
JMeter
Grinder
Suds Python
在工作中主要应用 SOAPUI 与 JMeter。SOAPUI 对接口安全测试有比较好的支持。本文还是主要介绍 JMeter 的使用,关注的是功能测试,对于它的强项性能测试,在以后的文章中描述。
因为在实际工作中测试的接口都是基于 HTTP 协议的,所以下面的测试用例及原则也是针对此类接口。
正面测试用例:
覆盖所有的必选参数
组合可选参数
参数边界值
如果参数的取值范围是枚举变量,需要覆盖所有枚举值
还应考虑实际业务应用场景,去设计输入参数的组合。(这些用例可用来测试功能,作为 SMOKE 用例。也可将来用于压力测试模拟实际业务场景,但要注意保证用例的独立性,因为压力测试是多线程的。比如我们测试 ACCOUNT 创建接口,NAME 是不能重的,在写测试用例时,给 NAME 赋值时可以加一个时间戳, 这样用例在多线程并发测试时也不会有问题)
负面测试用例:
空数据
包含特殊的字符
越界的数据
错误的数据
验证点:
status code(正常情况下,所有请求都应该返回 200)
响应信息数据结构(目前大多数情况下,返回信息都是 JSON, 我们应该验证相应的结构当数据信息发生改变时)
验证结点的类型
验证结点的值(主要是针对固定的值或者值遵循某些规则,我们能知道预期的结果的)
对于列表,应该根据请求参数,也应该验证列表的长度是否与期望值一致
负面测试用例,应验证 ERROR INFO 是否与实际相匹配
测试应该是独立的、可读的、抗变的、可维护的,其实这也是所有自动测试应该遵循的原则
每个测试用例都是独立的
测试用例都是可重复运行的 (这主要是说一些测试数据不能写死,不同的环境数据可能不同。在实际工作中,解决方案有二:自已创建所需要的数据,比如你要测试接口需要输入参数 ACCOUNTID,你可以先调用创建 ACCOUNT API, 然后从响应值拿到 ACCOUNTID, 当你测试完你要测的接口后,再把新建的 ACCOUNT 删除,也就是说一个测试用例分了三步。另外一种方法就是读取数据库,从数据库获取数据,这种方法在测试开发与测试环境还 OK,但如果测线上环境就比较困难了,因为我们不能随意更新上面的数据,也不能放过多的测试数据在上面。因此我个人比较推崇第一种方法,虽然增加开发用例的工作量,但一劳永逸)
测试能被运行在不同的环境里(平常测试环境至少会分 DEV/TEST/STAGING/ONLINE,我们在测试过程中,应该把域名,token/apikey 等应放在一个变量里,当切换环境时,我们只需改变变量的值即可
测试数据与业务相分离(测试数据包括参数接口数据/ 测试执行所需要的系统数据)
尽量统一共用的测试环境变量
测试完成后,要删除不必要的测试数据。
在实际工作中,我主要应用 JMeter 对接口做功能测试,所以下面主要介绍一下 JMeter 的使用
下面是我的一个测试脚本,通常一个文件会包含下面这些组件。我通过简单控制器与 DEBUG Sampler 来组织管理不同的接口,验证点主要通过写一些 Beanshell 脚本来实现。对于一些复杂的操作,如果网上能找到到现成的资源,比如 JAR,CLASS 文件会直接在 Beanshell PreProcessor/PostProcessor 引用。另外在 Jmeter 里写 Beanshell 不容易 DEBUG,所以还是建议复杂的功能直接在 Eclipse 里编写,然后生成 JAR 包. 关于 Beanshell 使用会在后面介绍
BeanShell 是一种完全符合 Java 语法规范的脚本语言,并且有自己的一些语法和方法 [官网](http://www.beanshell.org/)
我的脚本几乎所有验证都是通过 Beanshell 脚本,只有少部分应用了 Response Assert。
(http://jmeter.apache.org/api/org/apache/jmeter/threads/)
下面是一些实际的例子
log.info("log information")
它是类似的与 vars, 相应的属性在在文件 jmeter.properties 中定义
另外如果引用外部 JAR 包,也可在 TEST PLAN 中配置,在 JMeter 中点击 Test Plan 结点,就会看到下面的界面,可以直接添加 JAR 包所在路径
CSV_Data_Set_Config 当发送多组同样的请求,只是所带参数不同,这时可以加这个配置组件
然后在 SAMPLER 中可以应用上面这些变量配合循环控制器
在测试过程中,我们需要一些测试数据来自于数据库,这时我们需要在 Jmeter 连接数据库
下面以连接 MySQL 数据库为例
下载 MySQL JDBC driver 从(http://dev.mysql.com/downloads/connector/j/5.1.html)
拷贝这个文件到 JMeter 安装路径下的 “lib"文件夹
建立 “JDBC Connection Configuation"
其它数据库连接请参考下图:
因为我们在接口测试中,更多的时候是获取数据,所以基本都用 “SELECT"。如果想 INSERT 数据,需要选择 “Callable Statement"在"Query Type"
在使用过程中注意以下几点:
SQL 语句不要加分号
如果查询条件是变量,在语句中用 “?” 号代替,具体的值在下面的 “Parameters Value"定义,如果有多个参数,中间要用分号隔开。当然也可以用 ${变量名}(在用户定义变量组件中已经定义)
对于 “variable names" 数据表中有多少列就可以设置多少变量,对于不需要设置变量的列用逗号占位就可以了。
更具体的使用细节请参考(http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Request)
获取查询结果数据在 Beanshell 里
Aggregate Report 是 Jmeter 常用的一个 Listener, 中译为 “聚合报告”,每一列具体表示如下。
Label:每个 JMeter 的 element(例如 HTTP Request)都有一个 Name 属性,这里显示的就是 Name 属性的值
#Samples:表示你这次测试中一共发出了多少个请求,如果模拟 10 个用户,每个用户迭代 10 次,那么这里显示 100
Average:平均响应时间——默认情况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,也可以以 Transaction 为单位显示平均响应时间
Median:中位数,也就是 50% 用户的响应时间
90% Line:90% 用户的响应时间
Min:最小响应时间
Max:最大响应时间
Error%:本次测试中出现错误的请求的数量/请求的总数
Throughput:吞吐量——默认情况下表示每秒完成的请求数(Request per Second),当使用了 Transaction Controller 时,也可以表示类似 LoadRunner 的 Transaction per Second 数 KB/Sec:每秒从服务器端接收到的数据量,相当于 LoadRunner 中的 Throughput/Sec
说这个之前简单说一下如何在命令行执行 JMeter
首先配置 JMETER_HOME 环境变量,值即为你 Jmeter 解压路径
在命令行运行 jmeter -v , 正确返回当前版本,证明环境 OK
运行 jmeter -n -t script.jmx -l log.jtl
接下来做的事,lose 同学已经推荐了一个链接(https://testerhome.com/topics/2580),我觉得已经充分说明问题了,所以这里不再详述。
(本文完)