基于数据驱动的酒店对账自动化测试系统

随着马蜂窝酒店业务规模的不断扩大，酒店平台与各 OTA 的业务往来越来越频繁。实际业务中，在向各 OTA 平台结算金额前，我们需要通过对账环节与自身系统订单进行比对，确认双方订单金额、状态等是否存在异常，并以此作为结算金额的计算依据。

为什么需要自动化测试?

大家都知道，账务数据对精确性的要求非常高。之前酒店账务数据一致性的测试，基本是依靠财务人员手工处理。

图1：过去我们是这样的

业务的增长使对账系统的测试任务越来越多，传统的测试方法导致的问题愈加明显：

1)多源数据。账务数据来自不同的 OTA 平台，数据格式没有统一标准和规范，影响数据处理效率。

2)大量数据的处理效率以及准确性。数据的测试结果由账务人员手动对比 Excel 文件获得，每月都需要处理海量的流水数据，处理慢、精度低，并且不可避免的有错误出现。

3)多轮回归测试。测试时任务流程长且重复单调，人工在多轮测试后，非常容易疲惫厌倦，导致错误率上升，影响接下来的测试结果。

4)问题定位。使用手工测试，很难完整地记录测试结果和测试报告，在测试过程中遇到的异常情况，很多情况下无法进行实时记录，使得问题定位时花费较长时间。

基于酒店对账任务的现状和问题，我们决定决定采用以 Excel 表格作为数据源，使用 Java 语言来整合、筛选以及数据对比的方式，搭建一套酒店对账自动化测试平台，一方面可以有效地在短时间内处理大量数据;另一方面可以将财务人员从庞杂的手工对账测试中解放出来，提高工作效率。

图2：现在我们是这样的

通过本文，希望和大家分享过去几个月马蜂窝酒店财务对账项目的探索和实践，并对对账自动化测试平台进行一个总结。

基于数据驱动的自动化测试系统

上文提到过，酒店的对账数据来自于不同的 OTA，数据格式存在一定的差异。如何使用同一套代码，来处理这些数据方面的差异，提高脚本的复用性呢?我们采用了基于数据驱动的测试方式。

1.如何理解数据驱动

如果测试数据和代码结合在一起，每一次修改数据，两者都要同时变化，这种测试的方式不适合酒店业务数据的处理。数据驱动的方式将测式数据参数化，通过给测试脚本类的构造函数传递参数，从而达到数据的改变驱动自动化测试的执行，最终使得测试结果的改变。

通过这种方式，可以使测试数据和测试代码相分离，各自维护，只需要较少的代码产生的大量测试用例，提高脚本的复用率和可维护性。

2.技术实现

结合上文我们可以明确，在数据驱动的自动化测试框架中，一是必须要有与电子表格、文本文件、数据库等集成的能力;二是必须有数据来控制测试的业务流。整套框架我们采用的是 Maven + TestNG + Java +POI 来实现。

-- Maven 是一个通过配置文件来管理项目的构建工具，应用在自动化测试中时，无论是对 Jar 包的管理还是执行测试案例，表现都很出色。

-- TestNG 是一套可以利用注释来控制测试流程，从而达到强化测试功能的测试框架。它加入了单元测试、注解、组概念、套件、异常、参数化、依赖等测试思想，使其可以很好地支持和管理自动化测试任务。

-- Apache POI 是一种流行的 API , 它允许 程序员 创建、修改和显示 MS Office 文件。它是由 Apache 软件基金会开发和发布的一个开源库，用于使用 Java 程序设计或修改 MS-Office 文件。 它包含将用户输入数据或文件到 MS Office 文档进行解码的类和方法(详见官网：http://poi.apache.org/)。

通过使用 Apache POI 来解析 Excel 文档，结合 Java 语言对文档内容进一步处理，可以达到自动化的测试效果。

具体到一个测试用例的执行过程为：

图3：测试用例执行过程

自动化测试框架大致结构图：

图4：自动化测试框架结构图

各模块功能：

• DataProvider：通过构造函数向测试脚本传递测试数据，从而达到数据驱动的目的;
• TestScript：封装测试脚本;
• commonFunction 将一些常用的方法抽离出来放到该模块中;
• Data：将一些共享的常用的数据抽离出来放到该模块;
• Report：测试结果模块;
• 执行入口： xml 文件，可以用来配置测试的范围。

整个框架的工作流程大致可以描述为：

1. Testng.xml 作为测试入口;
2. DataProvider 通过测试数据驱动测试脚本的执行;
3. 测试脚本中通过 POI 读取测试数据，Java 分析测试数据，然后输出Report(在 Testscipt 中需要用到 Data 模块和 CommonFunc 模块。)

3.框架优化

一个好的测试框架的目标是能够减少代码量，大大提高测试脚本开发的效率。但它不是一蹴而就的，而是随着项目的不断的深入进行持续地改进。从上线投入使用开始，我们的框架也在不断优化，主要和大家分享以下几点经验：

1)Data 模块。在测试过程中发现一些测试数据会经常被使用到，而且经常需要改变，每次改动需要改动好多文件。我们对就对这部分数据进行了收取，放到 Data 模块中。

2)commonFunction 模块。在对 Excel 读写时，通过对不同的单元格数据类型的判断，进行不同的处理，来使单元格操作的健壮性增强。

3)对于 Excel 文件的读写需要多个循环，为了提高性能，应该事先对数据进行预处理，避免多个循环的嵌套。

近期规划及演进方向

现在测试数据的数据源是通过 Excel 文件来获取的，需要人为手工的进行数据的整合，对于持续化集成是一个阻碍。通过给接口传参来获取数据的方式，是一个比较理想的构想。通过接口获取数据的方式，可以通过 Jenkins 实现持续集成，测试人员可以给财务人员提供可视化的参数输入入口，实现财务人员触发测试脚本进行测试。这样做可以释放测试资源，提高回归频率，减少财务风险。

本文作者：高攀，马蜂窝酒店研发团队高级测试工程师。主要负责酒店自动化体系的搭建和优化，以及财务订单业务线整体测试工作。

【本文是51CTO专栏作者马蜂窝技术的原创文章，作者微信公众号马蜂窝技术(ID：mfwtech)】

戳这里，看该作者更多好文