API测试方案

- 边界分析测试
  1. 业务边界值测试
  2. 输入输出参数边界值分析
    1. 覆盖所有参数的必选参数
    2. 组合可选参数
    3. 参数有，无，null
    4. 参数的顺序，个数，类型
    5. 参数类型的数值大小，输入数值的范围
    6. 参数字串的长短，null, min,max
    7. 包含特殊字符串
  3. 参数组合测试
  4. 异常情况测试
    1. 并发测试
    2. 事务测试
    3. 环境异常
接口测试策略
- 接口测试依据与规范
  1. API文档标准
    1. 接口的业务名称。
    2. 接口地址：协议，主机，端口，路径
    3. 接口说明，权限说明，注意事项（若无则可以不写）

例如：

1. 1. 1. 发送请求的方式和参数：

参数名称，是否为必填项，参数值的类型，参数意义（比如货物量的吨数，只接受小于100的整数）。以下图为标准：

1. 1. 1. 服务端响应：数据格式（json/xml）

响应事列：{

"errcode": 0,

"errmsg": "ok",

"access_token": "accesstoken000001",

"expires_in": 7200

}

1. 1. 1. 服务端响应参数说明：

参数名称，是否为空，参数值的类型，参数意义，以下图为标准：

1. 1. 1. 服务端响应返回值说明：

业务状态码（返回为0时或返回为-1时）服务端返回值说明（为0时参数对应的返回值为什么，对应返回字段比如：收款单位名称，付款单位名称，剩余对账单金额）

1. 1. 1. 文档管理工具选择swagger
  2. 接口测试用例
    1. 请求方式

Get，post，Delete，put，options，trace

1. 1. 1. 接口地址
    2. 参数
    3. 输入数据
    4. 预期输出的结果
    5. 测试用例模板

1. 1. 1. 接口测试用例编写
是否满足前提条件：1.比如登录需要Token 2.逆向用例：针对是否满足前置条件，设计0~n条用例
是否携带默认值参数：带默认值的参数都不填写，不传参，必填参数都填写正确且存在的常规值其他不填写，设计0~n条用例
业务规则，功能需求
参数是否必填
参数之间是否存在关联：根据实际情况，考虑接口之间的关联，用工具怎么实现
参数数据类型限制：比如string number类型，设计正反向用例
参数数据类型自身的数据范围值限制：针对最大值，最小值，上点，离点来设置正反向用例
1. 1. 1. 编写用例原则

不同的接口参数覆盖不同的业务场景；
在后台构造合适的数据来满足接口的测试用例；
根据接口的返回值，断言其是否返回期望结果，并查看数据库验证；
测试用例涉及多个步骤的，应对涉及的步骤都验证；
删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境。
- 接口测试准入的标准
  1. API文档已出且完整规范
  2. 对测试人员的要求
    1. 熟悉HTTP请求方式，消息结构。
    2. 区分请求方式，熟悉Fiddler，charles等抓包工具，请求头，响应头。
    3. 熟练使用Jmeter，Postman等接口测试工具，理解每个元件的意义。
    4. 熟悉业务逻辑，分析接口文档，按照接口用例编写参数化文件。
    5. 了解Cookie与Session的区别和共同点，以及Token的工作原理。
    6. 测试团队相互配合，技术交流，统一接口测试流程，共同进步完成项目。
  3. 接口测试需求分析：

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

1. 1. 1. 理解接口输出，熟悉返回json的结构构成、返回值类别、返回值范围、返回data的不同类型等。
    2. 理解接口的逻辑、接口的业务关联，熟悉技术方案中的接口相互关联、依赖的关系，接口与接口之间的数据传递等。
  2. 接口数据准备：
    1. 接口数据准备：
    2. 接口入参数据准备，参数化文件准备
    3. 接口调用
    4. 结果调用：接口出参校验，DB数据校验
    5. 数据删除
2. 接口测试工具的选择
  1. 工具介绍
    1. Jmeter 可以测试各种类型的接口，不支持的也可以通过网上或自己编写
    2. Postman 功能上更简单，组织方式也更轻量级，它主要针对的就是单个接口
    3. Apifox 虽然其功能和界面非常易用，但安全性不高，要部署需成本费用
    4. Python 学习成本较高，需对语言及自动化框架熟练掌握
  2. 工具选择
    1. 经小组讨论后统一选择Jmeter作为测试工具，对于单个接口较多的项目可以选择Postman来提高工作效率
    2. Charles,Fiddler等作为抓包工具配合Jmeter使用
3. 接口测试工具的介绍与使用（Jmeter）
  1. Jmeter的下载和运行
    1. 在官网下载JMeter包apache-JMeter-5.3.zip；
    2. 关键：运行JMeter需要先保证电脑上的JDK环境是正常的。
    3. 解压出来，双击bin目录下的JMeter.bat文件，启动JMeter；

1. 1. 1. 常见问题：找不到Java版本

解决方法：在dos下查看有没有安装JDK，如果没有，则先安装JDK并配置环境变量

JDK环境变量配置:

新建一个变量JAVA_HOME，把它的值配置成JDK的安装目录；在path变量中添加%JAVA_HOME%\bin

1. 1. Jmeter的几个基本概念
    1. 测试计划

表示的是一系列描述步骤，可以由一个或者多个线程组构成，一个线程组又可以表示是一个业务流（功能）的实现；

1. 1. 1. 线程组

线程组是一个测试计划的开始点，在一个测试计划中的所有元件都必须在某个线程组下。所有的任务都是基于线程组。

1. 1. 1. 组件与元件

线程、配置元件、监听器等叫组件，组件下面的每个子菜单叫元件，组件就是一组元件

1. 1. 1. 线程数

线程数也就是并发数，每个线程将会完全独立地运行测试计划，互不干扰。多个线程用于模仿对服务器的并发访问，比如配置成10就表示模拟10个用户对接口发起请求，默认是1；

1. 1. 1. 测试计划下多个线程组的执行顺序

默认情况下，测试计划下的“独立运行每个线程组”选项是没有勾选的，表示测试计划下的所有线程组是同时执行的（谁先抢到资源就先执行谁），如果勾选了这个选项，就表示按测试计划下线程组的添加顺序依次执行。

1. 1. 1. 同一个线程组下面的多个线程的执行顺序

同一个线程组下所有的线程是同时执行的，谁先抢到资源就先执行谁。

1. 1. 1. 100个线程循环1次和1个线程循环100次的区别

前者相当于100个用户同时请求服务器，后者相当于1个用户请求100次，显然是前者对服务器的压力会更大。

1. 1. 1. 在JMeter上配置fiddler作为代理

添加一个HTTP请求默认值的元件，在高级页面配置代理服务器的IP和端口，配置的效果就是在该HTTP请求默认值的作用域范围内的所有HTTP请求的代理都采用这里配置的代理。

1. 1. JMeter的八大组件
    1. 取样器Sampler

又称之为采样器，可以实现模拟各种类型的请求发送；是实现JMeter相关测试的核心组件

HTTP请求取样器:
场景一：构造一个GET请求
场景二：构造一个POST请求:方法1：选择协议为POST，把请求参数添加到参数页面上，这时默认的Content-Type就是application/x-www-form-urlencoded；
方法2：选择协议为POST，把请求参数放到消息体数据中，但是要注意一点：在这种情况下默认的Content-Type是text/plain，需要通过HTTP信息头管理器元件来设置Content-Type为application/x-www-form-urlencoded

通过HTTP请求头管理器设置 Content-Type

发送一个POST请求，以JSON格式提交数据，需要在消息体数据下面填入JSON格式的参数，并用HTTP信息头管理器设置Content-Type为application/json。

发送一个POST请求，以form-data方式提交数据，需要在HTTP请求页面勾选对POST使用multipart/form-data选项，并在参数下填入请求参数。

通过Post请求上传文件

1. 1. 1. 调试取样器

非常有用的一个元件，经常用来辅助调试代码，可以通过调试取样器查看JMeter属性、JMeter变量、系统属性等；

1. 1. 1. 配置元件
HTTP信息头管理器：作用是用来配置HTTP请求header里的参数。
HTTP请求默认值：作用是配置其作用域范围内的所有HTTP请求的默认协议、主机ip、端口、路径、代理等等，如果某个请求中没有配置参数，则使用HTTP请求默认值中配置的参数，如果在请求中配置了具体的参数，则使用实际配置的数据。
HTTP Cookie管理器：作用是实现Cookie的自动存储与携带，如果多个接口请求之间要依赖Cookie，需要添加这个元件才能访问。
1. 1. 1. 前置处理器

前置处理器会在它作用域范围内的每个取样器执行之前执行。

1. 1. 1. 后置处理器

后置处理器会在它作用域范围内的每个取样器执行之后执行，常用的后置处理器元件有JSON提取器、正则表达式提取器、XPath提取器等，可以用来从响应中提取想要的内容。

1. 1. 1. 定时器

逻辑控制器可以实现条件判断、循环等操作。

1. 1. 1. 断言，监听器

用来校验响应文本中是否包含、等于某某字符串，如果断言成功则表示用例执行通过；断言失败后会在查看结果树里面展示，成功的话不会展示。作用是查看取样器的执行结果。

1. 1. 八大组件的作用域和执行顺序
    1. 配置元件->前置处理器->定时器->取样器->后置处理器->断言->监听器；
    2. 如果在同一级有多个相同优先级的元件，则按上下文关系按顺序执行；
    3. 取样器跟其他元件没有交互，不存在作用域的概念；
    4. 逻辑控制器只对元件只对其子节点中的取样器和逻辑控制器起作用，作用域就是它下面的所有取样器和逻辑控制器；
    5. 其它6种元件如果父级是一个取样器，那它的作用域就是这个取样器；如果父级不是取样器，那它的作用域是它父级下的所有取样器。
  2. Jmeter参数化:
    1. 使用CSV 数据文件实现参数化；

1. 1. 1. 注意事项：
在Windows上编辑csv文件保存时，如果csv文件中有中文，建议设置编辑格式为UTF-8，同时在csv data set config元件上填写UTF-8编码；
也可以把数据保存在txt格式文件中；
分隔符可以自定义，使用,或者\t或者|等；
通过循环控制器来循环，把csv文件设置元件和取样器放到循环控制器下面，通过循环来实现取每一条数据；也可以通过在线程组中设置循环来实现取每一条数据；还可以通过设置多线程来实现取每一条数据。比如如下图带引号的csv文件

1. 1. 1. 使用__CSVRead函数实现参数化
    2. 使用__StringFromFile函数实现参数化
  2. 接口关联：

在实际场景中，存在多个接口之间有依赖关系的情况，这就是接口的关联；接口的关联有两种典型场景：

1. 1. 1. cookie的关联：

后续接口在请求时需要携带前面接口的响应 cookie，通过添加http cookie管理器来实现cookie的自动存储与发送；

1. 1. 1. 数据的关联：

需要从上一个接口的响应数据中提取某个值，作为下一个接口的请求参数，解决方案是可以通过后置处理器（比如正则表达式提取器、JSON提取器、XPath提取器、CSS/JQuery提取器）从上一个接口的响应中提取数据，定义成变量，再在下一个接口的请求中引用这个变量来解决数据的依赖。

1. 1. 1. 接口关联的处理：
正则表达式提取器：作用是利用正则表达式从响应中提取需要的内容，配置说明如下：
Xpath提取器：提取器的作用是可以从XML格式的响应中提取整个标签或者文本，配置如下：

CSS/JQuery提取器：作用是可以从XML格式的响应中根据CSS选择器路径表达式提取指定属性对应的值；

JSON提取器（此提取器用途广泛）：作用是可以从JSON格式的响应中提取内容，需要写JSON路径表达式

举例：{

"store": {

"book": [

{

"category": "reference",

"author": "Nigel Rees",

"title": "Sayings of the Century",

"price": 8.95

{

"category": "fiction",

"author": "Evelyn Waugh",

"title": "Sword of Honour",

"price": 12.99

{

"category": "fiction",

"author": "Herman Melville",

"title": "Moby Dick",

"isbn": "0-553-21311-3",

"price": 8.99

{

"category": "fiction",

"author": "J. R. R. Tolkien",

"title": "The Lord of the Rings",

"isbn": "0-395-19395-8",

"price": 22.99

}

"bicycle": {

"color": "red",

"price": 19.95

}

"expensive": 10

1. 1. Token鉴权的实现:

接口测试中的token鉴权，同样可以通过处理参数关联的方式来实现，即从响应中提取token，保存为变量，在需要传token的接口请求中引用变量的值。

1. 1. 提取token：

传入token：

1. 1. JMeter断言
    1. 响应断言:用于断言响应中是否包含某个字符串
    2. JSON断言:

对于响应是JSON格式的情况，可以通过JSON断言来断言是否存在某个键值对以及键值对的值；

1. 1. 1. Xpath断言:

可以从XML格式的响应中断言是否存在满足某个条件的标签

1. 1. 1. 持续时间断言:

可以断言接口的响应时间，如果响应时间低于预期时间就断言成功，如果响应时间高于预期时间就断言失败；

1. 1. JMeter操作数据库
    1. 在测试计划下导入数据库的jdbc驱动包；
    2. 通过JDBC Connection Configuration元件实现连接数据库；
    3. 使用JDBC请求元件操作数据库，实现增删改查操作。
  2. 接口测试执行实例
    1. 新增一个测试计划
    2. 添加线程组

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

1. 1. 1. 添加“Http请求默认值”

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

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

1. 1. 1. 在“线程组”里添加“HTTP 请求”的Sampler

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

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

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

1. 1. 1. 添加断言

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

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

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

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

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

1. 1. 1. 添加监听器（测试报告配置）

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

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

运行结果查看：

使用聚合报告查看：

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

- 接口测试准出的标准

1、测试用例已全部执行完成

2、并无严重和致命的Bug，解决并跟进禅道上所有的Bug

- 接口测试的重点
  1. 检查接口的功能：

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

1. 1. 检查接口返回的数据：

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

1. 1. 检查接口的容错性：

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

接口测试管理
- 测试团队和任务

- 时间进度安排
  1. 设置更为紧迫的截至日期

提前设置紧迫的截止日期可以使测试人员专注，高效率的工作，从而不会拖沓办事，提高工作效率和质量。也使项目进度得以有充足的时间进行开发和测试。

1. 1. 根据项目紧急重要程度分配时间
    - - 测试人员需清楚项目开发情况，根据每个项目开发进度制定每日计划，且明确每个计划的重要程度和紧急程度
      - 每天制定工作表，按照优先级分配每日工作，分别完成。
      - 测试人员需预知自己完成计划的时间，给予自己足够多的遗留时间来完成每日任务，如果非常紧急的任务当天未完成，需通过加班完成。
2. 沟通方式
  1. 利用禅道管理方式来跟进Bug
  2. 遇到很难解决或是不太清楚的问题可线下找开发解决沟通
  3. 如遇到第三方接口不配合等情况及时反应到上级领导处
  4. 在接口测试过程中，需开发人员全程积极配合测试人员的项目测试，并给予测试人员相应的建议和帮助
  5. 产品经理需提前制定项目测试计划，安排好项目进度，给予测试人员充足的测试时间，并在接口开发中需求需明确，如有需求变更，需及时更新文档告知开发人员，如有业务逻辑的更换，也需及时告知测试人员。
  6. 需申请的权限

给与测试团队成员连接测试服务器及查看日志的权限

- Bug管理工具
  1. 公司自己的禅道系统
  2. 利用EXCLE统计Bug数量
接口测试风险

风险分类	具体风险情况	解决方案
不透彻理解Api文档	可能存在对需求理解有误差或者对软件的业务功能不熟悉的情况	有疑问的地方需要与产品人员沟通确认，在测试执行期间尽量保持与产品人员和测组同事之间的沟通，多咨询，多请教
预估不足测试时间	工作中遇到突发情况或是工作计划没有合理安排又或是工具不熟悉而导致测试时间预估不足	改进测试方法，学习测试工具以提高测试效率请求同事的帮助必要时适当加班解决遇到问题要及时向测试组长或主管反馈情况
测试执行不到位	测试人员存在侥幸心里而导致部分模块没有被测试。或是对API文档理解不全，业务功能不熟悉并且未虚心求教，未进行相关内容的测试	及时向测试组长或主管反馈，寻求解决办法，决不能蒙混过关粗心大意
人员不足	因负责自己项目的员工生病或有事请假导致项目组人员减少，测试工作缺少人手	向领导反馈，询问其他测试人员能否接手帮助测试。
接口开发时间已超过当前测试时间	可能由于某些原因导致项目组接口开发较困难或推迟能状况	联系产品催促开发人员尽快开发请开发人员预先编写接口文档，完善测试员接口测试用例。
开发人员能力问题	因开发能力不足导致一个Bug多次修改或屡次出错	即时汇报上级，说明其开发情况，必要时可进行项目组人员更换

方案总结
- 方案的意义

测试人员对接口测试流程规范，有效解决在项目开发初期工作有效、有规律的进行，

规范测试人员接口测试用例标准，Bug单标准。

规范测试人员接口测试流程统一性，开发Api文档编写完整、易读、有效提升项目开发效率和减少人工回归测试的人力和时间成本，缩短测试周期，支持后端快速发版。

本方案阐述了项目分析，时间进度安排，测试人员分工分配。可以让测试人员在项目初期就有对项目深刻理解且能很早介入项目开发，让后续测试工作压力减小，工作饱和。

提高测试效率，提升用户体验，降低产品研发成本，接口测试要为代码的编写保驾护航，增强开发人员和测试人员的自信，让隐含的BUG提前暴露出来，要让开发人员在第一时间修复 BUG，要让功能测试人员和性能测试人员在测试的时候更加顺手，最大限度减少底层 BUG 的出现数量，要让产品研发的流程更加敏捷，要缩短产品的研发周期，最后在产品上线以后，要让用户用得更加顺畅，同时也要让用户感觉产品服务零缺陷。
- 方案执行

测试人员使用工具Jmeter，Postman进行接口测试；
严格按照接口测试用例标准作业；
按照Bug管理工具禅道管理Bug;
测试组长安排分工，定期检查测试用例和Bug。
提升测试人员接口测试技能，按照接口测试流程标准进行接口测试。
- 最终效果
  1. 摸索阶段

测试组初期还是个较新的测试团队，需尝试不同的技术，框架和流程规范，希望通过本方案加以提升。

1. 1. 稳定提高阶段

后续根据实际项目实践执行后不断优化定型后的方案，总结出最佳方案。最终使项目都在有序、统一、高效、可靠的进行。

1. 1. 团队影响力

有效，更合理的运用测试团队资源，提高测试团队业绩，提升测试团队影响力，最终使产品质量达到预期，提升产品最终质量。

2022-12-8

接口测试方案

一、简介

（一）定义：

（二）为什么做接口测试:

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

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

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

（三）接口测试测试点：

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

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

3．异常操作：包括参数异常与数据异常两种，其中：

（四）接口测试工具的介绍与使用（Jmeter）

2．并无严重和致命的Bug，解决并跟进禅道上所有的Bug

2．遇到很难解决或是不太清楚的问题可线下找开发解决沟通

3．如遇到第三方接口不配合等情况及时反应到上级领导处

4．在接口测试过程中，需开发人员全程积极配合测试人员的项目测试，并给予测试人员相应的建议和帮助

6．需申请的权限：给与测试团队成员连接测试服务器及查看日志的权限

简介
- 定义

- 为什么做接口测试

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

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

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

- 接口测试测试点

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

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

3、异常操作：包括参数异常与数据异常两种，其中：

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

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

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

接口测试范围
- 业务功能测试

1、正常场景

2、异常场景

- 边界分析测试
  1. 业务边界值测试
  2. 输入输出参数边界值分析
    1. 覆盖所有参数的必选参数
    2. 组合可选参数
    3. 参数有，无，null
    4. 参数的顺序，个数，类型
    5. 参数类型的数值大小，输入数值的范围
    6. 参数字串的长短，null, min,max
    7. 包含特殊字符串
  3. 参数组合测试
  4. 异常情况测试
    1. 并发测试
    2. 事务测试
    3. 环境异常
接口测试策略
- 接口测试依据与规范
  1. API文档标准
    1. 接口的业务名称。
    2. 接口地址：协议，主机，端口，路径
    3. 接口说明，权限说明，注意事项（若无则可以不写）

例如：

1. 1. 1. 发送请求的方式和参数：

参数名称，是否为必填项，参数值的类型，参数意义（比如货物量的吨数，只接受小于100的整数）。以下图为标准：

1. 1. 1. 服务端响应：数据格式（json/xml）

响应事列：{

"errcode": 0,

"errmsg": "ok",

"access_token": "accesstoken000001",

"expires_in": 7200

}

1. 1. 1. 服务端响应参数说明：

参数名称，是否为空，参数值的类型，参数意义，以下图为标准：

1. 1. 1. 服务端响应返回值说明：

1. 1. 1. 文档管理工具选择swagger
  2. 接口测试用例
    1. 请求方式

Get，post，Delete，put，options，trace

1. 1. 1. 接口地址
    2. 参数
    3. 输入数据
    4. 预期输出的结果
    5. 测试用例模板

1. 1. 1. 接口测试用例编写
是否满足前提条件：1.比如登录需要Token 2.逆向用例：针对是否满足前置条件，设计0~n条用例
是否携带默认值参数：带默认值的参数都不填写，不传参，必填参数都填写正确且存在的常规值其他不填写，设计0~n条用例
业务规则，功能需求
参数是否必填
参数之间是否存在关联：根据实际情况，考虑接口之间的关联，用工具怎么实现
参数数据类型限制：比如string number类型，设计正反向用例
参数数据类型自身的数据范围值限制：针对最大值，最小值，上点，离点来设置正反向用例
1. 1. 1. 编写用例原则

不同的接口参数覆盖不同的业务场景；
在后台构造合适的数据来满足接口的测试用例；
根据接口的返回值，断言其是否返回期望结果，并查看数据库验证；
测试用例涉及多个步骤的，应对涉及的步骤都验证；
删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境。
- 接口测试准入的标准
  1. API文档已出且完整规范
  2. 对测试人员的要求
    1. 熟悉HTTP请求方式，消息结构。
    2. 区分请求方式，熟悉Fiddler，charles等抓包工具，请求头，响应头。
    3. 熟练使用Jmeter，Postman等接口测试工具，理解每个元件的意义。
    4. 熟悉业务逻辑，分析接口文档，按照接口用例编写参数化文件。
    5. 了解Cookie与Session的区别和共同点，以及Token的工作原理。
    6. 测试团队相互配合，技术交流，统一接口测试流程，共同进步完成项目。
  3. 接口测试需求分析：

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

1. 1. 1. 理解接口输出，熟悉返回json的结构构成、返回值类别、返回值范围、返回data的不同类型等。
    2. 理解接口的逻辑、接口的业务关联，熟悉技术方案中的接口相互关联、依赖的关系，接口与接口之间的数据传递等。
  2. 接口数据准备：
    1. 接口数据准备：
    2. 接口入参数据准备，参数化文件准备
    3. 接口调用
    4. 结果调用：接口出参校验，DB数据校验
    5. 数据删除
2. 接口测试工具的选择
  1. 工具介绍
    1. Jmeter 可以测试各种类型的接口，不支持的也可以通过网上或自己编写
    2. Postman 功能上更简单，组织方式也更轻量级，它主要针对的就是单个接口
    3. Apifox 虽然其功能和界面非常易用，但安全性不高，要部署需成本费用
    4. Python 学习成本较高，需对语言及自动化框架熟练掌握
  2. 工具选择
    1. 经小组讨论后统一选择Jmeter作为测试工具，对于单个接口较多的项目可以选择Postman来提高工作效率
    2. Charles,Fiddler等作为抓包工具配合Jmeter使用
3. 接口测试工具的介绍与使用（Jmeter）
  1. Jmeter的下载和运行
    1. 在官网下载JMeter包apache-JMeter-5.3.zip；
    2. 关键：运行JMeter需要先保证电脑上的JDK环境是正常的。
    3. 解压出来，双击bin目录下的JMeter.bat文件，启动JMeter；

1. 1. 1. 常见问题：找不到Java版本

解决方法：在dos下查看有没有安装JDK，如果没有，则先安装JDK并配置环境变量

JDK环境变量配置:

新建一个变量JAVA_HOME，把它的值配置成JDK的安装目录；在path变量中添加%JAVA_HOME%\bin

1. 1. Jmeter的几个基本概念
    1. 测试计划

表示的是一系列描述步骤，可以由一个或者多个线程组构成，一个线程组又可以表示是一个业务流（功能）的实现；

1. 1. 1. 线程组

线程组是一个测试计划的开始点，在一个测试计划中的所有元件都必须在某个线程组下。所有的任务都是基于线程组。

1. 1. 1. 组件与元件

线程、配置元件、监听器等叫组件，组件下面的每个子菜单叫元件，组件就是一组元件

1. 1. 1. 线程数

1. 1. 1. 测试计划下多个线程组的执行顺序

1. 1. 1. 同一个线程组下面的多个线程的执行顺序

同一个线程组下所有的线程是同时执行的，谁先抢到资源就先执行谁。

1. 1. 1. 100个线程循环1次和1个线程循环100次的区别

前者相当于100个用户同时请求服务器，后者相当于1个用户请求100次，显然是前者对服务器的压力会更大。

1. 1. 1. 在JMeter上配置fiddler作为代理

1. 1. JMeter的八大组件
    1. 取样器Sampler

又称之为采样器，可以实现模拟各种类型的请求发送；是实现JMeter相关测试的核心组件

HTTP请求取样器:
场景一：构造一个GET请求
场景二：构造一个POST请求:方法1：选择协议为POST，把请求参数添加到参数页面上，这时默认的Content-Type就是application/x-www-form-urlencoded；
方法2：选择协议为POST，把请求参数放到消息体数据中，但是要注意一点：在这种情况下默认的Content-Type是text/plain，需要通过HTTP信息头管理器元件来设置Content-Type为application/x-www-form-urlencoded

通过HTTP请求头管理器设置 Content-Type

发送一个POST请求，以JSON格式提交数据，需要在消息体数据下面填入JSON格式的参数，并用HTTP信息头管理器设置Content-Type为application/json。

发送一个POST请求，以form-data方式提交数据，需要在HTTP请求页面勾选对POST使用multipart/form-data选项，并在参数下填入请求参数。

通过Post请求上传文件

1. 1. 1. 调试取样器

非常有用的一个元件，经常用来辅助调试代码，可以通过调试取样器查看JMeter属性、JMeter变量、系统属性等；

1. 1. 1. 配置元件
HTTP信息头管理器：作用是用来配置HTTP请求header里的参数。
HTTP请求默认值：作用是配置其作用域范围内的所有HTTP请求的默认协议、主机ip、端口、路径、代理等等，如果某个请求中没有配置参数，则使用HTTP请求默认值中配置的参数，如果在请求中配置了具体的参数，则使用实际配置的数据。
HTTP Cookie管理器：作用是实现Cookie的自动存储与携带，如果多个接口请求之间要依赖Cookie，需要添加这个元件才能访问。
1. 1. 1. 前置处理器

前置处理器会在它作用域范围内的每个取样器执行之前执行。

1. 1. 1. 后置处理器

1. 1. 1. 定时器

逻辑控制器可以实现条件判断、循环等操作。

1. 1. 1. 断言，监听器

1. 1. 八大组件的作用域和执行顺序
    1. 配置元件->前置处理器->定时器->取样器->后置处理器->断言->监听器；
    2. 如果在同一级有多个相同优先级的元件，则按上下文关系按顺序执行；
    3. 取样器跟其他元件没有交互，不存在作用域的概念；
    4. 逻辑控制器只对元件只对其子节点中的取样器和逻辑控制器起作用，作用域就是它下面的所有取样器和逻辑控制器；
    5. 其它6种元件如果父级是一个取样器，那它的作用域就是这个取样器；如果父级不是取样器，那它的作用域是它父级下的所有取样器。
  2. Jmeter参数化:
    1. 使用CSV 数据文件实现参数化；

1. 1. 1. 注意事项：
在Windows上编辑csv文件保存时，如果csv文件中有中文，建议设置编辑格式为UTF-8，同时在csv data set config元件上填写UTF-8编码；
也可以把数据保存在txt格式文件中；
分隔符可以自定义，使用,或者\t或者|等；
通过循环控制器来循环，把csv文件设置元件和取样器放到循环控制器下面，通过循环来实现取每一条数据；也可以通过在线程组中设置循环来实现取每一条数据；还可以通过设置多线程来实现取每一条数据。比如如下图带引号的csv文件

1. 1. 1. 使用__CSVRead函数实现参数化
    2. 使用__StringFromFile函数实现参数化
  2. 接口关联：

在实际场景中，存在多个接口之间有依赖关系的情况，这就是接口的关联；接口的关联有两种典型场景：

1. 1. 1. cookie的关联：

后续接口在请求时需要携带前面接口的响应 cookie，通过添加http cookie管理器来实现cookie的自动存储与发送；

1. 1. 1. 数据的关联：

1. 1. 1. 接口关联的处理：
正则表达式提取器：作用是利用正则表达式从响应中提取需要的内容，配置说明如下：
Xpath提取器：提取器的作用是可以从XML格式的响应中提取整个标签或者文本，配置如下：

CSS/JQuery提取器：作用是可以从XML格式的响应中根据CSS选择器路径表达式提取指定属性对应的值；

JSON提取器（此提取器用途广泛）：作用是可以从JSON格式的响应中提取内容，需要写JSON路径表达式

举例：{

"store": {

"book": [

{

"category": "reference",

"author": "Nigel Rees",

"title": "Sayings of the Century",

"price": 8.95

{

"category": "fiction",

"author": "Evelyn Waugh",

"title": "Sword of Honour",

"price": 12.99

{

"category": "fiction",

"author": "Herman Melville",

"title": "Moby Dick",

"isbn": "0-553-21311-3",

"price": 8.99

{

"category": "fiction",

"author": "J. R. R. Tolkien",

"title": "The Lord of the Rings",

"isbn": "0-395-19395-8",

"price": 22.99

}

"bicycle": {

"color": "red",

"price": 19.95

}

"expensive": 10

1. 1. Token鉴权的实现:

接口测试中的token鉴权，同样可以通过处理参数关联的方式来实现，即从响应中提取token，保存为变量，在需要传token的接口请求中引用变量的值。

1. 1. 提取token：

传入token：

1. 1. JMeter断言
    1. 响应断言:用于断言响应中是否包含某个字符串
    2. JSON断言:

对于响应是JSON格式的情况，可以通过JSON断言来断言是否存在某个键值对以及键值对的值；

1. 1. 1. Xpath断言:

可以从XML格式的响应中断言是否存在满足某个条件的标签

1. 1. 1. 持续时间断言:

可以断言接口的响应时间，如果响应时间低于预期时间就断言成功，如果响应时间高于预期时间就断言失败；

1. 1. JMeter操作数据库
    1. 在测试计划下导入数据库的jdbc驱动包；
    2. 通过JDBC Connection Configuration元件实现连接数据库；
    3. 使用JDBC请求元件操作数据库，实现增删改查操作。
  2. 接口测试执行实例
    1. 新增一个测试计划
    2. 添加线程组

1. 1. 1. 添加“Http请求默认值”

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

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

1. 1. 1. 在“线程组”里添加“HTTP 请求”的Sampler

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

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

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

1. 1. 1. 添加断言

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

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

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

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

1. 1. 1. 添加监听器（测试报告配置）

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

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

运行结果查看：

使用聚合报告查看：

- 接口测试准出的标准

1、测试用例已全部执行完成

2、并无严重和致命的Bug，解决并跟进禅道上所有的Bug

- 接口测试的重点
  1. 检查接口的功能：

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

1. 1. 检查接口返回的数据：

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

1. 1. 检查接口的容错性：接口是否可以正常处理（假如传递的参数足够大或者为负、空值时）

7 97

关注

1
点赞
踩
15

收藏

觉得还不错? 一键收藏
1
评论
API测试方案

需要从上一个接口的响应数据中提取某个值，作为下一个接口的请求参数，解决方案是可以通过后置处理器（比如正则表达式提取器、JSON提取器、XPath提取器、CSS/JQuery提取器）从上一个接口的响应中提取数据，定义成变量，再在下一个接口的请求中引用这个变量来解决数据的依赖。默认情况下，测试计划下的“独立运行每个线程组”选项是没有勾选的，表示测试计划下的所有线程组是同时执行的（谁先抢到资源就先执行谁），如果勾选了这个选项，就表示按测试计划下线程组的添加顺序依次执行。接口测试是测试系统组件间接口的一种测试。
复制链接

扫一扫