本文作者：武让

GitLab 是一个全球知名的一体化 DevOps 平台，很多人都通过私有化部署 GitLab 来进行源代码托管。极狐GitLab ：https://gitlab.cn/install?channel=content&utm_source=csdn 是 GitLab 在中国的发行版，专门为中国程序员服务。可以一键式部署极狐GitLab。

更多关于极狐GitLab ：https://gitlab.cn 或者 DevOps 的最佳实践，可以关注文末的极狐GitLab 公众号。

学习极狐GitLab 的相关资料：

1. 极狐GitLab 官网：https://gitlab.cn
2. 极狐GitLab 官网文档：https://docs.gitlab.cn
3. 极狐GitLab 论坛：https://forum.gitlab.cn/
4. 极狐GitLab 安装配置：https://gitlab.cn/install
5. 极狐GitLab 资源中心：https://resources.gitlab.cn
6. 极狐 AI 研发助手：https://coderider.gitlab.cn/

搜索【极狐GitLab】公众号，后台输入加群，备注gitlab，即可加入官方微信技术交流群。

极狐GitLab 公众号后台回复新手指南，免费领取极狐GitLab 新手指南一份，从零到一快速上手极狐GitLab。

1 理论篇

1.1 什么是UI测试

WIKI百科对于UI测试的解释是：

图形用户界面测试是测试产品的图形用户界面（GUI）以确保其符合其规格的过程。这通常是通过使用各种测试用例来完成的。

按照UI测试的目的，可分为逻辑测试和视觉测试：

• 逻辑：主要指通过操作用户界面，如移动鼠标、点击按钮、输入文本等事件测试软件用户界面的反馈是否符合预期。
• 视觉：主要指检查用户界面上的文案、字体、字号、布局、颜色等设计元素是否符合预期。

通常来说，通过自动化手段做UI测试，应更多使用在逻辑测试的场景里，而视觉测试更多依靠人工来处理。

按照应用程序部署的平台不同，一般分为基于手机等移动设备的APP、基于B/S架构的Web应用、基于C/S架构的桌面应用（包括运行在硬件终端上的程序，如ATM机、自动购物机等）。

此外WIKI百科还对UI测试的难点进行了描述：

为了生成一组测试用例，测试设计人员尝试涵盖系统的所有功能并完全执行GUI本身。完成此任务的难度有两个：处理域大小和序列。

与 CLI（命令行界面）系统不同，GUI 可能具有需要测试的其他操作。一个相对较小的程序，如微软写字板有325个可能的GUI操作。在大型程序中，操作数量可以很容易地大一个数量级。

第二个问题是排序问题。系统的某些功能只能通过一系列 GUI 事件来完成。例如，要打开文件，用户可能首先必须单击“文件菜单”，然后选择“打开”操作，使用对话框指定文件名，并将应用程序集中在新打开的窗口上。增加可能的操作数量会使排序问题呈指数级增长。当测试人员手动创建测试用例时，这可能会成为一个严重的问题。

此外，测试人员在必须进行回归测试时面临更多困难。

为解决这些问题，UI自动化测试成为了行业内的大趋势，因为自动化测试的优势就是代替频繁的重复性操作，适合解决在大量测试用例下进行回归测试的难题。

1.2 开展UI自动化测试的条件

虽然UI自动化测试有着其不可替代的优势，但在企业内优先开展UI自动化测试仍是不推荐的。《Selenium 2自动化测试实战》一书中介绍了什么样的项目适合自动化测试，列出了10个条件：

1. 任务测试明确，不会频繁变动
2. 每日构建后的测试验证
3. 比较频繁的回归测试
4. 软件系统界面稳定，变动少
5. 需要在多平台上运行的相同测试案例、组合遍历型的测试、大量的重复任务
6. 软件维护周期长
7. 项目进度压力不太大
8. 被测软件系统开发比较规范，能够保证系统的可测试性
9. 具备大量的自动化测试平台
10. 测试人员具备较强的编程能力

可以看到每一个条件或是凸显UI自动化测试的优势，如频繁回归、大量重复任务等；或是避免UI自动化测试的劣势，如项目相对稳定、需求变动较少、测试人员具备一定的编程能力等。其目的都是为了获得较高的投入产出比，这也是测试金字塔所表达的核心思想。

需要说明的是这10个条件和开展UI自动化测试不是充分必要关系，只是用来参考和评估，毕竟每个企业、每个团队对ROI的要求也是不一样的。

另外按照个人经验，这10个条件里最主要的是需求和界面不能够频繁变动。从时机来看，频繁变动不利于自动化测试发挥替代重复工作的优势；从环境来看，频繁变动不具备开展其他工作的土壤；从人员来看，频繁变动会影响开发和测试人员的心态。属于天时地利人和三不靠，在这样的项目里开展UI自动化测试有较高的风险和失败的几率。

1.3 如何做UI测试

正如前文所说，因为一个应用程序的UI操作逻辑往往很复杂，并且有多重排列组合方式，所以UI测试的用例数量会非常庞大，即使自动化工具可以替代重复操作，但初期编写测试用例还是需要依靠测试人员，如何降低这个工作量？

个人经验是不需要过度追求UI测试用例的高覆盖率，应该把更多精力投入在单元测试、接口测试上，而在UI测试方面，覆盖常规的、主要的业务流程即可。参考28原则，把核心的、相对稳定的主流程通过自动化手段实现，那么相当于做了自动化的冒烟测试。

相较于自动化测试的优势，它的劣势同样明显，工具是人写的，所以自动化测试不适合发现新的Bug。这时候就需要手动测试互补，通过手动测试进行探索性测试，并且把手动测试发现的一些问题编写为测试用例并集成到自动化测试脚本中，不断丰富自动化测试脚本。所以自动+手动，回归+探索的组合式测试方案是行业的主流做法。

UI自动化测试主要用来做回归测试，所以他的运行时机主要有三种：

• 当应用程序的后台、前端发生变化时，主要指提交应用程序代码并发布到测试环境后，触发UI自动化测试，以验证本次代码提交、程序部署是否存在问题。
• 定时执行，设置一个时间计划，定时触发UI自动化测试，以验证程序运行一段时间或进行一些操作后是否存在问题。
• 手动执行，按需运行UI自动化测试。

UI自动化测试的运行模式有两种：

• GUI模式：应用程序运行在真实的设备上，如电脑、手机、硬件终端，测试脚本也在该设备上执行，操作应用程序的GUI进行测试。测试期间该设备GUI独占，不允许进行其他操作，否则会影响测试，所以测试任务只能顺序执行。
• Headless模式：主要指依靠浏览器的能力使Web应用无UI的运行在容器中，如使用Selemium测试Web应用时，可以使用Chrome的Headless模式，由于运行在容器里，所以Headless模式可以并发执行。