一： 测试入门
测试是指运用特定的方法、手段或工具，对某一对象进行验证、检查或评估，判断其是否符合预期标准或目标。例如，修理好一盏灯后通过按开关测试其是否正常工作；通过一次数学测验评估学生对代数知识的掌握程度。
1.1 为什么需要软件测试
企业的最终目标是“盈利”，而互联网企业通过软件或系统与用户交互实现盈利。因此企业的核心受众是广大的用户群体。用户的使用体验直接影响企业的盈利能力。如果产品质量较差，将导致用户大量流失，进而对企业的收益产生负面影响。因此，企业非常重视测试工作，以确保产品质量，提升用户满意度并巩固市场竞争力。
1.2 什么是需求
用户需求不能直接作为开发和测试的依据。针对用户需求，产品经理需要进行深入的需求分析，包括技术可行性、市场可行性、成本投入与收益比等方面的评估，经过综合分析后，才能将其转化为明确的软件需求，作为开发和测试的基础。
| 需求类型 | 描述 | 特点 | 示例 |
|---|---|---|---|
| 用户需求 | 用户需求可以简单理解为甲方提出的需求。如果没有明确的甲方，则是终端用户在使用产品时需要完成的任务。 | 需求通常比较简略，常以一句话概括，比如实现一个软件的登录功能。 | 女朋友说：“我饿了。” |
| 软件需求（功能需求） | 软件需求是对开发人员必须实现的软件功能的详细描述。 | 软件需求是测试人员进行测试工作的基本依据，具有明确性和可执行性。 | 通过多次沟通，明确具体需求。你问她：“想吃什么？” 她回答：“随便。” 你提议：“吃米饭炒菜？” 她说：“不想吃。” 你再问：“吃油泼面？” 她依然回答：“不想吃” 最终，通过反复沟通知道了她想吃红烧肉。 |
在⼯作中我们实际⻅到的软件需求⽂档类似于下⾯的表述：
⼀、用户需求：支持邮箱登陆
⼆、软件需求：
1.3 开发模型
随着软件工程学科的不断发展，人们对计算机软件的认识逐渐深入。软件工作的范围已不再局限于程序编写，而是扩展到整个软件生命周期的各个阶段，包括软件概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直至软件的更新与版本替换。
| 生命周期 | 描述 |
|---|---|
| 人的生命周期 | 生命周期是指从生命的起点到结束的整个过程。以人为例，人的生命周期从生命的孕育开始，依次经历幼年、童年、少年、青年、老年，直至生命的终结。 |
| 软件/产品的生命周期 | 软件或产品的生命周期与人的生命周期类似，其起点是需求的提出，随后依次经历需求分析、计划制定、设计、程序开发、程序测试等阶段，最终到达生命周期的终点，即软件不再进行维护或被替换。 |
对于一个软件来说，生命周期包括需求分析、计划、设计、编码、测试和运行维护，各阶段任务如下：
| 阶段 | 具体内容 | 产出 |
|---|---|---|
| 需求分析 | 分析用户需求的合理性，从市场需求和技术可行性等方面进行评估。 | 需求文档 |
| 计划 | 制定需求执行计划，明确完成时间及各阶段功能目标。 | 计划文档 |
| 设计 | 细化需求为任务，分配至团队成员；进行技术设计，包括架构设计、接口设计、技术选型。 | 技术设计文档 |
| 编码 | 开发人员根据需求文档、设计文档和交互图等文件编写代码。 | 代码文件 |
| 测试 | 测试人员根据测试用例对软件进行功能、性能等方面的测试。 | 测试用例、测试报告 |
| 运行维护 | 软件上线后进行修复性、完善性和预防性维护，确保软件稳定运行。 | 维护记录 |
1.4 常见的开发模型
1.4.1 瀑布模型
瀑布模型是软件工程的重要基础框架，瀑布模型适用需求固定的小项目，它采用线性顺序开发，各阶段仅执行一次。其主要缺陷是可运行产品出现较晚，导致较大的项目风险，尤其是集成风险。如果需求阶段的缺陷在测试或后期才被发现往往会引发大规模返工甚至项目失败，因此有“集成之日就是爆炸之日”的说法。早期未发现的错误会逐步传递并在后期放大，修复成本极高。尽管如此，许多企业仍基于瀑布模型的线性思想进行改进，如细化阶段并在关键环节引入迭代机制。瀑布模型将测试阶段安排在开发之后，因此必须预留充足时间，否则容易将缺陷遗留给用户。
1.4.2 螺旋模型
在软件开发初期需求不明确时，通常采用渐进式开发模式，而螺旋模型是其中的代表之一。它尤其适合规模庞大、复杂度高、风险大的项目。由于采用迭代开发，这种模式对软件测试提出了新要求，不再设置独立的测试阶段，而是测试需与开发同步迭代进行，这凸显了回归测试的重要性。
1.4.3 增量模型、迭代模型
增量开发通过逐步构建软件功能，显著降低项目风险，并结合持续构建机制，成为当前流行的软件工程实践之一。它鼓励用户反馈，在每次迭代中以循环且可预测的方式推进产品开发，每次迭代可能引入需求变更并生成新的可执行版本。这种模式要求频繁测试，且测试人员与开发人员需紧密协作。需注意，增量开发和迭代开发虽常被混淆，但有所区别：增量开发侧重逐步构建功能模块，迭代开发则更注重持续优化和完善。
1.4.4 敏捷模型
在早期迭代瀑布模型被广泛用于项目开发。但是随着时间推移，开发人员在使用它时面临诸多挑战，尤其是在项目开发过程中处理客户的变更请求。这些变更往往需要高昂的时间和成本，这成为瀑布模型的主要缺点。为了解决这些问题，敏捷软件开发模型在1990年代中期被提出，旨在更好地适应变更请求，从而提高项目开发的灵活性和效率。
敏捷模型通过将需求分解为可增量开发的小部分，并采用迭代开发方式，促进项目快速完成。每个增量部分在迭代中完成，迭代周期短小且易于管理，通常仅需几周即可完成。敏捷开发避免了长周期计划，专注于为客户逐步计划、开发和部署各个迭代。同时，通过删除不必要的活动，避免浪费时间和精力，从而实现敏捷性和高效性。
| 敏捷宣言内容 | 说明 |
|---|---|
| 个体与交互重于过程和工具 | 强调人和团队之间的沟通与协作，而非过度依赖工具和流程。 |
| 可用的软件重于完备的文档 | 优先交付可运行的软件，而不是追求过度详尽的文档记录。 |
| 客户协作重于合同谈判 | 注重与客户的紧密合作，而不是拘泥于合同条款的约束。 |
| 响应变化重于遵循计划 | 更关注灵活应对需求变化，而不是严格按照固定计划执行。 |
敏捷宣言总结了敏捷模型的四个特点：轻文档、轻流程、重目标、重产出。其中 Scrum是一种广泛使用的敏捷开发方法，也被称为迭代式增量软件开发模型。在Scrum模型中，强调团队协作与灵活开发，核心包含三个关键角色和五个重要会议，通过不断的迭代和增量开发实现高效交付。
| 角色 | 职责 |
|---|---|
| 产品经理 | 整理用户故事，定义商业价值并排序，制定发布计划，对产品整体负责。 |
| 项目经理 | 组织召开各类会议，协调项目进展，为研发团队提供支持与服务。 |
| 研发团队 | 由多技能成员组成，通过紧密协作完成每次迭代目标，并交付高质量的产品。 |
与瀑布模型不同，Scrum将产品开发划分为多个小型迭代，每个迭代周期为 1 至 4 周，但不会超过 4 周。参与团队成员通常为 5 至 9 人，每次迭代的 User Story 在开始时固定不变，并在迭代结束时产生可交付的成果。
| 流程阶段 | 具体内容 |
|---|---|
| 产品待办事项 | 产品负责人整理用户需求（User Story），形成产品待办列表（Product Backlog）。 |
| 发布计划会议 | 产品负责人讲解用户需求，对其进行估算和排序，制定本次迭代的任务列表，形成迭代待办事项（Sprint Backlog）。 |
| 迭代计划会议 | 项目团队将每个用户需求分解为具体任务，明确负责人并进行工时初估，确保每个任务涵盖故事的所有内容。 |
| 每日例会 | Scrum Master召集每日站立会议，团队成员汇报昨天的工作、今天的计划及遇到的问题。 |
| 演示会议 | 迭代结束后，团队向相关人员展示迭代成果，记录大家的反馈，由产品负责人整理形成新的用户故事。 |
| 回顾会议 | 团队总结本次迭代，发现不足，制定改进计划，通过持续改进优化未来迭代流程。 |
1.5 常见的测试模型
1.5.1 V 模型
V 模型由 Paul Rook 在 20 世纪 80 年代后期提出，旨在提升软件开发的效率和效果，是瀑布模型的一种改进版本。
| 优点 | 缺点 |
|---|---|
| 流程清晰，阶段明确 | 缺乏灵活性，难以适应需求变化 |
| 强调验证和确认，降低风险 | 初期需求定义不完善会导致问题 |
| 管理简单，适合小型项目 | 后期变更成本高，灵活性不足 |
| 测试过程有明确计划，易于跟踪 | 缺少实际运行时的反馈调整机制 |
1.5.2 W 模型 ( 双 V 模型 ）
W 模型在软件开发的各个阶段中引入了同步进行的验证和确认活动。它由两个 V 字模型组成，分别表示开发过程和测试过程，清晰地展现了两者的并行关系，从而加强了测试与开发的紧密结合。
| 优点 | 缺点 |
|---|---|
| 强调开发与测试并行，提高效率 | 增加了项目管理的复杂性 |
| 引入验证和确认活动，降低缺陷风险 | 对团队的技术能力和协作要求较高 |
| 清晰展现开发与测试的对应关系 | 初期规划和需求分析工作量较大 |
| 适合强调质量保障的复杂项目 | 不适合需求频繁变更的敏捷项目 |
| 测试贯穿开发全程，问题能早发现早解决 | 需要更多资源和时间投入进行测试活动 |
1.6 Bug
在计算机领域，bug是指程序或系统中的错误、缺陷或问题，它导致软件无法按照预期工作。Bug可能出现在代码、设计、逻辑或实现中，常常表现为程序崩溃、错误结果、不正确的行为或者功能异常。
描述bug的基本要素：问题发生的版本、问题发生的环境、重现问题的步骤、预期的结果、实际的结果。
| 基本要素 | 描述 |
|---|---|
| 版本 | ⾕歌浏览器版本 123.0.6312.123（正式版本）（64 位） |
| 环境 | Windows家庭版 |
| 重现步骤 | 1. 打开⾕歌浏览器，输⼊⽹址https://www.101eduyun.com/ 2. 等待首页页面渲染完成 |
| 预期结果 | ⼆维码与登录模块不会出现遮挡，⼆维码可以正常扫描 |
| 实际结果 | ⼆维码被登录模块遮挡，导致⼆维码扫描失败 |
1.6.1 bug 级别
bug 级别⼀般分为：崩溃、严重、⼀般、次要
| Bug级别 | 描述 |
|---|---|
| 崩溃 | 阻碍开发或测试工作的严重问题，导致系统崩溃、死机、死循环，或引起数据库数据丢失、连接错误、主要功能丧失、基本模块缺失等。如：代码错误、死循环、数据库死锁、重要功能无法使用等。这类问题一旦发生，应立即停止当前版本测试。 |
| 严重 | 系统主要功能部分丧失或数据错误，但不影响其他功能测试。如：数据库保存或调用错误、用户数据丢失、功能设计与需求严重不符、模块无法启动或调用、程序重启或自动退出、安全性或稳定性问题等。这类问题可以在不影响其他功能测试的情况下继续测试。 |
| 一般 | 功能未完全实现但不影响使用，功能菜单有缺陷但不影响系统稳定性。如：操作或查询时间过长、格式错误、边界条件错误、删除操作无确认框、数据库字段过多等。这类问题在测试中较为常见。 |
| 次要 | 界面或性能缺陷，建议类问题，不影响功能执行。如：错别字、界面格式不规范、页面显示重叠、不应显示的内容未隐藏、提示语丢失、文字排列不整齐、光标位置错误、用户体验不佳或优化性能的建议。这类问题优先级较低。 |
1.6.2 bug 的生命周期
测试人员在执行测试过程中，如果发现了 bug，应在对应的 bug 管理平台上创建 bug。创建的 bug 需由开发人员进行修复，同时测试人员需持续跟踪并验证修复结果。
| 状态 | 描述 |
|---|---|
| New | 新发现的Bug，尚未经过评审，暂未决定是否指派给开发人员进行修改。 |
| Open | 确认是Bug，认为需要修改，指派给相应的开发人员处理。 |
| Fixed | 开发人员完成修改后标记为“修改状态”，等待测试人员进行回归测试验证。 |
| Rejected | 如果确认不是Bug，则拒绝修改。 |
| Delay | 如果认为暂时不需要或无法修改，则将Bug状态延后处理。 |
| Closed | 已修改的Bug通过测试人员的回归测试验证，确认修复后关闭Bug。 |
| Reopen | 如果Bug在验证过程中仍然存在，则重新打开Bug，并指派开发人员重新修改。 |
| 无效的 Bug | Bug 流程示例：Open -> Closed 或 Open -> Rejected -> Closed。 |
1.6.3 与开发产生争执怎么办
遇到争执不要怕，要理性的分析和反馈问题。
| 项目 | 描述 |
|---|---|
| 自查 | 检查自身是否存在bug描述不清晰的问题，确保表述准确明确。 |
| 用户视角 | 站在用户角度考虑问题，确保提出的问题符合用户实际需求和使用场景。 |
| BUG定级 | 对Bug进行合理、明确的定级，并提供充分的依据，确保定级准确无误。 |
| 技术与业务能力提升 | 提高自身技术与业务水平，不仅能发现问题，还能提供有效的解决方案。 |
| Bug评审 | 参与Bug评审，确保问题描述清晰、定级合理，并推动问题高效解决。 |
二： 用例
2.1 什么是测试用例
测试用例是为实施测试而设计的一组集合，其中包含测试环境、操作步骤、测试数据和预期结果等关键要素，用于验证被测试系统的功能和性能是否满足需求。
| 用例编号 | test-01 |
|---|---|
| 标题 | 成功注册网易邮箱 |
| 测试方式 | 手工测试 |
| 功能模块 | 注册登录 |
| 重要性 | 重要 |
| 测试前提 | 系统运行正常，邮件服务器已开启 |
| 测试环境 | Windows 10，Chrome版本103.0.5060.66（正式版本）（64位） |
| 测试数据 | 邮箱地址：996402440@qq.com 密码：123456 手机号：12312341234 |
| 测试步骤 | 1. 打开谷歌浏览器，输入网易注册地址：https://mail.163.com/register/index.htm |
| 2. 输入邮箱地址、密码、手机号，获取验证码并输入正确的验证码，勾选协议 | |
| 3. 点击注册按钮 | |
| 期望结果 | 展现注册成功的结果页，并使用刚注册的账号正常登录进入邮箱首页。 |
为什么需要测试用例呢，不写测试用例可以进行测试吗？测试中可能会遇到很多问题，诸如：
| 问题类型 | 描述 |
|---|---|
| 功能测试不全面 | 无法确定是否全面覆盖了所有功能，存在遗漏风险。 |
| 测试覆盖率难衡量 | 测试的覆盖范围缺乏有效的衡量标准，无法量化测试的充分性。 |
| 回归测试困难 | 新版本的回归测试难以完全依赖人工方式，历史功能的回归验证效率低下。 |
| 冗余测试影响效率 | 测试中存在大量重复或无效的测试用例，影响整体测试效率，导致资源浪费。 |
测试用例的出现就是解决这些问题。另外测试用例还可以避免测试人员被迫背锅，因为实际中产品出现问题时第⼀责任⼈⾸先想到的是测试为啥没有测到？
2.2 设计测试用例的万能公式
设计测试用例的通用公式：功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全性测试 + 弱网测试 + 安装卸载测试。
| 测试类别 | 描述 |
|---|---|
| 功能测试 | 验证产品功能是否符合需求 |
| 界面测试 | 检查界面布局和显示效果 |
| 性能测试 | 测试系统的运行性能和稳定性 |
| 兼容性测试 | 验证产品在不同环境下的适配性 |
| 易用性测试 | 检查产品的使用便利性 |
| 安全性测试 | 验证产品的安全性和数据保护能力 |
| 弱网测试 | 模拟弱网环境，验证产品在网络不稳定条件下的表现 |
| 安装卸载测试 | 测试产品的安装、卸载过程是否顺利，以及是否对系统产生不良影响 |
2.3 弱网测试
弱网测试的目的是尽可能优化用户体验，重点关注以下关键点：
| 关注点 | 描述 |
|---|---|
| 页面响应时间 | 是否在可接受范围内，包括热启动、冷启动时间、页面切换、前后台切换、首字时间、首屏时间等。 |
| 页面呈现一致性 | 页面加载是否完成并保持一致。 |
| 超时文案和异常信息 | 超时提示文案是否符合定义，异常信息是否显示正常。 |
| 超时重连 | 是否支持超时后的自动重连功能。 |
| 安全性 | 是否存在DNS劫持、频繁更换登录IP、单点登录异常等安全问题。 |
| 大流量事件风险 | 弱网下是否触发大流量操作，如更新APK包或下载文件等。 |
弱网测试需要借助工具来模拟弱网环境，推荐使用 Fiddler 进行测试。
2.4 用万能公式对水杯写一个测试用例
-
功能测试
- 水倒容量是否为一半
- 水倒至安全刻度线以上
- 水倒满后是否溢出来
- 水杯的容量是否与其他水杯一致
- 漏水验证
-
性能测试
- 使用的最大次数或时间
- 杯盖松紧测试：水倒至杯盖，水倒干出来
- 掉到地上不易损坏
- 保温时长
- 杯子在耐高温性
- 杯子在耐低温性
- 长时间盛放水不会渗出来
- 杯子上放重物到什么程度杯子不会被损坏
-
界面测试
- 外观是否完整、美观
- 大小与设计的一致（高、宽、容量、直径）
- 材质与设计的一致
- 字体舒适
-
安全测试
- 杯子使用材质毒性验证
- 高温元素特性
- 低温元素特性
-
易用性测试
- 倒水方便
- 喝水方便
- 使用简单、便捷
- 防滑性能
-
兼容性
- 能容纳开水、白水、酒精、汽油等液体
-
震动测试
- 杯子和包装（有填充物），六面震动，检查产品是否能对抗复杂的运输条件，如公路/航空/铁轨。
2.5 设计测试用例的方法
2.5.1 基于需求的设计方法
基于需求的设计方法是设计测试用例的总体方法。在工作中，测试人员需要参考需求文档或产品规格说明书来设计测试用例。在接到需求后，测试人员需对需求进行分析和验证，从合理的需求中进一步细化，提炼出测试点，并根据这些测试点设计相应的测试用例。以注册邮箱账号的需求为例，我们来设计测试用例：
首先明确一下需求中的功能点：账号注册和账号登陆
2.5.2 具体的设计方法
2.5.2.1 等价类
根据需求将输入划分为多个等价类，并从每个等价类中选取一个测试用例进行测试。如果该测试用例通过，则认为该等价类的所有情况均通过。通过这种方法，可以用较少的测试用例覆盖尽可能多的功能，从而避免穷举测试的复杂性，等价类有两种：
| 等价类类型 | 描述 |
|---|---|
| 有效等价类 | 由符合程序规格说明书的合理、有效输入数据组成的集合，用于验证程序是否满足规格说明中的功能和性能要求。 |
| 无效等价类 | 由不符合需求说明书、不满足需求条件的输入数据组成的集合，用于验证程序是否能正确处理无效输入。 |
根据等价类设计测试用例的方法：
- 确定有效等价类和无效等价类，划分输入数据范围。
- 基于等价类，设计具体测试数据并编写测试用例。
| 等价类类型 | 描述 | 示例 |
|---|---|---|
| 有效等价类 | 姓名长度在6~15位之间，无错误提示 | 10位字符，无错误提示 |
| 无效等价类1 | 姓名长度小于6位，提示错误 | 1位字符，提示错误 |
| 无效等价类2 | 姓名长度大于15位，提示错误 | 20位字符，提示错误 |
2.5.2.2 边界值 + 次边界值
边界值分析法是一种针对输入或输出边界值进行测试的黑盒测试方法，通常作为等价类划分法的补充。该方法的测试用例通常选自等价类的边界值，以验证系统在边界条件下的正确性和稳定性。
| 边界值类型 | 描述 |
|---|---|
| 边界值 | 等价类范围的上下限值 |
| 次边界值 | 紧邻边界值的不合法值，用于验证系统对接近边界条件的处理 |
2.5.2.3 正交法
正交试验设计是一种用于研究多因素多水平的设计方法。该方法基于正交性，从试验因素的全部水平组合中挑选出具有代表性的一部分进行试验，并通过对试验结果的分析，全面了解整体试验情况，找到最优的水平组合。正交试验设计是一种基于正交表的高效、快速且经济的试验方法。
正交表的一个简单示例是 L4(2³)，其中 “L” 表示正交表，“4” 表示正交表有 4 行，即需要进行 4 次试验；括号内的指数 “3” 表示正交表有 3 列，最多可安排 3 个因素；括号内的数字 “2” 表示每个因素有两个水平，分别为 1 和 2。
| 构成要素 | 描述 |
|---|---|
| 因素数 | 表示正交表中可以安排的因素数量 |
| 水平数 | 表示每个因素包含的水平数量 |
| 行数 | 表示正交表中的试验次数 |
正交表的性质：
| 正交表性质 | 描述 |
|---|---|
| 列内均衡 | 每一列中，不同数字出现的次数相等 |
| 列间均衡 | 任意两列中数字的排列方式齐全且均衡 |
由于正交表需要满足列内均衡和列间均衡的性质，手动设计正交表难度较大，因此通常需要借助工具，例如 AllPairs 工具来生成正交表，使用 Allparis 生成的正交表和预期有出入，但是不影响我们⽤来设计测试用例。继续以邮箱注册为例， 采用正交法补全剩下的测试用例。
-
确定因素和水平
- 因素：姓名、电子邮箱、密码、确认密码、验证码
- 水平：填写、不填写
-
使用 AllPairs 工具生成正交表
- 在 Excel 表格中将因素和水平整理好。
- 在 AllPairs 目录下创建一个新的文本文件（如 0714.txt），将 Excel 中的因素和水平复制并粘贴到该文件中，保存并退出。
- 使用 AllPairs 命令生成正交表：allpairs.exe 0714.txt > 0714jg.txt（生成的正交表数据将存入 0714jg.txt 文件中）。
- 根据正交表编写测试⽤例
- 补充遗漏的重要测试用例：
2.5.2.4 判定表法
判定表是一种用于表达逻辑判断的工具，通过它可以清晰地展示所有条件与对应结果的关系，从而辅助测试人员编写详细的测试用例。判定表的形式如下：
根据判定表法设计测试用例的步骤：
| 步骤 | 描述 |
|---|---|
| 确认需求 | 确认需求中的输入条件和输出条件 |
| 分析关系 | 找出输入条件和输出条件之间的对应关系 |
| 绘制判定表 | 绘制判定表，清晰表达条件与结果的对应关系 |
| 编写用例 | 根据判定表设计并编写测试用例 |
举一个例子：用户输入的账号包含 admin 字符，或通过内部链接进入注册页面，并提交注册按钮后可成为管理员身份；否则为非管理员身份。
-
确认需求中的输入条件和输出条件
- 输入条件：账号包含 admin 字符（a）、内部注册链接（b）、点击注册按钮（c）
- 输出条件：管理员（1）、无管理员（2）
-
找出输入条件和输出条件之间的关系
输⼊条件：ac ab bc abc a b c ⾮abc
对应结果：1 2 1 1 2 2 2 2
- 绘制判定表
-
根据判定表编写测试用例
- 账号包含 admin，非内部注册链接，点击注册按钮，为管理员身份。
- 账号包含 admin，内部注册链接，不点击注册按钮，非管理员身份。
- 账号不包含 admin，内部注册链接，点击注册按钮，为管理员身份。
- 账号包含 admin，内部注册链接，点击注册按钮，为管理员身份。
- 账号包含 admin，非内部注册链接，不点击注册按钮，非管理员身份。
- 账号不包含 admin，非内部注册链接，点击注册按钮，非管理员身份。
- 账号不包含 admin，非内部注册链接，不点击注册按钮，非管理员身份。
2.5.2.5 场景法
场景法是一种测试方法，在常规流程中可能出现一些意想不到的情况。常规流程被称为基本流，而从流程中分析出的不同情况被称为备选流。场景法需要测试人员具备较强的发散思维能力，才能全面覆盖各种可能的情况。
进入街
│
├── 出现突发情况：不逛街 --> 重新规划逛街时间 （备选流）
│
└── 到服装店 （常规流）│├── 出现突发情况：不去服装店 --> 寻找其他服装店的机会（备选流）│└── 选衣服（常规流）│├── 无合适衣服 --> 继续寻找满意的衣服（备选流）│└── 买衣服（常规流）│├── 价格不满意或者其他方面有问题：不买衣服 --> 重新寻找满意的衣位（备选流）│└── 完成购买（常规流）
根据场景法设计测试用例的步骤：
| 步骤 | 描述 |
|---|---|
| 确定基本流 | 明确系统或业务流程中正常的操作流程。 |
| 确定备选流 | 分析基本流中可能出现的意外情况或分支流程。 |
| 补充测试用例 | 根据备选流补充对应的测试用例，覆盖所有场景。 |
| 编写测试用例 | 将基本流和备选流的测试用例详细编写出来。 |
2.5.2.6 错误猜测法
错误猜测法是一种基于对被测试软件的需求理解、设计实现细节的把握以及个人经验和直觉，推测软件可能存在缺陷并设计针对性测试用例的方法。该方法强调测试人员对软件需求和实现的深入理解，以及利用经验和直觉来发现潜在问题。错误推测法的核心思想与目前流行的“探索式测试方法”一致，在敏捷开发模式下具有较高的投入产出比，因而被广泛应用于测试工作中。举一个张三去卖瓜的例子：
| 用例编号 | 描述 |
|---|---|
| 用例1 | 张三这人不实诚，注意他可能缺斤少两 |
| 用例2 | 张三这人粗心，注意他的瓜可能被压坏了 |
| 用例3 | 张三这人小气，注意不要把他惹哭了 |
