可以呀，你在开源项目版块提交一下项目就好，我们审核内容 OK 后就可以发布，完成收录。

对的。自带 api 的写法调整，只能改源码。

PS：推荐用 virtual environment ，这样可以多个 python 版本并存，就不用担心影响整个环境了。

点赞。

之前试过 usbmux 改为用远程另一个 mac mini 的 socket，是可以直接拿到那台设备的 ios 设备并映射到所有上传工具中的，缺陷是本地的设备就会被忽略了，相当于替换，而非合并。

如果可以实现这个合并，那就很强大了。

估计是插件用到了某个 3.9 版本开始废弃的 python 旧自带 api。

你可以把报错信息以及堆栈发出来，然后网上搜索确认下。也可以参照 3.9 的官方更新信息：
https://docs.python.org/zh-cn/3.9/whatsnew/3.9.html

额，是想和大家交流如何解决吗？这么一个标题和内容，不知道该回啥。

测开持续发展的话，到最后应该是朝着测试架构师方向发展，统筹整个测试技术的规划和建设。只是确实很多公司测试团队规模不大，并不会有这样的岗位，可能测试通道最高也就只有测试经理这个级别了。

个人建议：
1、确认自己是不是要持续往技术方向深入。如果是，可以不断换到一些规模更大的团队（比如有自己专门测开团队的），这样测开通道的上升空间会更大。
2、如果不想往技术方向深入，那就做业务型测开，保持和业务的关联，除了关注平台的设计，也关注平台在业务中的落地应用，这样建立影响力后，后续也可以逐步转型为管理，管理整个测试团队。
3、如果并不想持续在测试赛道发展，建议尽快转。工作年限越大，你转型的劣势会越大，越难转。

最后，提一个建议，你可以和你的直属上级沟通下你的这个疑惑，看你的直属上级对于你的发展是怎么考虑的，也可以作为你的一个重要参考。

@ZhouYixun 远程连接上后，除了 sib，设备是否也会出现在其他调试工具的设备列表里？比如 tidevice、xcode 等。

之前有调研过这个方向，facebook 的 idb 也有提供类似的功能，但连接上的设备只能使用 idb 提供的功能，无法类似 adb 那样所有调试工具都可以连接上。

原理上只要是网络上的接口请求（前提是 http/https 协议），都能抓到，不大可能出现 h5 改为服务端渲染就抓不到。

建议楼主提供更多的线索吧，比如原本接口的请求和返回是啥样的，修改后变成了啥样。包括 url 、请求内容和返回内容等。一般 charles 抓不到，要不是走的不是 http 协议，要不走 https 但证书没被信任（移动端很常见）所以解析不了数据。

以前实习的时候见过一些 toG 项目里有个第三方验收环节，必须要有资质的公司来测试，并且这块是可以获得费用的，算是一个测试团队靠测试能力独立挣钱的路子。

但可能得要有 toG 的一些人脉，并且团队能获得对应的资质。

不错的总结，整个项目团队扩大 10 倍，测试只需要加 5 个人就可以抗住，很厉害！

从楼主的描述看，应该已经是项目中的测试团队负责人的角色了，能有这个位置其实挺难得的，而且还能前期 1 个人 hold 住众多业务线的测试需求，在自己精力管理这块，应该是能有比较大的收获？

也建议有时候可以多看看有没有什么测试策略可以提高测试效率，比如提高开发提测的要求/简单需求直接产品验收后上线，而不仅仅是集中在接口自动化/UI 自动化/单测，这样可能对整个团队而言收益会更高，成就感也更强。

万事开头难，而且看起来第一次效果还是挺不错的。楼主加油！

方便的话也可以把一些交流的摘要整理下在社区发出来，这样可以让更多人收益~

有考虑过用 whatsinput 输入法么？直接建立和浏览器的 ws 连接，用户浏览器上输入什么内容，到手机里就是什么内容。

atxserver2 用的是这个，目前内部用起来还是挺方便的。

m1 和 m2 还是有一定价格差的吧，然后 m2 和 m1 pro 也有一定价格差。性能上也是 m1<m2<m1 pro。

兼容性方面，m1 和 m2 用的一样的指令集，兼容性应该差别不大，看自己预算来买就好了。

帮顶一下，分布式压测用得比较少，不大好解答。

如果你这个程序没啥特别秘密的，建议你直接放到 github 上，这样细节更多。

否则这么看太费劲了。

多试试吧，现在大环境下拿到 offer 的机会会少很多，只能多点耐心。

另外，32 岁纯测开，没有带团队经验，只有大型项目测试负责人经验，可能也会有一些影响。毕竟这个年龄段及薪酬诉求，在很多公司的定位会是要承担一定的管理职责，或者作为部门级项目的负责人去推动落地，而不只是个优秀的一线员工了。

第四步：配置在线模块

这一步的截图里，我看到你的端口号和我文章中用的不一样，而且服务数量是 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 每次构建的内容差异，也是主要查看相比上次构建，代码变更记录来判定的。虽说也有可能让开发自己再写细一些，但对于一天构建几次甚至十几次的频率来说，每次这么写太费时间了，而且颗粒度、准确度相比直接查看代码提交记录来说，更难保障。

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

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

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