6.3 软件测试技术
6.3.1软件测试技术相关概念
软件测试的定义
•在某种指定的条件下对系统或组件操作，观察或记录结果，对系统或组件的某些方面进行评估的过程。
•分析软件各项目以检测现有的结果和应有结果之间的差异，并评估软件各项目的特征的过程。
软件缺陷
- 软件未实现产品说明书要求的功能。
- 软件出现了产品说明书指明不能出现的错误。
- 软件实现了产品说明书未提到的功能。
- 软件未实现产品说明书虽未明确提及但应该实现的目标。
- 软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。
- 验证（Verification）
- 保证软件特定开发阶段的输出已经正确完整地实现了规格说明
- 确认（Validation）
- 对于每个测试级别，都要检查开发活动的输出是否满足具体的需求或与这些特定级别相关的需求
软件质量保证
创建、执行改进过程并防止缺陷的标准和方法
质量与可靠性
- 功能性（functionality）
- 可移植性（portability）
- 效率（efficiency）
- 可靠性（reliability）
- 可维护性（maintainability）
- 可用性（usability）
软件调试
- 目标是定位与修复缺陷
软件测试
找出软件缺陷，并确保修复
软件测试的目标
- 测试用例（test case）：是测试输入、执行条件、以及预期结果的集合，是为特定的目的开发的，例如执行特定的程序路径或验证与指定的需求相符合。
- 主题。设计者、类型、测试名称、状态、描述、优先级、comment、步骤名、步骤描述、预期结果、评审人、评审备注、评审时间等……
软件测试的基本原则
- 穷尽测试是不可能的
- 测试无法显示潜伏的软件缺陷
- 测试活动应尽早进行
- 软件缺陷具有群聚性
- 注意“杀虫剂”现象
- 尽量由独立的测试团队进行测试
评估准则
主要测试方法
白盒测试
白盒测试
-
把测试对象看做一个透明盒子，允许利用程序内部逻辑结构及有关信息，进行测试。
-
通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
-
又称为结构测试或逻辑驱动测试。
检查范围
-
•对程序模块的所有独立的执行路径至少测试一次；
-
对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；
-
在循环的边界和运行界限内执行循环体；
-
测试内部数据结构的有效性等。
完全测试的困难性
对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字
例如：
执行路径数：520条
设：每一条路径测试需要1毫秒，如果一年工作365 × 24小时。需用时：3170年。
逻辑覆盖
以程序内部的逻辑结构为基础设计测试用例的技术。
- 语句覆盖
- 分支覆盖
- 条件覆盖
- 条件组合覆盖
分支覆盖
分支覆盖：就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。分支覆盖又称为判定覆盖。
条件覆盖
条件覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
条件组合覆盖
条件组合覆盖：设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
控制流图覆盖测试：是将代码转变为控制流图（CFG），基于其进行测试的技术。
程序的控制图
- 结点：符号○ ，表示一个或多个无分支的PDL语句或源程序语句。
- 边：箭头，表示控制流的方向。
- 汇聚节点：在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。
- 区域：边和结点圈定的区域。对区域计数时，图形外的区域也应记为一个区域，即每次至少有两个区域。
单条件嵌套
单条件嵌套：如果判断中的条件表达式是由一个或多个逻辑运算符 (OR, AND, NAND, NOR) 连接的复合条件表达式，则需要改为一系列只有单个条件的嵌套的判断。
节点覆盖
对图中的每个节点，至少要有一条测试路径访问该节点
显然，节点覆盖=语句覆盖
边覆盖
对图中每一个可到达的长度小于(无边图)等于1 的路径，中至少存在一条测试路径覆盖。
显然，边覆盖包含节点覆盖，且边覆盖也可以实现分支覆盖。
路径覆盖
路径覆盖测试：就是设计足够的测试用例，覆盖程序中所有可能的路径
基本路径覆盖
基本路径测试：将覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。
例
黑盒测试
-
测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性
-
只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明
-
又叫做功能测试或数据驱动测试。
基本思想
•把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。
检查范围
是否有不正确或遗漏了的功能?
在接口上，输入能否正确地接受? 能否输出正确的结果?是否有数据结构错误或外部信息访问错误?性能上是否能够满足要求?是否有初始化或终止性错误?
测试步骤
•划分等价类
•选取测试用例
完全测试的困难性
如果考虑所有的可能性，黑盒测试同样可能是天文数字
等价类划分
•等价类：某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。
•有效等价类：对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。
•无效等价类：对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
两个有无有效的等价类这两条需要同时考虑。
划分步骤
1： 如果输入条件规定了取值范围
2：如果输入条件规定了输入值的集合，或者规定了“必须如何”
3：如果输入条件是一个布尔量
4：如果规定了输入数据的一组值，而且要对每个输入值分别进行处理。
原则5：如果规定了输入数据必须遵守的规则
例
在某一PASCAL语言版本中规定：“标识符是由字母开头，后跟字母或数字的任意组合构成。有效字符数为不超过8个。”
并且规定：“标识符必须先说明，再使用。” “在同一说明语句中，标识符至少必须有一个。”
边界值分析
方法HOW
确定边界情况
选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据做为测试数据。
边界指标BY
相当于输入、输出等价类而言，稍高、低于其边界值的一些特定情况
含义WHAT
黑盒测试方法
对等价类划分方法的补充
原因WHY
大量的错误是发生在输入或输出范围边界上
边界测试可以查出更多的错误
例
状态测试
状态测试
在黑盒测试阶段，通过对状态的测试间接地加以验证功能
软件状态
软件当前所处的条件或者模式。
除了极少数简单程序外，均需选择重要的内容进行测试。
建立状态转换图
建立状态转换图 ——> 根据状态转换图设计测试用例
- 找出从一种状态转入另一种状态所需的输入和条件。
- 标识出软件可能进入的每一种独立状态。
- 找出进入或退出某种状态时的设置条件及输出结果。
根据状态转换图设计测试用例原则
- 每种状态至少访问一次
- 测试看起来是最常见和最普遍的状态转换
- 测试状态之间最不常用的分支
- 测试所有错误状态及其返回值
- 测试状态的随机转换
例
(1)列出所有输入事件
(2)从启动开始，第一轮状态分析
(3)从启动开始，第二轮状态图分析，加入所有可能的输入
静态分析方法
不运行程序，通过检查和阅读等手段来发现错误并评估代码质量的测试技术
作用
- 代码标准、质量监控提高可靠性
- 尽早通过源代码检查发现缺陷
- 代码审核定位易产生错误的模块
通用评审过程
- 计划
- 概述
- 准备
- 评审会议
- 返工
- 追踪
静态分析的主要内容
需求+设计+代码
静态分析类型
-
同事审查
适用于初次审查，要求最低的正式方法，也称为伙伴审查
-
走查
开发组内部进行
-
审查
以会议形式，由开发组、测试组和相关人员联合进行。
