测试--测试用例(设计测试⽤例的⽅法 http格式)-CSDN博客

本文链接：https://blog.csdn.net/wws7920/article/details/147988598

1.设计测试⽤例的万能公式

设计测试用例的万能公式:

功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全性测试

除了万能公式之外，还有⼀个⽐较常⽤的测试类型：弱⽹测试、安装卸载测试

1. 功能测试（Function Testing）

🔹 作用：

验证软件是否实现了需求文档中定义的功能，是否“能做”。

🔹 举例：

微信登录页面输入正确手机号+验证码 → 能成功进入主页面。
智能门锁输入指纹 → 门能正常打开。

2. 界面测试（UI Testing）

🔹 作用：

验证软件界面是否美观、符合设计图和用户操作逻辑，是否“好看好点”。

🔹 举例：

微信的“登录”按钮是否居中、可点击、颜色符合设计图。
门锁App的指纹录入界面图标、字体是否清晰、无错位。

3. 性能测试（Performance Testing）

🔹 作用：

评估软件在高负载、高并发或资源消耗下的表现，是否“跑得快、扛得住”。

🔹 举例：

淘宝在双11高峰期，服务器是否能处理百万请求而不崩溃。
智能门锁连续识别50次指纹是否卡顿或过热。

4. 兼容性测试（Compatibility Testing）

🔹 作用：

验证软件是否能在不同设备、系统、浏览器、网络环境下正确运行。

🔹 举例：

QQ可以在安卓、小米、苹果手机上都能安装打开。
门锁App在iOS 15、16 和 Android 12 上都能正常控制门锁。

5. 易用性测试（Usability Testing）

🔹 作用：

检验产品对用户来说是否易学、易操作、易理解，是否“上手快”。

🔹 举例：

从未使用过支付宝的新手能否在3分钟内学会扫码付款。
新用户能否顺利通过门锁App引导完成指纹设置。

6. 安全性测试（Security Testing）

🔹 作用：

验证软件是否存在信息泄露、权限越界、漏洞攻击等问题。

🔹 举例：

网站是否防止SQL注入：?id=1 OR 1=1 不会泄露数据。
普通用户是否可以访问管理员功能（越权问题）。
门锁是否通过加密通信，防止蓝牙被中间人劫持。

7. 弱网测试（Poor Network Testing）

🔹 作用：

测试在网络差、断网、延迟高等弱网环境下，系统是否能稳定、友好地处理问题。

🔹 举例：

滴滴打车App在地铁没信号时，是否会卡死、丢数据。
门锁远程开锁时网络信号差 → 是否有超时提示、断线重连。

8. 安装卸载测试（Install/Uninstall Testing）

🔹 作用：

测试应用在安装、升级、卸载过程中的行为是否稳定、数据是否保留或清除得当。

🔹 举例：

升级微信版本后，聊天记录仍然保留。
卸载门锁App后重装 → 是否保留绑定记录，或是否重新登录。

测试类型	作用简述	示例
功能测试	能不能用、对不对	登录成功、开锁正确
界面测试	好不好看、好不好点	按钮显示正确、无错位
性能测试	快不快、抗不抗压	并发100人下单不卡
兼容性测试	换环境会不会错	安卓+iOS都能运行
易用性测试	新人会不会用	第一次打开能顺利完成设置
安全性测试	会不会被攻破	是否防止SQL注入、越权
弱网测试	网差时还能不能用	弱网能否重连、显示错误提示
安装卸载测试	安装、升级、卸载是否异常	升级保数据，卸载清干净

2.具体的设计⽅法

1.等价类

测试点：填写名字字段要求：字符数要在6~15位，且为字符类型。

所有字符组成的情况，都要测一遍吗？不，这样永远测不完。

我们要把无限的情况分为有限的等价类，每类只选一个代表值测试，既减少用例数量，又提升覆盖率，是黑盒测试中性价比最高的方法之一。

eg.分为两个等价类 1.有效等价类 (字符类型且字符数在6~15) 2.无效等价类 (字符数<6||字符数>15||存在非字符类型)

1. 有效等价类（满足规则）

编号条件
E1 字符串长度在 6–15 之间，纯字符，非空

2. 无效等价类（不满足规则）

编号条件
I1 为空（未输入）
I2 长度 < 6（如5位、3位）
I3 长度 > 15（如16位、20位）
I4 含有非字符（如数字、符号、空格等）

大大减少了测试用例数量，能覆盖绝大多数输入组合逻辑。

编号	条件
E1	字符串长度在 6–15 之间，纯字符，非空

编号	条件
I1	为空（未输入）
I2	长度 < 6（如5位、3位）
I3	长度 > 15（如16位、20位）
I4	含有非字符（如数字、符号、空格等）

2.边界值

边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。

错误往往发生在边界附近，而不是在等价类的中间值。

还是上面的例子有效数据的范围是[6,15]

边界值为 6 15 (全有效数据)

次边界值 5 16 (全无效数据)

把这两个测试用例当作等价类的补充

次边界值为边界值的左值或者右值，具体看边界值是有效还是无效数据。

eg. (6,15] 范围的边界值和次边界值为？

边界值 6(无效) 15(有效)

次边界值 7(有效) 16(无效)

3.正交法

正交法（Orthogonal Array Testing）是一种覆盖输入条件组合的最优选择策略。它不穷举所有组合，而是用尽量少的用例，覆盖所有“两两因子组合”。

项目说明
减少测试用例数量比如 5 个字段，每个两个选项 → 全组合是 2⁵=32；正交法只要 8 条用例
保证测试覆盖度尽可能覆盖所有参数的两两组合
提高效率避免重复劳动与低价值组合测试

项目	说明
减少测试用例数量	比如 5 个字段，每个两个选项 → 全组合是 2⁵=32；正交法只要 8 条用例
保证测试覆盖度	尽可能覆盖所有参数的两两组合
提高效率	避免重复劳动与低价值组合测试

现在我们有5个选项，分别是，姓名、电⼦邮箱、密码、确认密码、验证码，可以选择填或者不填。这样按照排列组合设计出来的⽤例是32个。

如图最简单的正交表是L(4)(2(3))，含意如下：“L”代表正交表；L 下⻆的数字“4”表⽰有 4 横⾏，简称⾏，即要做四次试验；括号内的指数“3”表⽰有3 纵列，简称列，即最多允许安排的因素是3个；括号内的数“2”表⽰表的主要部分只有2 种数字，即因素有两种⽔平1与2。

正交表的构成：因素数、⽔平数、⾏数。
因素：对指标的影响条件，通常是正交表中的⼀列。(名电⼦邮箱密码确认密码验证码)
⽔平：因素对应的可选项。(填不填)

正交表的性质：
• 每⼀列中，不同的数字出现的次数相等。
• 任意两列中数字的排列⽅式⻬全⽽且均衡

怎么用正交法怎么设计测试用例呢？借助AllPairs 工具

1.先找出因素和水平

2.打开excel 仿造以下格式填写

3.在allparis.exe的同级目录下创建.txt文件，将上面表格的内容复制到txt文件中（注意：纯文本格式）

4.执行allparis命令

allpairs.exe new.txt > zhengjiao.txt

new.txt 是你输入的excel表格的内容

zhengjiao.txt 里面保存的就是正交表

5.根据正交表编写测试用例并补充遗漏的关键场景

4.判定表法

需求中会存在各种各样的场景，现在我们把需求改成如下的要求：
⽤⼾输⼊的账号中包含admin字符，或者通过内部链接进⼊注册⻚⾯，提交注册按钮成为管理员⾝份；反之⽆管理员⾝份。

通过这个需求可以看出，不同的组合操作可能对应不同的结果。采⽤正交法⽆法解决这样的问题。⽽正交法能够解决需要考虑输⼊之间的组合关系对应不同结果的场景。

判定表
判定表是⼀种表达逻辑判断的⼯具，形如：

通过该图，可以把所有条件对应的结果清晰的表达出来。我们就需要借助该表来清晰的写出测试⽤例。
根据判定表法设计测试⽤例的步骤：
1. 确认需求中输⼊条件和输出条件
2. 找出输⼊条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试⽤例

确认了步骤后，我们使⽤判定表法进⼀步对上述需求进⾏测试⽤例的设计：
1. 确认需求中输⼊条件和输出条件
输⼊条件：账号包含admin字符（a）、内部注册链接(b)、点击注册按钮(c)
输出条件：管理员（1）、⽆管理员（2）
2. 找出输⼊条件和输出条件之间的关系
输⼊条件：ac ab bc abc a b c ⾮abc
对应结果: 1 2 1 1 2 2 2 2
3. 画判定表
4. 根据判定表编写测试⽤例

a. 账号包含admin，⾮内部注册链接，点击注册按钮，为管理员⾝份
b. 账号包含admin，内部注册链接，不点击注册按钮，⾮管理员⾝份
c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员⾝份
d. 账号包含admin，内部注册链接，点击注册按钮，为管理员⾝份
e. 账号包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
f. 账号不包含admin，⾮内部注册链接，点击注册按钮，⾮管理员⾝份
g. 账号不包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份

项目	正交法	判定表法
参数数量多时	非常合适，避免全排列爆炸问题	不适合太多条件（规则会指数级增长）
逻辑规则复杂时	不适用（不体现逻辑判断）	非常合适，能清晰描述“若...则...”类型规则
典型场景	浏览器 × 操作系统 × 网络环境等组合测试	审核流程、会员规则、折扣逻辑等条件判断系统

正交法：关注组合覆盖率；判定表法：关注条件逻辑判断。

5.场景法

场景法是一种模拟真实用户操作流程中的可能路径（包括正常+异常+备选），以完整测试系统功能、交互与边界情况的方法。

类型定义举例
✅ 基本流（Basic Flow） 正常操作流程，最理想路径输入账号密码 → 注册成功
🔄 备选流（Alternative Flow） 某一步有多种可能选择邮箱重复 → 换一个再注册
⚠ 异常流（Exception Flow） 不满足前置条件或出错中断网络异常、验证码失效
❓ 假设流（Hypothetical Flow） 非常规边界推测，极端情况邮箱确认被劫持，邮箱伪造

类型	定义	举例
✅ 基本流（Basic Flow）	正常操作流程，最理想路径	输入账号密码 → 注册成功
🔄 备选流（Alternative Flow）	某一步有多种可能选择	邮箱重复 → 换一个再注册
⚠ 异常流（Exception Flow）	不满足前置条件或出错中断	网络异常、验证码失效
❓ 假设流（Hypothetical Flow）	非常规边界推测，极端情况	邮箱确认被劫持，邮箱伪造

场景法测试设计步骤

确定基本流：描述核心主流程

发散备选流：找出每个步骤的替代走法

列出异常点：如失败提示、超时、网络问题

编写测试用例：以场景+路径方式逐条补充

eg.编写测试⽤例：
1.输⼊正确的账号密码，点击注册后系统发出确认邮件并在24H内确认，注册成功。
2.不输⼊账号密码，点击注册，提⽰重新输⼊
3.只输⼊账号，不输⼊密码，点击注册，提⽰重新输⼊
4......

场景法 = 基本流 + 发散可能性 + 每一步异常覆盖

区别点	场景法	判定表法
是否重顺序	✅ 重视操作顺序，逐步推进	❌ 条件判断是无序的，只关心组合
测试结构	行为链条、流程图、步骤列表	二维逻辑表（条件+行为）
侧重点	用户路径流畅与否，是否中断	所有输入条件是否对应正确输出

判定表法 = 逻辑覆盖场景法 = 流程覆盖

6.错误猜测法

错误猜测法是一种基于经验、直觉、对系统设计理解的测试方法，测试人员预判出系统可能出错的点，有目的地设计测试用例去触发 bug.

它强调的是：

设计上容易疏漏的地方

常见历史 bug 模式

用户输入习惯造成的潜在风险

数据异常路径或特殊字符场景

方法	核心思想	适用场景
等价类	输入按规则分类	有明确输入规则的场景
边界值	错误常在边界附近	输入有限且有范围
判定表	多条件 → 多结果	多条件组合触发不同行为
正交法	多输入 → 尽可能组合	提高组合覆盖，控制用例量
场景法	模拟真实操作流程	适合多步骤用户路径
错误猜测法	基于经验的“拍脑袋”式策略	经验丰富时更容易发现隐藏点

总结：

编号	方法名	核心思想	最适合的场景	记忆口诀
1	等价类划分	有效 + 无效数据代表全体	表单输入、接口参数验证（输入值可分类的场景）	一类选一个，代表全体
2	边界值分析	边界最容易出错	年龄/金额/数量/长度/时间等上下限敏感的输入字段	边界有坑，必测上下
3	正交法	参数组合最小化测试	多配置、多参数组合（如浏览器×操作系统×网络等）	组合太多，用表挑对
4	判定表法	条件+动作=逻辑关系矩阵	复杂业务规则判断（如发券、权限、价格计算、审批）	逻辑复杂，全表搞定
5	场景法	按用户行为路径设计步骤链	系统流程测试、业务链路测试（如发布文章、购物下单等）	流程走一遍，路径都覆盖
6	错误推测法	经验猜测可能出错点	对已有功能做补充测试（如特殊字符、空输入、多次点击）	经验老司机，专挑漏洞点

等价类：输入手机号 → 测试合法号码、字母、空值

边界值：输入年龄 → 测试 0、1、120、121

正交法：测试不同浏览器 + 网络类型 + 分辨率

判定表：是否发放优惠券 = 是否会员 × 是否首单 × 是否满额

场景法：用户登录→搜索→加入购物车→支付

错误推测法：试试“SQL注入”、“Emoji表情”、“快速多点”

3.具体测试

1.登录页面测试用例清单

2.zip 命令行程序测试用例设计

测试类型	测试点	输入/操作示例	预期结果
功能测试	压缩单个普通文本文件	`zip test.zip a.txt`	生成 test.zip，包含 a.txt
功能测试	压缩图片/视频文件	`zip test.zip img.png video.mp4`	正常压缩，无报错
功能测试	压缩已是 zip 的文件	`zip test2.zip test.zip`	生成二级压缩包
功能测试	压缩混合类型文件	`zip all.zip a.txt b.jpg c.pdf`	所有文件均被包含
功能测试	压缩空文件夹	`zip -r empty.zip ./empty_folder`	生成 zip 文件，内容为空结构
功能测试	命令错误（缺参数）	`zip` / `zip test.zip`	报错提示缺参数
功能测试	使用选项（如 -r）	`zip -r test.zip folder/`	递归压缩目录成功

界面测试	正常压缩提示	执行 `zip` 命令压缩多个文件	命令行输出“adding...”提示美观、对齐
界面测试	错误压缩提示	输入非法路径	提示“file not found”或“no such file”清晰准确

性能测试	压缩大文件（>1GB）	压缩 `video.mp4 (1.5G)`	成功生成 zip，系统未死机
性能测试	测压时间	使用 `time zip large.zip large_file`	输出耗时在合理范围内（如 < 2 分钟）

兼容性测试	在 Linux 下使用	`zip demo.zip a.txt`	成功压缩
兼容性测试	在 Windows CMD 下使用	`zip demo.zip a.txt`	若环境配置正确，可压缩
兼容性测试	在 Mac 下使用	`zip demo.zip a.txt`	命令一致，压缩成功

易用性测试	使用 `zip --help`	查看帮助文档	输出所有支持参数与说明
易用性测试	错误提示是否有建议	错误命令如 `zip -z`	提示说明参数错误，附加建议

安全性测试	检查信息泄漏	`zip test.zip file.txt`	zip 文件未包含敏感系统路径
安全性测试	临时文件处理	压缩中中断或失败	无残留临时文件或信息泄漏

类型	测试点
边界测试	压缩文件名长度接近最大（255字节）是否正常
压缩密码保护	测试 `zip -e` 生成的压缩包能否正确输入密码
解压验证	解压后内容、结构是否完整一致
语言编码兼容	文件名含中文、emoji 是否能正常压缩与解压

3.web程序

4.http格式

1.HTTP 请求格式

HTTP 请求包括三部分：请求行 + 请求头 + 请求体(可选)
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

1. 请求行（Request Line）：

<请求方法> <请求URL> <协议版本>

请求方法：

GET 获取资源（常用于访问网页、获取数据）

POST提交资源（如表单、JSON，创建新内容）

PUT 更新资源（整体替换）

请求URL:

即客户端希望访问的资源路径，写在请求行中，不包含主机名：

GET /blog/detail?id=10 HTTP/1.1
这里的 /blog/detail?id=10 就是请求 URL。

请求 URL 是“相对路径”

完整的地址（如 https://www.example.com/blog/detail?id=10）会被拆解，只有路径部分写在请求行

主机名 www.example.com 会写在请求头的 Host: 字段中

协议版本：

协议版本说明
HTTP/1.0 最早广泛使用的版本（已基本淘汰）
HTTP/1.1 目前最广泛使用，支持持久连接
HTTP/2 支持多路复用、压缩头部等，性能提升显著
HTTP/3 基于 QUIC 协议，使用 UDP 更快

eg.GET /login HTTP/1.1

名称示例值含义说明
请求方法 GET, POST, ... 客户端想对资源做什么
请求 URL /index.html?user=abc 请求的资源路径
协议版本 HTTP/1.1, HTTP/2 使用的 HTTP 协议标准

协议版本	说明
`HTTP/1.0`	最早广泛使用的版本（已基本淘汰）
`HTTP/1.1`	目前最广泛使用，支持持久连接
`HTTP/2`	支持多路复用、压缩头部等，性能提升显著
`HTTP/3`	基于 QUIC 协议，使用 UDP 更快

名称	示例值	含义说明
请求方法	`GET`, `POST`, ...	客户端想对资源做什么
请求 URL	`/index.html?user=abc`	请求的资源路径
协议版本	`HTTP/1.1`, `HTTP/2`	使用的 HTTP 协议标准

2.请求头

HTTP 请求头是指在请求行之后、请求体之前，用来传递客户端信息和请求说明的一组键值对。

eg.
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: zh-CN
Connection: keep-alive
字段说明
Host 指定目标服务器的域名（必须字段）例如：Host: www.example.com
Connection 控制是否保持 TCP 连接如：keep-alive 或 close
Cache-Control 缓存控制策略，如 no-cache, max-age=3600
Date 当前请求的时间（RFC 1123格式）

字段	说明
`Host`	指定目标服务器的域名（必须字段）例如：`Host: www.example.com`
`Connection`	控制是否保持 TCP 连接如：`keep-alive` 或 `close`
`Cache-Control`	缓存控制策略，如 `no-cache`, `max-age=3600`
`Date`	当前请求的时间（RFC 1123格式）

3. 请求体

可选

仅某些方法（如 POST、PUT）带有

包含请求传递的数据（如表单数据、JSON 数据等）
{
  "username": "user1",
  "password": "123456"
}

2.HTTP 响应格式

响应也由三部分组成：状态行 + 响应头 + 响应体
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 52
Server: nginx/1.18.0

{
  "message": "Login successful",
  "code": 200
}
组成部分内容举例作用
状态行 HTTP/1.1 200 OK 告诉客户端：结果怎么样了
响应头 Content-Type: application/json 告诉客户端：我返回了什么数据
响应体 {"code":200, "msg":"成功"} 实际的数据内容

组成部分	内容举例	作用
状态行	`HTTP/1.1 200 OK`	告诉客户端：结果怎么样了
响应头	`Content-Type: application/json`	告诉客户端：我返回了什么数据
响应体	`{"code":200, "msg":"成功"}`	实际的数据内容

1.状态行

<HTTP版本> <状态码> <状态短语>
eg. HTTP/1.1 200 OK

HTTP/1.1：使用的协议版本

200：状态码，表示请求成功

OK：状态码的文字描述（可读性好）

状态码含义描述
200 OK 请求成功
301 Moved Permanently 永久重定向
302 Found 临时重定向
400 Bad Request 客户端请求语法错误
401 Unauthorized 未授权（需登录）
403 Forbidden 拒绝访问
404 Not Found 资源不存在
500 Internal Server Error 服务器内部错误
502 Bad Gateway 网关错误
503 Service Unavailable 服务不可用

状态码	含义	描述
200	OK	请求成功
301	Moved Permanently	永久重定向
302	Found	临时重定向
400	Bad Request	客户端请求语法错误
401	Unauthorized	未授权（需登录）
403	Forbidden	拒绝访问
404	Not Found	资源不存在
500	Internal Server Error	服务器内部错误
502	Bad Gateway	网关错误
503	Service Unavailable	服务不可用

2.响应头

告诉客户端：服务器是谁、返回什么类型的内容、是否缓存、返回多大等信息。
Content-Type: application/json
Content-Length: 123
Server: nginx/1.18.0
Set-Cookie: sessionid=abc123; Path=/
字段名称示例值说明
Content-Type text/html / application/json 返回数据的 MIME 类型
Content-Length 123 响应体的字节数
Server nginx, Apache 等服务器软件信息
Set-Cookie sessionid=abc123 返回 Cookie 值
Cache-Control no-cache, max-age=600 控制缓存行为
Location https://new.url 302/301 重定向时的新地址
Access-Control-Allow-Origin * 跨域资源共享 CORS 设置

字段名称	示例值	说明
`Content-Type`	`text/html` / `application/json`	返回数据的 MIME 类型
`Content-Length`	`123`	响应体的字节数
`Server`	`nginx`, `Apache` 等	服务器软件信息
`Set-Cookie`	`sessionid=abc123`	返回 Cookie 值
`Cache-Control`	`no-cache`, `max-age=600`	控制缓存行为
`Location`	`https://new.url`	302/301 重定向时的新地址
`Access-Control-Allow-Origin`	`*`	跨域资源共享 CORS 设置

3.响应体

就是 服务器返回给浏览器的真正内容

类型由 Content-Type 决定，可能是：

类型内容示例
text/html 网页 HTML
application/json JSON 数据接口
text/plain 普通文本
image/jpeg/png/gif 图片
application/octet-stream 二进制数据、下载文件

类型	内容示例
`text/html`	网页 HTML
`application/json`	JSON 数据接口
`text/plain`	普通文本
`image/jpeg/png/gif`	图片
`application/octet-stream`	二进制数据、下载文件

5.Posman API 开发与测试工具

Postman 是一款非常流行的 API 开发与测试工具，用于发送 HTTP 请求、调试接口、编写测试用例和管理 API 项目。它是前端、后端、测试工程师的常用工具之一。

操作步骤	GET 请求	POST 请求
请求方法	GET	POST
参数填写位置	`Params` 标签页	`Body` 标签页 → raw → JSON
请求体	无请求体	有请求体（一般是 JSON 或表单）
是否要设 Header	一般不强制	通常需设置 `Content-Type: application/json`
URL 是否带参数	是（如 `?id=123`）	否（参数在 body 中）
常用于	查询数据	登录、注册、提交表单、上传等

发送一个GET请求

请求标签

标签名称	常用于	说明
Params	GET 请求	URL 查询参数
Authorization	登录态接口	设置 Token、API Key 等认证信息
Headers	所有请求	设置请求头，如 JSON 类型声明
Body	POST/PUT 请求	请求参数内容（JSON/表单）
Scripts	自动化测试	写脚本验证响应内容或设置变量
Settings	高级配置	请求行为微调，如关闭 SSL 校验

响应标签

标签	作用说明
Body	显示服务器响应的正文内容（如 JSON、HTML、XML 等）这是你最常查看的部分，用来判断接口返回了什么结果。
Cookies	显示服务器在响应中设置的 `Set-Cookie` 内容，比如 session、token 等。也可以看到已发送的 Cookie。
Headers	查看响应头信息（如 `Content-Type`、`Content-Length`、`Server` 等），用于了解返回数据格式、缓存、CORS 等。
Test Results	如果你在 `Tests` 标签页写了测试断言，这里会显示通过/失败的测试结果（Postman 脚本运行报告）。