#19 楼 @chenjialu 谢谢

下了一个登陆不了，ios 8，提示账号或者密码错误，web 端登陆成功

#14 楼 @isaac 嗯。我建议是要结合服务端的代码进行设计的，知道他的实现方式，不是和研发保持步调一致，而是结合你的场景设计进行验证，验证你自己的想法，用你的场景去覆盖它，这也是测试的价值所在。你也说了：“但往往还有漏掉的思维盲区”，那我们测试可能也存在思维盲区，能了解研发的思维方式不是很好么。
接口用例设计的时候，功能方面一般都是实现了的，但是通过很多次实践已经证明，他们的接口设计会存在漏洞，会导致用户信息泄漏、接口越权、系统漏洞等问题，这些个 PRD 是保证不了的。比方说：http://www.wooyun.org/bugs/wooyun-2010-046547 这个 bug，它已经实现了功能，但是有漏洞而已。还有一些经典的接口 bug 案例。

#12 楼 @isaac 说实话，正交覆盖 100% 很不现实的，对于接口参数校验这一块，并不是被测系统的核心逻辑，并且校验方式轻易不会被修改。
按你打的比方，一个接口 10 个入参（参数有点多，考虑是否可以减少）这个接口自动化设计基于以下考虑
1.有些入参是诸如 type 这种枚举型或者 datetime 这种就不存在极大或者极小的问题
2.被测系统代码层的参数校验逻辑是什么，极大极小很多时候都可以规定为等价类
3.核心入参只有几个，重点是对这些参数根据业务逻辑进行设计然后实现自动化
4.template 只需要一个，但是数据有很多组，类似下图

对于接口自动化用例，我建议是要结合服务端的代码进行设计的

#9 楼 @isaac 补充一句，我们接口自动化实现数据驱动是用的 robotframe 的 template 功能来实现的

#9 楼 @isaac 你好。对于接口测试我认为接口的安全&越权优先级最高，就是对于核心参数的逻辑校验。接下来对于常规修改就是通用的边界值方法，如极大值、极小值、极长值、null、空这类情况，可以在一个自动化用例中用数据驱动的方式进行校验，这一类的预期结果应该都是类似的。接口测试和 UI 测试不同，接口测试的覆盖范围比 UI 更易实现覆盖，投入更少，建议在一个用例中用数据驱动的方式全覆盖，收益大于投入。

#7 楼 @chenjialu 谢谢，欢迎讨论。。

#4 楼 @archonwang 是的。我们现在是有 robot+jenkins 的框架的，自动化用例数 1200+ 的样子，前段时间改了 ride 源码做自动化用例转化的，不太成熟，现在想用 postman 作为入口做自动化用例转化。。WEB UI 已经放弃啦。

#3 楼 @chenhengjie123 是的。我说的就是功能方面的用例设计。。你可以看一下【接口测试怎么做】这一节，如果没有思路，再交流一哈。

#1 楼 @ycwdaaaa 是的。我是分开说的，有自动化的，我们是 python 封装类库 +robotframe+jenkins，这个里面说，一篇写不下。。谢谢建议

#10 楼 @allanwendy postman 有个环境变量的概念，但是我试了一下，环境变量只在 request 和 response 中生效，在 test 中没用，不然可以做参数化的

#11 楼 @_test 谢谢

#8 楼 @allanwendy 接口数据当然可以校验了，postman 本身提供了对于返回格式和返回值的校验，包括是否包含，如果是 json 的话可以精确匹配

#7 楼 @mendeta 谢谢

#6 楼 @lose 可以，你安装以后可以在 C:\Documents and Settings<$ 你登陆系统的这个用户名>\Local Settings\Application Data\Google\Chrome\User Data\Default\Extensions 下面找到并且修改源码，打包安装

#3 楼 @yiyusixing 不是的，不花钱，免费的功能。图四的左上角，点击就可以

#47 楼 @quqing 落地数据文件和你当时 select 查出来的有什么区别，这就是数据库告诉我当时它的状态啊？这不是数据库验证么？照你这么说，数据文件也别信，只有人眼看见的才算数，是这样么？那还自动化个毛线啊。。听你说话，感觉好装啊。。

#30 楼 @quqing 个人感觉日志可以解决问题啊，日志系统把自动化用例执行步骤，接口响应值，缓存层的值，DB 端关键数据的值都打印出来了，就是证据的。。这些数据难道不足以判断这段程序的执行过程么？

#59 楼 @skytraveler 严重同意

#1 楼 @seveniruby 嗯.postman 简单易用，但是设计理念很好。

ride 直接做不可以嘛？

楼主这套设计投入使用了么，效果如果？