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