测试
测试
测试技能
- 功能测试
- 自动化测试
- 接口测试
- 性能测试
- 总结
测试分类
- 按测试阶段划分
- 按代码可见度划分
- 总结
模型
- 质量模型
测试流程
测试用例
一、什么是用例
广义的 “用例”，是为达成某个特定目标、场景而设计的一系列操作步骤、条件及预期结果的集合，可应用于不同领域。像业务流程梳理里，用于描述用户办理业务的流程步骤；在软件测试场景中，聚焦软件功能验证，进而延伸出 “测试用例” 。简单来说，它是一种规范化、结构化描述 “怎么做以及期望怎样” 的文档或概念 。
二、什么是测试用例
在软件测试领域，测试用例是为验证软件某一功能（或特性）、模块，预先设计的详细测试方案 ，包含输入数据、操作步骤、预设环境、预期结果等要素 。比如测试电商 App 购物车 “添加商品” 功能，测试用例要写清：在登录状态、网络正常环境下，点击商品详情页 “加入购物车” 按钮（操作），输入商品数量（如 1 件，输入数据 ），预期购物车数量更新、商品信息正确显示（预期结果 ） 。通过这种精准设计，覆盖软件功能验证点，找出潜在缺陷 。
三、用例的作用
- 指导测试执行：测试人员按用例步骤、数据操作，避免测试遗漏、随意性，让测试过程标准化 。
- 发现软件缺陷：清晰的输入、预期结果对比，能快速识别实际结果与预期不符的情况，精准定位问题 。
- 评估测试覆盖率：通过梳理用例覆盖的功能点、场景，判断是否覆盖软件需求（如功能需求、非功能需求 ），评估测试完整性 。
- 回归测试依据：软件迭代更新后，复用历史用例执行回归测试，验证修改是否引入新问题、原有功能是否正常 。
- 团队协作与知识传承：用例是需求、测试、开发沟通的 “共同语言” ，新成员也能通过用例快速了解测试重点 。
四、用例编写格式（常用模板，可灵活调整 ）
| 用例编号 | 测试模块 / 功能 | 测试标题 | 前置条件 | 测试步骤 | 预期结果 | 实际结果 | 测试人员 | 测试时间 |
|---|---|---|---|---|---|---|---|---|
| TC-001 | 电商 App - 购物车 | 验证添加商品到购物车功能 | 1. 手机已安装目标 App 2. 用户已登录 3. 网络连接正常 | 1. 打开 App，进入商品详情页（如某款手机详情 ） 2. 点击 “加入购物车” 按钮 3. 在购物车弹窗，输入购买数量（如 2 台 ），点击 “确认” | 1. 购物车页面数量显示为 2 2. 商品名称、价格、数量与选择一致 3. 底部 “去结算” 按钮可点击 | 待测试执行后填写 | [测试人员姓名] | [具体日期，如 2025-08-01] |
说明：
- 用例编号：唯一标识，方便管理、检索，如按模块 + 序号规则（TC 代表 Test Case ）。
- 测试模块 / 功能：明确归属，便于分类、筛选。
- 测试标题：简洁概括测试点（如 “验证登录功能 - 密码错误提示” ）。
- 前置条件：执行用例前需满足的环境、状态（如登录状态、网络要求、数据准备 ）。
- 测试步骤：清晰、有序的操作流程，步骤要具体可执行 。
- 预期结果：基于需求，明确、可验证的期望输出（不能模糊，要量化、精准 ）。
- 实际结果：测试执行后填写，对比预期判断是否通过 。
- 测试人员 & 时间：记录执行信息，方便追溯 。
划分测试点
一、等价类划分法
（一）核心思想
将输入数据（或操作场景）划分为若干 “等价类”，每个等价类内的测试数据具有相同测试效果。只需选取**代表性数据 ** 测试，即可覆盖该类所有情况，减少用例数量。
（二）示例（以 “年龄输入框，要求 18 - 60 岁” 为例）
-
有效等价类：18≤年龄≤60（如
25 岁、40 岁） -
无效等价类：
- 年龄 < 18（如
15 岁） - 年龄 > 60（如
65 岁） - 非数字（如
“abc”）
- 年龄 < 18（如
测试时，从每个等价类选 1 - 2 个数据验证，即可覆盖该类逻辑。
（三）作用
-
大幅减少测试用例数量，避免冗余测试。
-
聚焦关键边界与规则，优先覆盖核心逻辑。
二、边界值分析法
（一）核心思想
软件对 “边界值”（如输入范围的最小值、最大值、临界值 ）更敏感，易出现缺陷。专门针对**边界点及附近值 ** 设计用例，补充等价类划分法的不足。
（二）示例（以 “密码长度 6 - 16 位” 为例）
- 边界值：
6 位、7 位、15 位、16 位 - 边界附近值：
5 位（比最小少 1 ）、17 位（比最大多 1 ）
通过验证这些值，暴露 “边界处理逻辑漏洞”（如 6 位密码是否真的能通过，17 位是否被拦截 ）。
（三）作用
-
精准打击 “边界漏洞”（这类问题在实际场景中高频出现，如数组越界、长度限制失效 ）。
-
补充等价类划分法（等价类侧重 “区间覆盖”，边界值侧重 “临界点” ）。
三、判定表法
（一）核心思想
当测试场景存在多个输入条件组合，且不同组合对应不同输出时，用 “判定表（表格）” 梳理所有条件组合及结果，再转化为测试用例。
（二）示例（以 “电商订单提交” 为例）
| 条件 1：库存是否充足 | 条件 2：地址是否填写 | 条件 3：支付方式是否可选 | 结果 |
|---|---|---|---|
| 是 | 是 | 是 | 提交成功 |
| 是 | 是 | 否 | 提示 “支付方式不可用” |
| 是 | 否 | 是 | 提示 “地址未填写” |
| 是 | 否 | 否 | 提示 “地址未填写” |
| 否 | 是 | 是 | 提示 “库存不足” |
| 否 | 是 | 否 | 提示 “库存不足” |
| 否 | 否 | 是 | 提示 “库存不足、地址未填” |
| 否 | 否 | 否 | 提示 “库存不足、地址未填” |
（三）作用
-
解决 “多条件组合” 的复杂场景，避免遗漏关键组合。
-
让测试逻辑可视化，方便评审与维护。
四、场景法
（一）核心思想
模拟用户实际使用流程（场景） ，覆盖正常流程和异常分支，验证软件在完整业务链路中的表现。
（二）示例（以 “打车 App 流程” 为例）
-
正常场景：
下单 → 司机接单 → 开始行程 → 结束行程 → 支付 -
异常场景：
- 下单后取消订单
- 司机拒单后重新分配
- 支付失败重试
（三）作用
- 贴近用户真实行为，确保 “业务流程完整可用”。
- 覆盖前端交互、后端逻辑联动的复杂场景，暴露 “流程断裂” 类问题（如取消订单后无法重新下单 ）。
五、错误推测法
（一）核心思想
基于经验、历史缺陷、行业常见问题，“推测” 软件可能出现的错误场景，针对性设计用例。无固定流程，依赖测试人员经验。
（二）示例（以 “文件上传功能” 为例）
根据经验推测以下场景：
- 文件格式错误（如要求 PDF，传 PNG ）
- 文件过大（超过系统限制 ）
- 网络中断时上传
（三）作用
- 补充 “结构化方法（如等价类、判定表 ）” 的不足，覆盖经验性、隐蔽性问题。
- 适合敏捷测试、探索性测试，快速挖掘潜在风险。
六、综合案例（以 “登录功能 - 账号密码登录” 为例）
以下是结合多种方法设计的用例思路：
| 方法 | 设计思路 & 用例示例 |
|---|---|
| 等价类划分 | - 有效类：正确账号 + 正确密码 - 无效类：错误账号、错误密码、空账号 / 密码 |
| 边界值分析 | 密码长度边界（如要求 6 - 20 位：测 5 位、6 位、20 位、21 位 ） |
| 判定表法 | 条件：账号存在（是 / 否）、密码正确（是 / 否） 结果：登录成功、提示账号不存在、密码错误 |
| 场景法 | - 正常场景：输入正确信息 → 登录成功 → 跳转首页 - 异常场景：输错密码后重试、登录中网络断开 |
| 错误推测法 | 模拟 “账号被锁定后登录”“密码含特殊字符（如 &* ）” 等经验性场景 |
这些方法可单独或组合使用，目标是用最少用例覆盖最多风险，提升测试效率与质量。实际项目中，需根据需求复杂度、业务场景灵活搭配 。
测试工具推荐
-
缺陷管理工具：禅道，JIRA，TFS
-
功能测试工具：Selenium
-
性能测试工具： JMeter
-
单元测试工具： JUnit、TestNG
-
集成测试工具：Spring Test
-
接口测试工具：RestAssured
-
UI 测试工具：Selenium、Appium
-
内存泄露测试工具：jmap、jconsole、jvisualvm