希望大家给点意见，QA 能干多久？

这个问题我表示没法回答。。。就像你问互联网还能活多久，没有人能准确预知这个未来。我只能说，QA 目前在持续变化，能取得不错成效的话还是可以活挺久的。就像运维借助 DevOps 从一个每天重复敲命令上线的体力劳动者变为一个做生产资源管理 + 自助上线赋能的技术工作者（现在这类岗位好像叫运维开发，其实也基本是一个产品 + 开发 + 测试 + 运维都要做的 one man one team 型岗位），测试也在寻求从每天重复点点点的体力劳动者变为做质量管理 + 质量保障赋能的技术工作者。只是质量这个事情业务特性更强，不像运维上线那么容易标准化和自动化。

如果不是 QA 那么转岗还来得及嘛？

我觉得关键不是是否来得及，而是你是否有足够的决心去承受转岗带来的落差。我建议你先想清楚你想要啥，然后再看通过什么方案可以达到你想要的？既然能坚持做这么多年 QA，至少应该是不讨厌 QA 工作的吧，方便的话可以分享下你现在具体遇到什么瓶颈，困在哪里？

1、方案上 tidevice 实现了不依赖 xcode 就可以启动 wda ，进而执行自动化脚本。但请注意只是 “启动” ，即你的手机里需要事先装好 wda 。而你这里在做的是 “编译” 中的依赖库安装，编译目前应该还是只有 mac 可以支持（编译暂时没见到可以绕过 xcode 的，而 xcode 只支持 mac ）

2、如果需要加上 appium ，需要调整 appium 的 desired_capabilities ，使其使用 tidevice 启动好的 wda 对应端口，而非默认的自行通过 xcodebuild 命令去启动 wda 。详细可以参考 https://testerhome.com/topics/30422#reply-195820。且由于 appium 本身内置了通过 ideviceinstaller 校验 bundleId 是否存在的逻辑，ideviceinstaller 不确定在 linux 上 appium 安装脚本是否会自行安装，建议你手动安装下。

发 http 请求的那个 sample 的配置截图发一下？试过搜索引擎里找到的哪些方法，使用后表现有什么变化，也可以发下？

问题直接一图流不是个好习惯，提供多点数据也有助于更全面了解问题。

业务方需要忽略掉只是变更了空格和格式的内容

这个细节挺不错，我们之前没留意到。确实需要加上。

是否可以先发下：

1、你这个互转，具体需求是什么？给个 yaml 和 excel 互转的示例？
2、你目前找到了哪些库？
3、这些库你试用后，具体哪部分灵活度不满足你需要，最好附上你当时写的 demo 代码？

灵活这个词太概括了，不知道你到底要怎么样程度的灵活，所以你先多给一些资料吧

要看系统对于 token 的具体实现吧，单纯这么问不好说差别有多大。

然后如果确实区别很大必须多个用户，那找开发协助，绕过实名认证直接造用户就好了？

大部分理解和我理解是一致的，有一小部分不大一样

就需要针对不同的业务上的场景设计不同的用例，来监测这些场景下的 TPS 值，最终通过分析这些值来确定整个系统的性能的指标以及需要的服务器的大致配置

根据不同场景设计不同用例这个是对的，但基于这些场景下的 TPS 值分析确定系统性能指标这个不大对。

性能指标应该是基于真实业务场景分析来制定的，而不应该是基于压测结果制定。比如同样 TPS 数据，线上的 TPS 数据，代表真实业务情况，所以可以作为场景分析的参考数据，而你自行压测得到的 TPS，只是你自己模拟得出的数据，可以用于验证性能是否达标，但不能用于作为场景分析的参考数据。实在没有线上数据可供参考，那和产品开发一起讨论，一起推敲出一个值也行。

感觉你目前在概念层面上有些理解不大对，需要有比较完善的文章或者示例，而不仅仅是我在这里只言片语的答复。建议可以看看楼上贴的 服务端性能测试 - 入门指南 ，或者去极客时间看看高楼老师的课程。目前是支持任选几讲免费试读的，你可以选关于基于业务场景制定性能指标的章节看下。

也许在你这个场景下，实际对性能要求并不那么高（PV 17W，对一个线上系统来说应该不算高负荷），但这些理念尽量入门时要了解好，避免后面走偏。性能测试的场景和目标指标制定是非常关键的，没做好，很可能会引起你性能测试结论是通过，但线上真正达到预计范围内的高峰期时系统却扛不住挂掉，那你这个性能测试基本就是白做了。我们之前就遇到过，花了快一个月专项做性能测试，结果上线后流量来了，就各种扛不住（我们当时是监管要求必须切新系统，所以不可能小流量慢慢上，一上来就是全量），后面研发就各种吐槽当时花那么多时间做的性能测试和调优，一点效果没有。

微信截图已删

bug 也记录了：https://github.com/testerhome/homeland/issues/136

。。。那就是 bug 。

你要删哪些楼层的，和我说一下，我帮你删吧。

进入回复内容编辑页，左下角有删除按钮：

公式： 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 了？