是这个帖子的编辑提交吗？审核后台查询到 12 月 12 日 18:53 的有一次审核申请，且已经审核通过了。

您大概是什么时候编辑提交的？可以 点击右上角用户头像->我的待审核区 ，确认下你的修改是否有对应的待审核记录？

不错的分享，已加精

看 22 年的经历，楼主成长很大，已经可以一个人完成完整的一套项目了，能力成长很大呀。

至于职业定位这块，提几个小建议吧：
1、不用这么快就把各个路都堵死，1 年没碰测试和后续继续做测开没太大冲突，效能也并非必须大厂才有。有丰富经验的测开，需求量还是挺大的。
2、这块可以问下你的前辈，或者你的 leader，他们更清楚你的情况，给到的建议可能会更好。而且在明确了你的规划后，你的 leader 可能也可以在工作上给予你对应的机会和帮助。

第一件事，提测单里应该有版本方面的明确信息。这部分信息不能有空就给，没空就不给的呀。
第二件事，构建出问题的确是要开发自己解决的，他们修改完后应该要他们自己自测，确认没问题再给你，而不是他们改一改，你们试一试。然后构建出问题后，立马先回滚，保障环境可用，再让开发自己改。

我们之前测试环境也是我们自己负责，刚开始确实会比较磕碰，不过运作起来，会有几个好处：
1、测试对系统拓扑结构更清晰（比如某个需求改到 abc 服务，这块一定会接触到），对测试设计、后面逐步测试左移等打下基础。
2、测试自己负责环境构建，可以起到把关人的角色。试问一下，如果你测试的代码你是无法把关，开发偷偷搞点变更 + 构建，你是完全不知情的，如果刚好这部分功能之前测过没问题，也不知道有改动，所以没有改动后再复测，那到时候线上这部分代码出问题，就会影响线上，最终还是会影响测试。
3、避免有时候开发不规范的操作，引起测试环境阻塞，测试只能干瞪眼，等开发解决，自己没啥自主权。

最后，关于测试环境是测试还是开发维护的问题，我觉得核心还是 2 个问题：
1、环境管理者是否可以保障环境保持稳定，不影响测试进度？
2、我们（特指测试）是否有办法做好版本管理，保障我们测试的代码版本和最终上线的版本一致，不出岔子？

如果这两者都可以保障好，那其实测试还是开发管理都问题不大。但如果保障不好，测试管理测试环境，能更有助于保障好这两者。

反射本质上属于运行时调用，被调用的功能甚至有可能是外部依赖库而非本身代码的，基本没办法通过静态检查工具（如 idea 的自动检查）进行有效的检查，这其实本质上也是反射特性带来的弊端。

个人有想到一些思路，仅供参考：
1、和开发一起梳理下项目里的代码，看有哪些涉及反射调用的，看涉及哪些功能。回归测试的时候，重点测试下这些相关的功能。
2、有些反射调用的地方，确认下是不是必须用反射，能不用的尽量不用，降低维护成本。
3、如果团队内有做覆盖率采集相关的工具，可以结合增量覆盖率，看看用到反射的模块的增量覆盖率情况。

PS：开发容易漏掉反射调用的修改，一定程度上说明开发自己要修改的代码调用情况还不够熟悉，过于依赖 ide 提供的自动重构功能。这块需要联合开发，通过一些手段把重构类的修改摘出来（比如要求必须单独 commit，或者独立分支之类的），对这部分修改做 review，避免遗漏，同时也帮助开发更好地熟悉整个项目内反射部分的关联，避免重复遗漏。

能自学把主流程写下来，也挺不错拉~而且知道自己代码哪里不好，说明对于好代码是怎样有个基本印象，至少不是井底之蛙了。

听楼主的描述，现在应该是达到一个人自学的天花板，不妨考虑开始向外交流。可以试试看你的城市有没有什么沙龙交流活动，加进去，认识一些同行，后面可以相互交流，以后跳槽啥的也方便。

“项目中没有一个站在全局角度关注开发过程的角色”，这个一般是项目中所有开发的老大担任这个角色，你们组织里没有这样的一个人吗？

“我也是不太明白测试环境开发为什么不给出来”，你提出测试管理测试环境的时候，开发没有说出他们不想让出的理由么？
沟通方式上，建议最好是测试老大和开发老大先通气，达成共识再会上提出，比较好。要不在一些会议上贸然提出，开发没有心理准备，第一反应会偏反抗一些（人都是天然抗拒被改变的）。

“前端负责人表示没问题， 后端负责人表示非常不愿意”，那就先从前端推起呗。推动后有效果，再用这个效果去推动后端。

顺着楼主的思路，进度出问题，我理解应该是如果某次发布把环境搞坏了，测试只能干着急，得开发才能解决？

如果是，可以把几个这样的案例举出来，说明对测试进度有什么阻碍，然后再顺理成章说测试来负责测试环境的发布，遇到这类问题可以直接自行解决。

另外，关于信息同步，建议推进开发的 commit 规范，带上提交类型、缺陷单号这些，达到基于 commit 信息就可以看出修了哪些 bug 的程度，这样从 Jenkins 代码变更情况就可以直接看到修复了哪些 bug，少一步人工同步，解决信息同步问题。

PS：我理解从开发角度，管理环境其实好处并不多，毕竟开发除了前期联调，后续比较少用到整套环境。所以其实不大需要想着 “说服”，说不定其实开发也不想管这个。

意思是，tidevice 可以在没有设置密码的情况下，可以自动让设备展示开发者模式的选项，并自动打开开关和重启系统让其生效？

赞，学习了~

另外，用这个方法打开选项后，应该还需要手动在 ios 系统上手动打开开发者模式，并重启系统，是吧？

是的。所以只适合用来确认原理，但不适合真正业务上使用。

当时还有想过一种方法，更底层的 usb over ip 方案，把 usb 设备的数据直接通过网络传输，比如 https://sourceforge.net/projects/usbip/ ，你有兴趣可以试试。

这个时间基本是常规时间，大部分给了 offer 的公司本身其实也会有这样的预期的，倒不用太担心。

@debugtalk 可以看看？

没太明白要对比什么，可以更清晰点说明对比的点，以及认定为是否一致的标准么？

md5 是基于文件的完整二进制内容生成的摘要，相当于必须是同一个文件，md5 才会一样。内容里多一个换行符或者空格都不行，转格式的就更不行了。一般用于校验文件下载是否完整，有没有损坏之类的。如果要对比文件内容，并不适合。

建议创新可以不用那么苛求。

不妨先整理下现状，看有哪些需要改进的，改进的过程中可能因地制宜使用的某些方法或者流程，就会成为创新点。

太苛求要创新，容易产生一些听起来很新，但没什么用东西。

你有选择了封面图片文件吗（jpg 格式）？

正常选择文件后，应该会变成这样，选择按钮右侧变为选择的文件名：

我用的 chrome 版本：Version 108.0.5359.124 (Official Build) (x86_64)
系统：macos 12.1

如果选择文件后，还是没有这么展示，麻烦同步下你的浏览器、操作系统等版本信息吧。

可以呀，你在开源项目版块提交一下项目就好，我们审核内容 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 的一些人脉，并且团队能获得对应的资质。