一、前言

对于传统的实现接口自动化的方案往往是搭建自动化框架，通过excel编写用例来驱动执行，例如常见的万金油技术栈组合：openpyxl、pytest、allure等。

很多公司往往是通过自动化框架而非测试平台来实现接口自动化，主要是自动化框架相对于测试平台的建设成本会低很多。 但对于自动化用例的维护、及编写用例的上手难度来讲同样会更难不少。建设架构的成本和用例维护成本是一个成反比的关系，所以我们需要根据实际情况来选择是建设自动化框架还是测试平台。当业务处于迭代快，项目多、场景复杂的情况下，用例成本维护的低效会让自动化变得越来越困难和复杂，这时选择建设测试平台是更优于自动化框架的。反之，则更应该选择自动化框架。

为何会说自动化框架难维护呢？举一个简单的问题：当接口参数发生变更时，如何找出其影响的测试用例？

这个问题对于传统的自动化框架测试方案来讲绝对是棘手的，我经手过最大的单项目有2000多个接口，基于此建立的用例有10000条+，如果通过excel驱动接口自动化测试的方式很难有合适高效的方案来解决这个问题。如果通过平台来做，由于有数据库的概念，维护了接口id与用例之前的关系，只需要查询用例中关联了该变更接口的数据就可以直接找出影响范围了。

这只是一个小例子，实际还有很多地方阻碍传统接口自动化测试的开展。所以很多体量较大的公司会建设自动化测试平台，来提高自动化开展的效率 ，提高用例的可维护性等。

该专栏完整教程地址：《从0搭建自动化测试平台》

项目在线演示地址：http://121.43.43.59/ （帐号：admin 密码：123456）

二、痛点分析

对于传统搭建接口自动化框架方案的痛点一张图可概括：

这也是为什么大厂都要建设自动化测试平台的原因了。但也不是谁都需要建设平台，如果你们公司属于迭代慢、项目少的情况，那传统的自动化方案才是最适合的。毕竟相对来说，平台的建设需要的人力、时间成本是巨大的。

三、接口自动化测试平台设计思路分析

为了解决上述列举的痛点，我们在建设测试平台时需要着重的考虑如何设计才能更优的解决并适配实际业务需求和测试场景，下面是我的一些思路和见解，这里分享给大家：

1. 抛弃单独维护接口的功能

往往，不少接口自动化平台的进行接口自动化建设时，第一步是需要在接口库中按照项目-模块-接口的层级维护接口数据，然后才是在编写自动化流程（测试用例/计划）时使用这些接口。但这一步在我看来完全是没必要的。

所以我直接抛弃了该步骤，直接进行测试计划的编写，用户在编写测试计划的过程中定会填写使用到的接口参数和测试数据等，这个时候我只需要在保存数据时将填写的接口参数和测试数据写入到对应的接口库中即可（下图是编写接口用例的页面）：

2. 通过引用用例的方式代替前后置用例

在自动化测试中经常存在前置或后置的重复操作（即需要在测试正式开始前先执行的操作）例如：

1. 在执行前进行登录
2. 准备测试数据
3. 清除测试过程中产生的数据

上述的操作我们能够很容易定义为前置还是后置用例，但在我们实际编写用例的过程中会发现，有很多能够作为前后置的用例我们写成了普通用例，或者某些用例依赖多个普通用例而非特定情况下的前置用例等情况。但我们编写的用例耦合性太强了，很难再拆分出前后置用例。所以实际情况往往需要更加灵活，用例之间的关系并非只有前后置两种，应该能够随意引用才行。所以我选择用引用的方式来代表前后置，用例之间可以随意引用，也可以引用多个等。以此来降低耦合性，增加可维护性。

3. 变量全局化及值记忆

在我们编写自动化用例的过程中，有动态参数变量的情况会让调试用例变得复杂，很多时候一个尾部用例需要前面的数据生成了数据，该用例才能跑下去，这样我们在调试尾部用例时就都需要跑一次前面的用例。这个过程是枯燥且繁琐的。

因此，在每次执行/调试用例的过程中，我都会将产生变量及变量来源(按照“计划-模块-步骤”的组合展示)加入到全局参数中，用户进行下一次请求或实时调试时，都能够直接使用这些变量，不需要重新执行依赖的用例：

这样设计最大的一个好处就是在调试时，也能直接使用变量，减少了我们很多操作，提高了不少效率：

4. 接入Swagger，及时发现变更

如果你们的Swagger比较规范，可以直接通过解析Swagger的方式，来将其导入到接口库中，这样完全不用用户来维护接口的参数及模块信息等数据了：

在执行或Jenkins构建后请求测试平台开放的Swagger比对接口，当接口出现变更的也可以直接对比出接口差异，这样结合接口和计划步骤的关联设计能够非常快速的找出影响的用例，以此减少维护成本。

5. 任务中心（定时、组合）

测试平台的定时执行是尤为重要的，所以也需要设计能够配置定时执行任务的功能：

另外，一个完备的测试平台不会只有接口自动化这一种功能，还会有性能、UI自动化等。所以任务中心还需要提供的功能则是不同类型的自动化之前的组合：

6. 控制器（重试、条件判断等）

1）重试

在实际业务中，接口本身的不稳定 （非100%成功的接口） 或一些异步接口 （响应结果为成功，但数据并未真正的导入进去，需要等几秒才会进数据） 的使用会导致自动化测试的不稳定性，很多小伙伴处理这类场景的时候，是使用强制等待来做的，在这类步骤之间增加一个sleep多少秒的操作。其实有更好的方案来代替它，在我平台的设计中，使用重试的方式来做：

用户可以配置步骤的重试次数，当出现与设立的期望不匹配或接口异常的情况后，系统会根据设置的重试次数进行重试，如果重试成功则继续执行，若超过设置的重试次数还未成功，则抛出失败。这样不仅能减少等待的时间也更能增加稳定性：

2）条件控制

有些时候，步骤能否执行依赖之前的数据是否成功，或自定义的变量状态。这时我们也可以在控制器中增加条件控制来满足这个需求。

当我们配置了控制后，对应步骤会增加一个标签，来区分那些没有配置控制器的步骤:

7. 断点（实时）调试

通过传统方案建设自动化有一个好处，就是能够Debug，打断点进行跟踪调试，更快捷精确的发现出问题的地方。

其实平台也能够做断点调试，实现方案也不难

传统方案的断点是代码层级的，一行行代码间的断点，而平台可以做步骤级的断点，每个步骤的断点，至于实时性，完全可以通过前端与后端建立webSocket就能够轻松搞定。所以也不是啥解决不了的问题。

8. 请求域名/变量/SQL等区分环境

很多情况下，自动化的应用不是在单一的一个环境中。我们的自动化就需要在四个环境中使用：测试、预发、性能、线上环境。
如果因为切换环境，就需要我们更改测试、用例数据这效率是非常低的。所以我们可以将这部分数据做环境区分，当执行环境不同时，自动选择不同的数据进行执行：

预先配置好各环境的基础数据：

在使用时，按项目维度选择：

这样在执行时，就能够达到我们想要的效果，不需要手动更改数据了：

9. 支持自定义函数

在我们开展自动化的过程中会发现存在不少特殊的情况无法范式化或着通用的解决，比如在参数解析和期望判断上，需要自定义的情况非常多。这个时候就需要函数来支撑，平台应该能够提供编写函数及选择使用函数的功能：

10. 支持SQL

原则上讲接口自动化不应该操作SQL，但实际情况却经常需要使用SQL才能继续进行自动化，所以平台对SQL的支撑也是必不可少的，我们的SQL连接信息也可以按环境来划分。在编写SQL时应该提供更直观方便的调试：

三、总结

这一章节基于自身理解为大家介绍了自动化测试平台和传统自动化框架的应用区别和适用场景等，另外分享了一些个人觉得高效的自动化测试平台应该具备的特点和功能。

后面的章节会对这些功能点进行分析并给出具体的实现方案（用哪些技术，组件，框架等）和思路，欢迎关注！