一、前言
对于传统的实现接口自动化的方案往往是搭建自动化框架，通过excel编写用例来驱动执行，例如常见的万金油技术栈组合：openpyxl、pytest、allure等。
很多公司往往是通过自动化框架而非测试平台来实现接口自动化，主要是自动化框架相对于测试平台的建设成本会低很多。 但对于自动化用例的维护、及编写用例的上手难度来讲同样会更难不少。建设架构的成本和用例维护成本是一个成反比的关系，所以我们需要根据实际情况来选择是建设自动化框架还是测试平台。当业务处于迭代快，项目多、场景复杂的情况下，用例成本维护的低效会让自动化变得越来越困难和复杂，这时选择建设测试平台是更优于自动化框架的。反之，则更应该选择自动化框架。
为何会说自动化框架难维护呢？举一个简单的问题：当接口参数发生变更时，如何找出其影响的测试用例？
这个问题对于传统的自动化框架测试方案来讲绝对是棘手的，我经手过最大的单项目有2000多个接口，基于此建立的用例有10000条+，如果通过excel驱动接口自动化测试的方式很难有合适高效的方案来解决这个问题。如果通过平台来做，由于有数据库的概念，维护了接口id与用例之前的关系，只需要查询用例中关联了该变更接口的数据就可以直接找出影响范围了。
这只是一个小例子，实际还有很多地方阻碍传统接口自动化测试的开展。所以很多体量较大的公司会建设自动化测试平台，来提高自动化开展的效率 ，提高用例的可维护性等。
该专栏完整教程地址：《从0搭建自动化测试平台》
项目在线演示
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/219788.html原文链接：https://javaforall.net
