公式： PV*80% / 3600*20% =TPS 的值 3600 代表 1 个小时 3600 秒】

看了下，你这个公式好奇怪，为啥直接用一天的 PV 去除以一个小时的 20% 时间？一天 80% 的接口访问量都在 12 分钟内灌进来？这个比例有点夸张了吧。

日 PV 是一天的量，性能测试里常说的二八原则一般是指 24 小时里，80% 的访问集中在 20% 的高峰期，按照这个去推算，峰值 TPS 应该是 日 PV*80% / (24 小时 *3600 秒 *20%) ，按你这里 17W PV ，算出来应该是 7.8 左右 ？

PS：TPS 是接口维度的数据，PV 是用户维度的数据，用户和接口是一对多的映射关系，而且随着活跃度差异、接口逻辑差异，这个一对多比例也会产生很大差异。所以你直接拿 PV 来算，算出来最多就是一个当天首次访问获取 token 这个接口的 TPS，并不能代表整个系统各个接口的 TPS 要求哦（比如平均一个用户会查看 10 个商品，那商品查看接口的累计访问量应该是 PV 的 10 倍。个人了解电商购物类网站，商品查看一般调用频率也是最高的，所以也是最需要做缓存、性能优化的地方）。

如楼上所说，不结合业务场景和逻辑，单靠一个 UV/PV ，实际是算不出系统各个接口的 TPS 目标值数据的，这样得到的数据大部分情况下会比实际值小，就算达到了也不代表能满足实际业务需要（比如按照前面的假设，商商品查看接口 TPS 目标不应该只有 7.8）。建议先理清楚核心业务流程背后接口调用时序，然后顺着业务逻辑来评估几个调用量比较大的接口的目标 TPS 吧。

是的，这个和业务场景会比较强相关，不同业务场景要用不同的压力策略模拟。

算出来的 TPS 分别是 16 和 23 ... 给一个接口跑了几遍 20 人的并发，TPS 都是 500+，不知道这又是为什么，查了这么多？

首先，TPS 有分目标值和实际值，目标值是按照你业务评估最低要达到的值，实际值是你实际压测得到的值。性能测试就是要让 TPS 的实际值大于等于目标值，响应时间的实际值小于等于目标值，才能算通过。

所以你目标值是 16 或者 23，和实际值达到 500+，是没有问题的呀，说明你的系统单个接口的性能可以满足要求。但是否可以通过，你还得测试下多接口调用的混合场景才能确认。

怎么决定开始人数和每阶段增加人数以及每阶段持续时间？有没有大佬能给个通俗易懂的讲解啊？感激不尽！

之前看了极客时间高楼老师的课，他的观点是：这个不重要，选一个能看出阶梯性的值即可，比如开始时 10 人，后续每 1 分钟增加 10 人。观察 TPS 是否也是按一样的阶梯上升，大概到多少时 TPS 不再上升而是响应时间增加（说明到了性能瓶颈，压力再增加，只会继续增加响应时间影响用户体验了）

至于并发线程数和用户数的关系，其实可以说是没有很明确的关系，毕竟你 100 人同时在线，根据业务情况，有可能每个用户都很活跃达到每秒 100 TPS（比如秒杀），也可能其实操作不频繁每秒 5 TPS（比如发信息，打字要花不少时间）。以前性能测试的书也会告诉你，最高峰 100 人同时在线，对应压测工具并发用户数不一定是 100 人，因为还有并发度或者思考时间什么的。而高楼老师进一步简化为了：压测给了多大压力不那么重要，重要的是找到系统性能瓶颈在哪里（TPS 到了某个值，再加并发线程数都不会上升，就表示达到瓶颈了），并根据达到瓶颈时的 TPS 是否可以满足业务需要来判定是否通过。

我个人还是挺认可高楼老师的观点的，毕竟确实没有非常有科学依据的公式去倒推各个客户端合并给到服务端的压力多大，那些传统的二八原则，拉一下实际线上监控数据看看，其实很可能真的不是这个比例。至于目标 TPS 要达到多少，可以结合实际场景的接口调用逻辑 + 用户操作场景，设定初始值，然后和产品、开发沟通，得到一个相对靠谱的值。最靠谱是直接拉线上监控数据，但新系统新业务是没线上数据的，所以主要靠前面说的去推断。

但是我很难做的部分是，当请求发出时，客户端收到 mqtt 的信息并且发送新的报文给接口。两个步骤如何同时进行。

这个点还是没明白，为何需要同时进行呢？

我确认下你接口内部逻辑实现，是否和我理解一致：

1、服务端收到请求
2、服务端通过 mqtt 发送消息给客户端
3、客户端收到消息后，进行处理。处理完毕后通过 mqtt 发回
4、服务端收到 mqtt 中客户端发回的结果，或者达到超时时间，发出 response

按照这个逻辑，没有异步的部分在里面吧。我理解的异步定义是获取任务后，立即返回一个已获取，然后后台处理任务，处理完毕再按约定的方式通知回去。但如果按我上面理解的逻辑，里面没有 立即返回结果 ，而是等待后台处理完毕再返回，所以我理解这里没有异步，都是同步。

不过是否同步异步不是关键，这个只是名词定义问题。关键是你的接口内部逻辑实现，到底是怎样的，建议可以画个类似 UML 时序图的东西阐述，不要用任何概念名次，这样会更清晰。

那这个得找你们公司网管看看了，这块我们无法触及。

看这截图，里面这个像是 h5 或者自定义 view，所以采集不到内部控件树。

你问下开发，这个是 webview 还是什么？

实在不行就只能用图像识别找控件了。

标题没看懂，内容勉强看懂了。我理解这里没有任何的异步，都是同步，接口实际还是要等待 mqtt 返回报文后才会返回。建议楼主先了解下异步和同步的概念？

回到问题，你先明确你要测的是提供 mqtt 消息处理的那个服务的逻辑，还是接口自身的逻辑（比如先查缓存后发 mqtt，等到 mqtt 收到返回，接口才返回 response）？如果是前者，不管接口直接测就好。如果是后者，可以想办法监控 mqtt 的消息收发情况，然后确认这个收发情况是否符合逻辑。

之前我们测试 mq ，要验证某个接口请求背后是否真实发出了 mq 消息，mq 消息内容是否正确，用的就是类似的手段。大概思路是给 mq 打开一些 debug 类开关，让它日志记录所有消息的收和发。然后再通过过滤日志，找到指定 topic 的消息，进行断言。

写成伪代码，类似于

# 调用接口
resp = request.post(xxx)
# 检查 topic 为 abc 的队列，在最近5秒内是否有一条包含 "userId: xxx" 内容的消息
mqAssert.topic("abc").timeout(5).contains("userId: xxx")

额，怎么隐藏的知道不？得先知道隐藏原理，才好推敲怎么识别吧。现在信息太少，没法给具体建议，硬要说就是先了解下这个是什么元素，怎么隐藏掉的。

PS：你这个截图也看不出来这个控件树是怎么 dump 出来的，dump 的具体方法也同步下？除了这个控件树，是否也可以提供下 app 的截图？要不光看这棵树啥都看不出来。

可以看看最近几届 MTSC 大会的议题，包括最新这届的：
http://testerhome.com/topics/31136

可以看下这篇：
jacoco 的 merge 源码分析

顺便给下搜索姿势：https://cn.bing.com/search?q=jacoco+merge&form=QBLH&sp=-1&pq=jacoco+merge&sc=0-12&qs=n&sk=&cvid=BF1058EE68D344DDA786303CAA5145A9 ，下次建议可以自行搜索下

你这个场景，jacoco 的解决方案是多个覆盖率数据的 merge 。比如指令 a 在第一个数据里是未覆盖，第二个里是已覆盖，第三个是未覆盖，那 merge 后 a 就是已覆盖。整个 merge 是基于一个基础数据基础上，合并后面的其他数据，所以对于你说的 “修复 bug 后想要补上之前的覆盖率”，那你 merge 里基础覆盖率数据必须是修复 bug 后的最新数据。
至于报告，都是基于覆盖率数据生成的，只要预先 merge 好数据，报告内容也会是 merge 后的数据。分母就是你 merge 里基础覆盖率数据里的总数，即修复 bug 后的最新代码产生的数据。

但有一个点，如果要 merge 的覆盖率数据中，第一次的数据和第二次数据对应的代码是不一样的，那 jacoco 会以类为单位，哪个类不一样，那这个类就不会 merge ，只有一样的会 merge 。我发你的文章里对源码的分析也把这部分说得很清晰了。所以会出现，开发有改了代码的类，以前你可能已经覆盖过其中一些方法，但合并后这些方法还是会显示为未覆盖（因为类改了，merge 时这部分数据对不上，所以被丢弃）。

加油！

不适应是好事呀，说明是个可以得到学习提升的地方。

之前也有遇到过，接口测试刚接触，产出慢，自己天天加班都达不到要求，心态会有点崩。当时是找了一些身边的同学多交流沟通尽快提高自己的技能，也找一些好朋友偶然吐吐槽，周末多做点自己喜欢的事情转换下心情。这样持续一段时间后，这道坎就过去了，而且自己也掌握了新技能，反过来看其实会很感激这段经历。

一般代理有设定好规则自动 rewrite 的手段的，可以试试，这样不用担心 timeout 。

你是不是手动改的抓包数据，改太慢所以客户端等不及 timeout 了？

帮你加了下代码块排版，终于看到缩进了。。。

你用 pycharm 具体是怎么执行的，也发一下具体步骤？如楼上所说，你这个文件里没有可直接执行的方法，都包在 class 里面。如果直接用 python xxx.py 这样的方式调用，实际里面没有任何一行是可以直接运行的，所以也是直接 Process finished with exit code 0 的

要具体看你的上报事件是客户端上报还是服务端上报的，什么逻辑下才会产生。

如果是客户端根据服务端返回值进行上报，抓包修改服务端返回值就好了。

如果是服务端上报，那得再分服务端这个 fail reason 是根据什么得到的，如果是基于数据可以改数据库，基于下游接口可以 mock 下游接口。

现在描述的信息不够具体，所以也没法给准确的建议。

有自己内部平台，基于 agiletc 做的，也是 xmind 形式写用例。

xmind 优点是编写简单，缺点是别人相对没那么容易看懂（也有办法优化，写细一些，有问题能问人就行），适合经常有新功能要写用例，且大部分用例其实不会换着人重复执行的场景。互联网大多是这种，就算是发版固定要跑的场景，xmind 写细点其实也够用。

excel 优点是很规范容易统一，缺点是写起来的成本比 excel 高，适合写完基本就不怎么会改，且会需要换着人执行的情况。只是互联网现在这种情况太少了，所以用得很少。

至于你提到的 excel 听说很多大厂都用这种 ，建议细问下是大厂的啥业务，啥场景（比如给流动性很高的外包纯执行用）？不能听到大厂就直接追随，大厂通常有很多不同类型的业务，不同业务差异还是很大的。

想问下，这个是稳定重现么？好慢具体是多慢（多少秒，浏览器开发者工具里，network 部分截个图看看就最好了）？完整的操作步骤发一下？

我这试了几次，都挺快的，基本 1 秒不到就加载完了，没法重现，所以也没法了解到你具体的情况。需要你多提供点信息。

3 年还年轻，多看看外面的世界吧。

另外，提了离职就不要考虑回头路了，你的上级都知道你的心不在这，就算你留下了也不一定会主力培养你。何况你也说了，已经没太多成长，为了这 1K 放弃后面更大的成长（前提是你确认新岗位真的能成长更多，这点你可以找你未来 leader 多聊聊），不大值得。

可以具体说下什么项目，安装不了是报什么错？

个人经验，开源项目的作者对项目太熟悉，有些细节可能会遗漏写到文档里。而且也不一定有条件在各种环境下安装，所以大家实际在其他环境下安装，可能会出现一些作者不会遇到的问题。需要自行踩坑填坑一下。

有问题安装不了，更建议大家社区发帖咨询沟通哈，安装文档都是需要大家持续反馈，持续迭代更新，才会越来越好的。说不定作者也在社区，这样交流起来也更便捷。

哈哈，感谢支持。当时其实也是刚入门接口测试，会有挺多困惑的，所以写下来也是为了帮助自己更好总结理解。

后面你对这个自动化意义有新的感悟，也欢迎来社区分享哈。学习了很多东西后，个人感觉，对术（怎么做、遇到的典型问题可以怎么解决）了解多了后，总结成道（能做什么不能做什么，什么时候适合什么时候不适合），会更容易记忆和应用，也避免跑偏用错，产生负效果。

那么基于场景得接口自动化意义在哪里？

个人理解主要有几个意义：
1、能高频跑，更早发现问题。我们之前最高频率是每 30 分钟跑一次，失败立马预警，开发立马修复。这个换成人力跑成本太高了，而且有些核心问题如果到末尾回归再发现和修复，时间会很紧，改过的代码多，找问题原因也会更加费时费力。
2、减少人工测试要跑的场景数量。主流程人工过一遍这个省不了，但工作量比全部过一遍要少不少了。
3、如果自动化校验点足够齐全（包括数据库校验等所有人工测试会验证的都有验证到），且修改点确认只有服务端，不涉及其他端，那我觉得跑完直接上线是没问题的。

例如一个支付接口他需要先添加购物车 =》下单 =》支付，那么在测试下单接口得时候，是把前两个接口都调用一遍获取订单信息再作为参数给到支付这里，还是直接在数据库里构造这部分信息测试支付呢？

建议是都调用一遍，主要是从可维护性角度考虑。一般服务提供的接口，会保障向下兼容，且保障按顺序调接口没问题的。至于插库，这个特别姿势一般不会保障，意味着需要测试自己保障；而且这部分也是很可能会改动的，依赖的数据不一定都来自数据库，也可能是第三方服务什么的，那这个方式就行不通了。

利用随机生成（0，1）方法随机生成 0~1000 的数

我看到第一反应也是 random.random()*1000 ，日常写代码要取某个范围内的随机正整数就是这么写的，random.random() 生成的是大于 0，小于 1 的随机数。但这里有两个不确定的点：

1、随机生成 (0, 1)，不知道是指只会随机生成 0 或者 1，还是生成 0-1 这个范围内的数字。
2、生成 0~1000 的数，不知道 0-1000 是范围还是啥。

客气啦，最终还是你自己找到原因和解决的。我平时用 allure 也不多，也只是临时现找一些，给点思路。