500 用户并发请求一分钟，实际的场景应该是我们的老师要上线上课了，大量用户登录并进入教室的场景，需求应该是不崩，且响应时间在几秒内吧，比如，5 秒？

这个还是有点模糊。可以再具体一点，比如预计大概会有多少用户进入教室，进入教室是 1 分钟内全部进入完毕吗？响应时间几秒内这个和你们交互也有关系，按照你们 app 交互设计，大概几秒以上会有不大好的体验？个人理解，性能场景设计的终点，就是要摸清系统要达到多少 TPS 才能满足实际业务的需要。增加虚拟用户增大压力，只是会增加响应时间，也就是体验上变慢，实际系统 TPS 达到上限就基本不会再增加了，变慢的本质是请求收到后都进去排队，而非立即处理了。

第二个问题，我问我们的开发应该是没有这种冷库机制，可能有分库分表的设计，但是我们的用户 id 都是递增生成的，我并不知道具体的分库分表逻辑

建议可以去了解下分库分表怎么分的。如果是按照 id 区间分，那有可能新的 id 所在表数据少，查询就会快一些，具体快多少要看你的表数据多大，如果命中索引，一般速度差别不会太大。

本质还是看重复 id 和非重复 id，背后执行的内容差异是否会引起性能差异，假设没有缓存都是落库查询，那就和你们数据库设计强相关，要看你们数据库设计上，不同 id 对应的查询，是否会有比较大的变化。

暂时还没确定，预计 7-8 月会开始卖，请留意社区置顶帖和公众号就好。

” 500 用户并发请求 1 分钟 “这种场景，是不是本身就是一个伪命题呢？

这个严格意义不算是性能场景，因为没有响应时间的要求，没法反推系统的 TPS 需要达到多少才能满足。

在不考虑缓存的情况下，我用同一个 userId，100 个线程同时请求登录接口，和 100 个不同的 userId 同时请求登录接口，制造的压力效果是一样的吗？

有没有缓存只是一个方面，关键是看系统在重复 id 情况下，是否每次请求做的事情，和不重复 id 做的一样。如果一样，压力应该就基本一致。举个极端点的例子，100 个不同的 userId，如果放在同一个表，且数据规模基本一致，那基本上就是一致的。但如果背后是分布在不同的数据库表，而且有的放在冷库冷表里（简单点说就是查询速度会慢不少）。那即使没有缓存，性能表现也可能会有比较大的差别。

个人观点，性能测试场景设计，需要尽量和真实场景一致是最好的，毕竟背后的系统深入了说涉及的东西挺多，比如查询结果的大小差异，也会影响性能表现。所以谁都说不准为了省事调整了场景后，是否会导致性能表现失真，尽量模拟真实场景反而是最简单有效的。

感觉你这个需求有点奇怪。

一般都是通过性能测试并调整系统，来达到 TPS 50 的，你这样刚好反过来，是怎么调整性能测试方式，让 TPS 达到 50 。性能脚本只需要模拟真实压力场景即可，这样出来的才是真实性能指标。

PS：我一般看系统 TPS 值，看的是虚拟用户数维持在一个水平的情况下，同一时间 TPS 的值。基本不怎么看聚合报告里的平均 TPS 值。

Selenium 4 中的 IDE 不仅仅是一个基本的播放和记录测试工具。与 Firefox 一起，它可用于 Chrome 浏览器（作为 Chrome 扩展程序）。

这句话读起来怪怪的，是机翻？

第二个点认同。

这个我觉得这个看实际需要把，各有各的道理。如果很关注入库正确性，最好是查下数据库。

这个情况，可以用 存草稿 功能来保存。

1、你说的同步计时器，是 Synchronizing Timer 吗？
2、如果同步计时器，指的是上面这个控件，那这个场景只有 1 个请求，好像没有设置同步计时器的必要（单线程情况下，本身就是一个请求收到返回结束后，下一个请求才开始发出）。能否把完整的同步计时器配置发下？有尝试过去掉同步计时器吗？

是不是没写完？

不明白为什么仅一次控制器控制登陆接口无效

不知道你说的无效，指的是不是设置了仅一次控制器，但登陆接口并不是只被调用一次？如果是，我解释下，仅一次指的是每个线程里仅执行一次此动作，相当于 for 循环里，只有第一次循环执行，后续不再执行。与之对应的是默认每个线程循环执行所有动作，直到到达时间要求或者其他限制条件。

如果你有多个线程，实际就会不止执行一次了。如果要线程数量无关地只执行一次，类似方案二这样的方法会更合适。

有兴趣可以看下官方文档的说明：https://jmeter.apache.org/usermanual/component_reference.html?#Once_Only_Controller

一般来说 TPS 跟并发数有关

你这里的并发数指的是 Jmeter 的并发线程数吗？如果是，这个和我理解刚好相反，tps 和 Jmeter 的并发线程数无关，只会和应用服务性能有关。只是现象上如果并发数过小，会导致应用服务的各个线程并非持续处于负荷状态，所以计算出来的 tps 会比极限值小。“并发为 1” 和 “1 秒只有一辆车过” 是两个不同的概念，并发为 1，但服务器性能高，响应时间为 100ms，那 1 秒可以处理 10 个请求，一样可以产生 10TPS。

这个具体要看你找的工作的 jd 要求了。

个人常问的一般有几个，仅供参考：
1、你用的这个 基于 robot framework 开发的一个第三方工具 ，大致的原理是？是否有可能搬运到新公司用？
2、你使用的 UI 自动化工具（如 appium、selenium）背后的大致原理是什么，比如从 findElementByXX 到获得返回值，背后发生了什么。
3、现有多少用例、一次执行大概多久、执行频率多高、稳定性多高？落地运行 UI 自动化用例过程中，对于提高稳定性，你之前是怎么做的，效果如何？
4、你觉得你现在做的 UI 自动化，有哪些做得好的，有什么做得不足的，不足的点有什么改善想法？

大多投递议题的，基本都直接发到投递议题的入口了，截止目前已经收到十多个议题了。

这里没啥回帖不一定代表热度不高。

看了下末尾的思考，有几个点说下我的不同见解：

1、测试开发后续不会越来越少，只是纯做工具平台的越来越少。测试开发慢慢已经从工具平台开发，变为能运用技术解决测试效能问题的岗位了。往后更需要的是更强的解决问题的能力（能运用技术去解决本身就是更强的能力了），而不仅仅是开发工具平台。

2、devops 方向，看描述更多指的是运维开发。这方面接触不多，不作评价。

3、单独从技术方面说，个人觉得，大数据和 AI 在未来是趋势，尤其大数据（目前其实挺多公司的运营指标等都是基于大数据来出的了）。目前其实挺多时候大数据的质量还是没有特别好的保障的（报表延迟、内容不大对、响应报表需求慢等），只是现在直接基于大数据做比较核心业务的功能比较少，出问题也不至于是最高级别问题，所以不少公司还不大愿意投大精力去改善这部分质量而已。

4、从个人发展角度，技术总归是有天花板的，而且由于技术发展非常快且颠覆性强（比如移动互联网，以前做服务端的经验放到移动端基本用不上），所以有些技术就算再熟悉，一旦过时价值就低很多了。所以如果放未来 5 年规划来说，更建议是走管理方向，或者至少是团队 leader 方向，这个天花板才更高。如果只是说 2-3 年内规划，选择有前景的技术方向也是听不错的。

建议你找到你工作上需要用到什么，再针对性学习。比如现在 ui 自动化的落地还有什么问题需要解决，或者除了 ui 自动化还有什么地方需要提效，大概需要什么技术。

学了但用不上，自然觉得价值低，而且效率也不高，熟练度也不高，成为不了真正的技能。

比如我之前需要二次开发用例管理平台，就重新复习了 java，学习了前端的 vue+react。后面需要做云真机，又去学习了云真机要用到的相关框架工具（这个得靠自己调研和同行交流，没有啥现成的材料可以直接学习）。学完再用到，不仅更牢固，而且产生的价值也更高

你这个立即停止，线程应该没法满足。

1、目前应该没怎么提供直接停止线程的方法，大多是在线程内部执行时通过一些轮询来确认是否有停止记号，如果有记号就线程自己停掉，没记号就继续执行。
2、另外，python 的线程由于解释器有 GIL 限制，和其它编程语言不大一样，实际并没法通过多线程用到 cpu 的多核性能，有点像是 伪并发 。所以 python 并行多任务大多用的多进程，多线程用得比较少一些，一般只会用在异步任务（比如等待网络 io）。不过看你这个场景应该用不着榨干性能，应该还好。

你这个场景，建议可以考虑改为用多进程（multiprocessing）？多进程的话通过 kill 发不同的信号量，可以做到仅给退出信号（类似 ctrl+c），或者强制直接杀死进程（操作系统直接杀，进程自己没有拒绝权利，比较符合你说的这个要求）。

啥意思？

Error: timeout of 240000ms exceeded

意思是某个处理已经达到 240 秒（4 分钟）极限超时时间，但还是没有返回。

背后可能是系统卡死、uiautomation 进程卡死等，这块需要结合 andorid logcat 日志才能分析定位。但和你 systemPort 应该没啥关系

以下个人理解：

数据仓库，属于大数据的概念，指的应该是存储基本所有待分析的有价值的数据的位置。一般用 Hive 等大型数据库存储。所有的分析报表都从数仓出来，所有有价值的业务数据最终都汇总到数仓存储。
数据工厂，或者叫造数据平台，指的是测试过程中快速造数据的工具
数据中台，属于大中台概念的一部分，指的是大数据的所有操作（包括数仓、数据处理、报表等）都集中到一个大服务中完成。日常的业务需求（比如新建一个报表，新接入一个数据源）都在数据中台中进行配置即可。与之对应的概念有业务中台、测试中台等

至于数仓怎么测试，目前我也没接触过，但艾辉老师的《机器学习测试入门与实践》有大致提了下，可以看看了解下。

wireshark 可以抓到，但抓到你也不一定能解析或者模拟。它用的可能是自定义协议，或者类似 proto buffer 这类没有协议解析工具没法正常解析的协议。

其实前面的同学已经给了几个可行的方案了，只是基本都绕不开开发的。推荐你还是找你们开发聊一下吧。

这个理解没错。

主要是支付的交互不是简单的一个接口就搞定的事情，毕竟涉及安全 + 异步（一般支付背后涉及很多方，耗时很难确定，所以都是做成异步式交互的），所以需要先搞清楚你们系统的交互。要不找不到对应在哪里 mock 掉它。

另外，抓不到包应该不是因为加密，加密只会让你看不懂，不会抓不到（如果加密后会导致抓包工具抓不到，网络传输一样也会识别错误，因为协议本身定义的部分，怎么加密都是不能改的）。抓不到一般就是抓包方式和传输协议不一致了。

比如微信 app 支付这种方式，下图这个位置的交互，很可能就不是走 http（据我所知，微信 app 和微信服务端，走的都是 tcp ，正常微信发消息的通讯交互，你用基于 http proxy 抓包的工具，如 charles、fiddler ，也一样抓不到）。

有其它办法，比如直接仿照系统的业务处理逻辑再写一遍，开发怎么产生数据的，造数平台也一样逻辑去产生，但这么做成本太高了。

相对而言，用接口等系统提供给外部调用的入口来造数，相对维护成本低不少。而且流程性接口用例本身就是自动化测试的产物，用来造数据属于水到渠成，也没有太多为了造数据而额外付出的成本。

或者你也可以先分享下你们的现状，以及你们现在人工造数据大概是怎么做的？

请描述清楚你的问题，插件的定义太广泛了。。。

那就爱莫能助了，和第三方支付的交互一般都不止一处的，不找开发确认清楚交互，比较难绕过。

或者可以试试用 UI 自动化来绕过呗。

但不是每次点击都有内容输入

有内容输入说明是有可能成功的。你对比看下成功的和不成功的，有没有什么差异？

你有能力直接看项目代码来了解交互也可以，但问开发效率更高，而且后面遇到阻碍也容易找开发协助处理（比如鉴权太复杂，模拟成本很高，让开发开个可以跳过鉴权的后门，成本会低很多）。

我理解这只是一个比较简单的合作而已，你们是有什么特殊情况，必须纯测试团队解决这个问题吗？

我指的是你的系统交互，不是用户交互。即你们的业务系统是怎么和第三方系统交互的，涉及哪些端、哪些接口等。

给你一个微信支付里的示例（只是微信支付提供的其中一种接入方式，具体你们怎么接入的，你还是问你们自己开发吧）：

https://pay.weixin.qq.com/wiki/doc/apiv3/open/pay/chapter2_5_2.shtml#part-5

PS：微信 app 和微信服务端交互走的是基于 tcp 长连接的自定义协议，普通 http proxy 这种抓包是抓不到的。