接口测试类型,请问api测试和接口测试有何不同

接口测试类型,请问api测试和接口测试有何不同详细介绍

本文目录一览： 软件测试中接口测试的分类

接口是指外部系统与系统之间以及内部各子系统之间的交互点。包括外部接口、内部接口，内部接口又包括：上层服务与下层服务接口、同级接口。常见的有：API(Application Programming Interface,应用程序编程接口)?、JDBC数据库接口、MySQL Connector.

接口测试的分类：

1、系统与系统之间的调用，如分享时，微信会提供接口给“跑向珠峰”；

2、上层服务对下层服务的调用；

3、服务之间的调用，如添加一条数据时，会先调用

什么是接口测试？

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试就是对系统或组件之间的接口进行测试，主要是校验数据的交换、传递和控制管理过程，以及相互逻辑关系。传智播客官网上写过
业内常说的接口一般指两种：
API：应用程序编程接口，程序间的接口
GUI：图形用户界面，人与程序的接口
软件接口测试中的接口特指API接口
接口测试又称API测试
接口实例：系统与系统间的接口调用，作用：实现了两个或多个独立系统或模块间的通信和数据交换能力。
接口就是指系统或组件之间的交互点，通过这些交互点可以进行数据之间的交互，换言之接口就是系统和系统之间、模块和模块之间的数据交互通道。
比如手机充电口与手机充电线常见的接口：micro-usb接口、lightning接口、type-c接口等
在传智播客上课期间就说过这个。
什么是接口测试
接口测试是测试系统组件间接口的一种方式，接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是检查数据的增删改查操作，以及系统之间的逻辑关系等。
http的几个类型（接口的几种类型）
接口的类型包括：post ，get，put，和delete等。
post和get的区别：post的参数是存在webfrom，以表单的形式存在，get的参数是存在在url中
get：请求获取request-url所标时的资源
post：在request-url所标识的资源提交数据或者附加新的数据。
put：和post很像，也是想像服务器提交数据，put指定了资源在服务器上的位置，post没有
delete：删除服务器上的某个资源

接口测试中 content-type有哪些最常见的类型？

接口测试 content-type有哪些常用类型？

1.application/json 适合提交一些复杂结构的数据，适合restful风格的接口

2.application/form格式的一种数据，浏览器的原生表单的形式；

3.text/xml格式，以http协议为传输协议，以xml为编码方式的一种远程调用规范，一般在webservice结构里比较常见；

4.multipartform-data,需要在表单中上传文件时使用到该格式

什么是接口测试？

什么是接口测试
接口测试是测试系统组件间接口的一种方式，接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是检查数据的增删改查操作，以及系统之间的逻辑关系等。
http的几个类型（接口的几种类型）
接口的类型包括：post ，get，put，和delete等。
post和get的区别：post的参数是存在webfrom，以表单的形式存在，get的参数是存在在url中
get：请求获取request-url所标时的资源
post：在request-url所标识的资源提交数据或者附加新的数据。
put：和post很像，也是想像服务器提交数据，put指定了资源在服务器上的位置，post没有
delete：删除服务器上的某个资源
怎么做接口测试
接口测试只是无界面的功能测试，设计的思路跟功能测试基本都是一致的。
1、输入的参数测试
1）根据参数的要求，进行判断是否满足要求，参数要符合他的要求，比方假如让输入一个数字，那么就判断输入数字----整数、小数、负数、复数等数字进行正常测试，或者超大数值和超小数值，异常测试就是判断当不输入数字，保持为空，或者输入的为字符串，不为数字时，反应是否正常。
2）参数是否为必填项，如果为必填项，将所有的必填项都填写，进行接口测试当必填项未填写时，进行接口测试，查看是否报错
3）如果参数为选填项，则进行测试，如果有多个选填项，一个个进行测试，填入所有必填项，和要求的一个选填项，接口返回是否正确，再测试，当选填项保持为空时，是否能够正常返回，当多个选填项时，是否返回正常
4）如果参数名称填写错误是否报错，如果存在不合法的参数，是否报错等等
5）对每个接口进行逻辑的测试，就是比方为新增一个数据，查对应的url，就得显示新增的数据，也就是所描述的每次新增，删除或者改动后都要进行检查查询。
6）接口中还得考虑一些异常情况，比方权限问题，a方建立了多个内容，b方采用接口是否可以删掉。
7）接口测试还得考虑各种逻辑和现实问题，这个就需要就是根据项目本身的可用性，可以完全想象成功能测试进行测试
8）还要考虑反复提交接口，是否报错
9）异常情景，如请求超时，快速连续点击、请求失败等情况
10）安全性问题，比方登录的密码是否需要加密。
您好，对于接口测试，首先测试人员要懂代码，你只需要知道接口的作用是什么就可以了（有文档更好，但大部分都没有）；其次，自己去读开发的代码；然后，根据该接口功能及代码写测试用例。
用例设计：
1：写一个程序去调用该接口，看是否能够达到该接口所定义的功能。
2：根据该接口参数，构造不同的用例，测试接口在参数合法及非法情况下能否达到预期效果。
3：根据该接口中的逻辑，设计不同条件的用例，测试该接口实现代码的逻辑。
4：进行容错及健壮性测试。
5：静态检测代码，看是否有内存泄露、或永远走不到的分支、代码规范及逻辑是否合理。
6：对于一些接口，需要进行多线程测试。
对于接口测试，首先测试人员要懂代码，你只需要知道接口的作用是什么就可以了（有文档更好，但大部分都没有）；其次，自己去读开发的代码；然后，根据该接口功能及代码写测试用例；
用例设计：
1：写一个程序去调用该接口，看是否能够达到该接口所定义的功能
2：根据该接口参数，构造不同的用例，测试接口在参数合法及非法情况下能否达到预期效果
3：根据该接口中的逻辑，设计不同条件的用例，测试该接口实现代码的逻辑
4：进行容错及健壮性测试
5：静态检测代码，看是否有内存泄露、或永远走不到的分支、代码规范及逻辑是否合理。
6：对于一些接口，需要进行多线程测试
接口测试是在测试系统组件间接口的一种测试。接口测试主要是用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点主要是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
1接口测试的定义与分类，以下就是接口测试
接口测试是测试系统组件间接口的一种测试。
主要用于检测外部系统与系统之间以及系统内部各个子系统之间的交互点。
重点测试数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等等。
这要求对业务逻辑有一定程度上的理解，对数据流向有较好的定位。
接口测试般会用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。
接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。
接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。
接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比。
接口测试天生为高复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换、传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
不是所有的团队都可以在一个隔离的测试环境中进行测试工作的，因此使得对外部接口的测试显得困难。
我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。
有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试，这些都增加了实际测试执行中遇到的风险，但有些时候是可以避免的。
接口测试有的公司是归纳在集成测试里面，也有的公司会放在系统测试阶段，不过这个都没有什么区别，本质上接口测试就是通过某个功能模块对外暴露的一个接口地址传参进行测试。
一般来说接口分为如下三类：
A. 系统与系统之间的调用(如我们一般常见的分享内容到朋友圈或者是微信朋友时，微信会提供接口给这些需要用到分享的应用)上层服务对下层服务的调用（这个理解难度稍微有点大，在我们程序中功能是分层的，那么属于上层对底层服务的调用，以后能够有机会接触到代码或者更加稍微复杂点的接口测试就能够理解。举个例子，我们的程序框架分为三层，分别是web层：提供给用户请求的层次；feb迁至层：作为信息传递的中转站；service层：作为程序应用的核心，处理所有的请求
C.服务之间的调用（如添加一条数据时，会先调用数据查询的服务，查询该数据是否是重复数据）
不同类型的接口测试方法可能不一致，但总体来说不管是哪种类型，被测接口即为服务，测试手段为客服方，接口测试的目的就是：通过我们的测试手段，去验证满足其申明提供的功能。
2如何做接口测试
接口测试的原理：通过测试程序模拟客服端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一过程（reques->response）。
接口测试的流程与功能测试有什么区别呢？从原则上以及流程上讲，是没有啥区别的，都同一套软件测试流程：需求讨论->评审需求->确定需求->产出接口定义->根据需求文档及接口定义设计测试用例（测试用例主要从业务场景，功能以及异常测试几个方面考虑）->评审用例->执行测试。
接口测试采用的最基本的就是黑盒测试，在这个测试过程中我们最需要关注的是，如何来设计测试用例，设计测试用例所采用的方法也是我们常所用的几大方法：等价类、边界值以及错误推测法、场景法。在设计测试用例之前，我们先来看看常见的接口文档形式。
这就是上图是一种比较规范的接口文档说明，包含了如下内容模块：接口的类型说明、接口地址、http请求方式、输入参数和请求接口后返回的响应结果。
接口测试编写测试用例，主要关注点是输入参数、输出结果以及内部业务逻辑是否正常‘，所以我梦设计用例也要从这几方面出发考虑：
a）输入参数测试：针对输入参数进行的测试，也可以说是假定接口参数的不正确性 进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法（不合法），输入参数为空，为null,输入参数超长等等；
b）接口是否满足了所提供的功能，相当正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例就有更好的可读性和可维护性；
c）逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试的界限并不是那么清晰，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；
d）异常情况接口测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何异常都进行处理；
针对上面的注册接口，我们利用测试用例设计方法来编写测试用例，如下所示：
3接口测试的工具选择
可以进行接口测试的工具有很多，这里简单介绍几个：
>loadrunner :一款商业性能测试工具，用来做接口测试，很好很强大。
>jmeter :一款开源的性能测试工具，操作简单方便，既有jdbc request 操作数据库数据，也有http request 和 soap request 应对测试；
>httprequester :火狐浏览器自带接口测试工具，插件中安装即可，界面简单明了，容易上手。
>postman :谷歌浏览器的扩展工具，界面简洁，开发者比较常用的一款插件工具。
>soapui : 开源测试工具，通过soap/http 来检查、调用、实现web service的功能/负载/符合性测试。
我们将在后面的教学中，重点讲解Jmeter这款综合性比较高的工具；

接口测试的测试点有哪些

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
测试的策略：
接口测试也是属于功能测试，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：
评审测试接口文档（需求文档）
根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）
执行测试，查看不同的参数请求，接口的返回的数据是否达到预期
那么设计测试用例时我们主要考虑如下几个方面：
功能测试：
接口的功能是否正确实现了
接口是否按照设计文档中来实现（比如username参数写为了user，那么这就不符合，因为接口文档在整个开发中都需要使用，所以接口实际的设计要与接口设计文档中保持一致）
兼容性测试： 比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式
错误码测试： 通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况
返回值测试： 返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析
参数边界值、等价类测试
json格式测试： 通常我们的接口一般设计的都是传递json串，那么就需要去测试 如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code
默认值测试： 很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。
逻辑业务：
是否有依赖业务，比如查看订单，是需要用户首先登录的，所以肯定要保证登录了或有相应的cookie
业务逻辑测试： 传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行 增删改的操作，也需要看数据库是否同步进行了这些操作
异常测试：
异常分为两类，参数异常和数据异常
参数异常：
关键字参数：将参数写为开发语言中的关键字
参数为空：比如去掉了username参数
多或少参数：多或者少参数的验证，现在还不确定如果一个接口多了参数如果没有报错是否是合理的，或者是否需要优化，因为就目前开发给予的答案是，一般不对接口多了参数的处理
错误参数：比如将username参数写为了user等看是否能返回相应的error code
数据异常：
关键字数据：将参数的值填为开发语言中的关键字
数据为空：将参数的额值填为空
长度不一致：因为数据库中每个字段都设置有字段长度，填写不符合的长度进行验证
错误数据：就是将参数的值任意填写，或填写不存在的数值
异常类型测试： 比如count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断
性能测试：
响应时间
吞吐量
并发用户数
占用内存，CPU等
安全性测试：
敏感信息是否加密
必要参数是否后端也进行校验（现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证）
接口是否防恶意请求（SQL注入）
cookie：就是将header中的cookie修改或删除后看是否能返回相应的error code
header：就是删除或修改header中部分参数的值，看是否能返回相应的error code
唯一识别码：删除修改唯一识别码测试

如何做接口测试？

接口测试作为业务质量的重要保证手段，是整个质量保证过程中必可不少的手段了，目前主要的测试方式包括利用工具进行测试比如postman、jmeter，还有纯代码编写测试case，测试平台，一些支持通过文件写测试用例的框架等。
为什么要做接口测试
在金字塔这样的自底向上结构中，越靠近底层，测试越稳定，所以我们投入的也应该越高；同样的，越是底层，发现问题越早、越高效，修改和维护的成本也就越低。但是单元测试目前只在一些大厂做的比较好，而且单元测试要想覆盖到的全面，需要很大的投入，一般的互联网公司这块是缺失，而由于接口测试的高投资回报比，决定其大范围的应用，互联网公司也会把中心放到这块儿。
接口测试的手段
可视化工具类
常用的接口可视化界面工具有postman，和他的情敌Postwoman，jmeter也可以做，postman可以接入Jenkins实现持续集成，而且操作方便，功能也很强大，现在互联网技术人员几乎人手必备。但是会有个问题，它的灵活性不够，在写接口测试用例的时候回有时会操作mysql、Redis，还会调用thrift，甚至需要建立socket链接，而且无法进行版本控制。
纯代码
纯代码的测试手段是能满足所有的接口测试需求，是最灵活的一种，个人认为也是最好用的一种。不同语言生态都可以实现，比如java生态们可以使用restassured、assrtj、junit来做，python生态可以使用requests、pytest来做，不过这需要编码能力，对测试人员的要求会高一些。
测试平台
通过搭建一个测试平台，在这上面写测试用例，平台一般会提供可视化界面让测试人员编写，平台的好处是可以让不懂编码的同学也能快速写出测试用例，而且可以对测试用例进行管理，控制用例执行等。
支持文件写用例的框架
还要写测试框架支持通过编写json、yaml文件编写测试用例，有框架解析文件生成测试用例，然后去执行。
接口测试的思路
接口测试用例设计主要针对输入、处理、输出进行考虑
针对输入进行设计
对于接口来说，输入就是入参，一般的参数类型数值型边界内、边界值、边界外三个方面去考虑特殊值处理不当程序异常、类型边界溢出、错误信息返回不正确字符串主要考虑字符串长度和字符串的内容空、特殊字符、数字、表情符号数组链表多个重复值、空、最大范围值结构体：json、字典字段错误，字段类型错误、未包含字段、缺失字段
针对逻辑设计
限制条件数值类型限制，比如购买次数、登录次数、优惠券最大面额、订单取消次数等状态限制：比如是否登录、是否有订单等关系限制：比如好友关系、关注关系，只能查看好友或者关注人的朋友圈权限限制：比如销售只能查看和自己绑定客户数据，而管理员可有查看所有客户数据时间限制：比如未支付过20分钟订单自动取消状态转换分析比如一个出租车订单，从乘客下单、司机抢单、到达起点、接上乘客、到达目的地，发起支付，支付，评价这是一个完整的订单状态转换流程，必须按照这个次序，才能正确流转，一旦打乱其中任何一个状态，就会出现逻辑问题。接口用例可以这样设计：正常状态迁移：乘客下单，司机抢单，异常状态迁移：乘客刚下的那，司机发起支付，出现异常针对输出设计
针对输出结果，一般情况下，接口正常处理的结果可能只有一个，但是异常的处理结果，可能会返回多种错误，那就可以针对不同的错误进行设计。接口超时，旧版本接口，废弃接口，接口设计是否合理，比如字段冗余、接口冗余、返回错误信息是否清晰明了、调用是否方便，幂等性总结
接口测试重要的思路要明确，清晰的理解业务逻辑，至于具体的工具根据自己目前的能力选择，先去做，在做的过程中不断完善不断学习，早日提高自己的测试技能。
码字不易，欢迎大家点赞评论支持。

请问api测试和接口测试有何不同

API测试又称为接口测试，接口测试是功能测试的一种。
API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
API函数包含在Windows系统目录下的动态连接库文件中。Windows API是一套用来控制Windows的各个部件的外观和行为的预先定义的Windows函数。用户的每个动作都会引发一个或几个函数的运行以告诉Windows发生了什么。这在某种程度上很像Windows的天然代码。而其他的语言只是提供一种能自动而且更容易的访问API的方法。

接口自动化测试测试用例设计

浅谈接口自动化测试测试用例设计

一、 ? 前言 ??

很多中台项目，大部分为接口测试。为了使新入职的测试同事尽快融入项目，以及迭代开发中方便管理测试用例。完成该总结。

二、 ? 测试用例设计思路 ??

1、 接口类型概述及优先级 ?

1） 提供给第三方调用的接口 ?

2） 内部系统使用，核心功能接口 ?

3） 内部系统使用，非核心功能接口 ?

基本按照1）2）3）的顺序进行测试，特别情况除外

2、?单接口测试优先级??

1） 优先测试正向测试用例，保证基本功能实现 ?

2） 设计逆向测试用例，确保接口的健壮性 ?

3） 满足前提条件的测试用例 ?

4） 默认参数是否满足 ?

5） 参数校验 ?

6） 参数间联动关系

7）多参数错误处理的优先顺序校验

三、 ? 设计分析 ??

1、?满足前提条件的测试用例??

测试目标接口需要满足前置条件才能成功获取数据。

例如：需要登录token，通过传入参数获取下游接口数据

2、?携带默认参数的测试用例??

携带默认参数的测试用例仅需要设计一条，所有默认参数的字段都不填写，其他字段输入正常。

[if !supportLists]3、?[endif]参数校验??

参数校验包含如下几方面：

[if !supportLists]1）[endif]输入参数是否为必须输入项

[if !supportLists]2）[endif]输入参数的类型

[if !supportLists]3）[endif]输入参数的枚举值校验

[if !supportLists]4）[endif]输入参数长度校验

以上测试用例最好根据字段一一校验，排除互相干扰

[if !supportLists]4、?[endif]参数间联动??

有些参数见存在彼此制约的关系，根据实际情况设计测试用例

例如:A字段为1时，B字段一定为空。否则报错。

那么测试用例设计时应为：A字段为1时，B字段为空；A字段为1时，B字段不为空；A字段不为1时，B字段为空；A字段不为1时，B字段不为空；四条测试用例

这样基本覆盖所有分支流程。

[if !supportLists]四、?[endif] 测试用例实践操作

接口测试用例样例:

多条件查询接口

测试方法：使用robotFramework测试doubbo接口

协议请求方式：post

接口协议：JSON

消息请求列表

字段名数据类型默认值必须项备注

IDint?是长度为2

Tokenstring?是设备令牌

Statusstring?是1：正常

2：异常

typeint??Status为1时，为必须输入项

sizestring??默认值

消息返回列表

字段名数据类型必须项备注

Codeint是正常：20000

异常：20001

Messagestring是?

typeMessageint?Status=1的所有ID

?

用例设计

?

NO. 测试内容 前置条件 输入参数 输出参数 用例属性

1目标数据为一条预置一条符合条件的数据Status=1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

正向测试用例

2目标数据为多条预置多条符合条件的数据Status=1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

正向测试用例

3 Token必须项检查 预置多条符合条件的数据Status=1，token输入为空，其他参数输入正常返回code=20001

typeMessage中返回为空

满足前提条件

4 Token正确性检查 预置多条符合条件的数据Status=1，token输入错误，其他参数输入正常返回code=20001

typeMessage中返回为空

满足前提条件

5 Status 必须项检查 预置多条符合条件的数据Status为空，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

6 Status枚举预置多条符合条件的数据Status为1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

参数校验

7 Status枚举预置多条符合条件的数据Status为2，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

参数校验

8 Status枚举预置多条符合条件的数据Status为3，其他参数输入正常返回code=20001

typeMessage中返回null

参数校验

9 Status=1，时联动校验预置多条符合条件的数据Status为1，type为空；其他参数输入正常返回code=20001

typeMessage中返回null

联动校验

10 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type为空；其他参数输入正常返回code=20000

typeMessage中返回对应ID

联动校验

11 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type不为空；其他参数输入正常返回code=20000

typeMessage中返回对应ID

联动校验

12 Size默认值输入校验预置多条符合条件的数据Size输入为空，其他参数输入正常返回code=20000

typeMessage中返回对应ID

默认值校验

13 Size默认值输入校验预置多条符合条件的数据Size输入不为空，其他参数输入正常返回code=20000

typeMessage中返回对应ID

默认值校验

14 ID 必须项检查 预置多条符合条件的数据ID为空，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

15 ID 长度检查 预置多条符合条件的数据ID长度大于2，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

16 破坏性测试预置多条符合条件的数据输入的参数类型错误请求未接收，返回404 稳定性测试

17 破坏性测试预置多条符合条件的数据输入的参数与提供的参数名称不一致请求未接收，返回404 稳定性测试

18 破坏性测试预置多条符合条件的数据输入的参数与提供的参数数量不一致请求未接收，返回404 稳定性测试

19 破坏性测试预置多条符合条件的数据输入的参数与提供的参数格式不一致请求未接收，返回404 稳定性测试

?

总结：自动化测试过程中会有一条自动化测试用例覆盖多种情况的可能（例如：正向测试用例与联动性验证的 Status=1，type输入不为空的测试用例重复，所以选择一条用例验证 。 ），以上的测试用例满足自动化的要求，手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性，无需检查输入参数的类型。

接口测试注意的点

接口测试作为集成测试的一部分，通过直接调用被测试的接口来确定系统在功能性、可靠性、安全性和性能方面是否能达到预期，有些情况是功能测试无法覆盖的，所以接口测试是非常必要的。

接口测试分为两种，一种是webservice接口，走soap协议通过http传输，请求报文和返回报文都是xml格式的，测试时通过工具soapUI进行测试。使用情况比较少；另一种http api接口，走http传输协议，通过路径来区分调用的方法，最常用的是get和post请求。

　　get请求和post请求的区别在哪里呢？网上的答案为：

　　1、get请求可以在浏览器中请求到，post请求的测试需要借助工具

　　2、get请求使用url和cookie传参，post的数据放在body中

　　3、post比get更安全，因为传递的参数在url上是看不到的

　　4、get请求的url会有限制，而post请求的数据可以非常大

　　5、一般get请求是来获取数据，post请求是传递数据的

　　其实，对于现在飞速发展的 互联网来说，上面的说法已经不严谨了。首先，post请求的参数也可以写在url里，但是这种情况不多见；其次表面上看起来，post利用body传参，比get的url传参安全，但其实只要用抓包工具（fiddler，Charles等），post的参数也是一览无余；再次，现在的浏览器非常强大，可以输入支持很长的URL，所以也不再有限制一说了。这么说来，种种区别只有最后一条是最根本的了。

　怎么来测试接口呢？根据什么来测呢？这就需要开发提供的接口文档了，接口文档和功能测试的需求说明书的功能是一样的。包括：接口说明、调用的url，请求方式（get or post），请求参数、参数类型、请求参数说明，返回结果说明。这里接口文档生成可以使用apipost接口文档生成工具。有了接口文档后，我们就可以设计用例了，一般接口测试的用例分为以下几种：

1、通过性验证，说白了就是传递正确的参数，是否返回正常的结果

2、参数组合，因为参数有必传和非必传，参数的类型和长度，以及传递时可能业务上的一些限制，所以在设计用例时，就要排列组合这些情况，保证所有情况都能覆盖到

3、接口的安全性，这个又分为几种情况：

　　1)绕过验证，比如提交订单时，在传递商品价格参数时，修改商品价格，就要看后端有没有验证了。或者我支付时，抓个包将订单金额一改，如果能以我改后的金额支付，那这个借口就有问题了。

　　2）绕过身份验证，就是某个功能只有有特殊权限的用户才能操作，那我传递一个普通的用户，是不是也能操作呢

　　3）参数是否加密，这个关系到一些账户的安全，比如我们在登录一些网站时，它要将我们的登录信息进行加密，如果不加密我们的信息就会暴露，危害性极大。

　　4) 密码安全规则，设置密码时复杂程度的校验。

4、根据业务逻辑来设计用例

用例设计完了，用什么来测试接口呢？我们可以借助一些工具，比如apipost和jmeter。apipost使用比较简单，可以在列表中选择请求方式，在输入框中输入URL，如果是get请求，直接点击发送就可以看返回结果了。

　　如果是post请求，会涉及到几种参数的上传方式和添加请求头、权限验证还有添加cookie等操作。apipost都可以简单实现

　　还有一种测试接口的工具是jmeter，用途比较广泛，不但能测接口的功能，还能对接口进行性能测试。比如：压力测试、负载测试等。在jmeter中需要创建线程组，如图：

Apipost官方链接： https://console.apipost.cn/register?utm_source=10008