04 | 案例：如何把流程化的测试脚本抽象为测试框架？

接口测试框架的形成过程 流水账式的接口测试脚本 在编写不少流水账式的接口测试脚本后，发现其中存在大量重复的代码 思考：能不能把公共的操作单独抽离出来，抽象到一个common文件中，在其他文件继承或导入文件进行使用 如何区分哪些是公共的部分？ 一般哪些是公共部分？ 公共部分与非公共部分的边界是什么？ 提供common文件的通用性 如不写死测试系统，通过传入参数指定测试系统 加入测试报告 加入测试报告模块，把测试结果储存在测试报告当中，而是都使用print打印 加入测试驱动框架 加入unittest或pytest测试驱动框架来驱动各个模块，更好地组织测试脚本 加入日志 为了更好地定位和分析问题，加入日志模块 加入断言 针对复杂断言，引入jsonpath断言、Xml断言、Xpath断言、hamcrest断⾔、Json schema校验 引入POM 为了更好地区分业务操作，方便脚本维护，引入POM 引入参数化 为了应对大数据量测试，引入参数化 ...... 不要把测试框架看得太高大上了，不是只有像selenium、appium、httprunner才叫测试框架，你可以从一个简单地测试框架开始做起。 测试框架是在编写大量测试脚本地过程中不断抽象封装出来地，然后不断完善，是一个循环往复地过程。

有个观点与老师不同，就是在编程语言的选择上，针对新手而言，选择与研发团队相同的编程语言（java,python,js,go）个人觉得会更好一些，一方面有研发团队作为依靠，另一方面在接入ci时，可以复用研发团队的ci接入技术栈。再有就是能复用面向测试的底层开源库就先复用它们，把更多的精力放在测试领域功能封装上，如：入参的处理，出参的传递，接口请求结果的抽取等方面。 如果对编程语言还是一知半解，老师本讲所讲的内容就要多去理解、实践了，它是很好的入门窗口。

看完这篇文章，可以更清晰的感觉到这个专栏的受众应该是初级测试人员，不太适合开发人员。 在部落中也零星看到一些关于这个专栏的讨论和批评，我觉得可能是因为大家对专栏的期望太高了，结果在这里没有看到化腐朽为神奇的东西。 一步一步来吧，总归是开卷有益，拓展思路，查漏补缺也挺好的。

推荐一本书，martin flower 的重构。

上了这个课程以后才知道自己会的接口测试知识太太少了，要学的太多了，自己的基础太薄弱了

单一接口测试代码可以用postman直接生成

老师，看你的脚步，写公共方法的那一段是否需要加上import requests呢？不然后面调用requests包时，会有问题吧，刚学Python代码，所以问题比较初级

我真的没看出common接收变量后，代码量有什么节省。就是不用动框架了，每次传参就可以了。

有一个Python业界很获得接口测试框架，HTTPrunner，老师你怎么看这个框架。

有下面这样的错误： print('Response内容：' + response_login.text) AttributeError: 'NoneType' object has no attribute 'text'