测试评审方法 · 软件评审与测试管理

根据 IEEE 1028 的定义，评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。狭义评审指软件文档和源程序的评审，广义还包括与软件测试相结合的评审及管理评审。完整的软件评审有八种，前四种跟着开发阶段走：软件需求评审在需求分析结束后进行，确保需求说明书中各项需求的合适性；概要设计评审在概要设计结束后进行，评价总体结构、外部接口、主要部件功能分配、全局数据结构及主要部件之间接口的合适性；详细设计评审在详细设计结束后进行，评价每个基本部件的功能、算法和过程描述的合适性；软件验证和确认评审在验证与确认计划完成后进行，评价计划中验证与确认方法的合适性与完整性。

记四个词：释放前、验收前、验收时、定期。功能检查在软件释放前，验证软件已满足需求说明书规定的所有需求；物理检查在软件验收前，验证程序和文档已经一致并做好交付准备；综合检查在软件验收时，允许用户或用户委托的专家进行设计抽样的综合检查，验证四个一致性——代码和设计文档、接口规格说明包括硬件和软件、设计实现和功能需求、功能需求和测试描述；管理评审对计划的执行情况定期或按阶段进行，必须由独立于被评审单位的机构或授权的第三方主持。

我挑最容易混的四条说。一，不应以测试代替评审：许多缺陷在早期阶段引入，发现得越晚纠正费用越高，每个进入下一步骤的缺陷都可能引起下一步骤的多个缺陷；早期阶段可以进行评审但无法进行测试，评审的目的就是减少泄漏到测试阶段的缺陷，而且测试不能发现某些特定类型的缺陷，例如违犯编程规范。二，评审人员应关注产品而不应评论开发人员——目的是发现产品中的问题，不是评价开发人员的水平，否则评审变成「批斗大会」。三，评审人员应关注于实质性问题，别揪着文档格式、措词不放。四，评审会议不应变为问题解决方案讨论会，评审会是发现问题的地方，解决问题是会后的事。

后四条快过：评审应被安排进入项目计划，不该临时安排；评审参与者应了解整个评审过程，否则会有抗拒情绪；评审人员事先应对评审材料充分了解，否则评审会变成技术报告会；应重视评审的组织工作，会议时间、通知、场所、设施、气氛都影响效果。真题问「软件评审过程中正确的做法」，选「评审产品而不是评审设计者，不能使设计者有压力」——另外三个选项「以测试代替评审」「评审会议变为问题解决方案讨论会」「评审人员不需要事先了解材料」，恰好都是原文明确反对的做法，等于把注意事项反过来出题。

先记共同点：验证与确认都是确定软件产品是否满足其预期要求和条件的过程。区别一句话：验证可适用于分析、设计、编码、测试和评审等众多的过程，而确认通常用于验收过程。真题考「验证与确认的区别」就选这句；「确认是过程检查、验证是产品检查」是反着说，「验证用于验收、确认用于分析设计编码」是张冠李戴，「两者完全相同」是和稀泥。

软件项目的验证一般包括七项：合同验证、过程验证、需求验证、设计验证、编码验证、集成验证和文档验证。各自的准则抓关键词——合同验证：供方具有满足需求的能力、需求一致并覆盖用户的需要、规定了处理需求变更和升级的规程、规定了各方接口与合作规程包括所有权许可权版权保密、按照需求规定了验收准则和规程。过程验证：项目适当及时、所选过程满足合同要求、标准规程环境适当、配备了经过培训的人员。

需求验证：需求明确、一致、无歧义、可行、可测试。设计验证：设计正确并能实现需求、可以从需求导出设计也可以从设计追踪需求。编码验证：编码正确并能实现设计和需求、可以从设计导出编码也可以反向追踪。集成验证：软件部件和单元、系统的硬件项软件项和人工操作都已完整正确地集成。文档验证：文档充分完备一致、制订及时、配置管理遵循规程。

确认可以是组织内部的，也可以由独立的第三方实施。确认过程的四项任务连成一条线：编写测试需求、测试用例和测试规程；确保它们可以反映软件产品的预期用途；执行测试；确认软件产品满足其预期用途。四个动作——编写、确保反映预期用途、执行、确认。

因为测试工作量很大，而许多测试操作是重复性的、非智力创造性的、需要细致注意力的工作，计算机最适合代替人类干这些，测试自动化会对开发工作的质量、成本和周期带来明显效果。适于自动化的测试工作五项：测试用例的生成，包括测试输入、标准输出、测试操作指令；测试的执行控制，包括单机与网络多机分布运行、夜间及假日运行、测试用例调用控制、测试对象范围版本控制等；测试结果与标准输出的对比；不吻合的测试结果的分析、记录、分类和通报；总测试状况的统计和报表的产生。收尾一句要背：测试自动化与软件配置管理密不可分，与测试有关的资源都应在配置管理中统一考虑。

传统测试策略从「小型测试」逐步走向「大型测试」，从单元到集成再到系统。但面向对象程序的结构不再是传统的功能模块结构，原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已成为不可能，也不可能用功能细化的观点来检测面向对象分析和设计的结果，所以传统测试模型已不再适用。针对 OOA、OOD、OOP 三阶段的开发模型，面向对象的测试分为六层：面向对象分析的测试、面向对象设计的测试、面向对象编程的测试、面向对象的单元测试、面向对象的集成测试和面向对象的系统测试。

变化最大。单元层面，传统单元测试的对象是软件设计的最小单位——模块，测试依据是详细设计说明书，多采用白盒测试技术；而面向对象软件里，每个类和类的实例即对象封装了属性和操纵这些数据的操作，而不是个体的模块，所以最小的可测试单位变成了封装的类或对象——问「面向对象测试模型中最小的可测试单位」，选「封装的类或对象」，模块、函数、过程都是拿传统概念干扰你，而且不再孤立地测试单个操作，而是将操作作为类的一部分来测。

集成层面，面向对象的软件没有层次控制结构，传统的自顶向下和自底向上集成策略已无太大意义，一次集成一个操作到类中的传统增量方法通常也不可能。OO 集成测试两种策略：基于线程的测试，集成系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，并使用回归测试以保证没有产生副作用；基于使用的测试，首先测试那些几乎不使用其他类的类，称为独立类，并开始构造系统，独立类测完后，下一层使用独立类的依赖类被测试，这个测试序列持续到构造完整个系统。

真题问「基于线程的测试策略」，选「集成系统的一个输入或事件所需的一组类，每个线程分别测试并使用回归测试」——「从主控模块开始按控制层次结构逐步集成」是传统自顶向下，「从最低层模块开始组装」是传统自底向上，「首先测试几乎不使用其他类的独立类」是 OO 的基于使用策略，三个干扰项分属三套体系，看关键词对号入座。

全章必背分三块。第一块测试方法：黑盒用于集成和确认测试阶段、白盒用于单元测试阶段；等价类划分是黑盒中用得最多的方法，有效等价类验功能、无效等价类验容错，有效等价类合并覆盖、每个无效等价类单独一个用例；边值取恰好等于、稍小于、稍大于边界值；错误推测靠经验直觉；因果图按输入与输出的因果关系设计。缺陷分输入输出、逻辑、计算、接口、数据五类；Beizer 十级从轻微到传染性；排错三策略——原始类计算机找错、回溯类沿控制流程回溯、排除类归纳演绎加分治。

第二块评审与验证：IEEE 1028 说评审是对软件元素或项目状态的评估手段；八种评审——需求评审、概要设计评审、详细设计评审、验证与确认评审，加功能检查在释放前、物理检查在验收前、综合检查在验收时验证四个一致性、管理评审由独立第三方定期主持；评审八注意核心是产品不评人、发现问题不解决问题、事先熟悉材料。验证适用于分析设计编码测试评审众多过程，确认通常用于验收过程；确认四任务是编写、确保反映预期用途、执行、确认。第三块其余：自动化五项从用例生成到统计报表，与配置管理密不可分；面向对象测试六层，最小可测试单位是封装的类或对象，集成用基于线程和基于使用两种策略。

那就趁热去做第 11 章的练习题，把错题对回原文再听对应段落。下一章我们讲嵌入式系统设计，硬件软件怎么配合、实时性怎么保证，又是一片新天地。