接口测试作什么

1、

对于接口测试来讲，项目测试用例的重复运行首先是表如今单个测试用例的独立性方面的，也就是说，每个测试用例的运行除了依赖被测对象和对应的数据库环境外，是不依赖于其余任何测试用例的，而且这个测试用例执行完毕后，对系统来讲，也是没有任何痕迹的，这样就保证了每一个测试用例运行时，都在一个干净的环境中运行。要实现测试用例的独立性，就必须对被测系统的设计有详细的了解，这样，不会出现测试用例执行后遗漏数据，环境未改变，另外，还须要对测试用例进行详细的设计。另外，要保证测试用例的重复使用，还须要作到测试用例的及时更新，在这个方面，咱们是作接口测试的人会维护对应的系统的接口测试用例，要保证，代码每次更新，测试用例都必须所有执行经过。

接口测试用例的设计方法其实和功能测试用例的设计方法是相似的，由于接口是须要知足需求的，而接口测试所依赖的也是需求说明书，可是，由于接口测试毕竟是经过代码去测试代码，因此，为了保证覆盖率，可能会使用到单元测试的方法，具体的测试用例设计，我考虑的以下，请参考，若是有错误，一块儿讨论。

输入参数测试：针对输入的参数进行测试，也能够说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都作了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长。

功能测试：接口是否知足了所提供的功能，至关因而正常状况测试，若是一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具备更好的可读性和维护性。

逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并非那么清楚，因此咱们也能够从给出的设计文档中考虑内部逻辑错误的分支状况和异常； 异常状况测试：接口实现是否对异常状况都进行了处理，接口输入参数虽然合法，可是在接口实现中，也会出现异常，由于内部的异常不必定是输入的数据形成的，而有多是其余逻辑形成的，程序须要对任何的异常都进行处理。

 

2、
接口测试做为集成测试的一部分，经过直接调用被测试的接口来肯定系统在功能性、可靠性、安全性和性能方面是否能达到预期，有些状况是功能测试没法覆盖的，因此接口测试是很是必要的。
　　接口测试分为两种，一种是webservice接口，走soap协议经过http传输，请求报文和返回报文都是xml格式的，测试时经过工具soapUI进行测试。使用状况比较少；另外一种http api接口，走http传输协议，经过路径来区分调用的方法，最经常使用的是get和post请求。
　　上面说过，get和post请求是经过路径来区分的，get请求的请求参数都是写在URL里的，格式为：http://url?param1&param2。而post的请求通常都是写在body里的，多是key-value格式，或者json串格式，也多是上传一个文件。。。那么问题来了，get请求和post请求的区别在哪里呢？咱们百度时，大多数的答案是这样的：
　　一、get请求能够在浏览器中请求到，post请求的测试须要借助工具
　　二、get请求使用url和cookie传参，post的数据放在body中
　　三、post比get更安全，由于传递的参数在url上是看不到的
　　四、get请求的url会有限制，而post请求的数据能够很是大
　　五、通常get请求是来获取数据，post请求是传递数据的
　　其实，对于如今飞速发展的互联网来讲，上面的说法已经不严谨了。首先，post请求的参数也能够写在url里，可是这种状况很少见；其次表面上看起来，post利用body传参，比get的url传参安全，但其实只要用抓包工具（fiddler，Charles等），post的参数也是尽收眼底；再次，如今的浏览器很是强大，能够输入支持很长的URL，因此也再也不有限制一说了。这么说来，种种区别只有最后一条是最根本的了。
　　怎么来测试接口呢？根据什么来测呢？这就须要开发提供的接口文档了，接口文档和功能测试的需求说明书的功能是同样的。包括：接口说明、调用的url，请求方式（get or post），请求参数、参数类型、请求参数说明，返回结果说明。有了接口文档后，咱们就能够设计用例了，通常接口测试的用例分为如下几种：
　　一、经过性验证，说白了就是传递正确的参数，是否返回正常的结果
　　二、参数组合，由于参数有必传和非必传，参数的类型和长度，以及传递时可能业务上的一些限制，因此在设计用例时，就要排列组合这些状况，保证全部状况都能覆盖到
　　三、接口的安全性，这个又分为几种状况：
　　1)绕过验证，好比提交订单时，在传递商品价格参数时，修改商品价格，就要看后端有没有验证了。或者我支付时，抓个包将订单金额一改，若是能以我改后的金额支付，那这个借口就有问题了。
　　2）绕过身份验证，就是某个功能只有有特殊权限的用户才能操做，那我传递一个普通的用户，是否是也能操做呢
　　3）参数是否加密，这个关系到一些帐户的安全，好比咱们在登陆一些网站时，它要将咱们的登陆信息进行加密，若是不加密咱们的信息就会暴露，危害性极大。
　　4) 密码安全规则，设置密码时复杂程度的校验。
　　四、根据业务逻辑来设计用例
　　用例设计完了，用什么来测试接口呢？咱们能够借助一些工具，好比postman和jmeter。postman使用比较简单，能够在列表中选择请求方式，在输入框中输入URL，若是是get请求，直接点击send就能够看返回结果了。


3、

一、什么是接口测试？
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等

二、为何要作接口测试
a)互联网的快速发展，公司内部系统或与外部系统的关联愈来愈多，一个业务流程关联多个后端系统，它们的关联都是基于接口来实现，接口测试能够将复杂的系统关联进行简化，只要作好每一个接口的测试就可以较好的保证系统质量。
b)单个系统的变动，是否会影响到关联业务系统，比较难用常规的测试方面来覆盖相关的应用系统（例如使用此接口的外部 系统有N个，不可能每一个作功能兼容性测试），但能够经过对接口功能的覆盖来验证是否影响它人对接口的调用。
c)接口功能比较单一，可以比较好的进行测试覆盖，也相对容易实现自动化持续集成，，能够减小人工回归成本与时间，缩短测试周期。
d)接口相对于界面功能，会更底层一些，测试覆盖会更容易（如业务在调用接口时作了判断，当不知足条件时连接就不显示，此时从界面没法测试相关功能是否作好判断，经过接口就比较容易）

三、接口测试范围
a)业务功能（包括正常、异常场景是否实现）
b)业务规则（覆盖度是否全面）
c)参数验证（边界、业务规则是否达到要求）
d)异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
e)性能测试（响应时间、吞吐量、并发数、资源要求）
f)安全测试（权限验证、SQL注入等）

四、接口测试的重点
一、检查接口返回的数据是否与预期结果一致。
二、检查接口的容错性，假如传递数据的类型错误时是否能够处理。
三、接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否能够正常处理。
四、接口的性能，http请求接口大多与后端执行的SQL语句性能、算法等比较相关。
五、接口的安全性，外部调用的接口尤其重要。
作好接口测试的前提

一、系统化的接口文档
传统的接口文档，通常采用word或wiki等系统来记录，从单次使用上彷佛比较简单，由于你们会更习惯这样的操做，但这种形式存在比较大的问题：
a、接口文档非标准化，没法直接与接口测试工具接口使用
b、接口维护困难，接口有变化时比较难标识清楚，沟通成本很高
系统化接口文档，例如rap（淘宝分源的一个系统），具有接口维护标准化、版本化管理、MOCK测试等功能；对标准化的接口内容作二次开发，能够直接导出Soapui等工具使用的格式，直接导入工具中使用，有如下好处：
A、接口测试时再也不须要手工输入相关字段，节省时间成本
B、版本化管理，可以清晰的知道哪些接口有变化
o

二、标准化的接口规范
接口管理是作好接口测试很重要的前提，若是一个系统有哪些接口都不太清楚，测试就很难覆盖到，接口管理建议采用如下方式：
A、按接口提供方为单位进行首次划分，按接口使用方进行二次划分，再按业务模块进行细分，分类原则根据内容多少进行优化，不须要固定，如自己接口较少就没有必要分得过细，较多时就须要多划分模块
如：系统A，提供有 一、二、三、四、五、六、七、八、9 这9个接口，接口分别给B系统、C系统使用，其中一、2为公用接口，三、四、5为B专用，六、七、八、9为C系统专用，划分以下：
B、按接口连接URL作为惟一，不一样的接口参数作为接口变量，接口有参数变动时在原来接口上进行维护，而不是新增长接口
C、为接口增长版本号，方便清楚哪些接口本次有变动，易于维护用例

原文：https://www.cnblogs.com/ailiailan/p/8652749.html