软件测试综述

目录

一、软件测试目标、任务与策略

二、白盒、黑盒测试方法的测试用例设计策略与方法

三、软件测试步骤与方法

四、常用软件测试工具

五、软件质量评估方法


一、软件测试目标、任务与策略

  • 软件测试的目标:发现程序中的错误,是为 了证明程序有错,而不是证明程序无错。保证软件质量,提高软件可靠 性的关键。
  • 测试的任务:

软件测试一般分为计划阶段,设计阶段,开发阶段,实现阶段和评估阶段。其中设计阶段和评估阶段是关键。根据各个阶段目标不同,软件测试的主要任务有:

(1) 设计阶段:通过对系统的整体分析,提出针对性的策略和规范,对系统输入空间进行合理的划分,据此来写出足够的、具体的测试用例。

(2) 开发阶段:由于系统的规模庞大,测试用例的多样化,在执行时要考虑效率的问题,所以需要开发必要的工具在测试用例的选择,修订和完善上尽可能采用自动化的手段。

(3) 实现阶段:代码完成后产品达到可靠性和稳定性阶段,也是产品的beta版阶段。产品的质量将由该阶段测试实现程度来决定。

(4) 评估阶段:根据设计阶段提出的准则对测试用例的覆盖度进行评判,对测试的有效性及结果的可信性提供只量化的依据。

  • 软件测试的策略
  1. 静态测试方法:人工测试方法,计算机辅助静态分析方法

基本特征:基本特征是在对软件进行分析、检查和测试,不实际运行被测试的软件. 静态测试约可找出 30 ~ 70%的逻辑设计错误.

 需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错.

  1. 动态测试方法:白盒测试方法,黑盒测试方法,穷举测试方法

基本特征:通过运行软件来检验软件的动态行为和运行结果的正确性.

动态测试的两个基本要素:被测试程序、测试数据(测试用例)

二、白盒、黑盒测试方法的测试用例设计策略与方法

  1. 白盒测试:
  1. 逻辑覆盖法:一系列测试方法总称,特点是逐渐进行越来越完整的通路测试。

准则:

(1) 语句覆盖

使程序中每个语句至少执行一次,语句覆盖是最弱的逻辑覆盖

(2) 判定覆盖

使每个判定的真假分支都至少执行一次,判定覆盖仍是弱的逻辑覆盖

(3) 条件覆盖

使每个判定的每个条件的可能取值至少执行一次。条件覆盖不一定包含判定覆盖,

判定覆盖也不一定包含条件覆盖

(4) 判定/条件覆盖

选取足够多的测试用例,使判断中的每个条件的所有可能取值至少执行一次,同

时每个判断本身的所有可能判断结果至少执行一次. 能同时满足判定、条件两种覆盖标准。取值。

(5) 条件组合覆盖

所有可能的条件取值组合至少执行一次

(6) 路径覆盖

覆盖每一个可能的路径

  1. 路径测试法:

借助程序控制流图设计测试

用例的白盒测试法.

u 点覆盖:

测试路径至少经过程序控制流图中每个节点一次

u 边覆盖

测试路径至少经过程序控制流图中每条边一次。

     2、黑盒测试:

  1. 等价类划分法:

把所有可能的输入数据(有效 有效的和无效的 的和无效的)划分成若干个等价的 划分成若干个等价的子集 子集 ( 称为等价类), , 使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同

可从每个子集中选取一组数据 可从每个子集中选取一组数据来测试程序即可。

分为有效等价类,无效等价类

划分规则:

(1) 如果规定了输入值的范围时,可定义一个有效等价类和两个无效等价类。

(2) 当规定了输入的规则时,则可以划分出一个有效的等价类(符合规则)和

若干无效的等价类(从不同角度违反规则)。

(3) 如规定了输入数据的一组值 , 且程序对不同输入值做不同处理 , 则每个允许

的输入值是一个有效等价类 , 并有一个无效等价类 ( 所有不允许的输入值的集合 )

(4 ) 如规定了输入数据是整型 , 则可划分出正整数 、 零、 负整数三个有效等价类 。

(5 ) 当处理表格时:有效类可分为空表 、 含一项的表 、含多项的表等 。

设计测试步骤:

(1) 形成等价类表 , 每一等价类规定一个唯一的编号;

(2) 设计一测试用例 , 使其尽可能多地覆盖尚未覆盖的有效等价类 , 重复这一步骤 , 直到所有有效等价类均被测试用例所覆盖;

(3) 设计一新测试用例 , 使其只覆盖一个无效等价类 , 重复这一步骤直到所有无效等价类均被覆盖 ( 通常程序执行一个错误后不继续检测其它错误 , 故每次只测一个无效类 )

1、边界值分析法:

是与等价类划分有区别

测试用例原则:

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

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

(3)如规格说明中提出输入输出的有序集 如规格说明中提出输入输出的有序集(顺序文件、有序表等 (顺序文件、有序表等),取有序集的第 ,取有序集的第一个和最后一个元素做测试用例

(4)如程序数据结构有预定的边界,应测试,如程序数据结构有预定的边界,应测试

其边界的数据项。

(5)如输出条件规定了取值范围,取边界上下如输出条件规定了取值范围,取边界上下

浮动值做测试用例。

2、错误推测法:

思路:

列出可能有的错误;

列出容易发生错误的特殊情况。

以此为基础设计测试方案。

三、软件测试步骤与方法

(1)软件测试的步骤:单元测试、集成测试、确认测试、系统测试

单元测试: 要对模块的五个基本特性进行评价

集成测试: 检验概要设计中模块接口设计问题

确认测试: 以需求规格说明书为检验尺度

系统测试: 综合检验,平行运行:新旧两套系统并行运行,对照检验,测试可视为分析、设计、编码三个阶段的最终复审,以保证软件质量。

(2)单元测试:

主要测试以下五个方面:

a、模块接口:

内部检查:传输参数的数目、属性、单位、 次序是否匹配;全程变量的定义是否一致; 只做输入的变元有无被修改,等等。 &

外部检查:打开、结束、关闭文件的操作; 文件和属性;I\O错误处理;输出拼写,等。

b、局部数据结构

数据说明(declaration);初始化与缺省 值的设置;变量名拼写;数据类型的相容性; 上、下溢出及地址异常,等等。

c、重要的执行通路:

由于穷尽测试不可能,故通常针对最常见 的错误设计测试方案。较常见的错误有:

计算次序问题;

不同类型混合运算(如比较类型不同的量);

初值设置错误;

精度问题(例:精度不够导致两变量不可能 相等,而程序中等待相等条件的出现;

表达式错误;

循环终止条件错误(例:次数差1,或陷入 死循环)。

d、出错处理通路

预见出现错误的条件,设置处理。较常见的问题有

输出的错误信息难以理解,不能确定错误位置 &

描述的错误与实际错误不符 &

处理之前系统已经干预 &

处理不正确

e、边界条件

单元测试中最后,也可能是 最重要的任务,因为软件常在其边界失效。

(3)软件测试的方法:

  • 静态测试方法:人工测试方法 计算机辅助静态分析方法
  • 动态测试方法:白盒测试方法 黑盒测试方法 穷举测试方法

静态测试:

基本特征是在对软件进行分析、检 查和测试,不实际运行被测试的软件.

静态测试约可找出30~70%的逻辑 设计错误. 对需求规格说明书、软件设计说明 书、源程序做结构分析、流程图分析 、符号执行来找错。

动态测试:

通过运行软件来检验软件的动 态行为和运行结果的正确性.

动态测试的两个基本要素:被测试程序测试数据(测试用例)

四、常用软件测试工具

(1)测试工具的分类:

自动化软件测试工具:通过计算机运行测试工具自动地进行脚本测试

测试管理工具:通过数据库共享测试用例,管理软件缺陷

两者相结合提高会让软件测试效率

(2)自动化软件测试工具:提高测试效率,用软件 来代替人工输入。

适应于的场合:软件需求变化不频繁、项目 周期长、测试脚本重复使用的情况

提高执行速度,缩短测试周期,多次运行;

自动化测试只能发现15%-30%的缺陷;

软件功能测试、验收测试等不适合自动化测试;

单元测试、集成测试、负载性能测试、回归测试适合进行自动化测试;

短期项目、需求变化频繁时,不适合自动 化测试

(3)测试管理工具:通常对测试需求、测试计划、测试用例和测试实施管理,并跟踪和管理软件缺陷。

测试管理工具的测试人员、开发人员及 其他人员共享一个数据库,相互交换信息,提高回归测试效率、提升测试质量 、用例复用等。

(4)按照功能分类:

代码测试覆盖率分析器;

内存泄露检测工具;

测试数据生成器;

网络测试工具;

GUI测试工具;

负载、性能和强度测试工具。

(5)按照测试技术分类:

黑盒测试工具

功能测试工具

性能测试工具

白盒测试工具

静态测试工具

动态测试工具

测试管理工具

  1. 开源测试工具:

单元测试工具JUnit

Junit 是一个开源的测试工具

可以单独使用

也可以集成在开发环境中使用,例如,Eclipse 和NetBeans 集成了Junit

性能测试工具Jmeter

Jmeter可以模拟大量并发用户访问, 可以模拟大量并发用户访问,

测试系统的并发性能、吞吐量。

缺陷管理工具Bugzilla

Bugzilla是一款服务器软件,专注于 是一款服务器软件,专注于软件缺陷跟踪,来源于 软件缺陷跟踪,来源于Mozilla 。

Bugzilla作为一款企业级软件,为世 作为一款企业级软件,为世界各地的软件开发组织机构跟踪了上百万个缺陷。

管理软件开发中缺陷提交、修复和关闭等整个生命周期。

测试管理工具TestLink

TestLink 是一款开源测试管理工具

它提供测试规范、测试计划、执行测试、报告测试结果,还可以与软件缺陷管理工具协作。

五、软件质量评估方法

1、软件质量评估的定义:

软件质量评估技术是软件工程中非常重要的研究领域,由于软件本身的复杂性和软件技术发展迅速等原因,软件质量评估技术在理论上和技术上都很不成熟,对软件质量更科学、更客观的评估。 可以促使得到更加可靠、高效的软件。

2、软件质量评估的原则:

  1. 针对性

具体表现就是功能性与高可靠性。

  1. 可测性

即能够定量表示,可以通过数学计算、平台测试、经验统计等方法得到具体数据。

  1. 简明性

即易于被各方理解和接受。

  1. 完备性

即选择的指标应覆盖分析目标所涉及的范围。

  1. 客观性

即客观反映软件本质特征,不能因人而异。

3、注意点:

选择的评估指标不是越多越好,关键在于指标在评估中所起的作用的大小。如果评估时指标太多,不仅增加结果的复杂性,有时甚至会影响评估的客观性。

4、软件质量评估指标体系:

通常,我们在软件的测试与评估时,主要侧重于功能特征、可靠特征、易用特征和效率特征等几个方面。

A、功能性指标:是软件最重要的质量特征之一,可以细化成完备性和正确性。对软件的功能性评价主要采用定性评价方法。

a.完备性

完备性是与软件功能完整、齐全有关的软件属性。如果软件实际完成的功能少于或不符合研制任务书所规定的明确或隐含的那些功能,则不能说该软件的功能是完备的。

b.正确性

正确性是与能否得到正确或相符的结果或效果有关的软件属性。软件的正确性在很大程度上与软件模块的工程模型(直接影响辅助计算的精度与辅助决策方案的优劣)和软件编制人员的编程水平有关。

B、可靠性指标

a.可用度:可用度指软件运行后在任一随机时刻需要执行规定任务或完成规定功能时,软件处于可使用状态的概率。

b.初期故障率:初期故障率指软件在初期故障期(一般以软件交付给用户后的三个月内为初期故障期)内单位时间的故障数。

c.偶然故障率:指软件在偶然故障期(一般以软件交付给用户后的四个月以后为偶然故障期)内单位时间的故障数。

d.平均失效前时间(MTTF):指软件在失效前正常工作的平均统计时间。

e.平均失效间隔时间(MTBF):指软件在相继两次失效之间正常工作的平均统计时间。

f.缺陷密度(FD):指软件单位源代码中隐藏的缺陷数量。

g.平均失效恢复时间(MTTR):指软件失效后恢复正常工作所需的平均统计时间。

易用性指标:可以细化为易理解性、易学习性和易操作性等。这三个特征主要是针对用户而言的。对软件的易用性评价主要采用定性评价方法。

a.易理解性:与用户认识软件的逻辑概念及其应用范围所花的努力有关的软件属性。b.易学习性:与用户为学习软件应用(例如运行控制、输入、输出)所花的努力有关的软件属性。

c.易操作性:与用户为操作和运行控制所花的努力有关的软件属性。

效率特征指标

a.输出结果更新周期:软件相邻两次输出结果的间隔时间。

b.处理时间:软件完成某项功能(辅助计算或辅助决策)所用的处理时间(注意:不应包含人机交互的时间)。

c.吞吐率:单位时间软件的信息处理能力(即各种目标的处理批数)。

d.代码规模:软件源程序的行数(不包括注释),属于软件的静态属性。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

呆呆熬夜写博客.

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值