软件工程 软件测试 第6篇随笔
5、软件测试
5.1、软件测试基础
1.软件测试的目的:
- 测试是一个为了发现错误而执行程序的过程
- 一个好的测试用例是指很可能找到迄今为止尚未发现的错误的测试用例
- 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试
2.Davis提出了一指导软件测试的基本原则:
- 所有的测试都应该可以追溯到客户的需求
- 应该在测试工作真正开始前的较长时间就进行测试计划
- pareto原则:测试中发现的80%的错误可能来自于20%的程序代码
- 测试应从”小规模“开始,逐步转向”大规模”
- 穷举测试是不可能的,为了达到最有效的测试,应由独立的第三方来承担责任
5.2、白盒测试与黑盒测试
1.白盒测试
白盒测试(又称为结构测试)把测试对象看作一个透明的盒子,测试人员根据程序内部的逻辑结构及有关信息设计测试用例,检查程序中所有逻辑路径是否都按照预定的要求正确工作
白盒测试主要用于对模块的测试:
- 程序模块中的所有独立路径至少执行一次
- 对所有逻辑判定的取值(“真”与“假”)都至少测试一次
- 在上下边界及可操作范围运行所有循环
- 测试内部数据结构的有效性
白盒测试常用的方法:
-
逻辑覆盖测试
逻辑覆盖主要考察使用测试数据运行被测试程序时对程序逻辑的覆盖程度
主要覆盖的标准:
-
语句覆盖
语句覆盖是指选择足够的测试用例,使得运行这些测试用例时,被测试程序的每个可执行语句都至少执行一次
-
判定覆盖
判定覆盖(也称分支覆盖)是指选择足够的测试用例,使得运行这些测试用例时,被测程序的每个判定的所可能结果都至少执行一次(即判定的每个分支至少经过一次);
满足判定覆盖也一定满足语句覆盖
-
条件覆盖
条件覆盖是指选择足够的测试用例,使得运行这些测试用例时,被测试程序的每个判定中的每个条件的所有可能结果都至少出现一次
-
判定—条件覆盖
判定—条件覆盖是指选择足够的测试用例,使得运行这些测试用例时,被测程序的每个判定的所可能结果都至少执行一次,并且,每个判定中的每个条件的所有可能结果都至少出现一次
判定—条件覆盖包括:语句覆盖、判定覆盖、条件覆盖
-
条件组合覆盖
条件组合覆盖是指选择足够的测试用例,使得运行这些测试用例时,被测程序的每个判定中条件结果的所有可能组合都至少出现一次
条件组合覆盖一定满足:判定—条件覆盖、语句覆盖、判定覆盖、条件覆盖
-
路径覆盖
路径覆盖是指选择足够的测试用例,使得运行这些测试用例时,被测程序的每条可能执行到的路径都至少经过一次(如果程序中包含环路,则要求每条环路至少经过一次)
-
-
基本路径覆盖测试
需要使用到程序控制流图(也称程序图)
例题:
-
数据流测试
数据流的测试是根据程序中变量的定义(赋值)和引用位置来选择测试用例
-
循环测试
分为四种不同的类型:
-
简单循环
下列规则设计简单循环测试:
- 0次循环
- 1次循环
- 2次循环
- m次循环
- 最大次数循环
- 比最大次数多一次循环
- 比最大次数少一次循环
-
嵌套循环
下列规则设计嵌套循环测试:
- 先测试最内侧的循环
- 由里向外,测试上一层循环
- 重复上一条规则,直到所有各层循环测试完毕
- 对全部各层循环同时取最小次数,或者同时取最大循环次数
-
串接循环
如果相互独立就使用简单循环来
如果两个循环相关,就使用嵌套循环来使用
-
非结构循环
这一类循环一个先将其结构化,然后在测试
-
2.黑盒测试
黑盒测试(又称为行为测试)把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能需求
黑盒测试可用于各种测试,它试图发现以下类型的错误:
- 不正确或遗漏的功能
- 接口错误,如输入/输出参数的个数、类型等
- 数据结构错误或外部信息(如外部数据库)访问错误
- 性能错误
- 初始化和终止错误
黑盒测试常用的方法:
-
等价类划分
等价类划分是为了解决不能穷举的方法,等价类划分方法将所有可能的输入数据划分若干个等价类,然后在每个等价类中选择一个代表数据进行测试用例
步骤:
- 确定等价类
- 设计测试用例
-
边界值分析
边界值分析也是一种黑盒测试方法,是对等价类划分方法的补充;是等价类划分的一种特殊情况;在边界值附件进行测试;超出边界值点点
-
比较测试
-
错误猜测
凭借直觉和经验推测某些可能存在的错误
-
因果图
是帮助人们系统地选择一组高效测试的用例方法
特点:
- 考虑输入条件的组合关系
- 考虑输出条件对输入条件的依赖关系,即因果关系
- 测试用例发现错误的效率高
- 能检查出功能说明中的某些不一致或遗漏
步骤:
- 分割功能说明书
- 识别“原因”和“结果”,并加以编号
- 根据功能说明中规定的原因与结果之间的关系画出因果图
-
根据功能说明在因果图中加上约束条件
-
根据因果图画出判定表
---- ---- 原因 允许的原因组合 中结节点 各种原因组合下中间结点的值 结果 各种原因组合下的结果值 -
为判定的每一列设计一个测试用例
5.3、测试策略
- 一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试
- 单元测试是针对程序中的模块或构件,主要揭露编码阶段产生的错误
- 集成测试针对集成的软件系统,主要揭露设计阶段产生的错误
- 确认测试是根据软件需求规约对集成的软件进行确认,主要揭露不符合需求规约的错误
- 对于基于计算机系统中的软件,还需将它集成到基于计算机系统中,并进行系统测试,以揭露不符合系统工程中对软件要求的错误
1.测试策略的原则:
- 在着手开始测试之前的较长时间,就要以量化的形式确定产品的需求
- 显示地陈述测试目标
- 了解软件的用户并为每一类用户建立剖面图
- 建立一个强调”快速循环测试“的测试计划
- 构造”健壮“的软件,它被设计成可测试自身
- 使用有效的正式技术评审作为测试之前的过滤器
- 使用正式技术评审来评估测试策略和测试用例本身
- 为测试过程建立一种持续改进的方法
2.四种测试
-
单元测试
又称模块测试,它着重对软件设计的最小单元(软件构件或模块)进行验证
单元测试内容:
- 模块接口
- 局部数据结构
- 边界条件
- 所有独立路径
- 所有错误处理路径
单元测试过程:
- 单元测试通常与编码工作结合起来进行
- 模块本身不是一个独立的程序,在测试模块时,必须为每一个被测试模块开发一个驱动(driver)程序和若干个桩(stub)模块
- 驱动模块接收测试数据,调用测试模块
- 桩模块替代被被测试模块调用的模块
-
集成测试
继承测试也称组装测试、联合测试
主要问题:
- 数据可能在通过接口时丢失
- 一个模块可能对另一个模块产生非故意的、有害的影响(副作用)
- 当子功能被组合起来时,可能不能达到期望的主功能
- 单个模块可以接受的不精确,连接起来后可能会扩大到无法接受的程度
- 全局数据结构可能会存在问题
集成的两种方式:
- 非增量式集成
- 增量式集成
- 自顶向下集成
- 自底向上集成
-
回归测试
回归测试就是对已经进行过测试的子集的从新执行,确保对程序的改变和修改,没有传播非故意的副作用
三种不同的测试用例:
- 能测试软件所有功能的代表性测试用例
- 专门针对可能会被修改影响的软件功能的附加测试
- 注重于修改过的软件模块的测试
-
确认测试
确认测试以软件需求规约为依据,以发现软件与需求不一致的错误
分为两类:
- 满足需求规约要求的功能或性能特性,用户可以接受
- 发现与需求规约由偏差,此时需列出问题清单
-
系统测试
系统测试是对整个基于计算机的系统进行的一系列测试
系统测试包括:
- 恢复测试
- 安全测试
- 压力测试
- 性能测试
5.4、面向对象的测试
面对对象软件的测试目标仍然是用最少时间和工作量来发现尽可能多的错误
1.面向对象语境对测试的影响
适用于面向对象测试的两种单元定义
- 单元是可以编译和执行的最小软件部件
- 单元是绝不会指派多个设计人员开发的软件部件
2.面向对象的测试策略
-
类内测试
-
类间测试
两种集成策略:
- 基于线程的测试(thread-based testing)
- 基于使用的测试(use-based testing)
2.面向对象的测试用例设计
传统的测试用例设计方法及其思想在面向对象测试中仍然可用
- 划分测试
- 基于状态的划分
- 基于属性的划分
- 基于类别的划分