测试用例及黑盒测试方法

一、测试用例

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. 在支付宝沙箱环境输入账号 `test@alipay.com` 和密码 `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. 等价类划分的完整步骤

2. 常见错误与改进方案

3. 等价类组合策略

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

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

组合测试设计：

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

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

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

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

需求：邮箱格式需满足 xxx@yyy.zzz，其中：

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

2.2.2 边界值

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

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

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

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

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. 边界值分析工具

工具示例：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-3：订单已提交且（金额>300 或 有红包）→ 享受优惠。
• 规则4-8：订单未提交 或 金额≤300且无红包 → 不享受优惠。

步骤4：生成测试用例

2. 判定表设计技巧

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

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

示例（权限系统）：

技巧2：合并重复动作

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

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

技巧3：处理多结果场景

示例（登录功能）：

3. 常见错误与改进方案

4. 工具辅助设计

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

2.2.4 正交表

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

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

1. 正交表核心概念

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：因素映射到列

步骤4：填充水平值

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

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

4. 正交法优势与局限

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覆盖