接口测试——自动化框架的设计与实现

一、自动化测试框架

在大部分测试人员眼中只要沾上“框架”，就感觉非常神秘，非常遥远。大家之所以觉得复杂，是因为落地运用起来很复杂；每个公司，每个业务及产品线的业务流程都不一样，所以就导致了“自动化测试框架”去完成自动化测试的时候产生很多不稳定因素，这样就很难定位成一个固定的框架。其实不然，真正的自动化测试框架不是一个模式，而是一种思想和方法的集合，通俗的讲就是一个架构。

二、自动化测试框架思想

为了更好的了解自动化测试框架，我们先从自动化测试的发展历程说起；一般测试工作限在3年以上且接触过自动化测试的应该对以下几种自动化测试框架思想有一定的认知：

• 模块化思想
• 库思想
• 数据驱动思想
• 关键字驱动思想

以上仅仅是代表了一种自动化测试的思想，并不能定义为框架。上面讲到框架=思想+方法，于是演化了以下五种框架：

1、模块化测试脚本框架

需要创建小而独立的可以描述的模块、片断以及待测应用程序的脚本。这些树状结构的小脚本组合起来，就能组成能用于特定的测试用例的脚本。

2、测试库框架

与模块化测试脚本框架很类似，并且具有同样的优点。不同的是测试库框架把待测应用程序分解为过程和函数而不是脚本。这个框架需要创建描述模块、片断以及待测应用程序的功能库文件。

3、关键字驱动或表驱动的测试框架

这个框架需要开发数据表和关键字。这些数据表和关键字独立于执行它们的测试自动化工具，并可以用来“驱动＂待测应用程序和数据的测试脚本代码，关键宇驱动测试看上去与手工测试用例很类似。在一个关键字驱动测试中，把待测应用程序的功能和每个测试的执行步骤一起写到一个表中。

这个测试框架可以通过很少的代码来产生大量的测试用例。同样的代码在用数据表来产生各个测试用例的同时被复用。

4、数据驱动测试框架

在这里测试的输入和输出数据是从数据文件中读取（数据池，ODBC源，CSV文件，EXCEL文件，Json文件，Yaml文件，ADO对象等）并且通过捕获工具生成或者手工生成的代码脚本被载入到变量中。在这个框架中，变量不仅被用来存放输入值还被用来存放输出的验证值。整个程序中，测试脚本来读取数值文件，记载测试状态和信息。这类似于表驱动测试，在表驱动测 试中，它的测试用例是包含在数据文件而不是在脚本中，对于数据而言，脚本仅仅是一个“驱动器”，或者是一个传送机构。然而，数据驱动测试不同于表驱动测试，尽管导航数据并不包含在表结构中。在数据驱动测试中，数据文件中只包含测试数据。

5、混合测试自动化框架

最普遍的执行框架是上面介绍的所有技术的一个结合，取其长处，弥补其不足。这个混合测试框架是由大部分框架随着时间并经过若干项目演化而来的。

三、接口自动化测试框架策略

1. 设计出来的框架是直接给测试人员，而且其他的测试人员只需要简单的向里面不断的补充测试用例即可；所以我们的框架设计必须三简化即操作简单，维护简单，扩展简单。
2. 设计框架的同时一定要结合业务流程，而且不仅仅靠技术实现，其实技术实现不难，难点对业务流程的理解和把握。
3. 设计框架时要将基础的封装成公用的，如：get请求、post请求和断言封装成同基础通用类。
4. 测试用例要与代码分享，这样便于用例管理，所以将我们选择上面的数据驱动思想。

四、接口自动化测试框架设计

1、进行接口框架设计前，我们先看看当前的一些主流接口自动化工具框架