xx接口测试方案模板

接口测试方案

1.  接口测试的意义

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

 

1. 为什么要做接口测试

1）越底层发现bug，修复成本越低（越早发现bug，修复成本越低）。

2）前后端按约定的接口开发，接口测好了，前端随便改，后端不用变。

3）如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供 这种情况下的解决方案。

4）接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试的人力和时间成本，缩短测试周期，支持后端快速发版。

5）现在很多系统前后端架构是分离的，从安全层面来说：

6）只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端实在太容易），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证；比如电商购物平台，前端价格不可能传入-1 元，但是通过接口可以传入-1元。

7）前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

2. 接口测试流程

1)接口测试的流程和功能测试流程类似，依据的对象是需求说明书和接口需求，接口测试流程如下：

1.  接口测试范围

1)接口的功能实现

    验证接口的功能是否按照API文档正确地实现。

2)逻辑业务测试

    验证接口之间是否有依赖业务，比如查看订单，需要用户先登录，如果不先调用登录也可以查看则不符合业务规则。

3)异常操作

    包括参数异常与数据异常两种，其中：

    参数异常：关键字参数，参数为空，多传，少传参数，错误参数等

    数据异常：关键字数据，数据为空，长度不一致，错误数据等

    关键字参数和关键字数据，指的是在传入参数或数据时，有意地传入java中的关键字，比如class、public等

4)接口的安全性

    比如敏感信息是否加密、必要的参数是否前后端都进行了限制、不带Cookie是否能获取数据、不带Header是否能获取数据等。

4. 接口测试重点

1）检查接口的功能：

检查接口的功能有没有实现，也就是请求会不会成功，如果不成功会不会返回错误代号

检查接口返回的数据：

检查接口返回的数据、数据格式、数据类型是否与预期一致（正向且传递的参数正常）；

检查接口的容错性：

接口是否可以正常处理（假如传递的参数足够大或者为负、空值时）

检查接口的安全性：

外部调用的接口尤为重要。

5. 接口测试需求分析

首先根据接口设计的技术架构方案，了解清楚被测接口对应的公共入参、入参、出参及返回数据的Json结构规范，根据测试场景进行测试。

1) 分析理解接口参数，熟悉接口参数的输入要求、输入值范围、必填项等；

2) 分析理解接口输出，熟悉返回json的结构构成、返回值类别、返回值范围、返回data的不同类型等。

3) 理解接口的逻辑、接口的业务关联，熟悉技术方案中的接口相互关联、依赖的关系，接口与接口之间的数据传递等。

4) 寻找测试点，根据输入(参数名、取值范围)、输出(参数名、返回值范围)、关联关系，进行测试点分析；

6. 接口测试用例设计

接口测试的主要测试对象是接口，但是随着系统复杂度越来越高，接口越来越多，完全覆盖所有接口是很难的一件事情，并且实际过程中任意内部接口的变动都可能导致我们的测试用例的不可用。

1. 接口用例设计优先级

A)优先级-->针对所有接口

a) 暴露在外面的接口，因为通常该接口会给第三方调用；

b) 供系统内部调用的核心功能接口；

c) 供系统内部调用非核心功能接口；

B)优先级-->针对单个接口

a) 首先考虑正向测试用例，其次考虑反向的测试用例；

b)

是否满足接口文档前提条件

是否携带默认参值参数

参数是否为必填项

参数之间是否存在关联

参数数据类型限制

参数数据类型自身的数据范围值限制

2）接口用例设计方法

具体可参考《接口测试用例设计》 如下图所示

 

1. 接口测试用例编写注意事项

 

进行测试用例编写时，有如下的原则：

① 不同的接口参数覆盖不同的业务场景；

② 在后台构造合适的数据来满足接口的测试用例；

③ 根据接口的返回值，断言其是否返回期望结果，并查看数据库验证；

④ 测试用例涉及多个步骤的，应对涉及的步骤都验证

⑤ 删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境

7. 接口测试用例模板

 

8. 接口数据准备

1.  接口测试工具

1) 接口测试工具选择

接口测试工具：Postman/Jmeter/Apifox/Python

Jmeter：可以测试各种类型的接口，不支持的也可以通过网上或自己编写的插件进行扩展。

postman：功能上更简单，组织方式也更轻量级，它主要针对的就是单个的HTTP请求。

Apifox：虽然其功能和界面非常易用，但安全性不高，要部署需成本费用。

Python：学习成本较高，需对语言及自动化框架熟练掌握。

备注：postman，apifox，python等抓包工具经小组一致讨论暂不考虑,目前主要以Jmeter做相关的接口测试。

1. 使用JMeter测试接口时接口组织形式规范如下，具体使用请参考《使用Jmeter测试接口》

1.  接口测试原则

1.  接口测试执行实例

11.1  使用Jmeter测试接口实例

1.接口测试环境准备

Jdk1.8：http://www.oracle.com/technetwork/java/javase/downloads/index.html

Jmeter下载址址：http://jmeter.apache.org/download_jmeter.cgi

插件的下载安装地址：http://www.jmeter-plugins.org/

2. 接口测试过程

1. 新增一个测试计划

1.下载好Jmeter后，双击bin目录下的jmeter.bat文件

2.win+R打开Dos窗口 输入jmeter

2)  添加线程组

在“测试计划”上点击鼠标右键-->添加-->threads(Users)-->线程组，添加测试场景设置组件，接口测试中一般设置为1个“线程数”，根据测试数据的个数设定“循环次数”。

3) 添加“Http请求默认值”

在上步的线程组上右键添加-->配置元件-->HTTP请求默认值。

当所有的接口测试的访问域名和端口都一样时，可以使用该元件，一旦服务器地址变更，只需要修改请求默认值即可。

4)   在“线程组”里添加“HTTP 请求”的Sampler

在“线程组”右键-->添加-->samlper-->“HTTP 请求

在HTTP请求设置页面，录入被测接口的详细信息，包括请求路径，对应的请求方法，以及随请求一起发送的参数列表，配置如下：

注：由于Jmeter请求线程组内的请求时从第一个开始执行，所以我们将需要最先执行的请求放在前面

5) 添加断言

在被测接口对应的“HTTP 请求”上，添加“响应断言”。右键点击HTTP请求“添加”–>“断言”–>“响应断言”

 

 

在设置页面上添加对相应结果的正则表达式存在性判断即可：

要测试的响应字段：响应文本、Document(text)、URL样本、响应信息、Response Headers、Lgnore Staus等选项。虽然接口返回的是Json格式的数据，但对于Jmeter来说返回数据为文本，所以，这里可以勾选“响应文本”

模式匹配规则：包括、匹配、Equals、Substring。这里只需要验证返回数据中是否包含主要的关键字，所以，这里勾选“包括”。

要测试的模式：其实就是断言的数据。点击“添加”按钮，输入要断言的数据。

6)  添加监听器（测试报告配置）

在“线程组”右键-->添加-->监听器->查看结果树、用表格查看结果、聚合报告三种结果的报告展示

 正在上传…重新上传取消

点击运行后，即可看到运行结果，结果如下：

转存失败重新上传取消

 转存失败重新上传取消

使用聚合报告查看：

正在上传…重新上传取消

上述步骤完成了一个简单测试案例的创建，复杂测试案例均在此基础上扩展完成。使用Jmeter工具开发的接口测试案例，一个子系统建议放在同一个 “测试计划”中，流程测试可以通过“线程组”来区分，这样也便于设定不同的测试数据个数。比较独立的接口，可以统一放在一个线程组内，顺序完成测试。　

11.2 接口测试结果报告

• CLI模式运行JMeter脚本
  • 如果在在dos下运行使用JMeter命令运行JMeter脚本，需要先把JMeter的安装目录配置到环境变量PATH里面，配置完之后需要重新打开dos窗口刷新；
  • JMeter命令的参数：
    • -h 帮助 -> 打印出有用的信息并退出
    • -n非GUI模式->在非GUI模式下运行JMeter
    • -t测试文件->要运行的JMeter测试脚本.jmx文件
    • -l结果文件->记录结果的文件（jmeter日志文件）
    • -r 远程执行 -> 在Jmter.properties文件中指定的所有远程服务器
    • -H 代理主机 -> 设置 JMeter 使用的代理主机
    • -P 代理端口 -> 设置 JMeter 使用的代理主机的端口号
    • -e在脚本运行结束后生成html报告
    • -o用于存放html报告的目录
  • CLI模式执行举例：jmeter -n -t jmeter保存文件的路径 -l 日志文件名称 -e -o 测试报告保存的目录

流程性接口的测试：如果要测试的接口可以组成一个流程，只需要顺序添加多个“HTTP 请求”的Sampler，各请求之间可以提取需要在上下文传递的数据作为参数，以保证流程中数据的一致性。

11.3 接口测试中常见问题及bug管理

接口测试经常遇到如下的bug和问题：

（1）传入参数处理不当，导致程序crash;

（2）类型溢出，导致数据读出和写入不一致；

（3）因对象权限为进行校验，可以访问其他用户敏感信息；

（4）状态处理不当，导致逻辑出现错乱；

（5）逻辑校验不完善，可利用漏洞获取非正当利益等；

bug管理工具：禅道

11.4 接口的关联处理

接口自动化适用场景及持续集成（暂定）接口关联：在实际场景中，存在多个接口之间有依赖关系的情况，这就是接口的关联；接口的关联有两种典型场景：

1. cookie的关联：后续接口在请求时需要携带前面接口的响应 cookie ，通过添加 http cookie 管理器来实现 cookie 的自动存储与发送；
2. 数据的关联：需要从上一个接口的响应数据中提取某个值，作为下一个接口的请求参数，解决方案是可以通过后置处理器（比如正则表达式提取器、JSON 提取器、 XPath 提取器、 CSS/JQuery 提 取器）从上一个接口的响应中提取数据，定义成变量，再在下一个接口的请求中引用这个变量来解 决数据的依赖。

四种提取器运用的场景：（具体如下）

正则表达式提取器：是可以通用的，每个场景都可以使用（返回的数据 json 、 html、xml、文本内容，返回的 json 数据是最多）

json 提取器：只能提取 json 数据

xpath 提取器：能提取 html 数据， xml 数据

CSS/JQuery 提取器：能提取 html 数据

正则表达式

又称规则表达式。（英语： Regular Expression ，在代码中常简写为 regex、regexp 或 RE ），正则 表达式通常被用来查询、替换那些符合某个模式(规则)的文本。

转存失败重新上传取消

() 使用小括号把正则表达式的符号括起来，表示返回括号中的符号匹配到的内容（括号也就是分组的意思）

| 表示指明两项之间的一个选择，比如a|b表示匹配a或者b，比如，

(z|f)ood 则匹配zood或food

? 表示非贪婪模式，如果不加?，默认是贪婪模式

正则表达式的贪婪模式和非贪婪模式：

贪婪模式：默认是贪婪模式，表示在满足左右边界的前提下，做最长的匹配，找到最后一个匹配的结果结束（尽可能多的匹配）；

非贪婪模式：使用?表示非贪婪模式，意思是在满足左右边界的前提下，做最短的匹配，找到第一个匹配的结果结束；

正则表达式的提取器

正则表达式的提取器：作用是利用正则表达式从响应中提取需要的内容，配置说明如下：

反向例子

JSON路径表达式

1. $ 表示根节点下的所有数据。
2. .或[] 表示子节点，如$.store表示根节点下的store节点下的所有数据，$[store]也表示相 同意思。
3. .. 任何位置的字节点，如$..title 表示搜索JSON中所有key为title属性的值。
4. * 通配符，表示任何元素，如$.*.book 表示根节点下所有节点的book节点数据。
5. @ 在表达式中使用，表示当前节点对象。
6. [‘’,‘’]如 $..[‘author’,‘price’]表示所有节点中author节点和price的值。
7. [,] 如 $..[1,2]表示所有节点中下标为1和2的节点的值。
8. [start:end] 如 $..book[2]取json中book数组的索引为2的值（第3个值） 。
9. [?()] 过滤器表达式，表达式结果必须是布尔值

JSON提取器

JSON提取器: 用于提取取样器返回的结果

xpath

xpath提取器

XPATH提取器的运用场景：如果服务器返回的数据时html页面或者时xml数据，就是使用XPATH提取

器：科瑞登陆后的xpath：//*[text()="退出"]

如果需要整个标签，就按如下操作:

xpath和Json路径表达的区别

CSS/JQuery表达式

CSS/JQuery提取器

作用：用于提取接口返回的html标签数据：例如：提取百度的网盘html>body>div>div>div:nth-

child(3)>a:nth-child(7)

转存失败重新上传取消

1.  开发要求

1. 对开发的要求

1. 在接口设计阶段，能规范研发人员的接口设计
2. 接口文档规范

1.接口名称

2.接口类型

3.输入参数

参数名；

参数类型；

参数业务含义；

是否可空；

字段长度（可选，一般需要提供，有严格要求的字段需特别注明）；

参数的单位（可选，金额类字段需注明）；

4. 输出结果

参数名；

参数类型；

参数业务含义；

是否可空；

参数的单位（可选，金额类字段需注明）；

返回状态的取值范围及其业务含义。

1.  执行时间

1.接口测试执行开始时间

方案确定通过后即开始执行，具体执行根据项目迭代以及每个人分工而定。

2.项目中接口测试介入时间

后端接口开发完成后即开始测试（开发一个测一个），若当前待测接口存在强依赖关系，则可等相关依赖接口开发完成后再开始。

3.项目中接口测试结束时间

迭代接口开发完成、相关bug修复完毕且无新bug产生，则当前迭代接口测试可结束。

15. 预期效果

1.接口测试的实际意义是为了在整个测试流程中减少因为接口故障或者阻塞导致流程性，或者一些主要功能出现问题的一种测试，所以是提前发现这些问题，去解决问题，已达到避免在后期出现问题时对于代码的改动导致异常的情况出现。但是一套完整的接口测试对于一些长期从事功能测试人员的技术要求也是一定的，在这个过程中可能会出现因为人员技术问题导致时间的增加，所以我们的避免措施是，对于不熟悉此软件的人员可以尽早的去做一些功课，能保证在使用期间避免这些问题的出现。