不好意思，确实我之前逻辑不够严谨。在服务端没有达到满负荷（即服务端每个处理线程都在工作中没有闲置，也是我们俗称的性能拐点）时，确实是压测工具的线程数增加，响应时间不变，tps 增加。

我其实核心不认同的应该是 线程数=并发 这个观点。我对这个观点的理解是：针对正文里的 登录接口能够承受秒级 1000 并发 ，就应该用假设 1 里面的 1000 个线程去发起压力，并要求响应时间达标。

在我的经验里，一般在线程数在比目标 tps 低不少的时候，系统就可以达到目标 tps 了。真要用和用户数一样的线程数去压且不考虑思考时间（现在越来越少人用这个了），容易给到过大的压力。

如果实在无法改变，那就先保持一致吧。

我一般的做法是，把产品的性能需求想办法转换为 tps+rt 目标指标，然后再去拿这个来和开发运维沟通以及出报告。一般其他角色只要觉得你的转换思路听起来是靠谱的，那他们也不会说你非得怎么怎么样，毕竟这个不是他们专业范畴，一讲深他们其实也就听不懂了。

一般不是业务和产品喜欢用并发用户数 +rt，开发运维喜欢用 tps+rt 吗？你意思是现在开发和运维也喜欢用并发用户数了？

一般高并发（线程）才能达到高 tps

这个结论和我日常认知差异有点大，建议你试试用 10 个线程去测试某个逻辑比较简单的接口，然后换 100 个线程再测一次，对比看下 10 个线程下的 tps ，和 100 线程下的 tps ，差异会不会很大？

个人理解，专业的性能测试人员，应该要用 TPS + 响应时间 来描述服务端性能。包括要达到的性能目标以及实际测试出来的性能结果。

• 先来解析下你正文里这两个看起来好像等价的假设：

假设并发理解为线程的话，1000 线程持续执行 60 秒，结果理论上应该产出 60000 条数据才符合需求

其实你这句话里面带有一个预设条件，就是每个请求的响应时间大约是 1 秒。要满足这个场景，性能需要达到 tps = 1000 + 响应时间 = 1s

假设并发理解为 TPS 的话，可能花 30 个线程就可以达到 1000tps 执行 60 秒，结果也能产出 60000 条数据

而从你这句话来倒推，30 个线程能达到 1000 tps ，意味着平均每个线程每秒得产生 33 tps，意味着接口的响应时间必须控制在 1/33（约为 0.03）秒左右。要满足这个场景，性能需要达到 tps = 1000 + 响应时间 = 0.03s

所以，加上响应时间这个指标后，你能明确看出来，这两个场景下对服务端的性能要求其实差了 33 倍了吧？

• 至于为啥大家会喜欢用线程数，我觉得里面有一些历史因素。

以前 LR 类似 JMeter 线程数的东西叫做 virtualUser（虚拟用户），意思是这个就是虚拟有多少个用户在使用。同时为了让这些用户表现更符合实际情况，还会有需要在每个操作之间加入 thinkTime（思考时间，实际就是固定的等待时长）。所以我只需要评估高峰期大概系统会有多少个用户来用，正常用户习惯每次操作之间间隔多久，就可以把这个场景直接输入到性能测试工具里，直接作为性能场景使用了。

但随着时间推移，这个思考时间越来越少人用或者考虑，因为不管设定多少都很难靠谱，而且思考时间差 1 秒，实际发起的压力就会有很大差异。但虚拟用户转变为线程数继续留在了 Jmeter 里，所以大家会习惯继续这么称呼，毕竟老板和产品更能听懂 “并发用户数” 这类词。但实际上只要稍微想细一点，就会发现不精确，因为这个场景下，线程和实际用户的核心差异是，线程得到响应后会立即再次发起请求，但实际用户谁有空没事做会一直不间断给你发请求呢。

因此，一个合格的性能测试工程师，应该能做好翻译工作，把老板和产品的想法，转换为专业的性能指标，应用到性能测试里。

哦哦，OK。

嗯嗯，大概理解了。你们的术语用法有点特别。

你这里的灰度测试目的是发现由于测试环境差异引发的问题的，这种我们一般称之为 “预发布测试（为发布做准备的测试）”。预发布环境用的是线上数据，也和线上环境在同一个机房环境，但入口是只有公司内网可以进入，外部用户进不来，测试期间用的也是测试人员自己的账号，而非外部用户的账号，保障就算出问题，对外部用户影响也为零。

预发布在互联网里面很常见，也很有效（能有效验证开发发布时做的各个配置项改动是否都合理到位，且由于环境完整，有些涉及第三方系统的测试也可以完整进行）。大部分在测试排期时就会单独排出来预发布测试阶段的。

而我们一般说的 “灰度测试/灰度发布”，指的是在线上环境只更新少量节点结合流量控制，做到只有小规模用户使用新版本的效果。如果出问题，会真的影响外部用户，只是用户规模会比全量小很多（一般 5%-50% 不等，可以自行控制）。详细的你可以搜索引擎看看。

方便把你项目其他无关信息精简掉，只留下能重现问题的最小项目内容，打个包或者上传 github 仓库后发一下不？

我这边没遇到过你这两个报错，不好评估。

这帖子正文看的云里雾里。。。

楼主到底是想问值不值得去，还是想问灰度是不是就可以解决发版晚的问题？

如果是前者，这个主要看你自己，有些业务性质决定确实只能放深夜发版，你很难改变业务，只能自己。

如果是后者，建议楼主先把你们家的灰度是怎么做的说清楚。正常灰度发布是按天算的，否则灰度的量不够，不具备代表性。而楼主这种感觉不像是正常的灰度。

感觉楼主这几个问题有点奇怪。楼主理解的灰度发布是什么？

我理解的灰度发布本质上是小规模线上新版本测试，降低出线上问题的影响用户数，进而降低线上问题引起的损失。它和我们日常主动做的回归测试完全是两码事，出问题是切切实实影响用户的线上问题。

在灰度发布的时候如果把问题都修复好的话，那全量出问题的概率确实是会降低，但 “不容易” 这个用词我觉得不妥，好像有了灰度发布后线上很难出问题一样。这个和灰度的量有多少，很大关系。

全量发布测试时间是否能大大缩短 不知道你这里的 全量发布测试时间 具体是啥时间？如果是指上线前的测试时间，我理解灰度并不是决定能否大大缩短的核心因素，核心因素应该是对出质量问题的容忍度，或者说可以接受出多大程度的质量问题。测试阶段在模拟环境进行，就是为了把出问题造成的损失降低为零（都是自家人自家数据），而灰度阶段出问题，这个损失并不为零，只是规模相对全量可以小一些。所以如果对质量问题容忍度高，允许一些规模相对不大的质量问题出现，那部分测试内容可以直接挪到灰度发布阶段由线上用户做小白鼠验证，这样是可以缩短测试阶段耗时的（测试内容少了），但如果容忍度不高，那测试内容很难挪到直接在灰度阶段验证，那就很难减少了。

1、每次查询，是基于当前页面的全部 html 来进行查询的。iframe 是比较特殊的标签，在 webdriver 里面一个 iframe 就相当于一个独立的页面，没法跨 iframe 查看里面的 html 内容，所以需要用 switch 语句才能切换 iframe 。

2、你这里面 aa 和 bb 都在同一个 iframe 标签里，所以不需要切换 iframe ，直接查就好了。

不知道楼主除了从怎么做场景模拟的角度外，有没有考虑过分析这类故障出现的原因？

我们以前类似这种测试环境没问题，一到线上大数据量就扛不住的情况，大多是 sql 本身写得不好，没命中索引引起全表查询导致。测试环境数据量少，所以全表查也没多慢。线上有些大表是千万级数据的，全表查一下就 gg 了，不仅接口响应超时，还可能由于占住了连接数，导致数据库很快连接数资源就被用尽，引起所有查库操作卡住的大问题。

如果楼主是类似情况，可以考虑在测试环境做一下所有实际执行 sql 的监控及检测。现在有一些 sql 检测工具是可以直接自动分析出 sql 的执行是不是会引起全表查询的（或者简单点，拿到线上库里分析下执行计划，也可以看出查询数据量情况），只要查询量达到一定量级，有性能风险的，都直接做预警，要求优化后才能上线。印象中 mtsc 大会上唯品会、微众银行也有类似这样的 sql 性能检测实践经验分享。

我们之前的监测预警有点简单暴力，主要是通过定期统计数据库落库数据来做的。

支付相关检测指标大概有：最近 5 分钟的支付发起数、支付成功数、支付失败数。每个指标除了绝对值，还会在曲线图中展示前一天的曲线和今天的曲线。这些指标的数据来源都是实时查询数据库里的数据（为了这个专门弄了个监控系统专用从库），有一个专门的大盘界面可以直接看到所有指标当前值及预警情况。

预警机制：失败数绝对值达到一定数量会直接自动电话预警（这种一般说明是出现严重故障了），成功数/发起数差值百分比达到一定程度会发消息预警。每个预警在大盘里会记录持续时长、跟进人这类信息。

另外，当时因为比较关注线上质量，还弄了一个专门的监控室，招专人排班 7x24 小时值班看大盘指标及预警数据，如果判断认为问题比较严重，人工通知检测指标对应的负责人（大盘系统里每个指标都会登记负责人信息）去排查确认。

从声网的建立初始就有了对可用性的投入，到现在已经成为了内部的标准与体系（见下图）。

这里的图好像没了？

hmm，做第三方支付服务的监测会比较麻烦，建议优先建设好预警机制，再补充主动检测机制。

你说的这两个，实际实施会遇到一些难点：

1、UI 自动化，有可能支付环节的输入密码都会做一些安全限制避免系统自动输入，这个会提高 UI 自动化的成本。

2、第三方提供测试账号这个，测试环境可能还可能提供。线上正式环境，三方支付一般只是中间商，背后他们还会再连接很多级的第三方系统直到银行的系统，基本上不可能存在能打通全链路的测试账号。

这种可以做的，不过这样只校验到自己的系统，可能作用不是特别大。

按我之前的经验，一般支付系统最常见的线上问题是外部第三方渠道的问题（比如他们要维护或者出线上问题导致链路不通，然后需要调整配置把这个渠道的流量比例降低到 0），自家系统出了上线变更或者基础设施负荷太大处理不过来外，相对比较少出问题。

怀疑是服务器被攻击了，导致处理不过来返回 502。。。

hmm，确实不大好。

晚些换个静态页替换掉 nginx 默认自带的这个页面。

不知道你这里的白名单，具体是指什么白名单？

我们之前支付环节不怎么做拨测，主要做监控 + 预警。主要原因是一般为了保障高可用会对接多个支付渠道，而支付渠道不同，背后走得第三方系统乃至自家系统配置都不少差异，要通过拨测覆盖成本不低。不如做支付失败数量，或者支付成功订单和前一天环比数量波动情况的预警性价比高。

这个问题描述看得我云里雾里。。。你的问题具体是什么，具体哪几行代码截取到的图不是指定元素的图？那截到的是什么图？

作为测试，描述问题请像报 bug 一样专业吧。

有这段代码的话，测试任务还是需要加锁的。因为测试任务里面的测试结果，pr 里面是不带有增量保存的。
同时前端记得按照我 pr 的说明里适配一下。

然后对于清除执行记录这个，我瞄了下我的前端，原来没把这个功能迁移过来。。。所以我只说思路吧。

思路是给服务端请求了 clear 清除了对应的测试结果记录后，把新结果的 json 对象更新到 VueTestcaseMinderEditor 的 init-json 属性绑定的对象即可（印象中 react 要显式用 set 属性名 的方法才能更新指定对象，而 vue 直接更新绑定的对象值即可）。组件内部有对这个属性值进行 watch 监听，一旦检测到变更，会立即变更自己的展示内容。

1、 前端想加上这个清除结果功能的时候，发现后端里面还调用了 websocket，会报错 ，不知道您的解决方案是？

你的服务端用的是 agileTC 么？清除结果的核心是清理掉数据库里 exec_record 表里的内容，清理了这里后重新从服务端再拉一次合并测试结果后的用例数据，就是清除了所有测试结果后的数据了。

2、保存 baseCaseContent 内容，在分配多个子任务的情况下，需要获取到全量的 baseCase？还是说只要获取到当前子集的 baseCase 内容？

没太明白你的问题，这里的全量和子集具体是指？

然后如果是使用这个组件配合 agiletc 服务端使用的话，多人协作这块可能你需要花点精力处理下，比如加个锁或者让服务端能做增量保存，否则按照默认情况，是会出现相互覆盖的问题的。

客气啦。

PS：建议你用下 python 的语法糖，用

code, udid = get_code()

这样的写法，会更清晰简洁。

你的工程代码方便分享下不？之前也有同学反馈过，但我这重现不了，不好处理。

额，排查说不上，只能说给些思路参考。

你这里报错的原因上面已经有同学说得很清楚了，原因是 find_element_by_class('android.widget.button') 没找到元素，所以返回的内容是 None 。一个 None 类型的对象，是没有 click() 方法的，所以才会出现你正文里的报错。

相当于你直接运行 None.click() 这段代码，这样会报正文里的错，应该显而易见吧。

然后你说的 最后测试跳过这个元素，操作点击其他的元素的时候同样也会报这个错误 ，没看懂你这里跳过是什么意思，请把你改动后的代码以及错误信息都贴上来吧（请不要截图，直接贴文字，截图看得好累。。。）