情况还有点特殊，那我尝试换位思考一下，从开发和开发老板希望从你那里获取什么信息。

1. 需求什么时候能测完，什么时候能上线
2. 需求的 bug 多不多，解 bug 需要花的时间会不会阻碍上线
3. 这次的需求测出来问题很多，有没有办法让下次差不多的需求没那么多问题
4. 上线的需求有很多 bug 反馈过来，以后能不能再也没有这些反馈
5. 除了基本需求测试外，你还有没有什么额外的测试产出

就只能从这些角度去写；3、4、5 其实很抽象，靠你自己去想。1、2 比较明确

1. 在测哪些项目
2. 项目测试进度（不要就一个抽象的进度 xx%；而是 “执行用例数 + 已花费时间 + 剩余用例数”，最后折算出整体进展 xx%，并得出还要多久才能测完）
3. 有什么风险（数据构造？研发不配合？测试环境没 ready？工作量太多？）
4. 是否需要支持（加班？摇人？延期？）

如果手头有一些什么专项，比如自动化，也可以按照类似上面的思路去写，但是要换成一些关键的统计指标，比如计划这个季度覆盖 xx 场景自动化，实现 xx 条用例，实际写了 xx 条。

发现了什么缺陷等等酌情写，如果是零碎的东西写进去没信息量，没人看，如果是通过这个 bug 去表达项目测试困难或者其他实质的问题，那是可以写的。

这个图的箭头方向应该反了，按照表述，数据是从机头指向 EAP，再从 EAP 指向 MES 系统？

没所谓，改改简历也就 10 分钟，给社区同学做点好事

不介意的话可以加我 wx，我免费帮你改改简历，给你点面试建议。之前社区也有几个同学加过我，帮过别人几次了

不是想学什么，而是看你需要什么再去学，得功利一些

进中厂可能会对你的外包经历有歧视，小公司可能反倒觉得这段经历是个亮点，所以这个思路我觉得没问题

钉钉这个业务虽然一般，但是如果你成长得快，多扛一些业务，呆两年多跳旗下小公司是可以的（比如我记得广州有个阿里旗下互娱的小公司），但是你说要跳到优酷做正式员工可能还是有些难度

找研发以前改过的 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 肯定早就这样了 有些简单的业务确实很适合这种模式