现在这种大环境，啥也不好干

非常感谢各位的回复，通过看大家的建议，还是学到了不少新东西

时间不允许弄太细，弄太细的话一天弄上三四个接口的用例，还没等弄完，开发已经上线了。
现在的矛盾就是留给接口测试的时间太短，想要覆盖到的面又很大。
时间太紧，用例肯定做不细；用例做细了，时间又不允许。就是想看看各位大佬有什么平衡点没，怎么把握

一些场景由于前段有校验规则，反而是功能业务测试不到的。比如接口要求某个字段传 int 型的，前端可以通过 js 或者其他情况校验你填的数据是不是 int 型的，由于某些未知原因导致前端校验失效了，用户不小心传了 string 类型的，这时候就有看接口的校验了。
所以接口用例设计这块我也很头大，弄的细了也不行，弄的粗了也不行。看看大家都是怎么做的，一起探讨下

你的这个定义规则的思路很好，学习了。关于测试数据构造方面，你有什么好的建议吗？
比如一个要求写 int 类型数值的接口，这用等价类和边界值，随便弄下就四五条用例，有什么简单的方法没？
或者接口测试不用测试到这么细的粒度？

思路挺好的，自己定义一些测试规则。可以省去不少人工的步骤，比如必填项可以用代码去校验，比自己写用例准确高效。不过这个有一个前提是有完整的接口文档，并且和接口测试平台集成到一起。幸运的是我们现在就是这么做的，哈哈：）

我们现在也是用 SpringMVC 开发了一套接口测试的 web 平台，就是感觉写脚本和调试脚本的时候效率不高，也参考过一些开源的平台做法，大家的做法都差不多。现在是一边开发接口平台一边写用例，投入产出比严重不对称。