先看题库能不能从需求推到测试用例
给出“年龄18至60岁、会员等级不同享受不同折扣”这样的需求，题库应引导你识别输入域、边界和条件组合，再选择等价类、边界值或判定表。直接问定义只能检查记忆，不能证明会设计。
白盒题同样需要证据。MC/DC不是看到每个条件取过真假就算满足，而要为每个基本条件找到一对测试，使其他相关条件保持不变，仅该条件变化就能独立改变判定结果。
| 方法 | 主要解决什么 | 题库应展示的证据 |
|---|---|---|
| 等价类 | 减少同类输入的重复测试 | 有效、无效类及代表值 |
| 边界值 | 发现边界附近错误 | 边界内、边界上、边界外取值 |
| 判定表 | 处理条件组合和业务规则 | 条件桩、动作桩与规则列 |
| MC/DC | 证明基本条件独立影响判定 | 每个条件对应的独立影响测试对 |
| 变异测试 | 评价测试集发现人为缺陷的能力 | 被杀死、存活和等价变异体 |
用MC/DC题检验解析是否会“证明”
对判定式(A AND B) OR C，解析不能只给四个测试用例。它应分别指出哪一对证明A的独立影响、哪一对证明B、哪一对证明C，并验证其他相关条件没有同时变化。
如果题库的答案是“满足条件覆盖，所以也满足MC/DC”，就说明概念边界没有讲清。软件测试的很多题都需要证据链：为什么这组用例覆盖到了，为什么那个缺陷能被观察，为什么指标这样计算。
- 写出完整判定式并列出基本条件。
- 为某个条件寻找一对仅该条件变化的测试。
- 确认整条判定结果随之改变。
- 对每个基本条件重复验证，不用一组笼统结论代替。
- 最后再检查是否存在短路求值或不可达组合等边界。
测试过程题要分清目的和时机
冒烟测试用于快速判断新版本是否具备继续深入测试的基本条件，失败时通常应退回修复，而不是继续投入完整回归。回归测试则关注变更是否破坏既有功能。两者都可能执行已有用例，但目的、范围和时机不同。
题库还应覆盖缺陷管理、评审、测试计划、性能、安全和可靠性。软件评测师不是只考黑盒白盒，实际题目会把测试活动放进版本、风险和质量目标中判断。
| 题目线索 | 优先想到 | 不要误判为 |
|---|---|---|
| 新构建能否进入深入测试 | 冒烟测试 | 完整回归测试 |
| 修改后旧功能是否受影响 | 回归测试 | 只重测缺陷点 |
| 多条件业务规则组合 | 判定表 | 只做边界值 |
| 代码条件独立影响判定 | MC/DC | 普通条件覆盖 |
| 测试集能否发现微小代码变更 | 变异测试 | 缺陷密度统计 |
错题复盘必须留下可复查的测试证据
测试题做错以后，最有用的记录不是“MC/DC不会”，而是画出测试对，指出哪个条件没有独立改变结果。指标题则写清分子和分母，例如DRE的分母包含发布前与发布后发现的缺陷总数，不能见到90%就直接倒算。
需要连续刷章节题和重做错题时，可以使用书木兰软考题库一类练习工具；查某种测试方法的完整推导时，再回到专题页细读。每次复盘都留下可被另一个人检查的表格、用例或计算，才符合测试工作的基本习惯。
DRE反向计算为什么容易错
DRE = 发布前发现缺陷数 ÷ 发布前后发现缺陷总数。
若DRE为90%、发布后发现10个缺陷，应先设发布前缺陷数为x。
列式x ÷ (x + 10) = 90%，而不是10 ÷ 90%。
指标题先写定义，再代入角色对应的数据，能少掉很多机械错误。
相关题目解析
下面这些题目和本专题的判断方法关联较强，适合读完概念后回到具体题干里校验理解。
- 判定式 (A AND B) OR C 的 MC/DC 最少怎么选用例？MC/DC / 修正条件判定覆盖
- MC/DC 为什么要求每个条件独立影响判定结果？MC/DC / 修正条件判定覆盖
- 把“>”改成“>=”后测试仍通过，说明了什么？变异测试 / 存活变异体
- 已知发布后缺陷数和 DRE，发布前发现了多少缺陷？DRE / 缺陷去除效率
- 冒烟测试失败后，测试团队通常应该怎么处理？冒烟测试 / 测试流程
常见问题
软件评测师题库应该重点练什么？
应覆盖测试过程、黑盒设计、白盒覆盖、缺陷管理、评审、性能、安全和质量指标，并能展示测试用例或计算证据。
软件评测师需要会写测试用例吗？
需要。只认识方法名称不足以应对场景题，应能根据需求划分输入、组合条件、选择覆盖准则并说明预期结果。
MC/DC题怎么判断题库解析是否正确？
检查解析是否为每个基本条件给出一对测试，在其他相关条件保持不变时，仅改变该条件即可改变整个判定结果。仅满足条件覆盖并不等于满足MC/DC。