为啥要做接口测试接口测试用例怎么写哪些工具可以用
4、设计接口测试用例方法前面我们已经介绍了什么是接口测试和接口测试的意义。在开始接口测试之前，我们来想一下，如何进行接口测试的准备工作。或者说，接口测试的流程是什么？有些人就很好奇，接口测试要流程干嘛？不就是拿着接口文档直接利用接口测试工具测试嘛。其实，如果只是三五个接口，你可以这么做一个临时的接口测试。但是，如果是上百个接口，或者，你们公司的这个项目，第一次做接口测试，那么，我们还是很有必要遵守测试的流程。
1.接口测试的流程接口测试和功能测试一样，流程也大致遵守V模型，请看下图
一般来说，接口测试左边的每个阶段，每个公司可能都侧重点不同，例如有些公司就没有需求讨论和需求评审这个阶段。不管如何，用例设计，这个是少不了，而且是重点，要花时间的阶段。只有覆盖全面的接口测试用例，才能有比较好的测试接口覆盖率，才会找出更多的接口的Bug.
2.为什么要写用例功能测试用例，大家都写过。接口测试用例，很多人没有写过。在写之前，我们来讨论下，为什么要写接口用例。
理清思路，避免漏测 提高测试效率 跟进测试进度 告诉领导做过 跟进重复性工作，回归功能使用上面五点，结合自己测试实际经验，应该来说是很好理解和认同的。有用例，就有思路，避免漏掉测试点。跟着用例测试，避免随机测试那种没有目的性的测试，提高测试效率。有用例，上级问你完成的进度，你好用数据回答。有用例，用来标记你执行的结果，证明你做过测试。避免将来发生问题，人家说你没有测试，有数据和证据说话。接口测试也需要重复跑，跑几轮，或者用自动化天天跑。这样的重复性工作，用例可以保证每次重复做的是一样的情况。
3、接口主要设计用例点主要从四个方面来设计接口用例：功能，逻辑业务，异常，安全功能：
1）功能是否正常；
2）功能是否按照接口文档实现
举例：有些添加到购物车，需要登录才能添加。也就是业务要求不支持游客添加购物车功能，如果设计一个没有登录的用户，然后去测试添加购物车接口，结果接口能添加到购物车，说明功能不正常，不符合需求和接口文档描述。
逻辑业务：是否依赖业务；
举例：该接口调用之前，需要调用登录接口，如果不登录也能请求数据，不符合业务规则。
异常：参数异常和数据异常参数异常：关键字参数，参数为空，多，少参数，错误参数数据异常：关键字数据，数据为空，长度不一致，错误数据 举例：不管数据异常还是参数异常，测试点差不多，一个参数有key和value，key表示参数，value表示数据。第一，看看参数和数据能不能支持关键字，例如Java中的保留关键字等等。第二个就是参数和数据都为空，看看是否做了判断。第三个，参数多和少，例如有两个参数的接口，你需要设计一个三个参数的用例，一个只有一个参数的用例。数据那边长度不一致，例如设计很长的字符串是否支持，因为数据库创建表过程都设置好了每个字段的长度。输入错误的参数和数据，例如故意输出单词等等。
安全测试用例设计：
cookie：有cookie才能获取数据，如果不带cookie还有信息返回，说明有问题header：正常接口带header信息，删除header看是否能够返回数据。唯一识别码：app手机识别码，一般是唯一的。安全测试主要从上面三点检查。第三个是唯一识别码，主要是指app上手机的识别码，一般很少用到，除非很严格的接口测试，例如银行app登录，需要指纹，而指纹来源手机，一般有一个手机识别码判断过程。
4、接口测试的工具目前，市场上有很多支持接口测试的工具。利用工具进行接口测试，能够提供测试效率。例如，加入让你一天完成100个接口测试任务，你觉得你加班能否完成。如果有工具，但是不是所有工具都能够支持你完成这个任务。下面我们就来挑选几个工具，简单介绍一下。
1.我画了一个图
1.fiddler
首先，这是一个HTTP协议调试代理工具，说白了就是一个抓http包的工具。web测试和手机测试都能用到这个工具。既然是http协议，这个工具也能支持接口测试。稍后文章，我们会专门介绍fiddler这个工具。
2.postman
这是一款google工程师开发的一个插件，可以安装到chrome浏览器上。支持不同接口测试请求，能够管理测试套件和自动化运行，弱点在于，自动化断言功能不强大。不能和jenkins和代码管理库进行持续集成测试。但是，绝对是一个很好的半手工，半自动化测试工具，我一般在写自动化接口测试用例，会打开postman进行辅助测试和debug。这个工具也会稍后在文章介绍。
3.wireshak
这个是一款计算机上抓包工具，支持抓各种包，TCP,UDP,HTTP都支持。如果做底层网络数据测试，一般都需要用到它。作为接口测试，这个软件有点不友好。因为刷新数据太快，不好定位每个操作对应的接口。所以，我们不会进行过多介绍这个工具。
4.soupUI
这个是一个开源免费和，企业版收费的软件。在国外的接口测试，使用非常多。这个工具能够支持接口自动化测试和接口性能测试，也能支持和jenkins做持续集成测试。了解一下就可以，自己可以下载一个社区免费版，做一个demo试试。
5.java代码做接口测试
代码是万能，笔记工具也是代码开发出来的。为什么要用代码做接口自动化测试呢。因为，有些工具功能是有限制，很多公司，需要一些特定的功能，工具不支持，只好用代码进行开发。一般用Java做自动化测试，主要是利用httpclient.jar这个包，然后利用junit或者testng这样的单元测试工具，进行测试用例的开发，然后在jenkins上创建一个job，进行持续集成测试。
6.Python代码做接口测试
和Java一样，Python中利用一个很好，功能强大的第三方库requests，能够方便都创建接口自动化用例。python下单元测试框架，一般采用unittest。生成测试报告，一般选择HTMLTestRunner.py。同样，可以和jenkins做持续集成测试。
7.LoadRunner
不要以为LR只能做性能测试，loadrunner同样可以做接口自动化和接口压力测试。只是我们很多人，不会利用LR的函数，进行开发接口测试用例。
8.JMeter
JMeter同loadrunner一样，都是以性能测试出名，一般用JMeter也是做接口性能测试。例如java+Jmeter+ant+jenkins做接口性能监听测试。JMeter如何做接口测试，请看我JMeter系列文章。
上面说了这么多工具，基本覆盖了接口功能测试，接口自动化测试，接口性能测试。这里提一下，在Python语言下有一个性能测试工具推荐：Locust。自己百度，安装下，很简单的web界面，感觉很不错，作为一个轻量级的协程测试工具。
接口测试用例和报告模板
当今在测试领域，接口测试已经越来越多的被提及，被重视。
区别于传统意义上的系统级别测试，很多测试人员在接触到接口测试的时候，也许对测试执行还可以比较顺利的上手，但一提到相关的归档，比如测试用例和报告，就有些不知所措了。
今天就用这篇文章来说说接口测试用例和报告。
1.接口用例模板
提到测试用例，我们知道，其中最重要的两个要素就是：
测试步骤预期结果其实对于接口测试也同样如此；接口测试的步骤中，最重要的是将实现向接口发送预设请求，结果则要关注响应信息及后续处理。
所以接口测试用例编排可以考虑下列两种形式：
要注意的是，实际工作场景中我们可能还会对接口之间的串联和混合场景进行测试。
2.测试报告模板接口测试报告很多时候会和接口性能测试报告一起，如果要单独报告的话，可以考虑以下内容：
2.1系统接口概况
简要描述与测试项目相关的一些背景资料，如被测系统简介，项目上线计划等。
对于系统接口的定义和设计做出介绍，比如系统一共有多少个接口？采用哪种协议？都涉及到哪些发送方法？采用怎样的请求格式？使用怎样的返回标准？可用表格说明。
2.2测试目的与范围
描述本次接口测试的目的、范围与目标，内容应与本次接口测试的《接口测试实施方案》中的对应内容保持一致。
2.2.1.测试目的
本次测试的目的在于确保系统接口功能和逻辑处理已验证，符合《接口定义说明书》的定义和要求，满足系统需要。
2.2.2. 测试对象范围
说明测试的对象是哪些
单场景接口功能测试混合场景接口功能测试详见《项目接口测试用例》可考虑贴出x-mind图
2.2.3. 测试指标范围被测接口接收请求和返回报文被测接口返回状态被测接口对应业务逻辑处理涉及数据沉淀的处理复杂场景下多接口串联交互2.3测试工具及资源2.3.1. 测试工具
说明本次测试使用到的测试工具和辅助工具
1.测试工具：该测试将使用Postman（例）
Postman是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运行，并支持用例导出、导入。
2.辅助工具：略
2.3.2. 测试资源
组
成员
职责
总负责
张三
各组间工作协调、方案评审
测试组
李四
需求分析，测试方案编写，脚本编写，执行测试以及编写测试报告
2.4测试记录及结果分析2.4.1. 单场景接口测试2.4.1.1 测试结果数据
给出本次单场景接口测试的测试结果数据
用例
场景描述
被测接口
测试结果
备注
API001
用户登录接口
/user/login
通过
API002
用户登出接口
/user/logout
失败
Defect:41335
......
2.4.1.2. 测试问题及结果分析
结合测试中发现的问题对于整体测试结果进行分析，做出判断。
l 接口业务功能错误类缺陷情况l 接口异常处理类缺陷情况l 接口处理数据沉淀缺陷类情况l 接口安全性缺陷情况2.4.2. 混合场景接口测试2.4.2.1. 测试结果数据
给出本次混合场景接口测试的测试结果数据
用例
场景描述
被测接口
测试结果
备注
APIm001
用户登录、搜索商品、查看商品
/user/login
/commodity/search
/commodity/pdp
通过
APIm002
用户登录、修改个人信息、上传头像
/user/login
/user/personalInfo
/user/personalInfo/portrait/upload
失败
Defect:41510
......
2.4.2.2. 测试问题及结果分析
结合测试中发现的问题对于整体测试结果进行分析，做出判断。
l 混合接口业务功能错误类缺陷情况；l 混合接口业务数据传递类缺陷情况； 2.5测试结论给出本次接口测试的测试总结论，一般以测试结果与测试目标的比较结果作为测试结论。
接口自动化测试（一）
本文参考教程:https://www.bilibili.com/video/BV134411v7Sj?from=search&seid=18200658007058455383
一、接口测试介绍参考链接：https://blog.csdn.net/qq_41782425/article/details/100180470
二、在没有接口测试文档的情况下编写接口测试文档一般情况下，开发都会提供一份接口测试文档；但是如果开发不给测试文档，那么就需要自己来写测试文档；接下开用一个小测试来了解下如何编写接口测试文档；三、实际操作百度查询ip地址接口测试使用工具：Fiddler（任意抓包工具都行）,Postman,Chrome(任意浏览器)步骤：启动Fiddler,简单的设置一下；
1）将允许抓取HTTPS包开启：参考链接：
接口测试用例怎么写
1.什么是接口？接口：主要是子模块或者子系统间交互并相互作用的部分。这里说的接口是广义的，客户端与后台服务间的协议；插件间通信的接口；模块间的接口；再小到一个类提供的方法；都可以理解为接口。接口测试：是指针对模块或系统间接口进行的测试。
2.接口测试经常遇到的bug和问题（1）传入参数处理不当，导致程序crash；（2）类型溢出，导致数据读出和写入不一致；（3）因对象权限未进行校验，可以访问其他用户敏感信息；（4）状态处理不当，导致逻辑出现错乱；（5）逻辑校验不完善，可利用漏洞获取非正当利益等。
3.用例设计思路接口测试的用例设计，主要从输入和接口处理，输出三方面考虑：（1）针对输入，可按照参数类型进行设计；（2）针对接口处理，可按照逻辑进行用例设计；（3）针对输出，可根据结果进行分析设计。
3.0用例模板3.1针对输入设计对于接口来说，输入就是入参。常见参数类型有:（1）数值型(int,long,float,double等）（2）字符串类型（3）数组或链表（4）结构体结构体(struct)是一些元素的结合，元素实际也是数值型，字符串型，数组或链表。下面详细说明数值型、字符串型、数组或链表三种参数类型用例设计。
3.1.1数值型数值型的参数主要考虑以下几个方面设计：如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。例如检查权限的接口：TaskChecker.checkTask(inttaskID)taskID的取值范围是1-35，那么设计时考虑：
1-35范围内和范围外的值；1-35的边界：0，1,35,36；**类型的特殊值：-1,0数据类型的边界值：int的最小值最大值；**因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。常见问题和风险：特殊值处理不当导致程序异常退出；类型边界溢出取值范围外值未返回正确的错误信息等
3.1.2字符串型字符串型的参数，主要考虑字符串的长度和内容：例如接口转换设置闹钟的接口DateUtil.getDayOfDDHH(Stringddhh)，用例可以考虑：长度为4位，比4位少，比4位多；边界值：String的最大长度；特殊值：空字符；字符串内容可考虑类型：数字，非数字；特殊字符。
**如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。**可能出现的问题和风险：传入非特定类型程序异常退出超长字符未进行处理，导致存储、显示等异常其他用户可见设置的敏感字
3.1.3数组或链表类型
参数类型为数组或链表时，用例可以考虑：例如批量提交任务的接口submitTask(int[]taskID)，参数用例设计考虑：正常取值：1-5个权限，范围外：6个权限；边界值：1-35的边界值，请求允许最大最小值；特殊值：0个；合法ID和不合法的；重复的ID等。可能存在的问题和风险：0个item时程序异常退出；重复的item处理时未去重导致结果异常等。
3.2针对逻辑设计接口需要进行一些逻辑处理的，那么按逻辑设计用例可以从以下几个角度分析。3.2.1约束条件分析（1）数值限制：分数限制、金币限制、等级限制等等。例如：兑换Q币活动要求积分>50才可参与。（2）状态限制：登录状态等。例如：同步用户信息需要先登录账号。（3）关系限制：绑定的关系，好友关系等。例如：帮家人防骗功能只能查询绑定家人的来电信息。（4）权限限制：管理员等。约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。它的意义在于：用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。但是实际上，如果有其他手段：例如UI有bug或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。
例如常见的例子：要兑换5Q币需要200积分，但是我积分不足，所以兑换按钮是灰色无法点击的状态：
正常用户是无法操作的，但是兑换其实是调后台的一个接口，如果绕过页面按钮的限制，直接调用后台接口兑换呢？是否可以兑换？预期当然是不能兑换的。因此积分这个数值限制就需要针对接口进行测试，并且非常重要。
其他约束条件类似：时间约束：22：00之前；数值约束：积分200；限量5个；状态约束：登录手机管家；等等约束条件类似。常见的问题和风险：约束条件判断不足，导致用户可通过特殊手段获取利益
3.2.2操作对象分析操作通常是针对对象的，例如用户绑定电话号码，电话号码就是操作对象，而这个电话号码的话费、流量也是对象。对象分析主要是针对合法和不合法对象进行操作。例如下述用例子:用户A查询电话P1话费：用户A查询电话P1流量；用户A查询电话P2话费；用户A查询电话P2流量。后台的逻辑处理，如果一个电话已经被绑定过，从后台的角度是可以查询到该电话的话费和流量的。但是在用户侧，应该是A绑定了的电话，才能让A查询到该电话的话费。故类似对象的测试也必不可少。常见的问题和风险：用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益
3.2.3状态转换分析被测逻辑可以抽象成状态机，各个状态之间根据功能逻辑从一个状态切换到另一个状态。如果我们打乱了这个次序，从一个状态切换到另一个不在它下一状态集中的状态，那么逻辑将会打乱，就会出现逻辑问题。
从某状态改变到新的状态，依赖于转换接口。而对于某转换接口，其输入状态是确定的，比如Fun23,这个函数只能把状态2转换为状态3，而不能把状态1转换为状态3。那么测试点就可以是：（1）状态为状态2，调用接口Fun23（），状态切换到状态3；（2）状态为1,3等，调用接口Fun23（），状态不能切换。
例如在做任务的时候，任务有三种状态：未领取，已领取未提交，已完成三种状态。那么可以这样设计：（1）正常的状态切换：未领取状态，领取任务后变为已领取状态；已领取满足任务条件提交后，变成已完成状态；完成后可以再次领取任务。（2）非正常的状态切换：未领取任务满足任务条件直接提交任务；已领取时再次领取任务等等。常见的问题和风险：可通过特殊手段达到原本不能的状态，从而谋取利益。
3.2.4时序分析在一些复杂的活动中，一个活动是由一系列动作按照指定顺序进行的，这些动作形成一个动作流，只有按照这个顺序依次执行，才能得到预期结果。在正常的流程里，这些动作是根据程序调用依次进行的，并不会打乱，在接口测试时，需要考虑如果不安装时序执行，是否会出现问题。例如，客户端数据同步是由客户端触发进行的，期间的同步用户无法干预。功能测试的时候可见的就是是否能正常进行同步，而进一步分析，同步流程实际涉及了一组动作：
从时序图可以看出，后台有3个接口：登陆获取用户ID，上报本地数据，上报本地冲突。三个接口需要依次调用执行，才能完成同步。那么在接口测试就可以考虑打乱上述接口的执行顺序去执行，会有怎样的结果，是否会出现异常。例如：获取用户ID后不上报本地数据而直接上报本地冲突。常见的问题和风险：非顺序执行后，数据出现异常，可能还会出现程序其他异常通过打乱顺序获取利益
3.3针对输出设计针对输出设计其实是针对接口返回的结果进行分析。3.3.1针对输出结果接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。例如提交积分任务的时候我们通常能想到的是返回正确和错误，错误可能想到：无效任务，无效登录态，但是不一定能否完全覆盖所有错误码，而接口返回定义的返回码可以设计更多用例：
覆盖返回码也是用例设计的一种思路。常见问题和风险：（1）错误前端处理不足，导致前端异常；（2）错误提示处理不当，导致用户看到晦涩的错误码；（3）错误提示不当，导致用户不知道哪里出了问题，如何解决。
3.3.2接口超时接口正常情况下是有返回的，那么如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。如果超时处理不当，可能会引起以下问题：
（1）未进行超时处理，导致整个流程阻塞（2）超时后又收到接口返回，导致逻辑出现错乱
3.4其他测试设计3.4.1已废弃接口测试已废弃协议，是指之前有定义，但是因为需求变更或其他原因，目前版本不用。这些接口虽然不再使用，但有可能代码并没有及时删除。如果利用技术手段调用这些接口，可能获取额外利益。
例如，任务之前有个清理任务，在一个版本需求里将清理任务替换为下载任务。在新版本客户端已不再调用完成清理任务的接口；但是如果该接口未关闭，用户就可以继续请求submitTask(inttaskID)接口完成清理任务获得积分。
因此新版本在考虑兼容旧版本的同时，还应做好相关废弃接口的检查，避免用户获得额外利益。
3.4.2接口设计合理性分析接口定义是否合理可以从以下几个方面分析：（1）接口字段是否冗余；（2）接口是否冗余；（3）接口是否返回了调用方期望得到的信息；（4）接口定义是否可满足所有调用需求；（5）接口定义调用是否方便。
3.5一个完整的例子下面举一个完整例子，通过上述方法来分析如何对接口进行用例设计。
某模块提供了一个接口给其他模块，用户请求任务，接口定义如下：
4.小结
接口用例设计方法中，针对输入、输出的设计是通用的，接口设计时都可用到。对于接口逻辑的设计可能会应用比较适合的一种或几种方法，在接口用例设计时，需要选取最合适的方法去覆盖被测逻辑。