1软件测试22.1 软件测试技术概述2.2 软件测试的分类与流程策略2.3 静态测试与动态测试概述2.4 软件测试的评审技术第二章第二章 测试方法概述与静态分析测试方法概述与静态分析32.1.1 软件测试技术的分类2.1.2 软件测试技术间的关系2.1.3 软件测试技术的选择2.1 2.1 软件测试技术概述软件测试技术概述4 从不同的角度，可以对软件测试方法进行分成不同种类p 执行代码p 程序结构p 开发过程p 功能性能 2.1.1 2.1.1 软件测试技术分类软件测试技术分类5 1 1、从是否执行代码来分、从是否执行代码来分u 静态测试：不实际运行被测试软件，只静态地检查程序代码、界面或文档中可能存在的错误的过程u 动态测试：实际运行被测试程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程2.1.1 2.1.1 软件测试技术分类软件测试技术分类6 2 2、从是否需了解程序结构来分从是否需了解程序结构来分黑盒测试（Black-Box Testing）、白盒测试（White-Box Testing）、灰盒测试黑盒测试：黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。
是一种从用户观点出发的测试，主要以软件规格说明书为依据，对程序功能和程序接口进行的测试白盒测试：白盒测试（White-box Testing）也称为结构测试或逻辑驱动测试，是在知道产品的内部工作过程，通过测试来检测产品内部动作是否按照规格说明书的规定正常进行2.1.1 2.1.1 软件测试方法分类软件测试方法分类7工程硕士7黑盒测试和白盒测试？X=2Y=4黑盒y=2xX=2Y=4白盒2.1.1 2.1.1 软件测试技术分类软件测试技术分类8灰盒测试：灰盒测试介于白盒测试和黑盒测试之间，是现代测试的一种理念就是指在白盒测试中交叉使用黑盒测试的方法；在黑盒测试中交叉使用白盒测试的方法2.1.1 2.1.1 软件测试技术分类软件测试技术分类9 3 3、从软件测试策略或过程来分、从软件测试策略或过程来分 单元测试(Unit Testing)集成测试(Integration Testing)确认测试(Validation Testing)系统测试(System Testing)验收测试(Verification Testing)2.1.1 2.1.1 软件测试技术分类软件测试技术分类10单元测试对程序中最小可测试单元进行检查和验证。
集成测试将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部分确认测试：检验所开发的软件能否满足所有功能和性能需求的最后 手段系统测试集成测试完成之后，将整个系统看成整体进行测试，包括功能、性能以及运行的软硬件环境用户验收测试系统测试的后期，以用户测试为主，按照功能需求说明书以及用户手册为标准测试整个系统，保证软件达到可以交付使用的状态2.1.1 2.1.1 软件测试技术分类软件测试技术分类11 4 4、从软件测试的作用来分、从软件测试的作用来分功能测试：检查软件的功能是否符合用户的需求，包括：逻辑功能测试界面测试易用性测试安装测试兼容性测试非功能测试：对系统功能之外的特性进行测试，包括：性能测试安全测试强度测试容量测试2.1.1 2.1.1 软件测试技术分类软件测试技术分类122.1.2 2.1.2 软件测试软件测试技术技术间的关系间的关系13工程硕士13不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术也称为静态分析技术实际运行程序，并通过观察程序运行的实际结果来发现错误的软件测试技术在不知道程序内部结构，只知道程序规格的情况下采用的测试技术或策略。
在知道程序内部结构的情况下采用的测试技术或策略开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动一般有正式的计划、流程和结果报告开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动一般有正式的计划、流程和结果报告2.1.2 2.1.2 软件测试软件测试技术技术间的关系间的关系14工程硕士14针对要求的程序功能，按照规范的流程进行的测试针对要求的程序功能以外的其他要求，包括性能、安全、配置、负载等指标，按照规范的流程进行的测试针对要求的程序功能、性能、安全、配置、负载等指标，基于破坏目的、按照经验进行的随机测试程序修改或者版本更新以后，为了确保以前正确的功能和其他指标仍旧正确，而重新进行的测试在测试过程中，选择足够的测试用例，使得每一个可执行语句至少被执行一次在测试过程中，选择足够的测试用例，使得程序中的每一个分支判断的每一种可能结果都至少被执行一次在测试过程中，选择足够的测试用例，使得程序中的每一条可能执行的路径都至少执行一次。
15n 单元测试 测试方法：白盒测试 参考规范：详细设计说明和代码结构n 集成测试 测试方法：黑盒测试和白盒测试 参考规范：详细设计说明和概要设计说明n 系统测试 测试方法：黑盒测试 参考规范：概要设计和需求规格说明n 可接受性测试 测试方法：黑盒测试 参考规范：需求规格说明n 回归测试 测试方法：黑盒测试和白盒测试 参考规范：需求变更文档和概要设计说明2.1.3 2.1.3 软件测试软件测试技术技术的选择的选择162.2.1 软件测试的分类2.2.2 软件测试的流程2.2.3 软件测试的策略2.2 2.2 软件测试的分类与流程策略软件测试的分类与流程策略172.2.1 2.2.1 软件测试的分类软件测试的分类 从不同的角度，软件测试有多种不同的分类p 测试范围p 测试目的p 测试对象p 测试过程p 其它 18 1 1、按测试范围来分、按测试范围来分u 单元测试u 组件测试u 集成测试u 系统测试u 验收测试u 安装测试2.2.1 2.2.1 软件测试的分类软件测试的分类19 2 2、按测试目的来分、按测试目的来分u 正确性测试 白盒测试 黑盒测试 u 性能测试u 可靠性测试 强壮性测试 异常处理测试 负载测试u 安全性测试2.2.1 2.2.1 软件测试的分类软件测试的分类20 3 3、按测试对象来分、按测试对象来分u 单元测试u 组件测试u 模块测试u 程序测试u 系统测试u 文档测试2.2.1 2.2.1 软件测试的分类软件测试的分类21 4 4、按测试过程来分、按测试过程来分u 需求阶段测试u 设计阶段测试u 程序阶段测试u 测试结果评估u 安装测试u 测试变化：维护2.2.1 2.2.1 软件测试的分类软件测试的分类22 5 5、其它测试、其它测试（P38P38）u 回归测试u 压力测试u 恢复测试u 兼容性测试2.2.1 2.2.1 软件测试的分类软件测试的分类23 1 1、软件测试的阶段划分、软件测试的阶段划分 软件测试是由一系列不同测试阶段组成的，这些阶段分为：规格说明书审查、系统和程序设计审查、单元测试、集成测试、功能测试、确认测试、系统测试、验收测试和安装测试。
P39P39）规格说明书审查：系统和程序设计审查：单元测试：集成测试：功能测试：确认测试系统测试：验收测试 安装测试2.2.2 2.2.2 软件测试的流程软件测试的流程24 2 2、从软件测试流程、从软件测试流程2.2.2 2.2.2 软件测试的流程软件测试的流程 从软件开发来看252.2.2 2.2.2 软件测试的流程软件测试的流程 从软件测试来看26 1 1、软件测试策略的概念、软件测试策略的概念 测试策略通常是描述测试工程的总体方法和目标描述目前在进行哪一阶段的测试（如单元测试、集成测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等），以确定合理的测试方案使得测试更有效2.2.3 2.2.3 软件测试的策略软件测试的策略27 2 2、软件测试策略的原则、软件测试策略的原则p 全面细致地了解产品的项目信息全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构p 全面细致地分析影响产品的因素：全面细致地分析影响产品的因素：基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素p 客观严格地执行测试计划：客观严格地执行测试计划：p 制定出度量测试等级和测试重点的标准：制定出度量测试等级和测试重点的标准：一般是根据程序的重要性和一旦发生故障将造成的损失来确定。
p 使用尽可能少的有效测试用例使用尽可能少的有效测试用例,发现尽可能多的程序错误是策略制发现尽可能多的程序错误是策略制订的目标：订的目标：一次完整的软件测试后,如果程序中遗漏的错误过多且很严重,则表明本次测试是失败的或不足的;而测试不足意味着让用户承担隐藏错误带来的危险反过来,如果过度测试,又会浪费许多宝贵的资源找到一个最佳平衡点2.2.3 2.2.3 软件测试的策略软件测试的策略28 3 3、软件测试策略制订的输入输出、软件测试策略制订的输入输出（P55P55）p 输入输入 p 输出输出2.2.3 2.2.3 软件测试的策略软件测试的策略292.3.1 静态测试2.3.2 动态测试2.3.3 黑盒测试2.3.4 白盒测试2.3.5 黑盒与白盒测试的比较2.3 2.3 静态测试与动态测试概述静态测试与动态测试概述静态测试与动态测试的比喻30 1 1、静态测试及其特征、静态测试及其特征 静态测试是对被测程序进行特性分析的方法总称，由于并不真正运行被测试的程序，只对被测程序进行特性分析，因此常称为“静态分析”所谓静态分析是指不需要执行测试程序，只是通过扫描程序正文，对程序的数据流和控制流等信息进行分析，找出系统的缺陷，得出测试报告。
静态测试包括代码检查、静态结构分析、代码质量度量等它可以由人工进行，以发挥人的逻辑思维优势，也可以借助软件工具自动进行2.3.1 2.3.1 静态测试静态测试31 特别地，静态分析的差错分析功能是编译程序所不能替代的编译系统虽然能发现某些程序错误，但这些错误远非软件中存在的大部分错误目前，已经开发了一些静态分析系统作为软件静态测试的工具，静态分析已被当作一种自动化的代码校验方法2.3.1 2.3.1 静态测试静态测试32 2 2、静态测试的活动、静态测试的活动 检查算法的逻辑正确性，确定算法是否实现了所要求的功能；检查模块接口的正确性，确定形参的个数、数据类型、顺序是否正确，确定返回值类型及返回值的正确性；检查输入参数是否有合法性检查如果没有合法性检查，则应确定该参数是否不需要合法性检查，否则应加上参数的合法性检查；2.3.1 2.3.1 静态测试静态测试33 检查调用其他模块的接口是否正确，检查实参类型、实参个数是否正确，返回值是否正确，若被调用模块出现异常或错误，程序是否有适当的出错处理代码；检查是否设置了适当的出错处理，以便在程序出错时，能对出错部分进行重做安排，保证其逻辑的正确性；检查表达式、语句是否正确，是否含存在二义性。
如表达式或运算符的优先级：=、&、|、+、-等；检查常量或全局变量使用是否正确；检查标识符的使用是否规范、一致，变量命名是否能够望名知义、简洁、规范和易记；2.3.1 2.3.1 静态测试静态测试34 检查程序风格的一致性、规范性，代码是否符合行业规范，是否所有模块的代码风格一致、规范；检查代码是否可以优化，算法效率是否最高；检查代码注释是否完整，是否正确反映了代码的功能，并查找错误的注释2.3.1 2.3.1 静态测试静态测试35 不同的测试方法各自的目标和侧重点不一样，在实际工作中要将静态测试和动态测试结合起来，以达到更加完美的效果1 1、动态测试及其特征、动态测试及其特征 动态方法是通过源程序运行时所体现出来的特征，来进行执行跟踪、时间分析以及测试覆盖等方面的测试动态测试是真正运行被测程序，在执行过程中，通过输入有效的测试用例，对其输入与输出的对应关系进行分析，以达到检测的目的2.3.2 2.3.2 动态测试动态测试36 2 2、动态测试的基本步骤、动态测试的基本步骤 选取定义域的有效值，或选取定义域外的无效值；对已选取值决定预期的结果；用选取值执行程序；执行结果与预期的结果相比，不吻合则说明程序有错。
3 3、动态测试方法的类型、动态测试方法的类型 在动态测试中，又可有基于程序结构的白盒测试（或称为覆盖测试）和基于功能的黑盒测试2.3.2 2.3.2 动态测试动态测试37 1 1、黑盒测试的定义、黑盒测试的定义 黑盒测试也称作功能测试和行为测试，是指根据功能需求来测试程序是否按照预期工作黑盒测试是一种从用户观点出发的测试，主要以软件规格说明书为依据，对程序功能和程序接口进行的测试黑盒测试把系统被看成一个不透明的黑匣，在完全不考虑软件内部结构和处理过程的情况下验证系统是否达到用户需求黑盒测试的示意图如图所示，从图可以看出黑盒测试只考虑程序的输入和输出，无须考虑程序的内部代码2.3.3 2.3.3 黑盒测试黑盒测试382.3.3 2.3.3 黑盒测试黑盒测试黑盒测试过程示意图 39 黑盒测试有两种基本思想，即通过测试和失败测试在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何，软件测试人员只是运用最简单、最直观的测试用例在设计和执行测试用例时，总是先要进行通过测试，验证软件的基本功能是否都已实现在确信了软件正确运行之后，就可以采取各种手段通过搞垮软件来找出缺陷纯粹为了破坏软件而设计和执行的测试用例，被称为失败测试或迫使出错测试。
2.3.3 2.3.3 黑盒测试黑盒测试40 2 2、黑盒测试的基础、黑盒测试的基础 黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么黑盒测试作为软件功能的测试手段，是重要的测试方法它主要根据规格说明设计测试用例，并不涉及程序内部结构和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例2.3.3 2.3.3 黑盒测试黑盒测试41 3 3、黑盒测试的目的、黑盒测试的目的 如果外部特性本身有问题或规格说明书的规定有误，黑盒测试方法显然是发现不了的黑盒测试方法着重测试软件的功能需求，是在程序接口上进行测试，其目的主要是为了发现以下错误：u 是否有不正确的功能，是否有遗漏的功能；u 在接口上，是否能够正确地接收输入数据并产生正确的输出结果；u 是否有数据结构错误或外部信息访问错误；u 性能上是否能够满足要求；u 是否有程序初始化和终止方面的错误2.3.3 2.3.3 黑盒测试黑盒测试42 4.4.黑盒测试的特点黑盒测试的特点 黑盒测试有两个显著的特点：u 黑盒测试不考虑软件的具体实现过程，当在软件实现的过程发生变化时，测试用例仍然可以使用；黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。
u 黑盒测试不仅能够找到大多数其他测试方法无法发现的错误，而且一些外购软件、参数化软件包以及某些自动生成的软件，由于无法得到源程序，只能选择黑盒测试2.3.3 2.3.3 黑盒测试黑盒测试43 1 1、白盒测试的定义、白盒测试的定义 白盒测试也称作结构测试或逻辑驱动测试，是一种基于程序内部实现结构和逻辑寻找缺陷的测试技术，它根据程序的控制结构设计测试用例白盒测试（White-box Testing）是在知道产品内部工作过程的情况下，通过测试来检测产品内部动作是否按照规格说明书的规定正常进行按照程序内部的结构检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能白盒测试是一种可视的测试方法，即把测试对象看作一个透明的盒子，测试人员要了解程序结构和处理过程白盒测试的过程如图所示2.3.4 2.3.4 白盒测试白盒测试44 源程序测试用例被测程序执行路径分析覆盖情况分析白盒测试过程示意图 2.3.4 2.3.4 白盒测试白盒测试45 2 2、白盒测试的必要性、白盒测试的必要性 逻辑错误和不正确假设与一条程序路径被运行的可能性成反比程序的逻辑流往往和直觉不一样笔误是随机功能测试本身有局限。
2.3.4 2.3.4 白盒测试白盒测试46 3 3、白盒测试的目的、白盒测试的目的 在对被测软件进行白盒测试时，主要对程序进行以下几个方面的检查u 保证一个模块中的所有独立执行路径至少测试一次；u 对所有逻辑判定取值“true”和“false”的两种情况都至少测试一次；u 在循环边界和运行界限内执行循环体；u 测试内部数据结构的有效性2.3.4 2.3.4 白盒测试白盒测试47 4 4、白盒测试的应用、白盒测试的应用 在软件测试领域，有六种基本的测试类型：单元测试，集成测试，功能测试/系统测试，可接受性测试，回归测试和Beta测试白盒测试可以用在其中的三种测试类型中：单元测试 集成测试 回归测试2.3.4 2.3.4 白盒测试白盒测试48 5、白盒测试与调试的不同点、白盒测试与调试的不同点 从承担的任务来看，白盒测试同其他类型测试一样，它的任务是发现所开发的项目中的缺陷；但调试不属于测试，其任务是纠正软件中的缺陷从最终的结果来看，白盒测试有预知结果，不可预知的只是程序是否通过测试，且成功测试的结果是发现错误的症状，从而引起调试的进行；而调试的结果是消除项目中的错误从执行的过程来看，测试是一个发现错误、改正错误、重新测试的过程；而调试是一个推理过程。
2.3.4 2.3.4 白盒测试白盒测试49 从准备工作来看，测试从已知的条件开始，使用预先定义的程序；调试一般是以不可知的内部条件开始，做统一性调试从执行的计划性来看，测试是有计划的并要进行测试设计；而调试则不受时间约束从执行的人员来看，测试经常是由独立的测试组在不了解软件设计的条件下完成的，而调试必须由程序员来完成从所使用的工具来看，大多数白盒测试的执行和设计可有工具支持，而调试程序员能利用的工具主要是调试器2.3.4 2.3.4 白盒测试白盒测试50 1 1、白盒测试的优缺点白盒测试的优缺点u优点 可构成测试数据对特定程序部分测试，可以检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；有较多工具支持；有一定的充分性度量手段2.3.5 2.3.5 黑盒与白盒测试的比黑盒与白盒测试的比较较51u缺点 工作量大,成本高通常只用于单元测试，有应用局限；无法检测代码中遗漏的路径和数据敏感性错误；不能验证规格说明的正确性；无法对规格说明中未实现的部分进行测试；不易生成测试数据(通常)2.3.5 2.3.5 黑盒与白盒测试的比黑盒与白盒测试的比较较52 2 2、黑盒测试的优缺点黑盒测试的优缺点u优点 对于较大的代码单元来说，效率高；测试人员不需要了解实现的细节，包括具体的编程语言；测试员和程序员可以由不同的人员来担任；从用户的角度进行测试，容易被理解和接受；有助于暴露任何规格不一致或有歧义的问题；测试用例的设计可以在规格说明完成之后马上进行；容易入手生成测试数据；适用于各阶段测试。
2.3.5 2.3.5 黑盒与白盒测试的比黑盒与白盒测试的比较较53u缺点实际上，只有一小部分可能的输入被测试到，某些代码得不到测试；如果没有清晰、简洁的规格说明，难以设计测试用例；如果测试人员不知道开发人员已经执行过该测试用例，会存在不必要的重复测试；会有很多程序路径没有被测试到；不能直接针对可能隐蔽了许多问题的特定程序段进行测试；如果规格说明有误，则无法发现；不易进行充分性测试2.3.5 2.3.5 黑盒与白盒测试的比黑盒与白盒测试的比较较54 3 3、白盒测试和黑盒测试的比较白盒测试和黑盒测试的比较 白盒测试只关注软件产品的测试，不能够确保产品已经实现了规格说明中的所有功能黑盒测试则只关注规格说明中的测试，不能够保证已经实现的各个部分都被测试到与黑盒测试相比，白盒测试的成本要高一些黑盒测试是一种确认技术，回答“我们在构造一个正确的系统吗？白盒测试是一种验证技术，回答“我们在正确地构造一个系统吗？”总之，建议测试人员在进行测试的过程中，可以考虑先使用黑盒测试，然后统计相应的覆盖率，再设计适当的白盒测试用例作为补充以保证测试的完整性2.3.5 2.3.5 黑盒与白盒测试的比黑盒与白盒测试的比较较552.4.1 软件评审及其评审点2.4.2 软件评审的组织与流程2.4.3 测试和评审的比较2.4.4 软件评审方法2.4.5 软件评审2.4.6 其它软件评审2.4.7 代码走读2.4 2.4 软件测试的评审技术软件测试的评审技术56工程硕士562.4.1 2.4.1 软件评审及其评审点软件评审及其评审点 1 1、什么是软件评审什么是软件评审 软件评审是指在软件开发过程中，由参与软件评审是指在软件开发过程中，由参与评审的人员对软件开发文档或代码进行审定或评审的人员对软件开发文档或代码进行审定或检查，帮助查找缺陷和改进。
其工作内容有：检查，帮助查找缺陷和改进其工作内容有：检验产品是否满足规范，如需求或设计文档；检验产品是否满足规范，如需求或设计文档；识别产品相对于标准的偏差；识别产品相对于标准的偏差；向作者提出改进建议；向作者提出改进建议；促进技术交流和学习促进技术交流和学习57工程硕士572.4.1 2.4.1 软件评审及其评审点软件评审及其评审点 2.2.软件评审原则软件评审原则对事不对人，评审不是对责任人绩效的评价对事不对人，评审不是对责任人绩效的评价责任人保持开发思想，接受别人意见，避免争论责任人保持开发思想，接受别人意见，避免争论评审组规模保持评审组规模保持3-73-7人人评审期间要努力发现问题，但不要试图去解决问评审期间要努力发现问题，但不要试图去解决问题题会议限制在两个小时之内会议限制在两个小时之内正式评审需要事先准备正式评审需要事先准备58工程硕士58需求规格说明书需求规格说明书评审评审概要设计说明书概要设计说明书详细设计说明书详细设计说明书编码编码单元测试单元测试集成测试集成测试系统测试系统测试系统测试文档系统测试文档用户资料和培训文档用户资料和培训文档可交付产品可交付产品集成测试文档集成测试文档单元测试文档单元测试文档评审评审评审评审评审评审评审评审评审评审评审评审 3 3、软件项目中的评审点软件项目中的评审点2.4.1 2.4.1 软件评审及其评审点软件评审及其评审点5959 1.1.软件评审的角色（实例）软件评审的角色（实例）责任人：是准备要评审的信息或工作产品的人。
责任人：是准备要评审的信息或工作产品的人主审人：是评审组长，评审会议主持人，带领评审团队工作主审人：是评审组长，评审会议主持人，带领评审团队工作保证评审达到预期的目的保证评审达到预期的目的讲解员：负责在评审会议期间对被审的工作产品部分进行释讲解员：负责在评审会议期间对被审的工作产品部分进行释义，使评审组可侧重于重要信息，将注意力由责任人转向产义，使评审组可侧重于重要信息，将注意力由责任人转向产品记录员：记录下评审会议过程中的相关信息，如对预审问题记录员：记录下评审会议过程中的相关信息，如对预审问题的确认，新出现的问题等的确认，新出现的问题等评审专家：了解评审对象，是寻找评审对象与所依照的文档、评审专家：了解评审对象，是寻找评审对象与所依照的文档、标准之间存在的差异标准之间存在的差异2.4.2 2.4.2 软件评审的组织与流程软件评审的组织与流程60工程硕士60制定计划制定计划责责 任任 人人主主 审审 人人预备会议预备会议*所有评审专家所有评审专家其他出席者其他出席者准准 备备责责 任任 人人主主 审审 人人讲讲 解解 员员记记 录录 员员评审专家评审专家评审会议评审会议责责 任任 人人主主 审审 人人讲讲 解解 员员记记 录录 员员评审专家评审专家跟跟 踪踪责责 任任 人人主主 审审 人人评审专家评审专家第三次会议第三次会议*责责 任任 人人主主 审审 人人讲讲 解解 员员记记 录录 员员评审专家评审专家可评审对象可评审对象会议安排（人员，地点，时间等）会议安排（人员，地点，时间等）可交付产品可交付产品评审总结报告评审总结报告评审问题列表评审问题列表评审问题列表评审问题列表预审问题列表预审问题列表相关质量标准相关质量标准2.2.软件评审的流程软件评审的流程 2.4.2 2.4.2 软件评审的组织与流程软件评审的组织与流程61工程硕士612.4.3 2.4.3 测试和评审的比较测试和评审的比较表现形式表现形式测试：单元测试、集成测试、确认测试、测试：单元测试、集成测试、确认测试、系统测试、验收测试系统测试、验收测试评审：审查、小组评审、走查、结对编程、评审：审查、小组评审、走查、结对编程、同级桌查、轮查、临时评审同级桌查、轮查、临时评审 62工程硕士622.4.3 2.4.3 测试和评审的比较测试和评审的比较工作对象工作对象测试：编译后可运行的程序测试：编译后可运行的程序评审：需求规格说明书、架构（概要）设评审：需求规格说明书、架构（概要）设计文档、详细设计文档、项目计划、项目计文档、详细设计文档、项目计划、项目过程文档、源代码、系统界面、测试计划、过程文档、源代码、系统界面、测试计划、测试用例和数据、用户手册测试用例和数据、用户手册 63工程硕士632.4.3 2.4.3 测试和评审的比较测试和评审的比较识别缺陷的阶段识别缺陷的阶段 测试：编码完成后测试：编码完成后 评审：需求阶段、设计阶段、编码阶段、评审：需求阶段、设计阶段、编码阶段、测试阶段测试阶段 64工程硕士64识别缺陷的成效识别缺陷的成效 测试：最多识别软件所有缺陷中的测试：最多识别软件所有缺陷中的30-35%30-35%评审：最多识别软件所有缺陷中的评审：最多识别软件所有缺陷中的70-75%70-75%2.4.3 2.4.3 测试和评审的比较测试和评审的比较65工程硕士65识别缺陷的成本识别缺陷的成本 测试：识别一个重要缺陷平均花费测试：识别一个重要缺陷平均花费15-2515-25小时小时 评审：识别一个重要缺陷平均花费评审：识别一个重要缺陷平均花费 需求阶段需求阶段2-32-3小时；小时；设计阶段设计阶段3-43-4小时；小时；代码阶段代码阶段3-53-5小时；小时；测试计划测试计划3-53-5小时。
小时2.4.3 2.4.3 测试和评审的比较测试和评审的比较66工程硕士66解决缺陷的成本解决缺陷的成本 测试：消除一个重要缺陷平均花费测试：消除一个重要缺陷平均花费30-8030-80小小 时（含识别缺陷时间）开发后期识别缺时（含识别缺陷时间）开发后期识别缺陷，成本较高陷，成本较高 评审：需求及设计阶段消除一个重要缺陷评审：需求及设计阶段消除一个重要缺陷花费花费5-105-10小时；代码评审阶段消除一个重小时；代码评审阶段消除一个重要缺陷花费要缺陷花费5-155-15小时倾向于在开发前期小时倾向于在开发前期识别缺陷，成本较低识别缺陷，成本较低 2.4.3 2.4.3 测试和评审的比较测试和评审的比较67工程硕士672.4.4 2.4.4 软件评审方法软件评审方法 1 1、软件评审方法的类型软件评审方法的类型审查（审查（InspectionInspection）团队团队/技术评审（技术评审（Team Review/Technical Team Review/Technical ReviewReview）走查（走查（WalkThroughWalkThrough）结对编程（结对编程（Pair ProgrammingPair Programming）同级桌查（同级桌查（Peer DeskCheckPeer DeskCheck）临时轮查（临时轮查（Ad hoc ReviewAd hoc Review68工程硕士68Team Review/Technical Review Team Review/Technical Review WalkThrough WalkThrough Pair Programming Pair Programming Peer DeskCheckPeer DeskCheckAd hoc ReviewAd hoc ReviewInspectionInspection最正式最正式最不正式最不正式2.4.4 2.4.4 软件评审方法软件评审方法1 1、软件评审方法的类型软件评审方法的类型69工程硕士692 2、软件评审的活动、软件评审的活动2.4.4 2.4.4 软件评审方法软件评审方法70工程硕士703 3、软件评审方法的选择、软件评审方法的选择 选择的原则是工作成果产生风险的可能性越大，采用的评选择的原则是工作成果产生风险的可能性越大，采用的评审方法越正式。
审方法越正式对于需求规格说明书，因为它的不准确和不完善会给对于需求规格说明书，因为它的不准确和不完善会给软件的后期开发带来极大的风险，所以必须要采用最正式软件的后期开发带来极大的风险，所以必须要采用最正式的评审方法，比如审查或者技术评审；的评审方法，比如审查或者技术评审；核心代码的失效也会带来很严重的后果，所以也应该核心代码的失效也会带来很严重的后果，所以也应该采用审查或者技术评审的方法进行评审；采用审查或者技术评审的方法进行评审；一般的代码，采用同行桌查或者临时评审就可以满足一般的代码，采用同行桌查或者临时评审就可以满足要求了2.4.4 2.4.4 软件评审方法软件评审方法71工程硕士714 4、各评审方法的评审目标、各评审方法的评审目标2.4.4 2.4.4 软件评审方法软件评审方法72工程硕士72 1 1、什么是审查、什么是审查Michael Fagan 20Michael Fagan 20世纪世纪7070年代在年代在IBMIBM提出，提出，也被称为也被称为“正正式审查式审查”，包含制定计划、总体会议、准备、会议、返工、，包含制定计划、总体会议、准备、会议、返工、跟踪和因果分析等阶段，每个阶段都有不同的角色参与，跟踪和因果分析等阶段，每个阶段都有不同的角色参与，是有计划有结构的评审方法是有计划有结构的评审方法 FaganFagan审查方法有多种变体审查方法有多种变体Gilb/GrahamGilb/Graham方法方法High-ImpactHigh-Impact审查审查分阶段审查分阶段审查2.4.5 2.4.5 软件审查软件审查73工程硕士732 2、审查角色、审查角色作者：准备要评审的信息或工作产品的人。
作者：准备要评审的信息或工作产品的人评审组长：审查会议主持人，带领审查团队工作，保证评审评审组长：审查会议主持人，带领审查团队工作，保证评审达到预期目的达到预期目的讲解员：负责在审查会议期间对被审的工作产品进行解释，讲解员：负责在审查会议期间对被审的工作产品进行解释，使审查组侧重于重要信息，将注意力由责任人转向产品使审查组侧重于重要信息，将注意力由责任人转向产品记录者：记录审查会议过程中的相关信息，如对预审问题的记录者：记录审查会议过程中的相关信息，如对预审问题的确认、新出现的问题等确认、新出现的问题等审查专家：寻找审查对象与所依照的规范、标准之间存在的审查专家：寻找审查对象与所依照的规范、标准之间存在的差异2.4.5 2.4.5 软件审查软件审查74工程硕士743 3、审查专家的选取、审查专家的选取2.4.5 2.4.5 软件审查软件审查75工程硕士754 4、审查的流程、审查的流程制定计划制定计划作作 者者评审组长评审组长总体会议总体会议所有审查者所有审查者其他出席者其他出席者准准 备备作作 者者评审组长评审组长读读 者者记记 录录 者者审查专家审查专家审查包审查包会议公告会议公告作者目标作者目标缺陷检查表缺陷检查表规则表规则表规格说明或规格说明或前期资料前期资料排印错误排印错误清清 单单初始可交付初始可交付产产 品品转下页转下页2.4.5 2.4.5 软件审查软件审查76工程硕士76审查流程（续）返返 工工作作 者者跟跟 踪踪作作 者者验证者验证者会会 议议作作 者者评审组长评审组长读读 者者记记 录录 者者审查专家审查专家审查总结报告审查总结报告审查经验教训审查经验教训排印错误排印错误清清 单单初始可交付初始可交付产产 品品接上页接上页因果分析因果分析审查者审查者质保工程师质保工程师问题日志问题日志过程改进过程改进修改后的修改后的可交付产品可交付产品基线化的基线化的可交付产品可交付产品2.4.5 2.4.5 软件审查软件审查77工程硕士77 1 1、技术评审技术评审 有时简称为“评审”或“轻型审查”，是有计划有结构的评审，但没有审查正式也没有审查严格，讲解角色可以由评审组长代替。
审查的组织与流程，适用于技术评审技术评审方法发现问题的数量是审查的2/32.4.6 2.4.6 其它软件评审其它软件评审78工程硕士78 2 2、走查走查由产品作者将产品向一组同事介绍，希望他们给出意见由产品作者将产品向一组同事介绍，希望他们给出意见是为了满足作者的需要而不是达到预期的质量目标是为了满足作者的需要而不是达到预期的质量目标一种非正式的评审一种非正式的评审通常不按照事先预定的过程进行通常不按照事先预定的过程进行不制定详细的准出条件不制定详细的准出条件不需要管理报告不需要管理报告不测量不测量 走查可以采用正式或不正式的的流程进行走查可以采用正式或不正式的的流程进行 走查发现问题的数量是审查的走查发现问题的数量是审查的1/21/22.4.6 2.4.6 其它评审方法其它评审方法79工程硕士79 3 3、结对编程结对编程两个开发者在一个电脑上同时操作一个程序，两个开发者在一个电脑上同时操作一个程序，每一行代码都由两个人共同编写每一行代码都由两个人共同编写一种非正式的评审一种非正式的评审没有结构和制定流程，不需要准备和评审文没有结构和制定流程，不需要准备和评审文档；档；缺乏正式评审中来自编程者以外的其他人的缺乏正式评审中来自编程者以外的其他人的想法，更像是一种开发方法。
想法，更像是一种开发方法2.4.6 2.4.6 其它评审方法其它评审方法80工程硕士804 4、同级、同级桌查桌查 桌查：仔细地检查源代码，以保证程序正确执行，桌查：仔细地检查源代码，以保证程序正确执行，是一种自评审是一种自评审桌查特点：桌查特点：除作者外只有一个人对工作产品进行检查；除作者外只有一个人对工作产品进行检查；依靠评审者自身的知识、技能和自律等因素，不依靠评审者自身的知识、技能和自律等因素，不同的评审者得到的结果可能不同同的评审者得到的结果可能不同桌查可以采用缺陷检查表、相应的分析方法和度桌查可以采用缺陷检查表、相应的分析方法和度量表格，也可以不采用量表格，也可以不采用2.4.6 2.4.6 其它评审方法其它评审方法81工程硕士814 4、轮、轮查查 轮查：又称轮查：又称“分配审查分配审查”，是一种由多人，是一种由多人组成的并行同级桌查，轮查时作者将产品副组成的并行同级桌查，轮查时作者将产品副本发给几位评审员并收集整理意见本发给几位评审员并收集整理意见请他人帮忙，在短时间内解决一些问题，请他人帮忙，在短时间内解决一些问题，在团队合作中非常常见的事情在团队合作中非常常见的事情。
2.4.6 2.4.6 其它评审方法其它评审方法82工程硕士821 1、代码走查及其流程、代码走查及其流程 代码走查：以组为单位阅读代码，是一系代码走查：以组为单位阅读代码，是一系列规程和错误检查技术的集合，但规程与检列规程和错误检查技术的集合，但规程与检查不同人工测试的方法，属于静态白盒测试，人工测试的方法，属于静态白盒测试，通过阅读程序源代码查找程序的错误通过阅读程序源代码查找程序的错误2.4.7 2.4.7 代码走查代码走查83工程硕士83 1 1、代码走查及其流程、代码走查及其流程2.4.7 2.4.7 代码走查代码走查作者作者组员、技术专家组员、技术专家初始初始评审对象评审对象问题清单问题清单缺陷检查表缺陷检查表可交付可交付评审对象评审对象Project Manager84工程硕士842 2、代码走查规程、代码走查规程小组组成：协调人、秘书、测试人员、富有经验的程序员、程序设计语言专家、程序员新手、维护人员、其他项目组的成员走查活动：使用书面的测试用例，采用人脑模拟计算机执行测试用例，即把测试数据跟程序的逻辑结构走一遍，以发现错误2.4.7 2.4.7 代码走查代码走查85工程硕士853 3、代码错误检查技术、代码错误检查技术代码错误检查技术错误列表数据引用错误；数据声明错误；运算错误；比较错误；控制流程错误；接口错误；输入/输出错误；其它检查；数据引用错误1、是否有引用的变量未赋值或未初始化？2、下标的值是否在范围之内？3、是否存在非整数下标？4、是否存在虚调用？5、当使用别名时属性是否正确？6、记录和结构的属性是否匹配？7、是否计算位串的地址？是否传递位串参数？8、基础的存储属性是否正确？9、跨过程的结构定义是否匹配？10、索引或下标操作是否有“仅差一个”的错误？11、继承需求是否得到满足？2.4.7 2.4.7 代码走查代码走查86工程硕士86代码错误检查技术错误列表数据引用错误；数据声明错误；运算错误；比较错误；控制流程错误；接口错误；输入/输出错误；其它检查；数据声明错误1、是否所有的变量都已声明？2、默认的属性是否被正确理解？3、数组合字符串的初始化是否正确？4、变量是否赋予了正确的长度、类型和存储类？5、初始化是否与存储类一致？6、是否有相似的变量名？2.4.7 2.4.7 代码走查代码走查87工程硕士87代码错误检查技术错误列表数据引用错误；数据声明错误；运算错误；比较错误；控制流程错误；接口错误；输入/输出错误；其它检查；运算错误1、是否存在非算术变量间的计算？2、是否存在混合模式的计算？3、是否存在不同字长变量间的运算？4、目标变量的大小是否小于赋值大小？5、中间结果是否上溢或下溢？6、是否存在被0除？7、是否存在二进制的不精确度？8、变量的值是否超过了有意义的范围？9、操作符的优先顺序是否被正确理解？10、整数除法是否正确？2.4.7 2.4.7 代码走查代码走查8888代码错误检查技术错误列表数据引用错误；数据声明错误；运算错误；比较错误；控制流程错误；接口错误；输入/输出错误；其它检查；比较错误1、是否存在不同类型变量间的比较？2、是否存在混合模式的比较运算？3、比较运算符是否正确？4、布尔表达式是否正确？5、比较运算是否与布尔表达式相混合？6、是否存在二进制小数的比较？7、操作符的优先顺序是否被正确理解？8、编译器对布尔表达式的计算方式是否被正确理解？2.4.7 2.4.7 代码走查代码走查89工程硕士89代码错误检查技术错误列表数据引用错误；数据声明错误；运算错误；比较错误；控制流程错误；接口错误；输入/输出错误；其它检查；控制流程错误1、是否超出了多条分支路径？2、是否每个循环都终止了？3、是否每个程序都终止了？4、是否存在由于入口条件不满足而跳过循环体？5、可能的循环越界是否正确？6、是否存在“仅差一个”的迭代错误？7、DO/END语句是否匹配？8、是否存在不能穷尽的判断？9、输出信息中是否有文字或语法错误？2.4.7 2.4.7 代码走查代码走查90工程硕士90代码错误检查技术错误列表数据引用错误；数据声明错误；运算错误；比较错误；控制流程错误；接口错误；输入/输出错误；其它检查；接口错误1、形式参数的数量是否等于实际参数的数量？2、形参的属性是否与实参的属性相匹配？3、传递给被调用模块的实参个数是否等于其形参的个数？4、传递给被调用模块的实参属性是否与其形参的属性匹配？5、调用内部函数的实参的数量、属性、顺序是否正确？6、是否引入了与当前入口点无关的形参？7、是否改变了某个原本仅为输入值得形参？8、全局变量的定义在模块间是否一致？9、常数是否以实参形式传递过？2.4.7 2.4.7 代码走查代码走查9191代码错误检查技术错误列表数据引用错误；数据声明错误；运算错误；比较错误；控制流程错误；接口错误；输入/输出错误；其它检查；输入/输出错误1、文件属性是否正确？2、OPEN语句是否正确？3、I/O语句是否符合格式规范？4、缓冲大小与记录大小是否匹配？5、文件在使用前是否打开？6、文件在使用后是否关闭？7、文件结束条件是否被正确处理？8、是否处理了I/O错误？2.4.7 2.4.7 代码走查代码走查92工程硕士92代码错误检查技术错误列表数据引用错误；数据声明错误；运算错误；比较错误；控制流程错误；接口错误；输入/输出错误；其它检查；其它检查1、在交叉引用列表中是否存在未引用过的变量？2、属性列表是否与预期的一致？3、是否存在“警告”或“提示”信息？4、是否对输入的合法性进行了检查？5、是否遗漏了某个功能？2.4.7 2.4.7 代码走查代码走查。