自动化脚本该写哪一些用例呢

# 自动化脚本该写哪一些用例呢？

我的经历

1. 第一家公司的时候， 自动化是直接90-95%的覆盖率， 即如果有100个功能用例的话， 那么就至少有90个自动化脚本， 但是这家公司，加班很严重，自动化的人员也很充足。功能测试比自动化测试的人大约能去到2:1的样子， 最多的时候， 可能能去到1:1。
2. 第二家公司的时候， 自动化是直接98%以上，也有可能是99%， 因为产品的特殊性， 做功能测试一定要通过脚本去测试，所以导致一定要写脚本，所以自动化的覆盖率非常高，部门内的任何测试，都能写自动化脚本， 并且自动化脚本是最简单的工作
3. 第三家公司的时候，自动化的输入是随机性的，主要看领导的理解和思路
4. 朋友所在的公司，做基础设施的， 覆盖率是30%， 主要就是直接由功能测试人员自己挑选30%的功能用例来写自动化
5. 另外一个朋友所在的金融行业公司，是直接对基本功能去写自动化，并且是完全没有用例指导和约束的。用的metersphere来写的，老实说， 这里的自动化实践真的很差。

我的反思

1. 大公司人力充足可以做到90甚至99%的覆盖率， 很让人羡慕， 但是并不适合所有公司， 尤其是小公司
2. 既然不适合小公司，那么小公司应该挑选哪些来写自动化呢， 要考虑哪些点呢
3. 要考虑效率， 成本， 收益
4. 还要考虑业务的主方向， 未来方向， 以及核心功能， 主干功能， 底层功能
5. 所以， 每个需求都挑选P0级别的， 大概10%的比例来写自动化？
6. 所以，把主干功能都捋出来一遍， 都写一遍？
7. 是否要有个什么顺序？
8. 是否可以直接根据 发现的BUG来写成自动化？

我现在的想法

1. 如果是全新开始的话，先把核心功能写完， 比如核心数据核心流程给写一遍， 积累框架和关键字
2. 对于每个需求，结合技术架构，根据软件的失效规律和场景， 决定是否写10%比例左右的用例
3. 分析老功能的线上问题，做增强测试，并挑选常见场景，或者关键依赖的路径来写自动化
4. 以上是从业务角度去分析的， 并且也是效率最大化， 成本最低， 收益最高的方式去做的
5. 这些P0脚本也就是主干功能， 可以这么理解，如果这个脚本失败了，那么该功能就直接阻塞了， 或者失效了
6. 另外还可以从技术的角度去分析， 首先就是从底座的技术去覆盖，从关键的耦合点去覆盖， 从防腐层去覆盖（这个暂时仅是我的猜想）

欢迎关注我！！
可以私信我，一起进群学习！
开源的优秀自动化框架 GitHub - WaterLoran/LoranTest

开源项目中， 可以看到我的联系方式哦。