自动化除了你写了多少条自动化用例拿来生成个柱形图外，基本没法量化吧？ 根本不指望它能发现多少 bug 的。我工作价值就比较容易写，直接写了全年写了多少测试用例，发现多少 bug,测试了多少项目........虽然很多大佬看不上这个指标，但是的确是量化的好数据

哈哈哈提到数据，在鹅厂外包的时候，导师做了个平台拉取了 tapd 上面的每个测试同学手头上负责的需求，每个迭代提了多少个 bug 单，每个 bug 单的具体闭环时间，都整理统计显示在了平台面板上。每周开会都会提一嘴谁的数据不好看 ，现在这个更离谱直接手动统计巨他妈 S13，数据随便写跟玩的似的

主要这些领导不满足，自动化的节省人力也不清除该怎么计算才合理

看来大部分还是看 bug 数和需求数来衡量，以后多提点建议的。

主要按照正确的思路去写就好。

先说支持的产品最终线上质量 -> 为了达到这个质量做了哪些事情 -> 这些事情对应的结果和产出是什么（业务测试或者各种专项）

唉~
这些事用汉字去描述还是挺好说也比较合适的
but！
这人就是让你整个数字出来，其名曰：数据说话。
这测试的工作咋去整些数值啊，要么就统计下用例数 bug 数，但感觉这样又有点空洞
真正体会到了啥叫刻板

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

有道理！

如果提供的数据不用于和其他人考核，仅给领导 PPT 提供，随便编点自圆其说的就行。要用这个数据和人比，就很烦了。

做自动化测试的目的是什么？其核心是回归测试，没有自动化测试，回归测试的人力成本是多少，有自动化测试后，回归测试的人力成本又是多少，这不就有数据了吗？再往细说，自动化用例的覆盖率是多少，这些都有数据可说啊。
测试日常工作也有数据支持，接了多少需求，bug 数，bug 等级，需求与 bug 比等等

思路不错，学习了

感觉可以按照一条回归用例 1 分钟的执行速度算，多少条自动化用例就减少多少分钟

还好，人少，应该不比