这是我个人电脑上 demo 试用的 阿里 通义灵码。 公司的电脑肯定不能随便用，除非是公司统一购买或者搭建的。

通常来说我们的压测都是针对生成的请求数量，至于这些请求是由同一个 openid 还是不同 openID 发过来是没关系的。

你是遇到 21 楼一样的问题吗？ 最简单的方法就是起两个 pytest 命令分别执行两个文件啊

上大学的第一课，当时的老师就说过： 大学教给你最重要的技能，就是怎么快速去查找资料去解决问题和掌握技能。 有了 AI， 让我们查找资料和解决问题的速度比以前更快，也更精准了，所以考验我们的是你怎么能快速地发现问题，找到对的思路。如果方向、思路错了，只会南辕北辙地跑到更偏的地方。

建两个 pipeline，一个触发事件，一个三十分钟后去验证数据

一些个人的建议哈：

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 循环，然后返回第一个找到的元素，没找到就继续循环；然后根据找到的元素判断你要做什么

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