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

背景

言简意赅，作者为啥要写今天这篇博文呢！其因有三啊！

1. 2021年部门的OKR中明确纳入了自动化测试为其中的一个目标。
2. 作者本人也把多年的工作对自动化测试的理解做个小总结，希望可以给一些刚参加工作或者即将开展自动化测试的一些新老同学提供一点启发～
3. 本次博文的自动化设计思路也就是作者本人所在公司小组的今年的自动化测试建设的设计思路
4. 最后还是秉着互相学习，互相进步的想法，欢迎大家添加作者的微信：1010584905共同探讨如何成为一名优秀的软件测试工程师，实现软件测试工程师的自我价值～ 从而实现升职加薪 迎娶白富美 走向人生巅峰…(😏😏😏😏😏😏😏😏😏😏)。

自动化测试发展过程

主要是以作者自参加工作以来真实的工作经历为角度，讲述一下作者本人看到的这几年的自动化测试的发展历程来讲述自动化的发展过程，作者本人进入软件这个行业于2012年，从一个帅气的阳光小伙 一路走来（不信的话可以私聊看照片 😄😄） 成为了一个中年大叔但自我感觉不油腻啊～用老赵之前的一句话那就是：小伙简直帅呆了 酷毙了 简直没法比喻了。。。当然这都是开玩笑的😝～我们还要言归正传。

作者当初进入IT行业是以一个Java软件开发工程师的身份参加了第一份工作，偶然的一个机会公司项目组要搞持续集成，也算是如今大热devops的一个冰山一角，项目组架构师牵头用jenkins 搭建了一套平台，当初功能大概是以天为周期通过Jenkins的插件PMD、findbugs、等其他工具每晚定时触发静态代码扫描和单元测试，第二天查看结果，如果单元测试失败是不可以被上线入库，单元测试覆盖率也必须达到某一指标才可以最终交付，同时我们也又严格的Code Review，我们被要求编写大量的单元测试（这里单元测试大多都是作为菜鸟的我来编写），不断修改不合格的代码风格，添加注视。从而达到最终的目标。这套组合下来对于当时菜鸟的我来说只是觉得这么开发整个项目运转非常又层次感，就是让人很舒服，大家的代码风格统一可读性上非常好，最终的交付结果也就自然非常高了，当时的测试工程师一般都是基于功能的测试，除了界面的一些bug后端的缺陷真的不多。所以***单元测试***算是我接触的第一种自动化测试了。

从这家公司后来的一个新进的自动化测试工程师那里还接触到了selenium UI自动化, 由于有较丰富单测和UI自动化