趣味学习 - 第11章测试评审方法

🎭 本章导读：错误与缺陷的纠葛

IEEE说：错误(error)针对开发过程，缺陷(fault)针对软件产品。开发过程中犯错→产品留下缺陷→测试发现缺陷→调试修复。测试目标是"尽可能多发现缺陷"，高效测试是"少用例多发现"。

生

小明

老师，测试不就是找bug吗？为啥还要"评审"？

师

老师

因为缺陷越早发现修复成本越低。需求阶段一个错字，到测试阶段可能变成几十个bug。评审就是在需求/设计阶段"提前抓虫"，那时还不能测试。测试是后期手段，评审是早期手段，缺一不可。

🔬 11.1 测试方法

测试用例=测试数据+预期结果。好测试用例=极可能发现至今未发现的缺陷。成功测试=发现了尚未发现的缺陷。

📊 11.1.1 软件测试三大阶段

按阶段分：单元测试→集成测试→系统测试。每个阶段的"计划"在更早阶段制定。

阶段	别名	发现什么错误	计划制定期
单元测试	模块测试	编程和详细设计错误	详细设计阶段
集成测试	组装测试	模块间接口和通信	概要设计阶段
系统测试	—	全局功能性能	需求分析阶段

单元测试需编写驱动模块(调用被测模块)和桩模块(模拟被调子模块)。顶层模块不需驱动，底层模块不需桩。内聚程度高可简化测试。

集成测试分非渐增式(一次全集成，难定位错误)和渐增式(每次加一个模块，主流)。渐增式又分自顶向下(不需驱动)和自底向上(不需桩)。

系统测试含确认测试(对照需求)和验收测试。Alpha测试在开发者场所(受控)，Beta测试在用户现场(不受控)。

三阶段像盖楼验检：单元测试=验每块砖(模块)，集成测试=验砖墙拼接(接口)，系统测试=整栋楼验收集(功能性能)。计划则"前移"——砖的计划在画砖图时定，墙的计划在画楼图时定，楼的计划在需求时定。

计划前移：单元计划在详设、集成计划在概设、系统计划在需求。驱动桩模块：顶层不驱动、底层不桩。Alpha受控Beta不受控。

高频考点：三种测试阶段对应的计划制定阶段；驱动模块/桩模块的作用与何时不需要；Alpha vs Beta测试的区别(场所+是否受控)。

🔦 11.1.2 白盒测试 vs 黑盒测试

白盒=透明箱子看内部逻辑(结构测试)，用于单元测试。黑盒=不透明箱子只看功能(功能测试)，用于集成和确认测试。

白盒测试核心：逻辑覆盖。6种覆盖标准，由弱到强：

覆盖	含义	强度
语句覆盖	每条语句至少执行一次	最弱
判定覆盖(分支)	每个判定的每种分支至少一次	较弱
条件覆盖	判定中每个条件取各种可能结果	与判定互不包含
判定/条件覆盖	同时满足判定+条件覆盖	较强
条件组合覆盖	条件结果所有组合至少一次	更强(但不含路径)
路径覆盖	每条可能路径至少经过一次	较强(不含条件组合)

注意：条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖。条件组合覆盖满足判定/条件覆盖但不保证路径。路径覆盖不考虑条件组合，不能代替条件覆盖。

黑盒测试4种技术：

等价类划分：用得最多。有效等价类(合理数据，验功能)+无效等价类(非法数据，验容错)。一个用例覆盖多个有效等价类，每个无效等价类单独一个用例。
边值分析：边界最易出错。取恰好等于、稍小于、稍大于边界值。常与等价类结合。
错误推测：靠经验和直觉选最可能出错的方案。
因果图：输入条件与输出结果的因果关系，检查组合。

白盒像体检医生看内脏X光(看到结构)，黑盒像顾客点奶茶只尝味道(不看配方)。6种覆盖像不同精度体检：语句=只看器官在，判定=看分支功能正常，路径=看所有血流路径。等价类像"奶茶甜度测试"——正常糖(有效)+负数糖(无效)各验一遍。

白盒6覆盖必背强弱序；条件覆盖与判定覆盖互不包含；无效等价类每个单独一个用例。黑盒4技术：等价类(最多)+边值(边界)+错误推测(经验)+因果图(组合)。

🏷️ 11.1.3 缺陷的分类和级别

5类缺陷+Beizer 10级严重程度。

5类缺陷(IEEE/Jorgensen)：输入/输出错误、逻辑错误、计算错误、接口错误、数据错误。

Beizer 10级：①轻微(错别字)→②中等(误导)→③使人不悦(数字断开)→④影响使用(交易未处理)→⑤严重(丢失交易)→⑥非常严重(不正确处理)→⑦极为严重(经常不正确)→⑧无法容忍(数据库破坏)→⑨灾难性(系统无法工作)→⑩传染性(导致其他系统瘫痪)。

5类缺陷"输逻计接数"；10级从"错别字"到"传染其他系统"，严重程度递增。

🔧 11.1.4 调试：排错三大策略

调试=测试发现错误后定位原因并改正。错误有8种特殊性质(征兆远离原因、纠正一个致另一消失、假象、操作疏忽、分时引起、输入难重建、征兆时有时无、多机分布)。

策略	思想	效率
原始类	"计算机找错"，输出存储器/寄存器内容，靠大量信息找线索	最低效，万般无奈用
回溯类	从错误征兆处沿控制流程人工回追	程序大时路线爆炸
排除类	归纳演绎，列可能原因逐一排除	较高效，分治思想

👥 11.2 评审方法：8种评审+8个注意点

IEEE 1028：评审是对软件元素或项目状态的评估，确定是否与计划一致并改进。广义评审含8种。

8种评审：①软件需求评审→②概要设计评审→③详细设计评审→④软件验证和确认评审→⑤功能检查(释放前)→⑥物理检查(验收前)→⑦综合检查(验收时)→⑧管理评审(定期)。

8个注意点：

不以测试代替评审(早期可评审不可测试，缺陷发现越晚成本越高)
关注产品不评论人(别变"批斗大会")
关注实质性问题(别纠结格式措词)
评审会不是问题解决会(发现而非解决)
评审应进项目计划(别临时安排)
参与者应了解评审过程
评审前应充分了解材料
重视评审组织工作(时间/通知/场所/设施/气氛)

评审像奶茶店新品发布前的"配方评审会"：需求评审=顾客需求是否合理，概设评审=产品架构是否对，详设评审=每步工艺是否对。评审会只"找问题"不"解决问题"，别开成"配方研讨会"。也别开成"批斗厨师大会"——评的是配方不是厨师。

8种评审的顺序和触发时机必考；8个注意点常出案例分析(如"评审变批斗会"违反第2条，"评审变研讨会"违反第4条)。

✅ 11.3 验证与确认(V&V)

验证(Verification)="做对了吗"(过程)，确认(Validation)="做的是对的吗"(产品)。验证适用于分析/设计/编码/测试/评审，确认通常用于验收。

验证7种：合同验证、过程验证、需求验证、设计验证、编码验证、集成验证、文档验证。

需求验证：明确一致无歧义、可行、可测试
设计验证：可实现需求、可从需求导出/追踪
编码验证：可实现设计、可从设计导出/追踪
集成验证：软硬件完整正确集成
文档验证：充分完备一致、及时、配置管理合规

确认：建确认过程，含编写测试需求/用例/规程→反映预期用途→执行测试→确认满足预期用途。可内部或第三方。

🤖 11.4 测试自动化

测试工作量大、重复性高、非智力创造性——适合计算机自动化。与配置管理密不可分。

5项可自动化：①测试用例生成 ②测试执行控制(多机分布/夜间假日运行) ③结果与标准输出对比 ④不吻合结果分析记录分类通报 ⑤状况统计报表。

🧬 11.5 面向对象的测试

OO软件抛弃传统功能模块结构，传统测试模型不再适用。测试焦点从"过程构件(模块)"移向"类"，视角扩大到分析和设计模型。

OO测试6阶段（对应OOA/OOD/OOP三阶段+传统三测试）：

OOA测试：测认定的对象/结构/主题/属性和实例关联/服务和消息关联
OOD测试：测认定的类/类层次结构/类库支持
OOP测试：测数据成员是否满足封装、类是否实现功能
OO单元测试：最小可测试单位变为"类或对象"(非模块)，不孤立测单操作
OO集成测试：无层次控制结构，传统自顶向下/自底向上无意义。两种策略：基于线程的测试(输入/事件所需的一组类)+基于使用的测试(先测独立类再测依赖类)
OO系统测试：参考OOA结果，检测软件能否"再现"问题空间

OO特性对测试的影响：封装降低数据非法操作测试；继承提高重用但提高错误传播概率；多态使同函数行为复杂化，需测不同类型参数。

OO测试焦点从模块→类，视角扩大到分析设计模型。单元测试对象变为类。集成测试两种策略：基于线程 vs 基于使用。封装/继承/多态对测试的影响。

🏆 本章总结：抓虫全流程

测试方法：3阶段(单元/集成/系统)+白盒6覆盖+黑盒4技术+5类缺陷+10级严重度+3种调试策略
评审：8种评审(需求→概设→详设→V&V→功能→物理→综合→管理)+8注意点
V&V：验证7种(合同/过程/需求/设计/编码/集成/文档)+确认(预期用途)
测试自动化：5项(生成/执行/对比/分析/统计)
OO测试：6阶段(OOA/OOD/OOP/单元/集成/系统)，焦点从模块→类

测试3阶段、白盒6覆盖、黑盒4技术、缺陷5类10级、评审8种8注意、验证7种、OO测试6阶段

测试评审方法：抓虫子的艺术 🐛