最近在做接口的相关测试，刚接触时觉得接口无非 “入参”，“逻辑”，“出参” 三项，比起前端测试要简单很多，可真正做起来的时候发现有很多问题。
一、接口测试应该在整个软件生命周期的什么阶段介入合适；
二、在设计测试用例的时候遇到了问题，由于接口测试的参数项和参数类型都是可见、可编辑的，这就造成了测试用例设计的时候可能的情况比直接从前端页面或者 app 直接输入有更多的组合情况，多个参数组合起来的测试用例更是多的不敢想象。
例如：
一个简单的验证码发送接口，光是手机号一项从等价类边界值设计用例就会有六七条用例，再加上后台逻辑的校验，起码有十几条用例；如果遇到参数多的情况，简单的必填项非必填项组合下用例量就大的惊人。
三、接口测试用现成的工具好些，还是自己通过写代码的方式好些
在使用 postman，jmeter，soupui 这些工具的时候，各有有缺点吧，都不能完全满足业务需求
例如：接口的数据加解密，一些特殊协议用工具处理起来就比较麻烦，有时候还需要二次开发；
自己写代码的话灵活些，但是工作量很大，验证结果的时候也没工具那么快速
希望有做过接口测试的大佬不灵赐教。
1.接口测试应该在前后端联调前介入并完成，保证前后端联调顺利
2.可以用 xmind 先罗列下测试点包括正常和非正常情况
自己写代码的话灵活些，但是工作量很大，验证结果的时候也没工具那么快速
你自己熟悉一门脚本的话，工作量实际并不大，结构写的好，脚本数量上来以后，是一本万利的
剪烛
回复
我们现在也是用 SpringMVC 开发了一套接口测试的 web 平台，就是感觉写脚本和调试脚本的时候效率不高，也参考过一些开源的平台做法，大家的做法都差不多。现在是一边开发接口平台一边写用例，投入产出比严重不对称。
2 个方向：web 化和脚本化。web 持续集成和可视化效果相对要好；脚本化自定义程度更高，验证的点可以更多，如果是自己搭个成型的架子，后续都可以用上了
如果是必填项验证、签名校验等公共性的用例，可以考虑提取成公共的方法，不用每个接口都写一遍，应该可以节省一些工作量。
这样可以把重点放在覆盖业务逻辑上了
迷惘
回复
思路挺好的，自己定义一些测试规则。可以省去不少人工的步骤，比如必填项可以用代码去校验，比自己写用例准确高效。不过这个有一个前提是有完整的接口文档，并且和接口测试平台集成到一起。幸运的是我们现在就是这么做的，哈哈：）
Jerry li
回复
你的这个定义规则的思路很好，学习了。关于测试数据构造方面，你有什么好的建议吗？
比如一个要求写 int 类型数值的接口，这用等价类和边界值，随便弄下就四五条用例，有什么简单的方法没？
或者接口测试不用测试到这么细的粒度？
红客联盟
回复
一些场景由于前段有校验规则，反而是功能业务测试不到的。比如接口要求某个字段传 int 型的，前端可以通过 js 或者其他情况校验你填的数据是不是 int 型的，由于某些未知原因导致前端校验失效了，用户不小心传了 string 类型的，这时候就有看接口的校验了。
所以接口用例设计这块我也很头大，弄的细了也不行，弄的粗了也不行。看看大家都是怎么做的，一起探讨下
基于 pict 接口测试...，看下我帖子，或者搜索下论坛
zyanycall
回复
时间不允许弄太细，弄太细的话一天弄上三四个接口的用例，还没等弄完，开发已经上线了。
现在的矛盾就是留给接口测试的时间太短，想要覆盖到的面又很大。
时间太紧，用例肯定做不细；用例做细了，时间又不允许。就是想看看各位大佬有什么平衡点没，怎么把握
非常感谢各位的回复，通过看大家的建议，还是学到了不少新东西
非常赞同这种做法，之前对边界等等都去写脚本实现，投入产出比太差。@zyanycall
@Jerry li ,请问你那有封装过类似的东西吗？我之前封装过一些，但是感觉不够好，想看看你封装的代码