经历挺丰富的，白盒是个亮点。但都是在说做什么，做得怎样 (成果) 比较模糊，只是大大提升效率。有可参考的量化数据 (如白盒发现多少问题，自动化多少用例，覆盖率和 sla 达到多少，减少百分之多少测试时间) 会更有说服力。

如果改变不了开发，可以用 rest assured 的 filter ，去掉返回值里面的 html 和 body 标签，只保留 json ，这样用例里用到的时候返回值相当于是纯 json 了。

不过极度不推荐这样做。

你们开发的姿势不对，既然有用的只有 json ，为何不直接 contentType 设为 json ，并且直接返回纯 json ？
对于纯 json ，rest assured 可以自动转换，方便用它提供的断言的

感觉没写完？

得继承 unittest 才有

抓包对比下 rest assured 发的包和 postman 的区别？
感觉是你的参数位置不对，query param 不是 http body 的参数，是路径末尾 ?keyword=xxx 这种参数

详细步骤、系统版本等详细能否补充下？信息量太少啦，就 2 个截图加一点文字，开发估计看到后还是得来你座位找你问步骤。

xx 公司 + 可以 + 测试开发

1. 用例不是个人产物，是团队结晶。团队内的人都应该开放权限修改，有需要就可以优化。
2. 至于是否适合修改，那是约定，但没必要通过系统权限这种机制来限制死。
3. 用例的每次修改后应该都保留一个版本，如果新的修改不合适，可以随时切换回修改前的版本。
4. 考虑一个场景，leader 给老大演示用例，发现一个明显错别字想立即改正，但却没有权限，多尴尬。。。

而且说实话，leader 没有合理理由就擅自修改用例，这个问题是 leader 的问题了。即使系统限制了，他还是会找你开通权限的，这种限制作用并不大。

已登记 issue ：https://github.com/testerhome/homeland/issues/83

这个问题晚些看下怎么解决。

如果想系统化的学习资料，建议到京东找书看。服务端性能有书的，接口测试没有独立的书，但一般书里会有相关的篇章
去年深圳沙龙金融专场也有相关的 topic ，可以参考下

PS: 建议楼主不要一下子看太多东西，一口吃不成大胖子

？？

大致能理解楼主的困惑，接口测试通过，客户端测试不通过，那么我直接做客户端测试好了，干嘛还需要额外做一次接口测试？

但可以换个角度想下：

1. 时间方面，一般客户端都是最后才联调好的，这个时间咱们就干等着？
2. 覆盖度方面，客户端一般已经做了过滤，无法覆盖更完整的接口参数场景，而接口测试可以。基本上接口测试通过，服务端不会有大问题。
3. 自动化成本方面，接口测试无论是维护成本还是执行效率，都比客户端自动化好不少，很适合投入自动化，也可以做得比较全面。开发自测或冒烟测试的时候会用得很爽。

不过有一个点，接口测试建议还是用自动化的方式进行，这样成本才低。用 postman ，每次执行都要手动改参数，确实成本比较高。

1. 用 env 命令，看 Jenkins shell 和你 ssh 的 shell 环境是否一致
2. 跑命令前，先用 source 命令加载环境变量配置。命令用法自行百度

这个区别是 shell 的交互式/非交互式区别引起的，你要了解下相关知识

阅读者已经懵了，完全不知道你业务情况、实现逻辑，想猜信息量也不够呀。建议直接找你们的开发同学询问这几个问题的答案。

很高兴能帮到你，我离大牛还远着呢，共同学习交流哈。

如果有时间，建议多走一步，看下堆栈里 self._find_robot_installation() 方法的源码。会出现这个错误说明这个地方还有可优化的地方，解决后还可以给官方提个 PR ，贡献下自己的开源力量。

看起来有点像找到不止一个 robot framework 。堆栈最后的输出意思是 split 后元素不止 2 个，所以赋值失败。

谢谢指正，deploy 拼写已更正。

这三者的区别确实如你所说，总结得很清晰。distributionManagement 这个遗漏了说明，我这两天补充一下。

这个 bug 报得不专业呀，没有环境，也没有步骤，请求方式也没提供。

平台本身并没有开放过，不过可以看到文档里面的图来了解这个平台。

http://test.360.cn/Case+/

不好意思，之前没看到消息。

1. 不大了解 soapUI 从 swagger 导入 URI 可以做到什么程度，如果可以做到自动生成部分用例内容，那么选这个可能更能提高工作效率。
2. 实现 excel 设计了数据组合后自动跑，如果是 java 可以用到 testng 的 dataprovider ，jmeter 的话可以直接用它读取 csv 的功能。其它工具就不大了解了。
3. 校验点的设计是个学问，可以先从 response 中是否包含指定内容开始，然后后期成熟后扩展到数据库的校验。
4. 开发提交后自动跑起来，可以用 jenkins 建一个 job 来跑自动化，job 的触发条件是开发代码仓库有 push 操作或者代码有改动。

没尝试过，不大确定。理论上只要打包前有做好插桩，还是可以收集到覆盖率的。

不错，嵌入容易，而且还带有用户操作记录，挺实用的。

这类参数应该是类似于用户账户之类的参数，调用一次后状态就会改变？

那可以把这类参数改成用 beanshell 随机生成，或者执行完毕后把通过操作数据库恢复数据。