测试用例及黑盒测试方法

一、测试用例

1.1 基本要素

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等4个主要要素。

1.1.1 测试环境

• 定义：测试执行所需的软硬件配置、网络条件、依赖服务等。
• 示例：
  • Web 端：Chrome 浏览器 v115 + Windows 11 + 网络带宽 100Mbps
  • 移动端：iPhone 14 Pro (iOS 16.5) + 4G 网络
  • 服务端：CentOS 7.9 + JDK 11 + MySQL 8.0
• 关键点：
  • 明确区分测试环境类型（开发环境、测试环境、预发布环境）。
  • 记录第三方依赖（如支付接口的沙箱环境）。

1.1.2 操作步骤

• 定义：测试执行的详细流程，需清晰、无歧义，确保不同测试人员执行结果一致。

• 示例：

  1. 打开应用，点击【登录】按钮。
  2. 输入用户名 `test_user` 和密码 `Test@123`。
  3. 勾选【记住密码】，点击【提交】。
  

• 关键点：

  • 步骤编号化，避免复杂长句。
  • 包含前置条件（如“已注册账号”）和后置操作（如“清理测试数据”）。

1.1.3 测试数据

• 定义：测试过程中使用的输入数据，需覆盖有效、无效、边界值等场景。

• 示例：

  测试场景	测试数据
  有效用户名	user_123（长度 8）
  无效用户名	admin#（含特殊字符）
  边界值用户名	a（长度 1）

• 关键点：

  • 数据需独立维护（如通过 CSV 文件或数据库管理），便于复用和维护。
  • 敏感数据脱敏处理（如密码用 **** 替代明文）。

1.1.4 预期结果

• 定义：每个步骤执行后系统应有的正确响应，需唯一且可验证。
• 示例：
  • 界面响应：跳转至首页，显示欢迎语“Hello, test_user”。
  • 数据验证：数据库的 user 表中新增一条状态为“激活”的记录。
  • 性能指标：接口响应时间 ≤ 500ms。
• 关键点：
  • 避免模糊描述（如“系统正常运行”）。
  • 结合自动化校验点（如断言数据库字段值）。

1.2 评价标准

1.2.1 用例表达清晰，无二义性

• 问题案例：输入错误密码，检查系统是否提示错误。
• 改进后：输入密码“123”，点击登录，页面弹出提示框“密码长度需为6-20位”。
• 关键点：
  • 使用具体数值而非“错误值”等模糊描述。
  • 明确界面元素名称（如按钮 ID 或文案）。

1.2.2 用例可操作性强

• 反例：测试支付功能是否能正常扣款（缺少步骤和验证点）。

• 正例：

  1. 在订单页选择【支付宝支付】，点击【立即付款】。
  2. 在支付宝沙箱环境输入账号 `[e-mail]` 和密码 `123456`。
  3. 预期结果：- 页面跳转至“支付成功”页。- 订单状态更新为“已支付”。- 支付宝账单中显示扣款金额 100 元。
  

1.2.3 输入与输出明确

• 常见问题：一条用例包含多个预期结果（如“登录成功并跳转首页”）。
• 改进方案：
  • 拆分用例：TC-001 验证登录成功 + TC-002 验证登录后跳转逻辑。
  • 使用自动化脚本分离校验点。

1.2.4 用例可维护性好

• 实践建议：
  • 模块化设计：按功能模块管理用例（如“登录模块”、“支付模块”）。
  • 参数化数据：将易变数据（如 URL、账号）提取为配置文件。
  • 版本关联：用例与需求 ID 或用户故事绑定，便于变更追踪。

1.2.5 需求覆盖率高

• 实现方法：

  1. 需求拆解：将用户需求转化为功能点（如“支持用户名登录”）。

  2. 映射矩阵：建立需求-用例追踪表，确保每个需求有对应测试用例。

     需求 ID	需求描述	关联用例	覆盖类型
     REQ-001	用户名长度为6-15	TC-001 ~ TC-005	功能+边界值

1.3 好处

测试用例是自动化测试的基础

1.3.1 提高测试效率

• 新版本迭代时，通过历史用例快速执行回归测试，减少漏测风险。
• 利用用例步骤直接生成自动化脚本（如 Selenium 或 Postman 集合）。

1.3.2 促进团队协作

• 开发人员参考测试用例理解需求验收标准。
• 新人通过用例快速熟悉系统功能。

1.3.3 降低沟通成本

• 缺陷报告中引用用例 ID，精准定位问题场景（如“TC-005 中实际结果与预期不符”）。

二、测试用例的设计方法

2.1 基于需求设计测试用例

2.1.1 功能需求测试分析

需求规格说明书、UI设计稿、测试人员经验

1. 业务流程测试设计：

• 步骤：

  1. 根据需求规格说明书绘制流程图（如泳道图、活动图）。
  2. 识别关键节点（如提交订单、支付、退款）。
  3. 覆盖正向流程和异常分支（如库存不足、支付超时）。

• 示例（电商下单流程）：

  正向流程：浏览商品 → 加入购物车 → 填写地址 → 支付 → 订单完成  
  异常分支：  - 支付失败 → 订单状态置为“待支付”  - 地址未填写 → 弹窗提示“请填写收货地址”  
  

2. UI测试设计要点：

• 布局验证：
  • 控件对齐方式（如左对齐、居中）。
  • 响应式设计（不同屏幕分辨率下的显示效果）。
• 交互细节：
  • 焦点跳转逻辑（如按 Tab 键切换输入框顺序）。
  • 错误提示的即时性和明确性（如实时校验密码强度）。

3. 用户体验（易用性）测试：

• 测试点：
  • 快捷键支持（如 Ctrl+C/V 复制粘贴）。
  • 页面加载时的加载动画（避免用户误以为卡顿）。

2.1.2 非功能需求测试分析

1. 兼容性测试：

• 浏览器兼容性：
  • 内核差异：Chrome（Blink）、Firefox（Gecko）、Safari（WebKit）。
  • 测试工具：BrowserStack、Selenium Grid。
• 移动端兼容性：
  • 分辨率适配：iPhone 14 Pro Max（2796×1290） vs. 折叠屏（2208×1768）。
  • 操作系统版本：Android 13 权限控制 vs. iOS 16 隐私标签。

2. 性能测试（补充指标）：

• 前端性能：
  • 首屏加载时间 ≤ 2秒（Web 端）。
  • FPS（帧率） ≥ 60（移动端动画流畅度）。
• 后端性能：
  • 接口 99% 请求响应时间 ≤ 1秒（P99 指标）。
  • 每秒事务数（TPS） ≥ 1000（高并发场景）。

3. 安全测试（渗透测试补充）：

• OWASP Top 10 覆盖：
  • SQL 注入：' OR 1=1 -- 攻击防御。
  • XSS 攻击：输入 <script>alert(1)</script> 检测过滤机制。
• 敏感数据保护：
  • 日志中禁止记录明文密码。
  • HTTPS 传输加密（TLS 1.3 协议）。

4. 网络测试（弱网模拟工具）：

• 工具：Charles 网络限速、Android Emulator 网络模拟。
• 测试场景：
  • 100% 丢包率下，检查本地缓存是否生效。
  • 2G 网络（50kbps）下，图片懒加载功能是否正常。

2.2 黑盒设计方法

2.2.1 等价类

又分成有效等价类和无效等价类。

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。

无效等价类：根据需求说明书，不满足需求的集合。

1. 等价类划分的完整步骤

步骤	说明	示例（用户名规则：6-15位字母，不区分大小写）
1. 分析需求，确定输入域	明确输入参数的类型、范围和约束条件。	输入类型：字符串； 长度范围：6-15位； 字符类型：仅A-Z/a-z。
2. 划分有效等价类	识别符合需求的有效输入组合。	- 有效字符：A-Z或a-z - 有效长度：6位、10位、15位。
3. 划分无效等价类	识别所有可能违反需求的无效输入类型。	- 无效字符：数字、特殊字符、空格、中文等 - 无效长度：5位、16位、空字符串。
4. 设计测试用例	每个等价类选取至少1个代表值生成用例。	有效用例："TestUser"（8位字母） 无效用例："User123"（含数字）、"Admin#"（含特殊字符）。
5. 补充边界值用例	结合边界值分析法覆盖临界场景。	长度边界："Abcdef"（6位）、"A...z"（15位）。

2. 常见错误与改进方案

错误类型	问题案例	改进方案
等价类遗漏	仅测试字母和数字，忽略特殊字符。	穷举所有无效类型：数字、符号、空格、Emoji、SQL语句等。
用例冗余	对同一等价类多次测试（如测试多个特殊字符）。	每个等价类仅保留1个典型用例（如 "User@" 代表所有特殊字符）。
组合缺失	未覆盖等价类组合（如无效字符+超长长度）。	结合正交法或判定表设计组合用例（如 "Admin@1234567890" 含特殊字符且超长）。

3. 等价类组合策略

场景：注册功能需验证用户名和密码规则

• 用户名规则：6-15位字母。
• 密码规则：8-20位，必须包含字母和数字。

字段	有效等价类	无效等价类
用户名	"TestUser"	"User123"（数字）
密码	"Pass1234"	"password"（无数字）

组合测试设计：

• 有效组合：有效用户名 + 有效密码 → 注册成功。
• 无效组合：
  • 无效用户名 + 有效密码 → 提示用户名错误。
  • 有效用户名 + 无效密码 → 提示密码格式错误。

4. 输出等价类设计（扩展场景）

需求：根据分数返回评级（A: ≥90，B: 70-89，C: <70）

输出等价类	分数范围	测试数据	预期结果
有效输出A	90-100	95	评级A
有效输出B	70-89	85	评级B
有效输出C	0-69	60	评级C
无效输出	<0或>100	-5, 105	提示错误

5. 实战案例：邮箱格式验证

需求：邮箱格式需满足 [e-mail]，其中：

• xxx：1-64位字母/数字/点/下划线。
• yyy：1-255位字母/数字/连字符。
• zzz：2-6位字母。

输入域	有效等价类	无效等价类	测试用例示例
用户名	"user.name_123"	"user@#"（含非法字符）	"[e-mail]"
域名	"example-123"	"exa_mple"（含下划线）	"user@exa_mple.com"
顶级域名	".com"（2位）	".a"（1位）、".abcdefg"（7位）	"user@domain.a"

2.2.2 边界值

通常边界值分析法是作为对等价类划分法的补充。

1. 边界值分析的核心概念

概念	定义	示例（用户名长度规则：6-15位）
上点	输入域的边界值（即有效与无效的分界点）	6位、15位
内点	输入域内任意一个有效值（通常取中间值）	10位
离点	距离上点最近且不属于有效范围的无效值（闭区间与开区间规则不同）	5位（闭区间左离点）、16位（闭区间右离点）

2. 不同区间类型的离点选择规则

区间类型	上点选择	离点选择规则（以区间 [a, b] 为例）	示例（取值范围）	离点计算
闭区间 [a, b]	a、b	离点为 a-1 和 b+1，域外	[6, 15]	5、16
开区间 (a, b)	a、b	离点为 a+1 和 b-1，域内	(6, 15)	7、14
半开半闭区间	根据开闭方向调整	如 [a, b)：离点为 a-1 和 b-1	[6, 15)	5、14

3. 边界值分析的完整步骤

步骤	操作说明	用户名长度示例（[6, 15]位）
1. 确定输入域边界	明确需求中数值、长度、时间等范围的上下限。	最小长度6位，最大长度15位
2. 识别上点、内点、离点	按区间类型计算三类点。	上点：6、15；内点：10；离点：5、16
3. 设计测试用例	每个边界点至少生成1个用例，覆盖有效和无效场景。	有效用例：6位、10位、15位；无效用例：5位、16位
4. 扩展多字段组合	若存在多个输入字段，需覆盖边界值的组合（如用户名长度+字符类型边界）。	用例：6位纯字母（有效） vs. 6位含数字（无效）

4. 复杂场景下的边界值设计

场景1：时间范围边界（跨天/跨月）

• 需求：允许选择2023-01-01至2023-12-31的日期。
• 边界用例：
  • 上点：2023-01-01、2023-12-31
  • 离点：2022-12-31、2024-01-01

场景2：多字段联合边界（折扣计算）

• 需求：订单金额 ≥100元且商品数量 ≥3件，可享受9折。
• 边界用例：
  • 金额99元 + 数量3件 → 无折扣
  • 金额100元 + 数量2件 → 无折扣
  • 金额100元 + 数量3件 → 折扣生效

5. 常见错误与改进方案

错误类型	问题案例	改进方案
遗漏边界类型	仅测试数值边界，忽略字符串空值。	穷举所有边界类型（空值、超长文本、特殊字符）。
错误计算离点	对开区间 (6,15) 测试5位和16位。	严格按区间类型选择离点（开区间离点为6和15）。
忽略多字段组合边界	单独测试长度和字符，未组合验证。	使用正交法生成组合用例（如6位+特殊字符）。

6. 边界值分析工具

工具示例：Boundary Value Checker

• 输入规则：定义字段类型、范围、步长（如数值型字段范围[1-100]，步长1）。

• 自动生成：工具输出所有上点、离点和内点用例。

• 输出示例：

  字段	测试数据	类型
  年龄	0	离点
  年龄	1	上点
  年龄	50	内点
  年龄	100	上点
  年龄	101	离点

7. 边界值与等价类法的结合策略

1. 先用等价类划分输入域：将用户名输入分为有效字母、无效字符等等价类。

2. 对每个等价类应用边界值：在字符类型有效等价类中，测试长度边界（如6位字母、15位字母）。

3. 生成综合用例：

   等价类	边界值用例	预期结果
   有效字母	6位字母（“Abcdef”）	注册成功
   无效特殊字符	6位含@符号（“User@@”）	提示“含非法字符”

8. 边界值分析法局限性

• 不覆盖组合缺陷：无法发现多个字段非边界值组合引发的问题（需结合判定表）。
• 不适用于连续型数据：如浮点数边界（需额外考虑精度问题，如0.999999≈1.0）。

2.2.3 因果图/判定表

因果图与判定表是处理 多条件逻辑组合 场景的核心方法，尤其适用于规则复杂的业务逻辑（如促销活动、权限控制）。

1. 因果图/判定表完整流程

步骤1：识别输入（因）与输出（果）

• 输入（条件桩）：所有可能影响结果的独立条件。
• 输出（动作桩）：系统应有的响应或动作。

示例（618购物优惠规则）：“618购物活动，订单已提交，订单合计金额大于300元或有红包，则优惠”。

• 输入：订单已提交、金额>300元、有红包。
• 输出：享受优惠。

步骤2：构建因果图（逻辑关系可视化）

• 基本逻辑符号：
  • 恒等（→）：条件为真 → 结果为真
  • 非（¬）：条件为假 → 结果为真
  • 或（∨）：任一条件为真 → 结果为真
  • 与（∧）：所有条件为真 → 结果为真

618购物优惠因果图：

订单已提交 ∧ (金额>300 ∨ 有红包) → 享受优惠

步骤3：转换为判定表（穷举所有规则）

• 条件组合数：n 个条件 → 2^n 种组合（需合并无效场景）。
• 618购物案例判定表：

条件桩	规则1	规则2	规则3	规则4	规则5	规则6	规则7	规则8
订单已提交	Y	Y	Y	Y	N	N	N	N
金额 >300元	Y	Y	N	N	Y	Y	N	N
有红包	Y	N	Y	N	Y	N	Y	N
动作桩
享受优惠	Y	Y	Y	N	N	N	N	N

合并简化规则：

• 规则1-3：订单已提交且（金额>300 或 有红包）→ 享受优惠。
• 规则4-8：订单未提交 或 金额≤300且无红包 → 不享受优惠。

步骤4：生成测试用例

用例ID	订单状态	金额	红包	预期结果
TC1	已提交	400元	有	享受优惠
TC2	已提交	400元	无	享受优惠
TC3	已提交	200元	有	享受优惠
TC4	已提交	200元	无	不享受优惠
TC5	未提交	400元	有	不享受优惠

2. 判定表设计技巧

技巧1：条件优先级与默认值

• 条件优先级：某些条件可能覆盖其他条件（如“管理员权限”优先于普通用户）。
• 默认值标记：用 - 表示条件无关（减少冗余组合）。

示例（权限系统）：

条件桩	规则1	规则2	规则3
是管理员	Y	N	N
有访问权限	-	Y	N
动作桩
允许访问	Y	Y	N

技巧2：合并重复动作

• 动作合并：不同条件组合导致相同结果时，合并规则。
  示例（合并购物规则4-8）：

  条件桩	有效规则	无效规则
  订单已提交	Y	N
  金额>300 或 有红包	Y	N
  享受优惠	Y	N

技巧3：处理多结果场景

示例（登录功能）：

条件桩	规则1	规则2	规则3
用户名有效	Y	Y	N
密码有效	Y	N	-
动作桩
跳转首页	Y	N	N
提示密码错误	N	Y	N
提示用户名不存在	N	N	Y

3. 常见错误与改进方案

错误类型	问题案例	改进方案
条件遗漏	未考虑“订单已提交”状态导致错误优惠。	需求分析阶段识别所有显性和隐性条件。
动作歧义	多个动作同时触发但未定义优先级（如弹窗冲突）。	明确动作执行顺序（如先校验再提交）。
规则冗余	重复测试相同逻辑组合（如规则1和规则2完全相同）。	合并相同输出的规则。

4. 工具辅助设计

• 在线判定表生成器：
  输入条件和动作，自动生成所有组合（如 Decision Table Tester）。
• Excel 公式：
  使用条件公式（如 IF(AND(A2="Y", OR(B2="Y", C2="Y")), "Y", "N")）快速填充判定表。

2.2.4 正交表

正交排列法（Orthogonal Array Testing）是高效覆盖多参数组合的核心技术，特别适合参数多但组合爆炸的场景。

以下以用户注册功能为案例进行讲解，考虑以下5个因素（用户名、邮箱、密码、确认密码、验证码）

1. 正交表核心概念

术语	定义	示例（用户注册功能）
因素	测试中需要验证的独立变量	用户名、密码、验证码
水平	每个因素可能的取值	填写/不填写
正交表	满足"任意两列组合均衡"的特殊矩阵	$L_4(2^3)$
行数(N)	测试用例数量（最少组合数）	4行
因素数©	变量个数	5（用户名、邮箱、密码、确认密码、验证码）
水平数(T)	每个变量的取值数量	2（填写/不填写）

2. 正交表表示法

• 通用格式：$L_N(T^C)$

3. 正交表设计五步法

步骤1：需求分析 → 提取因素和水平

因素：- 用户名：填写/不填写- 邮箱：填写/不填写- 密码：填写/不填写- 确认密码：填写/不填写- 验证码：填写/不填写

步骤2：选择正交表

• 选择原则：

• 正交表列数 ≥ 实际因素数	正交表必须能容纳所有因素
  正交表水平数 ≥ 因素水平数	水平数需匹配或可映射
  最小化行数	在满足组合均衡前提下选最小N

• 对于 $C$ 个因素 且每个因素有 $T$ 个水平 的场景，完整约束为

  • $$\{\begin{array}{ll}N\ge 1+C(T-1)& \text{（最小行数约束）}\\ N\equiv 0(\mathrm{mod}\lambda )& \text{（组合均衡约束）}\end{array}$$

  • $\lambda$ 为均衡系数：二水平时 $\lambda =4$

• 本案例：$T=2,C=5$

  • $1+5\times (2-1)=6$
  • 但 $6\not\equiv 0(\mathrm{mod}4)$ → 无解
  • 最小满足 $N\equiv 0(\mathrm{mod}4)$ 且 $N>6$ → $N=8$

  ✅ 正确结论：$L_8(2^7)$ 是数学约束下的唯一可行解

步骤3：因素映射到列

列号	1	2	3	4	5	6	7
因素	姓名	邮箱	密码	确认	验证	(空)	(空)

步骤4：填充水平值

用例	姓名	邮箱	密码	确认密码	验证码
1	1	1	1	1	1
2	1	1	1	2	2
3	1	2	2	1	2
4	1	2	2	2	1
5	2	1	2	2	1
6	2	1	2	1	2
7	2	2	1	2	2
8	2	2	1	1	1

• 水平映射：1：填写；2：未填写

步骤5：转换为可执行用例

用例	姓名	邮箱	密码	确认密码	验证码	预期结果
TC1	填写	填写	填写	填写	填写	注册成功
TC2	填写	填写	填写	不填写	不填写	提示"确认密码未填写"
TC3	填写	不填写	不填写	填写	不填写	提示"邮箱未填写"
…	…	…	…	…	…	…

4. 正交法优势与局限

优势	局限
✅ 用例数从$2^5=32$减至8（-75%）	❌ 不覆盖三三组合缺陷
✅ 保证所有两两组合被覆盖	❌ 水平数不同时需特殊处理
✅ 适合配置项、兼容性测试等场景	❌ 业务逻辑复杂时需结合判定表

2.3 万能测试用例模板

1. 功能测试
   • 核心流程验证： 登录/支付/提交等关键路径
   • 异常处理： 空输入、重复提交、非法操作
   • 数据一致性： DB字段校验、状态同步
   • 边界值覆盖： 数值、长度、时间临界点
2. 性能测试
   • 响应时间： 单操作≤1s，复杂操作≤3s
   • 并发能力： 最大用户数、TPS阈值
   • 资源消耗： CPU≤80%、内存≤90%
   • 稳定性： 持续运行12小时无故障
3. 界面测试
   • 布局规范： 间距对齐、字体统一
   • 交互反馈： 加载动画、错误提示
   • 响应式： 手机/平板/PC自适应
   • 视觉验收： 颜色对比度≥4.5:1
4. 兼容性测试
   • 浏览器： Chrome/Firefox/Safari/Edge
   • 操作系统： Win11/macOS Ventura/Ubuntu 22.04
   • 移动端： iOS 16+/Android 13+主流机型
   • 分辨率： 720P/1080P/2K/4K/折叠屏
5. 易用性测试
   • 操作路径： 核心功能≤3步完成
   • 指引设计： 新手指引/空白页提示
   • 快捷键： Ctrl+S保存/Enter提交
   • 文案清晰： 错误提示含解决方案
6. 网络测试
   • 弱网模拟： 3G(500kbps)/高延迟(500ms)，比如高延迟+低带宽 → 模拟偏远地区；低延迟+高丢包 → 模拟地铁场景
   • 断网恢复： 自动重连/数据同步
   • 协议验证： HTTPS/TLS1.3加密
   • 流量优化： 图片懒加载/API合并
7. 安全测试
   • 注入攻击： SQL/XSS/命令注入
   • 权限控制： 越权访问/垂直权限
   • 数据安全： 密码加密/日志脱敏
   • 漏洞扫描： OWASP Top 10覆盖