既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
对于传统的实现接口自动化的方案往往是搭建自动化框架，通过excel编写用例来驱动执行，例如常见的万金油技术栈组合：openpyxl、pytest、allure等。
很多公司往往是通过自动化框架而非测试平台来实现接口自动化，主要是自动化框架相对于测试平台的建设成本会低很多。 但对于自动化用例的维护、及编写用例的上手难度来讲同样会更难不少。建设架构的成本和用例维护成本是一个成反比的关系，所以我们需要根据实际情况来选择是建设自动化框架还是测试平台。当业务处于迭代快，项目多、场景复杂的情况下，用例成本维护的低效会让自动化变得越来越困难和复杂，这时选择建设测试平台是更优于自动化框架的。反之，则更应该选择自动化框架。
为何会说自动化框架难维护呢？举一个简单的问题：当接口参数发生变更时，如何找出其影响的测试用例？
这个问题对于传统的自动化框架测试方案来讲绝对是棘手的，我经手过最大的单项目有2000多个接口，基于此建立的用例有10000条+，如果通过excel驱动接口自动化测试的方式很难有合适高效的方案来解决这个问题。如果通过平台来做，由于有数据库的概念，维护了接口id与用例之前的关系，只需要查询用例中关联了该变更接口的数据就可以直接找出影响范围了。
这只是一个小例子，实际还有很多地方阻碍传统接口自动化测试的开展。所以很多体量较大的公司会建设自动化测试平台，来提高自动化开展的效率 ，提高用例的可维护性等。
该专栏完整教程地址：《从0搭建自动化测试平台》
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！
由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新
et/forums/4f45ff00ff254613a03fab5e56a57acb)**
1049
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
