第11章 · 播客 第3集
测试评审方法 · 黑盒测试、缺陷分类与排错
🎙️ 本集播客：第3集：白盒讲完，转到黑盒四技术——等价类划分、边值分析、错误推测、因果图；然后是缺陷五分类、Beizer 十级严重程度、错误的八条特殊性质与排错三策略；评审八种时机与八条注意事项、验证与确认、测试自动化、面向对象测试，末尾附全章必背清单。 语音由微软 Edge 神经网络语音预生成（女声·晓伊，男声·云希）。点击下方任意对话可直接从该句开始播，当前句朗读时下一句已预先加载，无缝衔接。
明
阿明
师姐，白盒六种逻辑覆盖我背熟了，今天该黑盒了吧？
雅
小雅
先把定位钉牢：黑盒测试又称功能测试，主要用于集成测试和确认测试阶段，和白盒主要用于单元测试阶段正好错开。黑盒把软件看作不透明的黑箱子，完全不考虑也不了解内部结构和处理算法，只检查功能能否按需求说明书要求正常使用、能否适当地接收输入并产生正确输出、运行中能否保持外部信息的完整性。
雅
小雅
设计用例的依据是软件需求说明书，不是代码。常用技术四种：等价类划分、边值分析、错误推测和因果图。最直接的一句：在设计测试用例时，等价类划分是用得最多的一种黑盒测试方法——问「黑盒中使用最多的方法」就选它。
雅
小雅
等价类是某个输入域的集合，其中的输入值揭示程序错误的作用是等效的。两分法：符合需求说明书要求的合理数据叫有效等价类，检验软件是否实现了规定的功能；不合理或非法的数据叫无效等价类，检验软件的容错性。有效验功能、无效验容错，这个分工本身是考点。
明
阿明
设计用例的时候，两类是一锅端吗？
雅
小雅
恰恰相反，这是本章最经典的一道题。三步走：第一步，对每一个输入条件确定若干个有效等价类和无效等价类并编号；第二步，设计一个测试用例，覆盖尽可能多的尚未被覆盖的有效等价类，重复直到全覆盖；第三步画风突变——每个测试用例只覆盖一个无效等价类，重复直到全覆盖。
明
阿明
有效的能一网打尽，无效的必须一个个来？
雅
小雅
对，原文的理由是：无效等价类用来测试非正常的输入数据，每个都有可能查出软件中的错误，所以要为每个无效等价类设计一个测试用例。为什么——把两个非法输入塞进同一个用例，程序在第一个就报错返回，第二个根本没被测到。问「正确的做法」，选「每个无效等价类单独设计一个测试用例」；「覆盖尽可能多的无效等价类」偷换概念，那句话只对有效等价类成立。口诀：有效合并测，无效拆开测。
明
阿明
边值分析就是专挑边界的数？
雅
小雅
对。经验表明，软件在处理边界情况时最容易出错，所以设计恰好运行在边界附近的用例，暴露错误的可能性更大。做法是每个等价类的边界都着重测试，取恰好等于、稍小于或稍大于边界值；等价类划分和边值分析结合使用，更有可能发现错误。
明
阿明
错误推测和因果图呢？
雅
小雅
错误推测靠经验和直觉：不同类型的软件通常又有一些特殊的容易出错的地方，从各种可能的方案中选出一些最可能引起程序出错的方案。因果图的「因」是输入条件、「果」是输出结果：先检查输入条件的各种组合情况，找出输出结果对输入条件的依赖关系，再为每种组合设计测试用例。
明
阿明
测出问题后，缺陷怎么归类？
雅
小雅
根据 IEEE 标准和 Paul C.Jorgensen 的教科书，缺陷主要分五类：输入/输出错误，如不接收正确的输入、输出结果有误；逻辑错误，如遗漏情况、极端条件出错、错误的操作符；计算错误，如不正确的算法、括号错误；接口错误，如调用了错误或不存在的过程、参数不匹配；数据错误，如不正确的初始化、数据溢出。归类口诀——想错归逻辑、算错归计算、接错归接口、数据坏归数据。
明
阿明
严重程度总得有标尺吧？
雅
小雅
Beizer 按错误后果的严重程度分十级：一级轻微，个别错别字不影响理解；二级中等，文字错误可能误导操作者；三级使人不悦，数字串被断开；四级影响使用，有些交易没有处理；五级严重，丢失交易；六级非常严重，不正确的交易处理；七级极为严重，经常出现不正确的交易处理；八级无法容忍，数据库遭到破坏；九级灾难性，系统无法工作；十级传染性，可导致其他系统无法工作。考题爱拿「数据库遭到破坏」这类描述反问第几级。
明
阿明
知道缺陷在哪是一回事，挖出来是另一回事。
雅
小雅
排错又称调试，与成功的测试形影相随——测试成功的标志是发现了错误，再根据错误迹象确定错误的原因和准确位置并加以改正。熬人，是因为隐藏在程序中的错误有八条特殊性质：征兆远离内部原因；纠正一个错误造成另一现象暂时消失；某些征兆只是假象；操作疏忽的征兆不易追踪；错误由分时而不是程序引起；输入条件难以精确地再构造；征兆时有时无、对嵌入式系统尤其普遍；任务分布在多台处理机上造成。
雅
小雅
排错策略三类。原始类最常用也最低效，万般无奈才用，主要思想是「通过计算机找错」——输出存储器、寄存器的内容，在程序中安排若干输出语句，凭借大量现场信息找线索。回溯类从出现错误征兆处开始，人工地沿控制流程往回追踪，直至发现出错的根源；程序变大后人工完全回溯可望而不可即。排除类基于归纳和演绎原理，采用「分治」概念——分析与错误出现有关的所有数据，假想一个错误原因，证明或反驳它；或列出所有可能原因，通过测试一一排除。
明
阿明
考题问「排除类基于的原理」，干扰项有计算机找错、回溯、现场信息。
雅
小雅
选「基于归纳和演绎原理，采用分治概念，假想错误原因并测试排除」。干扰项各归各家：计算机找错加现场信息是原始类，沿控制流程回溯是回溯类。反着考也要会——看到「输出存储器寄存器内容」选原始类，看到「沿控制流程往回追踪」选回溯类。
明
阿明
测完调完，评审登场。它是个什么动作？
雅
小雅
根据 IEEE 1028 的定义，评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。八种评审前四种跟着开发阶段走：需求评审在需求分析结束后，确保各项需求的合适性；概要设计评审在概要设计结束后，评价总体结构、外部接口、主要部件功能分配、全局数据结构及部件之间接口；详细设计评审在详细设计结束后，评价每个基本部件的功能、算法和过程描述；验证和确认评审在验证与确认计划完成后，评价方法的合适性与完整性。
明
阿明
后四种挂在什么时点？
雅
小雅
记四个词：释放前、验收前、验收时、定期。功能检查在软件释放前，验证软件已满足需求说明书规定的所有需求；物理检查在软件验收前，验证程序和文档一致并做好交付准备；综合检查在软件验收时，由用户或其委托的专家设计抽样，验证四个一致性——代码和设计文档、接口规格说明、设计实现和功能需求、功能需求和测试描述；管理评审定期或按阶段进行，必须由独立于被评审单位的机构或授权的第三方主持。
明
阿明
评审的八条注意事项，出题人爱拿它做场景判断。
雅
小雅
最容易混的四条。不应以测试代替评审：许多缺陷在早期阶段引入，发现得越晚纠正费用越高，早期阶段可以进行评审但无法进行测试，评审的目的就是减少泄漏到测试阶段的缺陷，而且测试不能发现某些特定类型的缺陷，例如违犯编程规范。评审人员应关注产品而不应评论开发人员，否则评审变成「批斗大会」。应关注实质性问题，别揪着文档格式、措词。评审会议不应变为问题解决方案讨论会，解决问题是会后的事。
雅
小雅
后四条：评审应被安排进入项目计划，不该临时安排；参与者应了解整个评审过程；评审人员事先应对评审材料充分了解，否则评审会变成技术报告会；应重视评审的组织工作。真题问「软件评审过程中正确的做法」，选「评审产品而不是评审设计者，不能使设计者有压力」——三个干扰项恰好都是原文明确反对的做法。
明
阿明
评审讲完，验证和确认这对双胞胎总算来了。
雅
小雅
先记共同点：验证与确认都是确定软件产品是否满足其预期要求和条件的过程。区别一句话：验证可适用于分析、设计、编码、测试和评审等众多的过程，而确认通常用于验收过程。真题考「验证与确认的区别」就选这句；「确认是过程检查、验证是产品检查」是反着说，「验证用于验收、确认用于分析设计编码」是张冠李戴，「两者完全相同」是和稀泥。
明
阿明
验证具体验些什么？
雅
小雅
验证一般包括七项：合同、过程、需求、设计、编码、集成、文档验证。准则抓关键词——需求验证：明确、一致、无歧义、可行、可测试；设计验证：设计正确并能实现需求、可从需求导出设计也可反向追踪；编码验证：编码正确、可从设计导出编码也可反向追踪；集成验证：软件部件单元、系统的硬件软件和人工操作都完整正确地集成；文档验证：充分完备一致、及时、配置管理遵循规程。
雅
小雅
确认可以是组织内部的，也可以由独立的第三方实施。确认过程的四项任务连成一条线：编写测试需求、测试用例和测试规程；确保它们可以反映软件产品的预期用途；执行测试；确认软件产品满足其预期用途。四个动作——编写、确保、执行、确认。
明
阿明
测试自动化为什么值得单独一节？
雅
小雅
因为许多测试操作是重复性的、非智力创造性的、需要细致注意力的工作，计算机最适合代替人类干这些。适于自动化的测试工作五项：测试用例的生成，包括测试输入、标准输出、操作指令；测试的执行控制，包括多机分布运行、夜间及假日运行、版本控制等；测试结果与标准输出的对比；不吻合结果的分析、记录、分类和通报；总测试状况的统计和报表的产生。收尾要背：测试自动化与软件配置管理密不可分，与测试有关的资源都应在配置管理中统一考虑。
明
阿明
最后一块硬骨头：面向对象的测试，传统那套为什么不适用？
雅
小雅
传统测试策略从「小型测试」逐步走向「大型测试」。但面向对象程序不再是传统的功能模块结构，逐步把模块搭建起来测试的集成方法已不可能，也不能用功能细化的观点检测面向对象分析和设计的结果。针对 OOA、OOD、OOP 三阶段的开发模型，面向对象的测试分为六层：面向对象分析、设计、编程的测试，加上面向对象的单元测试、集成测试和系统测试。
明
阿明
单元和集成这两层变化最大吧？
雅
小雅
变化最大。单元层面，传统单元测试的对象是软件设计的最小单位——模块，依据是详细设计说明书；面向对象软件里，类和类的实例即对象封装了属性和操纵这些数据的操作，所以最小的可测试单位变成了封装的类或对象——问「最小的可测试单位」，选「封装的类或对象」，模块、函数、过程都是拿传统概念干扰你；也不再孤立地测试单个操作，而是将操作作为类的一部分来测。
雅
小雅
集成层面，面向对象的软件没有层次控制结构，传统的自顶向下和自底向上集成策略已无太大意义。OO 集成测试两种策略：基于线程的测试，集成系统的一个输入或事件所需的一组类，每个线程分别测试并使用回归测试，以保证没有产生副作用；基于使用的测试，首先测试那些几乎不使用其他类的独立类，再逐层测试使用独立类的依赖类，直到构造完整个系统。
雅
小雅
真题问「基于线程的测试策略」，选「集成系统的一个输入或事件所需的一组类，每个线程分别测试并使用回归测试」——「从主控模块开始按控制层次结构逐步集成」是传统自顶向下，「从最低层模块开始组装」是传统自底向上，「首先测试几乎不使用其他类的独立类」是 OO 的基于使用策略。
明
阿明
到这全章讲完了，必背清单我来起个头，师姐把关。
雅
小雅
第一块测试方法：黑盒用于集成和确认测试阶段、白盒用于单元测试阶段；条件组合覆盖是前五种覆盖里最强的，路径覆盖不能替代它；等价类划分用得最多，有效验功能、无效验容错，有效合并覆盖、每个无效等价类单独一个用例；错误推测靠直觉、因果图抓因果关系。缺陷分输入输出、逻辑、计算、接口、数据五类；Beizer 十级轻微到传染性；排错三策略——原始类计算机找错、回溯类沿控制流程回溯、排除类归纳演绎加分治。
雅
小雅
评审与验证：八种评审前四种跟着需求分析、概要设计、详细设计、验证与确认计划走，功能检查释放前、物理检查验收前、综合检查验收时、管理评审第三方定期主持；评审八注意核心是产品不评人、事先熟悉材料；验证适用于分析设计编码测试评审众多过程，确认通常用于验收过程。第三块面向对象：测试六层，最小可测试单位是封装的类或对象，集成用基于线程和基于使用两种策略，
明
阿明
清单齐了。框架、白盒、黑盒加评审，这条线我串起来了。
雅
小雅
那就趁热去做第 11 章练习题，错题对回原文再听对应段落。下一章讲嵌入式系统设计，硬件软件怎么配合、实时性怎么保证，又是一片新天地。