这些点挺中肯的，也都是需要关注的一些点。

不过感觉上会有点散，除了基础测试外其他的点有点散。建议楼主可以试试梳理下思路，把差异化这块再拆分一下，让想到的内容可以更完整？

比如先服务端测试点（各种入参组合、合法/不合法输入、接口性能水平、内部计算和入库结果正确等），然后客户端（界面兼容、交互合理、合理的参数限制、用户填写大量内容误删页面下的自动缓存等），最后两端集成（成功/不成功返回、弱网下的重试幂等、接口响应久情况下的自动超时报错等）。

不错的分享，过程很清晰。

提个小疑问，这里面的 找用户收集复现步骤 + 本地调试复现并看到报错 ，是否可以简化为直接看线上服务相应时间的日志？这样沟通成本更低，而且也避免一些非必现问题被放过。

没用过，不好说有没有必要。

不过如 2 楼所说，模拟器无法取代云真机，核心原因是模拟器不具备真机才有的一些特点（最明显的就是用的不是各家厂商自己二次开发过的 android 系统），所以模拟器的结果可信度和真机相比会有差距。

个人经验，活跃度比较高的群一般都不会是持续交流技术而活跃的。一方面是有些技术是公司内部的，不方便对外传播；另一方面是技术的东西三言两语很多时候说不清楚，手机打字麻烦很容易放弃或者写不细。技术问题交流，更建议发帖把具体情况说清楚，得到的收获会更多。

如果想通过微信交流技术的话，更建议是找到几个觉得合适的人加下微信，私聊交流，或者组个 10 人内的小群内部交流。这样的交流会比一些大群交流有效得多，也方便聊深。

第一次接触 “云手机” 这个概念，不知道你这里说得云手机，是不是指云厂商提供的以 arm 虚拟机形式虚拟出来的一台手机？

hmm，感觉你这个问题不一定要转行解决，换公司可能也可以解决？

在广州

目前在招业务测试和游戏测试，不过学历主要要求本科，能力强的也会适当放松学历要求

有兴趣可以加我微信 chenhengjie123 ，发一下简历

我有一个小想法不知道可不可行：
一个证书是不是可以打包多个不同包名的 App，如果对包名没啥要求的是不是可以添加多个不同的包名，然后把测试包重签名成这个证书下的不同包名的 App 这样能不能解决数量限制的问题？

不可行，苹果限制的就是这个证书下的总关联设备数，和包名没关系。

你这个情况，不购买新的证书的前提下，按我理解只有两条路：
1、如果这 100 台设备，其实有一些是可以不需要的，可以找苹果客服申请重置，把不需要的踢掉，空出名额加新设备
2、如楼上说，用 testflight 包。可以通过短链分享给任何人的，缺点是发布到 testflight 需要在后台操作下

企业签名证书需要提交企业的相关资质文件来进行申请的，而且据说通过率并不高（这个证书提供了绕过 appstore 大规模分发的能力，很容易被黑产利用，设计用途应该是大型企业一些内部软件的分发），有条件搞这个最好，没条件不建议折腾。

我们这有招，有兴趣么？

这个回调本质上就是企业微信主动调回你们系统提供的指定接口吧？这样的话直接模拟企业微信发起请求就好啦。

系统设计上，可以把所有回调的消息直接甩消息队列做削峰处理，具体入库存储由另一个消费者服务从队列里取数据逐个进行，也可以比较有效避免消息太多系统崩掉。

游戏是因为兼容多版本成本比升级成本高，所以才基本都统一加载资源热更，保障用户使用的都是同一版本。

而普通软件升级成本比兼容成本高（如果老是打开后更新，估计用户就不用了，用户粘性比游戏低太多了），所以没有类似游戏这样每次都要 load 热更数据保障用最新版本，线上其实经常多版本并存。

而且其实普通软件内部也有提供自升级功能，用户点一下就可以下载安装包和更新。一般软件的热更内容比游戏少很多，所以基本都会想办法做到用户无感知（比如楼上提到的预先下载完，用户点按钮就直接应用），不怎么会有游戏这个明显的 loading 过程。

另外还有一个因素，具备修改软件逻辑的能力的热更技术，是可以绕过应用市场审核机制的（审核时是个计算器，审核后下发热更变成一个购物 app 也是完全可以做得到的），所以应用市场对这类技术限制相当严格，特别苹果，如果发现有类似框架引入，会直接拒绝。同时应用市场也有提供晚上 wifi 环境下自动更新的能力，足以满足大部分情况下新版本覆盖度的需要，所以相对来说，不会像游戏那样普遍使用热更来进行版本更新。

非常精彩的经历，点赞！

加油！

测试角度，就是拿不同型号的手机去测。主流型号的一般团队日常测试就要覆盖，一些特殊型号的就用云测平台去覆盖。

开发角度，不那么专业，纯个人理解：
界面展示方面：

• 屏幕大小/比例自动适配。这里 android 或者 ios 的开发手册都有对应的规范和工具，按着这些来基本可以自适应
• 各种挖孔屏适配。一般会在顶部设定安全区，这个区域内没有什么内容，避开这些孔 功能方面：
• 不同厂商对应系统的部分特殊 api 适配。这种就只能一家一家去适配了，但一般比较少。

赞同 21 楼，“让自我成长的人有土壤，让不想成长的人有活干。”。改变人是很难的，有些时候与其改变人，不如换人。

回到楼主主题，如果是想把气氛搞起来，可以先看看团队里有没有自驱力比较强或者比较爱学习的同事，先把这部分人组织起来，内部做几次比较不错的分享，再逐步考虑扩散到更大的范围。

另外，可以考虑针对一些想要重点培养晋升的高潜人员，定期面谈时多指引进行分享等手段，扩大影响力。分享的主题可以帮他做一些选题（比如近期解决的某个技术难题；怎么保障某个重大项目能按时按量完成），有时候范围太大反而不知道怎么分享好。

PS：目光可以扩大一些，保持学习和成长，并不只有做分享这个路子。结合实际工作需要，给大家 OKR 里增加一些新技术调研落地的目标，并给予对应的时间和资源，完成后顺水推舟来个分享，可能效果更好。

666

看下 console 有没有报错，也问下开发是不是有 cookies 之外的鉴权机制？

是这个帖子的编辑提交吗？审核后台查询到 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，避免遗漏，同时也帮助开发更好地熟悉整个项目内反射部分的关联，避免重复遗漏。

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

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

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

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

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