干货 | 基于 BDD 理念的 UI 自动化测试在携程度假的应用

作者简介

 

Leo Li，携程高级软件工程师，负责度假 BDD-Test UI 自动化测试框架的研发、维护和迭代等工作。

如今无论大公司还是小公司都越来越重视测试质量。并且前端领域越来越繁荣，前端工程也越来越复杂，纯靠人力手工测试已经显得有些力不从心并且更容易出错。因此在项目中引入 BDD 理念进行自动化 UI 测试，让项目质量可以通过自动化工具来保障也被提上日程。本文将介绍携程度假团队是如何将其付诸实践，希望能给大家带来一些启发。

一、UI 自动化测试背景以及意义

在日常开发中，我们的程序出现 Bug 是一件非常正常的事情。Bug 本身并不可怕，可怕的是我们把 Bug 带到真正的生产环境中。为了减少 Bug 被带上生产环境的可能性，我们已经做了许多：从代码提交后 GitLab CI 自动执行单元测试并进行 Sonar 代码质量扫描，再交付测试同学人工测试，最后灰度发布上线。这一系列的流程已经很好地帮助我们降低了 Bug 被带上生产的概率了。

作为前端开发的我们来说，已经用上了诸如：TypeScript，EsLint 等现代化开发工具来提升代码的质量。这些工具或框架可以把一些问题在开发阶段暴露出来，但是这还远远不够。那么我们的前端工程是不是也可以使用自动化测试来帮助我们提升项目质量呢 ？

说到自动化测试，其实在后端领域是非常普遍的（主要是单元测试和API 测试），但是在前端领域却应用的非常少 （UI 自动化测试）。按照软件工程自底而上的概念，前端测试一般分为单元测试（Unit Testing）、集成测试（Integration Testing）和端到端测试（E2E Testing）。

从下面这张图可以看出：从下往上测试的复杂度（成本）将不断提高，另一方面测试的收益反而不断降低。从运行测试速度上来看，三种测试的运行速度是呈倒金字塔结构。即单元测试运行得最快，开发成本也是最低的。随后是服务测试，最后是 UI 自动化测试。

随着我们的业务高速迭代，技术不断革新，我们的系统也变得越来越复杂，需要高质量的代码设计以及高质量的代码实现去支撑。相信大家在实际工作中绝大多数遇到的是这样的场景：遇到比较大的项目，这些项目由于种种原因，前人留下了各种坑。历史代码质量非常糟糕，可能修改一个小点，却产生了一个影响主流程的毁灭性 Bug。

这也是为什么，很多小伙伴发现之前遗留的代码写的非常糟糕，只要能跑，便不会主动去重构它的原因。主要是担心重构后引起新的问题，同时也会加大测试的工作量。即便，你投入了大量的时间和精力进行了重构，可能未必得到比之前更好的效果，甚至可能由于业务的调整，辛苦重构的代码直接要被废弃了。遇到这种情况，不仅开发重构的成本是非常高的，而且测试人员对发布的信心也是不足的。

因此，我们需要引入 UI 自动化测试，针对系统的核心业务流程进行自动化测试用例的编写。当我们的代码进行了修改甚至重构，我们的自动化测试就会一次次的去运行，如果通过了，证明我们新修改的代码没有影响到主流程，如果失败了，那我们也可以第一时间发现问题，去修复我们的代码。 

总结如下：

• UI 自动化测试在测试金字塔模型中处在顶层

• UI 自动化测试实现起来难度大成本高

• UI 自动化测试能有效增加开发与测试人员的信心

二、BDD UI 自动化测试理念

在说 BDD-UI-Testing 之前，我们先来看看 TDD、ATDD、BDD、DDD 这 4 个开发模式。

• TDD：测试驱动开发（Test-Driven Development）

• ATDD：验收测试驱动开发（Acceptance Test Driven Development）

• BDD：行为驱动开发（Behavior Driven Development）

• DDD：领域驱动开发（Domain Drive Design）

在我们日常工作中比较常见的其实是 TDD & ATDD 。即：我们在开发真正的代码前会开各种需求评审，技术评审，测试用例评审等会议。业务人员、产品经理、开发人员、测试人员会充分沟通，以确保需求被充分记录。在编写真正实现功能的代码之前会先要求测试人员提供测试用例。这种开发模式主要思想是：在正式编写需求功能的代码之前，先编写单元测试代码，再编写需求功能代码满足这些单元测试代码。

接下来我们来看看，我们日常开发项目时候的传统开发流程（W 模型）：

在 W 模型中，每一份项目文档（PRD），都对应着一份测试文档（测试用例）。

那么我们再来看看 BDD 流程是怎么样的：

采用 BDD 流程进行开发，由外而内，持续地描述当前系统或模块的行为，并为之实现自动化（即步骤定义）。当产品代码部分完成后，右侧的一系列测试活动都已经自动化了。

从层次上来说，BDD 是基于 TDD 的，或者说在自动化测试中，TDD 所在的位置比较底层，是基础，而 BDD 则是它的演进版本。

BDD 核心的是，开发人员、QA、非技术人员和用户都参与到项目的开发中，彼此协作。BDD 强调从用户的需求出发，最终的系统和用户的需求一致。BDD验证代码是否真正符合用户需求，因此 BDD 是从一个较高的视角来对验证系统是否和用户需求相符。

看到这里，大家肯能会对上面的理论知识有点蒙圈。那么让我们来看下 BDD 的交互过程：