1、第5讲：第5章 白盒测试的实用技术,白盒测试（White Box Testing），按照程序内部的结构、逻辑驱动测试程序，通过测试来检测产品内部动作是否按照设计说明书的规定正常进行，检验程序中的每条路径是否都能按预定要求正确工作。 此方法是把白盒测试的对象看成内部逻辑结构是完全可见的盒子，测试人员依据程序内部逻辑结构的相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点、不同分支检查程序的状态，确定实际的状态是否与预期的状态一致。 白盒测试技术是软件测试的主要方法之一，白盒测试的基本概念、检查方法、测试方法、测试工具等内容是必须掌握的，本章重点讨论以下内容： 白盒测试的基本概
2、念； 白盒测试方法； 白盒测试的常用技术； 白盒测试的要求； 人工静态测试方法； 动态测试； 结构测试。,5.1 白盒测试的基本概念,白盒测试（白箱测试 (White-box testing)是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件，使用程序设计的控制结构导出测试用例，是软件测试的主要方法之一。这种测试要求对程序的要求很高，需要了解程序的构架，具体需求，以及一些编写程序的技巧，能够检查一些程序规范，指针，变量，数组越界等问题，使得问题在前期就暴露出来。白盒测试又叫结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规
3、定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。一般程序所容易犯的错误,没有定义变量,无效引用,野指针,超过数组下标,内存分配后没有删除等,无法调入循环体,函数本身没有析构,导致循环实效或者死循环.参数类型不匹配,调用系统的函数没有考虑到系统的兼容性等。,白盒测试一般是以单元或者模块为基础的。目前的做法是把他归结为开发的范畴，用专人或者兼职的人去看代码或者利用部分工具，例如Rational 系列，Boundchecker 等工具，他们可以帮助人为的发现变量没有初始化，指针错误等
4、。大大的减少了人力。 白盒测试的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。白盒测试主要是检查程序的内部结构、逻辑、循环和路径。常用测试用例设计方法有：代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异等，运用最为广泛的是基本路径测试法。,5.1.1 白盒测试,白盒测试可分为静态测试和动态测试。 （1）静态测试 静态测试是测试中很重要的方法之一。它不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试。静态测试大约可以找出25%60%的逻辑错误。 （2）动态测试 输入一组预先按
5、照一定的测试准则设计的实例数据驱动运行程序，检查程序功能是否符合设计要求，发现程序中错误的过程。,5.1.2白盒测试的原则 白盒测试必须遵循以下4条原则，才能达到测试的目的： 1. 保证一个模块中的所有独立路径至少被测试一次； 2. 所有逻辑值均需测试真 (true) 和假 (false) 两种情况； 3. 检查程序的内部数据结构，保证其结构的有效性； 4. 在上下边界及可操作范围内运行所有循环。,5.1.3 白盒测试的策略和侧重点 白盒测试中测试的策略是采用先静态后动态的组合方式，然后现进行覆盖测试。 利用静态结构分析的结果，通过代码检查和动态测试的方法对结果进一步确认，使测试工作更为有效。
6、 白盒测试在不同测试阶段的侧重点是： 单元测试 以代码检查、逻辑覆盖； 集成测试 静构结构分析、静态质量度量； 系统测试 根据黑盒测试结果，采用白盒测试。,5.1.4 白盒测试的类别、依据和流程 1. 白盒测试的类别 白盒测试可分为代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试、符号测试、Z路径覆盖、程序变异。其中运用最为广泛的是基本路径测试法。白盒测试的类别具体分为8大类。 （1） 软件公用问题的测试； （2） 语言测试； （3） SQL语句测试； （4） 数据类型测试； （5） 界面测试； （6） 数值对象测试； （7） 业务对象测试； （8） 数据管理对象
7、测试。,2. 白盒测试的依据 软件需求报告； 软件需求规格说明； 程序设计文档； 软件界面设计； 编码规范； 开发命名标准。,白盒测试的流程 白盒测试的流程分为界面对象和业务对象两种方式。 界面对象测试 界面对象测试的流程如图5-1所示。,业务对象流程测试 业务对象测试的流程如图5-2所示。,5.2 白盒测试方法,在白盒测试中，可以使用各种测试方法进行测试。但是，测试要考虑五点问题。 （1）测试中，尽量先用自动化工具来进行静态结构分析； （2）测试中建议先从静态测试开始，如：静态结构分析、代码走查和静态质量度量，然后进行动态测试，如：覆盖率测试； （3）利用静态分析的结果作为依据，再使用代码检
8、查和动态测试的方式对静态分析结果进行进一步确认，提高测试效率及准确性； （4）覆盖率测试是白盒测试中的重要手段，在测试报告中可以作为量化指标的依据，对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率； （5）在不同的测试阶段，测试的侧重点是不同的。 在单元测试阶段，以程序语法检查、程序逻辑检查、代码检查、逻辑覆盖为主； 在集成测试阶段：需要增加静态结构分析、静态质量度量、以接口测试为主； 在系统测试阶段：在真实系统工作环境下通过与系统的需求定义作比较，检验完整的软件配置项能否和系统正确连接，发现软件与系统/子系统设计文档和软件开发合同规定不符合或与之矛盾的地方；验证系统是否满足了需求规格
9、的定义，找出与需求规格不相符合或与之矛盾的地方，从而提出更加完善的方案。确保最终软件系统满足产品需求并且遵循系统设计的标准和规定； 验收测试阶段：按照需求开发的，体验该产品是否能够满足使用要求；有没有达到原设计水平？完成的功能怎样？是否符合用户的需求，达到预期目的为主。,5.2.1代码检查 代码检查是静态测试的主要方法，代码检查包括代码走查、桌面检查、流程图审查等。对于代码检查从如下几点进行叙述。 1. 概述 代码检查主要检查代码和流图设计的一致性、代码结构的合理性、代码编写的标准性、可读性、代码的逻辑表达的正确性等方面。包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等
10、内容。 最常见的静态测试是找出源代码的语法错误，这类测试可由编译器来完成，因为编译器可以逐行分析检验程序的语法，找出错误并报告。除此之外，测试人员须采用人工的方法来检验程序，有些地方存在非语法方面的错误，只能通过人工检测的方法来判断。,2. 代码走查目的 代码走查是为达到以下目的： 通过检查代码程序是不是按照某种标准或规范编写的代码； 通过检查代码来发现代码是不是流程图要求的； 通过检查代码来发现有没有遗漏的项目； 代码要易于移植，代码经常需要在不同的硬件中运行，或者使用不同的编译器编译； 代码要易于阅读、理解和维护。 检查代码和设计是否一致； 代码是否对遵循标准、是否可读； 代码逻辑表达是否
11、正确； 代码结构是否合理； 程序编写与编写标准是否符合； 程序中是否有不安全、不明确和模糊的部分； 编程风格是否符合要求； 检查变量的交叉引用表：是否有未说明的变量和违反了类型规定的变量； 检查标号的交叉引用表：验证所有标号是否有正确； 检查子程序、宏、函数：验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致； 检查全部等价变量的类型的一致性； 确认常量的取值和数据类型； 选择、激活路径：在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活，则程序可能有错。 对照程序的规格说明，详细阅读源代码，比较实际的代码，从差异中发现程序的问题和错误。,3.
12、代码检查需要的文档 在代码检查检查前应准备好需求文档、程序设计文档、程序的源代码清单代码编码标准、代码缺陷检查表和流程图等。,5.2.2 代码检查方式 代码走查的方式有： 1 桌面检查 2 走查 3 代码审查 桌面检查 桌面检查是程序员对源程序代码进行分析、检验，并补充相关的文档，发现程序中错误的过程。由于程序员熟悉自己的程序，可以有程序员自己检查，这样可以节省很多时间，但要注意避免自己的主观判断。,走查 走查(走读)是程序员和测试员组成的审查小组通过逻辑运行程序，发现问题。小组成员要提前阅读设计规格书、程序文本等相关文档，利用测试用例，使程序逻辑运行。 走查可分为以下两步： 第一步：小组负责
13、人把材料发给每个组员，然后由小组成员提出发现的问题。 第二步：通过记录，小组成员对程序逻辑及功能提出自己的疑问，开会探讨发现的问题和解决方法。,代码审查 代码审查是程序员和测试员组成的审查小组通过阅读、讨论、分析技术对程序进行静态分析的过程 。 代码审查可分为以下两步： 第一步：小组负责人把程序文本、规范、相关要求、流程图及设计说明书发给每个成员。 第二步：每个成员依据所发材料作为审查依据，但是由程序员讲解程序的结构每、逻辑和源程序。在此过程中，小组成员可以提出自己的疑问；程序员在讲解自己的程序时，也能发现自己原来没有注意到的问题。 为了提高效率，小组在审查会前，可以准备出一份常见错误清单，提
14、供给参加成员对照检查。 在实际应用中，代码检查能快速找到20%-30%以上的编码缺陷和逻辑设计缺陷，代码检查看到的是问题本身而非征兆。代码走查是要消耗时间的，而且代码检查需要知识的经验积累。,5.2.3 代码检查项目,代码检查项目主要有以下几点： 1. 要求有文档和源程序代码 一份最新的设计文档； 程序结构图； 所有的模块源程序代码； 代码体系结构描述； 目录文件； 代码组织。 2 目录文件组织 所有的文件名简单明了，见名知意。 文件和模块分组清晰。 每行代码在80字符以内。 每个文件只包含一个完整模块的代码。,3. 数据库检查 数据库命名使用小写英语字母， 数字和下划线，无其他字符 ； 数据
15、库命名采用项目名或产品名称命名 ，长度小于20位 ； 数据库中的所有表字符集统一 ； 数据库对象的命名不使用保留关键字； 数据库设计考虑到将来可能存在的异种数据库迁移 ； 字段与画面项目能够一一对应（部分标识符字段和系统设定字段除外）； 索引是多值字段 ； 索引是单一字段 ； 字段取值符合域定义 ； 字段的类型和长度能够满足字段的值的最大限量 ； 文本字段有充足的余量对应可能的长度变更 ； 数字字段考虑了充足的余量和精度对应可能的长度或精度变更 ； 针对客户的特定应用采用了视图机制 。,4 检查函数 函数头清晰地描述了函数的功能。 函数的名字清晰地定义了它所要做的事情。 参数遵循一个规律的顺序
16、。 所有的参数都是要有用的。 函数参数接口关系清晰明了。 函数所使用的算法要有说明。 代码中有相关注解 ； 函数只做一件事情； 函数出口都有返回值 ； 函数异常处理清楚 。,5. 数据类型及变量 每个数据类型都有其解释。 每个数据类型都有正确的取值。 数据结构尽量简单，降低复杂性。 每一个变量的命名，都明确的表示代表什么。 所有的变量都要被使用。 全部变量要描述清晰。 数据来源正确性； 数据处理过程正确性； 数据处理结果不正确性； 变量分配了正确的长度、类型和存储空间； 静态变量明确区分； 变量初始化； 变量的命名不与标准库中的命名相冲突； 全局变量描述； 类型转换。,6. 检查条件判断语句
17、If/else 使用正确 ； 无嵌套的if链 数字，字符，指针和0/NULL/FLSE 判断明确 ； 不要有臃肿的判断逻辑； 所有的判断条件边界是否正确； 判断体足够短。 最常见的情况优先判断。,7. 检查循环体 循环体不为空； 循环之前做好初始化代码 ； 有明确的多次循环操作，使用For循环 ； 不明确的多次循环操作，使用while循环； 循环终止的条件清晰 ； 所有的循环边界是否正确； 循环体内的循环变量起到指示作用； 循环命名要有意义； 循环终止条件清晰。,8. 检查代码注释 有一个简单的说明，用于描述代码的结构 ； 每个文件和模块均以给予解释 ； 解释说明代码功能，准确描述代码意义 ；
18、 解释不过于简单 ； 注解清楚正确,并且易懂； 所有注释要具体，清晰； 无用的代码及注释要删除； 代码的注释与代码是否一致?注释是否是多余的。,9. 桌面检查 检查代码和设计的一致性； 代码对标准的遵循、可读性； 代码逻辑表达的正确性； 代码结构的合理性； 程序编写与编写标准的符合性； 程序中不安全、不明确和模糊的部分； 编程风格问题等。,10. 检查功能 重复的功能 ； 多余的功能 ； 功能实现与设计要求不相符 ； 功能使用性、方便性、易用性。 11. 检查界面 界面美观 ； 控件排列、格式； 焦点控制合理或全面性。,12. 检查流程 流程控制不符和要求 ； 流程实现不完整。 13. 检查提
19、示信息 提示信息重复或出现时机合理性； 提示信息格式和要求的合理性 ； 提示框返回后停留位置的合理性。 14. 输入输出检查 所有文件的属性描述清楚； 输入参数的异常是否处理了； 文件结束的条件进行检查。 15. 程序（模块）检查 程序中所有的异常是否处理了?； 程序中是否存在重复的代码? 程序结构是否清晰。 16. 表达式分析 对表达式进行分析以发现和纠正在表达式中出现的错误如：在表达式中不正确的使用了括号造成错误、数组下标越界错误、除数为零、浮点数计算的误差等。,17. 接口分析 接口分析主要是对接口一致性的分析如：各模块之间接口一致性；模块与外部数据库的接口一致性；形参与实参在类型数量、
20、顺序、维数、使用上的一致性；全局变量和公共数据区在使用上的一致性。 18. 函数调用关系图 函数调用关系图：通过应用程序各函数之间的调用关系展示了系统的结构。列出所有函数，用连线表示调用关系，作用：可以检查函数的调用关系是否正确、是否存在孤立的函数而没有被调用、明确函数被调用的频繁度、对调用频繁的函数可以重点检查。 19. 模块控制流图 模块控制流图由许多结点和连接结点的边组成的图形，其中每个结点代表一条或多条语句，边表示控制流向，可以直观地反映出一个函数的内部结构。,20. 其它检查 1） 软件的扩展字符，编码，兼容性，警告/提示信息。 2） 检查变量的交叉引用表：检查未说明的变量和违反了类
21、型规定的变量，变量的引用和使用情况。 3） 检查标号的交叉引用表：验证所有标号的正确性。 4） 检查子程序、宏、函数：验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致。 5） 等价性检查：检查全部等价变量的类型的一致性。 6） 常量检查：确认常量的取值和数制、数据类型。 7） 标准检查：检查程序中是否违反标准的问题。 8） 风格检查：检查程序的设计风格。 9） 比较控制流：比较设计控制流图和实际程序生成的控制流图的差异。 10） 选择、激活路径：在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活，则程序可能有错。 11） 补充文档：根据以上检查
22、项目，可以编制代码规则，规范和检查表等作为测试用例。 12） 对照程序的规格说明，详细阅读源代码，比较实际的代码，从差异中发现程序的问题和错误。 13） 检查必须遵守规定代码的语法格式、语法规则，如排版、注释、标识符命名、可读性、变量、函数、过程、可测性、程序效率、质量保证、代码编辑、编译、审查、代码测试、维护、宏等各方面的编码要求。 我们在进行人工代码检查时，可以制作代码走查缺陷表，在缺陷检查表中，我们列出工作中遇到的典型错误。代码走查缺陷表如表5-1所示。,5.2.4 静态结构分析,静态结构分析主要是以图形的方式表现程序的内部结构，例如函数调用关系图、函数内部控制流图。 静态结构分析是测试
23、者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表，检查软件有没有存在缺陷或错误；包括控制流分析、数据流分析、接口分析、表达式分析。,通过应用程序各函数之间的调用关系展示了系统的结构。列出所有函数，用连线表示调用关系和作用。静态结构主要分析如下内容： 1.检查函数的调用关系是否正确； 2. 是否存在孤立的函数而没有被调用； 3. 明确函数被调用的频繁度，对调用频繁的函数可以重点检查。 4. 编码的规范性; 5. 资源是否释放; 6.
24、数据结构是否完整和正确; 7. 是否有死代码和死循环; 8. 代码本身是否存在明显的效率和性能问题; 9. 类和函数的划分是否清晰，易理解; 10. 代码是否有完善的异常处理和错误处理。,5.2.5 SQL语句测试,主要检查以下两点： 1. 语句检查1）每个数据库对象都有拥有者；2）Table: 是DB的基本单位，由行和列组成，用于存储数据；3）Data Type: 限制输入到表中的数据类型；4）Constraint: 有主键、外键、唯一键、缺省和检查5种；5）Default: 自动插入常量值；6）Rule: 限制表中列的取值范围；7）Trigger: 一种特出类型的储存过程，当有操作影响到他
25、保护的数据时，自动触发执行；8）Index: 提高查询速度；9）View: 查看一个或多个表的一种方式；10）Stored Procedure: 一组预编译的SQL语句，可以完成指定的操作。 2. 类型转换 检查SQL语句的类型转换时，主要避免显示或隐含的类型转换。,5.2.6 代码检查的分析与评价,代码检查的分析与评价主要注意以下两大点： 1 能力 陈述经代码检查证实了的本软件的能力。 2 缺陷和限制 陈述经代码检查测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。缺陷和限制： (1) 数据引用错误：是指未经正确声明和初始化的变量、常量
26、、数组、字符串或记录而导致的软件缺陷。注意：数据引用错误是缓冲区溢出的主要原因一个造成许多软件安全问题的缺陷。 (2) 数据声明错误：其产生的原因是不正确地声明或使用变量和常量。 (3) 计算错误 (4) 比较错误小于、大于、等于、不等于、真、假。比较和判断错误很可能是由于边界条件问题。 (5) 控制流程错误控制流程错误的原因是编程语言中循环等控制结构未按预期方式工作，它们通常由计算或者比较错误直接或间接造成。 (6) 子程序参数错误来源是软件子程序不正确的传递数据。 (7) 输入/输出错误包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。 (8) 其它错误 编码错误？
27、警告/提示信息错误？ 通过对代码检查结果的分析，需标明遗留缺陷、局限性和软件的约束限制等，说明该代码是否已达到预定的结果，判定代码能否交付使用。审查小组必须做出审查结果的书面总结报告，并使报告便于开发小组的成员使用。,5.2.7静态质量度量,静态质量度量是测试者通过软件质量、质量度量模型和度量规则分析的。 1 软件质量 软件质量包括以下6个方面： 功能性（functionality）； 可靠性（reliability）； 可用性（usability）； 有效性（efficiency）； 可维护性（maintainability）； 轻便性（portability）。 2. 质量度量质量度量包括
28、以下3点： 质量因素（Factors） 质量因素与分类标准的计算方式相似，依据各分类标准取值组合权重方法来计算，依据结果将软件质量分为四个等级，与分类标准等级内容相同。 分类标准（criteria） 对某一软件质量分为不同的分类标准，每个分类标准由一系列度量规则组成，每个规则分配一个权重，每个分类标准的取值由规则的取值与权重值计算得出，依据结果将软件质量分为四个等级： 优秀（excellent）：符合本模型框加中的所有规则（可以接受）； 良好（good）：未大量偏离模型框架中的规则（可以接受）； 一般（fair）：违背了模型框架中的大量规则（可以接受）； 较差（poor）：无法保障正常的软件可
29、维护性（不可以接受）。 3度量规则（Metrics）度量规则使用代码行数、注释频度等参数度量软件各种行为属性。,5.3 白盒测试的常用技术,白盒测试常用技术主要有7种。现分别叙述如下。 5.3.1 逻辑覆盖法逻辑覆盖法主要讨论四点： 测试覆盖率； 逻辑覆盖 ； 面向对象的覆盖 ； 测试覆盖准则。 现分别进行讨论。,1. 测试覆盖率 测试覆盖率是用于确定测试所执行到的覆盖项的百分比。其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等。 测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。但覆盖率不是目标，只是一种手段。 其中测试覆盖
30、率包括功能覆盖和结构覆盖。 （1）功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。 （2） 结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等等。,2. 逻辑覆盖 根据覆盖目标的不同和覆盖源程序语句的详尽程度，逻辑覆盖又可分为语句覆盖 、判定覆盖、条件覆盖、条件判定组合覆盖、多条件覆盖、修改条件判定覆盖、组合覆盖和路径覆盖。 （1）语句覆盖语句覆盖是选择足够多的测试数据，使得程序中的每个可执行语句至少执行一次。 语句覆盖的缺点是对程序执行逻辑的覆盖很低。 （2） 判定覆盖判定覆盖是通过设计足够多的测试用例，使得程序中的每一个判定至少获得一次真值和假值，
31、或者使得程序中的每一个取真分支或取假分支至少经历一次，也称为“分支覆盖”。 判定覆盖的缺点是主要对整个表达式最终取值进行度量，忽略了表达式内部取值。 （3）条件覆盖 条件覆盖是通过设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。条件覆盖的缺点是不能够满足判定覆盖。 （4） 条件判定组合覆盖 条件判定组合覆盖是通过设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。条件判定组合覆盖的测试用例一定同时满足判定覆盖和条件覆盖。条件判定组合覆盖缺点是没有考虑单个判定对整体结
32、果的影响，无法发现逻辑错误。 （5）多条件覆盖 多条件覆盖也称条件组合覆盖，是通过设计足够多的测试用例，使得每个判定中条件的各种可能组合都至少出现一次（以数轴形式划分区域，提取交集，建立最少的测试用例）。 多条件覆盖的缺点是判定语句较多时，条件组合值比较多。 （6）修正条件判定覆盖修正条件判定覆盖是对每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次。 （7） 组合覆盖 组合覆盖是通过执行足够的测试用例，使得程序中每个判定的所有可能的条件取值组合都至少出现一次。满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。 （8） 路径覆盖
33、路径覆盖是设计足够多的测试用例，要求覆盖程序中所有可能的路径。,3. 面向对象的覆盖面向对象的覆盖主要讨论继承上下文覆盖和基于状态的上下文覆盖。 （1）继承上下文覆盖 由于传统的程序结构没有考虑面向对象的一些特性（如多态、继承和封装等），所以在面向对象领域，传统的程序结构覆盖必须被加强，以满足面向对象特性。 继承上下文覆盖考虑在每个类的上下文内获得的覆盖率级别。 继承上下文定义将基类上下文内例行程序的执行作为独立于继承类上下文内例行程序的执行。为了获得100继承上下文覆盖，代码必须在每个适当的上下文内被完全执行。 （2）基于状态的上下文覆盖 由于类的行为状态，每个类的行为在每个可能的状态中其性
34、质是不同的。 基于状态的上下文覆盖对应于被测类对象的潜在状态。 上下文覆盖把一个状态上下文内的一个例行程序达到100的基于状态的上下文覆盖，例行程序必须在每个适当的上下文（状态）内被执行。,4. 测试覆盖准则测试覆盖准则主要讨论ESTCA（Error Sensitive Test Cases Analysis）错误敏感测试用例分析和LCSAJ(Linear Code Sequence and Jump)线性代码序列与跳转。 （1）ESTCA覆盖准则ESTCA覆盖准则在容易发生问题的地方设计测试用例，即重视程序中谓词（条件判断）的取值。这一规则虽然并不完备，但在普通程序中却是有效的。原因在于这是
35、一种经验型的覆盖准则，规则本身针对了程序编写人员容易发生的错误，或是围绕着发生错误的频繁区域，从而提高了发现错误的命中率。规则具体如下： 规则1：对于A rel B（rel可以是）型的分支谓词（条件判断）的取值，应适当地选择A与B的值，使得测试执行到该分支语句时，AB的情况分别出现一次。 规则2：对于A rel c（rel可以是，A是变量，C是常量）型的分支谓词，当rel为时，应适当地选择A，使：A=c+M。 规则3：对外部输入变量赋值，使其在每一测试用例中均有不同的值与符号，并与同一组测试用例中其它变量的值与符号不一致。 （2）现行代码序列与跳转LCSAJ 现行代码序列与条状LCSAJ是指一
36、组顺序执行的代码，以控制流跳转为结束点。可产生4层覆盖 第一层：语句覆盖 第二层：分支覆盖 第三层：LCSAJ覆盖 第四层：两层LCSAJ覆盖，直到N个LCSAJ,5.3.2 插桩技术,软件动态测试中，插桩测试是一个被广泛应用的测试方法。插桩测试就是向源程序中插入语句然后执行程序，通过打印语句，获得动态信息（我们最为关心的信息）。 在这里，我们举一个最简单的例子，以计算整数X和整数Y的最大公约数为例，试图说明插桩技术的要点。 插桩后求最大公约数程序流程图如图5-3所示。,在插桩测试时需要注意的要点是： 需要哪些信息； 在什么位置插入语句； 需要在几个点插入语句以及在特定的位置需要什么特殊的判断
37、性语句。 对于插桩测试，分析好这三要点题尤为重要。前两个要点是需要结合具体的程序来判断的，不能给出具体的答案。对于最后一个要点，就要考虑如何才能插入最少的点，来完成实际的问题。这些通过工作经验的积累会很容易的解决的。,5.3.3 基本路径测试法,基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。 基本路径测试法的重点内容如下： 程序的控制流图：描述程序控制流的一种图示方法。 程序环形复杂度：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路
38、径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。 导出测试用例：根据圈复杂度和程序结构设计用例数据输入和预期结果。 准备测试用例：确保基本路径集中的每一条路径的执行。,1 程序控制流图程序控制流图（可简称流图）是对程序流程图进行简化后得到的，它突出表示程序控制流的结构。程序控制流图是描述程序控制流的一种方式。控制流图图形符号： 图形符号：圆圈代表一个结点， 表示一个或多个无分支的语句或源程序语句； 程序控制流边和点圈定的部分叫做区域。当对区域计数时，图形外的一个部分也应记为一个区域； 判断语句中的条件为复合条件时，即条件表达式由一个或多个逻辑运算符连接的逻辑表达式（
39、a and b），则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断。节点由带标号的圆圈表示，可代表一个或多个语句、一个处理框序列和一个条件判定框（假设不包含复合条件）。 控制流线由带箭头的弧或线表示，可称为边，它代表程序中的控制流。为了满足路径覆盖，必须首先确定具体的路径以及路径的个数。我们通常采用控制流图的边（弧）序列和节点序列表示某一条具体路径。 路径测试就是从一个程序的入口开始，执行所经历的各个语句的完整过程。任何关于路径分析的都可以叫做路经测试 完成路径测试的理想情况是做到路径覆盖，但对于复杂性大的程序要做到所有路径覆盖（测试所有可执行路径）是不可能的。 在不能做到所有路径覆盖
40、的前提下，如果某一程序的每一个独立路径都被测试过，那么可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。这种测试方法就是通常所说的基本路径测试方法。,基本路径测试方法是在控制流图的基础上，通过分析控制结构的环形复杂度，导出执行路径的基本集，再从该基本集设计测试用例。基本路径测试方法包括以下4个步骤： 画出程序的控制流图。 计算程序的环形复杂度，导出程序基本路径集中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界。 导出基本路径集，确定程序的独立路径。 根据中的独立路径，设计测试用例的输入数据和预期输出。 程序控制流图如图5-4所示。,程序的环路复杂度也
41、称为圈复杂度，它是一种为程序逻辑复杂度提供定量尺度的软件度量。 将环形复杂度用于基本路径方法，它可以提供：程序基本集的独立路径数量，确保所有语句至少执行一次的测试。独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路，包括一组以前没有处理的语句或条件的一条路径。通常环路复杂度环路复杂度以图论为基础，提供软件度量。可用如下方法来计算环路复杂度： 1） 控制流图中区域的数量对应于环形复杂度。 2） 给定控制流图G的环形复杂度-V(G)，定义为：V(G) = E-N+2 其中：E是控制流图中边的数量；N是控制流图中的节点数量。,计算环形复杂度如图5-5所示。 节点数量(用29表示)
42、N =8： 导出条边E=10。用（、编号表示） V(G) = E-N+2=10-8+2= 10（条边）- 8（个节点）+ 2 = 4 导出独立路径用路径1、 路径2、 路径3、路径4编号表示。,5.3.4 域测试法 域测试是一种基于程序结构的测试方法，基于对程序输入空间（域）的分析，选择测试点进行测试。主要为： 1）域错误：程序的控制流存在错误，对于某一特定的输入可能执行的是一条错误路径，这种错误称为路径错误，也叫做域错误； 2） 计算型错误：对于特定输入执行的路径正确，但赋值语句的错误导致输出结果错误，称为计算型错误； 3） 丢失路径错误：由于程序中的某处少了一个判定谓词而引起的丢失路径错误
43、。 域测试缺点是： 1) 为进行域测试对程序提出的限制过多； 2) 当程序存在很多路径时，所需的测试点很多。,5.3.5 符号测试法,符号测试基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，符号值可以是基本的符号变量值，也可以是符号变量值的表达式。 1） 符号测试执行的是代数运算，可以作为普通测试的一个扩充； 2） 符号测试可以看作是程序测试和程序验证的一个折衷办法； 3） 符号测试程序中仅有有限的几条执行路径；符号测试的缺点是： 分支问题不能控制； 二义性问题不能控制； 大程序问题不能控制。,5.3.6 Z路径覆盖法 分析程序中的路径是指检验程序从入口开始，执行过程中经历的各
44、个语句，直到出口。 Z路径覆盖 对循环机制进行简化，减少路径的数量，使得覆盖所有路径成为可能，简化循环意义下的路径覆盖称为Z路径覆盖（循环简化：限制循环次数，只考虑循环一次或零次情况），循环简化的目的是限制循环的次数，无论循环的形式和循环体实际执行的次数，简化后的循环测试只考虑执行循环体一次和零次（不执行）两种情况，即考虑执行时进入循环体一次和跳过循环体这两种情况。,5.3.7程序变异测试法 程序变异是一种错误驱动测试。错误驱动测试是指该方法是针对某类特定程序错误的，经过多年的测试理论研究和软件测试的实践，人们逐渐发现要想找出程序中所有的错误几乎是不可能的。比较现实的解决办法是将错误的搜索范围
45、尽可能地缩小，以利于专门测试某类错误是否存在。,5.4白盒测试的要求,5.4.1 软件各层公用问题的要求 各层公用测试主要问题有如下13大点内容。 1检查代码与设计对照表 代码与设计对照表要重点注意如下4点： 按软件需求检查CRC设计文档是否完全地实现了所有CRC卡中规定的内容，CRC设计文档完备、没有错误； 按软件需求检查UI设计文档是否完全地实现了所有的UI设计的规定要求UI设计完备、没有错误； 按软件需求检查编码对照表设计文档是否完全地实现了软件所规定的内容，完备、没有错误。 检查代码名，代码位数，代码含义，姓名，编号，删除，追加，修改是否实现设计的规定要求。,213大点的内容,请参见机
46、械工业出版社软件测试技术与测试实训教程( 2012.01)第1版第 5章 5.4.3节的内容,5.4.2 JAVA语言测试检查的要求 JAVA语言测试检查主要有如下9点内容: 1检查JAVA语言的下标是否有下标变量越界错误？ 2检查JAVA语言的除数是否包含有除零（n/0）错误的可能？ 3. 检查字符串 4. 检查字符串连结符“+“ 5. 检查浮点值、整型值应用没有错误； 6. 检查switch语句的应用没有错误； 7. 检查if语句的应用没有错误； 8. 检查循环语句的应用没有错误； 9. 检查数值范围是否存在溢出错误。,5.4.3 数据类型测试检查的要求 数据类型测试检查主要有如下5点内容
47、。 1. Null转化 在设置值对象VO时，在VO内部是否将空串“ “将转化null，数值型数据(整数、浮点数)null转为0.# 2. 检查控件数据类型的转换 编辑控件数据类型是否与表中对应字段数据类型一致。 3. 检查精度型(8位)、双精度型(20位)控件的范围控制 4. 检查小数位数的设置 5. 检查禁止输入字符的设置,5.4.4 SQL语句测试检查的要求 SQL语句测试检查主要有如下22大点内容。 请参见机械工业出版社软件测试技术与测试实训教程( 2012.01)第1版第5 章 5.4.4节的内容,5.4.5 界面测试检查的要求 界面UI检查主要有如下16大点内容。 请参见机械工业出版
48、社软件测试技术与测试实训教程( 2012.01)第1版第 5章 5.4.5节的内容,5.4.6 数值对象测试的要求 数值对象( Valuble Object)测试主要有11大点内容。 请参见机械工业出版社软件测试技术与测试实训教程( 2012.01)第1版第 5章5.4.6 节的内容,5.4.7 业务对象测试的要求业务对象( Business Object )测试主要有如下内容。 检查处理应用程序的业务逻辑和业务校验，是否完全地实现了软件所规定的内容，完备、没有错误； 检查允许与其它层相互作用的接口，是否完全地实现了软件所规定的内容，完备、没有错误； 检查管理业务层级别的对象的依赖，是否完全地实现了软件所规定的内容，完备、没有错误， 检查函数之间（考虑复用）功能独立，效率高，功能完整,全局看不雷同； 检查业务对象之间不考虑关系,全部都是函数载体； 检查类中是否存在名称相同且参数个数相同的方法（类中不能有名称相同且参数个数相同的两个方法同时存在）； 检查抛出异常功能（BO的所有业务方法都必须抛出异常，否则将不能生成EJB辅助代码）； 检查BO对象中使用环境变量时，使用方法是否有错误； 检查工具生成代码是否可用； 检查BO类中方法的命名是否反映该方法的业务含义； 检查BO类是否生成供客户端调用BS端的代码；检查向数据库插入一条记录时，是否为它提供获得唯一主键(OID)。,
