背景
言简意赅，作者为啥要写今天这篇博文呢！其因有三啊！
- 2021 年部门的 OKR 中明确纳入了自动化测试为其中的一个目标。
- 作者本人也把多年的工作对自动化测试的理解做个小总结，希望可以给一些刚参加工作或者即将开展自动化测试的一些新老同学提供一点启发～
- 本次博文的自动化设计思路也就是作者本人所在公司小组的今年的自动化测试建设的设计思路
- 最后还是秉着互相学习，互相进步的想法，欢迎大家添加作者的微信：1010584905共同探讨如何成为一名优秀的软件测试工程师，实现软件测试工程师的自我价值～ 从而实现升职加薪 迎娶白富美 走向人生巅峰............................(😏😏😏😏😏😏😏😏😏😏)。
自动化测试发展过程
主要是以作者自参加工作以来真实的工作经历为角度，讲述一下作者本人看到的这几年的自动化测试的发展历程来讲述自动化的发展过程，作者本人进入软件这个行业于 2012 年，从一个帅气的阳光小伙 一路走来（不信的话可以私聊看照片 😄😄）成为了一个中年大叔但自我感觉不油腻啊～用老赵之前的一句话那就是：小伙简直帅呆了 酷毙了 简直没法比喻了。。。当然这都是开玩笑的😝～我们还要言归正传。
作者当初进入 IT 行业是以一个 Java 软件开发工程师的身份参加了第一份工作，偶然的一个机会公司项目组要搞持续集成，也算是如今大热 devops 的一个冰山一角，项目组架构师牵头用 jenkins 搭建了一套平台，当初功能大概是以天为周期通过 Jenkins 的插件 PMD、findbugs、等其他工具每晚定时触发静态代码扫描和单元测试，第二天查看结果，如果单元测试失败是不可以被上线入库，单元测试覆盖率也必须达到某一指标才可以最终交付，同时我们也又严格的 Code Review，我们被要求编写大量的单元测试（这里单元测试大多都是作为菜鸟的我来编写），不断修改不合格的代码风格，添加注视。从而达到最终的目标。这套组合下来对于当时菜鸟的我来说只是觉得这么开发整个项目运转非常又层次感，就是让人很舒服，大家的代码风格统一可读性上非常好，最终的交付结果也就自然非常高了，当时的测试工程师一般都是基于功能的测试，除了界面的一些 bug 后端的缺陷真的不多。所以单元测试算是我接触的第一种自动化测试了。
从这家公司后来的一个新进的自动化测试工程师那里还接触到了 selenium UI 自动化, 由于有较丰富单测和 UI 自动化经验也不知怎么后来我来到了另一家公司就鬼使神差的成为了一名自动化测试工程师，从这家公司我把基于 selenium webdrver 发挥至极致，可以说是那时的这个框架的封装可以说是业界相对来说比较高级的了，我们做到了 远程执行、并发执行、失败重跑、通过和前端工程师配合增加固定的定位标签，可以自动化生成元素定位的 page 层避免了元素不容易找到的情况。也节省了这部分的编码时间。但是最后 UI 自动化的结果看来其 ROI 非常低！因为我们是个报表项目，感觉完全是个花架子，从那时起我便对 UI 自动化有了新的认知，从此不问 UI 自动化的江湖之事～ 当然 存在即合理 ～在这里并不否认其作用但是一定要用对地方，什么样的项目适合 UI 自动化，怎么使用 UI 自动化，哪些地方可以使用，这都是需要思考的！大多数互联网的项目其实还不是特别适合的。所以UI 自动化测试便是我接触到的第二种自动化测试（说个小插曲如果你会 UI 自动化测试在 2014-15 年左右你面试测试工程师会大大加分）。
随着时间的推移互联网技术快速推进，测试在行业中也做了角色上的细分：测试工程师、服务端测试工程师、自动化测试工程师、测试开发工程师等（有时间可以跟大家在聊一下测试技术或测试角色近 10 年的发展历程），此时服务端或测试开发工程师在日常工作中以接口测试为主，自然也就有了我们现在耳熟能详的接口测试自动化，各种个样接口测试框架，平台也如雨后春笋般百花齐放，所以接口测试自动化是我接触到的第三种自动化，除此之外还有一种自动化就是场景或步骤类的自动化，如一些 saas 项目，私有云公有云的项目。这种自动化没有通用的技术解决方案，多数是根据不同公司不同业务场景工程师自主开发设计的，具体小伙伴可以参考我另一篇博文《一个自动化项目的思考和总结》简单的介绍了这种场景自动化，需详细了解请添加作者 VX：1010584905 进一步一起讨论自动化的发展与实现。以上大概就是作者经历的自动化发展历程，下面就具体的自动化做一下简单的讲解。
自动化测试优点与缺点
优点
快
当整个软件生命周期需要重复测试活动时，自动化测试无疑是最适合的，一旦自动化被创建他将不需要工资夜以继日的为你的项目进行测试，也可以将平日里几小时的工作缩短到分钟级别，尤其是你的项目发布频繁那么这个 “快” 的特点优势将得到最大的发挥，从而释放人力资源，让工程师可以有精力去干更有价值的事情。
准
自动化测试用例一旦被编写完成，他将不假思索的每次执行相同的步骤，所以如果你的其他条件不变，自动化测试脚本没有 bug 的情况下，它的准确度一定是高于人工，作者本人坚信一句话 “程序不会骗人，只有人才会骗人”。人有七情六欲在测试活动容易受各种因素影响，有可能多次执行造成结果都不一样，而自动化程序则不然。
全
自动化测试在某个角度来说可以提升测试的覆盖度及深度，比如：自动化测试可以尝试查看程序内部的情况，通过脚本可以探测程序本身运行情况，如内存使用使用情况，数据运行情况，及文件内容状态是否符合预期，如果你想造个几万几十万用户模拟使用情况，那么自动化必然是最佳选择，靠手工测试必然会让你怀疑人生。
气
尽管自动化测试不能完全解决软件的质量问题，但是它在某个角度来说可以给予工程师信心，有了自动化测试的覆盖是不是每次上线每次重构都更有信心了呢！这种信心是可以提升团队生气，从侧面来说也起到了软件质量保障的作用。
缺点
除了以上的优点，自动化测试也有其显而易见的缺点比如：
时间成本
自动化测试需要前期的时间投入无论是自动化测试框架编写，自动化测试用例的实现，以及维护都是需要时间，往往日常的测试需求已经占据了我们大多的工作时间，中小公司往往没有精力投入到自动化建设当中，所以对于引入自动化的时间点和策略至关重要。
人力成本
自动化测试需要占据人力开发成本，自动化框架的设计往往需要具有编码能力的工程师，框架有了如何让其他工程师用起来也需要后期的培训成本这些都是要占据日常人力。
资源
自动化测试往往不与功能测试共同占用同一个测试环境，其需要独立的测试环境，这就意味着需要更多设备资源的投入。
那么综上所述了自动化的优点和缺点，那么就需要我们合理的引入自动化策略才是自动化测试的根本，如何引入自动化测试呢？如下！！
自动化测试引入策略
针对已存在项目的代码热区引入自动化
假如你是中途加入的一个测试工程师你要为你的项目引入自动化测试，那么作者建议你从项目代码热区开始。什么是代码热区？代码热区多指用户使用的功能最多大多数指最多的接口；或者研发频繁修改的接口函数等；对于那些年八辈子不改动，又不出问题的接口来说实际情况已经证明了其稳定性，那么就没有必要在浪费时间了。
紧跟新功能开发节奏
作者认为理想的自动化节奏是，随着每次的开发迭代，接口自动化的测试用例应该随之补上，因为这些新的自动化测试用例随着新功能开发上线他能立刻在后续的维护中起到保护网的作用，如果你拖延自动化测试用例的上线不但起不到新功能的保护网作用，而且还会造成 “欠债” 现象，越积越多，恶心循环～当然这种理想的状况说起来容易做起来难，中小公司都是业务迭代优先，那么就可能需要较高的沟通成本，首先领导者必须清楚自动化的在项目中的作用，有了领导者的支持那这些问题就不是问题了。
从中间层开始引入自动化
大家都听过金字塔质量模型，如果你想为你的项目引入自动化，那么作者建议你从金字塔中层开始着手自动化构建，其 ROI 最高，中间层一般是指服务的 API 层，从这里入手你的收入产出比最高，最上层的 UI 自动化历史已经证明了其存在的价值，最下层的单元测试虽然价值很高，理想是丰满的，现实却很骨感，以作者经历看来很少有公司的项目组会在单元测试上花费大量的时间成本人力成本，所以推动起来真的很难，也不是说大家觉得没用，就是客观的事情让你用不起来。所以中间层入手收益才最大。
高质量的测试框架及用例
自动化测试也是代码，是代码就需要框架与实现，往往优秀的自动化框架它可以为我们迭代自动化测试用例起到重要作用，优秀的自动化框架必须做到，可扩展性强，可维护性强，逻辑分层清晰，良好的自动化用例应该是独立的，稳定的且运行速度必须快；其他工程师可以以最小的代码实现最稳定的自动化，其次自动化用例并不是越多越好，够用就行切记追求所谓的接口覆盖率，往往因为接口覆盖率你会把时间浪费到了一些使用率低或者已经很稳定的接口上了，所以控制好自动化测试用例的比例就显得尤为重要。
如何应用自动化才能实现收益最大化
我们一般鼓励频繁的跑我们已经实现的自动化，并且需要在不同场景不同环境中跑，才能实现我们自动化的收益最大化，我们可以把自动化在软件开发的生命周期不同阶段，根据自动化用例级别加入到 CI 流程中，前面说了自动化可以解放人力又不拿工资，那就要让自动化 24 小时的跑起来吧。
基于金字塔模型的自动化设计
要想实现之前所说的自动化收益最大化那么自动化分层的设计也就至关重要，我们必须在不同层级中设计实现不同的自动化测试数量，针对最上层的测试用例应该越少越好，而随着测粒度的细分在每层选择不同的测试用例数量，从而构造一个自动化稳定的三角形结构，引用来源：Mike Cohn 在《Scrum 敏捷软件开发》中的金子塔模型，基于 Mike Cohn 其提出的金字塔模型的理论，作者也设计了符合作者所在项目组的自动化金字塔模型：
在作者所在项目组，最上层是基于场景的自动化，这些自动化 case，目前是个位数以内更多是一些场景；除此之外，你也可以根据你自己的项目情况最上层选择不同的自动化比如：UI 自动化，或者主流程的接口自动化；再或者端到端的自动化；中间层是我们更细粒度的测试，涉及了接口。产品框架，步骤，和一些运维命令的自动化，最下层就是单元测试了，一般公司单元测试并非测试人员编写，这块的目标达成就需要测试人员对 RD 单测的推动，测试人员要起到监督作用需要对研发的单元测试提出标准，check 他们的单元测试用例是否健全，check 是否每次迭代提交都能及时补充单元测试，也可以同时增加单元测试的代码测试覆盖率指标进行辅助检查。
总结
说了这么多我们简单的做一下总结，如今的互联网发展都讲究一个字 “快”，讲究 “双周一迭代”，这么高频的发布频率，自动化测试就更为显的尤其重要了，我们上面都提到了一些自动化测试引入策略和优缺点分析，还有根据金字塔模型建立符合自己项目的自动化质量保障建设，从而实现自动化的收益最大化，这里也总结作者一些自动化心得，希望可以帮助大家：
- 不能盲目追求自动化测试覆盖率，自动化测试用例并不是越多越好。
- 良好的自动化框架是自动化测试的根本。
- 历史项目应该从代码热区开始建立自动化。
- 假如你的项目质量情况很稳定，没啥大问题，那么就不必须追求自动化自动化测试用例的数量了。
- 只有在不同环境场不同景运行次数越多，自动化的平均成本才最低，收益才最大。
结尾
欢迎和作者一起探讨如何成为一名优秀的软件测试工程师，实现软件测试工程师的自我价值～ 从而实现升职加薪 迎娶白富美 走向人生巅峰............................(😏😏😏😏😏😏😏😏😏😏)
作者 VX：1010584905
