1、接口测试原理
接口测试，实际上是针对于接口做测试的。
那么接口是什么？
软件开发，既要做前端，也要做后端，并且后端是整个业务的核心，用于处理业务请求，实现具体的功能；而前端只是提供一个页面给用户看结果以及提供页面给用户做输入。所以整个业务的处理逻辑都在后端。而后端逻辑相对很复杂，所以在开发的时候，会由架构师确定接口，然后再针对这个接口实现其具体的功能。
接口也可以认为是我们要做多少事情，因为在技术层面，如果要实现登录、注册、增、删、改、查等操作，就会先设计好一个模块，说明具体实现哪些功能点，这个功能点应该有哪些输入项，有哪些方法。
这个东西就是我们所谓的接口，在java里，接口里包含属性名和方法，所有的方法都是抽象方法，只有方法名，而没有这个方法的具体实现。也就是说：我知道这是一个登录功能，但是登录怎么实现，这完全是不知道的，需要开发人员具体去实现。那么作为我们的开发人员，他就会领到一个任务去实现这个接口。比如，实现登录接口，注册接口等。
我们可以认为，虽然他是在实现登录接口、注册接口。也就相当于我们根据这个接口去实现登录功能，注册功能。所以这个接口实际上也就是后台一个具体的功能。
那么什么又是接口测试？
实际上我们所说的接口测试就是开发人员把这个接口实现了，他需要去验证这个接口的实现是否正确。
但是这是一个后台的功能，这个开发也是一个后台开发，他去验证接口的时候，他不会想让前端人员介入，因为让前台人员介入的话会比较麻烦。那么他就需要一个工具来模拟前端界面。（前端其实就是提供一个窗口，既能让用户输入数据，并且还可以查看结果。）
2、接口测试的实现
实际上我们做接口测试，还是“输入—处理—输出”这样的模式。用户输入一串数据，然后让这个接口或者让这个后台功能来处理，然后检查输出结果跟期望是否一致。
这个其实也就是我们所说的黑盒测试。也是我们做测试的一个常规的思路。用户输入一串数据，然后让系统去处理，然后我们再去检查结果跟期望是否一致。功能测试是这么做的，接口测试实际上还是这么做。
但是相对功能测试而言，接口测试有一个比较明显的区别，就是输入不再是界面的，而是一个基于HTTP的请求；输出也不再是界面，而是基于HTTP的响应。所以需要通过请求和响应分别来输入我们的数据以及检查我们的结果。
3、接口测试用例
其实接口测试和的功能测试是非常相似的，功能测试怎么做，接口测试还是怎么做。
功能测试用例，最核心的三个部分就是：输入、操作步骤和预期结果。
接口测试用例，其实主要的也就是这么三个部分。
平时所说的测试用例设计方法，也就是对输入项进行各种不同的取值，然后再做组合。拿登录来说，登录功能有用户名和密码，那用户名，有正确的用户名和错误的用户名两种情况，密码有正确的密码和错误的密码两种情况。用户名和密码在一起就会产生一些组合：
（1）用户名正确，密码正确；
（2）用户名正确，密码错误；
（3）用户名错误，密码的正确；
（4）用户名错误；密码错误。
输入时，选择不同的数据组合会产生不同的测试场景，每一个场景都需要执行一遍。
功能测试是这么去做的，但是接口测试没有界面，也就没有办法输入，怎么办？
接口测试里有个东西叫参数，这个参数就对应了功能测试里的输入项。所以，接口测试用例其实也就是对输入参数，做一个划分然后再做组合，形成接口测试用例。
每一组测试用例执行后，肯定会得到不同的结果。比如正确的用户名和正确的密码，结果是登录成功；错误的用户名或错误的密码，结果是登录失败。那么只要思考，如何将参数取值和测试结果应用在工具中，这个问题就解决了。
4、接口测试工具
接口测试工具有很多，比如soapUI，postman，jmeter等。
工具其实只是工具而已。
做接口测试一定要明白的一个前提：接口测试的流程。
第一步，设计操作步骤。
操作步骤就是请求，有一些请求是是单独的，有些请求是多个请求前后有联系的，这种情况就需要创建关联，。那么我们需要了解请求的格式，规范以及如何做关联。soapUI，postman，jmeter里，都有关联。
第二步，设计数据用例。
建议将数据用例写到Excel文档里，然后让工具读取Excel。Excel里有几组数据用例，就执行几次。循环执行（自动化），就可以让每一个用例被执行一次，那么每一个测试场景也就被运行到了。
第三步：断言。
也就是提前将预期结果写入到工具中，让工具自动化判断结果是否正确。不同的工具叫法不同，soapUI和Jmeter中叫做断言，postman中叫做tests。
第四步：执行并检查测试结果。
执行很简单，对测试结果进行分析的话就需要了解协议。知道发出去了什么，返回了什么，才能够知道，到底哪个环节出了问题。
5、HTTP协议
HTTP协议非常重要。清楚了HTTP协议，再去使用工具其实就很容易，按照上面四个步骤就行。
为什么是HTTP协议而不是其他协议？因为90%的系统都是HTTP协议的。
HTTP协议包含请求和响应
请求就是用户的输入，响应就是结果。我们通过请求去找参数，然后输入不同的参数值，然后组合成请求，只要这个请求是合法的，那么就可以发出去，并且能够被服务器接收。所以，首先要能够判断出来什么叫做合法请求。
那么就需要去了解HTTP协议的请求的组成，请求的规范，知道哪些请求项是我们所关心的，哪些请求项是我们一定要遵循的，哪些项是我们可以删除的。
同理，要想检查结果是否正确，就需要去了解响应。
HTTP请求包含两个部分
请求头和请求体，请求头的第一行非常的重要，包含请求方法和URL。这两个东西是非常核心的东西。请求方法有GET方法，POST方法，需要知道他们之间的区别，当然区别最明显的就是GET请求没有请求体，而POST请求有请求体。URL，相当于接口的入口。请求头里有很多项，每一项最好能知道是什么意思，并且要知道哪些项是比较核心的，其实核心的东西不多。一个是content-type，一个是cookies。
备注：网上很多资料会把请求分为三部分，请求行、请求头和请求体。这里的请求头的第一行其实就是请求行了，下面的响应也是一样
请求体包括参数，一般我们在测试的时候会修改请求体里的东西。
懂了上面这些，就知道该如何组装HTTP请求了。
响应包含两个部分
一个是响应头，一个是响应体。响应头里的第一行有响应的状态码和状态信息，这个非常重要。面试时候一般会被问到：状态码有几类？一般是有五类，1开头（请求正在处理），2开头（请求处理成功），3开头（重定向），4开头（客户端错误），5开头（服务器错误），这五类分别代表什么需要记住。一般5开头的都是系统bug。
6、JMeter
其实哪个工具都可以，但是jmeter有两个好处，第一个：它是中文版的，学习成本较低，postman和soapUI都是英文版的；第二个，jmeter既可以做接口测试，又可以做性能测试。
对应上面的四个步骤，如何用jmeter做接口测试？
1、 设计操作步骤：这里我们创建HTTP请求即可
添加——取样器——HTTP请求
2、 设计数据用例：由于jmeter只支持CSV文件，所以设计测试用例时记得生成CSV格式的，将CSV导入到jmeter中（这部分在性能测试里面叫做jmeter的参数化）
添加——配置元件——CSV数据文件设置
3、 断言，添加一个响应断言即可（也可以加别的）
添加——断言——响应断言
4、 执行，添加一个结果树
添加——监听器——查看结果树
7、抓包
一般情况下，做接口测试是有接口文档的
但是如果没有接口文档我们怎么做接口测试？
这就需要抓包，请求我们是可以抓到的，响应如果抓不到，我们可以根据测试数据自己分析应该得到什么样的结果
抓包工具推荐fiddler，两个优势：
1、简单好用；
2、fiddler抓包后可以直接导出为jmeter脚本。
8、接口测试可以发现什么样的Bug？
为什么要做接口测试？
基于两个理由：
第一个：开发人员把这个接口或者把后台代码开发好了，他会去做接口测试。开发人员自测完成后，我们测试人员可以对这个接口做一个全面的测试。
第二个：接口测试不会受到输入界面的影响，那界面所做出的一些限制也就不存在了，我们直接测的就是后台这一块儿，可以检查后台有没有做到相应的限制。
一个常见的问题，页面的输入框可能会有长度限制，比如限制只能输入十个字符，但是后台并没有做限制，这样很容易会导致出现一些数据库的异常，这样的问题可能在功能测试里面没办法发现，但是接口测试可以。所以很多时候，接口测试，可以认为是功能测试的一种补充。它可以让我们的测试做得更深入，更全面。深入浅出接口测试原理及步骤
1、接口测试原理
接口测试，实际上是针对于接口做测试的。
那么接口是什么？
软件开发，既要做前端，也要做后端，并且后端是整个业务的核心，用于处理业务请求，实现具体的功能；而前端只是提供一个页面给用户看结果以及提供页面给用户做输入。所以整个业务的处理逻辑都在后端。而后端逻辑相对很复杂，所以在开发的时候，会由架构师确定接口，然后再针对这个接口实现其具体的功能。
接口也可以认为是我们要做多少事情，因为在技术层面，如果要实现登录、注册、增、删、改、查等操作，就会先设计好一个模块，说明具体实现哪些功能点，这个功能点应该有哪些输入项，有哪些方法。
这个东西就是我们所谓的接口，在java里，接口里包含属性名和方法，所有的方法都是抽象方法，只有方法名，而没有这个方法的具体实现。也就是说：我知道这是一个登录功能，但是登录怎么实现，这完全是不知道的，需要开发人员具体去实现。那么作为我们的开发人员，他就会领到一个任务去实现这个接口。比如，实现登录接口，注册接口等。
我们可以认为，虽然他是在实现登录接口、注册接口。也就相当于我们根据这个接口去实现登录功能，注册功能。所以这个接口实际上也就是后台一个具体的功能。
那么什么又是接口测试？
实际上我们所说的接口测试就是开发人员把这个接口实现了，他需要去验证这个接口的实现是否正确。
但是这是一个后台的功能，这个开发也是一个后台开发，他去验证接口的时候，他不会想让前端人员介入，因为让前台人员介入的话会比较麻烦。那么他就需要一个工具来模拟前端界面。（前端其实就是提供一个窗口，既能让用户输入数据，并且还可以查看结果。）
2、接口测试的实现
实际上我们做接口测试，还是“输入—处理—输出”这样的模式。用户输入一串数据，然后让这个接口或者让这个后台功能来处理，然后检查输出结果跟期望是否一致。
这个其实也就是我们所说的黑盒测试。也是我们做测试的一个常规的思路。用户输入一串数据，然后让系统去处理，然后我们再去检查结果跟期望是否一致。功能测试是这么做的，接口测试实际上还是这么做。
但是相对功能测试而言，接口测试有一个比较明显的区别，就是输入不再是界面的，而是一个基于HTTP的请求；输出也不再是界面，而是基于HTTP的响应。所以需要通过请求和响应分别来输入我们的数据以及检查我们的结果。
3、接口测试用例
其实接口测试和的功能测试是非常相似的，功能测试怎么做，接口测试还是怎么做。
功能测试用例，最核心的三个部分就是：输入、操作步骤和预期结果。
接口测试用例，其实主要的也就是这么三个部分。
平时所说的测试用例设计方法，也就是对输入项进行各种不同的取值，然后再做组合。拿登录来说，登录功能有用户名和密码，那用户名，有正确的用户名和错误的用户名两种情况，密码有正确的密码和错误的密码两种情况。用户名和密码在一起就会产生一些组合：
（1）用户名正确，密码正确；
（2）用户名正确，密码错误；
（3）用户名错误，密码的正确；
（4）用户名错误；密码错误。
输入时，选择不同的数据组合会产生不同的测试场景，每一个场景都需要执行一遍。
功能测试是这么去做的，但是接口测试没有界面，也就没有办法输入，怎么办？
接口测试里有个东西叫参数，这个参数就对应了功能测试里的输入项。所以，接口测试用例其实也就是对输入参数，做一个划分然后再做组合，形成接口测试用例。
每一组测试用例执行后，肯定会得到不同的结果。比如正确的用户名和正确的密码，结果是登录成功；错误的用户名或错误的密码，结果是登录失败。那么只要思考，如何将参数取值和测试结果应用在工具中，这个问题就解决了。
4、接口测试工具
接口测试工具有很多，比如soapUI，postman，jmeter等。
工具其实只是工具而已。
做接口测试一定要明白的一个前提：接口测试的流程。
第一步，设计操作步骤。
操作步骤就是请求，有一些请求是是单独的，有些请求是多个请求前后有联系的，这种情况就需要创建关联，。那么我们需要了解请求的格式，规范以及如何做关联。soapUI，postman，jmeter里，都有关联。
第二步，设计数据用例。
建议将数据用例写到Excel文档里，然后让工具读取Excel。Excel里有几组数据用例，就执行几次。循环执行（自动化），就可以让每一个用例被执行一次，那么每一个测试场景也就被运行到了。
第三步：断言。
也就是提前将预期结果写入到工具中，让工具自动化判断结果是否正确。不同的工具叫法不同，soapUI和Jmeter中叫做断言，postman中叫做tests。
第四步：执行并检查测试结果。
执行很简单，对测试结果进行分析的话就需要了解协议。知道发出去了什么，返回了什么，才能够知道，到底哪个环节出了问题。
5、HTTP协议
HTTP协议非常重要。清楚了HTTP协议，再去使用工具其实就很容易，按照上面四个步骤就行。
为什么是HTTP协议而不是其他协议？因为90%的系统都是HTTP协议的。
HTTP协议包含请求和响应
请求就是用户的输入，响应就是结果。我们通过请求去找参数，然后输入不同的参数值，然后组合成请求，只要这个请求是合法的，那么就可以发出去，并且能够被服务器接收。所以，首先要能够判断出来什么叫做合法请求。
那么就需要去了解HTTP协议的请求的组成，请求的规范，知道哪些请求项是我们所关心的，哪些请求项是我们一定要遵循的，哪些项是我们可以删除的。
同理，要想检查结果是否正确，就需要去了解响应。
HTTP请求包含两个部分
请求头和请求体，请求头的第一行非常的重要，包含请求方法和URL。这两个东西是非常核心的东西。请求方法有GET方法，POST方法，需要知道他们之间的区别，当然区别最明显的就是GET请求没有请求体，而POST请求有请求体。URL，相当于接口的入口。请求头里有很多项，每一项最好能知道是什么意思，并且要知道哪些项是比较核心的，其实核心的东西不多。一个是content-type，一个是cookies。
备注：网上很多资料会把请求分为三部分，请求行、请求头和请求体。这里的请求头的第一行其实就是请求行了，下面的响应也是一样
请求体包括参数，一般我们在测试的时候会修改请求体里的东西。
懂了上面这些，就知道该如何组装HTTP请求了。
响应包含两个部分
一个是响应头，一个是响应体。响应头里的第一行有响应的状态码和状态信息，这个非常重要。面试时候一般会被问到：状态码有几类？一般是有五类，1开头（请求正在处理），2开头（请求处理成功），3开头（重定向），4开头（客户端错误），5开头（服务器错误），这五类分别代表什么需要记住。一般5开头的都是系统bug。
6、JMeter
其实哪个工具都可以，但是jmeter有两个好处，第一个：它是中文版的，学习成本较低，postman和soapUI都是英文版的；第二个，jmeter既可以做接口测试，又可以做性能测试。
对应上面的四个步骤，如何用jmeter做接口测试？
1、 设计操作步骤：这里我们创建HTTP请求即可
添加——取样器——HTTP请求
2、 设计数据用例：由于jmeter只支持CSV文件，所以设计测试用例时记得生成CSV格式的，将CSV导入到jmeter中（这部分在性能测试里面叫做jmeter的参数化）
添加——配置元件——CSV数据文件设置
3、 断言，添加一个响应断言即可（也可以加别的）
添加——断言——响应断言
4、 执行，添加一个结果树
添加——监听器——查看结果树
7、抓包
一般情况下，做接口测试是有接口文档的
但是如果没有接口文档我们怎么做接口测试？
这就需要抓包，请求我们是可以抓到的，响应如果抓不到，我们可以根据测试数据自己分析应该得到什么样的结果
抓包工具推荐fiddler，两个优势：
1、简单好用；
2、fiddler抓包后可以直接导出为jmeter脚本。
8、接口测试可以发现什么样的Bug？
为什么要做接口测试？
基于两个理由：
第一个：开发人员把这个接口或者把后台代码开发好了，他会去做接口测试。开发人员自测完成后，我们测试人员可以对这个接口做一个全面的测试。
第二个：接口测试不会受到输入界面的影响，那界面所做出的一些限制也就不存在了，我们直接测的就是后台这一块儿，可以检查后台有没有做到相应的限制。
一个常见的问题，页面的输入框可能会有长度限制，比如限制只能输入十个字符，但是后台并没有做限制，这样很容易会导致出现一些数据库的异常，这样的问题可能在功能测试里面没办法发现，但是接口测试可以。所以很多时候，接口测试，可以认为是功能测试的一种补充。它可以让我们的测试做得更深入，更全面。