文档格式的话，excel 或者 todo list 都行，能方便看到检查点和一个个打钩就好

实践形式的话，看这个 checklist 是想要求什么阶段做好。比如是上线前做好，那就放到上线申请单里。

PS：可以看看 checklist 里有什么是可以自动化检查的，能自动化尽量自动化，靠谱且效率高。

同感。

有些常规工作其实没必要写上去（如 “负责编写测试计划文档。”）。写上去的应该都是你想突出的你做出来的事情或技能，一方面可以更突出你的擅长点，另一方面也便于引导后续面试官往你擅长的地方去细问。可以试着给自己定个硬指标，项目经历控制在 3 个内，每个经历的细点控制在 4 个内，然后在这个范围内，把你觉得不那么突出的点或者经历去掉，只保留突出的。

简历里的工作经历，其实有点类似于工作中写绩效总结。关键不是大而全，而是要突出重点和亮点，让你比别人突出就好。

PS：后面实际投递的时候，一定要记得针对一些你真的比较想去的岗位的 JD，对简历进行微调，突出和 JD 要求匹配度高的内容，否则容易因为匹配度不够被筛掉。

这么说吧，webDriverAgentUrl 可以设置为任意地址，但你会因为 appium 更前面的一些流程卡住导致到不了用 webDriverAgentUrl 执行自动化这一步。

appium 在运行到连接 webDriverAgentUrl 前，还有一些前置步骤，如自动检测 udid 本地是否存在、检测被测 app 是否已安装等，这些步骤用的是 idevice_id 这类仅支持获取本地连接设备信息的工具进行的，所以如果设备不是本地连接，会在这些前置步骤里被卡住。

要解决的话，得手动改 appium 源码，让它跳过这类步骤。

你这种属于运行时赋值的变量，没法用 yaml 自带的变量机制实现。得用测试框架来存储，并设定一些赋值/使用变量语法给使用者在 yaml 中使用。

具体例子，建议可以看看 httprunner v1 或者 v2 版本。

那就边学边看呗，能力提升总是对自己有好处的。不过也要意识到，光靠能力提升没法帮你争取到调薪，只有通过应用能力，实打实取得项目成绩才能争取到。

从楼主描述看，想快速获得调薪机会，跳槽吧。

你换个角度看，如果你是公司领导，收到一个绩效平平，没怎么看得出项目成绩（项目主心骨那种程度）的员工想申请调薪，你会给调么？

调薪的最终目的是留住人才。你没法证明你是人才的话，是很难获得这方面的机会的。就算主动提出了，你的领导也帮你申请了，但再上面的领导也不大会批给你。

PS：赋能这段看起来是新招的自动化测试工程师的成绩，不知道放在这里是想表达什么？

客气啦，算不上大佬。只是做一下经验交流。

我们线上和测试环境数据是隔离的，所以很多时候本地是很难直接复现问题的。定位排查高度依赖日志，所以看到第一反应是查线上日志。

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

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

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

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

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

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

不过如 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 之外的鉴权机制？