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 了一下并没有相关信息. 所以想知道这些资料从哪里获得的..

非常感谢......