首页 > 其他 > 详细

接口自动化之设计考量

时间:2018-07-23 14:11:47      阅读:154      评论:0      收藏:0      [点我收藏+]

前置

前两篇已经写了:

1. 接口自动化之接口整理(抓包)

2. 接口自动化之接口工具选取(jmeter)

第二点,需要再扩展补充,工具的选取需要考量多个方案,其中不乏定制化后进行二次封装开发。

第一点,后续需要增加多种抓包情形。

设计

1.通过抓包整理,文档展示效果如果,如果接口数及模块比较多,整个的工作量还是很费时的。

技术分享图片

 2.接口间的关系设计


 

a)依赖关系

其实这块在抓包的时候,大致是可以知晓的。

比如,需要登录的才能操作的接口,那么这些接口一定是依赖登录的,或者获取cookie或者session。


 

b)无依赖关系,但是关系微妙

例如:

接口A为添加数据功能,接口B为获取某个数据的详细信息,接口C为删除某条数据。

以上A-B-C之间是没有直接关系的。

但是,当数据库不存在数据的时候,使用接口B的时候就会返回空,接口C也无法证明接口功能是否真实实现了(正向用例)。

这时,如果先执行A,再提取A的结果,使用B去查询该条数据,最后使用C删除该添加的数据,即做到了接口验证,同时又还原了初始数据,一举两得。


 

c)关系确认

关系的确认其实还是要根据接口自动化测试范围来确定,只做冒烟测试那么做正向用例其实是差不多的,但是如果要对接口做压测等等这些,考量又不一样了


 

3.接口的验证

 接口的验证比较难的点在于:验证的粒度,多大才是合适的。

比如:做接口测试要不要查询数据库!

我们从几个方面进行考量:

1)接口响应值

→接口的响应值是只返回最终成功或者失败的状态:那么不需要查询数据库,直接匹配响应值即可。(完美情况)

→接口的响应值是单纯只返回未被处理的数据:那么直接通过与请求同样的处理获取数据进行匹配即可。(完美情况)

→接口的响应值是返回被处理后的数据:那么需要通请求一样对数据进行同样格式的处理再进行匹配(完美情况)

→接口的响应值格式是无规律的:同未被处理(完美情况)

→接口的响应值返回是有类似json这样的美好格式的:同被处理(完美情况)

2)对产品的熟悉程度

→熟悉表结构

→熟悉各请求对应的表关系

→熟悉各请求对应的后端处理逻辑

BUT!

以上情况,我们很少能恰好做到。

so:

对于接口测试,建议分阶段进行处理。安排好测试计划。

是的,接口测试也要有测试计划的。

第一阶段

在不熟悉各表结构和反例的情况下,建议走正向用例。

在返回的数据比较复杂的情况下,建议在前置准备的时候,准备特性数据,校验的时候模糊匹配是否接收到对应的特性数据。

这种情况下的效果是:

优点:覆盖冒烟/回归,完成正向用例,结果准确性也能达到几近100%;

缺点:需要部分的手工干预,比如前置准备的特性数据。

 

第二阶段

在熟悉产品的同时,熟悉反向用例,补充完善反向用例

优点:在第一阶段的基础上,可以覆盖其他异常情况,执行本接口功能测试。

缺点:需要部分的手工干预,比如前置准备的特性数据。

 

第三阶段

在熟悉产品的同时,熟悉表结构等

其余阶段均是根据对产品的熟悉程度,对接口测试进行扩展扩充!

所以是否需要进行数据库查询联动,主要还是在于测试的范围,测试的粒度,测试的时间性等

......

原则上,接口自动化全程是无需手工干预的。即路径应该如下:

技术分享图片

 后续再完善。。。。

接口自动化之设计考量

原文:https://www.cnblogs.com/VVsky/p/9317966.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!