接口测试 在接口文档信息不完整的情况下,如何实现接口自动化测试?如何更好的处理多个接口信息依赖的问题?

zhangjg · July 25, 2018 · Last by YunchaoLearn replied at March 25, 2020 · 5789 hits

1.目前公司要实现接口自动化测试,简单的搭建框架没啥问题,问题在于接口文档信息不完整,咋处理?
2.如何更好的处理多个接口信息依赖的问题?
3.接口参数用什么方式进行存储、读取?

目前能想到的解决方法
1.通过fiddler抓包进行分析,这时候就会出现一个问题,不知道那些是必传的参数、参数的类型
2.比如A、B、C三个接口,C需要B的返回数据、B需要A的返回数据,在测试C接口时,需要首先调用A、B返回结果,判断后再处理C
3.接口参数、API、请求方式、预期结果全放在Excel里,循环读取每条数据进行请求处理

其实最主要的是1和2这两个问题,请教路过的大牛。

共收到 14 条回复 时间 点赞

1.正常开发会对参数写判断,参数试一下就可以呀。如果是接口文档没有,那你只能去问开发要。
2.你需要把接口和case分开,一个case对应一个或多个接口,你把c接口当成一个案例,依赖于a,b的response不就可以了吗?
3.没有接口测试平台就用jmeter,jmeter有断言控件,不要用excel.

这种情况下@server开发人员啊,要么你自己去看server源代码,不然单从抓包就想弄清楚每个参数的作用基本是不可能的,设计case的时候总得知道参数具体的作用和范围吧;至于接口依赖要具体看业务和框架设计,什么高内聚低耦合都没有实现接口测试功能来的重要,那都是在满足接口测试的需求之后再进行的重构和优化;对于参数化,优先考虑效率和可维护性。

zhangjg #3 · July 25, 2018 作者
0x88 回复

感谢回复
1.参数试一下不太现实,可能一个接口有15个左右的参数,成百上千个接口试的话工作量有点大。 -- 目前想到的是把一些主要的参数试一下,结合接口文档在看下
2.依赖的关系给个初始化
3.jmeter 很少用,为啥不用excel,感觉读取excel很方面。之前尝试过yaml、json啥的 维护有点繁琐

zhangjg #4 · July 25, 2018 作者
alizwd's 回复

感谢回复
我想最好的方法,骚扰开发(但接口太多,太多骚扰不太好),然后是结合源码、接口文档、抓包分析了,好像也只能这样了。
然后想的是,首先把接口的主要流程搞起来,后续的参数验证可以慢慢搞、慢慢优化。

没有接口文档?当然是不做接口测试

  1. 区分公共参数和当前接口特有参数——抓包,多观察几个请求就能了解个大概
  2. 公共参数统一配置,比如从配置文件读取,每个接口不必去单独测试这几个参数(或者也封装起来,在合适的方式用python的装饰器)
  3. 对接口进行封装,比如我们这叫action,这里只做请求
  4. 用测试框架,如pyunit,然后case这一层考虑各种可能的参数情况传入,和返回结果的断言
  5. 如果每个参数都校验,那用例是非常多的,可以考虑正交法
  6. 对于单个参数的可能情况,需要结合具体的业务场景。比如,一个字符串类型的参数,如果是用户输入的,那就要测试的非常详细,考虑比如中英日韩等各种语言、数字、字符、全角/半角、emoji等等。但是如果不是用户输入来的,那就没必要测试这么细了(除非项目对安全要求比较高/时间非常充裕)

一点经验,供参考

1.接口参数如果靠测试人员,来去梳理必传和非必传,不觉得效率低吗,要从公司大局考虑,让领导去push这些文档;本来是开发做的事情,结果让门外汉去做;无论从效果和效率上 都是下下策略;
2.关于接口依赖可以两种解决方案第一种通过自己自动化造数据 提供给接口测试 第二种 mock数据
接口测试一些看法:关于接口管理以及参数必传和非必传问题,最好的方法就是让开发进行梳理(当然这是一个很难推的事情),如果测试部门来做这个事情,今后将会出现想死的心都有,不但效率低,而且还没有成果(接口不停变动难道你实时跟进吗,开发业务线很多难道派很多人跟进吗 你们测试不干活了吗,接口跑不过发现接口参数有变动 你不觉得被动吗 ),时间久了 你就会放弃......

以上个人建议,有说的不靠谱的地方希望多交流。

我也是用excel维护的,然后excel里我有2列数据,一个是依赖项(比如cookie,serial),一个是依赖项传的参数。代码里会判断依赖项是哪个,然后根据传入依赖项的参数,获得结果,然后从结果里获得相应依赖值。

edsion 回复

最近较忙,都忘记这茬了。🙏感谢。

zhangjg #10 · July 31, 2018 作者
access 回复

关于mock数据,这点可以尝试下,感谢提供思路。关于接口传参的问题,领导的意思是目前只考虑正常的请求。想来数据梳理应该轻松不少。

zhangjg #11 · July 31, 2018 作者
黑山老妖 回复

周末抽了时间搞了初版的demo(pytest + excel + allure),给领导看了下,领导的意思要用数据库维护,看了下python sqlite3 感谢挺合适的,准备用sqlite3维护数据了。

zhangjg #12 · July 31, 2018 作者

今天跟领导讨论了一下,目前领导的意思大致如下:

1.验证一些常用接口
2.通过接口实现主流程的验证
3.使用数据库维护数据

后续在处理单个接口的参数验证,慢慢来吧。。。毕竟就我一个人搞,一般还都是休息时间搞,上班忙啊。

在信息不同步的情况下,我不会搞。成本太大。比如你现在覆盖的主流程,当接口不通过,以什么判断是参数问题还是接口真有问题,还有当主流程都写好后,接口变更后,维护成本也大。接口文档,本来就是开发的产物,不然他们怎么联调?怎么自测?

0x88 回复

大佬啊!
我一直局限于单个接口,多个接口这种思路,原来是忽略了,测试最基础的case了...
按照case来编写调用接口,而不是按照每个接口来写case....
一个功能是由一个或多个接口来完成的,所以应该以功能来设计case,而不是以接口来设计case...
学习了...

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up