测试基础

什么是软件测试

(概念\过程\目的)

概念：

软件测试是通过人工或自动化手段，对软件系统进行验证和确认的过程，目的是检查软件是否满足规定的需求或识别实际结果与预期结果之间的差异。

软件测试存在的意义是：通过一系列测试活动，“提前” 发现和定位软件产品质量的薄弱环节，并倒逼开发人员修正，从而保证交付的软件质量满足客户需求。

过程：

1. 需求分析：理解需求文档，明确测试范围。
2. 测试计划：制定测试策略、资源分配和时间表。
3. 测试设计：编写测试用例，覆盖功能和非功能需求。
4. 测试执行：执行测试用例，记录缺陷。
5. 缺陷管理：跟踪、修复和验证缺陷。
6. 测试报告：总结测试结果，评估软件质量。
7. 测试闭环：确认所有问题解决，输出最终报告。

目的：

• 确保软件质量，满足用户需求。
• 发现缺陷，降低生产环境风险。
• 验证功能、性能、安全性等非功能指标。
• 提供产品发布决策依据。

测试主流技能

• 黑盒测试
• 灰盒测试
• 白盒测试
• 单元测试
• 接口测试
• 系统测试
• 验收测试
• UI测试
• web测试
• app测试
• 冒烟测试
• 回归测试
• 功能测试
• 性能测试
• 安全测试
• 可靠性测试
• 兼容性测试

首先，我们从软件测试中最基础的三类测试（按“是否了解内部结构”分类）开始，全面介绍黑盒测试、白盒测试、灰盒测试的核心信息。这三类测试是理解后续单元测试、接口测试等的基础，核心区别在于对被测试对象（如代码、模块、系统）内部逻辑的“可见度”。

模型

质量模型

前置铺垫：

• 需求：

• 需求文档

  1.软件质量 软件质量，就是软件与明确地和隐含地定义得需求相致得程度。

质量模型为评估软件质量提供系统化框架，指导测试设计和结果分析。

得到需求、测试功能，可以从以下八个方向进行考虑：

功能、性能、兼容、易用、可靠、安全、维护、迁移

重点在：功能、性能、兼容、易用、安全

• 质量模型

  质量模型定义了软件质量的评价标准，最常用的是 ISO/IEC 25010 标准，包含以下八大特性：

#### 1. 功能性（Functional Suitability）

• 子特性：功能是否满足需求
  • 功能完备性：是否覆盖所有需求。
  • 功能正确性：输出结果是否准确。
  • 功能依从性：是否符合行业标准（如金融合规）。

#### 2. 性能效率（Performance Efficiency）

• 子特性：性能满足实际需求
  • 时间特性：响应速度、处理时间。
  • 资源利用率：CPU、内存、网络消耗。
  • 容量：最大并发用户数、数据处理能力。

#### 3. 兼容性（Compatibility）

• 子特性：软件能与主流硬件和软件兼容
  • 互操作性：与其他系统交互能力（如API兼容）。
  • 共存性：与其他软件共存时不冲突。
  • 环境适配性：支持不同操作系统、浏览器、设备。

#### 4. 可用性（Usability）

• 子特性：便于使用
  • 易学性：用户快速上手的难度。
  • 易操作性：界面交互是否直观。
  • 错误防御性：防止用户误操作的设计。

#### 5. 可靠性（Reliability）

• 子特性：性能和功能应用可靠
  • 成熟性：系统长期运行的稳定性。
  • 容错性：故障后恢复能力。
  • 可用性：系统持续可用的时间比例（如99.9% SLA）。

#### 6. 安全性（Security）

• 子特性：信息在传输或者储存过程的安全程度
  • 机密性：数据加密与权限控制。
  • 完整性：防止数据篡改。
  • 抗抵赖性：操作可追溯（如日志审计）。

#### 7. 维护性（Maintainability）

• 子特性：便于维护
  • 模块化：代码结构是否易于修改。
  • 可测试性：是否容易添加新测试用例。
  • 可分析性：定位问题的难易程度。

#### 8. 可移植性（Portability）

• 子特性：具备迁移和便捷性
  • 适应性：适配不同环境的成本。
  • 易安装性：部署流程是否简单。
  • 可替换性：是否可被其他系统替代。

软件生命周期

软件从没有到消亡的过程，软件生成、制作过程

瀑布模型

优点：时间长、环节清晰

敏捷开发模型

迭代增量式开发

项目被分解成不同的小部分，围绕最小化可行产品的特性进行产品规划，进行研发。接下来，对这个产品进行测试和评审，最终准备上线。然后循环这个过程，准备下一个最小化可行产品，直到得到一个可发布的产品。

一个循环可称为一个冲刺（sprints）,通常持续1-3周。

三个角色

产品经理：负责分析产品特性，梳理出产品需求列表。

团队负责人：负责协助团队完成开发，沟通、组织会议

团队：

三个工件

产品需求列表：产品经理从用户需求中筛选出优先性，并列入产品开发列表。

需求列表会随着每次sprint迭代和更改。

用户故事：一种表达产品需求的语言格式，从用户角度出发。

格式为：作为一名___用户，我需要___功能,所以___能够

产品经理通过用户故事了解需求细节，为团队合理制定任务优先级

最优项的用户故事将进入Sprint代办列表，剩下的评估优先级，交到下次sprint

燃尽图：用于展示整个Sprint代办列表的进度

三个活动

Sprint计划会议：产品经理、Master和团队的碰头会议。用于讨论用户故事并估算任务量

每日例会：整个团队讨论任务进度，是否调整任务和协调资源

Sprint回顾会议:团队向任务经理展示开发好的功能，讨论是否有需要改进的地方

测试模型

V模型

W模型

简称为”双V模型”

开发流程：需求分析、概要设计、详细设计、编码、集成、实施、交付。
测试流程：单元测试、集成测试、系统测试、验收测试

优点：

缺点：

测试流程

软件测试流程

1.需求分析：让参与项目的各部门对 “需求是什么” 达成一致理解，避免后续偏差。

2.计划编写：明确测试的核心问题 ——“测什么内容、谁来执行测试、用什么方法 / 流程测”。

3.用例设计：编写 “操作指南式” 的文档，用来验证项目是否符合需求（即 “测试用例”）。

4.用例执行：等项目模块开发好后，按照之前设计的测试用例，实际开展测试工作。

5.缺陷管理：对测试中发现的问题（“缺陷”）进行全流程管理（比如记录、追踪修复、验证修复效果等）。

6.测试报告：把测试的最终结果整理成文档，总结测试的情况（比如发现了多少问题、项目是否符合要求等）。

• 需求分析

前置：阅读需求分析文档，记录不明确之处

1、确定各部门对需求理解一致。
2、站在不同角度对需求进行（查、漏、补缺）

• 测试计划

核心： 1、测什么：测试目标及范围 2、谁来测：人员进度安排 3、怎么测：测试策略、测试工具

团队计划 --》  个人计划
团队计划：

个人计划：

• 用例设计

设计执行测试的文档

• 用例执行

执行测试的文档

• 缺陷管理

提交->验证->关闭

• 测试报告

测试背景、测试过程、缺陷统计、缺陷分析、测试总结

测试用例

什么是用例

• 测试用例：执行测试的文档（用户使用的文档）
• 考虑点：质量模型

**什么是测试用例？**

测试用例（Test Case）是为特定测试目标设计的一组**执行条件、输入数据、操作步骤和预期结果**，用于验证软件是否满足需求或发现潜在缺陷。它是测试执行的最小单位，是测试活动的核心指导文档。

用例的作用

• 防止漏测
• 实施测试的标准

测试用例的作用

1. 指导测试执行
   • 明确测试步骤和预期结果，避免遗漏或误操作。
   • 示例：登录功能测试用例确保覆盖“正确密码”“错误密码”“空密码”等场景。
2. 保障测试覆盖率
   • 通过设计用例，系统化覆盖功能、边界条件、异常场景。
   • 结合等价类划分、边界值分析等方法，减少测试盲区。
3. 缺陷发现与追踪
   • 通过比对实际结果与预期结果，快速定位缺陷。
   • 缺陷报告中可关联用例编号，便于复现和修复验证。
4. 团队协作与沟通
   • 作为测试与开发、产品之间的沟通桥梁，确保需求理解一致。
   • 用例评审（Review）可提前暴露需求歧义或设计漏洞。
5. 自动化测试的基础
   • 自动化脚本通常基于测试用例设计，确保脚本可维护性和可扩展性。
   • 示例：Selenium脚本按用例步骤执行登录操作。
6. 回归测试的保障
   • 维护用例库，便于后续版本快速执行回归测试，防止修复引入新问题。
7. 质量评估与报告
   • 统计用例通过率、缺陷密度等指标，评估软件质量，支持发布决策。
8. 知识沉淀
   • 用例文档化保留测试经验，方便新人快速上手或项目交接。

用例设计编写格式

测试用例的核心要素

• 用例编号：项目+模块+编号
• 用例标题：预期结果+操作步骤
• 模块/项目：所属项目或模块
• 前置条件：要执行此条用例，有哪些前置操作
• 优先级：表示用例的重要程度或者影响力P0~p4（PO最高）
• 测试步骤；描述操作步骤
• 测试数据：操作的数据，没有的话可以为空
• 预期结果：期望达到的结果

1. 用例编号：唯一标识（如TC_Login_001）。
2. 测试标题：简洁描述测试目的（如预期结果+测试点“注册成功（验证码6位）”）。
3. 前置条件：执行前的环境或数据状态（如“用户已注册”）。
4. 输入数据：测试所需的参数或操作（如用户名：[email protected]，密码：123456）。
5. 执行步骤：详细的操作流程（如：输入用户名 → 输入密码 → 点击登录按钮）。
6. 预期结果：符合需求的标准输出（如“跳转到用户主页”）。
7. 实际结果：执行后的实际输出（测试执行时填写）。
8. 优先级：标记重要性（如P0-紧急，P1-高，P2-中）。

测试用例与质量模型的关联

• 功能性：用例验证功能是否正确实现（如支付流程是否完整）。
• 性能效率：性能测试用例设计并发用户数、响应时间等场景。
• 安全性：安全测试用例覆盖SQL注入、越权访问等漏洞场景。
• 兼容性：用例验证不同浏览器、设备下的功能一致性。

总结

测试用例是软件测试的“作战计划”，其核心价值在于：

• 标准化：确保测试活动系统化、可重复。
• 高效性：减少重复劳动，提升测试效率。
• 可追溯性：缺陷、需求、用例三者关联，形成闭环管理。
• 质量保障：通过覆盖多维度场景，支撑软件质量目标的达成。

如何设计用例设计

1.等价类划分法–针对穷举场景

• • 说明：在所有测试数据中，具有某种共同特征的数据集合进行划分。

  • 分类：

    • 有效等价类：满足需求的数据集合，取一个进行测试即可
    • 无效等价类：不满足需求的数据集合，取一个进行测试即可

  • 步骤

    1.明确需求
    2.确定有效和无效等价类
    3.提取数据编写测试用例

• 案例

有效：

• 使用场景

  • 针对：需要有大量数据测试输入，但是没法穷举测试的地方。

    输入框 下拉列表 单选复选框

  • 典型代表：页面级的输入框类测试。

2.边界值分析法-针对边界范围规则

针对边界范围规则，使用边界值分析法+等价类划分法

• 边界范围节点

选取正好等于、刚好大于、搞好小于边界的值作为测试数据

• 上点：边界上的点（正好等于） 绿点
• 离点：距离上点最近的点（刚好大于、刚好小于） 黄点

• 内点：范围内的点（区间范围内的数据） 内点

  用例设计最多7条，最少5条

案例优化 结论：7个优化为5个点 上点：必选(不考虑区间开闭) 内点：必选(建议选择中间范围） 离点：开内闭外(考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

• 步骤

  2、边界值法设计用例步骤 1.明确需求 2.确定有效和无效等价类 3.确定边界范围值 4.提取数据编写测试用例

• 案例

案例一

案例二

• 使用场景

在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）

• 常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语

• 典型代表:有边界范围的输入框类测试

• 提示：边界值可以覆盖等价类的长度，但是无法覆盖类型。所以设计用例时，必须两者结合。

3.判定表法-针对多条件依赖关系

判定表定义及组成部分

是一种以表格形式表达多条件逻辑判断的工具 组成：

• 条件桩：列出问题中的所有条件，列出条件的次序无关紧要。
• 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。
• 条件项：列出条件对应的取值，所有可能情况下的真假值。
• 动作项：列出条件项的、各种取值情况下应该采取的动作结果。

规则:

判定表中贯穿条件项和动作项的一列就是一条规则

假设有n个条件，每个条件的取值有两个（0,1），全组合有2的n次方种规则

判定表法设计用例步骤

1、明确需求 2、画出判定表 1）、列出条件桩和动作桩 2）、填写条件项，对条件进行全组合 3）、根据条件项的组合确定动作项 4）、简化、合并相似规则（有相同的动作） 3、根据规则编写测试用例

验证码就4条：

正确、错误、过期、为空

• 案例

案例一

案例二

• 使用场景

• 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系

• 判定表一般适用于条件组合数量较少的情况（比如4个条件以下）

• 4个相互依赖条件可以使用正交表和因果图

4.场景法-使用对于项目业务

说明：

场景法也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例。 意义： 用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用 测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

• 案例

案例一

成功的最长的这条线一般用于冒烟测试。

用例二

案例三

• 使用场景

流程图

流程图对测试人员有什么作用？ 1、能够看懂流程图，设计业务用例 2、当需求文档信息不全是，能够根据需求，梳理出流程

5.错误推荐法

定义 通过经验推测系统可能出现的问题

场景： 1、时间紧任务量大时根据之前项目类似经验找出易出错的模块重点测试

2、时间宽裕时通过该方法列根据经验列举可能出现问题的、之前出现问题较多的模块题的清单，根据清单分析问题再次测试、推测发现缺陷

以下是测试用例的标准格式说明及示例，帮助团队统一规范、提升测试效率：

测试用例标准格式

测试用例模板示例

功能测试用例（Excel/工具模板）

性能测试用例（JMeter场景示例）

不同测试类型的格式差异

1. 功能测试用例

   • 强调步骤和结果的细节，适合手动测试。
   • 示例：UI操作流程、表单提交验证。

2. 自动化测试用例

   • 增加脚本路径、参数化数据源字段。

   • 示例：

     script_path: tests/login/test_login.py  
     data_source: data/login_data.csv  
     

3. 接口测试用例

   • 包含请求方法、URL、Headers、Body等字段。

   • 示例：

     **Request**:  
     - Method: POST  
     - URL: /api/login  
     - Body: { "username": "test", "password": "123" }  
     **Response**:  
     - Status Code: 200  
     - Body: { "token": "xxxx" }  
     

4. 安全测试用例

   • 描述漏洞场景和攻击向量。

   • 示例：

     测试标题：验证SQL注入漏洞  
     步骤：在用户名输入框输入 `' OR 1=1 --`  
     预期结果：系统返回错误提示，而非泄露数据库信息。  
     

注意事项

1. 清晰简洁
   • 避免冗长步骤，每一步只包含一个操作。
   • 示例：❌ 错误写法：“输入用户名和密码，点击登录”；✅ 正确写法：分步骤描述。
2. 可复用性
   • 参数化输入数据（如使用变量 ${username}），便于数据驱动测试。
3. 独立性
   • 单个用例不依赖其他用例结果，前置条件需明确初始化数据。
4. 版本控制
   • 用例文档需标注版本号和修订记录（如下表）：

常用工具与模板

1. Excel/Google Sheets：适合小型团队，灵活但不易维护。
2. TestLink/TestRail：专业测试管理工具，支持用例库、执行计划和报告生成。
3. JIRA + Zephyr：与缺陷管理无缝集成，适合敏捷团队。
4. Markdown/Confluence：便于文档协作和版本跟踪。

总结

规范的测试用例格式能：

• 提升团队协作效率，减少沟通成本。
• 确保测试覆盖率和执行一致性。
• 为自动化测试和回归测试提供可靠基础。
• 根据项目需求调整模板（如金融行业需增加合规性验证字段）。

缺陷

1．能够知道软件缺陷判定标准

缺陷介绍 1、缺陷的定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug。

2、缺陷的判定标准

• 软件未实现需求(规格)说明书中明确要求的功能-少功能
• 软件出现了需求（规格）说明书中指明不应该出现的错误-功能错误
• 软件实现的功能超出需求（规格）说明书指明的范围-多功能
• 软件未实现需求(规格)说明书中虽未明确指明但应该实现的要求-隐性功能错误
• 软件难以理解，不易使用，运行缓慢，用户体验不好-不易使用

3.缺陷产生的原因

需求阶段:需求描述不易理解，有歧义、错误等。 产品经理 设计阶段:设计文档存在错误或者缺陷。 架构师 编码阶段:代码出现错误。 运行阶段:软硬件系统本身故障导致软件缺陷。

IT行业常见岗位及作用

• 产品：梳理需求、设计原型图
• UI：美工
• 前端：写页面
• 后端：写功能
• 测试：找缺陷
• 运维：管理服务器
• 运营：上线运营策划

4、软件缺陷的生命周期

注入bug->发现bug->修复bug
从提交报告到修复关闭

5、软件缺陷的核心内容

缺陷的标题：描述缺陷的核心问题

缺陷的预置条件：缺陷产生的前提

缺陷的复现步骤：复现缺陷的过程

缺陷的预期结果：希望得到的结果

缺陷的实际结果：实际得到的结果

缺陷的必要附件：图片、日志等信息(证据)

6.缺陷提交要素

缺陷报告编号:缺陷的唯一性标志

严重程度:

严重（S1）：主功能 一般 (S2):次要功能

微小 (S3)：易用性、界面 建议（S4）：建议性问题

缺陷优先级：

Priority 0：24小时之内解决

Priority 1：发布前必须修复

Priority 2：可以在下一个版本中修复

Bug类型：

代码错误、兼容性问题、设计缺陷、性能问题

缺陥状态：

New:新建 Open:打开 Closed:关闭 Postponed:延期

7、软件缺陷类型

功能错误如何区分前端、后端错误： 利用抓包，检测请求和响应的数据是否正确

2.能够知道项目中缺陷的管理流程

缺陷报告示例

缺陷ID：用例ID

缺陷标题：操作数据描述+预期+实际

测试步骤：操作步骤+数据

缺陷的跟踪流程

发现BUG后该怎么做 --- 确认BUG可复现

3.能够使用Excel对于缺陷进行管理

4.掌握禅道工具管理缺陷

禅道的特点

三权分立

产品部门-构想者 研发部门-执行者 测试部门-保证者

四角协同

产品经理 项目经理 研发团队 测试团队

禅道使用流程

禅道缺陷管理

• 缺陷管理

• 用例管理

• 缺陷管理

1.提交缺陷  2.关闭缺陷

• 用例管理

测试用例设计方法

测试用例设计方法是保障测试覆盖度、准确性和效率的核心手段，不同方法适用于不同场景（如简单输入验证、复杂流程、多条件组合）。以下是10种主流测试用例设计方法，每种方法均包含“定义、核心思想、操作步骤、实际案例”，帮助你理解并落地应用。

一、等价类划分法（Equivalence Partitioning）

1. 定义

将“输入参数的所有可能值”按“是否符合需求”划分为有效等价类（符合需求的合理值）和无效等价类（不符合需求的不合理值），从每个等价类中选取1-2个代表性值作为测试用例，避免重复测试（同一等价类内的用例效果一致）。

2. 核心思想

“抓共性，减冗余”——无需测试所有可能值，只需覆盖“有效”和“无效”的核心分类，平衡覆盖度与效率。

3. 操作步骤

1. 分析需求：明确输入参数的“类型、范围、格式、约束”（如“手机号登录，需输入11位数字”）；
2. 划分等价类：
   • 有效等价类：满足所有约束的取值（如“11位纯数字手机号”）；
   • 无效等价类：违反任一约束的取值（如“少于11位”“多于11位”“包含非数字字符”）；
3. 设计用例：每个等价类至少设计1个用例，优先覆盖“边界附近的无效等价类”。

4. 案例（手机号登录功能）

| 等价类类型 | 等价类描述 | 代表性用例（输入值） | 预期结果 | |————|—————————|———————-|—————————| | 有效等价类 | 11位纯数字 | 13800138001 | 登录成功（跳转首页） | | 无效等价类 | 少于11位数字 | 1380013800（10位） | 提示“请输入11位手机号” | | 无效等价类 | 多于11位数字 | 138001380012（12位） | 提示“请输入11位手机号” | | 无效等价类 | 包含非数字字符（字母） | 13800138a01 | 提示“手机号仅支持数字” | | 无效等价类 | 包含非数字字符（特殊符号）| 13800138#01 | 提示“手机号仅支持数字” |

二、边界值分析法（Boundary Value Analysis, BVA）

1. 定义

针对“输入参数的边界值”设计用例——因为软件在“边界附近”最容易出现逻辑错误（如“密码长度6-20位”，6和20是边界，5和21是边界外的值，最可能出错）。

2. 核心思想

“边界是风险点”——聚焦“等于边界、略小于边界、略大于边界”的取值，覆盖等价类未重点关注的“临界场景”。

3. 操作步骤

1. 从等价类划分结果中，提取“有范围约束的参数”（如“年龄18-60岁”“订单金额≥0元”）；
2. 确定边界值：对“[a,b]”范围，边界值为a-1、a、a+1、b-1、b、b+1（若a=0，可省略a-1）；
3. 设计用例：优先测试“边界值”和“边界外1位”的取值。

4. 案例（密码设置功能，需求：密码长度6-20位，包含字母+数字）

| 边界场景 | 测试用例（密码） | 预期结果 | |————————-|——————|—————————| | 边界内最小值（6位） | Abc123 | 密码设置成功 | | 边界外最小值-1（5位） | Abc12 | 提示“密码长度需6-20位” | | 边界内最小值+1（7位） | Abc1234 | 密码设置成功 | | 边界内最大值（20位） | Abc123456789012345678 | 密码设置成功 | | 边界外最大值+1（21位） | Abc1234567890123456789 | 提示“密码长度需6-20位” | | 边界内最大值-1（19位） | Abc12345678901234567 | 密码设置成功 |

三、场景法（Scenario-Based Testing）

1. 定义

模拟“用户真实使用软件的完整流程”（场景），覆盖“正常流程”和“异常流程”，验证软件在“端到端场景”中的表现，适合复杂业务流程（如电商下单、支付、退款）。

2. 核心思想

“从用户视角出发，覆盖全流程”——不仅测试单个功能，更关注“功能间的联动是否符合业务逻辑”。

3. 操作步骤

1. 梳理业务流程：按“用户操作步骤”拆解核心场景（如“电商下单流程：登录→选商品→加购物车→结算→支付”）；
2. 补充异常分支：在每个步骤中添加“异常场景”（如“登录失败”“库存不足”“支付超时”）；
3. 设计用例：每个场景（正常/异常）对应1条端到端用例，包含“前置条件→操作步骤→预期结果”。

4. 案例（电商下单支付流程）

| 场景类型 | 场景描述 | 前置条件 | 操作步骤 | 预期结果 | |———-|————————-|————————-|————————————————————————–|————————————————————————–| | 正常场景 | 登录→选商品→支付成功 | 1. 用户已注册；2. 商品有库存 | 1. 输入账号密码登录；
2. 搜索“手机”，加入购物车；
3. 结算，选择地址；
4. 支付宝支付，完成付款。 | 1. 登录成功；
2. 商品加入购物车；
3. 跳转支付页；
4. 支付成功，生成订单，库存扣1。 | | 异常场景 | 选商品→库存不足→无法下单 | 1. 用户已登录；2. 商品库存仅剩0 | 1. 搜索“手机”，加入购物车；
2. 结算时系统提示“库存不足”；
3. 尝试继续下单。 | 1. 加入购物车成功；
2. 结算时提示“库存不足”；
3. 无法进入支付页，需删除该商品才能继续。 | | 异常场景 | 支付→超时→重新支付 | 1. 已下单；2. 未支付 | 1. 提交订单后，等待30分钟（支付超时）；
2. 系统提示“订单超时，需重新支付”；
3. 点击“重新支付”，用微信付款。 | 1. 订单状态变为“已超时”；
2. 重新支付成功后，订单状态变为“已支付”；
3. 库存扣1，无重复扣减。 |

四、错误推测法（Error Guessing）

1. 定义

基于“测试经验、开发常见错误、用户使用习惯”，推测软件可能出现错误的场景，设计针对性用例，是对其他方法的补充（无法通过规则覆盖的“隐性错误”）。

2. 核心思想

“凭经验抓漏洞”——依赖测试人员对业务和技术的理解，适合补充测试（如用户可能输入空格、重复提交、网络中断后重试）。

3. 操作步骤

1. 总结历史错误：回顾同类功能的Bug（如“登录时输入空格会被截断”“重复提交订单导致多下单”）；
2. 推测潜在错误：结合业务逻辑，思考“用户可能的误操作”（如“密码输入大小写混合”“地址为空仍提交”）；
3. 设计用例：针对每个推测的错误场景，设计1条用例验证。

4. 案例（表单提交功能）

| 推测的错误场景 | 测试用例（输入/操作） | 预期结果 | |——————————-|——————————|—————————| | 输入值包含前/后空格 | 用户名输入“ test123 ”（前后空格） | 系统自动去除空格，登录成功（或提示“用户名不能包含空格”） | | 重复点击“提交”按钮 | 快速点击“订单提交”按钮5次 | 仅生成1条订单，无重复下单 | | 网络中断后恢复，重新提交 | 提交表单时断网，恢复后重试 | 提示“表单已提交，无需重复操作”（或正常提交1次） | | 输入特殊字符（如 emoji） | 昵称输入“😊test” | 提示“昵称不支持特殊表情”（或正常保存，无乱码） |

五、因果图法（Cause-Effect Graphing）

1. 定义

当“输入条件（因）”与“输出结果（果）”存在复杂逻辑关系（如“且、或、非”）时，用“图形（因果图）”梳理所有条件组合，避免遗漏，再转化为测试用例。

2. 核心思想

“可视化逻辑关系，覆盖所有条件组合”——适合条件数≥2、逻辑关系复杂的场景（如“会员等级+订单金额决定折扣率”）。

3. 操作步骤

1. 提取“因”（输入条件）和“果”（输出结果）：如“因：A=会员，B=订单金额≥100元；果：C=9折，D=无折扣”；
2. 定义逻辑关系：用“与（∧）、或（∨）、非（¬）”描述因与果的关系（如“A∧B→C；¬(A∧B)→D”）；
3. 绘制因果图：用节点表示“因”和“果”，用线条表示逻辑关系；
4. 转化为测试用例：每个“因的组合”对应1条用例。

4. 案例（订单折扣规则：会员且订单≥100元享9折，其他无折扣）

| 因（输入条件） | 逻辑组合 | 果（输出结果） | 测试用例（会员？金额？） | 预期折扣 | |———————-|———-|—————-|————————–|———-| | A=会员，B=≥100元 | A∧B | C=9折 | 是会员，订单150元 | 135元（9折） | | A=会员，B=＜100元 | A∧¬B | D=无折扣 | 是会员，订单80元 | 80元 | | A=非会员，B=≥100元 | ¬A∧B | D=无折扣 | 非会员，订单120元 | 120元 | | A=非会员，B=＜100元 | ¬A∧¬B | D=无折扣 | 非会员，订单50元 | 50元 |

六、判定表法（Decision Table）

1. 定义

将“所有输入条件（因）”和“对应的输出结果（果）”以“表格形式”列出，覆盖所有条件组合，适合“条件数多、逻辑关系明确”的场景（如因果图的表格化落地）。

2. 核心思想

“穷举所有条件组合，无遗漏”——比因果图更直观，适合团队协作（开发、测试可共同确认判定表）。

3. 操作步骤

1. 确定输入条件（因）和输出结果（果），并编号；
2. 列出所有条件的“取值组合”（每个条件有“是/否”2种，n个条件有2ⁿ种组合）；
3. 对每个组合，确定对应的输出结果；
4. 简化判定表（合并相同结果的组合），转化为测试用例。

4. 案例（快递运费计算：重量≤1kg且江浙沪→8元；重量≤1kg且非江浙沪→12元；重量＞1kg且江浙沪→15元；重量＞1kg且非江浙沪→20元）

| 判定表编号 | 输入条件1（重量≤1kg？） | 输入条件2（江浙沪？） | 输出结果（运费） | 测试用例（重量+地区） | |————|————————–|————————|——————|————————| | 1 | 是 | 是 | 8元 | 0.8kg，上海 | | 2 | 是 | 否 | 12元 | 0.5kg，北京 | | 3 | 否 | 是 | 15元 | 1.2kg，杭州 | | 4 | 否 | 否 | 20元 | 2kg，广州 |

七、正交试验法（Orthogonal Array Testing）

1. 定义

当“输入参数多（≥3个）、每个参数有多个取值（水平）”时，用“正交表”选取“代表性的参数组合”（覆盖所有参数的所有水平，且组合数最少），减少测试用例数量。

2. 核心思想

“以最少用例覆盖最多组合”——平衡“覆盖度”和“效率”，适合多参数场景（如浏览器类型、操作系统、分辨率的兼容性测试）。

3. 操作步骤

1. 确定“参数（因素）”和“每个参数的取值（水平）”（如参数：浏览器（Chrome/Firefox/Safari）、系统（Windows/macOS）、分辨率（1920×1080/375×812））；
2. 选择合适的正交表：根据“参数数”和“水平数”选择标准正交表（如3参数2水平选L4(2³)，3参数3水平选L9(3⁴)）；
3. 映射参数与正交表：将参数取值填入正交表，生成测试用例。

4. 案例（Web页面兼容性测试：参数=浏览器（A）、系统（B）、分辨率（C））

| 参数（因素） | 取值（水平） | |————–|—————————–| | A（浏览器） | A1=Chrome，A2=Firefox，A3=Safari | | B（系统） | B1=Windows 10，B2=macOS Monterey | | C（分辨率） | C1=1920×1080，C2=375×812 |

选择正交表L8(2⁴)（适配3参数2水平，补充1个空列），生成用例： | 用例编号 | 浏览器（A） | 系统（B） | 分辨率（C） | 测试场景 | |———-|————-|———–|————-|————————-| | 1 | A1 | B1 | C1 | Chrome+Windows 10+1920×1080 | | 2 | A1 | B2 | C2 | Chrome+macOS+375×812 | | 3 | A2 | B1 | C2 | Firefox+Windows 10+375×812 | | 4 | A2 | B2 | C1 | Firefox+macOS+1920×1080 | | 5 | A3 | B1 | C1 | Safari+Windows 10+1920×1080 | | 6 | A3 | B2 | C2 | Safari+macOS+375×812 |

八、状态迁移法（State Transition Testing）

1. 定义

针对“有状态变化的功能”（如订单状态、用户登录状态），梳理“所有状态”和“状态转换条件”，验证“从一个状态到另一个状态的转换是否符合规则”。

2. 核心思想

“覆盖所有状态转换路径”——确保软件在状态变化时无逻辑错误（如“已取消的订单不能再支付”）。

3. 操作步骤

1. 提取“所有状态”：如订单状态=待支付、已支付、已发货、已完成、已取消；
2. 确定“状态转换条件”：如“待支付→已支付”的条件是“用户完成付款”；
3. 绘制状态迁移图：用节点表示状态，用箭头表示转换，标注转换条件；
4. 设计用例：每个转换路径对应1条用例，验证“触发条件后，状态是否正确变化”。

4. 案例（订单状态管理）

| 状态转换路径 | 转换条件 | 测试用例步骤 | 预期结果 | |———————–|————————-|————————————————————————–|————————————————————————–| | 待支付→已支付 | 用户完成支付 | 1. 提交订单，生成“待支付”订单；
2. 点击“支付”，完成微信付款。 | 订单状态从“待支付”变为“已支付”，提示“支付成功” | | 待支付→已取消 | 用户点击“取消订单” | 1. 生成“待支付”订单；
2. 点击“取消订单”，选择理由“不想买了”。 | 订单状态从“待支付”变为“已取消”，提示“订单已取消，库存已恢复” | | 已支付→已发货 | 商家点击“发货” | 1. 订单处于“已支付”状态；
2. 商家后台点击“发货”，输入快递单号。 | 订单状态从“已支付”变为“已发货”，用户端显示快递单号和物流信息 | | 已取消→待支付 | 无（不允许转换） | 1. 订单处于“已取消”状态；
2. 尝试点击“支付”按钮。 | 按钮置灰，提示“已取消的订单无法支付，请重新下单” |

九、基于风险的测试法（Risk-Based Testing）

1. 定义

根据“功能的重要性”和“潜在风险概率”，对测试资源进行优先级分配——高风险功能（如支付、登录）优先测试、重点覆盖；低风险功能（如帮助中心）简化测试、减少用例。

2. 核心思想

“抓重点，降风险”——适合测试时间紧张、资源有限的场景（如敏捷迭代中的快速测试）。

3. 操作步骤

1. 风险评估：从“影响范围（严重度）”和“发生概率”两个维度评分（1-5分），风险值=严重度×概率；
2. 风险分级：高风险（风险值≥12）、中风险（6≤风险值≤11）、低风险（风险值≤5）；
3. 资源分配：高风险功能用例覆盖度100%，优先执行；中风险80%；低风险50%。

4. 案例（电商App风险评估与测试分配）

| 功能模块 | 严重度（影响范围） | 概率（发生Bug概率） | 风险值 | 风险等级 | 测试策略（用例覆盖度） | |————|——————–|———————|——–|———-|————————| | 支付模块 | 5（涉及资金） | 4（逻辑复杂） | 20 | 高 | 100%覆盖，包含异常场景（支付失败、重复支付） | | 登录模块 | 5（影响所有功能） | 3（较稳定） | 15 | 高 | 100%覆盖，验证密码错误、验证码失效等场景 | | 商品搜索 | 3（影响购物体验） | 3（偶发Bug） | 9 | 中 | 80%覆盖，重点测试关键词搜索、筛选功能 | | 帮助中心 | 1（仅参考） | 2（很少变更） | 2 | 低 | 50%覆盖，仅测试核心帮助文档的显示 |

十、探索性测试法（Exploratory Testing）

1. 定义

无预设用例，测试人员根据“对业务的理解”和“实时测试结果”，自由设计和执行测试操作，探索软件的“隐性Bug”（如操作流畅度、界面交互细节），是“结构化测试（如等价类）”的补充。

2. 核心思想

“自由探索，发现意外Bug”——依赖测试人员的经验和创造力，适合测试后期补充验证。

3. 操作步骤

1. 确定探索范围：如“电商App的购物车模块”；
2. 设定时间盒：每次探索15-30分钟，避免无目标耗时；
3. 记录操作与结果：实时记录“操作步骤→实际结果→Bug描述”；
4. 复盘总结：整理探索中发现的Bug，补充到结构化用例中。

4. 案例（电商购物车探索性测试）

| 探索方向 | 操作步骤 | 发现的Bug/优化点 | |————————-|————————————————————————–|——————————————-| | 多商品批量操作 | 1. 购物车添加3件商品；
2. 勾选2件，点击“删除”；
3. 撤销删除，再勾选3件。 | 撤销删除后，第3件商品勾选状态消失，需重新勾选（优化点） | | 弱网下的交互 | 1. 模拟2G弱网；
2. 购物车刷新商品库存。 | 弱网下无“加载中”提示，用户以为卡住（Bug） | | 商品规格变更 | 1. 购物车中商品A选择“黑色128G”；
2. 商品详情页将A改为“白色256G”；
3. 回到购物车。 | 购物车中商品A的规格未同步更新，仍显示“黑色128G”（Bug） |

不同方法的适用场景总结

| 设计方法 | 适用场景 | 优势 | 劣势 | |——————|——————————————-|—————————————|—————————————| | 等价类+边界值 | 简单输入验证（手机号、密码、金额） | 覆盖全面，减少冗余 | 不适合复杂流程 | | 场景法 | 端到端业务流程（下单、支付、退款） | 贴近用户真实使用，覆盖流程联动 | 用例量大，执行耗时 | | 因果图+判定表 | 多条件组合（折扣规则、权限控制） | 逻辑清晰，无遗漏组合 | 条件数多时表格复杂 | | 正交试验法 | 多参数兼容性测试（浏览器、系统、分辨率） | 用例少，效率高 | 可能遗漏低概率组合 | | 状态迁移法 | 有状态变化的功能（订单状态、登录状态） | 覆盖所有状态转换，无逻辑漏洞 | 仅关注状态，不覆盖非状态相关场景 | | 基于风险的测试 | 时间紧张、资源有限的场景（敏捷迭代） | 聚焦高风险功能，降低业务风险 | 低风险功能可能遗漏Bug | | 探索性测试 | 测试后期补充验证、发现隐性Bug | 灵活，易发现意外问题 | 依赖经验，无固定标准 |

实际测试中，通常会组合多种方法（如“等价类+边界值+场景法”覆盖核心功能，用探索性测试补充细节），以达到“覆盖全面、效率优先”的目标。