行为驱动开发在携程机票前端研发流程中的实践

前言

过去，在携程机票前台团队保障研发质量的体系中，采用先开发后测试的模式，测试验收环节以手工测试为主。

机票预订研发流程中 BDD（行为驱动开发）模式的引入，统一了技术人员和非技术人员对软件行为描述的语言，均衡了自动化测试与手工测试之间的关系；入门级中文编程易读易用，且支持细颗粒度用例及海量用例复用。

一、困境

传统的敏捷软件开发，产品经理根据用户诉求和商业目的撰写 PRD 文档，测试工程师基于 PRD 文档考虑边界值和场景排列组合产出测试用例文档，软件工程师按照自己对需求的理解实现代码，最后的验收环节由手工测试完成。

在这个过程中，容易出现这些问题：

各方低质量的沟通

产品经理和技术人员分别站在不同的角度，使用不同的专业术语描述软件的行为，这使得沟通往往反复进行。

难以维护与线上逻辑一致的文档

PRD、用例文档和软件代码都是对软件行为的描述，要保持这三份文档逻辑的同步是投入高收益少的事情，实际上他们通常是不同步的。如果遇到项目重构或团队人员变动，需要花费较多的时间才能整理与线上软件行为一致的文档。

先开发后测试放大风险

实际项目经验表明：问题暴露的时间越临近发布时间，修复问题的成本越大。

手工测试限制迭代速度

每次发布前，投入手工测试做回归，周期长，成本高，限制了发布的次数。

UI 自动化成本高覆盖低

自动化测试需要较高的编程能力，对于功能测试人员门槛较高。

我们尝试通过 BDD 缓解这些问题。

二、什么是 BDD

什么是 BDD ？参考维基百科的描述：

行为驱动开发（英语：Behavior-driven development，缩写 BDD）是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA 和非技术人员或商业参与者之间的协作。BDD 最初是由 Dan North 在 2003 年命名，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。在过去数年里，它得到了很大的发展。

BDD 的重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识。它通过用自然语言书写非程序员可读的测试用例扩展了测试驱动开发方法。行为驱动开发人员使用混合了领域中统一的语言的母语语言来描述他们的代码的目的。这让开发者得以把精力集中在代码应该怎么写，而不是技术细节上，而且也最大程度的减少了将代码编写者的技术语言与商业客户、用户、利益相关者、项目管理者等的领域语言之间来回翻译的代价。

使用 BDD 的敏捷软件开发包括以下关键步骤：

• 需求各利益方（产品，测试，开发）对需求进行充分讨论

• 讨论基于软件的行为展开

• 讨论的产出为自然语言书写的非程序员可读的测试用例文档

• 产出的测试用例能在自动化测试平台上执行

• 程序员专注于编写代码通过测试用例

BDD 是一种软件过程的思想或者方法，而不是一个技术框架或者系统。

为了建立 “自然语言测试用例文档”和“自动化测试代码”间的关联关系，需要用到支持 BDD 工具，我们使用了 Cucumber。

为了实现 BDD 中“测试用例能在自动化测试平台上执行”，需要用到 UI 自动化测试框架，我们使用了 Macaca。

三、BDD 改造过程

Cucumber

Cucumber 是一种支持行为驱动开发的工具。Cucumber 提供了一套名为 Gherkin 的语法规则，一个功能的描述由多个场景组成，一个场景由多个语句组成。

以 “假如( GIVEN )” 开头的语句描述的是场景的前提条件、初始状态， 以 “当( WHEN )” 开头的语句表示采取某个动作或者是发生某个事件， 以 “那么( THEN )” 开头用来描述一种期望的结果。每条自然语句将和一个代码编写的自动化测试方法对应，这让整个文档变得可执行。

如下 feature 文档描述了在机票单程列表页的直飞优先排序功能：

# language: zh-CN功能: 排序-单程列表页
  场景:    假如 跳转页面到[机票单程列表页]    当   点击[直飞优先按钮]    那么 第[1]程列表页按照直飞航班在前，中转航班在后排序

Macaca

Macaca 是阿里开源的前端 UI 自动化测试框架。业内优秀的自动化测试框架不少，最终我们选择 Macaca 有以下几个原因：

• 跨平台 API 统一性 — Macaca 支持 PC、Android、iOS 和 Hybrid，并从 API 的设计上抹平了各平台的差异，这样的设计对测试跨平台的 React Native 应用有利；

• 文档和周边工具丰富 — Macaca 官方网站提供了丰富的中英文文档，有利于框架的快速接入使用，同时提供了 app-inspector 等常用工具，方便了控件的查找定位；

• 多语言支持 — Macaca 支持使用 Java、JS 和 Python 编写测试脚本，其中 Java 和 JS 是团队中常用的开发语言，降低了学习成本；

• 开源 — 能看到源代码，方便问题定位和功能扩展。

MEC

我们在 Cucumber 和 Macaca 的基础上，整合出一系列通用的工具和完善的文档，取名为 MEC (macaca eating cucumber)。为了让 BDD 变得轻松和高效， MEC 做了这些事情：

1）扩展 Macaca Api

支持在携程 app 中打开 Schema，绑定服务 Mock，登陆账号等功能。

2）提供开箱即用的公共自然语句

30+ 条，涉及交互、页面元素断言、服务 Mock、页面跳转等场景的可执行自然语句。

3）提供 CLI 改善使用体验

提供 10 个命令，涵盖项目初始化、打补丁、运行、下载 app、编译、生成报告等场景。

4）支持基于 UI ViewModel 的校验提升自动化测试覆盖率

基于 UI 自动化框架，能方便的对可视区域内的单个页面元素进行测试，但对以下场景则不能很好覆盖：

• 基于多个页面元素的关系的判断 - 比如判断航班列表按照低价优先展示，航班在列表中的顺序越靠后，价格越高；

• 长列表 - 需要把要校验的元素滑动到可视区域，才能获取；

• 更快的执行速度 - 运行在移动设备上的 UI 自动化稳定性和执行效率不理想；

我们的解决方案是将页面上展示的信息用数据的方式发送给 MEC Server， 如 React 中把 state 发送出来，测试用例的断言部分，直接校验界面数据，而不再通过 UI 自动化框架实现。

5）实现 Cucumber 场景片段复用

编写 feature 有一个痛点：有的固定语句组合会出现在多个 feature 中。Cucumber 没有提供类似编程可以抽象公用方法的功能，这不利于用例的编写和维护。我们的解决方案是在原来的语法规则上做扩展，通过新增编译过程，把使用了场景片段复用功能的 feature 转义成标准语法的 feature。

6）支持业务方做语句扩展

MEC 作为通用的 BDD 解决方案，提供了 30+ 条开箱即用的自然语句，但对于业务方，也有封装与业务强相关的语句的需求。针对这样的使用场景，MEC 提供了 API，方便业务方对自然语言做扩展。

7）执行报告

MEC 提供了报告模板，用例运行结束会生成直观的运行结果报告。

8）文档和推广

为了向团队中的非技术人员和技术人员推广 BDD 模式，帮助手工测试利用 BDD 转型自动化测试，我们提供了接入文档。

四、测试开发同时进行

BDD 意味着相对于开发环节，测试可以同步进行或者先行；使用自然语言编写 feature 意味着原本的功能测试人员可以较容易的参与自动化测试。现在，研发流程从之前的先开发后测试演变为测试开发同时进行：

五、回顾

随着软件过程中引入 BDD，feature 文档统一了各方的沟通语言并作为一份活的文档，保持着与线上软件行为的一致，让各方更容易达成共识；研发模式的改变让测试开发工作可以同时进行，减少了发布前夕才发现问题带来的风险；质量保证环节从手工测试为主到自动化为主，降低了发布的成本并提高了准确性。

现在，国际机票预订主流程 UI 自动化测试用例覆盖率达到 90%+，集成测试成本降低了 75%。

附录

1、Macaca https://macacajs.github.io

2、Cucumber https://cucumber.io

作者介绍：

任跃华，携程机票前台软件工程师，参与了国际机票 RN Clean Architecture 落地和 MEC 中文测试框架研发工作。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

https://mp.weixin.qq.com/s/TSvg0nVPTffLp9jfqU3wdA