找研发以前改过的 bug 来看他们怎么修复，最好那个 bug 还是你提的，这样你就知道 bug 怎么复现，看起来更有感觉。

从 AI 训练物料来说，淘汰的是最基础最一次性的学习笔记类文章，这种文章千篇一律，谁写的都差不多，也很容易写。

越是有价值的文章，往往有很强的上下文关联和话题针对性，而且按照知识付费的发展，这种文章往往都在某个平台的信息孤岛里，不充钱就看不了，AI 根本爬取不了。

外包先看是哪里的外包，如果是第一次在大厂做外包，这段经历最好有个两年，会有相对好的背书作用。如果是非大厂外包，那就看做的东西怎么样。

自研小公司，一定要关注业务的健康度和行业动向，首要问题是有利润能活下来，业务方向不好团队再牛逼也白搭。其次就是关注研发测试人数比，如果测试人太少，那必然是极度牛马且无话语权，不太建议。

-1

那大概就是 学历、年限、职级 等一类问题了。业务线其实也很没办法，HR 考虑的是如果到时候面试通过，基本条件会不会阻碍 offer 推进。不然即使面试过了，后面再往上审批 offer 时也会被质疑

来支持雷总啊，遥遥领先还是太贵了点，品牌溢价比较多

从对接过的各类内推和面试邀约经验看，应该是铁门槛

如果我是面试官，看到一个应届生列的技能比我还多，我第一个感觉就是这个人其实啥也不会 ，过度包装效果反而是负面的。

建议把只是简单部署跑一下的程度就去掉，留下 Top3 你认为是最熟悉的，其他的就写接触过就好了

感谢分享贡献！

可能只是不合适吧

之前有校招的名额，现在应该是招社招了。如果直接是我在的业务方向，应该要 3 年以上，不过投一投简历也无所谓啦~ 投简历不用过我的手直接进系统的，我也看不到简历信息，有效保护隐私

是的，如果从收益角度看，站得住脚的逻辑可能是：

1. 先分析哪个端的 ui 问题多，并且这些 ui 问题能用 ui 自动化解决（这部分就是预期收益）
2. 再来说我要在这个端做 ui 自动化，并且还能使用有 ui bug 的版本，来验证新做的 ui 自动化的确能发现过往的 ui 问题（这部分会比较难，事实上往往做的 ui 自动化还真不一定能把历史出现过的问题都拦截住，就看老板认不认吧）

各种实操经验，但凡是不一样的人来开发就必然会引入差异，所以可能最后变成：

1. Android 和 iOS 部分自动化可以复用，但还是不少地方要分开维护
2. H5 和 小程序就各做各的

我觉得可以这么去考虑：

1. 是不是一定要做 UI 自动化才能解决现在的质量或效率问题？
2. Android、iOS、H5、小程序，在明确了不存在一套代码全部覆盖的前提下，还是想要全部都做，精力应该不允许，故哪个端综合考虑流量大、风险高、历史问题多的，就应该先做哪个端
3. UI 自动化无法做很重，UI 频繁变更决定了其维护成本高，哪个公司哪个业务都一样，所以有些质量问题得考虑结合其他手段解决，这些手段可能是什么？

在明确选择这么做之前，想先问问业务多端的 ui 本来就是完全一致的吗？我猜肯定是不一致的，不然为什么不直接上类似 flutter 等跨端语言，而是要每个端都专人写

如果业务本身多端就不一致，这个选择就是巨坑，坑的还是自己

不仅不开内部账号，可以说对实际测试业务一无所知。这种岗位就是别人告诉你怎么操作你就怎么操作，大家保持了一个很好的边界，一方不过问任何业务细节只管执行，一方不愿意花多少时间在离案上人不行就直接换

确实是字节，至于哪里传过来的我也不知道，理论上 TX 肯定早就这样了 有些简单的业务确实很适合这种模式

仅个人看法。

测试的最终产物：

1. 对于产研：线下线上各个环节都有测试参与并提供合理的质量保障方案，让人心安
2. 对于业务：一套完善的质量保障体系，变更上线都不慌不忙，线下拦截好，线上监控召回强
3. 对于企业：一套可低成本复制迁移的方案，新业务套用方案后，在短时间内也可以跟上成熟业务的质量
4. 对于个人：一系列经过实践验证的落地经验和数据导向的逻辑思维，对于业务不同阶段要建设什么，为什么要建设，未来发展的建设预判，都了然于胸

最近半年，一些大厂开始搞离岸外包了，长期目标是减少驻场外包，通过离案外包来进一步降本增效（因为离案外包不在一线城市上班，生活成本低所以工资也可以更低）。

从这个情形看，外包也逐渐强调水平差异，最低级的离案外包，我接触下来就是牛马工具人，不仅工作几年后活依然干得一般，基础也很差，权限非常低接触不大一点大厂精华（内部平台都要单点开权限才能用的那种）。

给个比较不一样的建议：所以如果活干得好，顶级驻场外包也不是不行。

至少我见过的业务，优秀的驻场外包是单独负责某个业务 + 带离案外包干活，还有正式员工 1v1 深入的辅导，工资也能在 1.5~2w 之间收入和成长都有明显的资源倾斜，也很容易获得业务测试负责人的信任，抱上大腿（后面别人带着你去其他好业务）。

学历是硬伤，即使专升本也依然无法避免面试歧视。如 10 楼所说，既然学历已经不好操作，那就把履历做好，用大平台来帮自己背书，自己再通过文章或代码沉淀在面试时让人眼前一亮。如果哪个外包在面试时给我秀代码，即使代码写得一般般，我也会觉得很惊艳，因为根本没有外包这么做过，但如果是面正式员工，我反而不会觉得好甚至可能会挑毛病，这就是矮子里拔高，宁做鸡头不做凤尾。

我个人观点是，不要把自己钉死在 “一直想办法保持学习” 上，而应该是想办法将已经学到的东西变现，在这个过程中在顺带学习新的知识。

虽然测试的知识本身并不能帮助我们直接变现，但是测试岗位接触到的业务上下游知识，以及对痛点的敏感度，也许对变现是有帮助的。

其实如果只是做笔记类型的公众号，不会有什么高质量粉丝，要想靠这个做副业不现实。而且这种文章实在遍地都是，写了自己也没啥沉淀，你说每天都在写 1+1=2 多没意思。这种文章不足以让别人有理由关注你的号

要减少焦虑，我觉得不是通过日更来 “麻痹” 自己，让自己看出来产出很丰满，还是要讲含金量。比如你选某个领域，或者直白说，你就挑一个开源项目，去使劲分析。社区里之前有 uiAutomator 的分析文章，像那种文章你写出来包精华帖

日更真没必要，那些能日更的，基本都是写一些比较玄幻的生活感想随录，或者一些很泛的理财和所谓的 “提升认知” 一类的博主。

我关注过，感觉他们的文章有一个特质，就是看起来日更，但是每篇的核心内容都很相似，基本上就是一个点换着文案包装每天发，质量并不高。

首先明确，无论是产研测都不会直接对接，分工上属于运营范畴，同时质量侧会有一定关注（具体取决于是什么问题）

我是 ToC 业务，流程上：

1. 专门的运营同学先对接处理
2. 如果无法处理，看具体问题会考虑拉研发，如果是 bug 也会同时拉测试，产品一般不会拉到具体 bug 反馈里面，除非大家判断有必要再拉

有些公司是一次性面试完成的，所以倾向于选择线下（合适的人，线下直接车轮战一次性面完）；
有些公司的时间没那么灵活（越是大规模也是这样），每轮面试都要隔几天，这种基本都线上。

求个录屏，有事情没法线上听讲