第四步：配置在线模块

这一步的截图里，我看到你的端口号和我文章中用的不一样，而且服务数量是 2 个，和我文章也不大一样。你确认你启动的被测服务，使用的是这里面其中一个端口号吗？

另外，你截图里第三步是启动被测服务，但没见到我文章提及的 5.2、让 repeater 注入到被测应用 ，不知道你这一步是否有做，命令行使用的命令和我写的是否一致？

你提的这个问题提供的线索太少了，只有一个 “接收不到在线流量”，但没有更详细的你具体是怎么配置的过程记录，没法基于你提供的信息反馈有效的解决建议。

建议你开个新的帖子，把你完整的配置过程记录下来？

准确且详细的重现步骤，确实很多时候是定位问题原因的重要辅助。之前看到有类似的实践，报 bug 时自动拉取出现 bug 时前一段时间的日志、录制视频等数据，附到 bug 里，有效提高报 bug 效率和开发重现效率。

不过我有时候在想，其实现在大部分客户端的点击按钮、进入页面都有通用埋点上报数据，结合服务端同时段的日志信息（核心是收到的 request 和返回的 response 内容），其实是不是也可以得到足够定位问题的数据呢？

结合你截图里分布式压测时响应时间 95% 都是在 106ms（单机是 3000ms），说明你分布式执行时实际给到服务端的压力应该是比单机 4000 并发低了很多的，否则响应时间不可能低这么多。至于实际分布式压测时，服务端的 tps 到底是多少，建议以服务端监控软件（看你图里有 grafana）为准。

建议分享一下你的压测拓扑结构（特别是分布式时，每台压测机和被压测节点的网络链路，看会不会由于网络原因导致压力传递不到被压节点），以及你分布式运行的具体命令参数、通过什么命令采集并生成截图里这些统计数据的等更详细的信息。

另外，也可以参照这份官方的分布式压测文档自查一下：https://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.html

问题 1：如何获取 “估值” 这个元素并点击？

从截图看，这个 tab 栏是个继承了 View 的自定义控件，且没有实现 accessibility 相关 api ，导致内部的子 view 没法被获取到（uiautomator dump 控件树，本质上是从最外层的 FrameLayout 开始递归调用子孙组件的 accessibility 相关对象来获取的，类似读屏软件。所以如果没实现对应方法，就会获取不到内部的子控件）。如果能推动开发增加相关支持，可以尝试推动下。如果不行，可以考虑用图像识别类方法。

参考文章：让自定义视图使用起来更没有障碍 。

问题 2：如何获取市盈率 PE 的值呢？

这是个 webview 内的元素，你切换到 webview 上下文后，应该就可以看到这个控件对应的元素了。

首先，存在偶发性问题，说明代码逻辑上还存在一些漏洞，在一些极端场景下可能出现问题。只是这类场景出现条件苛刻，且会引发其出现的关键因素并非人为操作路径，所以很难复现。

针对这类问题，核心是需要获得领导出现此问题时，足够详细的信息（比如日志），帮助进行定位处理。如果是崩溃类的还相对容易，接入崩溃捕获平台即可（如 bugly 等）；但如果是功能类问题，可能需要基础平台侧想办法开发一些可以手动捞取指定手机上，应用内部打点日志信息的工具，结合足够详细的日志打印信息，才能有效辅助定位问题。

另外，偶发性问题测试无法在上线前发现，这个其实很难解。本质上，偶发性问题大多出在某一段逻辑不够严谨的代码中（如写了 if 没有写 else，针对 IO 操作没有有效捕获异常），或者是某个 sdk 使用姿势不正确，甚至是多线程情况下没有保障数据读写的线程安全引发问题。这类问题由于本身出现概率低，条件苛刻，所以正常测试中实际上很难发现，就算发现了也很难复现进而得到有效的修复和确认修复有效。要避免这类问题，个人能想到的是：设计层面上能充分考虑到后续可能遇到的所有情况 + 代码编写上有足够详尽的单元测试来保障每个单元的逻辑足够严谨完善 + 足够完善的 code review 避免单人思路受限 + 足够的线上灰度时间让代码接受真实用户的洗礼。这在国内互联网类业务大多研发时间很有限的状态下基本不大可能。所以，其实一般这种情况，老板自己都无法稳定复现的问题，其实老板也不会特别苛责为啥测试完还会出这样的问题。

从效率上说，确实直接把代码提交记录复制过来是最简单的。我们 Jenkins 每次构建的内容差异，也是主要查看相比上次构建，代码变更记录来判定的。虽说也有可能让开发自己再写细一些，但对于一天构建几次甚至十几次的频率来说，每次这么写太费时间了，而且颗粒度、准确度相比直接查看代码提交记录来说，更难保障。

不知道楼主想要的是什么效果呢？

好久没见到这么完整有干货的实践分享了，加个精

加个精，方便更多同学参考借鉴，以及用上楼主提供的工具快速解决同类问题。

听起来，像是第三方没有正确回调，并且自己系统的补偿机制没有生效，导致数据一直没有同步更新。

个人了解，MS 的性能测试应该是不收费吧？

为楼主的这份思考和实践分享点赞，感谢楼主末尾还分享了这个轻量级反向代理工具。

多套测试环境切换已经改成使用公共代理（nohosts）+ 特殊请求头（标记去请求哪套环境或开发的后端服务）的方式了

好奇问下，为何不能直接沿用这套机制呢？我理解这套机制里，应该有一些手段记录某个主机的请求来了后，是走哪个环境的。这套机制应该也能适用于主机地址相对固定的第三方回调？

另外，这个统一对外，并基于配置转发给内部其他服务的反向代理，在很多的架构中会称为网关（gateway），或许楼主把搜索关键字改为 gateway ，会找到一些合适的工具。

我觉得这个问题，和每个人所处的环境和追求的目标有很大关系，不好讨论。

只能说，真心想存的人总有办法存，相比存钱更关注享受现在的，也大概率会存不下钱（消费会和收入一起增长，导致收入增加后还是没有余钱存在下来）。

在今年这个大环境下，最好还是存点钱，抵御未来不可知的风险吧。

没太理解 “就是大部分都是同一个页面上有不同的切页或者下钻弹框。”，具体是什么意思？每个页面的 url 是一样还是不一样？

前面提到一个个点击，我理解你想要的应该是基于可交互控件进行遍历的工具，这类工具大多针对的是 app ，针对 web 的没怎么见到过。建议可以找个针对 app 且基于 appium 的进行改造（appium 的协议和 webdriver 基本一致，改起来相对容易一些）。

从测试套件这一层的角度，它不应该限制用例必须是接口的或者是 web 的，它只需要管理好用例的执行顺序，记录好用例的执行结果，并提供一些用例间信息传递的机制（比如全局变量）就可以了。

现实中 web 和接口一般会分开不同的套件，分开编写用例和执行用例，主要是因为分开后问题定位以及用例维护复杂度都能降低。

接口测试能比较纯粹地测试接口，不用耦合 UI 界面，失败基本可定位为服务端问题，和客户端无关；而 web 测试则是偏集成测试，服务端 + 客户端（前端）都会集成在一起测试，一旦失败需要再定位是服务端原因还是客户端原因。

所以一般使用上，会先通过接口测试保障服务端没问题，然后再通过 web 测试保障两端集成后也没问题。两边会分开在不同的套件中，分别执行。偶尔会遇到的需要合在一起执行的场景，一般是借助接口调用造数据供 web 测试使用，这个时候接口调用只是作为前置条件，并非用例本身，所以严格意义上说，也不算融合。

不错的解析文，点个赞！

资料有点少，不好评价反馈，只能留点疑问，楼主可以看下有没有做好：
1、UI 自动化里面，框架是否有提供什么机制便于提高用例稳定性？（如找元素的自动等待等）
2、UI 自动化脚本的写法里，怎么尽可能让代码容易复用？（如 PageObject，从代码看有 Page 的概念，但不确定是不是用了 PO 模式）
3、一旦有报错，框架层是否可以捕获并输出足够清晰的日志等信息，便于使用者基于日志就可以定位并解决问题？

接口自动化：
1、一般接口自动化的特点是数量多，如果每一个都得写不少代码的话，编写维护成本会相对高。针对这块是否有评估过一个接口用例按现在框架写，大概要多久？
2、从这个截图看，有不少代码是为把报告输出到 allure 服务的。不确定这部分是不是用例，如果是，可以考虑下把这部分由框架直接代劳，而不用每个用例自己写？
3、类似 UI 自动化，接口自动化也有流程型的用例的，通过调用多个接口形成一个流程进行测试。不知道是否有考虑过脚本如何分层，让流程型用例和单接口用例，都能尽量复用一些公共代码，降低编写成本？
4、接口测试很多时候会需要测试多个环境，从脚本看像是从一个全局配置文件里直接获取 url 的，建议框架可以提供多环境分开配置的能力（类似 spring 里面可以分别为 dev 和 prod 设定不同的配置项对应值）。

除了图，是否也可以分享下一些关键技术点或者设计思路？

不是瞧不起，无意引战。

postman 本身是很好的接口测试工具，日常的接口调试或者简单测试，我也喜欢用 postman 。上手比 jmeter 还要简单（不用管什么线程组、sample 这堆术语），当然对应的灵活性扩展性等也会比 jmeter 稍微差一些。

我这里举这个例子，只是想说明有很多团队对于接口测试工具的需求其实并不那么复杂，类似 postman 这样的灵活性弱一些但简单好用的工具，也可以很好满足。

Jmeter 用的人多，个人觉得主要还是因为它可以做接口 + 性能测试，对于新人来说，学一个工具可以做 2 个事情，肯定会比要学 2 个工具有吸引力。况且国内 Jmeter 有大量文档可以参考，这对于新手自学也可以起到很大帮助。

Jmeter 我觉得核心的硬伤主要是团队协作，以及脚本封装复用。大部分公司做接口测试规模并不大，团队协作需求相对不那么强，脚本也不算很复杂，没有太多需要相互复用的地方，所以也可以大概理解。甚至其实还有不少团队在用 postman 做接口测试呢。团队协作需求强的，一般都会上平台，光靠工具很难解决。

至于 "问题定位" 这块，其实实际使用并没有这样的问题。jmeter 配合 ant 插件，可以输出包含类似 result tree 内容在内的报告，方便查看请求参数和失败的返回值内容的。

以前 deviceName 这个配置项，名字就叫 deviceName 。刚查了下官网 https://appium.io/docs/en/writing-running-appium/caps/index.html ，名字好像没变。

楼主是在哪个资料看到名字叫 appium:deviceName 这个的？

如果是服务端，可以直接借助拨测工具进行测试，包括直接写个脚本让当地人跑，或者直接用商业/免费的拨测工具。

如果是客户端，可以考虑用海外云真机。

另外，海外连接服务的延迟情况，和机房位置也有很大关系。机房选址的时候，建议做一些网络速度联通情况的测试，避免后面再迁移机房那么痛苦。

看了下，基本原理上应该还是离不开要单独有个进程/线程去接收 ws 的推送消息的了。

至于用例怎么去校验推送过来的信息，建议可以搞个 queue（队列）。接受 ws 推送的进程，把收到的消息记录到 queue 中，包含消息内容 + 收到的时间戳。然后封装一个断言函数，里面判断在什么时间段内，应该收到什么样的消息，接着就到这个 queue 里面检查有没有符合条件的数据。用例通过这个断言函数就可以进行判定了。

移动网络的弱网（如强制降低到 2g 模式），可能会存在并发 tcp 连接数受限的情况，导致本身可以一次性并发的请求变成小批量串行。

这块好像一般的网络模拟软件模拟不到。

另外，你是在哪个文章看到，可以发下地址，大家一起看看，判断一下？

哈哈，后面你也可以来分享下你的成长经历~