关于软件测试的一些基本知识

软件测试方法：分为两类
（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．词法和语法分析
（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条件，每个条件对于判定的结果值是独立的

练习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），则需要改变复合条件的判断为一系列只有单个条件的嵌套的判断
图形符号图所示

（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 生成测试用例，确保基本路径集中每条路径的执行

五．其他白盒测试方法
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）列出等价类表
在确定了等价类之后，建立等价类表，列出所有划分出的等价类
输入条件有效等价类无效等类
…… …… ……

（5）确定测试用例步骤
l 第一步：为每个等价类规定一个惟一的编号
l 第二步：设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
l 第三步：设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步骤，最后使得所有有效等价类均被测试用例所覆盖
小结：采用等价类划分方法设计测试用例，按照划分等价类、列出等价列表、确定测试用例三个步骤完成，目标是把可能的测试用例组合缩减到仍然足以满足软件测试需求为止。

2．边界值分析法
（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页，大于允许最大页数

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 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要

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．采用因果图方法设计测试用例
某个软件的规格说明中包含下面的要求：
第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L，如果第二列字符不是数据，则给出信息

软件测试基本内容（转贴）

第 1 帖【 2004 － 5 － 10 】：软件测试的理想模式是什么？

Brian Marick ：我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效，而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组，他们不可能有时间把所有测试都做好。所以，最佳的方式是让开发人员承担一定量的测试，独立测试组给予他们支持。独立测试组主要承担整个系统的测试，去寻找开发人员还没有发现的缺陷，如子系统间的交互、运行条件、内存使用等。

如何更有效地开展系统测试呢？让测试人员在项目初期就参与进去，让他们看到第一版的系统需求、用户手册和系统原型，在系统实现前就对需求进行捕获和跟踪。在该过程中，他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行，并且在该过程中会发现一些缺陷。大家都知道，这个阶段，问题发现是非常 “ 便宜 ” 的。

这样，系统测试工程师在项目早期就介入，产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计，因为书写完整测试的条件还不成熟，但这却是构建完整测试的基础。

注： Brian Marick 是 Reliability Software 公司的专职测试技术顾问。

第 2 帖【 2004 － 5 － 11 】：测试经理角色定位

Johanna Rothman ：测试经理服务于两种完全不同的客户：测试工程师和高层管理者。对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。

产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，就可以通过测试去验证产品在多大程度上满足了客户需求。

对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责。

高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量。

第 3 贴【 2004 － 5 － 12 】：测试的基本原则

（美） Roger S. Pressman
在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：
1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。

第 4 贴【 2004 － 5 － 13 】：什么是 “ 好 ” 的测试？

什么是 “ 好 ” 的测试？ Kaner ， Falk & Nguyen
1 、一个好的测试发现错误的可能性很高
为了达到这个目标，测试者必需理解软件、并尝试设想软件如何才能失败，例如：在 GUI （图形用户界面）中有一种潜在的错误，即错误识别鼠标位置，那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。
2 、一个好的测试并不冗余
测试的时间和资源是有限的，没有必要构造一个与其他测试用例完全相同的测试，每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如，软件 SafeHome 中有一个模块被用来识别用户密码以决定是否启动系统，为了测试密码输入的错误，测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码（ 4 个数字），然而，每一个有效 / 无效密码将只检测一种不同错误模式，例如一个将 8080 作为有效密码的系统将不会接受非法密码 1234 ，如果接受 1234 ，将产生错误，另一个测试输入 1235 ，与 1234 的测试意图相同，因此是冗余的，然而，非法输入 8081 或 8180 就有些细微的差异，即对与有效密码相近但并不相同的密码应该进行测试。
3 、一个好的测试应该是 “ 最佳品种 ”
在一组目的相似的测试中，时间和资源的限制可能只影响其某个子集的执行，此时，应该使用最可能找到所有错误的测试。
4 、一个好的测试既不会太简单，也不会太复杂
虽然有时会将一组测试组合到一个测试用例中，其副作用可能屏蔽错误，通常每一个测试应该独立执行。

第 5 贴【 2004 － 5 － 14 】：软件可测试性

Roger S. Pressman
理想情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性，这就使得测试工程师能够更容易地设计有效的测试用例。

什么是 “ 可测试性 ” ？软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。 James Bach 这样描述可测试性：软件可测试性就是一个计算机程序能够被测试的容易程度。

以下是一个常见的软件可测试性检查表：
· 可操作性－ “ 运行地越好，被测试的效率越高。 ”
· 可观察性－ “ 所看见的，就是所测试的。 ”
· 可控制性－ “ 对软件的控制越好，测试越能够被自动执行与优化。 ”
· 可分解性－ “ 通过控制测试范围，能够更好地分解问题，执行更灵巧的再测试。 ”
· 简单性－ “ 需要测试的内容越少，测试的速度越快。 ”
· 稳定性－ “ 改变越少，对测试的破坏越小。 ”
· 易理解性－ “ 得到的信息越多，进行的测试越灵巧。 ”

第 6 贴【 2004 － 5 － 15 】：实时系统测试

Roger S. Pressman

很多实时系统的时间依赖性和异步性给测试带来新的困难－－时间！测试用例的设计者考虑的不仅是白盒和黑盒测试用例，而且包括事件处理（如中断处理）、数据的时间序列以及处理数据的任务（进程）的并发性。很多情况下，提供的测试数据有时使得实时系统在某状态下可以正常运行，而同样的数据在系统处于不同状态时有时又会导致错误。

另外，实时系统的软件和硬件之间的密切关系也会导致测试问题，软件测试必须考虑硬件故障对软件处理的影响，这种故障很难实时仿真。由于实时系统的特殊性和复杂性，还没有一个完善的综合性的测试用例设计方法，但是，大致可以分为以下四个步骤：

1 、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例，并在测试时执行每个任务。任务测试能够发现逻辑和功能错误，但是不能发现时间和行为错误。

2 、行为测试。利用 CASE 工具创建软件模型，就可能仿真实时系统，并按照外部事件的序列检查其行为，这些分析活动可作为创建实时系统时设计测试用例的基础。

3 、任务间测试。在隔离了任务内部和系统行为错误以后，测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务，看任务间的同步是否会产生错误。另外，测试通过消息队列和数据存储进行通讯的任务，以发现这些数据存储区区域大小方面的错误。

4 、系统测试。集成软件和硬件，并进行大范围的系统测试，以发现软件 / 硬件口间的错误。

第 7 贴【 2004 － 5 － 16 】：单元测试、集成测试、系统测试、验收测试、回归测试

Software Research
单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “ 先知者问题 ” 。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。

验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。

2005-1-20 12:35:01   鲜花(1) 鸡蛋(0)

tester2005

等级：论坛游侠
文章：283
积分：841
注册：2004-12-23
        第2楼

第 8 贴【 2004 － 5 － 17 】：软件测试策略

Roger S. Pressman
测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－我们可以把特定的测试用例方法放置进去的一系列步骤。

人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中。
· 不同的测试技术适用于不同的时间点。
· 测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。

软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。

第 9 贴【 2004 － 5 － 18 】：白盒测试

Rex Black
白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
1 ）保证一个模块中的所有独立路径至少被使用一次；
2 ）对所有逻辑值均需测试 true 和 false ；
3 ）在上下边界及可操作范围内运行所有循环；
4 ）检查内部数据结构以确保其有效性。

“ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？ ” 答案在于软件自身的缺陷：
1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ” 的处理则难于发现。
2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。
3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。

正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” ，而白盒测试更可能发现它。

第 10 贴【 2004 － 5 － 19 】：黑盒测试

黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误：
1 ）功能错误或遗漏；
2 ）界面错误；
3 ）数据结构或外部数据库访问错误；
4 ）性能错误；
5 ）初始化和终止错误。

白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：
1 ）如何测试功能的有效性？
2 ）何种类型的输入会产生好的测试用例？
3 ）系统是否对特定的输入值尤其敏感？
4 ）如何分隔数据类的边界？
5 ）系统能够承受何种数据率和数据量？
6 ）特定类型的数据组合会对系统产生何种影响？

运用黑盒测试方法，可以导出满足以下标准的测试用例集：
1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
2 ）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。

第 11 贴【 2004 － 5 － 20 】：软件测试充分性准则

（ 1 ）空测试对任何软件都是不充分的。
（ 2 ）对任何软件都存在有限的充分测试集合。
（ 3 ）如果一个软件系统在一个测试数据集合上的测试是充分的，那么再多测试一些数据也应该是充分的。这一特性称为单调性。
（ 4 ）即使对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。
（ 5 ）即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。
（ 6 ）软件测试的充分性应该与软件的需求和软件的实现都相关。
（ 7 ）软件越复杂，需要的测试数据就越多。这一特性称为复杂性。
（ 8 ）测试得越多，进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。

第 12 贴【 2004 － 5 － 21 】：静态测试

在软件开发过程中，每产生一个文档，都必须对它进行测试，以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的，也与项目管理过程相一致。每当一个文档通过了静态测试，就标志着一项开发工作的总结，标志着项目取得了一定的进展，进入了一个新的阶段。

静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以用于对各种软件文档进行测试，是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段，由于可运行的代码尚未产生，不可能进行动态测试，而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小，因此，在这些阶段，静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上，人们总结出了一些行之有效的静态测试技术和方法，如结构化走通、正规检视等等。这些方法和测试技术可以与软件质量的定量度量技术相结合，对软件开发过程进行监视、控制，从而保障软件质量。

第 13 贴【 2004 － 5 － 22 】：什么是测试需求？

Brian Marick
测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。

在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。

测试的下一步是选择满足这些测试需求的输入值 / 测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。

这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：
1 ）插入一个新的条目
2 ）插入失败－条目已经存在
3 ）插入失败－表已满
4 ）哈希表在插入前为空
这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。

第 14 贴【 2004 － 5 － 30 】： GUI 测试

Roger S. Pressman

图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南：

窗口：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动？
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新调用后，窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能？
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
· 显示多个窗口时，窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮？
· 如果使用多任务，是否所有的窗口被实时更新？
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
· 窗口是否正确地被关闭？

下拉式菜单和鼠标操作：
· 菜单条是否显示在合适的语境中？
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗？
· 菜单、调色板和工具条是否工作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能？
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确？
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰？
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性？
· 菜单项是否有帮助，是否语境相关？
· 在整个交互式语境中，是否可以识别鼠标操作？
· 如果要求多次点击鼠标，是否能够在语境中正确识别？
· 光标、处理指示器和识别指针是否随操作恰当地改变？

数据项：
· 字母数字数据项是否能够正确回显，并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作？
· 是否能够识别非法数据？
· 数据输入消息是否可理解？

第 15 贴【 2004 － 5 － 31 】： Client/Server 测试

Roger S. Pressman

通常，客户 / 服务器软件的测试发生在三个不同的层次：
（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行；
（ 2 ）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；
（ 3 ）完整的 C/S 体系结构，包括网络运行和性能，被测试。

下面的测试方法是 C/S 应用中经常用到的：
应用功能测试 —— 客户端应用被独立地执行，以揭示在其运行中的错误。
服务器测试 —— 测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。
数据库测试 —— 测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。
事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。
网络通信测试 —— 这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。

2005-1-20 12:35:14

tester2005

等级：论坛游侠
文章：283
积分：841
注册：2004-12-23
        第3楼

第 16 贴【 2004 － 6 － 1 】：软件质量

“ 每一个程序都能正确地做某件事，但是这并不是我们想要它作的事情。 ” 这样的软件不能算一个质量好的软件。

我们如何定义软件质量呢？可以从不同的角度来看待软件质量并对其定义，它们有一些共同点：强调软件与得到了清晰描述的功能和性能需求的符合度、明显的文档标准以及被认为是所有专业开发的软件所具备的隐式特征。

ISO9126 从如下几个方面来衡量软件质量：功能性、可靠性、可用性、可维护性、效率、可移植性。

如下三个方面应该尤其被重视：
1 、软件需求是质量测度的基础。需求符合性的缺乏也就是缺乏质量；
2 、特定的过程定义了一套开发标准，用以指导软件开发的方式。如果标准未能遵守，那么缺少质量就几乎是肯定的结论；
3 、除了功能需求等显示的需求外，要对非功能的隐式需求重视（例如，对好的可维护性的期望）。如果软件符合其他显式的需求，但是未能满足隐式需求，软件质量仍然是值得怀疑的。

软件质量是一个多因素的复杂混合，这些因素随着不同的应用和需要它们的用户而变化。测试时需要根据一定的质量标准有针对性的进行测试。

第 17 贴【 2004 － 6 － 2 】系统测试方法之恢复测试

Roger S. Pressman

许多基于计算机的系统必须在一定的时间内从错误中恢复过来，然后继续运行。在有些情况下，一个系统必须是可以容错的，这就是说，运行过程中的错误不能使整个系统的功能都停止。在其他情况下，一个系统错误必须在一个特定的时间段之内改正，否则就会造成严重损失。

恢复测试是通过各种手段，让软件强制性地发生故障，然后来验证恢复是否能正常进行的一种系统测试方法。如果恢复是自动的（由系统本身来进行的），重新初始化、检查点机制、数据恢复和重启动都要进行正确验证。如果恢复是需要人工干预的，那么要估算修复的平均时间是否在可以接受的范围之内。

第 18 贴【 2004 － 6 － 3 】：系统测试方法之安全测试

Roger S. Pressman

任何管理敏感信息或者能够对个人造成不正当伤害的计算机系统都是不正当或非法侵入的目标。侵入包括了范围很广的活动：只是为练习而试图侵入系统的黑客；为了报复而试图攻破系统的有怨言的雇员；还有为了得到非法的利益而试图侵入系统的不诚实的个人。

安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。引用 Beizer 的话来说： “ 系统的安全当然必须能够经受住正面的攻击 —— 但是它也必须能够经受住侧面的和背后的攻击。 ”

在安全测试过程中，测试者扮演着一个试图攻击系统的个人角色。测试者可以尝试去通过外部的手段来获取系统的密码，可以使用可以瓦解任何防守的客户软件来攻击系统；可以把系统 “ 制服 ” ，使得别人无法访问；可以有目的地引发系统错误，期望在系统恢复过程中侵入系统；可以通过浏览非保密的数据，从中找到进入系统的钥匙；等等。

只要有足够的时间和资源，好的安全测试就一定能够最终侵入一个系统。系统设计者的任务就是要把系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息的价值。

第 19 贴【 2004 － 6 － 4 】：系统测试方法之压力测试

Roger S. Pressman

在较早的软件测试步骤中，白盒和黑盒技术对正常的程序功能和性能进行了详尽的检查。压力测试（ Stree Testing ）的目的是要对付非正常的情形。在本质上说，进行压力测试的人应该这样问： “ 我们能够将系统折腾到什么程度而又不会出错？ ”

压力测试是在一种需要反常数量、频率或资源的方式下运行系统。例如，
（ 1 ）当平均每秒出现 1 个或 2 个中断的情形下，应当对每秒出现 10 个中断的情形来进行特殊的测试；
（ 2 ）把输入数据的量提高一个数量级来测试输入功能会如何响应；
（ 3 ）应当执行需要最大的内存或其他资源的测试用例；
（ 4 ）运行一个虚拟的操作系统中可能会引起大量的驻留磁盘数据的测试用例。
从本质上来说，测试者是想要破坏程序。

压力测试的一个变种是一种被成为是敏感测试的技术。在有些情况（最常见的是在数学算法中）下，在有效数据界限之内的一个很小范围的数据可能会引起极端的甚至是错误的运行，或者引起性能的急剧下降，这种情形和数学函数中的奇点相类似。敏感测试就是要发现在有效数据输入里可能会引发不稳定或者错误处理的数据组合。

第 20 贴【 2004 － 6 － 5 】：系统测试方法之性能测试

Roger S. Pressman

在实时系统和嵌入式系统中，提供符合功能需求但不符合性能需求的软件是不能被接受的。性能测试就是用来测试软件在系统中的运行性能的。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的真正性能。

性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要的在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。外部的测试设备可以监测测试执行，当出现情况（如中断）时记录下来。通过对系统的检测，测试者可以发现导致效率降低和系统故障的原因。

第 21 贴【 2004 － 6 － 6 】：回归测试

Roger S. Pressman

每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的 I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预的副作用。

在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。

回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
· 能够测试软件的所有功能的代表性测试用例。
· 专门针对可能会被修改影响的软件功能的附加测试。
· 针对修改过的软件成分的测试。

在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。

第 22 贴【 2004 － 6 － 7 】：测试与调试

测试的目的是显示存在错误，而调试的目的是发现错误或导致程序失效的错误原因，并修改程序以修正错误。调试是测试之后的活动。 [Beizer, 1984] 认为，测试和调试在目标、方法和思路上都有所不同，如下：

1 、测试从一个已知的条件开始，使用预先定义的过程，有预知的结果。调试从一个未知的条件开始，结束的过程不可预计。

2 、测试过程可以实现设计，进度可实现确定。调试不能描述过程或持续时间。

3 、测试是显示错误的行为。调试是推理的过程。

4 、测试显示开发人员的错误。调试是开发人员为自己辩护。

5 、测试能预期和可控。调试需要想象，经验和思考。

6 、测试能在没有详细设计的情况下完成。没有详细设计的信息调试不可能进行。

7 、测试能由非开发人员进行。调试必须由开发人员进行。

第 23 贴【 2004 － 6 － 8 】：系统测试方法之功能测试

功能测试又称正确性测试，它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素，所以其测试也最重要。

基本的方法是构造一些合理输入，检查是否得到期望的输出。这是一种枚举方法。测试人员一定要设法减少枚举的次数，否则测试投入太大。关键在于寻找等价区间，因为在等价区间中，只需用任意值测试一次即可。等价区间的概念可表述如下：记（ A ， B ）是命题 f(x) 的一个等价区间，在（ A ， B ）中任意取 x1 进行测试。如果 f (x1) 错误，那么 f (x) 在整个（ A ， B ）区间都将出错。如果 f (x1) 正确，那么 f (x) 在整个（ A ， B ）区间都将正确。上述测试方法称为等价测试，来源于人们的直觉与经验，可令测试事半功倍。

还有一种有效的测试方法是边界值测试。即采用定义域或者等价区间的边界值进行测试。因为程序员容易疏忽边界情况，程序也 “ 喜欢 ” 在边界值处出错。例如测试平方根函数的一段程序。凭直觉输入等价区间应是（ 0 ， 1 ）和（ 1 ， +∞ ）。可取 x=0 。 5 以及 x=2 。 0 进行等价测试。再取 x=0 以及 x=1 进行边界值测试。

有一些复杂的程序，我们难以凭直觉与经验找到等价区间和边界值，这时枚举测试就相当有难度。

第 24 贴【 2004 － 6 － 9 】：黑盒测试的端口测试模型

端口测试模型侧重于对被测对象的抽象，它阐明的是我们要测试什么。它将被测试者间的共性抽象出来，使测试者和被测者可以最大程度地分离开来。其主要思想是：被测试者可以用测试端口集来表达。测试功能体现在测试端口对外协议（称为端口协议）的实现，对不同系统的测试或对同一系统中不同子系统的测试都表现为对不同端口的测试。端口协议一般是非确定的有限自动机（ NFA) ，它可以分解成确定的有限自动机（ DFA) 的集合（对应于功能迁移路径集），并可以用结构化语言描述在测试用例中。这样，端口协议的差异就不会影响测试者的内部实现（与被测者的接口除外）。

第 25 贴【 2004 － 6 － 10 】：黑盒测试的对象测试模型

对象测试模型注重于测试内容的表达，它阐明的是如何表达我们的测试内容。它把分散的功能测试单元有机地组合起来，使实际测试更逼近真正的系统测试。其主要思想是：测试内容及测试的实现方法（指对测试数据的处理）可以被封装在一个个的测试对象中。测试对象有三个层次：数据对象、业务对象和事务对象，它们的关系是逐级被包含。简单来说，数据对象是指业务（或功能）数据的载体，它通常有物理对应，其主要测试内容是一个状态迁移图；业务对象指共同实现一种业务（或功能）的数据对象集合，它一般都只有逻辑对应，其主要测试内容是一个时间追踪图；事务对象是指一组业务相关的业务对象的有序组合，其主要测试内容是业务间的关系图，准确地说是业务结果间的布尔关系图。

第 26 贴【 2004 － 6 － 11 】：黑盒测试的分层设计模型

分层设计模型侧重于黑盒自动测试工具的实现，它阐明的是我们如何设计测试工具。它将测试工具的功能进行抽象和分层，使测试工具的积木化开发现实可行。其主要思想是：测试工具可划分为五个不同的层次，从低到高依次是：端口驱动层、测试执行层、测试表达层、测试管理层、测试设计层。通过规范这五个层次间的接口，可以使按照这个设计模型设计的测试工具或提供相同的接口的其它测试工具无缝地集成在一起，从而实现理想的积木式开发。

第 27 贴【 2004 － 6 － 12 】： QA 的职责

QA 到底应该在企业里起什么作用呢？下面是 QA 职责的总结：

1 、保障软件组织流程体系得到遵守；
2 、促使软件组织过程改进；
3 、指导项目实施流程，；
4 、增加开发活动透明度；
5 、评审项目活动；
6 、审核工作产品；
7 、协助工作产品问题解决；
8 、度量数据采集、分析，提供决策参考；
9 、进行缺陷预防；
10 、实现质量目标。

第 28 贴【 2004 － 6 － 13 】：软件走读

软件走读的目的是为了对软件产品进行评价，软件走读也可以是为给参与走读的人员培训有关软件产品知识而举行，软件走读的主要目的是：
1 ）发现软件产品中的软件异常，缺陷、遗漏和自相矛盾的地方，以改进产品并提出可供选择的实现方案；
2 ）改进软件产品；
3 ）考虑可选项方案的实现方法；
4 ）评价与标准和规格的符合性；
5 ）进行技术交流，人员培训。

在软件走读中可以指出各种缺陷，例如软件产品中的效率和可读性问题，设计或编码中模块化问题，或者规格书中的可测试问题等等。

要求进行软件走读的软件产品，包括但不限于：
1 ）软件需求规格，
2 ）软件设计文档，
3 ）源代码，
4 ）软件测试文档，
5 ）软件用户文档，
6 ）维护手册，
7 ）安装过程

第 29 贴【 2004 － 6 － 14 】： TCL 简介

TCL 是一脚本解释器，具有基本的语言特性，支持整型和字符串变量，支持循环等控制结构；同时它具有灵活的扩展性和跨平台的特性，后者是它最主要的特性。通过 TCL 脚本可以编写测试用例，通过扩展功能，可以扩展你想要的测试动作。最终目的是将测试的自动化和灵活性（可扩展性）结合在一起。

     TCL 提供以下接口：
     1 、用户接口
      对用户提供语言特性，如循环、条件判断等控制结构，通过它用户可以灵活的书写测试用例；当然只提供语言特性远远不够，因为业务千差万别，所以用户需要业务接口，从而完成特定的测试任务。而业务接口，是通过下面的程序员接口实现。
      2 、程序员接口
       用户可以编写自己命令，它包括用户层（即名字）和实现层（通过 C 语言实现），然后用 TCL 提供的注册函数登记，以后命令就可灵活的嵌入到脚本中了。

      TCL 测试模型分三部分：
       被测试程序（由开发人员编写） ---- 测试人员应搞清楚程序结构和业务功能，指导扩展命令的设计。
       测试代码（由测试设计人员编写）   --- 通过程序员接口，提供给脚本扩展命令。
       测试用例（ TCL 脚本形式，由测试执行人员编写） --- 通过脚本对扩展命令进一步组合。

第 30 贴【 2004 － 6 － 15 】： CMM 的五级简介

CMM 为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级只是一个起点，任何准备按 CMM 体系进化的企业都自然处于这个起点上，并通过它向第二级迈进。除第一级外，每一级都设定了一组目标，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一级别迈进。
第一级、初始级：
      初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。
第二级、重复级：
      根据多年的经验和教训，人们总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
第三级、义级：
       在可重复级定义了管理的基本过程，而没有定义执行的步骤标准。在第三级则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。
第四级、管理级：
       第四级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。
第五级、优化级：
      优化级的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

2005-1-20 12:35:49

tester2005

等级：论坛游侠
文章：283
积分：841
注册：2004-12-23
        第4楼

第 31 贴【 2004 － 6 － 16 】： CMM 2 级 KPA 的目标

CMM 2 级：可重复级
        Requirement Management
        需求管理
        Goal 1 System requiremnets allocated to software are controlled to establish a baseline for software engineering and management use.
        目标 1 ：分配到软件部分的系统需求通过建立基线受控。
        Goal 2   Software plans, products, and activities are kept consistent with the system requirements allocated to software.
        目标 2 ：软件计划、产品和活动与分配到软件部分的系统需求一致。

        Software Project Planning
        软件项目计划
        Goal 1   Software estimates are documented for use in planning and tracking the software project.
        目标 1 ：用来计划和跟踪软件项目的软件估计文档化。
        Goal 2   Software project activities and commitments are planned and documented.
        目标 2 ：制定了软件项目活动和任务书的计划，并且有文档记录。
        Goal 3   Affected groups and individuals agree to their commitments related to the software project.
        目标 3 ：受影响的小组和个人接受和软件项目相关的任务书。

        Software Project Tracking and Oversight
        软件项目跟踪及监控
        Goal 1 Actual results and performances are tracked against the software plans.
        目标 1 ：按照软件计划跟踪实际结果和性能。
        Goal 2 Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans.
        目标 2 ：当实际的结果和性能严重偏离软件计划时，采取了正确的行动终止这种状况。
        Goal 3 Changes to sofware commitments are agreed to by the affected groups and individuals.
        目标 3 ：受影响的小组和个人接受软件任务书的变化。

        Software Subcontract Management
        软件子合同管理
        Goal 1 The prime contractor selects qualified software subcontractors.
        目标 1 ：主签约人挑选有资格的子签约人。
        Goal 2 The prime contractor and the software subcontractor agree to their commitments to each other.
        目标 2 ：主签约人和子签约人互相接受他们的任务书。
        Goal 3 The prime contractor and the software subcontractor maintain ongoing communications.
        目标 3 ：主签约人和子签约人保持持续的沟通。
        Goal 4 The prime contractor tracks the software subcontractor's actual results and performance against its commitments.
        目标 4 ：主签约人按照任务书跟踪子签约人的实际结果和效能。

        Software Quality Assurance
        软件质量保证
        Goal 1 Software quality assurance activities are planned.
        目标 1 ：制定了软件质量保证计划。
        Goal 2 Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively.
        目标 2 ：客观地检验软件产品和活动是否符合适用的标准、过程和需求。
        Goal 3 Affected groups and individuals are informed of software quality assurance activities and results.
        目标 3 ：软件质量保证的活动和结果通知了受影响的小组和个人。
        Goal 4 Noncompliance issues that cannot be resolved within the software project are addressed by senior management.
        目标 4 ：高层管理着手解决在软件项目内部不能解决的不符合项。

        Software Configuration Management
        软件配置管理
        Goal 1 Software configuration management activities are planned.
        目标 1 ：制定了软件配置管理活动的计划。
        Goal 2 Selected software work products are identified, controlled, and available.
        目标 2 ：选定的软件工作产品是被标识的、受控的和可利用的。
        Goal 3 Changes to identified software work products are controlled.
        目标 3 ：被标识的软件工作产品的变化是受控的。
        Goal 4 Affected groups and individuals are informed of the status and content of software baselines.
        目标 4 ：软件基线的状态和内容通知受影响的小组和个人。

第 32 贴【 2004 － 6 － 17 】： Logiscope 的功能

LOGISCOPE 是为软件的全面质量控制而开发的强大工具，可以用在编程、测试和维护阶段。 LOGISCOPE 五个模块的功能：
(1) 阅读器 (Viewer) ：以文件调用图 ( 各部件文件之间的关系 ) 及组件调用图 ( 函数和程序间的调用关系 ) 的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序，在不同级别上的引导有助于整个应用程序的理解。
(2) 效果检查器 (ImpactChecker) ：允许用户检查使用的资源 ( 文件、函数、用户定义类型、全局变量、结构成员常量 ) 。它有助于我们理解函数间的信息流 ( 参数传递 ) ，以及数据和其它应用程序资源间的关系。
(3) 规则检查器 (RuleChecker) ：软件公司应定义自己的编程规则和质量目标。这样做的好处是公司编程行为保持一致性、易于维护、提高可靠性、易于移植到其它机器上。我们可以用规则检查器 (RuleChecker) 确立编程标准，保证质量控制。
(4) 测试检查器 (TestChecker) ：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器 (TestChecker) 和动态分析器 (Dynamic Analyzer) 通过阅读器产生用于应用程序分析的数据。
(5) 代码检查器 (CodeChecker) ：验证应用程序与质量模型的一致性。代码检查器和静态分析器 (Static Analyzer) 通过阅读器 (Viewer) 产生用于应用程序分析的数据。代码检查器 (CodeChecker) 可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。

第 33 贴【 2004 － 6 － 18 】： α 测试

α 测试是由一个用户在开发环境下进行的测试，也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试， α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 。尤其注重产品的界面和特色。 α 测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。 α 测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。

第 34 贴【 2004 － 6 － 19 】： β 测试

β 测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与 α 测试不同的是，开发者通常不在测试现场。因而， β 测试是在开发者无法控制的环境下进行的软件现场应用。在 β 测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。 β 测试主要衡量产品的 FLURPS 。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当 α 测试达到一定的可靠程度时，才能开始 β 测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。
由于 β 测试的主要目标是测试可支持性，所以 β 测试应尽可能由主持产品发行的人员来管理。

第 35 贴【 2004 － 6 － 20 】：面向对象的集成测试

　　传统的集成测试，是通过各种集成策略集成各功能模块进行测试，一般可以在部分程序编译完成的情况下进行。而对于面向对象程序，相互调用的功能是散布在程序的不同类中，类通过消息相互作用申请和提供服务。类的行为与它的状态密切相关，状态不仅仅是体现在类数据成员的值，也许还包括其他类中的状态信息。由此可见，类相互依赖极其紧密，根本无法在编译不完全的程序上对类进行测试。所以，面向对象的集成测试通常需要在整个程序编译完成后进行。此外，面向对象程序具有动态特性，程序的控制流往往无法确定，因此也只能对整个编译后的程序做基于黑盒子的集成测试。
　　面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。基于单元测试对成员函数行为正确性的保证，集成测试只关注于系统的结构和内部的相互作用。面向对象的集成测试可以分成两步进行：先进行静态测试，再进行动态测试。
　　静态测试主要针对程序的结构进行，检测程序结构是否符合设计要求。现在流行的一些测试软件都能提供一种称为 " 可逆性工程 " 的功能，即通过原程序得到类关系图和函数功能调用关系图，例如 International Software Automation 公司的 Panorama-2 、 Rational 公司的 Rose C++ Analyzer 等，将 " 可逆性工程 " 得到的结果与 OOD 的结果相比较，检测程序结构和实现上是否有缺陷。换句话说，通过这种方法检测 OOP 是否达到了设计要求。
　　动态测试设计测试用例时，通常需要上述的功能调用结构图、类关系图或者实体关系图为参考，确定不需要被重复测试的部分，从而优化测试用例，减少测试工作量，使得进行的测试能够达到一定覆盖标准。测试所要达到的覆盖标准可以是：达到类所有的服务要求或服务提供的一定覆盖率；依据类间传递的消息，达到对所有执行线程的一定覆盖率；达到类的所有状态的一定覆盖率等。同时也可以考虑使用现有的一些测试工具来得到程序代码执行的覆盖率。
　　具体设计测试用例，可参考下列步骤：
1. 先选定检测的类，参考 OOD 分析结果，仔细出类的状态和相应的行为，类或成员函数间传递的消息，输入或输出的界定等。
2. 确定覆盖标准。
3. 利用结构关系图确定待测类的所有关联。
4. 根据程序中类的对象构造测试用例，确认使用什么输入激发类的状态、使用类的服务和期望产生什么行为等。
　　值得注意，设计测试用例时，不但要设计确认类功能满足的输入，还应该有意识的设计一些被禁止的例子，确认类是否有不合法的行为产生，如发送与类状态不相适应的消息，要求不相适应的服务等。根据具体情况，动态的集成测试，有时也可以通过系统测试完成。

第 36 贴【 2004 － 6 － 21 】：面向对象的系统测试

通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试。换个角度说，开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作。　　
系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考 OOA 分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全 " 再现 " 问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。
　　这里说的系统测试是对测试步骤的抽象描述。它体现的具体测试内容包括：
· 功能测试：测试是否满足开发要求，是否能够提供设计所描述的功能，是否用户的需求都得到满足。功能测试是系统测试最常用和必须的测试，通常还会以正式的软件说明书为测试标准。
· 强度测试：测试系统的能力最高实际限度，即软件在一些超负荷的情况，功能实现情况。如要求软件某一行为的大量重复、输入大量的数据或大数值数据、对数据库大量复杂的查询等。
· 性能测试：测试软件的运行性能。这种测试常常与强度测试结合进行，需要事先对被测软件提出性能指标，如传输连接的最长时限、传输的错误率、计算的精度、记录的精度、响应的时限和恢复时限等。
· 安全测试：验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。安全测试时需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。
· 恢复测试：采用人工的干扰使软件出错，中断使用，检测系统的恢复能力，特别是通讯系统。恢复测试时，应该参考性能测试的相关测试指标。
· 可用性测试：测试用户是否能够满意使用。具体体现为操作是否方便，用户界面是否友好等。
· 安装 / 卸载测试（ install/uninstall test ）等等。
　　系统测试需要对被测的软件结合需求分析做仔细的测试分析，建立测试用例。

第 37 贴【 2004 － 6 － 22 】： TMM 介绍

测试是软件开发的重要过程之一，但是 CMM 没有充分的定义测试，没有提及测试成熟度的概念，没有对测试过程改进进行充分说明，在 KPA 中没有定义测试问题，与质量相关的测试问题如可测性，充分测试标准，测试计划等方面也没有满意的阐述。

TMM 是受 CMM 模型启发产生的，关注于测试的成熟度模型。它描述了测试过程，是项目测试部分得到良好计划和控制的基础。 TMM 测试成熟度分解为 5 级别，关注于 5 个成熟度级别递增：

    Phase 0 ：测试和调试没有区别，初了支持调试外，测试没有其他目的
    Phase 1 ：测试的目的是为了表明软件能够工作
    Phase 2 ：测试的目的是为了表明软件不能够能够正常工作
    Phase 3 ：测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度
    Phase 4 ：测试不是行为，而是一种自觉的约束 (mental discipline) ，不用太多的测试投入产生低风险的软件上的

第 38 贴【 2004 － 6 － 23 】：软件测试自动化的概念

软件测试自动化，是一项让计算机代替测试人员进行软件测试的技术。他可以让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。如果采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现 “ 夜间测试 ” 和 “ 无人测试 ” 。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。

软件测试自动化通常借助测试工具进行。测试工具可以进行部分的测试设计、实现、执行和比较的工作。通过运用测试工具，可以达到提高测试效率的目的。所以测试工具的选择和推广使用应该给予重视。部分的测试工具可以实现测试用例的自动生成，但通常的工作方式为人工设计测试用例，使用工具进行用例的执行和比较。

软件测试自动化的设并不能由工具来完成，必须由测试人员进行手工设计，但是在设计是却必须考虑自动化的特殊要求，否则无法实现利用工具进行用例的自动执行。为此，就必须在测试的设计和内容的组织方面采取一些特殊的方法。

对于软件测试自动化的工作，大多数人都认为是一件非常容易的事。其实，软件测试自动化的工作量非常大，而且也并不是在任何情况下都适用，同时软件测试自动化的设计并不比程序设计简单

第 39 贴【 2004 － 6 － 24 】：自动化测试的优点

通过自动化测试，可以使某些任务提高执行效率。除此之外，还有其它优点：

① 对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。

② 可以运行更多更繁琐的测试。自动化的一个明显的好处是可以在较少的时间内运行更多的测试。

③ 可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。

④ 更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。

⑤ 测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。

⑥ 测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。

⑦ 可以让产品更快面向市场。自动化测试可以缩短测试时间，加快产品开发周期。

⑧ 增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。

总之，通过较少的开销获得更彻底的测试，提高软件质量，这是测试自动化的最终目的。

2005-1-20 12:36:37

tester2005

等级：论坛游侠
文章：283
积分：841
注册：2004-12-23
        第5楼

第 40 贴［ 2004-6-25 ］：自动化测试中常见的问题

在软件测试自动化的实施过程中会遇到许多问题，以下是一些比较普遍的问题：

① 不现实的期望。一般来说，业界对于任何新技术的解决方案都深信不疑，认为可以解决面临的所有问题，对于测试工具也不例外。但事实上，如果期望不现实，无论测试工具如何，都满足不了期望。

② 缺乏测试实践经验。如果缺乏测试的实践经验，测试组织差，文档较少或不一致，测试发现缺陷的能力较差，那么首先要做的是改进测试的有效性，而不是改进测试效率。只有手工测试积累到一定程度，才能做好自动化测试。

③ 期望自动测试发现大量的新缺陷。测试第一次运行时最有可能发现缺陷。如果测试已经运行，再次运行相同的测试发现新缺陷的概率就小得多。对回归测试而言，再次运行相同的测试只是确保修改是正确的，并不能发现新的问题。

④ 安全性错觉。如果自动测试过程没有发现任何缺陷，并不意味着软件没有缺陷。可能由于测试设计的原因导致测试本身就有缺陷。

⑤ 自动测试的维护性。当软件修改后，通常也需要修改部分测试，这样必然导致对自动化测试的修改。在进行自动化测试的设计和实现时，需要注意这个问题，防止自动化测试带来的好处被高维护成本所淹没。

⑥ 技术问题。商业的测试工具也是软件产品，并不能解决所有问题，通常在某些地方还会有欠缺。测试工具都有适用范围，要很好的利用它，对使用者进行培训是必不可少的。

⑦ 组织问题。自动测试实施并不简单，必须有管理支持及组织艺术。

第 41 贴【 2004 － 6 － 27 】：测试自动化的限制

测试自动化可以带来非常明显的收益，但也有其限制，主要有：
1. 不能取代手工测试
2. 手工测试比自动测试发现的缺陷更多
3. 对测试质量的依赖性极大
4. 测试自动化不能提高有效性
5. 测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
6. 工具本身并无想像力

另外，人工测试比测试工具更优越的另一个方面是可以处理意外事件。虽然工具也能处理部分异常事件，但是对真正的突发事件和不能由软件解决的问题就无能为力。

第 42 贴【 2004 － 6 － 28 】：什么是应首先被自动化的测试？

软件测试的自动化过程是一个渐进的过程，并不需要一开始就对所有的测试进行自动化，这通常也是不现实的。如何选择首先被自动化的测试成了最先遇到的问题。

有些测试，完全没有必要进行自动化，因为自动化它们所需的时间比手工运行它们全部的次数所需的时间总和还长。例如，手工运行一个测试要 10 分钟，而且一般每个月运行 1 次，那么一年需要 120 分钟。但如果自动化这测试需要 10 小时，那么这个测试需要连续不断运行 5 年才能收回成本。

有些测试，虽然执行的时间不长，但过程繁琐，需要执行的动作非常多。比如，一个运行 10 分钟的测试，可能需要击键 150 次，打开 4 ～ 5 个窗口，切换操作。如果将其自动化，可以提高可靠性，也是值得的。

对软件进行的功能性测试，是测试软件系统在做什么。这些测试可以明确的知道应该在什么情况下输入什么，会有什么样的输出。这样的测试是非常容易被自动化的，也能从自动化中获得较大的收益。

对软件进行的性能测试，包括在不同的系统负载下进行的测试。这些测试需要采用工具辅助完成，非常适合进行自动化。

如果在测试中，运行 10% 的测试需要花费 90% 的时间，那么将这 10% 的测试自动化是值得的。

      以下列出了选择首先进行自动化时要考虑的因素：
      非常重要的测试
      涉及范围很广的测试
      对主要功能的测试
      容易自动化的测试
      很快有回报的测试
      运行最频繁的测试

应该注意避免一口气自动化太多的测试。太多的工作导致参与人员工作积极性下降，可维护性下降，增加工作的风险。寻找可快速制胜的测试，尽快让大家看到工作成果，有助于获得更多的工作支持。

第 43 贴【 2004 － 6 － 29 】：工具的选择：创建还是购买

在评估了商业市场后，你可能会发现在你的限制之内没有符合你需求的工具。这时需要考虑是否自行开发自己的工具，还是等待市场上出现满足要求的新工具。

自行开发新工具有以下特点：
1 、它将是最合适你的需求的
2 、可以在工具中补偿被测软件缺乏的可测试性
3 、工具可以假设很了解被测程序，因而减少了实现测试自动化所需的工作
4 、在文档、帮助和培训方面可以不用提供很好的支持
5 、工具可能具有某些典型的问题，如结构、可扩展性等
6 、用户界面不友好

商业工具有以下特点：
1 、获得一个指定功能和性能标准的工具的费用可能比自行开发一个工具的成本要低
2 、在文档、帮助和培训方面必须提供良好的支持
3 、工具通常应该很有吸引力
4 、即使使用一个商业工具，可能无法完全避免建立自己的工具

但即使决定自行开发测试工具，也不要试图生产一个可以广泛使用的商业工具。

第 44 贴【 2004 － 6 － 30 】：自动化脚本之线性脚本

线性脚本是录制手工执行的测试用例得到的脚本。这种脚本包含所有用户的键盘和鼠标输入。如果仅使用线性脚本技术，每个测试用例可以通过脚本完整地被回放。线性脚本中也可能包括比较，比如检查某个窗口是否弹出。

手工运行 10 分钟的测试用例，可能需要 20 分钟到 2 个小时才能完成测试自动化的工作。因为录制的脚本需要维护，尤其是增加部分内容后的维护和测试需要花费很多时间。而且自动化以后的测试执行的时间会大于 10 分钟。

线性脚本有以下的优点：
1 、不需要深入的工作或计划
2 、可以加快开始自动化
3 、对实际执行操作可以审计跟踪
4 、用户不必是编程人员
5 、提供良好的（软件或工具）的演示

线性脚本适用于以下情况：
1 、演示或培训
2 、执行量较少，且环境变化小的测试
3 、数据转换，如将数据从 Notes 数据库中转换到 EXCEL 表格中

线性脚本有以下缺点：
1 、过程繁琐
2 、一切依赖于每次捕获的内容
nbsp; 3 、测试输入和比较是 “ 捆绑 ” 在脚本中的
4 、无共享或重用脚本
5 、线性脚本容易受软件变化的影响
6 、线性脚本修改代价大，维护成本高
7 、非常容易受意外事件的影响，引起整个测试失败

2005-1-20 12:36:50

tester2005

等级：论坛游侠
文章：283
积分：841
注册：2004-12-23
        第6楼

第 45 贴【 2004 － 7 － 1 】：自动化脚本之结构化脚本

结构化脚本类似于结构化程序设计，含有控制脚本执行的指令。这些指令或为控制结构，或为调用结构。控制结构中包括 “ 顺序 ” 、 “ 循环 ” 和 “ 分支 ” ，和结构化程序设计中的概念相同。调用结构是在一个脚本中调用另外脚本，当子脚本执行完成后再继续运行父脚本。

    结构化脚本的优点是健壮性好。也可以通过循环和调用减少工作量。
    结构化脚本的缺点是脚本更复杂，而且测试数据仍然 “ 捆绑 ” 在脚本中。
    结构化脚本侧重于描述脚本中控制流程的结构化特性。

第 46 贴【 2004 － 7 － 3 】：自动化脚本之共享脚本

共享脚本是指脚本可以被多个测试用例使用，一个脚本可以被另外一个脚本调用。这样可以节省生成脚本的时间；当重复任务发生变化时，只需修改一个脚本。

建立共享脚本的时间可能更长，因为需要建立更多的脚本，且每个脚本需要进行适当的修改，达到脚本共享的目的。

共享脚本可以是在不同主机、不同系统之间共享脚本，也可以是在同一主机、同一系统之间共享脚本。

共享脚本的优点有：
1 、以较少的开销实现类似的测试
2 、维护开销低于线性脚本
3 、删除明显的重复
4 、可以在脚本中增加更智能的功能

共享脚本的缺点有：
1 、需要跟踪更多的脚本，给配置管理带来一定的困难
2 、对于每个测试，仍然需要特定的测试脚本，因此维护费用比较高
3 、共享脚本通常是针对被测软件的某部分，存在部分脚本不能直接运行

要获得高质量的共享脚本，需要接受一定的训练。在开始编写脚本时，多花些时间进行设计是值得的。通过共享脚本技术，还可以建立脚本库，达到最大程度的共享。由于共享脚本需要被多次使用，所以与脚本相配套的文档更应该引起注意。

共享脚本侧重描述脚本中共享的特性。

第 47 贴【 2004 － 7 － 4 】：自动化脚本之数据驱动脚本

数据驱动脚本技术将测试输入存储在独立的数据文件中，而不是绑定在脚本中。执行时是从数据文件而不是从脚本中读入数据。这种方法最大的好处是可以用同一个脚本允许不同的测试。对数据进行修改，也不必修改执行的脚本。

使用数据驱动脚本，可以以较小的开销实现较多的测试用例，这可以通过为一个测试脚本指定不同的测试数据文件达到。将数据文件单独列出，选择合适的数据格式和形式，可将用户的注意力集中到数据的维护和测试上。达到简化数据，减少出错的概率的目的。

数据驱动脚本的优点有：
1 、可以快速增加类似的测试
2 、测试者增加新测试不必掌握工具脚本语言的技术
3 、对第二个及以后类似的测试无额外的维护开销

数据驱动脚本的缺点有：
1 、初始建立的开销较大
2 、需要专业（编程）支持
3 、必须易于管理

第 48 贴【 2004 － 7 － 5 】：自动化脚本之关键字驱动脚本

关键字驱动实际上是比较复杂的数据驱动技术的逻辑扩展。将数据文件变成测试用例的描述，用一系列关键字指定要执行的任务。在关键字驱动技术中，假设测试者具有某些被测系统的知识，所以不必告诉测试者如何进行详细的动作，只是说明测试用例做什么，而不是如何做。这样在脚本中使用的是说明性方法和描述性方法。描述性方法将被测软件的知识建立在测试自动化环境中，这种知识包含在支持脚本中。

例如，为完成在网页浏览时输入网址，一般的脚本需要说明在某某窗口的某某控件中输入什么字符；而在关键字驱动脚本中，可以直接是在地址栏中输入网址什么什么；甚至更简单，仅说明输入网址什么什么。

关键字驱动脚本的数量不随测试用例的数量变化，而仅随软件规模而增加。这种脚本还可以实现跨平台的用例共享，只需要更改支持脚本即可。

第 49 贴【 2004 － 7 － 6 】：脚本预处理

预处理是一种或多种预编译功能，包括美化器、静态分析和一般替换。脚本的预处理是指脚本在被工具执行前必须进行编译。预处理功能通常需要工具支持，在脚本执行前自动处理。

美化器是一种对脚本格式进行检查的工具，必要时将脚本转换成符合编程规范的要求。可以让脚本编写者更专注于技术性的工作。

静态分析对脚本或表格执行更重要的检查功能，检查脚本中出现的和可能出现的缺陷。测试工具通常可以发现一些如拼写错误或不完整指令等脚本缺陷，这些功能非常有效。静态分析可以检查所有的缺陷和不当之处。类似于程序设计中的 PC-Lint 和 LogiScope 的功能。

一般替换也就是宏替换。可以让脚本更明确，易于维护。使用替换时应注意不要执行不必要的替换。在进行调试时，应该注意缺陷可能是存在被替换的部分中，而不是原来的脚本中。

第 50 贴【 2004 － 7 － 7 】：自动比较技术

测试验证是检验软件是否产生了正确输出的过程，是通过在测试的实际输出与预期输出（例如，当软件正确执行时的输出）之间完成一次或多次比较来实现的。进行测试自动化工作时，自动比较就成为一个必须的环节。有计划的进行比较会比随意的比较有更高的效率和发现问题的能力。

自动比较的内容可以是多方面的，包括基于磁盘输出的比较，如对数据文件的比较；基于界面输出的比较，如对显示位图的比较；基于多媒体输出的比较，如对声音的比较；还包括其它输出的内容的比较。

比较器可以检测两组数据是否相同，功能较齐全的比较器还可以标识有差异的内容。但比较器并不能告诉用户测试是否通过或失败，需要用户自行判断。

比较可以是简单的比较，仅匹配实际输出与预期输出是否完全相同，这是自动化比较的基础。智能比较是允许用已知的差异来比较实际输出和预期输出。比如，要求比较包含日期信息的输出报表的内容。如果使用简单比较，显然是不行的，因为每次生成报表的日期信息肯定是不同的。这时就需要智能比较，忽略日期的差别，比较其它内容，甚至还可以忽略日期的具体内容，比较日期的格式，要求日期按特定格式输出。智能比较需要使用到较为复杂的比较手段，包括正则表达式的搜索技术、屏蔽的搜索技术等。

第 51 贴【 2004 － 7 － 8 】：测试的敏感性和健壮性

敏感的测试是指测试过程能发现微小的，甚至是不起眼的错误。敏感的测试能发现较多的问题，但任何一点微不足道的改动都将导致测试用例及执行过程的更改。健壮的测试是指测试过程能够容忍较多的差别，不会影响测试用例的失败。在自动化测试时，健壮的测试可以较容易通过执行，也就减少了意外情况对测试过程的影响，但会导致发现问题的能力下降，甚至放过应该发现的问题。

应当在测试的敏感性和测试的健壮性之间进行权衡。对大量的自动测试用例而言，过多的敏感性比缺少敏感性更会反面影响失败分析工作。如果运行一组敏感的测试用例，那么有可能其中多数的测试用例由于相同的原因而失败。在这种情况下，每个失败的测试用例都指示相同的错误，但测试人员只是希望获得不同的错误及错误的差异，并不需要重复相同的错误报告。

    敏感性和健壮性的测试应当是：
   1 、无论软件何时发生了变化，主要在高层次，即在作为明智的检验运行测试事例的地方，使用敏感比较
   2 、考虑多组测试用例，其中的一两组使用敏感比较，而其他组使用健壮比较
   3 、好的测试自动化策略应该是规划敏感测试和健壮测试的混合体

第 52 贴【 2004 － 7 － 9 】： TMM2 级目标

TMM Level 2 - 阶段定义级目标：
1 、区分调试和测试的的各自目标
为了区分调试和测试，需要成立为测试和调试负责的组织，该组织需要建立测试目标和策略，另外该组织还要建立调试目标和策略，这些目标和策略要文字化并确保知会到所有的项目经理和开发人员。

2 、引进测试计划过程
完成这个目标，要建立组织范围内的测试计划组织、建立测试计划策略及计划模板、建立把用户需求引入测试计划的正规途径、测试目标作为测试计划基线、对项目管理者进行测试计划培训、对软件工程师进行测试设计和用例设计培训、
计划工具必须被评估、推荐和申购，使用要得到管理层的支持

3 、基本的测试技术和方法被制度化
必须明确制定何时、如何应用那些测试技术。为此要成立组织范围内的测试技术研究组，进行学习、评估、推荐基本的测试技术、方法和相应的工具支持，管理者要在政策上保证推荐的技术和方法在组织范围内坚持使用。

第 53 贴【 2004 － 7 － 11 】： TMM3 级目标

TMM Level 3 - 集成级目标：
1 、立软件测试的专门组织
建立组织范围内的测试组织，取得高层支持，并且有资金保证；组织范围内明确定义了测试部门的角色和职责，将受过良好培训和激励的员工分配到测试部，测试部员工协助 SQA 工作，以提高测试效率和软件质量；测试部门能与用户建立沟通渠道，把用户需求引入测试过程

2 、建立技术培训流程
管理层必须建立组织范围内的测试培训体制，提供支持和资金，必须建立培训的目标和计划，建立内部培训组织，提供必要的工具、设备和资料

3 、测试和软件周期集成
将测试分成若干阶段，以集成到开发过程中；建立并采用 V 模型，制定与测试相关的工作标准，为了使集成容易实现，必须建立测试人员和开发人员的工作机制

4 、监督和控制软件测试过程
建立相应机构和策略以监控测试过程，建立测试相关活动的度量机制，为测试计划执行过程中的突发事件制定应急措施

第 54 贴【 2004 － 7 － 11 】： TMM4 级目标

TMMLevel 4 - 管理和度量级目标
1 、建立组织范围内的评审流程
评审能尽早、有效地识别、分类和消除缺陷，高层管理者必须制定评审的政策，支持评审过程，并把评审集成在组织文化中；测试组和 SQA 必须制定整个生命周期内的评审目标，计划和过程，并文档化，必须指定要评审的项目；参加评审者要接受培训，包括评审的政策，实践和程序

2 、建立测试度量流程
建立组织范围内的测试度量政策和目标，必须建立面向数据收集、分析和应用的测试度量计划，根据度量分析结果，制定并记录相应的行动计划以改进测试过程

3 、进行软件质量评估
管理者、测试和 SQA 组织必须定义与软件质量相关的质量政策，质量目标和质量属性（例如可以参照 ISO9126 制订质量度量模型）；测试过程必须是结构化的，可度量和可评估的，以保证软件质量目标的可达性

软件测试技术

　软件测试的重要性及其对软件质量的好坏的预意是非常重要的。下面这段话引自Deutsch［DEU79］：性及其对软件质量的好坏的预意是非常重要的。下面这段话引自Deutsch[DEU79]：

　　软件系统的开发包括一系列生产活动，其中由人带来的错误因素非常多。错误可能出现在程序的最初…，其时目标可能是错误的或描述不完整，也可能在后期的设计和开发阶段…，因为人们不能完好无缺地工作和交流，软件开发过程中必须伴有质量保证活动。

　　软件测试是软件质量保证的关键元素，代表了规约、设计和编码的最终检查。

　　软件作为系统元素的可见性不断增加软件故障带来的代价太高使得人们注重于规划良好的彻底测试，软件开发组织将30％—40%的项目精力花在测试上并不为怪。另一方面，人命悠关的软件(如飞行控制和核反应堆)测试所花的时间往往是其他软件工程活动时间之和的三到五倍。

　　本章讨论软件测试基础和设计软件测试用例的技术。软件测试基础定义了软件测试的目标，测试用例的设计讨论符合整体目标的测试用例创建技术。

　　1.1软件测试基础

测试为软件工程师带来了很有趣的意外。在软件过程的早期，软件工程师试图由抽象概念到具体实现来建立软件，现在来了测试，工程师创建测试用例试图“摧毁”已经建立的软件。事实上，在软件工程过程中，测试可以看成(至少心理上)摧毁性的而不是建设性的。

　　软件开发者就其本性而言是建设者，测试要求开发者放弃刚开发的软件是正确的观念，并克服发现错误时的心理矛盾。Beizers［BEI90］如下描述了这种情况：

　　如果我们真正擅长编程，就应当不会有错误，但这只是一个神话。如果我们真的很认真，如果每个人都使用结构化方法，自顶向下设计而且使用决策表，如果程序是用SQUISH写的，如果我们有合适的银弹，就不会有错误了，这样，神话就不存在。因为我们并不擅长所做的事，所以有错误，如果不擅长，就应当感到内疚。因此，测试和测试用例设计是对失误的承认，它注入了一针内疚剂。测试的枯燥是对我们错误的处罚，为什么处罚？为了人？为什么内疚？为了没能达到人类的完美境界？为了没有区别另一个程序员所想的和所说的？为了没有心灵感应？为了没有解决人类四千年来尚未解决的相互通信问题？

　　测试真的应当注入内疚感？测试真的是摧毁性的？这些问题的回答是“不！”，然而，测试的目标可能和我们所期待的不同。

　　1.1.1测试目标

　　Glen Myers［MYE79］在他的软件测试著作中陈述了一系列关于测试目标的规则：欢馐?

　　1.测试是一个为了寻找错误而运行程序的过程。

　　2.一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。

　　3.一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

　　上述目标蕴含了一个观点上的戏剧性变化，他们转向通常的观点，即一个成功的测试是指没有找到错误的测试。我们的目标是设计这样的测试，它们能够系统地揭示不同类型的错误，并且耗费最少时间与最小工作量。

　　如果成功构造了测试(根据上述目标)，则能够在软件中揭示错误。测试的第二个好处在于它证实了软件依据规约所具有的功能及其性能需求，此外，构造测试时的数据收集提供了软件可靠性以及软件整体质量的一些信息。但是，有一件事测试无法完成：

　　测试无法说明错误不存在，它只能表示软件错误已经出现。

　　在构造测试时必须牢记这一点。

　　1.1.2测试原则

　　在设计有效的测试用例之前，软件工程师必须理解软件测试的基本原则。Davie［DAV95］提出了一组①测试原则：

　　·所有的测试都应追溯到用户需求。正如我们所知，软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。

　　·应该在测试工作真正开始的前较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始，因此，所有测试可以在任何代码被产生前进行计划和设计。

　　· Pareto原则应用于软件测试。简单而言， Pareto原则暗示着测试发现的错误中的80％很可能起源于程序模块中的20％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。

　　·测试应从“小规模”开始，逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

　　·穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。

　　·为了达到最佳效果，应该由独立的第三方来构造测试。“最佳效果”指最可能发现错误的测试(测试的主要目标)。由于本章中已经介绍过、并将进一步讨论的那些原因，创建系统的软件工程师并不是构造软件测试的最佳人选。

　　1.1.3可测试性

　　在理想的情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性，这就使得负责测试的人能够更容易地设计有效的测试用例，但是，什么是“可测试性”呢？ JamesBach②这样描述可测试性：

　　软件可测试性就是一个计算机程序能够被测试的容易程度。因为测试是如此的困难，因此，需要知道做些什么才能理顺测试过程。有时，程序员愿意去做对测试过程有帮助的事，而一个包括可能的设计点、特性等等的检查表对他们是很有用的。

　　肯定存在可用于在很多方面测度可测试性的度量，有时，可测试性被用来表示一个特定测试集覆盖产品的充分程度。在军方还用它来表示工具被检验和修复的容易程度。这两种意义都略不同于“软件可测试性”。下面的检查表提供了一组可测试软件的特征：

　　可操作性。“运行得越好，被测试的效率越高。”

　　·产品在功能阶段的演化(允许同时的开发和测试)。

　　可观察性。“你所看见的就是你所测试的。”

　　·每个输入有唯一的输出。

　　·系统状态和变量可见，或在运行中可查询。

　　·过去的系统状态和变量可见，或在运行中可查询(例如：事务日志)。·所有影响输出的因素都可见。

　　·容易识别错误输出。

　　·通过自测机制自动侦测内部错误。

　　·自动报告内部错误。

　　·可获取源代码。

　　可控制性。“对软件的控制越好，测试越能够被自动执行与优化。”·所有可能的输出都产生于某种输入组合。

　　·通过某种输入组合，所有的代码都可能被执行。

　　·测试工程师可直接控制软件和硬件的状态及变量。

　　·输入和输出格式保持一致且有结构。

　　·能够便利地对测试进行说明、自动化和再生。

　　可分解性。“通过控制测试范围，能够更快地分解问题，执行更灵巧的再测试。”·软件系统由独立模块构成。

　　·能够独立测试各软件模块。

　　简单性。“需要测试的内容越少，测试的速度越快。”

　　·功能简单性(例如：特性集是满足需求所需的最小集合)。

　　·结构简单性(例如：将体系结构模块化以限制错误的繁殖)。

　　·代码简单性(例如：采用代码标准为检查和维护提供方便)。

　　稳定性。“改变越少，对测试的破坏越小。”

　　·软件的变化是不经常的。

　　·软件的变化是可控制的。

　　·软件的变化不影响已有的测试。

　　·软件失效后能得到良好恢复。

　　易理解性。“得到的信息越多，进行的测试越灵巧。”

　　·设计能够被很好地理解。

　　·内部、外部和共享构件之间的依赖性能够被很好地理解。

　　·设计的改变被通知。

　　·可随时获取技术文档。

　　·技术文档组织合理。

　　·技术文档明确详细。

　　·技术文档精确性稳定。

　　软件工程师可运用James Bach提出的这些属性来开发可测试的软件配置(即程序、数据和文档)。

　　但是关于测试本身呢？ Kaner， Falk和Nguyen［KAN93］给出了“好”测试的一些属性：文1.一个好的测试发现错误的可能性很高。为了达到这个目标，测试者必须理解软件，并尝试设想软件如何才能失败，理想，被探测的错误类别，例如，在GUI(图形用户界面)中有一种潜在的错误，即错误识别鼠标位置。应该设计一个测试集来验证鼠标位置识别的错误。

　　2.一个好的测试并不冗余。测试的时间和资源是有限的，没有必要构造一个与其他测试用途完全相同的测试，每一个测试都应该有不同的用途(哪怕是细微的差异)。例如，软件SafeHome①中有一个模块被用来识别用户密码以决定是否启动系统，为了测试密码输入的错误，测试者设计了一系列的输入密码测试。在不同的测试中输入有效与无效密码(四个数字)，然而，每一个有效/无效密码将检测一种不同错误模式，例如，一个将8080作为有效密码的系统将不会接受非法密码1234，如果接收1234，将产生错误，另一个测试输入1235，与1234的测试意图相同，因此是冗余的，然而，非法输入8081或8180就有些细微的差异，即对与有效密码相近但并不相同的密码该进行测试。

　　3.一个好的测试应该是“最佳品种” ［KAN93］。在一组目的相似的测试中，时间和资源的限制可能只影响其某个子集的执行，此时，应该使用最可能找到所有错误的测试。

　　4.一个好的测试既不会太简单，也不会太复杂。虽然有时会将一组测试组合到一个测试用例中，其副作用可能屏蔽错误，通常，每一个测试应该独立执行。

　　1.2 测试用例设计

　　软件和其他工程产品的测试设计与产品本身的设计一样具有挑战性，然而由于已经讨论过的一些原因，软件工程师经常将测试作为一种事后的措施，开发一些“感觉上正确”但是缺乏完整保证的测试用例。再回头看看测试目标，我们必须设计出最可能发现最多数量的错误、并耗费最少时间和最小代价的测试。

　　在过去的20年，出现了大量的测试用例设计方法，为开发人员进行测试提供了系统的方法。更重要的是，方法提供了一种有助于确保完全测试的机制，并提供了揭示软件错误的最高可能性。

　　能够采用以下两种方法之一对任何工程化产品(以及大多数其他东西)进行测试：(1)若了解产品的特定功能，则构造测试，以证实各功能完全可执行，同时在各功能中寻找错误；(2)若了解产品的内部构造，则构造测试，以确保“所有齿轮吻合”，即内部操作依据规约执行，而且所有的内部构件被充分利用。第一种测试方法被称为黑盒测试，第二种则被称为白盒测试。

　　如果考虑计算机软件，黑盒测试指在软件界面上进行的测试，虽然设计黑盒测试是为了发现错误，它们却被用来证实软件功能的可操作性；证实能很好地接收输入，并正确地产生输出；以及证实对外部信息完整性(例如：数据文件)的保持。黑盒测试检验系统的一些基本特征，很少涉及软件的内部逻辑结构。

　　软件的白盒测试依赖对程序细节的严密检验，提供运用特定条件和/与循环集的测试用例，对软件的逻辑路径进行测试，在不同的点检验“程序的状态”以判定预期状态或待验证状态与真实状态是否相符。

　　一眼看去，可能认为全面的白盒测试将产生“百分之百正确的程序”，需要我们做的只是定义所有的逻辑路径、开发相应的测试用例，并评估结果，简而言之，详尽地生成用例以测试程序逻辑。不幸的是，穷举测试带来了必然的计算问题，即使是很小的程序，可能的逻辑路径数量也非常大，例如，考虑 100行C语言程序，在一些基本的数据声明之后，程序包含两个嵌套循环，根据输入的条件分别执行1到20次，在内部循环中，需要四个if-then-else结构，该程序中大约有1014条可能路径！

　　为了正确表达这个数值，我们假设开发了一个有魔力的测试处理器(“有魔力”是因为不存在这样的处理器)进行穷举测试。该处理器能在一毫秒内开发一个测试用例、进行运行并评估结果，如果每天运行24小时，每年运行365天，则需要3170年的时间来测试这个程序。不可否认，这将导致大多数开发进度表的混乱，对大型软件系统不可能进行穷举测试。

　　然而，白盒测试不应该被抛弃，可选择有限数量的重要逻辑路径进行测试，检测重要数据结构的有效性，可以综合黑盒测试和白盒测试的属性提供一种方法，以验证软件界面，并有选择地保证软件内部工作的正确性。

　　1.3白盒测试

　　白盒测试，有时称为玻璃盒测试，是一种测试用例设计方法，它使用程序设计的控制结构导出测试用例。使用白盒测试方法，软件工程师能够产生测试用例(1)保证一个模块中的所有独立路径至少被使用一次；(2)对所有逻辑值均需测试true和 false；(3)在上下边界及可操作范围内运行所有循环；(4)检查内部数据结构以确保其有效性。

　　此时可能会提出一个合理的问题：“我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心(和测试)逻辑细节？”换一种说法，我们为什么不将所有精力用于黑盒测试呢？答案在于软件自身的缺陷

　　·逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时，错误往往开始出现在我们的工作中。日常处理往往被很好地了解(和很好地细查)，而“特殊情况”的处理则难于发现。

　　·我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，只有路径测试才能发现这些错误。

　　·印刷上的错误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些打印错误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。打印错误出现在主流上和不明显的逻辑路径上的可能性是一样的。

　　上述任何一条原因都是该进行白盒测试的论据，黑盒测试，不管它多么全面，都可能忽略前面提到的某些类型的错误。正如Beizer所说［BEI90］：“错误潜伏在角落里，聚集在边界上”。白盒测试更可能发现它们。

　　1.4基本路径测试

　　基本路径测试是Tom McCabe［MCC76］首先提出的一种白盒测试技术，基本路径测试方法上”。允许测试用例设计者导出一个过程设计的逻辑复杂性测度，并使用该测度作为指南来定义执行路径的基本集。从该基本集导出的测试用例保证对程序中的每一条语句至少执行一次。

　　1.4.1流图符号

　　在介绍基本路径方法之前，必须先介绍一种简单的控制流表示方法，即流图或程序图①。流图使用图1-1中的符号描述逻辑控制流，每一种结构化构成元素有一个相应的流图符号。

　　为了说明流图的用法，我们采用图1-2中的过程设计表示法，此处，流程图用来描述程序控制结构。图 1-2b将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)。在图1-2b中，每一个圆，称为流图的节点，代表一个或多个语句。一个处理方框序列和一个菱形决测框可被映射为一个节点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。一条边必须终止于一个节点，即使该节点并不代表任何语句(例如：参见if-else-then结构的符号)。由边和节点限定的范围称为区域。计算区域时应包括图外部的范围①。

　　任何过程设计表示法都可被翻译成流图，图 1-3显示了一个程序设计语言(PDL，ProgramDesign Language)片段及其对应的流图，注意，对PDL语句进行了编号，并将相应的编号用于流图中。

　　程序设计遇到复合条件时，生成的流图变得更为复杂。当条件语句中用到一个或多个布尔运算符(逻辑OR，AND，NAND，NOR)时，就出现了复合条件。图1-4中，将一个PDL片段翻译为流图，注意，为语句IF a OR b中的每一个a和b创建了一个独立的节点，包含条件的节点被称为判定节点，从每一个判定节点发出两条或多条边。

　　1.4.2环形复杂性

　　环形复杂性是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于基本路径方法，计算所得的值定义了程序基本集的独立路径数量，并为我们提供了确保所有语句至少执行一次的测试数量的上界。

　　独立路径是指程序中至少引进一个新的处理语句集合或一个新条件的任一路径。采用流图的术语，即独立路径必须至少包含一条在定义路径之前不曾用到的边。例如，图1-2b中所示流图的一个独立路径集合为：

　　路径1：1-11

　　路径2：1-2-3-4-5-10-1-11

　　路径3：1-2-3-6-8-9-10-1-11

　　路径4：1-2-3-6-7-9-10-1-11

　　注意，每一条新的路径都包含了一条新边。路径1-2-3-4-5-10-1-2-3-6-8-9-10-1-11不是独立路径，意味它只是已有路径的简单合并，并未包含任何新边。

　　上面定义的路径1，2，3和4包含了图 1-2b所示流图的一个基本集，简而言之，如果能将测试设计为强迫运行这些路径(基本集)，那么程序中的每一条语句将至少被执行一次，每一个条件执行时都将分别取true和false。应该注意到基本集并不唯一，实际上，给定的过程设计可派生出任意数量的不同基本集。

　　如何才能知道需要寻找多少条路径呢？对环形复杂性的计算提供了这个问题的答案。环形复杂性以图论为基础，为我们提供了非常有用的软件度量。可用如下三种方法之一来计算复杂性：

　　1.流图中区域的数量对应于环形的复杂性。

　　2.给定流图G的环形复杂性——V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图节点数量。

　　3.给定流图G的环形复杂性——V(G)，也可定义为V(G)=P+1，P是流图G中判定节点的数量。

　　再回到图1-2b。可采用上述任意一种算法来计算环形复杂性。

　　1.流图有4个区域。

　　2.V(G)=11条边-9个节点+2=4。

　　3.V(G)=3个判定节点+1=4。

　　因此，图1-2b的环形复杂性是4。

　　更重要的是，V(G)的值提供了组成基本集的独立路径的上界，并由此得出覆盖所有程序语句所需的测试设计数量的上界。

　　1.4.3导出测试用例

　　基本路径测试方法可用于过程设计或源代码生产。本节中，我们将基本路径测试表示为一系列步骤，图1-5中PDL所描述的过程“求平均值”将被用于阐明测试用例设计方法中的各个步骤。注意，“求平均值”虽然是一个非常简单的算法，但是仍然包含了复合条件和循环。

　　1.以设计或代码为基础，画出相应的流图。

　　2.确定结果流图的环形复杂性。可采用上一节中的任意一种算法来计算环形复杂性——V(G)。应该注意到，计算V(G)并不一定要画出流图，计算PDL中的所有条件语句数量(过程求平均值中复合条件语句计数为2)，然后加1即可得到环形复杂性。在图1-6中，

　　V(G)=6个区域

　　V(G)=18条边-14个节点+2=6。

　　V(G)=5个判定节点+1=6。

　　3.确定线性独立的路径的一个基本集。V(G)的值提供了程序控制结构中线性独立的路径的数量，在过程求平均值中，我们指定六条路径：

　　路径1：1-2-10-11-13

　　路径2：1-2-10-12-13

　　路径3：1-2-3-10-11-13

　　路径4：1-2-3-4-5-8-9-2-……

　　路径5：1-2-3-4-5-6-8-9-2-……

　　路径6：1-2-3-4-5-6-7-8-9-2-……

　　路径4、5和6后面的省略号(……)表示可加上控制结构其余部分的任意路径。通常在导出测试用例时，识别判定节点是很有必要的。本例中，节点2、3、5、6和10是判定节点。

　　4.准备测试用例，强制执行基本集中每条路径。测试人员可选择数据以便在测试每条路径时适当设置判定节点的条件。满足上述基本集的测试用例如下：

　　路径1测试用例：

　　value(k)=有效输入，其中k＜i

　　value(i)=-999，其中2≤i≤100

　　期望结果：基于k的正确平均值和总数

　　注意：路径1无法独立测试，必须作为路径4、5和6测试的一部分。

　　路径2测试用例：

　　value(1)=-999

　　期望结果：求平均值=-999；其他按初值汇总

　　路径3测试用例：

　　试图处理101或更大的值

　　前100个数值应该有效

　　期望结果：与测试用例1相同

　　路径4测试用例：

　　value(i)=有效输入，其中i＜100

　　value(k)＜最小值，其中k＜i

　　期望结果：基于k的正确平均值和总数

　　路径5测试用例：

　　value(i)=有效输入，其中i＜100

　　value(k)＞最大值，其中k≥i

　　期望结果：基于k的正确平均值和总数

　　路径6测试用例：

　　value(i)=有效输入，其中i＜100

　　期望结果：基于k的正确平均值和总数

　　执行每个测试用例，并和期望值比较，一旦完成所有测试用例，测试者可以确定在程序中的所有语句至少被执行一次。

　　重要的是要注意，某些独立路径(如，例子中的路径1)不能以独立的方式被测试，即，穿越路径所需的数据组合不能形成程序的正常流，在这种情况下，这些路径必须作为另一个路径测试的一部分来进行测试。

　　1.4.4 图矩阵

　　导出流图和决定基本测试路径的过程均需要机械化，为了开发辅助基本路径测试的软件工具，称为图矩阵(graph matrix)的数据结构很有用。

　　图矩阵是一个正方形矩阵，其大小(即列数和行数)等于流图的节点数。每列和每行都对应于标识的节点，矩阵项对应于节点间的连接(边)，图1-7显示了一个简单的流图及其对应的图矩阵［BEI90］。

　　该图中，流图的节点以数字标识，边以字母标识，矩阵中的字母项对应于节点间的连接，例如，边b连接节点3和节点4。

　　这里，图矩阵只是流图的表格表示，然而，对每个矩阵项加入连接权值(link weight)，图矩阵就可以用于在测试中评估程序的控制结构，连接权值为控制流提供了另外的信息。最简单情况下，连接权值是 1(存在连接)或0(不存在连接)，但是，连接权值可以赋予更有趣的属性：

　　·执行连接(边)的概率。

　　·穿越连接的处理时间。

　　·穿越连接时所需的内存。

　　·穿越连接时所需的资源。

　　举例来说，我们用最简单的权值(0或1)来标识连接，图1-7所示的图矩阵重画为图1-8。字母替换为1，表示存在边(为清晰起见，没有画出0)，这种形式的图矩阵称为连接矩阵(linkmatrix)。图1-8中，含两个或两个以上项的行表示判定节点，所以，右边所示的算术计算就提供了另一种环形复杂性计算(参1.4.2节)的方法。

　　Beizer［BEI90］提供了可用于图矩阵的其他数学算法的处理，利用这些技术，设计测试用例的分析就可以自动化或部分自动化。

　　1.5 控制结构测试

　　1.4节所述的基本路径测试技术是控制结构测试技术之一。尽管基本路径测试简单高效，但是，其本身并不充分。本节讨论控制结构测试的其他变种，这些测试覆盖并提高了白盒测试的质量。

　　1.5.1 条件测试

　　条件测试是检查程序模块中所包含逻辑条件的测试用例设计方法。一个简单条件是一个布尔变量或一个可能带有NOT(“┓”)操作符的关系表达式。关系表达式的形式如：

　　E1＜关系操作符＞E2

　　其中E1和E2是算术表达式，而＜关系操作符＞是下列之一：“＜”，“≤”，“=”，“≠”(“┓=”)，“＞”，或“≥”。复杂条件由简单条件、布尔操作符和括弧组成。我们假定可用于复杂条件的布尔算子包括OR“|”，AND“＆”和NOT“┓”，不含关系表达式的条件称为布尔表达式。

　　所以条件的成分类型包括布尔操作符、布尔变量、布尔括弧(括住简单或复杂条件)、关系操作符或算术表达式。

　　如果条件不正确，则至少有一个条件成分不正确，这样，条件的错误类型如下：

　　·布尔操作符错误(遗漏布尔操作符，布尔操作符多余或布尔操作符不正确)。

　　·布尔变量错误。

　　·布尔括弧错误。

　　·关系操作符错误。

　　·算术表达式错误。

　　条件测试方法注重于测试程序中的条件。本节后面讨论的条件测试策略主要有两个优点，首先，测度条件测试的覆盖率是简单的，其次，程序的条件测试覆盖率为产生另外的程序测试提供了指导。

　　条件测试的目的是测试程序条件的错误和程序的其他错误。如果程序P的测试集能够有效地检测P中的条件错误，则该测试集可能也会有效地检测P中的其他错误，此外，如果测试策略对检测条件错误有效，则它也可能有效地检测程序错误。

　　已经提出了几个条件测试策略。分支测试可能是最简单的条件测试策略，对于复合条件C，C的真分支和假分支以及C中的每个简单条件都需要至少执行一次［MYE97］。

　　域测试(Domain testing)［WHI80］要求从有理表达式中导出三个或四个测试，有理表达式的形式如：

　　E1＜关系操作符＞E2

　　需要三个测试分别用于计算E1的值是大于、等于或小于E2的值［HOW82］。如果＜关系操作符＞错误，而E1和E2正确，则这三个测试能够发现关系算子的错误。为了发现E1和E2的错误，计算E1小于或大于E2的测试应使两个值间的差别尽可能小。

　　有n个变量的布尔表达式需要2n个可能的测(n＞0)。这种策略可以发现布尔操作符、变量和括弧的错误，但是只有在n很小时实用。

　　也可以派生出敏感布尔表达式错误的测试［FOS84，TAI87］。对于有n个布尔变量(n＞0)的单布尔表达式(每个布尔变量只出现一次)，可以很容易地产生测试数小于2n的测试集，该测试集能够发现多个布尔操作符错误和其他错误。

　　Tai［TAI89］建议在上述技术之上建立条件测试策略，称为BRO(branch and relational试集operator)的测试保证能发现布尔变量和关系操作符只出现一次而且没有公共变量的条件中的分支和条件操作符错误。

　　BRO策略利用条件C的条件约束。有n个简单条件的条件C的条件约束定义为(D1，D2，…，Dn)，其中Di(0＜i≤n)表示条件C中第i个简单条件的输出约束。如果C的执行过程中C的每个简单条件的输出都满足D中对应的约束，则称条件C的条件约束D由C的执行所覆盖。

　　对于布尔变量B，B输出的约束说明B必须是真(t)或假(f)。类似地，对于关系表达式，符号＜、=、＞用于指定表达式输出的约束。

　　作为简单的例子，考虑条件

　　C1∶B1＆B2

　　其中B1和B2是布尔变量。C1的条件约束式如(D1，D2)，其中D1和D2是“t”或“f”，值(t，f)是C1的条件约束，由使B1为真B2为假的测试所覆盖。BRO测试策略要求约束集｛(t，t)，(f，t)，(t，f)｝由C1的执行所覆盖，如果C1由于布尔算子的错误而不正确，至少有一个约束强制C1失败。

　　作为第二个例子，考虑

　　C2∶B1＆(E3=E4)

　　其中B1是布尔表达式，而E3和E4是算术表达式。C2的条件约束形式如(D1，D2)，其中D1是“t”或“f”，D2是＜，=或＞。除了C2的第二个简单条件是关系表达式以外，C2和C1相同，所以可以修改C1的约束集｛(t，t)，(f，t)，(t，f)｝，得到C2的约束集，注意(E3=E4)的“t”意味着“=”，而(E3=E4)的“f”意味着“＞”或“＜”。分别用(t，=)和(f，=)替换(t，t)和(f，t)，并用(t，＜＼＜＞)和(t，＞)替换(t，f)，就得到C2的约束集｛(t，=)，(f，=)，(t，＜)，(t，＞)｝。上述条件约束集的覆盖率将保证检测C2的布尔和关系算子的错误。

　　作为第三个例子，考虑

　　C3∶(E1＞E2)＆(E3=E4)

　　其中E1、E2、E3和E4是算术表达式。C3的条件约束形式如(D1，D2)，其中D1和D2是＜、=或＞。除了C3的第一个简单条件是关系表达式以外，C3和C2相同，所以可以修改C2的约束集得到C3的约束集，结果为

　　｛(＞，=)，(=，=)，(＜，=)，(＞，＞)，(＞，＜)｝

　　上述条件约束集能够保证检测C3的关系操作符的错误。

　　1.5.2 数据流测试

　　数据流测试方法按照程序中的变量定义和使用的位置来选择程序的测试路径。已经有不少关于数据流测试策略的研究。

　　为了说明数据流测试方法，假设程序的每条语句都赋予了独特的语句号，而且每个函数都不改变其参数和全局变量。对于语句号为S的语句，

　　DEF(S)=｛X｜语句S包含X的定义｝

　　USE(S)=｛X｜语句S包含X的使用｝

　　如果语句S是if或循环语句，它的DEF集为空，而USE集取决于S的条件。如果存在从S到S′的路径，并且该路径不含X的其他定义，则称变量X在语句S处的定义在语句S′仍有效。

　　变量X的定义—使用链(或称DU链)形式如［X，S，S′］，其中S和S′是语句号，X在DEF(S)和USE(S′)中，而且语句S定义的X在语句S′有效。

　　一种简单的数据流测试策略是要求覆盖每个DU链至少一次。我们将这种策略称为DU测试策略。已经证明DU测试并不能保证覆盖程序的所有分支，但是，DU测试不覆盖某个分支仅仅在于如下之类的情况：if-then-else中的then没有定义变量，而且不存在else部分。这种情况下，if语句的else分支并不需要由DU测试覆盖。

　　数据流测试策略可用于为包含嵌套if和循环语句的程序选择测试路径，为此，考虑使用DU测试为如下的PDL选择测试路径：

　　proc x

　　B1；

　　do while C1

　　if C2

　　then

　　if C4

　　then B4；

　　else B5；

　　endif；

　　else

　　if C3

　　then B2；

　　else B3；

　　endif；

　　enddo；

　　B6；

　　end proc；

　　为了用DU测试选择控制流图的测试路径，需要知道PDL条件或块中的变量定义和使用。假设变量X定义在块B1，B2，B3，B4和B5的最后一条语句之中，并在块B2，B3，B4，B5和B6的第一条语句中使用。DU测试策略要求执行从每个B(0＜i≤5)到Bj(0＜j≤6)的最短路径(这样的测试也覆盖了条件C1，C2，C3和C4中的变量使用)。尽管有25条X的DU链，只需5条路径覆盖这些DU链。原因在于可用5条从Bi(0＜i≤5)到B6的路径覆盖X的链，而这5条链包含循环的迭代就可以覆盖其他的DU链。

　　注意如果要用分支测试策略为上述的PDL选择测试路径，并不需要另外的信息。为了选择BRO测试的路径，只需知道每个条件和块的结构。(选择程序的路径之后，需要决定该路径是否实用于该程序，即是否存在执行该路径的至少一个输入)。

　　由于变量的定义和使用，程序中的语句都彼此相关，所以数据流测试方法能够有效地发现错误，但是，数据流测试的覆盖率测度和路径选择比条件测试更为困难。

　　1.5.3循环测试

　　循环是大多数软件实现算法的重要部分，但是，在软件测试时却很少注意它们。

　　循环测试是一种白盒测试技术，注重于循环构造的有效性。有四种循环［BEI90］：简单循环，串接循环，嵌套循环和不规则循环(如图1-9所示)。

　　简单循环。下列测试集应当用于简单循环，其中n是允许通过循环的最大次数。

　　1.整个跳过循环。

　　2.只有一次通过循环。

　　3.两次通过循环。

　　4.m次通过循环，其中m＜n。

　　5.n-1，n，n+1次通过循环。

　　嵌套循环。如果要将简单循环的测试方法用于嵌套循环，可能的测试数就会随嵌套层数成几何级增加，这会导致不实际的测试数目，Beizer［BEI90］提出了一种减少测试数的方法：*

　　1.从最内层循环开始，将其他循环设置为最小值。

　　2.对最内层循环使用简单循环测试，而使外层循环的迭代参数(即循环计数)最小，并为范围外或排除的值增加其他测试。

　　3.由内向外构造下一个循环的测试，但其他的外层循环为最小值，并使其他的嵌套循环为“典型”值。

　　4.继续直到测试完所有的循环。

　　串接循环。如果串接循环的循环都彼此独立，可以使用嵌套循环的策略测试串接循环。但是，如果两个循环串接起来，而第一个循环的循环计数是第二个循环的初始值，则这两个循环并不是独立的。如果循环不独立，则推荐使用嵌套循环的方法进行测试。

　　不规则循环。尽可能的情况下，要将这类循环重新设计为结构化的程序结构。

　　1.6黑盒测试

　　黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。

　　黑盒测试试图发现以下类型的错误：(1)功能不对或遗漏，(2)界面错误，(3)数据结构或外部数据库访问错误，(4)性能错误和(5)初始化和终止错误。

　　白盒测试在测试的早期执行，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。测试用于回答以下问题：

　　·如何测试功能的有效性？

　　·何种类型的输入会产生好的测试用例？

　　·系统是否对特定的输入值尤其敏感？

　　·如何分隔数据类的边界？

　　·系统能够承受何种数据率和数据量？

　　·特定类型的数据组合会对系统产生何种影响？

　　运用黑盒测试，可以导出满足以下标准的测试用例集［MYE79］：(1)所设计的测试用例能够减少达到合理测试所需的附加测试用例数，和(2)所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。

　　1.6.1 基于图的测试方法

　　黑盒测试①的第一步是理解软件所表示的对象②及其关系，然后，第二步是定义一组保证“所有对象与其他对象都具有所期望的关系”［BEI95］的测试序列，换而言之，软件测试首先是创建对象及其关系图，然后导出测试序列以检查对象及其关系，并发现错误。

　　为了完成这些步骤，软件工程师首先创建一个图，节点代表对象，连接代表对象间的关系，节点权值描述节点的属性(如特定的数据值或状态行为)，连接权值描述连接的特点①。

　　图的符号表示如图1-10a所示。节点表示为圆，而连接有几种，有向连接(有箭头表示)表明关系只在一个方向上存在。双向连接，也称为对称连接，表示关系适于两个方向。如果节点间有几种联系，就使用并行边。

　　举一个简单的例子，考虑部分字处理应用程序图，如图1-10b所示：

　　对象＃1=新建文件菜单选择

　　对象＃2=文档窗口

　　对象＃3=文档文本

　　如图所示，选择菜单“新建文件”产生一个文档窗口，文档窗口的节点权值提供窗口产生时所期望的属性集，连接权值表明窗口必须在1.0秒之内产生，一条无向边在“选择菜单新建文件”和“文档文本”之间建立对称联系，并行连接表明“文档窗口”和“文档文本”间的联系，事实上，要产生测试用例还需要更加详细的图。软件工程师遍历图，并覆盖所显示的联系就可以导出测试用例，这些用例用于发现联系之间的错误。

　　Beizer［BEI95］描述了几个使用图的行为测试方法：

　事务流建模。节点代表事务的步数(如使用联机服务预订航空机票的步数)，连接代表步骤之间的连接关系(如flighgt.information.input后跟validation/availabilty.processing)。数据流图可用于辅助产生这种图。

　　有限状态建模。节点代表不同用户可见的软件状态(如订票人员处理订票时的各个屏幕)，而连接代表状态之间的转换(如order-information在inventory-availability-look-up时验证并后跟customer-billing-information-input)。状态变迁图可用于辅助产生这种图。

　　数据流建模。节点是数据对象，而连接是将数据对象转换为其他对象时发生的变换。例如，节点FICA.tzx.withheld(FTW)由gross.wagess(GW)利用关系FTW=0.062×GW计算而来。

　　时间建模。节点是程序对象，而连接是对象间的顺序连接。连接权值用于指定程序执行时所需的执行时间。

　　基于图的测试方法的详细讨论超出了本书的范围。但是，大致了解一下基于图的测试还是值得的。

　　基于图的测试开始定义节点和节点权值，也即标识对象及其属性，数据模型可以作为起始点，但是要注意很多节点是程序对象(不在数据模型中时显表示出来)，为了标识图的起点和终点，可以定义入点和出点。

　　标识节点以后，就可以建立连接及其权值，连接一般应当命名，但是当代表程序对象间控制流的连接时除外。

　　很多情况下，图模型可能有循环(如图的路径含有环)，循环测试也可用于行为(黑盒)测试，图可用于标识需要测试的循环。

　　分别研究每个关系，以导出测试用例。研究顺序关系的传递性可以发现关系在对象间传播的影响。举例说明，有三个对象X，Y和Z。考虑如下关系：

　　计算Y需要X

　　计算Z需要Y

　　所以，X和Z之间有传递性：

　　计算Z需要X

　　基于这种传递性，测试Z的计算时要考虑X和Y的各种值。

　　关系(图连接)的对称性也是设计测试用例的重要考虑，如果关系是双向(对称)的，就要测试这种性质。很多应用程序的UNDO功能［BEI95］实现了有限的对称性，应该彻底测试并标识鸵馑械囊斐＃床荒苁褂肬NDO的地方)。最后，图的每个节点都应当有到自己的关系，本质上是“空操作”循环，自反性也应当进行测试。

　　开始设计测试用例时，第一个目标是节点的覆盖度，这意味着测试不应当遗漏某个节点，而且节点的权值是正确的。

　　接着，考虑连接的覆盖率，基于属性测试每个关系，例如，测试对称关系以表明它的确是双向的，测试传递关系以表明存在传递性，测试自反关系以表明存在空操作。指明连接权值时，要设计测试以展示权值是否有效，最后，加入循环测试(参见1.5.3节)。

　　1.6.2 等价划分

　　等价划分是一种黑盒测试方法，将程序的输入域划分为数据类，以便导出测试用例。理想的测试用例是独自发现一类错误(如字符数据的处理不正确)。等价划分试图定义一个测试用例以发现各类错误，从而减少必须开发的测试用例数。

　　等价划分的测试用例设计基于输入条件的等价类评估。使用前面章节介绍的概念，如果对象由具有对称性、传递性或自反性的关系连接，就存在等价类［BEI95］。等价类表示输入条件的一组有效或无效的状态。典型地，输入条件通常是一个特定的数值，一个数值域，一组相关值或一个布尔条件。可按照如下指南定义等价类：

　　1.如果输入条件代表一个范围，可以定义一个有效等价类和两个无效等价类。

　　2.如果输入条件需要特定的值，可以定义一个有效等价类和两个无效等价类。

　　3.如果输入条件代表集合的某个元素，可以定义一个有效等价类和一个无效等价类。

　　4.如果输入条件是布尔式，可以定义一个有效等价类和一个无效等价类。

　　作为例子，考虑自动银行应用软件所维护的数据，用户可以用自己的微机拨号到银行，提供六位数的密码，并遵循一序列键盘命令以触发各种银行功能。银行应用程序的软件可以接受如下格式的数据：

　　区号——空或三位数字。

　　前缀——三位数字，但不是0和1开始。

　　后缀——四位数字。

　　密码——六位字母或数字。

　　命令——“检查”，“存款”，“付款”等。

　　与银行应用程序各种数据元素相关的输入条件可以表示为：

　　区号：输入条件，布尔——区号存在与否。

　　输入条件，范围——定义在200和999之间的数值，少数例外。

　　前缀：输入条件，范围——大于200不含0的数值。

　　后缀：输入条件，值——四位数字。

　　密码：输入条件，布尔——密码存在与否。

　　输入条件，值——六位字符串。

　　命令：输入条件，集合——包含上述命令。

　　利用上述导出等价类的指南，就可以为每个输入域的数据项开发并执行测试用例，测试用例的选择最好是每次执行最多的等价类属性。

　　1.6.3边界值分析

　　由于某些未被完全知道的原因，输入域的边界比中间更加容易发生错误，为此，可用的边界值分析(boundary value analysis，BVA)可作为一种测试技术。边界值分析选择一组测试用例检查边界值。

　　边界值分析是一种补充等价划分的测试用例设计技术。BVA不是选择等价类的任意元素，而是选择等价类边界的测试用例，BVA不仅注重于输入条件，而且也从输出域导出测试用例［MYE79］。

　　BVA的指南类似于等价划分：

　　1.如果输入条件代表以a和b为边界的范围，测试用例应当包含a、b、略大于a和略小于b的值。

　　2.如果输入条件代表一组值，测试用例应当执行其中的最大值和最小值，还应当测试略大于最小值的值和略小于最大值的值。

　　3.指南1和2也适用于输出条件，例如，工程分析程序要求输出温度和压强的对照表，测试用例应当能够创建包含最大值和最小值的项。

　　4.如果程序数据结构有预定义的边界(如数组有100项)，要测试其边界的数据项。

　　大多数软件工程师会在某种程度上自发地执行BVA，利用上述指南，边界测试会更加完整，从而更可能发现错误。

　　1.6.4 比较测试

　　有些情况下(如航空电子设备、核电厂控制)，软件的可靠性绝对重要，此时，需要冗余的硬件和软件，以减小错误的可能性。开发冗余软件时，另外的软件工程师队伍利用相同的需求开发应用程序的另外版本，这样，可用相同的测试数据引进测试以产生相同的输出，接着，并行执行所有版本并进行实时结果比较以保证一致性。

　　利用从冗余系统中学到的经验，研究者建议对关键应用程序开发不同的软件版本，即便最后只使用一个版本，不同的版本成了称为比较测试或背靠背测试的黑盒测试技术的基础。

　　同样的需求有不同的实现时，利用其他黑盒技术(如等价分割)设计的测试用例可以作为另一个版本的输入，如果每个版本的输出相同，就可以假定所有的实现都正确，如果输出不同，就要调查各个版本，以发现错误所在。大多数情况下，可用自动化工具进行输出比较。

　　比较测试并不能够保证无错，如果需求本身有错，所有的版本都可能反映错误，另外，如果各个版本产生相同但却错误的结构，条件测试也无法发现错误。
　　

　　1.7 针对专门环境和应用的测试

　　随着计算机软件变得更为复杂，对特殊测试方法的需求也增加了。1.5和1.6两节所讨论的白盒和黑盒测试方法可以用于所有的环境、体系结构和应用程序，但是有时还是需要专门的指南和方法。本节讨论用于软件工程师常见的特定环境、体系结构和应用程序的测试指南。

　　1.7.1 GUI测试

　　图形用户界面(GUI)对软件工程师提出了有趣的挑战，因为GUI开发环境有可复用的构件，开发用户界面更加省时而且更加精确，同时，GUI的复杂性也增加了，从而增加了设计和执行测试用例的难度。

　　因为现代GUI有相同的观感，已经有一序列标准的测试。下列问题可以作为常见GUI测试的指南：

　　对于窗口：

　　·窗口能否基于相关的输入或菜单命令适当地打开？

　　·窗口能否改变大小、移动和滚动？

　　·窗口中的数据内容能否用鼠标、功能键、方向箭头和键盘访问？

　　·当被覆盖并重调用后，窗口能否正确地再生？

　　·需要时能否使用所有窗口相关的功能？

　　·所有窗口相关的功能是可操作的吗？

　　·是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用，并适当地显示？

　　·显示多个窗口时，窗口的名称是否被适当地表示？

　　·活动窗口是否被适当地加亮？

　　·如果使用多任务，是否所有的窗口被实时更新？

　　·多次或不正确按鼠标是否会导致无法预料的副作用？

　　·窗口的声音和颜色提示和窗口的操作顺序是否符合需求？

　　·窗口是否正确地关闭？

　　对于下拉式菜单和鼠标操作：

　　·菜单条是否显示在合适的语境中？

　　·应用程序的菜单条是否显示系统相关的特性(如时钟显示)？

　　·下拉式操作能正确工作吗？

　　·菜单、调色板和工具条是否工作正确？

　　·是否适当地列出了所有的菜单功能和下拉式子功能？

　　·是否可以通过鼠标访问所有的菜单功能？

　　·文本字体、大小和格式是否正确？

　　·是否能够用其他的文本命令激活每个菜单功能？

　　·菜单功能是否随当前的窗口操作加亮或变灰？

　　·菜单功能是否正确执行？

　　·菜单功能的名字是否具有自解释性？

　　·菜单项是否有帮助，是否语境相关？

　·在整个交互式语境中，是否可以识别鼠标操作？

　　·如果要求多次点击鼠标，是否能够在语境中正确识别？

　　·如果鼠标有多个按钮，是否能够在语境中正确识别？

　　·光标、处理指示器和识别指针是否随操作恰当地改变？

　　对于数据项：

　　·字母数字数据项是否能够正确回显，并输入到系统中？

　　·图形模式的数据项(如滑动条)是否正常工作？

　　·是否能够识别非法数据？

　　·数据输入消息是否可理解？

　　除了上述智能以外，有限状态建模图(参见1.6.1节)也可以用于导出GUI相关的数据和程序对象的测试集。

　　因为GUI操作相关的排列数很大，所以应当用自动化工具进行测试。近几年来市场上已有不少的GUI测试工具，关于详细情况。

　　1.7.2 客户/服务器体系结构的测试

　　客户/服务器体系(C/S)结构对软件测试人员提出了很大挑战。客户/服务器的分布式特性、事务处理相关的性能、不同硬件平台存在的可能性、网络通讯的复杂性、由中心(或分布式)数据库为多个客户服务和服务器的协调需求一起使得C/S体系结构及其软件的测试更为困难。事实上，最近的工业研究表明开发C/S环境时显著增加了测试时间和成本。有关客户/服务器测试的详细信息。

　　1.7.3 测试文档和帮助设施

　　术语“软件测试”造成一种假象，即测试用例是为程序及其操纵的数据准备的。回忆一下本书第一章所讲的软件定义，要注意到测试必须扩展到软件的第三个元素——文档①。

　　文档错误会同数据和代码错误一样给程序带来灾难性后果。没有什么比精确地按照用户指南，但得到的结果却不符合文档的描述更令人气恼的了。为此，文档测试也是每个软件测试中有意义的一部分。

　　文档测试可以分为两个步骤。第一步为正式的技术复审，检查文档的编辑错误；第二步是活性测试(live testing)，结合实际程序的使用而使用文档。

　　活性测试可使用类似于1.6节所述的黑盒测试方法，基于图的测试可用于描述程序的使用。等价划分和边界值分析可以定义输入类型及其相关的交互，然后就可以按照文档跟踪程序的使用：

　　·文档是否精确描述了如何使用各种使用模式？

　　·交互顺序的描述是否精确？

　　·例子是否精确？

　　·术语、菜单描述和系统响应是否与实际程序一致？

　　·是否能够很方便地在文档中定位指南？

　　·是否能够很方便地使用文档排除错误？

　　·文档的内容和索引是否精确完整？

　　·文档的设计(布局、缩进和图形)是否便于信息的理解？

　　·显示给用户的错误信息是否有更详细的文档解释？

　　·如果使用超级链接，超级链接是否精确完整？

　　回答这些问题最可行的方法是让第三个组(如选择用户)按照程序的使用测试文档。标出所有错误和模糊的地方，以便重写。

　　1.7.4 实时系统测试

　　很多实时系统的时间依赖性和异步性给测试带来新的困难——时间。测试用例的设计者考虑的不仅是白盒和黑盒测试用例，而且包括事件处理(如中断处理)，数据的时间安排以及处理数据的任务(进程)的并发性。很多情况下，提供的测试数据有时使得实时系统在某状态下可以正常运行，而同样的数据在系统处于不同状态时有时又会导致错误。

　　例如，控制复印机的实时软件在机器复印时接收操作员的中断(如操作员按某些键如“reset”或“darken”)不会产生错误，但是如果在夹纸时，按同样的键就会产生一个诊断代码，指明夹纸的位置信息将被丢失。

　　另外，实时系统的软件和硬件之间的密切关系也会导致测试问题，软件测试必须考虑硬件故障对软件处理的影响，这种故障很难实时仿真。

　　实时系统的综合性测试用例设计方法还有待进一步发展，但是，仍然已有了大致的四步策略：

　　任务测试测试实时系统的第一步是独立地测试各个任务。也即对每个任务设计白盒和黑盒测试用例，并在测试时执行每个任务。任务测试能够发现逻辑和功能错误，但是不能发现时间和行为错误。

　　行为测试利用CASE工具创建的软件模型，就可能仿真实时系统，并按照外部事件的序列检查其行为，这些分析活动可作为创建实时系统时设计测试用例的基础。使用类似于等价划分的技术，可以对事件(如中断、控制信号和数据)分类测试，例如，复印机的事件可能是用户中断(如重置计数)、机器中断(如卡纸)、系统中断(如缺粉)和故障模式(如过热)。每种事件都可以独立测试，并且检查可执行系统的行为以检测是否有与事件处理相关的继发性错误。对系统模型(在分析活动时开发)的行为和可执行软件进行符合性比较，看是否一致。测试每种事件以后，以随机顺序和随机频率将事件传给系统，检查系统行为看是否有行为错误。

　　任务间测试在隔离了任务内部和系统行为错误以后，测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务，看任务间的同步是否会产生错误。另外，测试通过消息队列和数据存储进行通讯的任务，以发现这些数据存储区域大小方面的错误。

　　系统测试集成软件和硬件，并进行大范围的系统测试，以发现软件/硬件接口间的错误。

　　很多实时系统处理中断，所以，测试布尔事件的处理尤其重要。利用状态变迁图和控制规约，测试者可开发一系列可能的中断及其将发生的处理，设计测试用例以验证如下的系统特性：

　　·是否能够正确赋予和处理中断的优先权？

　　·每个中断的处理是否正确？

　　·中断处理的性能(如处理时间)是否符合需求？

　　·关键时刻有大量中断时，是否会导致功能和性能上的问题？

　　另外，也测试应当作为中断处理一部分的传输信息的全局数据区域，以评估潜在的副作用。

软件测试的常识

软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

? 软件未达到客户需求的功能和性能；

? 软件超出客户需求的范围；

? 软件出现客户需求不能容忍的错误；

? 软件的使用未能符合客户的习惯和工作环境。

考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

? 测试是不完全的（测试不完全）

很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合为我们精简测试复杂性的一条必经之道。

? 测试具有免疫性（软件缺陷免疫性）

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

? 测试是 “ 泛型概念 ” （全程测试）

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

? 80-20 原则

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

? 为效益而测试

为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

? 缺陷的必然性

软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

? 软件测试必须有预期结果

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

? 软件测试的意义 - 事后分析

软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。

结论：

软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助。

posted on 2008-06-02 15:35 小寒阅读(8445) 评论(2) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

点滴积累,融会贯通

公告

黑盒测试

软件测试基本内容（转贴）

软件测试技术

软件测试的常识