这起码是 10 多年前的测试工程师衡量标准吧，什么 bug 数、用例设计数、用例执行数

外包合伙人？

看来行情很好啊

93 年 32 了

直接 java 吧，适用度更广

平时多用隐私模式

效果就是年底绩效可能会好点

要数据是对的，不管是你的领导，还是你的领导的领导，看的都是数据。但是具体是什么数据、数据准确性、数据解读，都是从你嘴里来的，领导不需要如何准确的数据，只要你提供了一份能够向上汇报、有正向意义且你能自圆其说的数据就 ok 了。比如，自动化测试这个项目，以下是我的一些思路：
1、覆盖了几个项目、几个场景、维护了多少个用例，占所有主流程场景的占比，这个体现出工作量与覆盖度
2、通过自动化项目，回归了多少次线上或线下回归，平均每次节省人力回归成本多少，总共节省多少（不一定要那么准确，合理即可，可稍微美化）
3、通过自动化项目，发现或避免了多少问题，这些问题占所有线上或线上问题的占比（体现出其作用，没有可以不写）
4、通过自动化项目，保障了多少次线上发布，其中多少次是线上无故障的，占比多少
5.......
另外，自动化项目的投入时间也要心里有数，但是可以不说，因为很可能投入和产出不成正比，心里有谱避免被领导一问三不知。如果投入较少，产出不错，则可以作为一个亮点数据写出来。
以上这些数据，我认为还是比较容易拿到的，如果这些数据你自己都没有总结，那你可能得明年记得多记录记录，咱们不能只埋头干活

晋升成功

初入一个团队，开发大都对测试有一定的敌意，特别是给他提 bug 提优化的时候，但是当一段时间后，你总能为开发找出他自己都发现不了且质量较高的 bug 时，他就会离不开你了，因为你就是他最后的防线，这是一个测试工程师理想的工作状态