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

皆非 · 2018年07月25日 · 最后由 揽星河入怀 回复于 2021年09月14日 · 2252 次阅读

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

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

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

共收到 15 条回复 时间 点赞

楼主解决了吗?我这边遇到跟你类似的情况了,09 年的接口,现在让我搞自动化

0x88 回复

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

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

皆非 #12 · 2018年07月31日 Author

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

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

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

皆非 #11 · 2018年07月31日 Author
黑山老妖 回复

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

皆非 #10 · 2018年07月31日 Author
access 回复

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

edsion 回复

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

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

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

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

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

一点经验,供参考

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

alizwd's 回复

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

0x88 回复

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

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

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

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