基于金字塔模型的自动化测试设计

背景

1. 2021年部门的OKR中明确纳入了自动化测试为其中的一个目标。

自动化测试发展过程

从这家公司后来的一个新进的自动化测试工程师那里还接触到了selenium UI自动化, 由于有较丰富单测和UI自动化经验也不知怎么后来我来到了另一家公司就鬼使神差的成为了一名自动化测试工程师，从这家公司我把基于selenium webdrver 发挥至极致，可以说是那时的这个框架的封装可以说是业界相对来说比较高级的了，我们做到了 远程执行、并发执行、失败重跑、通过和前端工程师配合增加固定的定位标签，可以自动化生成元素定位的page层避免了元素不容易找到的情况。也节省了这部分的编码时间。但是最后UI自动化的结果看来其ROI非常低！因为我们是个 表项目，感觉完全是个花架子，从那时起我便对UI自动化有了新的认知，从此不问UI自动化的江湖之事～ 当然 存在即合理 ～在这里并不否认其作用但是一定要用对地方，什么样的项目适合UI自动化，怎么使用UI自动化，哪些地方可以使用，这都是需要思考的！大多数互联 的项目其实还不是特别适合的。所以***UI自动化测试***便是我接触到的第二种自动化测试（说个小插曲如果你会UI自动化测试在2014-15年左右你面试测试工程师会大大加分）。

自动化测试优点与缺点

优点

快

当整个软件生命周期需要重复测试活动时，自动化测试无疑是最适合的，一旦自动化被创建他将不需要工资夜以继日的为你的项目进行测试，也可以将平日里几小时的工作缩短到分钟级别，尤其是你的项目发布频繁那么这个“快”的特点优势将得到最大的发挥，从而释放人力资源，让工程师可以有精力去干更有价值的事情。

准

全

自动化测试在某个角度来说可以提升测试的覆盖度及深度，比如：自动化测试可以尝试查看程序内部的情况，通过脚本可以探测程序本身运行情况，如内存使用使用情况，数据运行情况，及文件内容状态是否符合预期，如果你想造个几万几十万用户模拟使用情况，那么自动化必然是最佳选择，靠手工测试必然会让你怀疑人生。

气

尽管自动化测试不能完全解决软件的质量问题，但是它在某个角度来说可以给予工程师信心，有了自动化测试的覆盖是不是每次上线每次重构都更有信心了呢！这种信心是可以提升团队生气，从侧面来说也起到了软件质量保障的作用。

缺点

除了以上的优点，自动化测试也有其显而易见的缺点比如：

时间成本

自动化测试需要前期的时间投入无论是自动化测试框架编写，自动化测试用例的实现，以及维护都是需要时间，往往日常的测试需求已经占据了我们大多的工作时间，中小公司往往没有精力投入到自动化建设当中，所以对于引入自动化的时间点和策略至关重要。

人力成本

自动化测试需要占据人力开发成本，自动化框架的设计往往需要具有编码能力的工程师，框架有了如何让其他工程师用起来也需要后期的培训成本这些都是要占据日常人力。

资源

自动化测试往往不与功能测试共同占用同一个测试环境，其需要独立的测试环境，这就意味着需要更多设备资源的投入。

那么综上所述了自动化的优点和缺点，那么就需要我们合理的引入自动化策略才是自动化测试的根本，如何引入自动化测试呢下！！

自动化测试引入策略

针对已存在项目的代码热区引入自动化

紧跟新功能开发节奏

从中间层开始引入自动化

高质量的测试框架及用例

自动化测试也是代码，是代码就需要框架与实现，往往优秀的自动化框架它可以为我们迭代自动化测试用例起到重要作用，优秀的自动化框架必须做到，可扩展性强，可维护性强，逻辑分层清晰，良好的自动化用例应该是独立的，稳定的且运行速度必须快；其他工程师可以以最小的代码实现最稳定的自动化，其次自动化用例并不是越多越好，够用就行切记追求所谓的接口覆盖率，往往因为接口覆盖率你会把时间浪费到了一些使用率低或者已经很稳定的接口上了，所以控制好自动化测试用例的比例就显得尤为重要。

如何应用自动化才能实现收益最大化

我们一般鼓励频繁的跑我们已经实现的自动化，并且需要在不同场景不同环境中跑，才能实现我们自动化的收益最大化，我们可以把自动化在软件开发的生命周期不同阶段，根据自动化用例级别加入到CI流程中，前面说了自动化可以解放人力又不拿工资，那就要让自动化24小时的跑起来吧。

基于金字塔模型的自动化设计

总结

1. 不能盲目追求自动化测试覆盖率，自动化测试用例并不是越多越好。
2. 良好的自动化框架是自动化测试的根本。
3. 历史项目应该从代码热区开始建立自动化。
4. 假如你的项目质量情况很稳定，没啥大问题，那么就不必须追求自动化自动化测试用例的数量了。
5. 只有在不同环境场不同景运行次数越多，自动化的平均成本才最低，收益才最大。

结尾