接口测试 接口自动化设计的疑问点整理

陈小憩 · 2017年09月21日 · 最后由 黑水 回复于 2017年09月22日 · 97 次阅读

接口自动化涉及功能

1.接口功能及异常组合情况

https://testerhome.com/topics/7260 这篇文章来看,已经很复杂了,是否需要设计成如此复杂的方式。接口测试过程中例如一个输入参数字段值为 0 到 10 的范围,那接口测试时需要组合的就有 0、10、9、-1、” 0”、11、””、null 等接口测试用例组合,那么,是否需要全部考虑到,各大公司做的接口自动化框架,满足了哪些业务场景,做到哪种程度?

2.host 切换。

测试用例的执行的环境配置,例如可能在公司内存在测试环境、线上环境、运营环境 (配置各种运营需求或数据需求)
(1) 开发需求比较多时,例如,接口需要先在测试和运营环境配置 host,并且接口开发、测试通过,然后部署到线上环境,需要保证 host 切换 (在接口未上线前)。
(2) 灵活配置 host,验证某些模块或功能回归正常。

3.关于公共模块的设计 (登录请求或者多请求下的接口设计)。

(1) 公共模块设计会有类似登录请求,使用登录请求响应中的 token 作为下一个请求的入参再进行请求,然后验证请求回来的响应的正确性。多接口请求方式,层次最好能深入几层?或者说如何能更加灵活的进行多接口配置等。
(2) 公共模块可能还涉及到对每个接口是否 200,返回的 json 的公共结构是否正常;还有一些加密算法、md5 校验,json 结构中 result 字段的格式结构、字段 key 的公共校验。
(3) 每个接口请求的 log 记录、请求时间记录、测试结果记录等。

4.关于入参数据或数据准备设计思路 (如何更方便)。

根据https://testerhome.com/topics/4773 中介绍的数据管理策略,分为 databasefile 注解的属性 -- 作用域的设计方式,分为 method 和 class 的作用范围。测试思路类似 appium 编写脚本时的 setUp 和 tearDown,在 setUp 中定义好作用域的范围,然后在执行脚本时如果是 method 方式的,只有这个测试方法内可以使用;如果是 class 作用域,其实就相当于这个 suite 或 class 类可以使用这些数据。
(1) 思路很不错,可以使用 testng 带的注解作用域方式来实现和使用。
(2) 对于数据来源思路,可以从数据库中保存然后取出,根据场景业务,制定测试数据场景是否可行?测试中的 post 数据会修改服务端的状态,在每次测试之前,是否可以编写一个 shell 脚本,先去执行服务端创建的测试数据删除操作 (根据测试账号,测试分类等进行相应删除)?希望各位大神给点提示,和思路。

5.接口相应校验 (数据库校验、只校验字段格式)。

(1) 接口公共模块校验 (上边所说的公共模块设计)。
(2) 对于较长的 json 格式,可以将请求接口 request、响应的 response 对应关系保存到数据库中,在接口自动化测试时根据请求接口,查询对应 response 是否正确,这种校验方式类似 rest-assured 中的 json schema 校验方式,可以根据场景进行定义。
最好的方式是从数据库取出数据,进行字段校验。但问题也有:如果自动化执行时连接的是线上数据库,是否会影响线上,那么我自己 copy 一份线上数据库是否可行,而且还涉及到测试过程中要和开发的数据库保持一致等问题。这块的问题不太了解,希望大神们指点一二,谢谢。

共收到 7 条回复 时间 点赞

那接口测试时需要组合的就有 0、10、9、-1、” 0”、11、””、null 等接口测试用例组合

比如 Google 地图 API 这种在互联网上公开的接口,能做到这些算合格。一个内部管理系统能做到就很优秀了。
我见识少,接触过的公司,能做到一个接口有一条正向用例的就很少了。

用 TestNG 的话,就是写 JAVA 咯,用 JDBC 写 SQL 或者 ORM 框架也行,比用 Shell 好一些吧。

不过需要在 Host 切换、token 、数据恢复上花很多心思,说明在环境治理上还很原始。这些问题会影响交付过程中的方方面面,并不是接口测试时才会面临的问题。

见过最好的项目,没有数据恢复的说法,因为每次测试执行都在新环境上。测试代码里也不需要准备数据,因为维护了有一个包含测试数据的镜像。测试环境包含了三方服务(包括单点登录)的 Mock 服务,所以测试代码里也不需要这些东西。

黑水 回复

你说的包含测试数据的镜像,我没有明白什么意思,第三方服务的 mock 服务是测试自己写的还是?

关于第一个问题,接口测试要做到什么程度,也是我一直以来的困惑。
如果简单的说凭经验肯定是不行的,或者说根据实际情况我是不行的。

问题在于,在一般的情况下,接口自动化测试用例,要做到什么程度?
或者说:从多细的地方开始划断,该手工测试的归手工测试,该自动化的归自动化?

期待有大牛来根据实际的案例讲解一下自己的经验。

我以我的理解,尝试逐一回答你的问题:

  1. 我认为的【接口测试】是通过接口调用来实现业务逻辑的测试,而不是接口连通性测试。但可惜的是,很多人是在做后面这些工作。
    所以你不能问是不是要把 1 到 10 到验证一遍,而是要看这些值在业务上是否有具体的语义。

  2. 所谓的host 切换,我的理解是要让用例执行在多个环境下,我不清楚目前你们怎么做的。但是我们的接口用例实现层跟环境是解耦的,用例逻辑本身不用关注执行在什么环境中。

  3. 其实跟第二点很像,用例层根本不用去关心 token 怎么获取、签名是如何生成,重点永远是业务逻辑,那么这些行为在哪里去实现呢? 封装到框架的接口层

  4. 特殊的测试数据我们在本地保存一份,没有特殊性的数据实时从数据库中获取,这是我们的思路。

  5. 其实第一个问题的回答中提到了,关键在于你们的接口测试要解决什么:连通性?还是业务逻辑校验。如果是前者,我没什么可说的。如果是业务逻辑,那么关键字段的正确性必须是要校验的。

以我的理解,尝试回答下你的问题

  1. 各种异常参数,实际测试的是系统健壮性。建议更多地从业务场景去考虑参数组合,用例会更有效。
  2. host 切换,一般是框架层面设计的时候做好,用例永远只会从框架取环境设置。我们目前的做法是在命令行加了一个环境的参数,换个参数就切换环境了。
  3. 公共模块这个,通过框架的接口层完成。例如 rest-assured 通过 filter 可以完成你说的加解密或者自动加字段,用例不需要关心。(当然 filter 也是写接口测试的同学来写的,项目强相关)

最后两个 @jacexh 已经说得很不错了。至于线上数据问题,线上是不可能跑全量测试环境的用例的,需要另外有一个用例集,主要进行查询类接口的测试。

接口分级就好 功能 - 流程 - 性能 - 监控 看测试策略的不同来进行颗粒度的划分

陈小憩 回复

以前用虚拟机是利用快照和镜像。之后数据库在 Docker 容器里,准备好数据之后 ``
执行

# 准备数据
docker commit api-test init:1
# 执行测试
docker run --name api-test init:1
begin api-test
# 执行测试
docker run --name api-test init:1
begin api-test
# 追加测试数据
docker commit api-test init:2
# 执行测试
docker run --name api-test init:2
begin api-test

Mock 自己也写过、也用过现有工具、也用过在线服务。

一个技术方案是在很多因素影响下产生的:组织结构、要达到的效果、人员技术能力、硬件资源、投入时间……

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册