自测题清单：测测你的测试基本功
软件测试的基础知识，是每个从业者的立身之本。无论你是刚入行的新人，还是已有几年经验的老手，偶尔回看这些基础概念，总能发现一些平时忽略的细节。
下面这7道自测题，涵盖了测试分类、测试设计、缺陷管理、测试流程等核心模块。每道题都配有「是什么→为什么→怎么做」的拆解和实战案例，帮助你真正理解，而不是死记硬背。
---
问题1：什么是黑盒测试？它与白盒测试的核心区别是什么？
是什么
黑盒测试是一种不关注内部代码结构的测试方法，测试人员将软件视为一个“黑盒子”，只通过输入和输出判断功能是否正常。白盒测试则需要了解内部逻辑，测试代码路径。
为什么
黑盒测试模拟最终用户的使用场景，关注功能正确性；白盒测试关注代码的覆盖率和逻辑正确性。两者互补，缺一不可。只做黑盒测试可能漏掉边界条件；只做白盒测试可能忽略用户体验。
怎么做
- ►黑盒测试：使用等价类划分、边界值分析、决策表等方法设计用例。
- ►白盒测试：使用语句覆盖、分支覆盖、路径覆盖等方法设计用例。
案例
一个登录功能，输入用户名和密码，点击登录。
- ►黑盒测试：验证“正确账号+正确密码”能登录，“错误账号+正确密码”提示错误。
- ►白盒测试：验证代码中if-else分支是否都被执行，比如密码校验的异常路径。
---
问题2：等价类划分和边界值分析有什么区别？什么时候该用哪个？
是什么
等价类划分：将输入数据划分为若干个等价类（有效类、无效类），每个等价类中取一个代表值测试。
边界值分析：专门测试输入范围的边界点，因为大量的缺陷发生在边界附近。
为什么
等价类划分能大幅减少测试用例数量，提高效率。边界值分析则针对“边界陷阱”，比如输入范围1-100，99和100是有效边界，0和101是无效边界。
怎么做
- ►等价类划分：先划分类，再从每类中选一个值。
- ►边界值分析：在等价类划分的基础上，额外测试边界值（最小值-1、最小值、最大值、最大值+1）。
案例
一个年龄输入框，要求输入1-120的整数。
- ►等价类：有效类（1-120），无效类（<1，>120，非数字）。
- ►边界值分析：测试0、1、2、119、120、121。
何时用
- ►输入范围明确时，优先用边界值分析。
- ►输入范围不明确或逻辑复杂时，先用等价类划分，再补充边界值。
---
问题3：一个高质量的Bug报告应该包含哪些要素？
是什么
Bug报告是测试人员与开发人员沟通缺陷的载体，必须清晰、完整、可复现。
为什么
一个模糊的Bug报告会导致开发人员反复追问、浪费时间，甚至无法复现而搁置。高质量的Bug报告能加速问题定位和修复。
怎么做
一份标准的Bug报告包含：
1. 标题：简明扼要，如“登录页点击‘忘记密码’后页面白屏”。
2. 环境：操作系统、浏览器版本、设备型号。
3. 前置条件：需要哪些数据或操作状态。
4. 复现步骤：按顺序列出操作。
5. 实际结果：出现的错误现象。
6. 预期结果：应该出现的正确现象。
7. 截图/日志：辅助信息，如错误日志、截图。
8. 严重程度：致命、严重、一般、建议。
案例
标题：购物车页面点击“删除”按钮后商品数量未更新 环境：Chrome 120，Windows 11 前置条件：购物车中有2件商品 复现步骤： 1. 打开购物车页面 2. 点击任一商品的“删除”按钮 3. 观察页面右上角的购物车图标中的数字 实际结果：数字仍显示“2” 预期结果：数字应变为“1” 严重程度：一般
---
问题4：回归测试和冒烟测试有什么区别？
是什么
冒烟测试：在收到新版本后，快速验证核心功能是否正常工作，决定是否接受版本进行后续测试。
回归测试：在修改代码后，验证已有功能没有被破坏。
为什么
冒烟测试是“准入测试”，确保版本基本可用。回归测试是“防退化测试”，确保修改不引入新缺陷。
怎么做
- ►冒烟测试：选择最核心的用例，如登录、首页加载、核心业务流程。通常在几分钟到半小时内完成。
- ►回归测试：根据修改影响范围，选择相关模块的用例，或者执行全量回归。通常需要数小时甚至数天。
案例
一个电商App发布新版本，修复了支付BUG。
- ►冒烟测试：验证登录、商品浏览、加入购物车、支付流程是否跑通。
- ►回归测试：除了支付相关用例，还要验证订单查询、退款流程、用户信息修改等功能是否正常。
---
问题5：什么是测试用例的“前置条件”？为什么它很重要？
是什么
前置条件是指执行测试用例前必须满足的状态或数据。比如“用户已登录”、“购物车中有商品”、“网络已连接”。
为什么
没有前置条件，测试用例可能无法执行，或者执行结果受其他因素干扰。明确前置条件能保证用例的可复现性和独立性。
怎么做
在编写测试用例时，专门列出“前置条件”字段，并写明具体的状态或数据。例如：
- ►前置条件：用户账号A已注册，且余额为100元。
- ►前置条件：测试数据中有一条状态为“待发货”的订单。
案例
测试用例：验证用户能对“待发货”订单申请退款。
- ►前置条件：用户已登录，且该用户下存在一条状态为“待发货”的订单。
- ►步骤：进入订单详情页 → 点击“申请退款”按钮 → 填写退款原因 → 提交。
- ►预期结果：退款申请成功，订单状态变为“退款中”。
---
问题6：什么是“探索性测试”？它和脚本化测试有何不同？
是什么
探索性测试是一种同时设计、执行和学习的测试方法。测试人员在测试过程中根据系统反馈，动态调整测试策略和用例。脚本化测试则是预先编写好用例，严格按照步骤执行。
为什么
探索性测试适合发现脚本化测试难以覆盖的复杂场景和边界情况。脚本化测试适合可重复、可自动化的回归场景。两者结合能最大化测试覆盖率。
怎么做
- ►探索性测试：没有固定脚本，测试人员基于对业务的理解，自由操作，记录发现的问题。
- ►脚本化测试：编写详细的测试步骤和预期结果，按顺序执行。
案例
一个社交App的“发布动态”功能。
- ►脚本化测试：输入文字 → 添加图片 → 点击发布 → 验证动态出现在时间线。
- ►探索性测试：先发布一条带视频的动态，然后快速连续发布多条，再删除其中一条，观察页面状态、数据一致性、性能表现。可能发现“快速连续发布后页面卡顿”或“删除动态后图片未释放”等问题。
---
问题7：测试计划中应该包含哪些核心内容？
是什么
测试计划是指导整个测试过程的文档，明确测试范围、策略、资源、进度和风险。
为什么
没有测试计划，测试工作容易混乱，遗漏关键模块，或者资源分配不合理。一份好的测试计划能让团队对齐目标，提高效率。
怎么做
一份标准的测试计划包含：
1. 测试范围：哪些功能要测，哪些不测。
2. 测试策略：采用哪些测试方法（功能、性能、安全等）。
3. 资源分配：测试人员、环境、工具。
4. 进度安排：各阶段的起止时间。
5. 风险与应对：可能的风险（如环境不稳定）及应对措施。
6. 交付物：测试用例、Bug报告、测试总结报告。
案例
一个电商App的测试计划简版：
- ►测试范围：登录、商品浏览、购物车、下单支付、订单管理。不测：后台管理系统。
- ►测试策略：功能测试为主，辅以兼容性测试（Chrome、Safari、Edge）。
- ►资源：2名测试人员，1台Windows笔记本，1台MacBook。
- ►进度：第1周功能测试，第2周兼容性测试和回归测试。
- ►风险：支付接口可能出现第三方响应延迟，已准备备用支付渠道。
- ►交付物：测试用例集、Bug清单、测试总结。
---
自测清单：你答对了几道？
| 问题 | 你的答案 | 正确理解 |
|---|---|---|
| 黑盒测试与白盒测试的核心区别 | 关注输入输出 vs 关注代码逻辑 | 正确 |
| 等价类和边界值的适用场景 | 等价类用于减少用例，边界值用于边界 | 正确 |
| Bug报告要素 | 标题、环境、步骤、实际结果、预期结果 | 正确 |
| 冒烟测试与回归测试区别 | 准入 vs 防退化 | 正确 |
| 前置条件的重要性 | 保证用例可复现和独立 | 正确 |
| 探索性测试的特点 | 动态设计、学习和执行 | 正确 |
| 测试计划核心内容 | 范围、策略、资源、进度、风险 | 正确 |
如果你的答案与正确理解偏差超过2道，建议重新梳理对应模块的基础知识。如果全部答对，说明你的测试基础扎实，可以继续挑战更深入的问题。