感觉没写完？

得继承 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 随机生成，或者执行完毕后把通过操作数据库恢复数据。

但是参数使用执行脚本后，这个参数就不可用了

这个具体说下是什么情况？

可以理解为一个基于 mock 技术和接口定义做的测试。mock 是一个技术，契约测试是一种测试类型。当然也有概念的成分啦，否则怎么和其它已有测试区分开

平时 mock 都是放在程序以外，单独维护，很容易出现代码更新后 mock 还没更新的情况。微服务下，这个问题会更加严重，因为十几个服务的 Mock 维护工作量可是不少的。并且调用链复杂的话，很容易上游改一个接口内容，下游就全都出问题。

契约测试则把 mock 放到应用中，更新代码同时更新这个 mock 。并且有用到这个服务的应用，都可以在单元测试中就直接启动这个基于最新接口内容的 mock 服务，不需要额外的服务器。自然也就起到了接口更新后如果不兼容，可以尽早发现的作用（前提是你要写针对服务调用的测试代码，哈哈）。这方面的详细内容，可以看看 spring cloud contract 的解决方案。

我们之前有尝试过，但因为项目中契约变动量不是特别大，而且说实话维护契约本身也是个不少的体力活，投入产出比并不高，所以后面放弃了。

闪退相关的 logcat 日志是什么？

截图里的是 warning ，不会引起闪退。