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

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

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

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

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

共收到 15 条回复时间点赞

0x88 #1 · 2018年07月25日

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

alizwd's #2 · 2018年07月25日

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

皆非 #3 · 2018年07月25日 Author

对

0x88 回复

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

皆非 #4 · 2018年07月25日 Author

对

alizwd's 回复

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

测试小书童 #5 · 2018年07月25日

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

edsion #6 · 2018年07月26日

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

一点经验，供参考

access #7 · 2018年07月27日 1 个赞

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

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