自动化测试平台(十三)：接口自动化框架与平台对比及应用场景分析及设计思路分享

一、前言

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

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

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

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

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

---

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

项目在线演示