软件自动化测试当中最简单也是最常用接口自动化测试，当我们投入到实际工作应用中就会发现，虽然接口测试很有效也很容易推广开来，但是很多时候真正需要测试验证的不仅仅是接口测试的返回，还包括前端页面的重现。所以近下来的学习内容就将进入到 WEB 自动化（即 WEB 端 UI 自动化）。

什么是 WEB自动化

• WEB 自动化测试就是把在网页上的人工操作转化为使用机器、软件、程序来测试产品的过程。也就是把大量需要人工回归用例、人工操作的这些手段由计算机代替执行的一种测试方式。模拟人工执行的一系列操作，同时最终会抓取并判断结果是否符合我们的预期的这样一个过程。

• 换而言之，就是把 “点点点” 通过编程手段实现的一种测试的手段。（做 WEB 自动化之前首先需要知道自己要测什么，把部分的 “点点点” 的内容。转化为代码、脚本，减轻手工测试的工作量 ，从而提高产品的质量。）

• 做 WEB 自动化与做接口自动化有一个相像的地方，那就是 WEB 自动化同样是不在于发现新的功能的问题，而是保证产品、项目在迭代与重构的过程中，原有的已经上线过的功能依旧保持正常。以及执行一些手工很难达到的测试场景目的。（比如一个快速输入的场景，想要输入几百个字符，这样的快速输入的问题就需要 WEB 自动化来实现。）

• 还有就是在意比较大型的项目中，功能点太多的情况下，没有办法保证每一次上线发布之前通过手工的方式把这些功能都测试一遍，不太现实。不管是测试人员也好，还是开发人员也好都没有办法保证所有的功能在上线之前都能够验证完毕 。因此就需要这么一套自动化测试的方式，主要测试已经有的功能保证在每次交互的时候，已有的功能不会出现太大的问题。

• 下图就是实现 WEB 自动化的一种方式。

为什么要学习WEB自动化

在真实的工作场景非 WEB 的测试，也就是接口测试，和我们 WEB 测试是互为补充的。自动化的基本原则是已接口自动化测试为主，WEB 自动化作为必要的补充。

比较常见的需要 WEB 自动化补充的点，主要有两个方面：

1. 偏向于用户维度的场景测试

2. 验收的确认测试

偏向于用户维度的测试，要求从用户真实的角度去测试产品的实现，只有包含了 WEB 层才能完整的验证用户的真实体验。从实现的角度来看，这一类的自动化测试用例不会覆盖的那么完善，只覆盖最基本的和核心的端到端的用户场景，所以一般情况下不使用 “WEB自动化” 测试那些步骤特别负载或者边边角角的异常场景的测试用例，这是一个方面。

另一方面就是我们的测试逻辑和用户界面绑定在一起，无法绕过界面直接测试核心逻辑页面，在这种情况下也是不得已而为之的，在实际工作中也是最经常出现的。尤其是现在，频繁的使用微服务的情况下，服务与服务之间的交互变得比较复杂，就比较难直接通过接口一次性搞定。这样就会造成接口与接口之间的处理上存在着不稳定的因素，甚至有些处理是完全放到前端来做处理，这个时候就需要 " WEB自动化" 来进行辅助。

说理两个方面，无论是上面说的哪种情况。都有一个共同的特征，都是从一个 最终用户 来出发，对大多数有页面的系统来说，WEB 才是最理想的集成或者说系统测试的入口。也是对于产品来说、对于用户来说、对于公司来说最最需要测试的地方，同时也可以弥补开发自测、接口上的一些不足。

当然，我们的最终目标是服务于测试项目。取代那些重复的、枯燥的…操作，从测试进阶上的要求，将我们的技术范畴从使用什么技术去完成，变为多角度多纵深的去完成。

学习完自动化就会发现一个事情， 接口测试好不好呢？那是相当的有效！但是呢，接口是看不到摸不着的，但是如果做 WEB 自动化框架，能跳出浏览器就简直太神了。

同时呢，也是为了我们面试这一环节能够获得更好的待遇。

简单来说就是以下四点：

1、WEB自动化是面向用户的 “自动化”。

2、可以弥补单元测试、接口测试的不足。

3、取代部分重复枯燥的操作。

4、功能测试岗位的进阶。

什么样的项目适合做WEB自动化

有了要学习 WEB自动化 的必要性并不是说我们马上就要动手去做了，还需要稍微思考一个问题，是不是所有的项目都适合做 WEB自动化？上文关于 WEB自动化 的重要性说了很多，在关于自动化测试策略的手提到 “以接口测试为主，WEB自动化进行适当的补充”。为什么说是补充，而不是使用 WEB自动化 作为主力呢？因为 WEB自动化的缺点也是很明显的。

1、开发 WEB自动化 用例的成本相较于 接口自动化 要多很多

2、WEB自动化不是很稳定，在页面变更、迭代过于频繁的项目中，可能页面今天是这个样子，明天又变成另外的样子了。这样的话，之前辛辛苦苦写的很多的 WEB自动化测试脚本 很有可能就会废掉，需要推翻重写。

所以在这里，我们就来聊一聊什么样的项目能够最大程度的发挥 WEB 自动化的优势。对应前面所说的，首当其冲的就是 迭代可以很多、需要构建验证的次数也可以很多，但是尽量不要有频繁的变动，界面越稳定越好，而且项目的维护周期长，能够稳定存在。

稳定对于自动化测试来说，非常的重要，这样能够让我们的 WEB自动化脚本 能够使用的频率更高，这样脚本的成本也就降的越低。

如下：

1、任务测试明确，不会频繁变动。

2、每日构建后的频繁测试验证。

3、比较频繁的回归测试。

4、软件系统界面稳定，变动较少。

5、软件维护周期较长。

6、被测试系统开发比较规范，能够保证系统的可测试性。（前端代码太随意，测试人员两行泪。）

7、测试人员具备不错的编程能力。

8、项目进度压力不宜太大。（这句可能有点玩笑，目前我所接触的项目压力不大的只有银行的后台项目，一条需求审批得半年。）尤其是在任务的前期，刚开始动手写的时候，尽量争取到充裕的时间去搭建框架、编写脚本等等。

WEB 自动化面临的问题如何改进

上面我们提到过，当遇到不稳定、难以维护的项目时，是非常不适合使用 WEB自动化 的。那么面对这个问题，要如何改进呢？

有的公司在自动化测试领域有一个 721 规则，这个规则就是说 70% 的自动化测试工作几种在底层的接口测试和一些单元测试， 20% 的测试工作是一些集成的测试，10% 的测试工作是尽量通过 UI自动化 来实现。

既然 WEB 自动化是需要有它的辅助作用的，那么就需要用有限的条件、有限的精力将 WEB 自动化做的更好，怎么样才能叫更好呢？就需要做到以下三点：

• 更优秀的架构（框架）设计

• 更合理的维护方式

• 更稳健的测试环境

合理的架构可以保证我们自动化测试代码的编写更加方便、简洁；维护起来更加的容易；环境操作起来更加的简单稳定。

OKK，关于WEB自动化的介绍和一些基础理论的探讨到这里就告一段落，下一章节我们将了解一下 "软件自动化测试工具的历史与WEB自动化测试工具的选择。"

作者：渴望力量的哈士奇

原文链接：https://blog.csdn.net/weixin_42250835/article/details/125126560