测开，个人理解是能通过技术手段解决业务质量问题的人群。

1. 和会什么语言一点关系都没有，也没有人会 care 你用什么语言解决问题（除非是特定领域，比如你要搞 android 那你肯定得会 java 和 kotlin），只要你能解决就行，解决不了，几十你会 100 种语言也没用
2. 技能熟练度方面，能写测试框架和工具，如果复杂度到位，那证明你是一个技术还不错的人员，但不一定是个好测开
3. 测开并不是只需要去写代码，好的测开，技术视野首先要比业务测试同学好，更重要的，是得能和业务测试同学一起分析运营业务质量问题，也了解业务

感谢肯定 😙

😙

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

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，我免费帮你改改简历，给你点面试建议。之前社区也有几个同学加过我，帮过别人几次了

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

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