介绍的提到的主要是单接口用例，一发一收，而且只校验返回 json ，好像没有考虑流程类用例和数据库校验？

另外，有个疑问，我看到代码里有通过 WriteExcelExpected 通过数据库的数据往 excel 写入预期值，想了解这里的数据库时被测系统的，还是脚本自己的？为何预期值是从数据库来，而非设计用例时编写到用例中？

找到一篇文章，里面有提到类似的情况，你参考看下？
https://www.jianshu.com/p/3a62abf85984

好文，读了几遍，有些例子非常有共鸣，特别是质效提升的，很值得回味。

这个方法是 gcc 编译器提供的，不是 XcodeCoverage 的。

真机使用 arm ，理论上不应该会有 x86_64 的错误，能不能把详细日志发上来看看？

有个几个疑问：

1. 社区 VP 委员会权利非常大，通过什么方式来选定委员会的人选确保权利得到适当的使用？
2. 各地活动的组织者，是否也视为自动加入 社区管理委员会 ？若不是，建议把这部分分离出来。

symbol(s) not found for architecture x86_64

看起来是模拟器（x86_64）不支持。你用真机试试？

这有点伸手党了，你先说下你的想法或做法，大家一起分享？

Unauthorized ，你的手机没授权给电脑调试

1.统计一周内的订单折线图，如果测试的话真的要每天做一下单子，连续做一周才会完整的折线图展现吗？
就这个功能而言，开发代码的入参应该是数据库数据吧，那对应地造数据库数据或者改数据库数据不满足需要？

2.在线教育课程的，从约课开始，每节课至少要半个小时，一个流程下来好多节课几个小时才能走完一个流程，效率太低
如果不大想改程序，那么你提到的上课前 xx 小时，上课后 xx 小时应该是配置项吧，把配置项值改小，然后搞一个几秒钟的测试专用课程，可以大幅度减少你等待的时间。

你现在的测试思路都是把程序当成完全的黑盒，找开发帮忙多打孔让你方便测试。但敏捷情况下，测试是需要了解被测系统的一些技术设计和基本逻辑的，不至于白盒，但至少是灰盒吧。这样才能找到成本最低，且结果有效的测试方法。

uiautomator2 是 google 官方的吧？
atx 提供的是它的 python 封装库。

经历挺丰富的，白盒是个亮点。但都是在说做什么，做得怎样 (成果) 比较模糊，只是大大提升效率。有可参考的量化数据 (如白盒发现多少问题，自动化多少用例，覆盖率和 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 ，贡献下自己的开源力量。