我们目前的项目，自动化依据为手工测试 case，占比应该也有 90%， 除非 case 中有一些步骤框架无法支持，那就要提单申请 skip 这条 case，跟你们情况也类似， 大部分操作都能复用， 要现写代码的 case 很少。大部分时间都是在折腾测试数据，因为做自动化的同事可能对具体业务不是很熟悉， 给过来的手工 case 有些带了测试数据，那就很好实现， 但是没有数据的就要自己想办法，经常一条 case 造数据花了一天时间， 实际实现就几分钟。

接口用例 100%；功能用例 80%，几乎包含所有特性场景

集成电路行业不一样，各种工具、检测仪器、工程软件需要大量的自动化。纯软件行业的自动化没有说一定需要多少占比，有专门的测试开发组自动化程度就高，没有专门的测试开发组，自动化就是用空闲时间做，比例非常低。如果你们终端产品是 ToC 的，除了软件 APP 外，有时间的话硬件应该都可以做，要学 C 系列编程或者 shell 命令去控制终端产品运行，这些基本上硬件测试都可以做

我们产品是 to b 的，可以实现的自动化，信号类的性能测试就是封装好的，具体测就是跑一遍就行。实现的功能类，对应的自动化方法也都有，不过就是中后期或者压测，调整一下脚本跑就行。日常测试我们还是手动占的多，自动化只是说有这个技术，但是没有很依赖，就是要用了，调一调。接触到的这个新公司说他们自动化占日常 90% 那基本纯开发了吧

大佬

自动化程度为 0%，纯手工测。一群人干活，津津有味。

从结果来看，当然是希望 100% 覆盖。 但还是要看投入产出比。
根据测试金字塔， 更多的自动化应该放在 UT， API 上面， UI 的部分能多做就多做，不行就挑重点的覆盖； 然后如果是长期的产品， 就需要维护一个回归测试的用例库，然后朝着这个目标去慢慢把越来越多的回归用例自动化。这样后面可以大量节省回归测试的时间。

说个我过去的一个 O 吧，都达标了，供参考：(服务端/客户端一样，测试环境，预发环境未纳入）

1. 核心接口覆盖率>=90%
2. 核心接口通过率>=95%
3. 自动化发问题拦截率>=10%
4. 核心场景覆盖率>=80%

下一个目标：

1. 原来数值上再提高
2. 预发环境指标定义
3. 线上巡检定义
4. 全量用例占比扩展定义