白盒测试技术
软件测试方法：分为两类
（1）静态测试：不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试
（2）动态测试：通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程，特点如下：
l 必须生成测试数据来运行被测试程序，取得程序运行的真实情况、动态情况，进而进行分析
l 测试质量依赖于测试数据
l 生成测试数据，分析测试结果的工作量大，使开展测试工作费时、费力、费人
l 动态测试中涉及多方面工作，人员多，设备多，数据多，要求有较好的管理和工作规程
（1）静态测试：不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试
（2）动态测试：通过输入一组预先按照一定的测试准则构造的实例数据动态运行程序，而达到发现程序错误的过程，特点如下：
l 必须生成测试数据来运行被测试程序，取得程序运行的真实情况、动态情况，进而进行分析
l 测试质量依赖于测试数据
l 生成测试数据，分析测试结果的工作量大，使开展测试工作费时、费力、费人
l 动态测试中涉及多方面工作，人员多，设备多，数据多，要求有较好的管理和工作规程
一．概述
1． 定义
也称结构测试或逻辑驱动测试，按照程序内部的结构对程序进行测试，通过测试来检查产品内部动作是否按照设计规格说明书的规定正常进行，检查程序中的每条通路是否能按照预定要求正确工作
2． 测试内容
把测试对象看成是一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序的所有逻辑路径进行测试，通过不同点检查程序的状态，确定实际的状态与预期的状态一致
3． 测试基本技术
（1）词法分析与语法分析
（2）静态错误分析
（3）程序插桩技术
4． 测试方法
（1）代码检查法
（2）静态结构分析法
（3）静态质量度量法
（4）逻辑覆盖法
（5）基本路径测试法
（6）域测试
（7）符号测试
（8）Z路径覆盖
（8） 程序变异
5．黑盒测试与白盒测试
黑盒测试 白盒测试
不涉及程序结构 考查程序逻辑结构
用软件规格说明书生成测试用例 用程序结构信息生成测试用例
可适用于从单元测试到系统联调 适用于单元测试和集成测试
某些代码段得不到测试 对所有逻辑路径进行测试
1． 定义
也称结构测试或逻辑驱动测试，按照程序内部的结构对程序进行测试，通过测试来检查产品内部动作是否按照设计规格说明书的规定正常进行，检查程序中的每条通路是否能按照预定要求正确工作
2． 测试内容
把测试对象看成是一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序的所有逻辑路径进行测试，通过不同点检查程序的状态，确定实际的状态与预期的状态一致
3． 测试基本技术
（1）词法分析与语法分析
（2）静态错误分析
（3）程序插桩技术
4． 测试方法
（1）代码检查法
（2）静态结构分析法
（3）静态质量度量法
（4）逻辑覆盖法
（5）基本路径测试法
（6）域测试
（7）符号测试
（8）Z路径覆盖
（8） 程序变异
5．黑盒测试与白盒测试
黑盒测试 白盒测试
不涉及程序结构 考查程序逻辑结构
用软件规格说明书生成测试用例 用程序结构信息生成测试用例
可适用于从单元测试到系统联调 适用于单元测试和集成测试
某些代码段得不到测试 对所有逻辑路径进行测试
二．白盒测试基本技术
1．词法和语法分析
（1）获取信息
l 可以获取软件组成的重要基本因数，如变量标识符、过程标识符、常量等
l 组合获取的基本因数，可以得到软件的基本信息，如：
v 标号交叉引用表：列出各模块中出现的全部标号及标号的属性，模块以外的全局、计算标号
v 变量交叉引用表：列出变量定义及引用信息，变量的属性，变量类型（全局、局部）
v 子程序、宏和函数表：列出各个子程序、宏及函数的属性，输入、输出参数信息
v 等价表：列出在等价语句和等值语句中出现的全部变量和标号
v 常数表：列出全部数字常数和字符常数
（2）作用
l 直接从表中查出说明/使用错误，如标号交叉引用表、变量交叉引用表
l 为用户提供辅助信息，如子程序、宏和函数表、等价表、常数表
l 用来做错误预测和程序复杂度计算，如操作符和操作数的统计 表
2．静态错误分析
用于确定在源程序中是否有某类错误或‘危险’结构，包括以下几种：
（1） 类型和单位分析
对源程序的类型进行检查，为了强化检查效果，扩充一些新的数据类型，进行静态预处理程序，分析程序中的类型错误
（2） 引用分析
l 对程序中变量的引用进行检查，发现引用异常错误（如变量在定义前被引用，变量定义后未被引用）。
l 采用深度优选的方法遍历程序流图的每一条路径
l 建立引用异常的探测工具，包括变量定义表和变量引用表
（3） 表达式分析
对表达式进行分析，以发现和纠正在表达式出现的错误，如：
l 在表达式中不正确的使用了括号造成错误
l 数组下标越界错误
l 除数为零
l 浮点数计算的误差（最复杂）
（4） 接口分析
接口一致性是程序的静态错误分析和设计分析共同研究的题目，接口分析主要对下内容时进行一致性的分析：
l 各模块之间接口一致性
l 模块与外部数据库的接口一致性
l 形参与实参在类型，数量，顺序，维数，使用上的一致性
l 全局变量和公共数据区在使用上的一致性
3．程序插桩技术
（1） 概述
在动态测试中，是一种基本的测试手段，有广泛的应用
主要借助向程序中插入操作，来实现测试目的的方法（即向源程序中添加一些语句（也称探测器），实现对程序语句的执行、变量的变化等情况进行检查）
（2） 设计时考虑的问题
l 明确要探测哪些信息
l 在程序的什么部位设置探测点
l 需要设计多少个探测点
（3） 探测点设置位置（以Fortran为例）
l 程序块的第一个可执行语句之前
l entry语句的前后
l 有标号的可执行语句处
l 循环语句之后
l 条件语句之后
l logical if语句之后
l call语句之后
l go to语句之后
（4） 断言语句
在程序中的特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程序的运行特性得到证实，我们把这些插入的语句称为断言语句。
三．白盒测试方法－静态测试
1． 代码检查法
（1） 目的
通过桌面检查，代码审查和走查方式，对以下内容进行检查
l 检查代码和设计的一致性
l 代码对标准的遵循、可读性
l 代码逻辑表达的正确性
l 代码结构的合理性
l 程序编写与编写标准的符合性
l 程序中不安全、不明确和模糊的部分
l 编程风格问题等
（2） 代码检查方式
方式名称 执行人员 检查内容 检查过程
桌面检查 程序员 对源程序代码进行分析、检验，并补充相关的文档，发现程序中的错误
代码审查 程序员和测试员组成的审查小组 通过阅读、讨论和争议，以程序进行静态分析的过程 第一步：小组成员提前阅读设计规格书、程序文本等相关文档第二步：召开程序审查会，开发人员读程序，审查小组讨论、发现、解决问题
走查 程序员和测试员组成的审查小组 通过逻辑运行程序，发现问题 第一步：小组成员提前阅读设计规格书、程序文本等相关文档第二步：利用测试用例，使程序逻辑运行，记录程序的踪迹，发现、讨论、解决问题
1．词法和语法分析
（1）获取信息
l 可以获取软件组成的重要基本因数，如变量标识符、过程标识符、常量等
l 组合获取的基本因数，可以得到软件的基本信息，如：
v 标号交叉引用表：列出各模块中出现的全部标号及标号的属性，模块以外的全局、计算标号
v 变量交叉引用表：列出变量定义及引用信息，变量的属性，变量类型（全局、局部）
v 子程序、宏和函数表：列出各个子程序、宏及函数的属性，输入、输出参数信息
v 等价表：列出在等价语句和等值语句中出现的全部变量和标号
v 常数表：列出全部数字常数和字符常数
（2）作用
l 直接从表中查出说明/使用错误，如标号交叉引用表、变量交叉引用表
l 为用户提供辅助信息，如子程序、宏和函数表、等价表、常数表
l 用来做错误预测和程序复杂度计算，如操作符和操作数的
2．静态错误分析
用于确定在源程序中是否有某类错误或‘危险’结构，包括以下几种：
（1） 类型和单位分析
对源程序的类型进行检查，为了强化检查效果，扩充一些新的数据类型，进行静态预处理程序，分析程序中的类型错误
（2） 引用分析
l 对程序中变量的引用进行检查，发现引用异常错误（如变量在定义前被引用，变量定义后未被引用）。
l 采用深度优选的方法遍历程序流图的每一条路径
l 建立引用异常的探测工具，包括变量定义表和变量引用表
（3） 表达式分析
对表达式进行分析，以发现和纠正在表达式出现的错误，如：
l 在表达式中不正确的使用了括号造成错误
l 数组下标越界错误
l 除数为零
l 浮点数计算的误差（最复杂）
（4） 接口分析
接口一致性是程序的静态错误分析和设计分析共同研究的题目，接口分析主要对下内容时进行一致性的分析：
l 各模块之间接口一致性
l 模块与外部数据库的接口一致性
l 形参与实参在类型，数量，顺序，维数，使用上的一致性
l 全局变量和公共数据区在使用上的一致性
3．程序插桩技术
（1） 概述
在动态测试中，是一种基本的测试手段，有广泛的应用
主要借助向程序中插入操作，来实现测试目的的方法（即向源程序中添加一些语句（也称探测器），实现对程序语句的执行、变量的变化等情况进行检查）
（2） 设计时考虑的问题
l 明确要探测哪些信息
l 在程序的什么部位设置探测点
l 需要设计多少个探测点
（3） 探测点设置位置（以Fortran为例）
l 程序块的第一个可执行语句之前
l entry语句的前后
l 有标号的可执行语句处
l 循环语句之后
l 条件语句之后
l logical if语句之后
l call语句之后
l go to语句之后
（4） 断言语句
在程序中的特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程序的运行特性得到证实，我们把这些插入的语句称为断言语句。
三．白盒测试方法－静态测试
1． 代码检查法
（1） 目的
通过桌面检查，代码审查和走查方式，对以下内容进行检查
l 检查代码和设计的一致性
l 代码对标准的遵循、可读性
l 代码逻辑表达的正确性
l 代码结构的合理性
l 程序编写与编写标准的符合性
l 程序中不安全、不明确和模糊的部分
l 编程风格问题等
（2） 代码检查方式
方式名称 执行人员 检查内容 检查过程
桌面检查 程序员 对源程序代码进行分析、检验，并补充相关的文档，发现程序中的错误
代码审查 程序员和测试员组成的审查小组 通过阅读、讨论和争议，以程序进行静态分析的过程 第一步：小组成员提前阅读设计规格书、程序文本等相关文档第二步：召开程序审查会，开发人员读程序，审查小组讨论、发现、解决问题
走查 程序员和测试员组成的审查小组 通过逻辑运行程序，发现问题 第一步：小组成员提前阅读设计规格书、程序文本等相关文档第二步：利用测试用例，使程序逻辑运行，记录程序的踪迹，发现、讨论、解决问题
（3） 代码检查项目（采用分析技术）
l 检查变量的交叉引用表：检查未说明的变量和违反了类型规定的变量，变量的引用和使用情况
l 检查标号的交叉引用表：验证所有标号的正确性
l 检查子程序、宏、函数：验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致
l 等价性检查：检查全部等价变量的类型的一致性
l 常量检查：确认常量的取值和数制、数据类型
l 标准检查：检查程序中是否违反标的问题
l 风格检查：检查程序的设计风格
l 比较控制流：比较设计控制流图和实际程序生成的控制流图的差异
l 选择、激活路径：在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活，则程序可能有错
l 对照程序的规格说明，详细阅读源代码，比较实际的代码，从差异中发现程序的问题和错误
l 补充文档
根据以上检查项目，可以编制代码规则，规范和检查表等作为测试用例
（4） 编码规范
程序编写过程中必须遵守的规则，规定代码的语法格式、语法规则，如排版、注释、标识符命名、可读性、变量、函数、过程、可测性、程序效率、质量保证、代码编辑、编译、审查、代码测试、维护、宏等各方面的编码要求
（5） 代码检查规则
对程序逻辑结构检查时，所规定的规则，形成
（6） 缺陷检查表
主要包括一些容易出错的地方和在以往工作中遇到的典型错误，形成表格形式
重要性 审查项 结论
文件结构 重要 头文件和定义文件的名称是否合理
2． 静态结构分析法
在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表，检查软件有没有存在缺陷或错误；包括控制流分析、数据据流分析、接口分析、表达式分析
（1） 函数调用关系图：通过应用程序各函数之间的调用关系展示了系统的结构。列出所有函数，用连线表示调用关系，作用：
l 可以检查函数的调用关系是否正确
l 是否存在孤立的函数而没有被调用
l 明确函数被调用的频繁度，对调用频繁的函数可以重点检查
（2） 模块控制流图：由许多结点和连接结点的边组成的图形，其中每个结点代表一条或多条语句，边表示控制流向，可以直观地反映出一个函数的内部结构。
*例子1－GIS软件：存在无法执行的死代码；有多个出口，可能没有在所有出口进行内存释放与回收，有内存泄露的可能
*例子2－MIS软件：有多个出口，存在内存泄露的可能；有10逻辑判断结点，易出现逻辑错误，降低可靠性，可能会破坏对CPU操作进行优化的处理，影响其运行性能
3． 静态质量度量法
（1） 软件质量：根据ISO/IEC9126 国际标准，包括以下六个方面：
l 功能性（functionality）
l 可靠性（reliability）
l 可用性（usability）
l 有效性（efficiency）
l 可维护性（maintainability）
l 轻便性（portability）
（2） 质量度量模型（从上到下）
l 质量因素（Factors）：与分类标准的计算方式相似，依据各分类标准取值组合权重方法来计算，依据结果将软件质量分为四个等级，与分类标准等级内容相同
l 分类标准（criteria）：对某一软件质量分为不同的分类标准，每个分类标准由一系列度量规则组成，每个规则分配一个权重，每个分类标准的取值由规则的取值与权重值计算得出，依据结果将软件质量分为四个等级：
v 优秀（excellent）：符合本模型框加中的所有规则（可以接受）
v 良好（good）：未大量偏离模型框架中的规则（可以接受）
v 一般（fair）：违背了模型框架中的大量规则（可以接受）
v 较差（poor）：无法保障正常的软件可维护性（不可以接受）
l 度量规则（Metrics）：使用代码行数、注释频度等参数度量软件各种行为属性
四． 白盒测试方法－动态测试（即设计测试用例的方法）
1． 白盒测试的动态测试原则－根据程序的控制结构设计测试用例
（1） 保证每个模块的所有独立路径至少被使用一次
（2） 对所有的逻辑值均测试true和false
（3） 上下边界及可操作范围内运行所有循环
（4） 检查内部数据结构以确保其有效性
2． 逻辑覆盖法
（1） 概述
逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖
（2） 分类－依据覆盖源程序语句的详尽程度
l 语句覆盖 SC（Statement Coverage）
l 判定覆盖 DC（Decision coverage）
l 条件覆盖 CC（Condition Coverage）
l 条件判定组合覆盖 CDC（Condition/ Decision Coverage）
l 多条件覆盖 MCC （Multiple Condition Coverage）
l 修改条件判定覆盖 MCDC（Multiple Condition Decision Coverage）
（3） 语句覆盖
l 选择足够多的测试数据，使被测程序中每条语句至少执行一次
l 缺点：对程序执行逻辑的覆盖很低
（4） 判定覆盖
l 设计足够多的测试用例，使得程序中的每一个判定至少获得一次‘真’值和‘假’值，或者使得程序中的每一个取‘真’分支或取‘假’分支至少经历一次，因此又称分支覆盖
l 可以满足语句覆盖
l 缺点：主要对整个表达式最终取值进行度量，忽略了表达式内部取值
（5） 条件覆盖
l 设计足够多的测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次
l 不能够满足判定覆盖
（6） 条件判定组合覆盖
l 设计足够多的测试用例，使得判定中的每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果也至少出现一次
l 缺点：没有考虑单个判定对整体结果的影响，无法发现逻辑错误
（7） 多条件覆盖
l 也称条件组合覆盖，设计足够多的测试用例，使得每个判定中条件的各种可能组合都至少出现一次（以数轴形式划分区域，提取交集，建立最少的测试用例）
l 满足条件覆盖一定满足判定覆盖、条件覆盖、条件判定组合覆盖
l 缺点：判定语句较多时，条件组合值比较多
（8） 修正条件判定覆盖
l 每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次
l 程序的判定被分解为通过逻辑操作符（and，or）连接的bool条件，每个条件对于判定的结果值是独立的
l 检查变量的交叉引用表：检查未说明的变量和违反了类型规定的变量，变量的引用和使用情况
l 检查标号的交叉引用表：验证所有标号的正确性
l 检查子程序、宏、函数：验证每次调用与所调用位置是否正确，调用的子程序、宏、函数是否存在，参数是否一致
l 等价性检查：检查全部等价变量的类型的一致性
l 常量检查：确认常量的取值和数制、数据类型
l 标准检查：检查程序中是否违反标的问题
l 风格检查：检查程序的设计风格
l 比较控制流：比较设计控制流图和实际程序生成的控制流图的差异
l 选择、激活路径：在设计控制流图中选择某条路径，到实际的程序中激活这条路径，如果不能激活，则程序可能有错
l 对照程序的规格说明，详细阅读源代码，比较实际的代码，从差异中发现程序的问题和错误
l 补充文档
根据以上检查项目，可以编制代码规则，规范和检查表等作为测试用例
（4） 编码规范
程序编写过程中必须遵守的规则，规定代码的语法格式、语法规则，如排版、注释、标识符命名、可读性、变量、函数、过程、可测性、程序效率、质量保证、代码编辑、编译、审查、代码测试、维护、宏等各方面的编码要求
（5） 代码检查规则
对程序逻辑结构检查时，所规定的规则，形成
（6） 缺陷检查表
主要包括一些容易出错的地方和在以往工作中遇到的典型错误，形成表格形式
重要性 审查项 结论
文件结构 重要 头文件和定义文件的名称是否合理
2． 静态结构分析法
在静态结构分析中，测试者通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构，生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形图表，清晰地标识整个软件的组成结构，便于理解，通过分析这些图表，检查软件有没有存在缺陷或错误；包括控制流分析、数据据流分析、接口分析、表达式分析
（1） 函数调用关系图：通过应用程序各函数之间的调用关系展示了系统的结构。列出所有函数，用连线表示调用关系，作用：
l 可以检查函数的调用关系是否正确
l 是否存在孤立的函数而没有被调用
l 明确函数被调用的频繁度，对调用频繁的函数可以重点检查
（2） 模块控制流图：由许多结点和连接结点的边组成的图形，其中每个结点代表一条或多条语句，边表示控制流向，可以直观地反映出一个函数的内部结构。
*例子1－GIS软件：存在无法执行的死代码；有多个出口，可能没有在所有出口进行内存释放与回收，有内存泄露的可能
*例子2－MIS软件：有多个出口，存在内存泄露的可能；有10逻辑判断结点，易出现逻辑错误，降低可靠性，可能会破坏对CPU操作进行优化的处理，影响其运行性能
3． 静态质量度量法
（1） 软件质量：根据ISO/IEC9126 国际标准，包括以下六个方面：
l 功能性（functionality）
l 可靠性（reliability）
l 可用性（usability）
l 有效性（efficiency）
l 可维护性（maintainability）
l 轻便性（portability）
（2） 质量度量模型（从上到下）
l 质量因素（Factors）：与分类标准的计算方式相似，依据各分类标准取值组合权重方法来计算，依据结果将软件质量分为四个等级，与分类标准等级内容相同
l 分类标准（criteria）：对某一软件质量分为不同的分类标准，每个分类标准由一系列度量规则组成，每个规则分配一个权重，每个分类标准的取值由规则的取值与权重值计算得出，依据结果将软件质量分为四个等级：
v 优秀（excellent）：符合本模型框加中的所有规则（可以接受）
v 良好（good）：未大量偏离模型框架中的规则（可以接受）
v 一般（fair）：违背了模型框架中的大量规则（可以接受）
v 较差（poor）：无法保障正常的软件可维护性（不可以接受）
l 度量规则（Metrics）：使用代码行数、注释频度等参数度量软件各种行为属性
四． 白盒测试方法－动态测试（即设计测试用例的方法）
1． 白盒测试的动态测试原则－根据程序的控制结构设计测试用例
（1） 保证每个模块的所有独立路径至少被使用一次
（2） 对所有的逻辑值均测试true和false
（3） 上下边界及可操作范围内运行所有循环
（4） 检查内部数据结构以确保其有效性
2． 逻辑覆盖法
（1） 概述
逻辑覆盖是通过对程序逻辑结构的遍历实现程序的覆盖
（2） 分类－依据覆盖源程序语句的详尽程度
l 语句覆盖 SC（Statement Coverage）
l 判定覆盖 DC（Decision coverage）
l 条件覆盖 CC（Condition Coverage）
l 条件判定组合覆盖 CDC（Condition/ Decision Coverage）
l 多条件覆盖 MCC （Multiple Condition Coverage）
l 修改条件判定覆盖 MCDC（Multiple Condition Decision Coverage）
（3） 语句覆盖
l 选择足够多的测试数据，使被测程序中每条语句至少执行一次
l 缺点：对程序执行逻辑的覆盖很低
（4） 判定覆盖
l 设计足够多的测试用例，使得程序中的每一个判定至少获得一次‘真’值和‘假’值，或者使得程序中的每一个取‘真’分支或取‘假’分支至少经历一次，因此又称分支覆盖
l 可以满足语句覆盖
l 缺点：主要对整个表达式最终取值进行度量，忽略了表达式内部取值
（5） 条件覆盖
l 设计足够多的测试用例，使得每一判定语句中每个逻辑条件的可能值至少满足一次
l 不能够满足判定覆盖
（6） 条件判定组合覆盖
l 设计足够多的测试用例，使得判定中的每个条件的所有可能（真/假）至少出现一次，并且每个判定本身的判定结果也至少出现一次
l 缺点：没有考虑单个判定对整体结果的影响，无法发现逻辑错误
（7） 多条件覆盖
l 也称条件组合覆盖，设计足够多的测试用例，使得每个判定中条件的各种可能组合都至少出现一次（以数轴形式划分区域，提取交集，建立最少的测试用例）
l 满足条件覆盖一定满足判定覆盖、条件覆盖、条件判定组合覆盖
l 缺点：判定语句较多时，条件组合值比较多
（8） 修正条件判定覆盖
l 每一个程序模块的入口和出口点都要考虑至少要被调用一次，每个程序的判定到所有可能的结果值要至少转换一次
l 程序的判定被分解为通过逻辑操作符（and，or）连接的bool条件，每个条件对于判定的结果值是独立的
练习1：采用多条件覆盖方法，对下程序进行白盒测试用例设计
if ((a >1 )&&( b= = 0))
{
x=x/a;
}
if (( a = = 2)|| (x > 1 ))
{
x=x+1;
}
if ((a >1 )&&( b= = 0))
{
x=x/a;
}
if (( a = = 2)|| (x > 1 ))
{
x=x+1;
}
3． 基本路径覆盖
（1） 概述
l 在程序控制流图的基础上，通过分析程序控制流图的环路复杂性，导出基本可执行路径的集合，然后据此设计测试用例
l 设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次
（2） 程序控制流图
l 控制流图是描述程序控制流的一种方式
l 图形符号：圆圈代表一个结点 表示一个或多个无分支的语句或源程序语句
l 边和点圈定的部分叫做区域。当对区域计数时，图形外的一个部分也应记为一个区域
l 判断语句中的条件为复合条件时，即条件表达式由一个或多个逻辑运算符连接的逻辑表达式（a and b），则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断
图形符号图所示
（1） 概述
l 在程序控制流图的基础上，通过分析程序控制流图的环路复杂性，导出基本可执行路径的集合，然后据此设计测试用例
l 设计出的测试用例要保证在测试中程序的每一条可执行语句至少执行一次
（2） 程序控制流图
l 控制流图是描述程序控制流的一种方式
l 图形符号：圆圈代表一个结点 表示一个或多个无分支的语句或源程序语句
l 边和点圈定的部分叫做区域。当对区域计数时，图形外的一个部分也应记为一个区域
l 判断语句中的条件为复合条件时，即条件表达式由一个或多个逻辑运算符连接的逻辑表达式（a and b），则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断
图形符号图所示
（3） 程序环路复杂性
l 程序的环路复杂性即McCabe复杂性度量，简单的定义为控制流图的区域数
l 从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界
l 独立路径：包括一组以前没有处理的语句或条件的一条路径
l 通常环路复杂性可用以下三种方法求得：
v 将环路复杂性定义为控制流图中的区域数。
v 设E为控制流图的边数，N为图的结点数，则定义环路复杂性为 V(G)＝E－N＋2。
v 若设P为控制流图中的判定结点数，则有 V(G)＝P＋1。
（4） 基本路径测试步骤
l 以详细设计或源代码为基础，导出程序的控制流图
l 计算得到控制流图G的环路复杂性v(g)
l 确定线性无关的路径的基本集
l 生成测试用例，确保基本路径集中每条路径的执行
l 程序的环路复杂性即McCabe复杂性度量，简单的定义为控制流图的区域数
l 从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必须的测试用例数目的上界
l 独立路径：包括一组以前没有处理的语句或条件的一条路径
l 通常环路复杂性可用以下三种方法求得：
v 将环路复杂性定义为控制流图中的区域数。
v 设E为控制流图的边数，N为图的结点数，则定义环路复杂性为 V(G)＝E－N＋2。
v 若设P为控制流图中的判定结点数，则有 V(G)＝P＋1。
（4） 基本路径测试步骤
l 以详细设计或源代码为基础，导出程序的控制流图
l 计算得到控制流图G的环路复杂性v(g)
l 确定线性无关的路径的基本集
l 生成测试用例，确保基本路径集中每条路径的执行
五． 其他白盒测试方法
1． 域测试
（1） 概述
是一种基于程序结构的测试方法，基于对程序输入空间（域）的分析，选择适的测试点进行测试
（2） Howden错误分类－相对于程序路径分类
l 域错误：程序的控制流存在错误，对于某一特定的输入可能执行的是一条错误路径，这种错误称为路径错误，也叫做域错误
l 计算型错误：对于特定输入执行的路径正确，但赋值语句的错误导致输出结果错误，称为计算型错误
l 丢失路径错误：由于程序中的某处少了一个判定谓词而引起的
（3） 测试理想结果：检验输入空间的每一个输入元素是否都产生正确的结果
（4） 缺点
l 为进行域测试对程序提出的限制过多
l 当程序存在很多路径时，所需的测试点很多
2． 符号测试
（1） 概述
l 基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，符号值可以是基本的符号变量值，也可以是符号变量值的表达式。
l 符号测试执行的是代数运算，可以作为普通测试的一个扩充
l 符号测试可以看作是程序测试和程序验证的一个折衷办法
（2） 测试理想情况：程序中仅有有限的几条执行路径，如果都完成了符号测试，就可把握的确认程序的正确性了
（3） 缺点
l 分支问题
l 二义性问题
l 大程序问题
3． Z路径覆盖
（1） 概述
对循环机制进行简化，减少路径的数量，使得覆盖所有路径成为可能，简化循环意义下的路径覆盖称为Z路径覆盖
（2） 循环简化：限制循环次数，只考虑循环一次或零次情况
4． 程序变异
（1） 概述
是一种错误驱动测试
错误驱动测试：指该方法是针对某类特定程序错误的，即专门测试某类错误是否存在
错误驱动测试分类：程序强变异和程序弱变异
（2） 优点：便于集中目标对软件危害最大的可能错误，提高测试效率，降低成本
六． 白盒测试综合策略
1． 白盒测试中测试方法的选择策略
（1） 在测试中，首先尽量使用测试工作进行静态结构分析
（2） 采先静态后动态的组合方式，先进行静态结构分析，代码检查和静态质量度量，然后现进行覆盖测试
（3） 利用静态结构分析的结果，通过代码检查和动态测试的方法对结果进一步确认，使测试工作更为有效
（4） 覆盖率测试是白盒测试的重点，使用基本路径测试达到语句覆盖标准；对于重点模块，应使用多种覆盖标准衡量代码的覆盖率
（5） 不同测试阶段，侧重点不同
l 单元测试：以代码检查、逻辑覆盖
l 集成测试：增加静构结构分析、静态质量度量
l 系统测试：根据黑盒测试结果，采用白盒测试
2． 最少测试用例数计算
l 将构成循环操作的重复型结构用选择结构代替，因此在N-S图中只存在顺序和分支操作
l N-S图按分支结构分层，整个程序的最少测试用例数为每个分层中最少测试用例数的乘积
3． 测试覆盖标准
l Foster的ESTCA覆盖标准
l Woodward等人的层次LCSAJ覆盖标准
1． 域测试
（1） 概述
是一种基于程序结构的测试方法，基于对程序输入空间（域）的分析，选择适的测试点进行测试
（2） Howden错误分类－相对于程序路径分类
l 域错误：程序的控制流存在错误，对于某一特定的输入可能执行的是一条错误路径，这种错误称为路径错误，也叫做域错误
l 计算型错误：对于特定输入执行的路径正确，但赋值语句的错误导致输出结果错误，称为计算型错误
l 丢失路径错误：由于程序中的某处少了一个判定谓词而引起的
（3） 测试理想结果：检验输入空间的每一个输入元素是否都产生正确的结果
（4） 缺点
l 为进行域测试对程序提出的限制过多
l 当程序存在很多路径时，所需的测试点很多
2． 符号测试
（1） 概述
l 基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，符号值可以是基本的符号变量值，也可以是符号变量值的表达式。
l 符号测试执行的是代数运算，可以作为普通测试的一个扩充
l 符号测试可以看作是程序测试和程序验证的一个折衷办法
（2） 测试理想情况：程序中仅有有限的几条执行路径，如果都完成了符号测试，就可把握的确认程序的正确性了
（3） 缺点
l 分支问题
l 二义性问题
l 大程序问题
3． Z路径覆盖
（1） 概述
对循环机制进行简化，减少路径的数量，使得覆盖所有路径成为可能，简化循环意义下的路径覆盖称为Z路径覆盖
（2） 循环简化：限制循环次数，只考虑循环一次或零次情况
4． 程序变异
（1） 概述
是一种错误驱动测试
错误驱动测试：指该方法是针对某类特定程序错误的，即专门测试某类错误是否存在
错误驱动测试分类：程序强变异和程序弱变异
（2） 优点：便于集中目标对软件危害最大的可能错误，提高测试效率，降低成本
六． 白盒测试综合策略
1． 白盒测试中测试方法的选择策略
（1） 在测试中，首先尽量使用测试工作进行静态结构分析
（2） 采先静态后动态的组合方式，先进行静态结构分析，代码检查和静态质量度量，然后现进行覆盖测试
（3） 利用静态结构分析的结果，通过代码检查和动态测试的方法对结果进一步确认，使测试工作更为有效
（4） 覆盖率测试是白盒测试的重点，使用基本路径测试达到语句覆盖标准；对于重点模块，应使用多种覆盖标准衡量代码的覆盖率
（5） 不同测试阶段，侧重点不同
l 单元测试：以代码检查、逻辑覆盖
l 集成测试：增加静构结构分析、静态质量度量
l 系统测试：根据黑盒测试结果，采用白盒测试
2． 最少测试用例数计算
l 将构成循环操作的重复型结构用选择结构代替，因此在N-S图中只存在顺序和分支操作
l N-S图按分支结构分层，整个程序的最少测试用例数为每个分层中最少测试用例数的乘积
3． 测试覆盖标准
l Foster的ESTCA覆盖标准
l Woodward等人的层次LCSAJ覆盖标准
黑盒测试
一． 黑盒测试概述
1．定义
l 也称功能测试，它是通过测试来检测每个功能是否都能正常使用
l 把程序看成一个黑盒子，完全不考虑程序内部结构和内部特性，着眼于程序外部结构，不考虑内部逻辑结构
l 在程序接口进行测试，只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息
l 主要针对软件界面和软件功能进行测试
2．试图发现的错误类型
l 功能不正确或遗漏
l 界面错误（输入能否正确的接受？能否输出正确的结果）
l 数据库访问错误（如数据结构定义错误或外部信息（如数据文件）访问错误）
l 性能错误
l 初始化和终止错误
3．黑盒测试用例设计方法
（1） 等价类划分法：把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类的其他值
（2） 边界值分析法：通过选择等价类边界的测试用例。不仅重视输入条件边界，而且也必须考虑输出域边界
（3） 错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法
（4） 因果图法：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输入或程序状态的改变），可以通过因果图转换成判定表
（5） 判定表驱动法：利用判定表进行测试用例的设计
（6） 正交试验设计法：使用已设计好的正交表格来安排试验，并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率
（7） 功能图法：用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成
二． 黑盒测试用例设计方法
1．等价类划分法
（1）划分基础：需求规格说明书中输入、输出要求
（2）等价类：某个输入域的子集合；分为有效等价类和无效等价类
l 有效等价类：指对于程序规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中的功能和性能
l 无效等价类：与有效等价的定义恰巧相反
（3）划分等价类原则（6条）
序号 输入条件（数据） 划分等价类
1 规定了取值范围值的个数 一个有效等价类两个无效等价类
2 规定了输入值的集合规定了“必须如何”的条件 一个有效等价类一个无效等价类
3 是一个布尔量 一个有效等价类一个无效等价类
4 输入数据的一组值（n个），并且程序对每一个输入值分别进行处理 n个有效等价类一个无效等价类
5 规定必须遵守的规则 一个有效等价类（符合规则）若干个无效等价类
6 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
（4） 列出等价类表
在确定了等价类之后，建立等价类表，列出所有划分出的等价类
输入条件 有效等价类 无效等类
…… …… ……
l 也称功能测试，它是通过测试来检测每个功能是否都能正常使用
l 把程序看成一个黑盒子，完全不考虑程序内部结构和内部特性，着眼于程序外部结构，不考虑内部逻辑结构
l 在程序接口进行测试，只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息
l 主要针对软件界面和软件功能进行测试
2．试图发现的错误类型
l 功能不正确或遗漏
l 界面错误（输入能否正确的接受？能否输出正确的结果）
l 数据库访问错误（如数据结构定义错误或外部信息（如数据文件）访问错误）
l 性能错误
l 初始化和终止错误
3．黑盒测试用例设计方法
（1） 等价类划分法：把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类的其他值
（2） 边界值分析法：通过选择等价类边界的测试用例。不仅重视输入条件边界，而且也必须考虑输出域边界
（3） 错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法
（4） 因果图法：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输入或程序状态的改变），可以通过因果图转换成判定表
（5） 判定表驱动法：利用判定表进行测试用例的设计
（6） 正交试验设计法：使用已设计好的正交表格来安排试验，并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率
（7） 功能图法：用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型构成
二． 黑盒测试用例设计方法
1．等价类划分法
（1）划分基础：需求规格说明书中输入、输出要求
（2）等价类：某个输入域的子集合；分为有效等价类和无效等价类
l 有效等价类：指对于程序规格说明书来说是合理的、有意义的输入数据构成的集合。利用有效等价类可以检验程序是否实现了规格说明书中的功能和性能
l 无效等价类：与有效等价的定义恰巧相反
（3）划分等价类原则（6条）
序号 输入条件（数据） 划分等价类
1 规定了取值范围值的个数 一个有效等价类两个无效等价类
2 规定了输入值的集合规定了“必须如何”的条件 一个有效等价类一个无效等价类
3 是一个布尔量 一个有效等价类一个无效等价类
4 输入数据的一组值（n个），并且程序对每一个输入值分别进行处理 n个有效等价类一个无效等价类
5 规定必须遵守的规则 一个有效等价类（符合规则）若干个无效等价类
6 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类
（4） 列出等价类表
在确定了等价类之后，建立等价类表，列出所有划分出的等价类
输入条件 有效等价类 无效等类
…… …… ……
（5） 确定测试用例步骤
l 第一步：为每个等价类规定一个惟一的编号
l 第二步：设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
l 第三步：设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
小结：采用等价类划分方法设计测试用例，按照划分等价类、列出等价列表、确定测试用例三个步骤完成，目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。
l 第一步：为每个等价类规定一个惟一的编号
l 第二步：设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
l 第三步：设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
小结：采用等价类划分方法设计测试用例，按照划分等价类、列出等价列表、确定测试用例三个步骤完成，目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。
2．边界值分析法
（1） 边界类型
l 边界条件：可以在产品说明书中有定义或者在使用软件过程中确定
l 次边界条件：在软件内部，也称为内部边界条件
l 其他边界条件：如输入信息为空（对于此类问题应建立单独的等价类空间）、非法、错误、不正确和垃圾数据
（2）边界值的选择方法（遵循原则）
序号 输入条件（数据） 输入边界值数据
1 规定了取值范围 刚刚达到这个范围刚刚超越这个范围
2 规定值的个数 最大个数、比最大个数大1最小个数、比最小个数少1
3 根据规格说明书的每个输出条件，使用 原则1、2
4 输入或输出是个有序集合 集合的第一个、最后一个元素
5 程序中使用一个内部数据结构 内部数据结构边界上的值
6 分析规格说明，找出其他可能的边界
（1） 边界类型
l 边界条件：可以在产品说明书中有定义或者在使用软件过程中确定
l 次边界条件：在软件内部，也称为内部边界条件
l 其他边界条件：如输入信息为空（对于此类问题应建立单独的等价类空间）、非法、错误、不正确和垃圾数据
（2）边界值的选择方法（遵循原则）
序号 输入条件（数据） 输入边界值数据
1 规定了取值范围 刚刚达到这个范围刚刚超越这个范围
2 规定值的个数 最大个数、比最大个数大1最小个数、比最小个数少1
3 根据规格说明书的每个输出条件，使用 原则1、2
4 输入或输出是个有序集合 集合的第一个、最后一个元素
5 程序中使用一个内部数据结构 内部数据结构边界上的值
6 分析规格说明，找出其他可能的边界
（3）例子：
l 允许文本输入1～255个字符：测试用例－1、255、254、0、256
l 程序读写软盘：测试用例－文件很小、等于软盘容量限制之内、空、超过
l 程序允许在一张纸上打印多个页面：测试用例－只打印一页，规定最大页，0页，大于允许最大页数
l 允许文本输入1～255个字符：测试用例－1、255、254、0、256
l 程序读写软盘：测试用例－文件很小、等于软盘容量限制之内、空、超过
l 程序允许在一张纸上打印多个页面：测试用例－只打印一页，规定最大页，0页，大于允许最大页数
3．错误推测法
基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例
基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例
4．因果图法
侧重于输入条件的各种组合，各个输入情况之间的相互制约关系
（1） 因果图设计方法
从用自然语言书写的程序规格说明的描述中找出因果，通过因果图转换成判定表
（2） 因果图导出测试用例步骤
l 第一步：分析程序规格说明的描述中，哪些是原因，哪些是结果。原在因常常是输入条件或是输入条件的等价类，结果是输出条件
l 第二步：分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的‘因果图’
l 第三步：标明约束条件
l 第四步：把因果图转换成判定表
l 第五步：为判定表中每一列表示的情况设计测试用例
（3） 因果图基本图形符号
通常在因果图中，用Ci 表示原因，Ei表示结果，各结点表示状态，可取值0（状态不出现） 或1（某状态出现）
l 恒等：若原因出现，则结果出现；若原因不出现，则结果不出现
l 非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现
l 或（V）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现；
l 与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现
（4） 因果图的约束符号
从输入（原因）考虑四种约束
l E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
l I（包含）：表示三个原因中至少有一个必须成立
l O（惟一）：表示两个原因中必须有一个，且仅有一个成立
l R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
从输出（结果）考虑一种约束
l M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定
2005-4-19
5．判定表驱动法
（1） 判定表：是分析和表达多逻辑条件下执行不同操作的情况的工具
（2） 判定表组成
l 条件桩：列出了问题的所有条件
l 动作桩：列出了问题规定可能采取的操作
l 条件项：列出针对它所列条件的取值，在所有可能情况下的真假值
l 动作项：列出在条件项的各种取值情况下应该采取的动作
l 规则：任何一个条件组合的特定取值及其相应要执行的操作
注：判定表中贯穿条件项和动作项的一列就是一条规则；
（3） 判定表的建立（步）
l 第一步：确定规则的个数。假如有n个条件，每个条件有两个取值（0,1），故有2n种规则
l 第二步：列出所有的条件桩和动作桩
l 第三步：填入条件项
l 第四步：填入动作项。制定初始判定表
l 第五步：简化。合并相似规则或者相同动作
（4） 适合使用判定表设计测试用例的条件
l 规格说明以判定表的形式给出，或很容易转换成判定表
l 条件的排列顺序不影响执行哪些操作
l 规则的排列顺序不影响执行哪些操作
l 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
l 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要
侧重于输入条件的各种组合，各个输入情况之间的相互制约关系
（1） 因果图设计方法
从用自然语言书写的程序规格说明的描述中找出因果，通过因果图转换成判定表
（2） 因果图导出测试用例步骤
l 第一步：分析程序规格说明的描述中，哪些是原因，哪些是结果。原在因常常是输入条件或是输入条件的等价类，结果是输出条件
l 第二步：分析程序规格说明的描述中语义的内容，并将其表示成连接各个原因与各个结果的‘因果图’
l 第三步：标明约束条件
l 第四步：把因果图转换成判定表
l 第五步：为判定表中每一列表示的情况设计测试用例
（3） 因果图基本图形符号
通常在因果图中，用Ci 表示原因，Ei表示结果，各结点表示状态，可取值0（状态不出现） 或1（某状态出现）
l 恒等：若原因出现，则结果出现；若原因不出现，则结果不出现
l 非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现
l 或（V）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现；
l 与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现
（4） 因果图的约束符号
从输入（原因）考虑四种约束
l E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
l I（包含）：表示三个原因中至少有一个必须成立
l O（惟一）：表示两个原因中必须有一个，且仅有一个成立
l R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
从输出（结果）考虑一种约束
l M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定
2005-4-19
5．判定表驱动法
（1） 判定表：是分析和表达多逻辑条件下执行不同操作的情况的工具
（2） 判定表组成
l 条件桩：列出了问题的所有条件
l 动作桩：列出了问题规定可能采取的操作
l 条件项：列出针对它所列条件的取值，在所有可能情况下的真假值
l 动作项：列出在条件项的各种取值情况下应该采取的动作
l 规则：任何一个条件组合的特定取值及其相应要执行的操作
注：判定表中贯穿条件项和动作项的一列就是一条规则；
（3） 判定表的建立（步）
l 第一步：确定规则的个数。假如有n个条件，每个条件有两个取值（0,1），故有2n种规则
l 第二步：列出所有的条件桩和动作桩
l 第三步：填入条件项
l 第四步：填入动作项。制定初始判定表
l 第五步：简化。合并相似规则或者相同动作
（4） 适合使用判定表设计测试用例的条件
l 规格说明以判定表的形式给出，或很容易转换成判定表
l 条件的排列顺序不影响执行哪些操作
l 规则的排列顺序不影响执行哪些操作
l 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
l 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要
2005-4-20
6．正交试验法
（1） 概述
l 从大量的试验数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试验设计方法
l 使用已造好的表格“－”正交表来安排试验并进行数据分析的一种方法
l 因子：影响实现指标的条件
l 因子的状态：影响实现因子的条件
（2） 优点
l 节省测试工时
l 可控制生成的测试用例的数量
l 测试用例具有一定的覆盖率
（3） 设计步骤
l 提取功能说明，构造因子‘－’状态表。
l 加权筛选，生成因素分析表；
l 利用正交表构造测试数据集，正交表的推导依据Galois理论
L：代表正交表，L8（27）代表7为因子数，2为因子的水平数，8为此表行的数目（试验次数）
行数为mn型的正交表中，试验次数（行数）＝∑（每列水平数－1）＋1
例：5个3水平因子及一个2水平因子，表示为35*21，试验次数＝5*(3-1)+1*(2-1)+1＝12，
即L12（35*2）
7．功能图法
（1） 程序功能说明的组成
l 动态说明：描述输入数据的次序或转移次序
l 静态说明：描述输入条件和输出条件之间的对应关系
（2） 功能图：由状态迁移图和布尔函数组成，状态迁移图用状态和迁移来表示。一个状态指出数据输入的位置（或时间），一个迁移指明状态的改变，同时要依靠判定表或因果图表示的逻辑功能
（3） 功能图法概述
l 用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例
l 功能图模型由状态迁移图和逻辑功能模型构成
v 状态迁移图：用于表示输入数据序列以及相应的输出数据；由输入数据和当前状态决定输出数据和后续状态
v 逻辑功能模型：用于表示在状态中输入条件和输出条件的对应关系。由输入数据决定输出数据。此模型只适用于描述静态说明
l 功能图测试用例由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满中的一对条件组成
（4） 测试用例生成方法
从状态迁移图中选取测试用例，用节点代替状态，用弧线代替迁移，状态图就可转化成一个程序的控制流程图形式
（5） 测试用例生成规则
为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来，从功能图生成实用的测试用例，在一个结构化的状态迁移（SST）中，定义3种形式的循环：顺序，选择和重复
（6） 功能图生成测试用例步骤
l 生成局部测试用例：在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成
l 测试路径生成：利用上面的规则生成从初始状态到最后状态的测试路径
l 测试用例合成：合成测试路径与功能图中每个状态的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。
l 测试用例的合成算法：采用条件构造树
8．场景法
（1） 基本流和备选流
采用此方法进行设计时，需要进行场景的设计，在场景中采用基本流和备选流表示经过用例的每条路径
l 基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
l 备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）
（2） 设计步骤
l 根据说明，描述出程序的基本流及各项备选流
l 根据基本流和各项备选流生成不同的场景
l 对每一个场景生成相应的测试用例
l 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
三． 黑盒测试用例设计方法的选择策略
1． 首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少测试量和提高测试效率的最有效办法
2． 在任何情况下都必须使用边界值分析方法。此方法设计的测试用例发现程序错误的能力最强
3． 可以用错误和推测法追加一些测试用例
4． 对照程序的逻辑，检查已设计的测试用例的逻辑覆盖度，如果没有达到要求，应在补充
5． 如果程序的功能说明中含有输入条件的组合情况，一开始就可以使用因果图法和判定表驱动法
6． 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
7． 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的数据
8． 对于业务流清晰的系统，可以利用场景法贯空整个测试案例过程，在案例中综合使用各种方法
四． 测试用例的编写
1. 测试用例概述
（1） 定义
l 将测试行为具体量化的方法之一
l 设计一种情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果
l 为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据，
l 一个好的测试用例是在于它能发现至今未发现的错误
（2） 优点：
l 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率
l 测试用例的使用令软件测试的实施重点突出、目的明确
l 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期
l 功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升
2．计划测试用例的目的
（3） 计划测试用例，是达成测试目标的必由之路
（4） 组织性：使测试用例具有组织性，便于全体测试员和其他项目小组人员有效地审查和使用
（5） 重复性和跟踪，可以明确测试过程中测试用例的执行情况，保证测试的全面性
（6） 计划测试用例，可以避免发布忽略某些测试用例的软件
（7） 测试证实，正确的测试用例计划和跟踪提供了一种证实测试的手段
3．测试设计说明
（1） 定义：在测试计划中提炼测试方法，要明确指出设计包含的特性以及相关的测试用例和测试程序，并指定判断通过/失败的规则
（2） 目的；组织和描述针对具体特性需要进行的测试，注：不给出具体的测试用例或执行测试的步骤
（3） 包含的部分内容（来自ANSI/IEEE829 ANSI 美国国家标准化组织）
l 标识符：用于引用和定位测试设计说明的惟一标识符
l 要测试的特性：对测试设计说明所包含的软件特性的描述。还将明确出要间接测试的特性
l 方法：描述测试的通用方法。如果方法在测试计划中描述，在测试设计说明中要详细描述要使用的技术，并给出如何验证测试结果的方法
l 测试用例信息：用于描述所引用的测试用例的相关信息。如测试用例编号
l 通过/失败规则：描述用什么规则来判定某项特性的测试结果是通过还是失败。
4．测试用例说明
（1） 定义（ANSI/IEEE829）：编写用于输入的实际数据和预期结果，并明确指出使用具体测试用例产生的测试程序的任何限制
（2） 包含的内容
l 标识符：由测试设计过程说明和测试程序说明引用的唯一标识符
l 测试项：描述被测试的详细特性、代码模块等
l 输入说明：列举执行测试用例的所有输入内容或者条件
l 输出说明：描述进行测试用例预期的结果
l 环境要求：执行测试用例的软件、硬件、测试工具及人员等要求
l 特殊要求：描述执行测试用例的特殊要求
l 用例之间的依赖性：注明与其分用例的依赖关系或受其他用例的影响
5. 测试程序说明
（1） 定义：明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤，有时也称为‘测试脚本说明’，即详细定义了执行测试用例的每一步操作
（2） 包含的内容
l 标识符：把测试程序与相关测试用例和测试设计相联系的惟一标识
l 目的：本程序描述的目的以及将要执行的测试用例的引用信息
l 特殊要求：执行测试所需的其他程、特殊测试技术或者特殊设备
l 程序步骤：执行测试用例的详细描述，包括
v 日志：指出记录测试结果和现象的方式
v 设置：如何准备测试
v 启动：启动测试的步骤
v 程序：运行测试的步骤
v 衡量标准：描述如何判断结果
v 关闭：描述因意外原因页推迟测试的步骤
v 终止：描述正常停止测试的步骤
v 重置：说明如何把环境恢复到测试前的状态
v 偶然事件：说明如何处理计划之外的情况
（1） 基本流和备选流
采用此方法进行设计时，需要进行场景的设计，在场景中采用基本流和备选流表示经过用例的每条路径
l 基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
l 备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）
（2） 设计步骤
l 根据说明，描述出程序的基本流及各项备选流
l 根据基本流和各项备选流生成不同的场景
l 对每一个场景生成相应的测试用例
l 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值
三． 黑盒测试用例设计方法的选择策略
1． 首先进行等价类划分，包括输入条件和输出条件的等价类划分，将无限测试变成有限测试，这是减少测试量和提高测试效率的最有效办法
2． 在任何情况下都必须使用边界值分析方法。此方法设计的测试用例发现程序错误的能力最强
3． 可以用错误和推测法追加一些测试用例
4． 对照程序的逻辑，检查已设计的测试用例的逻辑覆盖度，如果没有达到要求，应在补充
5． 如果程序的功能说明中含有输入条件的组合情况，一开始就可以使用因果图法和判定表驱动法
6． 对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果
7． 功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的数据
8． 对于业务流清晰的系统，可以利用场景法贯空整个测试案例过程，在案例中综合使用各种方法
四． 测试用例的编写
1. 测试用例概述
（1） 定义
l 将测试行为具体量化的方法之一
l 设计一种情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果
l 为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据，
l 一个好的测试用例是在于它能发现至今未发现的错误
（2） 优点：
l 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率
l 测试用例的使用令软件测试的实施重点突出、目的明确
l 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期
l 功能模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升
2．计划测试用例的目的
（3） 计划测试用例，是达成测试目标的必由之路
（4） 组织性：使测试用例具有组织性，便于全体测试员和其他项目小组人员有效地审查和使用
（5） 重复性和跟踪，可以明确测试过程中测试用例的执行情况，保证测试的全面性
（6） 计划测试用例，可以避免发布忽略某些测试用例的软件
（7） 测试证实，正确的测试用例计划和跟踪提供了一种证实测试的手段
3．测试设计说明
（1） 定义：在测试计划中提炼测试方法，要明确指出设计包含的特性以及相关的测试用例和测试程序，并指定判断通过/失败的规则
（2） 目的；组织和描述针对具体特性需要进行的测试，注：不给出具体的测试用例或执行测试的步骤
（3） 包含的部分内容（来自ANSI/IEEE829 ANSI 美国国家标准化组织）
l 标识符：用于引用和定位测试设计说明的惟一标识符
l 要测试的特性：对测试设计说明所包含的软件特性的描述。还将明确出要间接测试的特性
l 方法：描述测试的通用方法。如果方法在测试计划中描述，在测试设计说明中要详细描述要使用的技术，并给出如何验证测试结果的方法
l 测试用例信息：用于描述所引用的测试用例的相关信息。如测试用例编号
l 通过/失败规则：描述用什么规则来判定某项特性的测试结果是通过还是失败。
4．测试用例说明
（1） 定义（ANSI/IEEE829）：编写用于输入的实际数据和预期结果，并明确指出使用具体测试用例产生的测试程序的任何限制
（2） 包含的内容
l 标识符：由测试设计过程说明和测试程序说明引用的唯一标识符
l 测试项：描述被测试的详细特性、代码模块等
l 输入说明：列举执行测试用例的所有输入内容或者条件
l 输出说明：描述进行测试用例预期的结果
l 环境要求：执行测试用例的软件、硬件、测试工具及人员等要求
l 特殊要求：描述执行测试用例的特殊要求
l 用例之间的依赖性：注明与其分用例的依赖关系或受其他用例的影响
5. 测试程序说明
（1） 定义：明确指出为实现相关测试设计而执行具体测试用例和操作软件系统的全部步骤，有时也称为‘测试脚本说明’，即详细定义了执行测试用例的每一步操作
（2） 包含的内容
l 标识符：把测试程序与相关测试用例和测试设计相联系的惟一标识
l 目的：本程序描述的目的以及将要执行的测试用例的引用信息
l 特殊要求：执行测试所需的其他程、特殊测试技术或者特殊设备
l 程序步骤：执行测试用例的详细描述，包括
v 日志：指出记录测试结果和现象的方式
v 设置：如何准备测试
v 启动：启动测试的步骤
v 程序：运行测试的步骤
v 衡量标准：描述如何判断结果
v 关闭：描述因意外原因页推迟测试的步骤
v 终止：描述正常停止测试的步骤
v 重置：说明如何把环境恢复到测试前的状态
v 偶然事件：说明如何处理计划之外的情况
