不好意思，我不是想咨询怎么做兼容性测试，只是好奇你这里举的例子是不是符合真实的项目测试需要。

五年 RF 用户说一下对 RF 的使用感受：
RF 的优点：

1. 支持度丰富，我们同时做 mobile 端和 web 端的 UI 自动化， 分别使用 appiumlibrary 和 seleniumlibrary 就能写，而且主要的操作、验证这些都有了自带的关键字可以直接使用。
2. 天然的关键字驱动的语法，适配 BDD 的用例格式。这在传统行业、外企里面很实用。
3. 扩展很简单，就是正常的 python 封装方法，然后引入文件之后就能直接使用方法名来调用。
4. 支持 allure report ， 可以跟其他框架使用同样的 report 。

RF 的缺点：

1. 如果直接用 RF 的语法去处理数据、写 for 循环、做判断等等，是很不方便和维护的，对我来说语法很奇怪。 所以我要求对于复杂的处理，都用 python 直接去封装，不要用 RF 去写别扭的逻辑。
2. debug 不方便。 所以我很少去 debug。
3. 处理数据不发表，不适合写 API 的用例。 所以 API 我们用的还是 pytest 。

总结： 没有最好的工具，只有最适合的工具。自己能用得顺手就可以了。

请问直接用 jmeter 的话，怎么满足团队合作的需求？ 比如同一套用例，团队里十个人都要写用例，怎么通过 git 之类的代码管理平台来做管理？

测试（test）只是对软件质量检测的一系列手段的结合，从静态测试，文档测试，单元测试，集成测试，回归测试，自动化测试，性能测试等等都是不同阶段和不同类型的测试类型和手段。
我觉得 “测试人员（tester）” 其实应该更倾向于是回归到 QC 和 QA 的身份上面，也就是我们的目的不是为了要测试而测试，而是如果为软件提供质量控制和质量保障。 这里需要的能力，除了上面提到的各种测试方法的掌握， 还需要有敏锐的质量管理意识，为团队梳理质量管理的流程，建立完善的质量体系。

面试的时候我会问： 为什么你会发现比别人更多的 bug。可能的回答： 我能力更强，所以同一个模块测试能比别人发现更多 bug； 我对业务了解更强，所以常年负责更核心更重要的模块，也负责更多的项目测试，所以发现最多的 bug。

我有点疑问，你这是插上了什么设备就跑什么设备的用例？
我们的测试应该是按需执行的： 比如要发布一个 android 的新包，我们就会去安排对应 android 的回归测试（自动化 + 手工），然后启动对应的 android 脚本执行测试。

你保证是在项目的根目录执行这个文件，应该就是没问题的

好专业

写个 for 循环，然后返回第一个找到的元素，没找到就继续循环；然后根据找到的元素判断你要做什么

另外再说一句：对于测试来说，我们的责任是质量把控，所以能不能按时交付，不归我们管，我们关心的是质量能不能达标。当然了作为团队的一分子，我们也要对交付时间做贡献，保障测试效率，按计划内时间完成测试；遇到开发延误的情况下，大部分情况下还是要尽力去配合赶上进度。 但原则还是质量标准不能降低。

所有的决定都应该是遵循大家都同意的规则去判断的。比如发版前是否还有哪个等级以上的缺陷，剩余的缺陷是否拿到业务的同意，可以接受这些缺陷在以后再修复。
如果目标是按时发版，那就以达到发版目标去提前规划，以及每天的日报里面把这些写出来：改修复的赶紧修复，不能修复的赶紧找业务商量，拿他们的背书。如果最后还是有严重的缺陷没办法处理完，业务也不同意上线，那就别上了呗，反正测试我就不松口，谁要违反流程去上，那就是谁的锅。

所以最根本的，还是要把相关负责人拉到一起，把这个游戏规则讲明白；统一规则之下，谁违反谁的锅。测试不能轻易降低自己的标准，这样也不会轻易被甩锅给测试。

要看自动化替代的是哪部分测试， 如果你是手工测试接口，那做成自动化就能替代这部分的手工； UI 的自动化对应就是替代页面的手工点点点。

可以用 sys argv 来传递

1. 接口测试只是分层测试的其中一环，整体的测试策略起码要在 UI 上多做一层 UI 自动化或者手工测试作为补充。
2. 要从流程上去分析，为什么前端改了代码而没测试到的原因是什么。 如果这个改动完全没有遵守流程（不在需求里面，没有提测给测试），那就是开发流程的问题，要去补充强化流程； 如果是开发已经提测了，但是测试以为跑个接口测试就能覆盖，那就是测试策略的错误，需要去强化测试设计和加强测试用例评审流程； 如果开发也是无意中带出来的改动，或者因为代码部署错误，把没提测的东西带上去了，就需要去强化你们的回归测试策略，不管有没有前端的改动，该做的回归测试都要做，并且基于这个去设计你们的自动化测试（包括 UI 和接口）

用 allure， 每个 log 都记录到 case level？

楼上的朋友们，这个项目我已经五年没维护了，所以你们如果遇到问题请尽量自己尝试解决和二次开发，恕我现在没办法帮到你们。 所以请慎重选择这个项目哈，抱歉！

首先一个原则，我们是不可能覆盖市场上所有的机型和操作系统版本组合的。
建议你整理成一个兼容性测试的方案给领导去 review：

1. 目标是要覆盖市场上多少比例的机型和操作系统？
2. 要达到这个比例，需要购买多少测试机？ 是否考虑使用付费云测平台？
3. 有了测试机和云测平台之后，你们的兼容性测试方案怎么和现在的回归测试策略结合起来？ 需要投入多少人力去执行？
4. 是否考虑用自动化测试来做兼容性测试？
5. 新机型怎么定期购买？
6. 新的操作系统版本怎么定期投入研究和兼容性测试，避免新版本发布之后对线上客户的影响？

然后呢，有多少钱干多少活； 出了问题，这是已知的风险， 因为没投钱啊

想起了脱口秀大会里小鹿讲过的一个段子： 你这个个人经验主要是太个人

检查一下是不是配置的地址是 localhost，导致不在那天机器上就访问不了（看你的截图）

我当时没有集成 iOS 的代码

我理解性能测试不应该以单个业务来设计， 而是去评估每个接口分别会有多少流量，然后按比例来构造。 比如 四个接口的流量比例分别是 1:2:2:3 类似这样。
具体的比例是多少，要么是看生产的数据统计，要么是根据业务模型去评估。

我们应该要感谢一直在 “卷”，还愿意免费分享出来的同行们

Pyechart 我以前用的是 0.5.5 ， 你看看能不能安装这个版本

看你的截图，失败的是 验证 的那个步骤，也就是断言失败了。
你可以点开旁边的截图看看具体是什么问题，有可能是你用错了关键字

这三百多评论里有一般是我的回复，哈哈