软件工程导论—软件测试(上)

简介: 软件工程导论—软件测试

文章目录


1. 软件测试基础

1.1. 软件测试的目的和准则

1.2. 软件测试方法和步骤

1.3. 测试内容

1.4. 测试阶段的信息流

2. 单元测试

3. 集成测试

3.1. 集成测试概述

3.2. 自顶向下集成

3.3. 自底向上集成

3.4. 不同集成测试策略的比较与回归测试

4. 确认测试

4.1. 确认测试概述

4.2. 确认测试的范围和软件配置复查

4.3. Alpha和Beta测试

5. 白盒测试技术

5.1. 白盒测试技术概述

5.2. 逻辑覆盖

5.3. 控制结构测试

6. 黑盒测试技术

6.1. 黑盒测试概述

6.2. 等价划分

6.3. 边界值分析

6.4. 错误推测

7. 调试

7.1. 调试概述

7.2. 调试过程和途径

8. 软件可靠性

8.1. 软件可靠性相关的几个概念

8.2. 估算平均无故障时间的方法


正文


1. 软件测试基础


1.1. 软件测试的目的和准则


测试是为了发现程序中的错误而执行程序的过程,好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案,成功的测试是发现了至今为止尚未发现的错误的测试。


一般来说,软件测试有以下几条准则:


所有测试都应该能追溯到用户需求;

应该远在测试开始之前就制定出测试计划;

把Pareto原理应用到软件测试中;

应该从“小规模”测试开始,并逐步进行“大规模”测试;

穷举测试是不可能的;

为了达到最佳的测试效果,应该由独立的第三方从事测试工作。


1.2. 软件测试方法和步骤


软件测试方法主要分为黑盒测试和白盒测试:


黑盒测试(功能测试)

把程序看作一个黑盒子,完全不考虑程序的内部结构和处理过程,而是在程序接口进行的测试;

白盒测试(结构测试)

把程序看成装在一个透明的盒子里,测试者完全知道程序的结构和处理算法,按照程序内部的逻辑测试程序,检测程序中的主要执行通路是否都能按预定要求正确工作。


黑盒测试 白盒测试
优点 适用于各阶段测试
从产品功能角度测试
容易入手生成测试数据
可构成测试数据使特定程序部分得到测试
有一定的充分性度量手段
可获较多工具支持
缺点 某些代码得不到测试
如果规格说明有误,则无法发现
不易进行充分性测试
通常不易生成测试数据
无法对未实现规格说明的部分进行测试
工作量大,通常只用于单元测试,有应用局限
性质 一种确认技术,回答"我们在构造一个正确的系统吗?" 一种验证技术,回答"我们在正确地构造一个系统吗?"


一般来说,测试的按照以下步骤进行:


模块测试(单元测试)

模块测试主要发现的往往是编码和详细设计的错误,目的是保证每个模块作为一个单元能正确运行;

子系统测试

子系统测试把经过单元测试的模块放在一起形成一个子系统来测试,着重测试模块的接口。

系统测试

把经过测试的子系统装配成一个完整的系统来测试,发现的往往是软件设计中的错误,也可能发现需求说明中的错误。不论是子系统测试还是系统测试,都兼有检测和组装两重含义,通常也称为集成测试。

验收测试(确认测试)

验收测试是在用户积极参与下进行的,而且可能主要使用实际数据(系统将来要处理的信息)把软件系统作为单一的实体进行测试进行测试,它发现的往往是系统需求说明书中的错误

平行运行

同时运行新开发出来的系统和将被它取代的旧系统,然后比较新旧两个系统的处理结果。平行运行可以在准生产环境中运行新系统而又不冒风险,同时用户能有一段熟悉新系统的时间,用户可以趁这段时间验证用户指南和使用手册之类的文档。以准生产模式对新系统进行全负荷测试,可以用测试结果验证性能指标。

详细步骤说明如下表所示:

测试阶段 主要依据 测试人员 测试方法 测试内容
单元测试 系统设计文档 开发小组 白盒测试 接口测试
路径测试
子系统测试 系统设计文档
需求文档
独立测试小组 白盒测试
黑盒测试
接口测试
路径测试
功能测试
性能测试
系统测试 需求文档 独立测试小组 黑盒测试 功能测试、健壮性测试
性能测试、用户界面测试
安全性测试、压力测试
可靠性测试、安装/卸载测试
验收测试 需求文档 用户 黑盒测试 功能测试、健壮性测试
性能测试、用户界面测试
安全性测试、压力测试
可靠性测试、安装/卸载测试



1.3. 测试内容


接口测试

每个接口可能有多个输入参数,每个参数有 “典型值”、“边界值”、“异常值”之分,根据接口的定义,可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。 同时要观察是否有程序语句从来没有被执行过,特别留意函数体内的错误处理程序块。

路径测试

路径测试就是测试程序的流程路径,想遍历全部路径几乎是不可能的,不测试或者胡乱找几条路径测试却又不行,输入与对应的输出之间的路径是唯一的。由于接口测试时的输入要有代表性的,因此相应的路径也具有代表性,制定的路径测试检查表应该包括:数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理。

功能测试

功能测试的基本方法是构造一些合理输入(在需求范围之内),检查输出是否与期望相同。有两种比较好的测试方法:等价划分法和边界值分析法,等价划分是指把输入空间划分为几个“等价区间”,在每个“等价区间”中只需要测试一个典型值就可以了;边界值测试法是对等价划分法的补充。除了典型值外还要用边界值作为测试用例。

健壮性测试

健壮性是指在异常情况下,软件能正常运行的能力。它有两层含义:(1)容错能力,容错性测试通常构造一些不合理的输入来引诱软件出错;(2)恢复能力,恢复测试重点考察系统能否重新运行、有无重要的数据丢失、是否毁坏了其它相关的软件硬件。

性能测试

性能测试即测试软件处理事务的速度,一是为了检验性能是否符合需求,二是为了得到某些性能数据供人们参考,有时人们关心测试的“绝对值” ,有时关心测试的“相对值” 。

用户界面测试

绝大多数软件拥有图形用户界面,图形用户界面的测试重点是正确性、易用性和视觉效果,在评价易用性和视觉效果时,主观性非常强,应当考虑多个人的观点。

信息安全测试

信息安全性是指防止系统被非法入侵的能力,既属于技术问题又属于管理问题。主要有如下步骤:(1)为非法入侵设立目标、(2)邀请一些人扮演黑客,让他们想尽办法入侵系统,实现“目标”、(3)如果有人成功了,请他详述入侵的过程。

压力测试

压力测试也叫负荷测试,即获取系统能正常运行的极限状态。 主要任务是:构造正确的输入,使劲折腾系统却让它刚好不瘫痪。 压力测试的一个变种是敏感测试,敏感测试目的是发现什么样的输入可能会引发不稳定现象。

可靠性测试

可靠性是指在一定的环境下、给定的时间内、系统不发生故障的概率。软件可靠性测试可能会花费很长时间。 比较实用的办法是,让用户使用该系统,记录每一次发生故障的时刻。计算出相邻故障的时间间隔,注意要去掉非工作时间。然后统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。

安装/卸载测试

目前市面上有非常流行的、专门制作安装/卸载程序的一些工具,如Install Shelled。主要的测试工作是:(1)至少在标准配置和最低配置两种环境下测试;(2)如果有安装界面,应当尝试各种选项,如选择“全部”、“部分”、“升级”等。


1.4. 测试阶段的信息流


测试阶段输入的信息有两类: 软件配置和测试配置,其中软件配置包括需求说明书、设计说明书和源程序清单等,测试配置包括测试计划和测试方案。

13.png


2. 单元测试


单元测试和编码属于软件过程的同一个阶段,它应用人工测试和计算机测试这样两种不同类型的测试方法对模块进行集中检测。单元测试主要使用白盒测试技术,对多个模块的测试可以并行地进行。


人工测试的方法由审查小组进行,其主要使用白盒测试技术进行代码审查,审查的重点是模块接口、局部数据结构、重要的执行通路、出错处理通路和边界条件,一般来说可以查出30%~70%的逻辑设计错误和编码错误,这可以减少系统验证的总工作量。


审查小组一般由一名审查组长,带领程序的设计人员、编码人员和测试人员共同进行。


计算机测试的方法必须为每个单元测试开发驱动程序和(或)存根程序,驱动程序是一个“主程序”,它接收测试数据,传送给被测试的模块,并且输出有关的结果。


存根程序代替被测试的模块所调用的模块。它使用被它代替的模块的接口,可能做最少量的数据操作,输出对入口的检验或操作结果,并且把控制归还给调用它的模块。


3. 集成测试


3.1. 集成测试概述


集成测试是测试和组装软件的系统化技术,主要目标是发现与接口有关的问题。


由模块组装成程序时有两种方法:


非渐增式测试方法

先分别测试每个模块,再把所有模块按设计要求放在一起结合成所要的程序。非渐增式测试一下子把所有模块放在一起,并把庞大的程序作为一个整体来测试,测试者面对的情况十分复杂,在庞大的程序中想要诊断定位一个错误是非常困难的,改正错误更是极端困难,而且一旦改正一个错误之后,马上又会遇到新的错误。

渐增式测试方法

把下一个要测试的模块同已经测试好的那些模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试,每次增加一个模块,实际上同时完成单元测试和集成测试。把程序划分成小段来构造和测试,在这个过程中比较容易定位和改正错误;

而渐增方式也有两种集成策略:自顶向下集成和自底向上集成,下面分别对它们进行介绍


3.2. 自顶向下集成


从主控制模块开始,沿着程序的控制层次向下移动,逐渐把各个模块结合起来,就是自顶向下的集成。

14.png

在把附属于主控制模块的那些模块组装到程序结构中去时,可以使用深度优先的策略或者使用宽度优先的策略。


所谓深度优先,就是先组装在软件结构的一条主控制通路上的所有模块;宽度优先就是沿软件结构水平地移动,把处于同一个控制层次上的所有模块组装起来。

15.png

然后按照下述4个步骤完成把模块结合进软件结构的过程:


对主控制模块进行测试,测试时用存根程序代替所有直接附属于主控制模块的模块;

根据选定的结合策略(深度优先或宽度优先),每次用一个实际模块代换一个存根程序(新结合进来的模块往往又需要新的存根程序);

在结合进一个模块的同时进行测试;

为了保证加入模块没有引进新的错误,可能需要进行回归测试(即,全部或部分地重复以前做过的测试);

不断地重复2~4步,直到构造起完整的软件结构为止。

自顶向下的测试能够在测试的早期对主要的控制或关键的抉择进行检验,如果选择深度优先的结合方法,可以在早期实现软件的一个完整的功能并且验证这个功能。但是由于存根程序代替了低层次的模块,在软件结构中没有重要的数据自下往上流。


3.3. 自底向上集成


16.png

用下述步骤可以实现自底向上的结合策略:


把低层模块组合成实现某个特定的软件子功能的族;

写一个驱动程序(用于测试的控制程序),协调测试数据的输入和输出;

对由模块组成的子功能族进行测试;

去掉驱动程序,沿软件结构自下向上移动,把子功能族组合起来形成更大的子功能族。

不断重复2~4步,直到构造起完整的软件结构为止。

17.png


3.4. 不同集成测试策略的比较与回归测试


集成测试策略 优点 缺点
非渐增式 没有错误隔离手段
主要设计错误发现迟
潜在可重用代码测试不充分
需要驱动程序和存根程序
自顶向下 具有错误隔离手段
主要设计错误发现早
不需要驱动程序
潜在可重用代码测试不充分
需要存根程序
自底向上 具有错误隔离手段
潜在可重用代码能充分测试
不需要存根程序
主要设计错误发现迟
需要驱动程序
混合 具有错误隔离手段
主要设计错误发现早
潜在可重用代码能充分测试
较少


所谓混合集成测试策略,主要有两种:


改进的自顶向下测试方法

基本上使用自顶向下的测试方法,但是在早期使用自底向上的方法测试软件中的少数关键模块。该策略能在测试的早期发现关键模块中的错误;测试关键模块时需要驱动程序。

混合法

对软件结构中较上层使用的自顶向下方法与对软件结构中较下层使用的自底向上方法相结合,该策略兼有两种方法的优缺点,当被测试的软件中关键模块比较多时,这种混合法可能是最好的折衷方法。

每一轮集成测试后都要尽可能的进行回归测试,用于保证由于调试或其他原因引起的变化,不会导致非预期的软件行为或额外错误的测试活动,可以通过重新执行全部测试用例的一个子集人工地进行,也可以使用自动化的捕获回放工具自动进行。


4. 确认测试


4.1. 确认测试概述

确认测试也称为验收测试,它的目标是验证软件的有效性(即软件的功能和性能是否符合用户预期)。


需求分析阶段产生的软件需求规格说明书,准确地描述了用户对软件的合理预期,因此是软件有效性的标准,也是进行确认测试的基础。


4.2. 确认测试的范围和软件配置复查

确认测试必须有用户积极参与,或者以用户为主进行,使用用户界面输入测试数据并且分析评价测试的输出结果,在验收之前通常要由开发单位对用户进行培训,一般来说确认测试分为Alpha和Beta测试。


确认测试的一个重要内容是复查软件配置。复查的目的是保证软件配置的所有成分都齐全,质量符合要求,文档与程序完全一致,具有完成软件维护所必须的细节。


4.3. Alpha和Beta测试


Alpha测试就是由开发者“指导”用户在开发环境下进行的测试。Alpha测试是在受控的环境中进行的。


Beta测试就是由软件的最终用户们在一个或多个实际生产环境下进行的测试。开发者通常不在Beta测试的现场,因此,Beta测试是软件在开发者不能控制的环境中的“真实”应用。

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
相关文章
|
2月前
|
安全 测试技术 持续交付
【软件工程】实用测试手册:软件工程中各种测试类型一览
【软件工程】实用测试手册:软件工程中各种测试类型一览
49 0
|
4月前
|
安全 测试技术 持续交付
软件工程之测试阶段
软件工程之测试阶段
68 0
|
7月前
|
存储 数据管理 人机交互
【软件工程】测试六
【软件工程】测试六
100 0
|
2月前
|
Java 测试技术 持续交付
【软件工程】单元测试:构建坚固软件基石的不可或缺一环
【软件工程】单元测试:构建坚固软件基石的不可或缺一环
21 0
|
4月前
|
安全 测试技术 持续交付
软件工程之测试
软件工程之测试
54 0
|
7月前
|
监控 项目管理 调度
【软件工程】测试十
【软件工程】测试十
36 0
|
7月前
|
敏捷开发 安全 程序员
【软件工程】测试七
【软件工程】测试七
50 0
|
7月前
【软件工程】测试九
【软件工程】测试九
44 0
|
7月前
|
监控 测试技术
【软件工程】测试五
【软件工程】测试五
82 0
|
7月前
|
算法 程序员 测试技术
【软件工程】测试四
【软件工程】测试四
140 0

热门文章

最新文章