测试执行比较明确，对错也好判断，现阶段无非就是贵和耗时 (除了模型本身速度，还需要考虑错了重试的消耗)。
用例生成这种看起来简单的，生成出来的效果反倒是最差的。
特别是迭代到中后期的业务还要涉及到之前的相关文档，压缩也无法明确哪些和本次有关系，会不会被压没了

什么？界面可信度为啥要找 70 位测试去打分？这不是产品经理和 UI 要做的事情么

测最大可以承受多少并发很麻烦的。
不如用最大 tps&当前的并发&响应时间估算

感觉你的视角有问题，要测路口，关注的只是这个条路每秒能过几辆车。 每辆用时多久。
并发数只是用来保证这条路是饱和的，每个口子都有车在过。四个口子的话只要保持 4 的并发即可。
就算加到一万辆车一起过，除了在过口子的车，其他车都是无效的压力。因为对于四个口子的路口来说他们当前也只承受了 4 个并发而已，后面的车他们感知不到的。

只有这条路有 1W 个口子可以并排开过 1W 辆车的时候，并发才算是 1W

TPS 怎么算出来的是 4？

并发是 TPS* 平均响应时间，2*1.5 =3 啊。
并发 3 是意味着一直保持有三辆车在过闸口。

要是你说一共只有 8 量车，那并发量其实是根据时间在递减的。
你想啊，过了 1 秒后，还剩 4 量车，这时候并发还是 8 么？

TPS=并发数/平均响应时间是对的
TPS=总请求数/总请求耗时。
总请求数=并发量 * 总请求耗时/平均响应时间。

没办法，实在琢磨不出来，为啥我的反问句会被理解成疑问句

那线程在等什么呢？ 等迟钝了的服务器的返回对不对？ 压力没增加那为什么服务器迟钝了？

高线程等不等于高压力？44 楼的回帖你真的看懂了么？
增加线程没有增加压力的话，那服务器响应的延时会增加是因为什么呢？