为什么要开发自己的测试框架？

之前，我们说到了用Postman 来完成接口测试，但随着你的接口测试项目逐渐增加，你会发现越来越难以管理它的脚本，虽然测试工具导出的测试脚本也可以存放到代码仓库，但   是，如果只是通过代码来查看是很难看懂的，你必须用原来的测试工具打开，才能更容易看懂原来的脚本做了什么样的操作。

搭建测试框架，不要纠结于技术选型

在做接口测试脚本开发的技术选型上，我更建议你根据自己的技术实力和技术功底来选择，而不要以开发工程师的技术栈来选择。

搭建前的准备工作

我相信现在你已经准备好，和我一起完成今天的内容了，但在开工之前，我要先把一些基础知识简单介绍给你。我们今天会用到 Python 的一个第三方 HTTP 协议支持库 requests，它可以让我们在和HTTP 协议打交道时更轻松；requests 项目的描述是“HTTP for Humans”，由此可见， 这会是一个人见人爱的 HTTP 协议库。你可以通过下面这个命令，完成 requests 的安装：

pip install requests

# Python代码中引入requests库，引入后才可以在你的代码中使用对应的类以及成员函数import requests# 建立url_index的变量，存储战场的首页url_index='http://127.0.0.1:12356/'# 调用requests类的get方法，也就是HTTP的GET请求方式，访问了url_index存储的首页URL，返回结果response_index = requests.get(url_index)# 存储返回的response_index对象的text属性存储了访问主页的response信息，通过下面打印出来print('Response内容：' + response_index.text)

第一个接口的单接口测试脚本如下，我在代码中做了详细的注释，你既可以复制出去直接运行，也可以通过注释看懂代码的作用。这样，你就完成了一个无参数的、GET   访问的验证工作。

# 定义一个common的类，它的父类是objectimport requests
class Common(object):  # common的构造函数    def __init__(self, url_root):  # 被测系统的跟路由        self.url_root = url_root  # 封装你自己的get请求，uri是访问路由，params是get请求的参数，如果没有默认为空
    def get(self, uri, params=''):  # 拼凑访问地址        url = self.url_root + uri + params  # 通过get请求访问对应地址        res = requests.get(url)  # 返回request的Response结果，类型为requests的Response类型        return res  # 封装你自己的post方法，uri是访问路由，params是post请求需要传递的参数，如果没有参数这里为        def post(self, uri, params=''):  # 拼凑访问地址        url = self.url_root + uri        if len(params) > 0:            # 如果有参数，那么通过post方式访问对应的url，并将参数赋值给requests.post默认参数data            # 返回request的Response结果，类型为requests的Response类型            res = requests.post(url, data=params)        else:            # 如果无参数，访问方式如下            # 返回request的Response结果，类型为requests的Response类型            res = requests.post(url)            return res

通过改造 Common 类的构造函数，这个类已经变成一个通用类了，无论是哪一个项目的接口测试，都可以使用它来完成 HTTP 协议的接口验证了。我相信现在你已经掌握了测试框架的形成过程，就如下图所示，测试框架的形成是在撰写大量测试脚本的过程中不断抽象封装出来的，然后，再用这个不断完善的框架，改写原有的测试脚本。循环往复这个过程，你就会慢慢获得一个独一无二的、又完全适合你工作的接口测试框架。

其实到这里，我们上面说的只能算是一个调试代码，还不能算是一个测试框架。上面这些代码所有的返回值都打印到控制台后，为了完成接口测试，你需要时时刻刻看着控制台，这还不能算是自动化，只能说是一个辅助小工具。在这里，你应该让全部测试结果都存储到测试报告里面，同时通过一个测试驱动框架来完成各个模块的驱动，这也是为什么你在学习任何一种框架的时候，总会遇见类似  Java  的JUnit、Python 的 Unittest 的原因，因此，上面的 Common 类还需要和 Python 的unittest 一起使用，才算是一个完美的测试框架。至于你自己的 Common 类怎么和测试驱动框架相结合，这部分内容就留给你在未来的接口测试工作中，自己去学习并完成了。

总结

今天，我们一起学习了一个测试框架的诞生过程。测试框架就是在你测试脚本中不断抽象和封装得来的。今天我们课程的内容充斥着各种代码，如果你的代码基础稍微比较薄弱，并没有完全记住上面的内容，那么我希望你记住从测试脚本到测试框架的转化过程：

1. 不断撰写测试脚本，所有的抽象和封装都是站在已有的测试脚本基础之上的；

2. 多观察已经写好的测试脚本，找出其中的重叠部分，最后完成封装；

3. 以上两步是一个不断循环又循序渐进的过程，你要在你的工作中始终保持思考和警惕，发现重复马上进行框架封装。

最后我想和你强调的是，测试框架的封装和抽象过程并不是一蹴而就的，它是靠一点一点的积累得来的，因此，你要通过自己的实践，慢慢积累和完善你的测试框架，而不要妄想一次就能有一个完善的测试框架。我相信，当你通过写脚本完成整个项目的接口测试后，你一定会得到一个完美的测试框架。