软件测试PPT 第二章 软件测试技术.ppt

1、软件测试,2.1 软件测试技术概述 2.2 软件测试的分类与流程策略 2.3 静态测试与动态测试概述 2.4 软件测试的评审技术,第二章 测试方法概述与静态分析,2.1.1 软件测试技术的分类 2.1.2 软件测试技术间的关系 2.1.3 软件测试技术的选择,2.1 软件测试技术概述,从不同的角度，可以对软件测试方法进行分成不同种类。 执行代码 程序结构 开发过程 功能性能,2.1.1 软件测试技术分类,1、从是否执行代码来分 静态测试：不实际运行被测试软件，只静态地检查程序代码、界面或文档中可能存在的错误的过程。 动态测试：实际运行被测试程序，输入相应的测试数据，检查实际输出结果和预期结果是

2、否相符的过程。,2.1.1 软件测试技术分类,2、从是否需了解程序结构来分。 黑盒测试（Black-Box Testing）、 白盒测试（White-Box Testing）、灰盒测试。 黑盒测试：黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。是一种从用户观点出发的测试，主要以软件规格说明书为依据，对程序功能和程序接口进行的测试。 白盒测试：白盒测试（White-box Testing）也称为结构测试或逻辑驱动测试，是在知道产品的内部工作过程，通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。,2.1.1 软件测试方法分类,工程硕士,7,黑盒测试和白盒测试,2.1.1 软

3、件测试技术分类,灰盒测试：灰盒测试介于白盒测试和黑盒测试之间，是现代测试的一种理念。就是指在白盒测试中交叉使用黑盒测试的方法；在黑盒测试中交叉使用白盒测试的方法。,2.1.1 软件测试技术分类,3、从软件测试策略或过程来分 单元测试(Unit Testing) 集成测试(Integration Testing) 确认测试(Validation Testing) 系统测试(System Testing) 验收测试(Verification Testing)。,2.1.1 软件测试技术分类,单元测试 对程序中最小可测试单元进行检查和验证。 集成测试 将通过测试的单元模块组装成系统或子系统，再进行测

4、试，重点测试不同模块的接口部分。 确认测试： 检验所开发的软件能否满足所有功能和性能需求的最后 手段。 系统测试 集成测试完成之后，将整个系统看成整体进行测试，包括功能、性能以及运行的软硬件环境。 用户验收测试 系统测试的后期，以用户测试为主，按照功能需求说明书以及用户手册为标准测试整个系统，保证软件达到可以交付使用的状态。,2.1.1 软件测试技术分类,4、从软件测试的作用来分 功能测试：检查软件的功能是否符合用户的需求，包括： 逻辑功能测试 界面测试 易用性测试 安装测试 兼容性测试 非功能测试：对系统功能之外的特性进行测试，包括： 性能测试 安全测试 强度测试 容量测试 。,2.1.1

5、软件测试技术分类,2.1.2 软件测试技术间的关系,工程硕士,13,不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。也称为静态分析技术。,实际运行程序，并通过观察程序运行的实际结果来发现错误的软件测试技术。,在不知道程序内部结构，只知道程序规格的情况下采用的测试技术或策略。,在知道程序内部结构的情况下采用的测试技术或策略。,开发组内部进行的，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。,开发组内部进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。,开发组、测试组和相关人员(QA、产品经理等)联合进行

6、的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。,2.1.2 软件测试技术间的关系,工程硕士,14,针对要求的程序功能，按照规范的流程进行的测试。,针对要求的程序功能以外的其他要求，包括性能、安全、配置、负载等指标，按照规范的流程进行的测试。,针对要求的程序功能、性能、安全、配置、负载等指标，基于破坏目的、按照经验进行的随机测试。,程序修改或者版本更新以后，为了确保以前正确的功能和其他指标仍旧正确，而重新进行的测试。,在测试过程中，选择足够的测试用例，使得每一个可执行语句至少被执行一次。,在测试过程中，选择足够的测试用例，使得程序中的每一个

7、分支判断的每一种可能结果都至少被执行一次。,在测试过程中，选择足够的测试用例，使得程序中的每一条可能执行的路径都至少执行一次。,单元测试 测试方法：白盒测试 参考规范：详细设计说明和代码结构 集成测试 测试方法：黑盒测试和白盒测试 参考规范：详细设计说明和概要设计说明 系统测试 测试方法：黑盒测试 参考规范：概要设计和需求规格说明 可接受性测试 测试方法：黑盒测试 参考规范：需求规格说明 回归测试 测试方法：黑盒测试和白盒测试 参考规范：需求变更文档和概要设计说明,2.1.3 软件测试技术的选择,2.2.1 软件测试的分类 2.2.2 软件测试的流程 2.2.3 软件测试的策略,2.2 软件测

8、试的分类与流程策略,2.2.1 软件测试的分类,从不同的角度，软件测试有多种不同的分类。 测试范围 测试目的 测试对象 测试过程 其它,1、按测试范围来分 单元测试 组件测试 集成测试 系统测试 验收测试 安装测试,2.2.1 软件测试的分类,2、按测试目的来分 正确性测试 白盒测试 黑盒测试 性能测试 可靠性测试 强壮性测试 异常处理测试 负载测试 安全性测试,2.2.1 软件测试的分类,3、按测试对象来分 单元测试 组件测试 模块测试 程序测试 系统测试 文档测试,2.2.1 软件测试的分类,4、按测试过程来分 需求阶段测试 设计阶段测试 程序阶段测试 测试结果评估 安装测试 测试变化：维

9、护,2.2.1 软件测试的分类,5、其它测试（P38） 回归测试 压力测试 恢复测试 兼容性测试,2.2.1 软件测试的分类,1、软件测试的阶段划分 软件测试是由一系列不同测试阶段组成的，这些阶段分为：规格说明书审查、系统和程序设计审查、单元测试、集成测试、功能测试、确认测试、系统测试、验收测试和安装测试。 （P39） 规格说明书审查： 系统和程序设计审查： 单元测试： 集成测试： 功能测试： 确认测试 系统测试： 验收测试 安装测试,2.2.2 软件测试的流程,2、从软件测试流程,2.2.2 软件测试的流程,从软件开发来看,2.2.2 软件测试的流程,从软件测试来看,1、软件测试策略的概念

10、测试策略通常是描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（如单元测试、集成测试、系统测试）以及每个阶段内进行的测试种类（如功能测试、性能测试、压力测试等），以确定合理的测试方案使得测试更有效。,2.2.3 软件测试的策略,2、软件测试策略的原则 全面细致地了解产品的项目信息:应用领域,测试范围,市场需求,产品的特点和主要功能,技术架构。 全面细致地分析影响产品的因素：基于模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素。 客观严格地执行测试计划： 制定出度量测试等级和测试重点的标准：一般是根据程序的重要性和一旦发生故障将造成的损失来确定。 使用尽可能少的有效测试用

11、例,发现尽可能多的程序错误是策略制订的目标：一次完整的软件测试后,如果程序中遗漏的错误过多且很严重,则表明本次测试是失败的或不足的;而测试不足意味着让用户承担隐藏错误带来的危险。反过来,如果过度测试,又会浪费许多宝贵的资源。找到一个最佳平衡点。,2.2.3 软件测试的策略,3、软件测试策略制订的输入输出（P55） 输入 输出,2.2.3 软件测试的策略,2.3.1 静态测试 2.3.2 动态测试 2.3.3 黑盒测试 2.3.4 白盒测试 2.3.5 黑盒与白盒测试的比较,2.3 静态测试与动态测试概述,静态测试与动态测试的比喻,1、静态测试及其特征 静态测试是对被测程序进行特性分析的方法总称

12、，由于并不真正运行被测试的程序，只对被测程序进行特性分析，因此常称为“静态分析”。所谓静态分析是指不需要执行测试程序，只是通过扫描程序正文，对程序的数据流和控制流等信息进行分析，找出系统的缺陷，得出测试报告。 静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，以发挥人的逻辑思维优势，也可以借助软件工具自动进行。,2.3.1 静态测试,特别地，静态分析的差错分析功能是编译程序所不能替代的。编译系统虽然能发现某些程序错误，但这些错误远非软件中存在的大部分错误。目前，已经开发了一些静态分析系统作为软件静态测试的工具，静态分析已被当作一种自动化的代码校验方法。,2.3.1 静态测试

13、,2、静态测试的活动 检查算法的逻辑正确性，确定算法是否实现了所要求的功能； 检查模块接口的正确性，确定形参的个数、数据类型、顺序是否正确，确定返回值类型及返回值的正确性； 检查输入参数是否有合法性检查。如果没有合法性检查，则应确定该参数是否不需要合法性检查，否则应加上参数的合法性检查；,2.3.1 静态测试,检查调用其他模块的接口是否正确，检查实参类型、实参个数是否正确，返回值是否正确，若被调用模块出现异常或错误，程序是否有适当的出错处理代码； 检查是否设置了适当的出错处理，以便在程序出错时，能对出错部分进行重做安排，保证其逻辑的正确性； 检查表达式、语句是否正确，是否含存在二义性。如表达式

14、或运算符的优先级：=、&、|、+、-等； 检查常量或全局变量使用是否正确； 检查标识符的使用是否规范、一致，变量命名是否能够望名知义、简洁、规范和易记；,2.3.1 静态测试,检查程序风格的一致性、规范性，代码是否符合行业规范，是否所有模块的代码风格一致、规范； 检查代码是否可以优化，算法效率是否最高； 检查代码注释是否完整，是否正确反映了代码的功能，并查找错误的注释。,2.3.1 静态测试,不同的测试方法各自的目标和侧重点不一样，在实际工作中要将静态测试和动态测试结合起来，以达到更加完美的效果。 1、动态测试及其特征 动态方法是通过源程序运行时所体现出来的特征，来进行执行跟踪、时间分析以及测

15、试覆盖等方面的测试。动态测试是真正运行被测程序，在执行过程中，通过输入有效的测试用例，对其输入与输出的对应关系进行分析，以达到检测的目的。,2.3.2 动态测试,2、动态测试的基本步骤 选取定义域的有效值，或选取定义域外的无效值； 对已选取值决定预期的结果； 用选取值执行程序； 执行结果与预期的结果相比，不吻合则说明程序有错。 3、动态测试方法的类型 在动态测试中，又可有基于程序结构的白盒测试（或称为覆盖测试）和基于功能的黑盒测试。,2.3.2 动态测试,1、黑盒测试的定义 黑盒测试也称作功能测试和行为测试，是指根据功能需求来测试程序是否按照预期工作。黑盒测试是一种从用户观点出发的测试，主要以

16、软件规格说明书为依据，对程序功能和程序接口进行的测试。 黑盒测试把系统被看成一个不透明的黑匣，在完全不考虑软件内部结构和处理过程的情况下验证系统是否达到用户需求。黑盒测试的示意图如图所示，从图可以看出黑盒测试只考虑程序的输入和输出，无须考虑程序的内部代码。,2.3.3 黑盒测试,2.3.3 黑盒测试,黑盒测试过程示意图,黑盒测试有两种基本思想，即通过测试和失败测试。 在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何，软件测试人员只是运用最简单、最直观的测试用例。在设计和执行测试用例时，总是先要进行通过测试，验证软件的基本功能是否都已实现。 在确信了软件正确运行之后，就可以采取

17、各种手段通过搞垮软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试用例，被称为失败测试或迫使出错测试。,2.3.3 黑盒测试,2、黑盒测试的基础 黑盒测试的基本观点是：任何程序都可以看作是从输入定义域映射到输出值域的函数过程，被测程序被认为是一个打不开的黑盒子，黑盒中的内容（实现过程）完全不知道，只明确要做到什么。黑盒测试作为软件功能的测试手段，是重要的测试方法。它主要根据规格说明设计测试用例，并不涉及程序内部结构和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。,2.3.3 黑盒测试,3、黑盒测试的目的 如果外部特性本身有问题或规格说明书的规定有误，黑盒测试方法显然是发

18、现不了的。黑盒测试方法着重测试软件的功能需求，是在程序接口上进行测试，其目的主要是为了发现以下错误： 是否有不正确的功能，是否有遗漏的功能； 在接口上，是否能够正确地接收输入数据并产生正确的输出结果； 是否有数据结构错误或外部信息访问错误； 性能上是否能够满足要求； 是否有程序初始化和终止方面的错误。,2.3.3 黑盒测试,4. 黑盒测试的特点 黑盒测试有两个显著的特点： 黑盒测试不考虑软件的具体实现过程，当在软件实现的过程发生变化时，测试用例仍然可以使用；黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。 黑盒测试不仅能够找到大多数其他测试方法无法发现的错误，而且一些外购软

19、件、参数化软件包以及某些自动生成的软件，由于无法得到源程序，只能选择黑盒测试。,2.3.3 黑盒测试,1、白盒测试的定义 白盒测试也称作结构测试或逻辑驱动测试，是一种基于程序内部实现结构和逻辑寻找缺陷的测试技术，它根据程序的控制结构设计测试用例。 白盒测试（White-box Testing）是在知道产品内部工作过程的情况下，通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。按照程序内部的结构检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。 白盒测试是一种可视的测试方法，即把测试对象看作一个透明的盒子，测试人员要了解程序结构和处理过程。白盒测试的过程如图所示。,2.3

20、.4 白盒测试,白盒测试过程示意图,2.3.4 白盒测试,2、白盒测试的必要性 逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。 程序的逻辑流往往和直觉不一样。 笔误是随机。 功能测试本身有局限。,2.3.4 白盒测试,3、白盒测试的目的 在对被测软件进行白盒测试时，主要对程序进行以下几个方面的检查。 保证一个模块中的所有独立执行路径至少测试一次； 对所有逻辑判定取值“true”和“false”的两种情况都至少测试一次； 在循环边界和运行界限内执行循环体； 测试内部数据结构的有效性。,2.3.4 白盒测试,4、白盒测试的应用 在软件测试领域，有六种基本的测试类型：单元测试，集成测试，功

21、能测试/系统测试，可接受性测试，回归测试和Beta测试。白盒测试可以用在其中的三种测试类型中： 单元测试 集成测试 回归测试,2.3.4 白盒测试,5、白盒测试与调试的不同点 从承担的任务来看，白盒测试同其他类型测试一样，它的任务是发现所开发的项目中的缺陷；但调试不属于测试，其任务是纠正软件中的缺陷。 从最终的结果来看，白盒测试有预知结果，不可预知的只是程序是否通过测试，且成功测试的结果是发现错误的症状，从而引起调试的进行；而调试的结果是消除项目中的错误。 从执行的过程来看，测试是一个发现错误、改正错误、重新测试的过程；而调试是一个推理过程。,2.3.4 白盒测试,从准备工作来看，测试从已知的

22、条件开始，使用预先定义的程序；调试一般是以不可知的内部条件开始，做统一性调试 。 从执行的计划性来看，测试是有计划的并要进行测试设计；而调试则不受时间约束。 从执行的人员来看，测试经常是由独立的测试组在不了解软件设计的条件下完成的，而调试必须由程序员来完成。 从所使用的工具来看，大多数白盒测试的执行和设计可有工具支持，而调试程序员能利用的工具主要是调试器。,2.3.4 白盒测试,1、白盒测试的优缺点 优点 可构成测试数据对特定程序部分测试，可以检测代码中的每条分支和路径； 揭示隐藏在代码中的错误； 对代码的测试比较彻底； 有较多工具支持； 有一定的充分性度量手段。,2.3.5 黑盒与白盒测试的

23、比较,缺点 工作量大, 成本高。通常只用于单元测试，有应用局限； 无法检测代码中遗漏的路径和数据敏感性错误； 不能验证规格说明的正确性； 无法对规格说明中未实现的部分进行测试； 不易生成测试数据(通常)。,2.3.5 黑盒与白盒测试的比较,2、黑盒测试的优缺点 优点 对于较大的代码单元来说，效率高； 测试人员不需要了解实现的细节，包括具体的编程语言； 测试员和程序员可以由不同的人员来担任； 从用户的角度进行测试，容易被理解和接受； 有助于暴露任何规格不一致或有歧义的问题； 测试用例的设计可以在规格说明完成之后马上进行； 容易入手生成测试数据； 适用于各阶段测试。,2.3.5 黑盒与白盒测试的比

24、较,缺点 实际上，只有一小部分可能的输入被测试到，某些代码得不到测试； 如果没有清晰、简洁的规格说明，难以设计测试用例； 如果测试人员不知道开发人员已经执行过该测试用例，会存在不必要的重复测试； 会有很多程序路径没有被测试到； 不能直接针对可能隐蔽了许多问题的特定程序段进行测试； 如果规格说明有误，则无法发现； 不易进行充分性测试。,2.3.5 黑盒与白盒测试的比较,3、白盒测试和黑盒测试的比较 白盒测试只关注软件产品的测试，不能够确保产品已经实现了规格说明中的所有功能。黑盒测试则只关注规格说明中的测试，不能够保证已经实现的各个部分都被测试到。 与黑盒测试相比，白盒测试的成本要高一些。 黑盒测

25、试是一种确认技术，回答“我们在构造一个正确的系统吗？白盒测试是一种验证技术，回答“我们在正确地构造一个系统吗？” 总之，建议测试人员在进行测试的过程中，可以考虑先使用黑盒测试，然后统计相应的覆盖率，再设计适当的白盒测试用例作为补充以保证测试的完整性。,2.3.5 黑盒与白盒测试的比较,2.4.1 软件评审及其评审点 2.4.2 软件评审的组织与流程 2.4.3 测试和评审的比较 2.4.4 软件评审方法 2.4.5 软件评审 2.4.6 其它软件评审 2.4.7 代码走读,2.4 软件测试的评审技术,工程硕士,56,2.4.1 软件评审及其评审点,1、什么是软件评审 软件评审是指在软件开发过程

26、中，由参与评审的人员对软件开发文档或代码进行审定或检查，帮助查找缺陷和改进。其工作内容有： 检验产品是否满足规范，如需求或设计文档； 识别产品相对于标准的偏差； 向作者提出改进建议； 促进技术交流和学习。,工程硕士,57,2.4.1 软件评审及其评审点,2. 软件评审原则 对事不对人，评审不是对责任人绩效的评价 责任人保持开发思想，接受别人意见，避免争论 评审组规模保持3-7人 评审期间要努力发现问题，但不要试图去解决问题 会议限制在两个小时之内 正式评审需要事先准备,工程硕士,58,评审,评审,评审,评审,评审,评审,评审,3、软件项目中的评审点,2.4.1 软件评审及其评审点,59,1.

27、软件评审的角色（实例） 责任人：是准备要评审的信息或工作产品的人。 主审人：是评审组长，评审会议主持人，带领评审团队工作保证评审达到预期的目的。 讲解员：负责在评审会议期间对被审的工作产品部分进行释义，使评审组可侧重于重要信息，将注意力由责任人转向产品。 记录员：记录下评审会议过程中的相关信息，如对预审问题的确认，新出现的问题等。 评审专家：了解评审对象，是寻找评审对象与所依照的文档、标准之间存在的差异。,2.4.2 软件评审的组织与流程,工程硕士,60,2. 软件评审的流程,2.4.2 软件评审的组织与流程,工程硕士,61,2.4.3 测试和评审的比较,表现形式 测试：单元测试、集成测试、确

28、认测试、系统测试、验收测试 评审：审查、小组评审、走查、结对编程、同级桌查、轮查、临时评审,工程硕士,62,2.4.3 测试和评审的比较,工作对象 测试：编译后可运行的程序 评审：需求规格说明书、架构（概要）设计文档、详细设计文档、项目计划、项目过程文档、源代码、系统界面、测试计划、测试用例和数据、用户手册,工程硕士,63,2.4.3 测试和评审的比较,识别缺陷的阶段 测试：编码完成后 评审：需求阶段、设计阶段、编码阶段、测试阶段,工程硕士,64,识别缺陷的成效 测试：最多识别软件所有缺陷中的30-35% 评审：最多识别软件所有缺陷中的70-75%,2.4.3 测试和评审的比较,工程硕士,65

29、,识别缺陷的成本 测试：识别一个重要缺陷平均花费15-25小时 评审：识别一个重要缺陷平均花费 需求阶段2-3小时； 设计阶段3-4小时； 代码阶段3-5小时； 测试计划3-5小时。,2.4.3 测试和评审的比较,工程硕士,66,解决缺陷的成本 测试：消除一个重要缺陷平均花费30-80小 时（含识别缺陷时间）。开发后期识别缺陷，成本较高 评审：需求及设计阶段消除一个重要缺陷花费5-10小时；代码评审阶段消除一个重要缺陷花费5-15小时。倾向于在开发前期识别缺陷，成本较低,2.4.3 测试和评审的比较,工程硕士,67,2.4.4 软件评审方法,1、软件评审方法的类型 审查（Inspection）

30、 团队/技术评审（Team Review/Technical Review） 走查（WalkThrough） 结对编程（Pair Programming） 同级桌查（Peer DeskCheck） 临时轮查（Ad hoc Review,工程硕士,68,2.4.4 软件评审方法,1、软件评审方法的类型,工程硕士,69,2、软件评审的活动,2.4.4 软件评审方法,工程硕士,70,3、软件评审方法的选择 选择的原则是工作成果产生风险的可能性越大，采用的评审方法越正式。 对于需求规格说明书，因为它的不准确和不完善会给软件的后期开发带来极大的风险，所以必须要采用最正式的评审方法，比如审查或者技术评审；

31、 核心代码的失效也会带来很严重的后果，所以也应该采用审查或者技术评审的方法进行评审； 一般的代码，采用同行桌查或者临时评审就可以满足要求了。,2.4.4 软件评审方法,工程硕士,71,4、各评审方法的评审目标,2.4.4 软件评审方法,工程硕士,72,1、什么是审查 Michael Fagan 20世纪70年代在IBM提出， 也被称为“正式审查”，包含制定计划、总体会议、准备、会议、返工、跟踪和因果分析等阶段，每个阶段都有不同的角色参与，是有计划有结构的评审方法 Fagan审查方法有多种变体 Gilb/Graham方法 High-Impact审查 分阶段审查,2.4.5 软件审查,工程硕士,7

32、3,2、审查角色 作者：准备要评审的信息或工作产品的人。 评审组长：审查会议主持人，带领审查团队工作，保证评审达到预期目的。 讲解员：负责在审查会议期间对被审的工作产品进行解释，使审查组侧重于重要信息，将注意力由责任人转向产品。 记录者：记录审查会议过程中的相关信息，如对预审问题的确认、新出现的问题等。 审查专家：寻找审查对象与所依照的规范、标准之间存在的差异。,2.4.5 软件审查,工程硕士,74,3、审查专家的选取,2.4.5 软件审查,工程硕士,75,4、审查的流程,2.4.5 软件审查,工程硕士,76,审查流程（续）,2.4.5 软件审查,工程硕士,77,1、技术评审 有时简称为“评审

33、”或“轻型审查”，是有计划有结构的评审，但没有审查正式也没有审查严格，讲解角色可以由评审组长代替。 审查的组织与流程，适用于技术评审。 技术评审方法发现问题的数量是审查的2/3。,2.4.6 其它软件评审,工程硕士,78,2、走查 由产品作者将产品向一组同事介绍，希望他们给出意见。是为了满足作者的需要而不是达到预期的质量目标。 一种非正式的评审 通常不按照事先预定的过程进行 不制定详细的准出条件 不需要管理报告 不测量 走查可以采用正式或不正式的的流程进行 走查发现问题的数量是审查的1/2,2.4.6 其它评审方法,工程硕士,79,3、结对编程 两个开发者在一个电脑上同时操作一个程序，每一行代码都由两个人共同编写。 一种非正式的评审 没有结构和制定流程，不需要准备和评审文档； 缺乏正式评审中来自编程者以外的其他人的想法，更像是一种开发方法。,2.4.6 其它评审方法,工程硕士,80,4、同级桌查 桌查：仔细地检查源代码，以保证程序正确执行，是一种自评审。 桌查特点： 除作者外只有一个人对工作产品进行检查； 依靠评审者自身的知识、技能和自律等因素，不同的评审者得到的结果可能不同。 桌查可以采用缺陷检查表、相应的分析方法和度量表格