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

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

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

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

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

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

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

ruby on rails开发
性能测试
springMVC