返回测试基础模块新手先记住三个动作：看要求、想意外、做验证 用户感知到的质量，是多个维度共同作用的结果
一次迭代中的测试活动 测试分层：越靠下反馈越快，越靠上越接近真实业务 风险矩阵：影响越大、发生越容易，越需要优先测试
Foundations / Tutorial 01
软件测试基础教程
从“我点了一遍没问题”走向“我能用证据说明风险是否可接受”。
10 个章节1 条完整下单流程图解 + 实战 + 练习
01
从商城下单开始学习测试
零基础起点先看懂
先用“看要求、想意外、做验证”三个动作理解测试，不急着背术语。
放进业务
接下来，你会通过商城下单流程理解每个测试概念，并看到它在真实业务中如何应用。
动手验证
学完后，亲自整理风险、编写用例和缺陷报告，把理解变成可以执行的测试工作。
案例：完成一次在线商城下单
现在，你要测试一条完整的下单流程：用户选择商品，填写地址，使用优惠券并提交订单；系统校验库存、计算金额、创建订单并扣减库存。表面上只是点击一次“提交订单”，实际上需要同时保证业务规则、数据一致性、异常恢复和权限安全。
02
软件测试到底是什么
先看、再想、再验证先记住一句话
软件测试就是：先弄清楚功能正常时应该是什么样，再想想用户可能遇到哪些意外，最后亲自操作并检查结果是否正确。
例如产品说“用户可以提交订单”。测试人员不会只成功下一单，还会继续确认：库存为 0 能不能提交？连续点两次会不会生成两单？优惠券过期后金额是否正确？
01
先看要求
正常情况下应该怎样
下单示例：库存充足时，应该生成一笔订单
02
再想意外
哪些情况容易出错
下单示例：库存为 0、重复点击、优惠券过期
03
动手确认
实际结果到底怎样
下单示例：检查页面提示、订单、库存和金额
普通用户通常这样用
- 选择一个有库存的商品。
- 填写正确地址并提交订单。
- 看到“下单成功”就结束操作。
测试人员会多想几步
- 正常操作时，页面和订单数据是否都正确。
- 输入错误、库存不足或网络中断时会发生什么。
- 重复操作后，订单、库存和金额有没有出错。
- 把看到的结果记录下来，让别人可以再次确认。
测试思维不是故意挑刺，而是在用户遇到问题之前，替用户多走几条容易出错的路。
03
质量不只是功能正确
六个观察角度“可以下单”只说明主功能可能可用。真正的软件质量还需要从稳定性、体验、速度、环境和安全等角度观察。
01功能正确
02稳定可靠
03容易使用
04响应及时
05环境兼容
06权限安全
用六个角度检查下单质量
| 维度 | 要回答的问题 | 下单时检查什么 |
|---|---|---|
| 功能性 | 功能是否做对 | 价格、库存、优惠券和订单状态符合规则 |
| 可靠性 | 异常时是否稳定 | 断网重试不会重复创建订单 |
| 易用性 | 用户是否容易完成 | 错误提示明确，操作路径不绕 |
| 性能 | 高负载下是否可用 | 活动高峰提交订单仍能及时响应 |
| 兼容性 | 不同环境是否一致 | 不同浏览器和手机上都能正常下单 |
| 安全性 | 数据和权限是否可靠 | 用户不能读取或修改他人订单 |
04
测试贯穿整个研发流程
不是提测后才开始01
需求
问清规则
02
设计
识别风险
03
开发
提前验证
04
提测
执行测试
05
修复
回归影响
06
发布
说明风险
越早发现，修复成本越低
- 需求阶段发现规则冲突，只需要改文档。
- 开发阶段发现设计缺口，需要调整代码。
- 上线后发现资金或数据错误，还要补偿用户和数据。
每个阶段都有测试产出
- 需求：问题清单、验收标准、风险清单。
- 设计：测试点、数据方案、环境依赖。
- 执行：结果、缺陷、阻塞和剩余风险。
- 发布：测试报告、回归结论、上线检查项。
05
常见测试类型怎么区分
按目标选择验收测试业务目标
系统测试完整流程
接口测试服务与数据
单元测试函数与规则
按测试层级
- 单元测试：验证函数或类，由开发快速反馈。
- 接口测试：验证服务契约、业务规则和数据。
- 系统测试：从用户视角验证完整产品。
- 验收测试：确认系统是否满足业务交付目标。
按质量目标
- 功能测试：业务行为是否正确。
- 性能测试：响应、吞吐和资源是否达标。
- 安全测试：认证、授权和数据保护是否可靠。
- 兼容性测试：不同设备、浏览器和系统是否一致。
测试类型不是互相替代的工具。下单金额计算适合单元测试，创建订单规则适合接口测试，用户完整购买流程则需要系统测试。
06
从需求中识别风险
先问清楚再测试拿到需求先问四类问题
- 用户是谁：游客、普通用户、会员和管理员的权限有什么不同？
- 规则是什么：库存、价格、优惠券、状态流转如何计算？
- 失败怎么办：断网、超时、重复请求和下游异常如何处理？
- 数据去哪了：页面、接口、数据库、缓存和消息是否需要保持一致？
低概率
中概率
高概率
高影响
中
高
高
中影响
低
中
高
低影响
低
低
中
下单时优先检查这些风险
- 重复提交产生两笔订单或重复扣款。
- 优惠计算错误导致用户少付或多付。
- 库存扣减失败造成超卖。
- 用户修改订单 ID 后访问他人订单。
- 支付成功但订单状态没有更新。
07
把风险变成可执行用例
条件、动作、结果一条好用例应让别人也能执行
- 标题使用“当……时，……”说明条件和预期行为。
- 前置条件明确账号、数据和系统状态。
- 步骤只写必要动作，不把多个验证目标塞进一条用例。
- 预期结果同时检查页面、接口和关键数据变化。
- 优先级由业务影响和发生可能性决定，不按固定比例凑数。
商城下单用例
| 优先级 | 用例标题 | 关键预期 |
|---|---|---|
| P0 | 当库存充足且地址有效时，订单创建成功 | 生成一笔订单；金额、库存和状态正确 |
| P0 | 当商品库存为 0 时，提交订单失败 | 提示库存不足；不生成订单、不扣库存 |
| P0 | 当用户连续点击两次提交时，仅创建一笔订单 | 请求幂等；不会重复扣款或扣库存 |
| P1 | 当优惠券刚好达到使用门槛时，优惠金额正确 | 边界金额计算正确；订单实付一致 |
| P1 | 当收货地址缺少手机号时，无法提交订单 | 定位到错误字段；保留已填写内容 |
| P2 | 当订单备注达到最大长度时，可以正常保存 | 备注完整保存；页面不溢出 |
先覆盖 P0 核心交易与资金数据，再覆盖 P1 主要规则和异常，最后考虑 P2 低频体验。优先级准确比用例数量漂亮更重要。
08
执行测试时记录什么
让结果可追溯执行前
- 确认版本、环境和本次变更范围。
- 准备账号、商品、库存和优惠券数据。
- 检查依赖服务是否可用。
- 先跑冒烟测试，确认版本值得继续测试。
执行中
- 记录实际结果，而不是只标通过或失败。
- 失败时保存时间、请求、日志和业务 ID。
- 区分产品缺陷、环境问题和测试数据问题。
- 新风险及时补充探索性测试。
通过、失败、阻塞不是同一件事
- 通过：实际结果符合明确的预期。
- 失败：实际结果与预期不一致，存在产品问题或需求冲突。
- 阻塞：由于环境、权限或依赖不可用，当前无法完成验证。
- 未执行：本轮范围、时间或条件不包含该用例。
09
缺陷报告与回归测试
把问题说清楚一份可复现的缺陷报告
| 字段 | 下单问题 | 为什么要写 |
|---|---|---|
| 标题 | 当重复点击提交订单时，系统创建两笔订单 | 一句话说明条件、动作和错误结果 |
| 环境 | 测试环境 / Chrome 128 / 测试账号 A | 让开发者知道问题在哪里发生 |
| 前置条件 | 商品库存 10，购物车内 1 件商品 | 说明复现前系统应处于什么状态 |
| 复现步骤 | 进入确认页 → 连续点击提交两次 | 步骤短、明确、可以重复执行 |
| 实际结果 | 生成两笔订单，库存减少 2 | 记录观察到的事实，不写猜测 |
| 预期结果 | 仅生成一笔订单，库存减少 1 | 对应需求规则或质量标准 |
| 证据 | 截图、录屏、请求日志、订单 ID | 帮助快速定位并确认修复 |
修复后为什么还要回归
- 确认原缺陷在相同条件下已经消失。
- 验证修复没有破坏相邻业务。
- 覆盖同类输入和相反路径，防止只修一个样例。
- 核心链路重新执行，确认版本仍可发布。
缺陷严重程度与优先级
- 严重程度描述对系统和用户造成的影响。
- 修复优先级描述团队需要多快处理。
- 严重但低频的问题也可能必须阻断发布。
- 不要用情绪争论等级，要用影响范围和证据沟通。
10
完成一次真正的基础练习
从阅读走向执行练习：独立完成一次商城下单测试
- 画出从选择商品到订单创建成功的完整流程。
- 列出至少 8 个风险，覆盖规则、异常、权限和数据。
- 按“当……时，……”格式编写 10 条用例。
- 为每条用例设置优先级，并写出判断理由。
- 假设出现“重复点击后生成两笔订单”，写一份完整缺陷报告。
- 说明修复后需要回归哪些相邻功能。
理解需求
- 用户和目标明确
- 规则和边界明确
- 异常处理明确
- 数据流向明确
完成验证
- 核心路径已覆盖
- 高风险异常已覆盖
- 结果有证据
- 缺陷可复现
支持发布
- 修复已回归
- 阻塞项已说明
- 剩余风险已说明
- 结论有范围限制
完成这些输出后，你已经具备进入“测试用例设计实战教程”的基础。
继续学习测试用例设计