开头
很多测试同行面试时最怕被问基础概念，不是不会，而是“好像知道，但说不清楚”。比如“等价类划分”和“边界值分析”到底怎么组合用？“黑盒测试”能发现所有bug吗？
本文准备了5道基础自测题，覆盖核心概念、方法和常见误区。你不需要全对，但每道题都值得停下来想一想——为什么是这个答案？
---
自测题1：黑盒测试能发现代码逻辑错误吗？
题干：
以下哪种缺陷最可能被黑盒测试发现？
A. 数组越界导致的程序崩溃
| B. 条件判断中的逻辑运算符用错（如 `&&` 写成 ` | `） |
|---|
C. 用户输入非法字符后，系统未给出提示
D. 内存泄漏导致长时间运行后性能下降
答案：C
解析：
黑盒测试只关注输入与输出，不关心内部代码实现。用户输入非法字符后，系统应返回明确错误信息，这是典型的黑盒测试场景（功能正确性）。
数组越界（A）和内存泄漏（D）属于运行时代码问题，通常通过白盒测试或压力测试暴露。逻辑运算符错误（B）虽然可能通过特定输入触发，但黑盒测试无法保证覆盖所有逻辑分支，而白盒测试可以通过代码覆盖率分析直接定位。
误区提示：
“黑盒测试看不到代码”不等于“黑盒测试发现不了代码逻辑错误”。如果错误导致输出结果异常，黑盒测试当然能发现，但无法定位根因。此题选C是因为它是最典型的、完全依赖外部表现即可验证的缺陷类型。
---
自测题2：等价类划分和边界值分析怎么组合用？
题干：
一个输入框要求输入1~100的整数（含1和100）。如果用等价类划分+边界值分析设计测试用例，以下哪个选项是最优组合？
A. 有效类：1, 50, 100；无效类：0, 101, -1, 200
B. 有效类：1, 100；无效类：0, 101
C. 有效类：1, 50, 100；无效类：0, 101
D. 有效类：1, 2, 99, 100；无效类：0, 101
答案：C
解析：
- ►等价类划分：有效等价类（1~100）取一个代表值（如50）；无效等价类有两个：小于1（如0）和大于100（如101）。
- ►边界值分析：在有效类的边界上取点——上点（1和100）、离点（0和101）。
组合规则：等价类保证每个“类”至少有一个用例，边界值覆盖边界上的关键点。
- ►选项A：无效类包含了-1和200，但-1和0同属“小于1”这个等价类，200和101同属“大于100”这个等价类，属于冗余。
- ►选项B：有效类只取了边界点，没有覆盖有效类的中间值（虽然中间值风险低，但理论上少了一个等价类代表）。
- ►选项D：取了2和99，这是边界值的内点，但等价类划分中不需要重复覆盖边界附近的点，取一个边界+一个中间值即可。
最优解C：有效类取1（边界）、50（代表）、100（边界），无效类取0和101，既覆盖了等价类，也覆盖了边界值。
一句话总结： 等价类划分负责“分类覆盖”，边界值分析负责“边界打点”，两者结合时，边界值可以直接作为等价类代表使用，避免重复。
---
自测题3：测试用例设计，先写预期结果还是先写步骤？
题干：
在编写测试用例时，以下哪种做法最正确？
A. 先写步骤，再补充预期结果
B. 先写预期结果，再设计步骤
C. 同时写，互相参考
D. 先写步骤，后期再统一补预期结果
答案：B
解析：
预期结果是测试用例的灵魂。如果你不知道“正确的结果是什么”，步骤写得再详细也无效。
- ►先写预期结果：迫使你明确需求，避免“步骤写完了才发现自己也不知道什么是对的”。
- ►先写步骤（A/D）：容易陷入“凭感觉操作”，最后预期结果写得模糊，甚至漏写。
- ►同时写（C）：适合经验丰富的测试人员，但对新手来说容易顾此失彼。
实战建议：
对于复杂场景，先列出“这个用例要验证什么”（即预期结果），再倒推“怎么操作才能触发这个结果”。比如验证“支付失败后订单状态不变”，先明确预期结果（订单状态仍为“待支付”），再设计步骤（输入错误卡号→点击支付→检查状态）。
---
自测题4：回归测试应该覆盖所有已有用例吗？
题干：
一个电商系统新增了“优惠券叠加使用”功能，回归测试时以下哪种策略最合理？
A. 全量回归，执行所有历史测试用例
B. 仅执行与优惠券相关的测试用例
C. 基于风险评估，选择核心交易流程+优惠券相关用例
D. 不执行回归测试，只验证新功能
答案：C
解析：
- ►全量回归（A）：理论上最安全，但时间成本极高，尤其在项目迭代频繁时不可行。
- ►仅执行相关用例（B）：容易漏掉“新功能对旧功能的影响”。比如优惠券叠加可能影响订单计算逻辑，导致普通商品价格计算错误。
- ►不回归（D）：高风险，新功能几乎必然影响已有功能。
最优解C：
1. 风险评估：判断新功能影响范围（优惠券→订单→支付→库存）。
2. 核心流程：必须回归登录、商品浏览、下单、支付、退款等主干流程。
3. 关联模块：优惠券相关用例全部执行，同时补充订单计算、价格显示的边界测试。
经验法则： 回归测试不是“全做”或“不做”，而是“基于风险做精准覆盖”。通常用“影响范围分析”确定回归集，再用自动化执行高频用例。
---
自测题5：测试用例覆盖率达到100%意味着什么？
题干：
如果一个模块的代码覆盖率达到100%，以下哪项说法正确？
A. 该模块没有bug
B. 该模块的每个语句都被执行过
C. 该模块的每个分支都被测试过
D. 该模块的功能测试已充分
答案：B
解析：
代码覆盖率有多种类型：
- ►语句覆盖（最基础）：每条语句至少执行一次 → 达到100%说明代码都跑过了，但可能漏掉分支条件。
- ►分支覆盖：每个判断的真假分支都执行过 → 比语句覆盖更强，但仍无法保证数据组合。
- ►条件覆盖：每个条件的所有可能取值都出现过 → 更精细，但组合爆炸。
题干未指定覆盖率类型，默认指最基础的语句覆盖。即使语句覆盖100%，也可能存在：
- ►未覆盖的分支组合（如
if (a && b)只测了a=true,b=true，漏了a=false,b=true） - ►数据边界问题（如
int x = 100执行了，但没验证x=0时的行为） - ►业务逻辑理解错误（代码写对了，但需求理解错了）
所以： 覆盖率是“测试充分性”的一个指标，不是“无bug”的保证。覆盖率100%只说明“代码被跑过”，不代表“功能被测全”。
---
自测清单
自测完成后，你可以用以下清单检查自己的薄弱点：
- ►[ ] 能准确区分黑盒/白盒测试的适用场景
- ►[ ] 设计测试用例时，先明确预期结果再写步骤
- ►[ ] 知道等价类划分和边界值分析的组合原则
- ►[ ] 回归测试时，能基于风险确定回归范围
- ►[ ] 理解覆盖率指标的真实含义，不盲目追求100%
你答对了几题？如果全对，说明基础扎实；如果错了两道以上，建议重新梳理一下测试设计方法的核心逻辑。