Skip to content

基础知识

字数
6176 字
阅读时间
25 分钟

一、基本概念

  • 接口:系统之间或组件之间的交互点,通过这些交互点可以实现数据的交互。接口就是数据交互的通道。
  • 接口类型
    • 按范围划分:
      1. 系统之间的接口:多个内部系统之间的交互,内部系统与外部系统之间的交互
      2. 程序内部的接口:方法与方法之间、模块与模块之间的交互
    • 按协议划分:Tcp、IP、HTTP等接口
    • 按语言划分:C++、Python、Java

1. 接口测试

  • 接口测试:对系统之间或组件之间的接口进行测试。校验传递的数据正确性和逻辑依赖关系的正确性。
1)原理
  • 模拟客户端向服务器发送请求,测试服务器针对客户端请求回发的校验数据是否符合预期结果--> 断言(主要针对服务器进行测试)
2)特点
  1. 测试可以提前介入,提早发现bug,符合质量控制前移的理念
  2. 可以发现一些页面操作发现不了的bug
  3. 接口测试低成本高效益(接口测试属于底层测试,一个底层bug可能会引发多个上层bug)
  4. 接口测试是从用户角度对系统进行全面检测
3)常用工具、代码
  • 工具:JMeter、Postman、Fiddler(Fiddler主要是抓包)
  • 代码:Python+Requests+UnitTest

2. 接口自动化测试

  • 概念:让程序或工具代替人工自动完成对接口进行测试的一种过程。即:借助工具、代码,模拟客户端向服务器发送请求,并通过断言自动判断预期结果与实际结果是否一致

3. HTTP协议

该协议主要用于B/S架构的系统
  • 协议 --> 规则:要求通信的必须严格遵守
  • HTTP:超文本传输协议,是一种基于请求和响应模式的、应用层的协议,也是互联网上应用最为广泛的一种网络协议。
    • IP:在网络环境中唯一标识一个主机
    • TCP端口:一台主机的一个端口唯一标识一个 应用
  • 特点:
    1. 支持客户端/服务器模式
    2. 简单快速
    3. 灵活
    4. 无连接(可以通过IP和Port端口唯一标识定位到一个主机上的指定应用)
    5. 无状态(主要是相对TCP/IP协议而言,TCP协议建立连接过程中客户端和服务器都有会多种状态变化,但HTTP协议没有)

4. 🌟URL

  • URL:统一资源定位符,是互联网上标准资源的地址。HTTP使用URL来建立连接和传输数据。URL可在网络 环境中唯一的定义一个资源(可以是网站、也可以是方法函数、变量等)。
  • 🌟URL语法格式组成:
    • 查询参数以键值对形式存储,与资源路径之间通过 ? 分隔
    • 协议:http --> 规定数据传输的方式
    • 域名(IP):在网络环境中找到主机 --> 通过://与协议隔分
    • 端口(Port)(常省略,为默认值):在网络主机上,标识一个进程(应用程序) --> 通过:与域名隔分。范围:065535
      • http默认端口:80
      • https默认端口:443
    • 资源路径:标识网络资源(音视频、图片、文件、变量等) --> 通过/与端口隔分
    • 查询参数:将参数传递给资源路径标识的资源。 --> 通过 ? 与资源路径隔分;查询参数内部通过 & 隔分多个键值对
  • 例如:https://www.baidu.com/的协议是https,域名是www.baidu.com,端口默认为443,资源路径没写,默认为最后的/,一般指向index.html

5. HTTP请求

  • 作用
    • 客户端(app、浏览器),发送请求给服务器时,使用的协议 ---- http请求协议
    • 规定发送给服务器的数据传输的语法格式
  • 整体结构:
    • 请求行(http请求第一行):请求方法 URL 协议版本(协议版本主流是HTTP/1.1)
    • 请求头:语法格式 --> k: v (键值对格式)
      • User-Agent:告知服务器,当前的浏览器是什么类型(描述 请求发送端 的浏览器类型)。服务器就会返回对应的浏览器数据,防止多并发导致浏览器性能下降,防止爬虫
      • 🌟
        • 需要注意的两个Content-Type:application/x-www-form-urlencoded(表格类型的数据)和application/json(json类的数据)
    • 空行:代表http请求头结束
    • 请求体:请求发送时携带的数据。数据类型与Content-Type标识的一致
      • post 和 put 有请求体
      • get 和 delete 没有请求体
  • 示例:
1)请求行
  • http请求方法:
    1. GET:查询数据。参数在URL中作为查询参数传入
    2. POST:提交/添加数据。参数封装在请求体body中,更安全(常用作登录)
    3. PUT:修改数据。
    4. DELETE:删除数据。
2)请求头
  • 语法格式:k:v对(键值对)
  • 典型的请求头有:
    • 🌟User-Agent:产生请求的浏览器类型(请求发送端)
    • Accept:客户端可识别的内容类型列表
    • 🌟Content-Type:请求体数据的类型,常见的类型有:
      • text/html:HTML格式
      • text/plain:纯文本格式
      • image/jpeg:jpg图片格式
      • :JSON数据格式
      • :form表单数据被编码为key/value格式发送到服务器(表单默认的提交数据格式)
      • multipart/form-data:在表单中进行文件上传时使用
3)请求体
POST和PUT方法有请求体,GET和DELETE方法没有请求体
  • 数据值的组织形式受 Content-Type 影响

6.HTTP响应(或称:响应包、响应报文)

  • 一个响应包中只能有一个状态码
  • 作用:
    • 服务器端,针对客户端发送的http请求,回发响应数据。 --> http应答
    • 规定 回发给客户端的数据组织格式
  • 组成结构:响应行、响应头、空行、响应体
  • 示例:
1)响应行(状态行)
  • 格式:协议类型 状态码 状态描述
    • 如上文示例图中所示,HTTP/1.1是协议类型,200是状态码,OK是状态描述/状态消息
  • 状态码由三位数字组成,第一个数字定义了响应的类别:
    • 1xx:指示信息,表示请求已被接受,等待继续处理
    • :请求成功被处理/接收。常见:200、201
      • 注意,请求成功被处理,不代表该请求的事件成功。例如:请求登录 --> 成功处理请求 --> 密码错误 --> 响应行返回 200 OK,但请求体返回错误提示信息
    • 3xx:请求的资源需要重定向 --> 待访问的资源需要重新指定路径访问
    • :代表客户端错误。常见:404、403
    • 5xx:服务端错误。 --> 可能是由于其他原因导致的服务端错误,不一定是服务端出错了。
  • 状态码描述:一般与状态码唯一对应。 200 -- OK; 404 -- file not found
2)响应头
  • 语法格式:k:v对
  • Content-Type:描述 响应体 中的数据类型。
  • Content-Length:标明 响应体 的大小。
    • 单位:Byte(字节)。计算时要考虑编码,例如:ASCII和UTF-8编码下可能大小不同。
    • 可以不写,服务器会自动求取。一旦写了,必须准确,否则浏览器仅显示Content-Length指明的大小,多余的内容不会显示。
3)空行
  • 代表响应头结束
4)响应体
  • 绝大多数情况下不为空。(请求成功回发数据,请求失败回发错误信息)
    • 数据类型受响应头Content-Type值影响
    • 常携带 错误码 信息

7.常见接口

1)传统风格接口【了解即可】
  • 对用户进行操作的相关接口,包括增删改查,其URL结构设计如下:协议类型://IP:端口/项目名/模块名/具体方法名?参数名=参数值,例如:删除功能教学示例为:http://127.0.0.1:8080/myweb/user/deleteUser?id=1
    1. 查询某个用户
      • 请求方法:GET/POST
      • 成功状态码:200
    2. 查询所有用户
      • 请求方法:GET/POST
      • 成功状态码:200
    3. 添加用户
      • 请求方法:POST
      • 成功状态码:200
    4. 修改用户
      • 请求方法:POST
      • 成功状态码:200
    5. 删除用户
      • 请求方法:GET/POST
      • 成功状态码:200
  • 请求方法只使用GET和POST即可。URL不唯一,同一个操作可能有多个URL(主要是具体的方法名不一样,可能不同方法实现的是同一个功能,就会造成这种情况)
  • 状态码使用较单一,200最常见。
2)RESTful风格接口
定义
  • RESTful:即:Representational State Transfer的缩写,意思是“表现层状态转化”。
    • 表现层:对同一个对象的描述方法/表现形式不同(例如,对一个人的描述/表现,可以是文字描述,也可以是图片)
    • 状态转化:一个接口可以有POST、GET、PUT等多种不同的请求方法
    • URL组成:协议类型://IP:端口/资源名/资源标识?参数名=参数值
常用功能接口
  1. 查询某个用户
    • 请求方法:GET
    • 成功状态码:200
  2. 查询所有用户
    • 请求方法:GET
    • 成功状态码:200
  3. 添加用户
    • 请求方法:POST
    • 成功状态码:201
  4. 修改用户
    • 请求方法:PUT
    • 成功状态码:201
  5. 删除用户
    • 请求方法:DELETE
    • 成功状态码:204
RESTful架构特点
  1. 每个URL代表一种资源
  2. 客户端和服务器之间,传递这种资源的某种表现层(即:传递其表现形式)
  3. 客户端通过四个HTTP动词(GET、POST、PUT、DELETE),对服务器资源进行操作,实现“表现层状态转化”
  4. 接口之间传递数据最常用的格式为JSON
3)区分
  • 可以通过请求方法来区分传统接口方法和RESTful接口方法,传统接口方法只有两种(GET和POST),而RESTful接口方法则有四种,对应数据库增删改查(GET、POST、PUT、DELETE)

8.接口测试流程

  1. 分析需求,产生需求文档(产品)
  2. 开发产生接口文档,解析接口文档
  3. 产生测试用例(送审)
  4. 执行接口测试用例
    • 工具:postman、jmeter
    • 代码:python + Requests + UnitTest
  5. 提交、跟踪缺陷
  6. 生成测试报告
  7. (可选)接口自动化持续集成
1)接口文档
  • 接口文档:又称API文档,一般是由开发人员所编写的,用来描述系统所提供接口信息的文档。大家(开发团队)都根据这个接口文档进行开发,并需要一直维护和遵守
  • 作用/好处:
    1. 能让前端开发和后台开发人员更好的配合,提高工作效率(有个统一的参考文档)
    2. 项目迭代或者人员变动时,方便后期参与人员查看和维护
    3. 方便测试人员进行接口测试
  • 常见形式:Word、Excel、PDF
  • 结构:
    • 基本信息:
      • 资源路径(协议和域名在“系统信息”中)
      • 请求方法
      • 接口描述
    • 请求参数:
      • 请求头
        • Content-Type --> 描述请求体数据类型
      • 请求体
        • 实现该接口使用的数据以及对应类型
    • 返回数据:
      • 状态码200
      • 错误码(一种自定义的状态码)
        • 码值:例如:200,1000
        • 描述信息:例如:OK,操作成功!

状态码仅表示HTTP请求传输的成功与否,其对应的业务功能是否成功执行则要看返回的错误码内容。断言时最好对状态码和错误码一并进行断言判断。

2)接口文档解析
  • 本质:从接口文档中,找出http请求所需要的数据信息请求方法
    • 主要包含:请求方法、URL、请求头、请求体、状态码、响应状态码、描述
    • 以“登录”功能为例:
      • 请求方法:POST
      • URL:http://ihrm-test.itheima.net/api/sys/login
      • 请求头:Content-Type:application/json
      • 请求体:
      • 响应状态码:200
        • 错误码(就是开发人员自定义的状态码):
          • 10000:操作成功!
          • 20001:用户名或密码错误
          • 99999:抱歉,系统繁忙,请稍后重试!

二、接口测试

1. 测试点设计

在设计接口测试的测试点之前,我们要先了解接口测试阶段需要进行哪些测试。后续的接口测试内容,都是借助工具、代码,绕过前端页面,组织接口所需要的数据,展开接口测试。
1) 功能测试
  1. 单接口功能:手工测试中的单个业务模块,一般对应一个接口
    • 例如:
      • 登录业务 --> 登录接口
      • 加入购物车业务 --> 加入购物车接口
      • 订单业务 --> 订单接口
      • 支付业务 --> 支付接口
  2. 业务场景功能
    • 按照用户实际使用场景,梳理 接口业务 场景
    • 组织业务场景时,一般只需要做正向测试即可(与手工功能测试一致)
    • 一般建议用最少的用例覆盖最多的业务场景
      • 例如:登录 --> 搜索商品 --> 添加购物车 --> 下单 --> 支付 --> 评价
        • 这一条用例就直接覆盖了用户使用最多的业务场景(至于登录--> 搜索商品 --> 添加购物车 --> 退出 这类业务场景的用户使用数不会太高)
2)性能测试
后续还会继续详细讲解,这里仅作了解
  1. 响应时长:客户端发送请求后,直到接收到服务器返回的响应,这期间经过的时长
  2. 吞吐量:当前接口能处理的当前用户的请求数。
    • 吞吐量一般以TPS为参考指标(TPS:单位时间内服务器接口能处理的事务数)
  3. 并发数:单位时间内同时有xxx个用户访问接口
  4. 服务器资源使用率
3)安全测试(常指业务安全)
  • 攻击安全:由专业的安全测试工程师来完成
  • 业务安全:
    1. 敏感数据是否加密
    2. SQL注入
      • 例如:原先传入后台生成的SQL操作为:select * from table1 where username = '$name' and password = '$pwd',而SQL注入可以在用户名name后注入’ or 1=1#来绕开条件语句,#在SQL语句中的作用是将#后的所有内容注释掉,也就是说,SQL注入后,SQL操作变为select * from table1,这会导致table1表中的所有字段信息都会暴露出来
    3. 其他
与手工测试的不同之处
  1. 手工测试是 测试手工写入到输入框中的数据是否正确。接口测试是 测参数对应的参数值是否正确。
  2. 接口测试不仅可以对参数值进行测试,还可以对 参数本身 进行测试。
    • 例如:接口文档中,登录功能的参数为:username和password,那么就要测试一下 uname,pwd等错误参数名,携带正确参数值时是否能成功登录。(参数名不对,那么就算参数值正确也不应该登录成功)
  • 接口测试:
    • 正向参数:
      • 必选参数:所有的 必选(必填)参数 都包含
      • 组合参数:所有的 必选 + 任意一个或多个可选参数
      • 全部参数:所有的 必选 + 所有的 可选参数
    • 反向参数:
      • 多参数错误:同时构造多个错误参数值,查看接口是否能识别出所有的错误,用于判断接口的综合处理能力
      • 冗余参数(多参):多传了一个或多个 API 接口文档中没有定义的参数
      • 少参:缺少了一个或多个 必选参数
      • 无参:请求体为空,未传入任何必选参数,是"少参"的极端情况
      • 错误参数:参数名错误。或参数名正确,但参数值不对

2. 单接口测试用例

  • 手工 功能测试 测试用例 8大要素:编号、(用例名称)标题、模块、优先级、前置条件、测试数据、测试步骤、预期结果
  • 接口测试 测试用例 10大要素:编号、(用例名称)标题、模块、优先级、前置条件、、预期结果
    • 请求方法和URL组成请求行

接口测试中,需要先使用功能测试的分析方法分析并设计功能模块的正向和反向测试点,随后再针对接口测试的正向参数和反向参数补充用例设计

  • 登录功能测试用例
  • 用户名相关 5 条:
编号标题模块优先级前置条件协议URL请求头请求体(请求数据)预期结果
login_002用户名为空登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_003用户名包含特殊字符、字母登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_004用户名超11位(12位)登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_005用户名不足11位(10位)登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_006用户名未注册登录p2数据库中不存在的手机号POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
  • 密码相关 5 条:
编号标题模块优先级前置条件协议URL请求头请求体(请求数据)预期结果
login_007密码为空登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_008密码包含特殊字符、字母登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_009密码1位登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_010密码100位登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_011错误密码登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
  • 参数相关:
编号标题模块优先级前置条件协议URL请求头请求体(请求数据)预期结果
login_012必选参数(全部参数)登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_013多参登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_014少参(少mobile)登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
login_015无参登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json
login_016错误参数(mobile参数名错误)登录p2——POST{协议+域名}/api/sys/loginContent-Type:application/json状态码:200
  • 登录成功后返回的响应体数据中包含的data数据值就是令牌(Token),需要作为后续添加员工、查询员工、修改员工、删除员工操作的必选参数传入

3. 业务场景测试

  • 用户怎么用,业务场景就怎么设计
  • 用最少的测试用例,尽量覆盖最多的接口
分析测试点:

针对 “员工管理” 业务场景:

  • 登录 —— 添加员工 —— 查询员工 —— 修改员工 —— 再次查询 —— 删除员工 —— 查询员工列表

三、postman

1. 批量执行测试用例

此处演示的是没有数据文件时的场景,迭代次数可自由定义
  1. 若要使用postman批量执行测试用例,需要保证这些测试用例都处于同一个用例集中,随后选中要批量执行的用例集,选择Run设置
  2. 进入Runner页面后,对用例执行进行设置689
  3. 单击右下角"Run批量执行测试用例"即可

2. postman测试报告

postman插件 -- newman下载:cmd命令行输入:npm install -g newman。
newman的作用:在使用postman进行接口测试后生成测试报告。
完成newman的下载后,安装newman-reporter-html:npm install -g newman-reporter-html。这是newman插件的的子插件
  • 要生成测试报告,需要执行如下步骤:

    1. 批量执行测试用例,确保用例无误后,导出测试集数据277
    2. 打开cmd输入,使用newman命令,运行导出的测试集数据:
      c
      newman run 测试脚本文件 -e 环境变量文件 -d 测试数据文件 -r html --reporter-html-export report.html
      
      eg:
       newman run demo.postman_collection.json -r html
       newman run demo.postman_collection.json -r html --reporter-html-export report.html

    // 在生成测试报告之前,可以先测试一下newman是否能正常运行 newman run xxx.json ``` - run xxx.json:表示要执行的postman脚本,即:导出的数据集 - -e source:用来指定环境变量文件的路径(没有可不写) - -d source:用来指定测试数据文件的路径(没有可不写) - report.html:生成一个名为report(可改名)的html文件,该文件就是测试报告

    • 如果添加-r html就报错,说明newman-reporter-html安装失败

贡献者

The avatar of contributor named as freeway348 freeway348

文件历史

撰写