IT 不等于互联网. 很多大吵的互联网概念在制造业的 IT 领域并不是要考虑遵循的.
一切以实际落地出发, 一切以解决问题出发.

不同的测试工具有不同的概念, 理解清楚之后才好对应入手设置参数. 对于 locust 来说, 你是需要通过命令行收入-c -n 之类的一系列的参数来启动对吧.（很久没用 Locust, 忘记具体参数名字了, 此处代指.）

那么, 此刻的 c, n 应该是指的 Locust 的并发数量 (gevent 的协程数量), 当你不设置休眠时间 (wait_time?) 的时候, 其实在每个协程内部类似于 while true {sendReq()}...对于协程来说, I/O 阻塞的时间才是它能利用的时间, 才是它能去发送其他请求的时间. 所以, APi 的响应时间快慢是会影响你单核设置的最大有效的协程数量的.

回到你的问题中, 每个 worker 的最大能力对不同 API 来说是动态, 你可以使用类似于每分钟递增 x 个的方式去边测边健康, 当服务器资源正常响应并且 Locust 的单核趋于 90-100% 波动的时候, 就说明对于这个 API, 单核的最大能力要到了.

我其实是想纠正你的一个概念就是你所说的并发是指的 100WQPS, 而不是 100W 的虚拟用户数同时在线....
Locust 是基于 gevent 来模拟的虚拟用户数 (并发数), 然后模拟的 Http 请求, 根据响应的数量计算的 QPS, 也就是你描述的 100W.
Locust 的官方所说的单核 5000 8000 的也是这个指标 (QPS).
而你使用 Locust 测试的时候无法直接提供 100WQPS 去指令去测试，只能通过-c 之类的参数来提供虚拟用户数 (并发数) 来模拟请求，而这个-c 之类的参数的值, 可能是 100-200-300 等单位. 毕竟 gevent 启动的协程数量过大的话也会影响它 QPS 的施压能力..
-----------------------总而言之:
大部分开发嘴里的并发数, 其实都是 QPS/TPS 的值, 特别表明的除外.. 而测试工具不同, 提供的参数也不同, 造成的能力也会不同. 真实测的时候需要注意这点, 否则达不到官方所说的能力.

你指的百分级并发, 指的是虚拟用户数还是 TPS/QPS? 类似于 Jmeter, 100 并发=100 线程. 但是 100 并发能产生几万的 QPS 也是可以的..
假如 1 个并发 (线程)，1 秒内, 完成了 100 次请求 (响应时间平均 10ms), 那么这是 100 并发还是 1 并发.
我怀疑你说的并发是指的 QPS

这应该就是属于业务利好了, 感觉只适合面向大众 C 端的简单业务. 不涉及太多逻辑依赖的.

几个月前就在整理 IOS WebView 测试的东西, 用 Python 重写了 Appium 中与 IOS WebKit 交互解析过程. 如果当时有看到这个文章的话估计能少踩太多坑了

有想法又落地, 赞

以下通俗大白话:
当一个解决方案能够解决你们公司的某个痛点问题, 并且你们真正用到日常中解决了这个通点 (非理论上), 没因为这个方案的实施造成其他额外的痛点, 那么这个方案就落地了.
什么叫不方便落地？ 有些方案是依赖于 DevOps 的深度支持, 更有甚者是依赖于后端架构的一些修改才能开展, 而并不是所有公司的 DevOps 团队都能做这些支持, 也并不是所有的开发部门都允许这些修改, 那么这个方案在你们公司就无法落地.
像 Appium 几年前在 Mobile 测试产生的效果, 像 Selenium 在 Web 的效果, 抛开它们的一些缺点不谈, 整体效果上这些普遍适用的就是好的落地方案.
测试行业内小而美的工具永远是最帅的
以上仅代表个人观点

没人怀疑过可能是 Shadow 的问题吗? 排除 iframe 之后, 还定位不到的话, 大几率就是 Shadow 的问题了

最近看到帖子, 感觉帮了很大的忙, 谢谢 感谢.. 另外有个问题咨询下， 文章中的如下信息:

_rpc_reportIdentifier:: 向 webinspector 服务注册当前链接（传输 connectionId）
_rpc_getConnectedApplications:: 要求获取连接到 webinspector 的 iOS 应用列表
_rpc_forwardGetListing:: 获取某个应用的页面列表（传输 connectionId, appId）
_rpc_forwardSocketSetup:: 注册当前会话（传输 connectionId、senderId）
_rpc_forwardSocketData:: 利用某个会话传输数据（传输 connectionId、senderId、data）。Webkit 调试协议所传输的 JSON 就是通过这个方法传递的——JSON 字符串的二进制表达被通过这个接口传递到 iOS 设备上的调试服务。
另一方面，iOS 端也会传过来很多消息，同样遵循基本消息提的格式，常见的 __selector 有：

_rpc_reportConnectedApplicationList:: 回报连接到 webinspector 的应用列表
_rpc_applicationSentListing:: 回报某个应用的页面列表
_rpc_applicationConnected:: 某个 iOS 应用连接到了调试服务
_rpc_applicationDisconnected:: 某个 iOS 应用从调试服务断开

以上这些_rpc_xx 的信息, 如果想看更全一些的, 或者想知道最近几年的一些变化. 应该去哪里找呢? Google 了一下并没有相关信息. 所以想知道这些资料从哪里获得的..

非常感谢......

这个经验, 不一定是测试的经验, 局限不应该在测试上. 说白了其实就是解决问题的经验.
举个例子： 很多测试的文章在追求平台化, XX 平台分享. 但是大部分都留在了 Web 页面整合, Web 页面处理. 数据格式上. 花大时间在前端上在 UI 上在后端数据上. 但是往往测试的引擎 (语义: 指的依赖工具/包) 不变. 比如: 基于 Locust 的 XX 平台, 基于 Jmeter 的 XX 平台. 基于 httprunner 的 A1 平台, 基于 Httprunner 的 A2 平台. 其实根本上都是在做页面做数据格式. 真正起作用的还是 Jmeter, Locust, Httprunner 等.

真正的解决问题的能力, 应该较为深入一下.

总结: 个人理解, 测开不应该着相于 Flask,Django 上. 好的测开应该更倾向于解决方案/工具的提供上. 比如 Httprunner, 比如 tidevice, 比如 WDA, 比如 Locust. 比如 libimobiledevice. 比如...... 测试开发应该侧重于开发上. 提供测试方案/支持的开发.

你哪里设置了 70 并发 你设置的是 10 并发/User, 然后每个 User 的任务是挨个执行那 70 个 API.
我估计你对 Locust 理解错了. 和参数化没啥关系.

所以我猜测你的原意是想让你 Excel 的 70 个接口同时运行, 并且每个接口有 10 个并发？ 如果是的话,你估计需要分别对每个接口设置一个 Locust 脚本？ 可能是.....

如果对你每个接口 10 个并发这个数字 10 要求不那么敏感的话,也可以写一个 Locust, 然后用 task 装饰器装饰 70 个接口方法. 然后设置 700 并发. 权重一样的情况下, 每个 User 每进行一次请求都是从 70 个 Task 里面随机找的 (几率相等)

没明白你的描述. 但是从你截图代码中看到你代码设计的就是你 N 个接口逐个请求，　而不是 N 个接口并发请求．
而且, 你设置的 10 并发, 那么你的现象应该是 10 个 User, 相当于有 10 个 User 同时都在轮询你 Excel 中定义的接口, 而且是顺序逐步的.

看了下招聘网上测试开发招聘没有明确指定需要 django 能力还是 flask 能力
----测试开发的招聘为什么会要求 django 或者 flask? 难道测试开发岗位==UI/接口自动化岗位 + 测试自动化平台 (其实就是写 Case 执行 Case 的功能)？

""压力机用 1000 个线程还是 100 个线程，服务端的线程数也不同啊，并不是没有区别的，占用的资源自然也会不同""
压力机 1000 个线程不代表服务器也是 1000 个线程呀. 假设压力机开 1W 个线程. 线程调度时间大幅度增加, 服务器的线程就更小于 10000 这个数啦.

假设压力机调度 1000 线程用时间 0.002s, 如果被测 API 的服务器响应时间为 0.001s, 那么 理论上这 1000 个压力机线程最多只能造成服务器同时 500 的线程吧. 绝对的并发==并行, 如果要绝对的并发, 假设没有 IO 阻塞, 那只能开启 CPU 核心数量相同的进程数量来做了.

感觉并发数的概念, 很容易造成误导.

有点不太理解, 为什么要用假设 1 中的 1000 线程呢.
假如: 登录接口的响应时间平均 0.2 秒. 那么 1000 个线程会造成 5000/s 的 TPS 吧 (服务器没达到瓶颈的前提下). 而这个测试的需求: 秒级 1000 用户并发. 理解为 1000/s TPS 去测的话, 200 个线程数就够了.

前段时间做过一些系统的性能测试, 如果将常说的 1000 并发理解为 1000 线程话, 如果响应时间低于 1s 的时候, 很容易造成大于 1000/s 的 TPS 压力, 导致服务器过载.

所以现在我们的思路就是当开发提到某某接口预计要能支持 1000 并发的时候, 如果响应时间要求低于 1s, 我们往往会转化为 1000TPS 的目标去测. 而如果响应时间要求低于 2s, 那么就按照 1000/2s 的 TPS 去测. 这样出的结果, 也比较容易和运维抓到的客户当前的请求量相结合匹配.

所以, 是我理解错了吗

测试对应的性能测试感觉和开发对应的后端开发一样, 都是俩四字的名字. 都代表了较低的门槛和无限高的上限. 名字表达的意思太范围笼统了.

有点全家桶的意思了.

还有个原因是数据私密性,无法开放第三方实例的连接访问权限. 我觉得这个原因应该很多人共有.

之前在线客服跟你们提了一个需求 好像是"请求频率 - 流量数据"的精准回滚, 回复是不支持这个功能. 不得已只能自研了.

两周前看到了虫洞,感觉很炫的功能.. 今天就在论坛看到蓝牙鼠标模拟实现这块了, 不得不说论坛 666

如果有精力, 可以尝试仿照 WDA 的项目结构重写 YourWDA, 抛弃很多对你们被测项目来说用不到的情况. 预计运行结果会快的飞起. 对自己也是个很大的锻炼.

混合使用吧. 如果你们开发的程序支持 SDK 接入的话那么更好. 不支持的话,就混合多种常见方案吧. 比如 WinAppDriver + OCR/模板匹配 + 坐标偏移计算？
至于所说的不太稳定的问题, 其实 Window 程序的环境固定, 只要对业务情况加深熟悉, 是能够稳定下来的. 需要付出一些精力.
我们去年曾经搞过 SAP B1 的 Window 桌面自动化, 采用的方案就是 WinAppDriver + OpenCV + 坐标偏移计算 + SAP B1 UI SDK 接入. 混合使用的效果能够实现 80% 以上的常见业务流. 稳定性还算 OK.

传统业务没有接口文档挺常见. 曾经见过传统业务的 UI 自动化用例搞到 2000 多条的. 业务不同, 适合的方向不同.
可能你接触的这个业务不太适合搞接口测试? UI 搞起来.

自动化 != 自动化测试
自动化测试 != 接口自动化
离开业务去考虑自动化往往匹配不严合. 有的业务类型比较适合, 有的业务类型不太适合. 在不同的业务中, 自动化测试的发展方向不太一样. 实现的成本也不同.
但是绝大部分的业务,引入自动化测试是提高测试人员代码能力相对合适的提升路径. 一段时间之后哪怕是点点点提出的 BUG 也会提的比较精确. 减少很多开发 - 测试的沟通效率. 而从团队能力的角度考虑, 这种提升是非常友好的.