一些个人的建议哈：

1. 建议不要直接用 request ，可以做一层公共的封装。 好处是后面如果想做一下 log 的增加，统计每个请求的时间，或者做一些自定义的功能， 就可以直接在公共方法里面做，不用所有地方都改一遍。
2. 关于前置请求， 数据初始化之类的，考虑一下 pytest fixture

分两种情况去看：

1. 使用 fixture 去初始化登录，设置好 scope，不要重复登录了
2. 如果是用 pytest xdist 取并发执行，每个线程都可能会单独登录初始化一个新的 token。 这时候可以考虑用 锁的方式去保证只需要登录一次。

你的目的是把 1000 个用例分配到三个进程里面跑，还是想起三个进程，把这 1000 条用例都分别跑一次？

大佬终于回来了呀，点赞👍

你是不是都在用同一个目录去生成 report， 所以每次生成新的 report 都把旧的给覆盖了？

所以你四楼的答案就是 “不符合” 了

从软件测试的角度看你的例子：

1. 我要测试的对象是明确的，比如要测试网易云音乐， 对应的用例都是针对这个 app 的，不会像你的例子一样，每种不同的手机就打开对应自带的音乐播放器。 也就是测试对象不明确。
2. 我的测试范围是明确的。 比如我负责的是网易云音乐 app 的测试，就是需要甄选不同的用例列表，然后通过不同的用例集，去启动对应的手机执行这些测试。 也就是我需要测试 iOS 上的云音乐 app，就是去链接某台 iPhone，启动这个 app，然后开始执行；而不会像你例子里的一样，先判断当前连的是什么手机，什么机型，才去执行对应的用例。 举个例子来说，假如练了一百台都是小米的手机，你就把同一个用例在小米手机里面测了一百遍，而其他机型则一次也测不到。 这是不符合实际使用情况的。

所以我认为你这个只能算是 demo， 告诉别人怎么连不同机型，怎么打开不同的 app；但和怎么做兼容性测试没太大关系。

只是没有标记原创这么简单吗？

1. 像楼上被翻出来的例子 ，明显从其他地方搬过来的内容却标记了原创，这是在变相鼓励抄袭？
2. 被发现抄的还是站里面其他小伙伴的精华文章也不被处理，连水友们为社区贡献的内容也不保护？
3. 明显是靠不停搬运文章来给自己引流，甚至卖书，对站内可能上当受骗的小伙伴的保护呢？

不懂管理员为什么不处理这种涉嫌靠抄袭来给自己公众号引流的账号，而且还在每篇里面挂链接买书呢
PS 后面会不会把这些 “原创合集” 拿去出书卖钱？

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

五年 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？

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