接口测试是面试测试岗位基本都会问到的问题，但是对于一些刚做测试的小伙伴可能并不是很熟悉，也有可能了解接口测试，但是完全不知道接口自动化怎么做。下面我们大概介绍一下。
首先我们需要知道接口自动化测试的目的是为了节约手工测试接口的时间或者减少不必要的重复工作，或者为了监控线上接口是否运行正常等情况的发生。
在我们日常的接口测试工作中大多数小伙伴可能都是用一个接口工具：fiddler、postman、jmeter、soapui等等来进行一个简单的接口测试。
当然，工具的选择这个看大家的喜好，但是我们都会发现一个特点，这些工具如果仅仅是工具的使用我们都不能够根据自己的业务等特殊情况进行修改，具有一定的局限性，并且一些只能一次测试一个。
最最最关键的是这个无法体现我们的逼格，是不是有种感觉就是没办法体现我们自己的价值，如果面试使用这些好像无法要出高工资。
那下面我们就从这简单的第一步开始，让我们从简单地提高自己开始。
如果使用一门语言来做接口测试，我会毫不犹豫地选择python，他的高效不是一般的。我们先看下面使用python测试慕课网登录的一个简单例子：
看到上面的代码有点像样子了，如果在实际项目中我们要测试一个登陆接口那么我们只需要将上面的代码拿过来，然后将我们的url更换一下，然后将用户名和密码信息换一下就ok，但是我们会发现一个问题，这个代码看着没有复用性，而且实际存在的价值并不是很高，所以我们可以将上面的代码进行一个简单的封装，把封装成一个函数，我们需要传入url、data就可以了，然后我们每次需要测试接口时调用这个函数就能够完成我们的测试，结果如下：
这样看起来是不是觉得顺手一点点了呢？此时我们的代码确实没什么问题了，但是看着好像少了点东西，不知道你是否觉得？因为在我们常见的接口中不止是有post类型的接口，我们还有get类型的接口，那么我们是不是要根据不同类型的接口做不同的封装呢？那我们做get的接口是如何进行测试的呢？看下面代码：
看见上面的代码和之前我们写的代码是不是发现了一些区别，其实在python中使用requests库进行接口时我们唯一的区别就是实用post、get两个函数，他们就分别对应了测试post类型和get类型的接口，同样的我们将get接口的函数进行一个简单的封装，那么就成了下面的样子：
通过上面的代码和之前封装的代码我们是不是就简单的把我们常见的post和get两个类型的接口进行了一个封装，我们如果下次需要测试接口只需要去调用这个就可以了呢？但是我们发现一个问题如果我们需要调用，每次还需要知道我们接口类型，然后来调用不同的方法，这样是不是有点麻烦呢？那我们应该怎么去简化整个过程呢？我们是不是可以将我们这俩函数封装在一起然后有一个主要的入口，然后其他的地方来进行调用？答案肯定是可以的，我们只需要封装一个主函数就行，这个函数主要功能是做什么呢？他主要是用来辨别你接口是什么类型的，然后去调用不同类型的接口。那就变成了下面这样：
看到这里是不是有那么点明白的感觉？其实我们只需要将我们的两个函数封装起来就ok了，但是其实看到这里我们觉得还是少点什么？能不能把整个封装成一个类呢？答案肯定是可以的，看下面：
这个整段代码是不是就变成了我们刚开始测试很low的那代码的封装呢？对的，但是有没有思考过一个问题，这样看起来虽然有点样子了，但是是不是还缺少点什么呢？我们能不能够按照一条case一条case那样执行呢？好比我登陆时传入不同的用户信息，然后返回不同结果，有不同的断言呢？肯定可以，我们这里简单引入一个unittest的框架，具体看下面：
这里我们能够看到一个简单的unittest的简单架子，首先我们是引入了一个unittest包，然后创建类的时候继承了这个unittest.TestCase这个方法，在下面我们只需要编写我们的case就可以了，在程序的执行入口，我们将两个case添加到一个组件中，然后去运行这个组件就ok了。虽然架子有了，我们要怎么把我们的requests的基础模版和我们的unittest结合起来呢？其实我们只需要在我们的unittest类开始将我们的RunMethod类引入然后使用就好，然后结果变成了下面这个样子：
看到这里好像有那么点意思了，但是美中不足的是好像我们还没有测试报告那我们需要如何去生成一个测试报告呢？这里我们就需要运用我另外一个东西HTMLTestRunner.py，这个文件可以在网上下载，我们这里可以直接使用，同样的我们只需要将HTMLTestRunner这个引入就好，接着上面的代码我们往下看：
上面看着没什么变化，这里我们只是将unittest创建的测试组件放在了HTMLTestRunner中去运行，这样运行后就有我们的结果了
思考：这就真的达到了我们接口的自动化了么？
