haihongyuan.com
海量文库 文档专家
全站搜索:
您现在的位置:首页 > 小学教育 > 小学英语小学英语

软件建模考试复习题

发布时间:2014-07-11 11:46:25  

软件测试复习题

一、判断题

1.软件测试的目的是尽可能多的找出软件的缺陷。(Y)

2.Beta 测试是验收测试的一种。(Y)

3.验收测试是由最终用户来实施的。(N)

上面说到了验收测试的目的和目标,所以验收测试也可是是软件生产的企业内部人员来实施。例如产品经理。

当软件以项目的形式出现,那么验收测试由最终用户来实施的情况是比较长见的。但是对于产品形式的软件,生产企业内部的验收测试会更多。

4.项目立项前测试人员不需要提交任何工件。(Y)

5.单元测试能发现约80%的软件缺陷。(Y)

6.代码评审是检查源代码是否达到模块设计的要求。(N)

代码审查是一种静态技术,从这个意义上说代码复查是需要和其他的一些动态测试技术配合才能检查代码是否符合设计的要求。

7.自底向上集成需要测试员编写驱动程序。(Y)

8.负载测试是验证要检验的系统的能力最高能达到什么程度。(N)

负载测试(Load testing),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征。例如,响应时间、事务处理速率和其他与时间相关的方面。

9.测试人员要坚持原则,缺陷未修复完坚决不予通过。(N)

软件配置管理应用于整个软件工程过程。

10.代码评审员一般由测试员担任。(N)

11.我们可以人为的使得软件不存在配置问题。(N)

12.集成测试计划在需求分析阶段末提交。(N)

二、选择

1.软件验收测试的合格通过准则是:(ABCD)

A. 软件需求分析说明书中定义的所有功能已全部实现,性能指标全部达到要求。

B. 所有测试项没有残余一级、二级和三级错误。

C. 立项审批表、需求分析文档、设计文档和编码实现一致。

D. 验收测试工件齐全。

2.软件测试计划评审会需要哪些人员参加?(ABCD)

A.项目经理

B.SQA 负责人

C.配置负责人

D.测试组

3.下列关于alpha 测试的描述中正确的是:(AD)

A.alpha 测试需要用户代表参加

B.alpha 测试不需要用户代表参加

C.alpha 测试是系统测试的一种

D.alpha 测试是验收测试的一种

4.测试设计员的职责有:(BC)

A.制定测试计划

B.设计测试用例

C.设计测试过程、脚本

D.评估测试活动

5.软件实施活动的进入准则是:(ABC)

A.需求工件已经被基线化

B.详细设计工件已经被基线化

C.构架工件已经被基线化

D.项目阶段成果已经被基线化

三、填空

1.

2.请列举三种以上系统测试的策略有:功能测试,性能测试,可靠性测试,负载测试,易用性测试,强度测试,安全测试,配置测试,安装测试,卸载测试,文挡测试,故障恢复测试,界面测试,容量测试,兼容性测试,分布测试,可用性测试,(答对其中任意三个即得分)

3.

4.

四、简答题

1.如何区别阶段评审与同行评审?(答对其中3条即得满分)

同行评审目的:发现小规模工作产品的错误,只要是找错误;

阶段评审目的:评审模块 阶段作品的正确性 可行性 及完整性

同行评审人数:3-7人 人员必须经过同行评审会议的培训,由SQA指导

阶段评审人数:5人左右 评审人必须是专家 具有系统评审资格

同行评审内容:内容小 一般文档

阶段评审内容: 内容多,主要看重点

同行评审时间:一小部分工作产品完成

阶段评审时间: 通常是设置在关键路径的时间点上!

2 怎么做好文档测试

仔细阅读,跟随每个步骤,检查每个图形,尝试每个示例。P142

检查文档的编写是否满足文档编写的目的

内容是否齐全,正确

内容是否完善

3 白盒测试有几种方法

总体上分为静态方法和动态方法两大类。

静态:关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义

动态:语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

4.Alpha测试与beta的区别

Alpha测试 在系统开发接近完成时对应用系统的测试;测试后仍然会有少量的设计变更。这种测试一般由最终用户或其它人员完成,不能由程序或测试员完成。

Beta测试 当开发和测试根本完成时所做的测试,最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其它人员完成,不能由程序员或测试员完成。

5.比较负载测试,容量测试和强度测试的区别

负载测试:在一定的工作负荷下,系统的负荷及响应时间。

强度测试:在一定的负荷条件下,在较长时间跨度内的系统连续运行给系统性能所造成的影响。

容量测试:容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等),系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运 行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测 试是面向数据的,并且它的目的是显示系统可以处理目标内确定的数据容量。

6.测试结束的标准是什么?

用例全部测试。

覆盖率达到标准。

缺陷率达到标准。

标记是否正确

其他指标达到质量标准 描述软件测试活动的生命周期?

测试周期分为计划、设计、实现、执行、总结。其中:

计划:对整个测试周期中所有活动进行规划,估计工作量、风险,安排人力物力资源,安排进度等;

设计:完成测试方案,从技术层面上对测试进行规划;

实现:进行测试用例和测试规程设计;

执行:根据前期完成的计划、方案、用例、规程等文档,执行测试用例。

总结:记录测试结果,进行测试分析,完成测试报告。

8. 软件的缺陷等级应如何划分?

A类—严重错误,包括以下各种错误: 1. 由于程序所引起的死机,非法退出 2. 死循环 3. 数据库发生死锁 4. 因错误操作导致的程序中断 5. 功能错误 6. 与数据库连接错误 7. 数据通讯错误

B类—较严重错误,包括以下各种错误: 1. 程序错误 2. 程序接口错误 3. 数据库的表、业务规则、缺省值未加完整性等约束条件

C类—一般性错误,包括以下各种错误: 1. 操作界面错误(包括数据窗口内列名定义、含义是否一致) 2. 打印内容、格式错误 3. 简单的输入限制未放在前台进行控制 4. 删除操作未给出提示 5. 数据库表中有过多的空字段

D类—较小错误,包括以下各种错误: 1. 界面不规范 2. 辅助说明描述不清楚 3. 输入输出不规范 4. 长操作未给用户提示 5. 提示窗口文字未采用行业术语 6. 可输入区域和只读区域没有明显的区分标志

E类—测试建议

大体是这样,还会有一些变动,同时最后一道题出的是画流程图和控制图的题,等腰三角形那个

9. 测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?

软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软

件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。 测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试策略和测试方法(最好是能先评审)

10. 简述“5W”规则的含义,明确内容与过程

“5W”规则指的是“What (做什么)”、“Why (为什么做)”、“When (何时做)”、“Where (在哪里)”、“How (如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理 解测试的目的(Why ),明确测试的范围和内容(What ),确定测试的开始和结束日期(When ), 指出测试的方法和工具(How ),给出测试文档和软件的存放位置(Where )。

11. 简述四款主流测试工具的测试流程

主流测试工具的测试流程

========winrunner

1) 启动时选择要加载的插件

2) 进行一些设置(如录制模式等)

3) 识别应用程序的 GUI,即创建map(就是学习被测试软件的界面)

4) 建立测试脚本(录制及编写)

5) 对脚本除错及调试(保证能够运行完)

6) 插入各种检查点(图片,文字,控件等)

7) 在新版应用程序中执行测试脚本

8) 分析结果,回报缺陷

=========quicktestpro========

1) 准备录制

打开你要对其进行测试的应用程序,并检查QuickTest 中的各项设置是否适合当前的要求。

2) 进行录制

打开QuickTest 的录制功能,按测试用例中的描述,操作被测试应用程序。

3) 编辑测试脚本

通过加入检测点、参数化测试,以及添加分支、循环等控制语句,来增强测试脚本的功能,使将来的回归测试真正能够自动化。

4) 调试脚本

调试脚本,检查脚本是否存在错误。

5) 在回归测试中运行测试

在对应用程序的回归测试中,通过QuickTest 回放对应用程序的操作,检验软件正确性,实 现测试的自动化进行。

6) 分析结果,报告问题查看QuickTest 记录的运行结果,记录问题,报告测试结果。 ====TestDirect============

安装好后,先进入站点管理

1) 创建域及工程

2) 添加用户

3) 编辑 licenses 及本服务器

4) 编辑数据库

5) 选择新建的工程进行定制(列表,用户,组,版本等)

6) 在 require 中增加需求

7) 把需求转化为 plan

8) 在testlab 中由计划新建测试具体用例与执行

9) 发现bug,在defect 中提交bug

(每一部分都可以相对独立地使用)

======loadrunner

1) 制定负载测试计划

(分析应用程序, 确定测试目标,计划怎样执行LoadRunner)

2) 开发测试脚本

(录制基本的用户脚本,完善测试脚本)

3) 创建运行场景

(选择场景类型为Manual Scenario,选择场景类型,理解各种类型,场景的类型转化)

4) 运行测试

5) 监视场景

(MEMORY 相关,PROCESSOR 相关,网络吞量以及带宽,磁盘相关,WEB 应用程序 , IIS5.0,SQL SERVER,NETWORK DELAY 等)

6) 分析测试结果

(分析实时监视图表,分析事务的响应时间,分解页面,确定 WEBSERVER问题,其他有用的 功能)

12.基于WEB 信息管理系统测试时应考虑的因素有哪些?

一、功能测试

1、链接测试

2、表单测试

3、Cookies 测试

4、设计语言测试

5、数据库测试

二、性能测试

1、连接速度测试

2、负载测试

3、压力测试

三、可用性测试

1、导航测试

2、图形测试

3、内容测试

4、整体界面测试

四、客户端兼容性测试

1、平台测试

2、浏览器测试

五、安全性测试

13.软件本地化测试比功能测试都有哪些方面需要注意?

软件本地化测试的测试策略:1.本地化软件要在各种本地化操作系统上安装并测试。2.源语言软件安装在另一台相同源语言操作系统上,作为对比测试。3.重点测试因本地化引起的软 件的功能和软件界面的错误。4.测试本地化软件的翻译质量。5.手工测试和自动测试相结合。

14.软件测试项目从什么时候开始,?为什么?

软件测试应该在需求分析阶段就介入,因为测试的对象不仅仅是程序编码,应该对软件开发过程中产生的所有产品都测试,并且软件缺陷存在放大趋势.缺陷发现得越晚,修复它所花费的成本就越大.

15.简述一下缺陷的生命周期

软件缺陷的生命周期指的是一个软件缺陷被发现、报告到这个缺陷被修复、验证直至最后关闭的完整过程。

简单的软件缺陷生命周期:

1)发现——打开:测试人员找到软件缺陷并将软件缺陷提交给开发人员;

2)打开——修复:开发人员再现、修复缺陷,然后提交测试人员去验证;

3)修复——关闭:测试人员验证修复过的软件,关闭已不存在的缺陷。

但是这是一种理想的状态,在实际的工作中是很难有这样的顺利的,需要考虑的各种情况都还是非常多的。

16.文件格式系统有哪几种类型?分别说说 win95、win98、winMe、w2k、winNT、winXP 分别支持那些文件系统。

FAT(File Allocation Table)是“文件分配表”的意思。

对我们来说,它的意义在于对硬盘分区的管理。FAT16、FAT32、NTFS 是目前最常见的三

种文件系统。

Win95: FAT16 和FAT32

Win98: FAT16,FAT32

winMe:FAT16,FAT32

w2k: FAT(FAT16),FAT32,NTFS

winNT: FAT16/FAT32/NTFS

winXP:FAT16,FAT32,NTFS

17.分别填入一个语句,完成下面的函数,通过递归计算数组a[100]的前n 个数之和。 Int sum ( int a[],int n )

{

if (n>0) return_____ sum(a[], n--) + a[n] _____;

else return_____ a[n]____; // 其实就是 a[0]

}

//一直递归到0,然后逐级返回,实现累加

18.写出你所知道的3 种常用的排序方法,并用其中一种方法设计出程序为数组a[100]排序。

常用的排序算法有很多:

冒泡,快速排序,直接插入,希尔排序,选择排序,堆排序,归并排序! 就举冒泡排序(c++):

void bubblesort()

{

for (i = 1; i < max; i ++)

{

for (j = max - 1; j >= i; j --)

if (a[j + 1] < a[j]) //小则交换

{

a[0] = a[j + 1];

a[j + 1] = a[j];

a[j] = a[0];

}

}

}

19.我现在有个程序,发现在WIN98 上运行得很慢,怎么判别是程序存在问题还是软硬件系统存在问题?

可能是病毒或者恶意程序,如果是程序运行慢那肯定是软件问题,

硬件问题主要表现在点不亮机子和报警.

解决方法,安装杀毒软件和优化软件.

根据软件可靠性的约定,与财务有关的关键软件所允许的故障密度为

A. 0.01~1 个/每千行

软件的可靠性

已投入运用的软件的故障密度:

与生命攸关的关键软件:0.01~1 个/每千行

与财务有关的关键软件:1~10 个/每千行

微软优秀的软件开发人员:3~6 个/每千行

注:Vista系统含5500万行代码

XP系统含4500万行代码

已闲置不用的Wind 98仍有很多错误代码

什么是软件缺陷?

软件未达到产品说明书中已经标明的功能;

软件出现了产品说明书中指明不会出现的错误;

软件未达到产品说明书中虽未指出但应当达到的目标;

软件功能超出了产品说明书中指出的范围;

软件测试人员认为软件难以理解、不易使用,或者最终用户认为该软件使用效果不良。 如何进行软件测试?

软件缺陷严重性的级别

软件缺陷的产生

★需求解释有误

★需求定义有误

★需求记录有误

★设计说明有误

★编码说明有误

★程序代码有误

★其他如数据输

入有误等

软件缺陷的修复费用

缺陷发现或解决得越迟,成本越高,几乎呈指数增长

测试人员座右铭:尽早地、不断地测试!

软件测试的发展

软件测试的现状

相对目前软件工程的发展而言,软件测试仍然薄弱;

软件测试重要性的认识有待加强;

国内的软件测试工作起步晚,测试的管理与技术落后,亟须提高。

软件测试的定义

G.J. Myers提出的三个重要观点:

程序测试是为了发现错误而执行程序的过程;

好的测试用例是发现迄今为止尚未发现的错误;

成功的测试执行是发现了至今为止尚未发现的错误的测 试执行。

优点:明确指出软件测试是为了寻找错误,而不是证明无错。

局限性:将测试定义规定的范围限制得过于狭窄,测试工作似乎只有在编码完成以后才能开始。

软件测试的对象

需求分析说明书

概要设计说明书

详细设计说明书

源代码

★软件测试不仅仅是对程序的测试,而是贯穿于软件定义和开发的整个过程

软件测试的关键问题

1. 测试由谁执行?

2. 测试什么?

3. 什么时候进行测试?

4. 怎样进行测试?

第一章

软件测试的目的

软件测试的原则

(1)测试的目的是为了证伪而不是证真。

(2)测试应当有重点。

(3)事先定义好产品的质量标准,确定测试用例预期、输出结果。

(4)软件项目一启动,软件测试也就开始,而不是等到程序写完才开始进行测试。

(5)穷举测试是不可能的。

(6)第三方进行测试会更客观,更有效。

(7)软件测试计划是做好软件测试工作的前提。

(8)测试用例是设计出来的,不是写出来的。

(9)对发现错误较多的程序段,应进行更深入的测试。

(10)重视文档,妥善保存一切测试过程文档。

测试的不可穷尽

测试在开发各个阶段的任务

软件测试的信息流

软件测试的停止标准

1. 测试超过了预定时间;

2. 执行了所有测试用例,但未发现故障;

3. 使用特定的测试用例设计方法判断是否停止;

4. 正面指出测试停止的要求,如发现并修改70个缺陷;

5. 根据单位时间内查出故障的数量决定是否停止。

测 试 过 程

单元测试

集成测试

系统测试

验收测试

单元测试

单元测试也称模块测试,测试的对象是软件的最小单元——程序模块,如函数或子函数,菜单或显示界面

单元测试的目的是检测程序模块中的错误故障,着力解决以下五个方面的问题: 模块接口测试

模块局部数据结构测试

覆盖测试

出错处理检测

边界条件测试

集 成 测 试

软件实现一般是渐增式的,从单元到整个系统通常要经历多次集成,每次都要进行相应的集成测试。

刚开始集成时由于规模较小,主要以白盒测试为主,不但要检测实现集成功能的那部分新增代码,有时甚至还要检测已测试过的单元的内部。

随着集成规模的壮大,离目标系统越来越近,此时要以黑盒测试为主,还可以提前做系统测试测试阶段的部分工作,如子系统的功能测试、性能测试等。

系 统 测 试

系统测试是针对系统中各组成部分进行的综合测试,其主要目标不是要找出软件的缺陷,而是要证明系统的性能。

系统测试的主要内容包括:功能测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/卸载测试等。

验收测试

验收测试是把产品交付用户之前进行的最后一次质量检验活动,解决软件产品是否符合预期的各项要求,用户是否接受等问题。

验收的主要任务是:明确验收测试通过的标准;确定验收计划和方式,并对其进行评审;确定测试结果的分析方法;设计验收测试的用例;执行验收测试,分析验收结果,决定是否通过验收。

软件产品的组成

客户需求

产品说明书

进度表

设计文档

测试文档

软件产品的其他组成部分

如帮助文件、用户手册等

软件开发人员组成

项目经理

业务分析人员

架构师

数据设计人员

开发人员

测试人员

软件开发模式

大棒模式

边写边改模式

瀑布模式

快速原型模式

螺旋模式

V模式

双V模式

大 棒 模 式

大棒模式是指软件项目组成员的所有精力都花在开发软件和编写代码上的一种软件开发模式,测试工作通常都在开发任务完成以后才进行。

优点:简单,计划、进度安排和正规开发过程几乎没有。

缺点:非工程化的。

边写边改模式

边写边改模式是项目小组在未刻意采用其它开发模式时常用的一种开发模式,在只有粗略想法时即进行简单的设计,然后开始长期的反复编写、测试和修复的过程。

此模式考虑到了软件产品的要求,是在大棒模式基础上的一个进步,适合用在快速制作且用完就扔的小项目上。

瀑布模式

瀑布模式

模式特点:将软件生命周期的各项活动规定为按照固定顺序相连的若干个阶段性工作,形成瀑布流水,最终得到软件。

优点:易于理解;调研开发呈阶段性;强调早期计划及需求调查;确定何时能够交付产品及何时进行评审与测试。

缺点:需求调查分析只进行一次,不能适应需求的变化;顺序的开发流程,使得开发中的经验教训不能反馈到该项目的开发中去;不能反映出软件开发过程的反复性与迭代性;没有包含任何类型的风险评估;开发中出现的问题直到开发后期才能显露,因此失去了及早纠正的机会。

快速原型模式

快速原型模式首先构造一个功能简单的原型系统,然后通过对原型系统逐步求精,不断扩充完善得到最终的软件系统。这个模型可在运行中被检查、测试、修改,直到它的性能达到用户需求为止。

优点:支持用户,使用户在系统生存周期的设计阶段起到积极的作用;能减少系统开发的风险,特别是在大型项目的开发中,对项目需求的分析难以一次完成,应用此法效果明显。 螺旋模式

螺旋模式

螺旋模式的主要思想:在开始时不必详细定义所有的细节,而是从小开始,定义重要功能,尽量实现,接受客户反馈,进入下一阶段并重复上述过程,直到获得最终产品。

优点:产品的来龙去脉清楚、成本相对较低,测试从最初就参与各项工作。

缺点:需要投入更多的精力以细致地管理

V模式

★优点:对测试活动进行了细分

双V模式

软件测试过程

测试计划

测试需求分析

测试设计

测试规程实现

测试执行

总结生成报告

Infosys公司

校园招聘要求:

良好的语言交流能力(包括外语的应用);

快速的学习能力(Quick Learning);

扎实的计算机理论知识(编程能力无需很高);

学历本科以上,专科要求极为优秀。

测试人员要求:

语言沟通和处事能力好,灵活,愿接受新事物,Open;

业务精通,技术(即编码能力)可以不似编程人员;

在岗人员每年参加公司内部的业务&技术培训;

对员工有职业规划。

初级—工程师—分析员—Team Leader—测试经理—高级经理—部门经理

执行—设计用例—做测试计划和策略—做需求分析(面向用户)

待遇:接近或稍少于开发人员

人员比例:测试人员1:2开发人员;测试中男1:1.2女

推荐用书

原著:Ron Patton,Software Testing

译者:周予滨,姚静,《软件测试》机械工业出版社

总体评价:目前国内测试新手入门的经典教材

作者简介:具有15年软件测试和软件质量保证的工作经验,曾就职于德州仪器公司、西门子公司和微软公司。他从事的项目涉及任务关键型工厂自动化生产设备、多媒体开发工具、儿童娱乐和教育光盘、计算机外设及电动Barney玩偶。他现在是一个独立的软件咨询师,还是美国红十字会西雅图区的志愿者后勤部长。

推荐用书

The Art of Software Testing,Myers著

《软件测试的/之艺术》

《软件测试技术概论》

上海艾微软件技术有限公司,

古乐,史九林著

清华大学出版社

Any Questions

第二章

第二章 软件测试方法与过程

决定测试次数的主要因素

系统的目的

潜在的用户数量

信息的价值

开发机构

测试的时机

第二章 软件测试方法与过程

软件测试方法

静态测试和动态测试

黑盒测试和白盒测试

人工测试和自动化测试

人工测试是人为测试和手工测试的统称。

人为测试的主要方法有桌前检查 (desk checking) ,代码审查( code review )和走查( walkthrough )。经验表明,使用这种方法能够有效地发现 30% 到 70% 的逻辑设计和编码错误。

手工测试指的是在测试过程中,按测试计划一步一步执行程序,得出测试结果并进行分析的测试行为。

自动化测试指的是利用测试工具来执行测试,并进行测试结果分析的测试行为。

#include<stdio.h>

max(float x, float y)

{

float z;

z = x>y? x:y;

return(z);

}

main()

{

float a, b;

int c;

scanf(―%f, %f ‖, &a, &b);

c = max(a, b);

printf(―Max is %d\n‖, c);

}

第二章 软件测试方法与过程

软件测试阶段

需求分析说明书审查

系统和程序设计审查

单元测试

集成测试

确认测试

系统测试

验收测试

第二章 软件测试方法与过程

单元测试

什么是单元?

一个函数或子函数

类或类内成员函数

最小菜单

什么是单元测试?

单元测试是对软件基本组成单元进行测试,主要是为了发现单元内部可能存在的各种错误和不足

主要工作分为两个步骤:人工静态检查和动态执行跟踪

一般由开发人员进行

单元测试主要任务

模块接口测试

局部数据结构测试

路径测试

错误处理测试

边界测试

模块接口测试

调用本模块的输入参数是否正确

本模块调用子模块时传出的参数是否正确

全局变量的定义在各模块中是否一致

是否修改了只做输入用的形式参数

文件属性是否正确

Open与Close语句是否正确

缓冲区容量与记录长度是否匹配

在进行读写操作之前是否打开了文件

在结束文件处理时是否关闭了文件

正文书写/输入错误

I/O错误是否检查并做了处理

局部数据结构测试

不正确或不一致的数据类型说明

使用尚未赋值或尚未初始化的变量

错误的初始值或错误的默认值

变量名拼写错误或书写错误

不一致的数据类型

上溢、下溢或地址异常

路径测试

选择适当的测试用例,对模块中重要的执行路径进行测试

设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误 对基本路径和循环进行测试可以发现大量的路径错误

错误处理测试

对错误处理的测试设计

不输入数据,观察应用程序是否提供默认值或产生一个错误消息

输入无效数字数据,如负数或字母数字串

输入任何被认为是非法的数据类型格式

尝试不常用的数据组合

确保使用零值

输入超过或者短于要求长度的数据

边界测试

注意数据流、控制流中正好等于、大于或小于边界值时出错的可能性,对边界值仔细设计测试用例,认真加以测试。

桩 和 驱 动

int max()

{

int a=funct1();

int b=funct2();

if (a>b)

return a;

else

return b;

}

单元测试误区

单元测试的进行

依据详细设计说明书和源程序清单,了解该模块的I/O条件和模块的逻辑结构,主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理的和不合理的输入,都能鉴别和响应。

第二章 软件测试方法与过程

集成测试

集成测试是在单元测试的基础上,将所有模块按照概要设计要求组装成为子系统或系统所进行的测试

集成测试关注的重点

模块接口的数据交换

各子功能组合起来能否达到预期要求的功能

模块间是否有不利影响

全局数据结构

单个模块的误差是否会累积放大

集 成 方 式

一次性集成测试模式:一次性把所有模块组装在一起进行测试,会导致对错误的定位和纠正非常困难。

增量式集成测试模式:集成是逐步渐增的,将可能出现的差错分散暴露出来,易于对错误进行定位和纠正,且一些模块在多次集成中得到反复检测,可取得较好的测试结果。 集成方法

自顶向下的两种集成方式

深度优先 广度优先

A+B A+B

A+B+E A+B+C

A+B+E+H A+B+C+D

A+B+E+H+L A+B+C+D+E

…… A+B+C+D+E+F

……

混 合 集 成

在实际测试中,应将不同集成模式有机结合起来,采用并行的自顶向下、自底向上的混合集成方式,采取持续集成的策略。

持续集成有助于尽早发现缺陷,避免集成阶段突然涌现大量缺陷,减少消除缺陷的消耗时间,提高软件开发的质量与效率

回 归 测 试

每当软件增加了新的功能,或者软件中的缺陷被修正,这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用,不仅要对内容进行测试,还要重复进行过去已经进行过的测试,以证明修改没有引起未曾预料的后果,或证明修改后的软件仍能满足具体的要求,这就是回归测试。

回归测试是重复性较多的活动,容易使测试者感到疲劳和厌倦,可以使用自动化测试工具提高测试效率。

回归测试的一些策略

理想情况下,软件每进行一次改动,就需要把测试工作从头回归一次,但在现实中,往往需要凭借经验来确定何时回归及回归的程度如何。例如,某软件公司对回归测试的做法如下:

每两周进行一次完整的回归测试;

当修复的缺陷数累计到50个时,进行一次完整的回归测试;

在产品递交用户前5个工作日进行一次完整的回归测试。

第二章 软件测试方法与过程

确认测试

有效性测试:在模拟的环境下,运用黑盒测试方法,验证被测软件是否满足需求规格说明书的要求。

软件配置复查:保证软件配置的所有成分都齐全,各方面的质量都符合要求,具有维护阶段所必需的细节,而且已经编排好分类的目录。

第二章 软件测试方法与过程

系统测试

什么是系统测试?

系统测试是将集成好的软件系统,作为基于整个计算机系统的一个元素,与计算机硬件、外设、支持软件、数据等其它系统元素结合在一起,在实际运行(使用)环境下所进行的一系列测试活动。

系统测试的目的

通过与系统的需求定义比较,检查软件是否存在与系统定义不符合或与之矛盾的地方,以验证软件系统的功能和性能等满足其规约所指定的要求。

性能测试是要检查系统是否满足在需求说明书中规定的性能,通常对软件性能的检测表现在以下几个方面:响应时间、吞吐量、辅助存储区,例如缓冲区,工作区的大小等、处理精度,等等。

影响系统性能的因素很多,有时候是因为软件设计的原因引起的,例如使用了未经优化的算法,也有时候是因为硬件、网络的原因引起的,如当多人同时在线时,软件的响应速度会变慢,会使该产品失去用户,哪怕它的创意再好。

需重点考虑进行性能测试的情况

软件中某个模块涉及复杂的计算,特别是一些基于人工智能的分析

涉及大量数据的读写、通信

涉及大数据量的数据检索

具有多个并发用户

软件在运行时,可用资源(特别是CPU和内存)可能在某些情况下很紧张,如在一些嵌入式系统软件中

强度测试是要检查在系统运行环境不正常或发生故障的情况下,系统可以运行到何种程度的测试。例如:

把输入数据速率提高一个数量级,确定输入功能将如何响应。

设计需要占用最大存储量或其它资源的测试用例进行测试。

强度测试的一个变种是敏感性测试。在程序有效数据界限内的一个小范围内的一组数据可能引起极端的或不平稳的错误处理出现,或者导致极度的性能下降的情况发生。强度测试可发现可能引起这种不稳定性或不正常处理的某些数据组合。

恢复测试是要证实在克服硬件故障(包括掉电、硬件或网络出错等)后,系统能否正常地继续进行工作,并不对系统造成任何损害。

错误探测功能:系统能否发现硬件失效与故障

能否切换或启动备用的硬件

在故障发生时能否保护正在运行的作业和系统状态

在系统恢复后能否从最后记录下来的无错误状态开始继续执行作业,等等。

安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞,以检查系统对非法侵入的防范能力。系统安全包括了物理设备安全和软件安全,其中的软件

安全是一个相对比较薄弱的环节,受到越来越多的关注。

对大多数的软件产品而言,杜绝非法入侵既不可能也不必要。一般地,如果黑客为非法入侵花费的代价高于得到的好处,那么这样的系统可以认为是安全的。

安全测试的主要步骤

分析系统的安全隐患,为非法入侵设立目标,例如盗窃某个文件、修改用户权限、更改数据库记录等

令自己或悬赏别人扮演黑客,想尽办法入侵系统,实现既定的“目标”

根据成功攻击的过程找出系统的漏洞,确定是否需要进行漏洞的修复。

安全性测试用例的参考模板

可靠性测试是为了检验系统的可靠性是否达到预期目标而进行的测试,其常用指标为:

平均故障间隔时间 MTBF (Mean Time Between Failures),越大越好

平均故障恢复时间 MTTR (Mean Time To Repairs) ,越小越好

安装测试的目的不是找软件错误,而是找安装错误。

在安装软件系统时,会有多种选择。

要分配和装入文件与程序库

布置适用的硬件配置

进行程序的联结

安装测试就是要找出在这些安装过程中出现的错误,验证成功安装系统的能力。

安装与卸载测试内容

测试各种不同的组合安装,验证各种不同组合的正确性;

安装完成后确认应用程序可以正确启动和运行;

安装之前备份注册表,安装之后要查看注册表中是否有多余的垃圾信息;

至少要在一台笔记本电脑上进行安装测试,尤其是系统级的产品;

在安装成功并简单使用后进行卸载操作,确认可以成功卸载;

对于C/S系统,先装客户端再装服务器端;

考察对该系统的安装是否对其他应用程序造成影响.

容量测试是根据预先分析出的某项指标极限值,测试系统在极限值状态下是否能保持正常运行。例如,

对于编译程序,让它处理特别长的源程序;

对于操作系统,让它的作业队列“满员”;

对于信息检索系统,让它使用频率达到最大。

在使系统的全部资源达到“满负荷”的情形下,测试系统的承受能力。

容量测试用例参考模板

内 存 泄 漏

内存泄漏又叫存储泄漏,是指用动态存储分配函数动态开辟的空间,在使用完毕后未释放,结果导致一直占据该内存空间,使应用程序不断消耗系统内存或虚拟存储器,程序运行出现响应变慢,某些功能无法实现,甚至整个系统瘫痪等问题。该现象在C/C++语言编写的程序中及其普遍,在嵌入式系统中会导致系统瘫痪。

内存泄漏测试

以C++语言编写的代码,当出现以new语句分配内存时,应该在某个地方出现以delete语句释放内存。但有时候new和delete并不是成对出现,这就增加了代码审查的难度。

内存越界:当程序员建立了一个100字节的数组,试图向第101字节的位置写入内容时,就产生了内存越界。

常用工具:Compuware的BoundCheck、

Rational公司的Purify

用户界面测试原则

易用性原则

规范性原则

帮助设置原则

合理性原则

美观与协调性原则

菜单位置原则

独特性原则

快捷方式的组合原则

排错性考虑原则

多窗口的应用与系统资源原则

升 级 测 试

升级测试包括两种情况:软件的升级和软件运行环境的升级

软件升级后,要注意做到前向兼容,确保之前的开发版本运行良好。

对软件运行环境的升级测试是一个挑战,因为难以预知将来的运行环境是怎样的,如很多在XP环境下的软件产品不能在Vista环境下运行。

兼 容 性 测 试

需要重点考虑的兼容性问题:

操作系统的兼容性,如测试Windows、Mac OS、UNIX、Linux等操作系统

浏览器的兼容性,如测试微软的 IE、Mozilla的FireFox、腾讯的TT浏览器、遨游Maxthon等。

硬件的兼容性,如显示器的分辨率为1024×768或800×600.

冒 烟 测 试

当软件的一个新版本送交测试人员进行测试时,首要任务是检查其基本功能是否稳定、重要功能有无遗漏,这就是冒烟测试,其目的是检查版本的基本功能。

冒烟测试又称版本确认检查,所进行的是一系列对于该软件比较核心的测试。如果新版本不能通过冒烟测试,测试小组往往会拒绝进行该版本的其他测试。

文档测试用于检查用户文档的清晰性和精确性。

文档中的一些常见错误为:

文字错误、语法错误、拼写错误

操作步骤的描写有遗漏

产品功能的描写有误

软件功能进行修改后没有及时对相关文档进行更新

第二章 软件测试方法与过程

验收测试

验收测试是以用户为主的测试,软件开发人员和质量保证人员也应参加。

由用户参加设计测试用例,使用用户界面输入测试数据,并分析测试的输出结果。一般使用生产中的实际数据进行测试。

在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。

验收测试类型

α测试:指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品(称为α版本)进行测试,试图发现错误并修正。

β测试:指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本,并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。

α测试与β测试的比较

第二章 软件测试方法与过程

面向对象技术给测试带来的新问题

(1)封装:限制了对象属性对外的透明性和外界对它的操作权限,在某种程度上避免了对数据的非法操作,有效防止了故障的扩散,但封装机制也给测试数据的生成、测试路径的选取以及测试结构的分析带来了困难。

(2)继承:子类继承了父类中定义的数据和操作,同时还有自己新的特性。继承使代码的重用率得到了提高,但同时也使故障的传播几率增加。此外,父类的正确性不能保证子类的正确性。

(3)多态:增加了系统运行中可能的执行路径,而且给面向对象软件带来了严重的不确定性,给测试覆盖率的活动带来新的困难。

面向对象/过程软件的测试

面向对象技术独有的封装、继承、多态等新特点给测试带来一系列新的问题,增加了测试的难度。与传统的面向过程的程序设计相比,面向对象程序设计产生错误的可能性增大,或者使得传统软件测试中的重点不再那么突出,使原来测试经验和实践证明的次要方面成为了主要问题。例如:对函数 y = Function(x)的测试

面向对象软件的单元测试

最小的可测试单位是封装的类或对象,而不再是个体的模块。

面向对象的单元测试通常也称为类测试。

主要考察封装在一个类中的方法和类的状态行为。

面向对象软件的单元测试

单独的看待类的成员函数,与面向过程程序中的函数或过程没有本质的区别,传统的测试方法都可使用,如等价类划分法、边界值分析法、逻辑覆盖法等。

面向对象编程的特性使得对成员函数的测试又不完全等同于传统的函数或过程测试,尤其是继承特性和多态特性,使子类继承或重载的父类成员函数出现了传统测试中未遇见的问题,这里要考虑如下两个问题:

(1)继承的成员函数是否都不需要测试?

(2)对父类的测试是否能照搬到子类?

继承的函数是否需要测试?

对父类中已经测试过的成员函数,以下两种情况需要在子类中重新测试:

a)继承的成员函数在子类中做了改动;

b)成员函数调用了改动过的成员函数的部分。

例:假设存在父类Base有Inherited()和Redefined()这两个成员函数,继承父类Base的子类Derived只对Redefined() 做了改动。那么,Derived::Redefined()就需要重新测试;对于Derived::Inherited(),若它包含了调用Redefined()的语句 (x=x/Redefined()),就需要重新测试,否则不需要。

父类的测试是否可以照搬?

如前面的假设:父类Base::Redefined()与子类Derived::Redefined() 是不同的,按理应该要对子类重新测试分析,设计测试用例。但是由于面向对象的继承使得子类与父类的两个函数相似,故只需要在对父类的测试要求和测试用例上添加对子类新的测试要求和增补相应测试用例。

例 Base::Redefined()含有如下语句:

If (value<0) message(―less‖);

else if (value==0) message(―equal‖);

else message(―more‖);

……

Derived::Redefined()中的相应语句为:

If (value<0) message(―less‖);

else if (value==0) message(―It is equal‖);

else {

message(―more‖);

if (value==88) message(―luck‖);

}

……

测试时,只需要在原有对父类的测试上作如下改动:

1)改动value==0的预期输出结果;

2)增加value==88的测试用例。

面向对象软件的集成测试

传统的自顶向下和自底向上的集成策略对于面向对象的测试集成是没有意义的,类之间的相互依赖使其根本无法在编译不完全的程序上对类进行测试。因此,面向对象集成测试通常需要在整个程序编译完成后进行。此外,面向对象程序具有动态特性,程序的控制流往往无法确定,所以也只能对整个编译后的程序做基于黑盒的集成测试。

面向对象的集成测试通常需要进行类簇(一组相互影响、联系比较紧密的类)的测试。

面向对象的集成测试能够检测出相对独立的单元测试无法检测出的那些类相互作用时才会产生的错误。

面向对象软件的集成测试

基于类间协作关系的横向测试:由系统的一个输入事件作为激励,对其触发的一组类进行测试,执行相应的操作/消息处理路径,最后终止于某一输出事件。应用回归测试对已测试过的类集再重新执行一次,以保证加入新类时不会产生意外的结果。

基于类间继承关系的纵向测试:首先通过测试不使用或很少使用其他类服务的类,即独立类(是系统中已经测试正确的某类)来开始构造系统。在独立类测试完成后,下一层继承独立类的类(称为依赖类)被测试,这个依赖类层次的测试序列一直循环执行到构造完整个系统。 面向对象软件的系统测试

系统测试是对所有程序和外部成员构成的整个系统进行整体测试,检验软件和其他系统成员配合工作是否正确,另外,还包括了确认测试内容,以验证软件系统的正确性和性能指标等是否满足需求规格说明书所制定的要求。

它一般不考虑内部结构和中间结果,因此与传统的系统测试差别不大,可沿用传统的系统测试方法。

系 统 排 错

系统排错:根据测试时所发现的错误,找出原因和具体的位置,并进行改正。

排错工作主要由程序开发人员进行,也就是说,谁开发的程序由谁来排错。

错误的特殊性质

错误的外部征兆远离引起错误的内部原因,对于高度耦合的程序结构,此类想象更为严重。 纠正一个错误造成了另一错误现象(暂时)的消失。

某些错误征兆只是假象。

因操作人员一时疏忽造成的某些错误征兆不易追踪。

错误是由于分时而不是程序引起的。

输入条件难以精确地再构造。

错误征兆时有时无(嵌入式系统常见)。

错误是由于把任务分布在若干台不同处理机上运行而造成的。

排 错 过 程

排错过程开始于一个测试用例的执行,若测试结果与期望结果有出入,即出现了错误征兆,排错过程首先是要找出错误原因,然后对错误进行修正。

排错过程有两种可能:一种是能确定错误原因并进行纠正;另一种是未找出错误原因,只能对错误进行推测,直到找到错误并进行纠正。

常 用 排 错 方 法

1. 原始类排错法:是最常用也是最低效的方法,主要思想是“通过计算机找错”,如程序插桩。

2. 回溯法:能成功地用于程序的排错,方法是“顺藤摸瓜”,即从错误出现的地方开始,人工沿着控制流程往回追溯。

常 用 排 错 方 法

3. 归纳和演绎法:采用“分治”的概念,首先基于错误出现有关的所有数据,假想一个错误原因,用这些数据证明或反驳它;或者一次列出所有可能的原因,通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端,则立即精化数据,进一步进行深入的测试。 Web应用系统的测试

以电子商务网站为例,对它的要求是:

有足够好的性能,不要在并发用户很多的时候响应速度很慢

有足够好的兼容性,当使用IE之外的浏览器时,仍旧能够正常使用该网站

有足够强的安全性,至少不期望自己的用户名和密码被他人轻易获得

有良好的正确性,当点击购买某本图书的链接时,不期望出现的是一张音乐CD页面 Web系统故障的产生原因

Web应用系统的用户数目可能在某个时间段迅速增加,其增加的速度和用户的总数量可能令系统的设计和开发者始料不及。

用户的使用环境五花八门,有的使用Windows系统,有点用户使用Linux或者其他系统,有的用户使用IE浏览器,有的用户使用Netscape,有的用户使用的显示器可以支持1024×768分辨率,有的显示器只支持800×600。

网络上的人为攻击、病毒攻击日渐频繁和强大。

在一个Web应用系统中,存在大量的页面链接,而且,这些链接是在不断地更新之中,稍有不慎,某个链接就可能出错。

负载测试要点—并发用户数量

并发用户数量是指在某个时间内,并发用户数量达到甚至超过软件设计上限时的系统反应情况。如前述的电子商务网站,需要测试并发用户在5000人的时候系统的反应,此外还需要测试并发用户在10000人的时候的系统反应情况,这样可以知道系统的个别极端情况下的运行状态。如果这个时候只是反应速度很慢(相应时间超过5000人的时候的状况),那是可以接受的。但如果这个时候出现了数据丢失、系统无响应的情况,就需要对原因进行分析,并解决问题。

负载测试的重点—吞吐量

吞吐量是指软件系统在一定时间内可以完成的事物的数量。吞吐量与并发用户数是有所区别的,更多的并发用户数量并不意味着更大的吞吐量。

例如:网页每分钟能够完成的购买次数就是一个很重要的吞吐量指标。

第三章 黑盒测试

黑盒测试法概述

黑盒测试又称为功能测试或数据驱动测试,着眼于软件的外部结构,把软件看成一个不能打开的黑盒子,完全不考虑程序的内部结构和处理程序,主要针对软件界面、软件功能、外部数据库访问以及软件初始化等方面进行测试。

黑盒测试属于穷举输入测试方法,只有将所有可能的输入都作为测试情况来使用,才能检查出程序中所有的错误。但穷举法是不现实的,因此需要选择合适的方法使测试用例具有完整性和代表性,并能有效地发现软件缺陷。

黑盒测试检测目标

在已知软件产品应具有的功能的基础上,黑盒测试的主要目的是发现以下类型的错误: 检查程序功能是否按照需求规格说明书的规定正常使用,测试每个功能是否有遗漏,检测性能等特性是否满足要求。

检测人机交互是否错误,检测数据结构或外部数据库访问是否错误,程序是否能够适当地接收数据而产生正确的输出结果,并保持外部信息(如数据库或文件)的完整性。 检测程序初始化和终止方面的错误。

第三章 黑盒测试

边界值分析法

边界值分析法的基本思想是:选取正好等于、刚刚大于和刚刚小于边界值的数据进行测试。

大量的测试实践表明,程序在处理大量中间数据时都正确,但在边界处最可能出现错误,因此,许多故障往往发生在输入定义域或输出值域的边界上,而不是在其内部,例如: 循环条件漏写了等于;

计数器少计或多计了一次;

数组下标忽略了0的处理。

边界值分析

内部边界值

有些边界是在软件内部,难以看到,但在进行软件测试时仍需要对其进行检查。例如:

若文本输入框只接受的输入字符为A~Z和a~z,测试时要参考ASCII码,测试表中刚好位于A和a前面、Z和z后面的四个字符:

@ [ ? {

边界值测试

基本原理:程序在处理大量中间数据时都正确,但在边界处最可能出现错误

基本思想:将程序看成是一个函数,程序的输入构成函数的定义域,程序的输出构成函数的值域,测试时将输入变量取

最小值(min)

略高于最小值(min+)

正常值(nom)

略低于最大值(max-)

最大值(max)

边界值分析法设计测试用例

n变量函数

所有变量都取正常值(nom),得到1个测试用例;

其中一个变量取边界值(min、min+、max-、max),其余变量均取正常值,得到4个测试用例;

重复步骤2,将剩余变量循环取边界值,其他变量取正常值,得到4×(n-1)个测试用例; 对于一个n变量函数,测试用例数为4n+1个。

例如:两变量函数,输入分别为x1、x2

(X1nom, X2nom) (X1min, X2nom)

(X1min+,X2nom) (X1max-,X2nom)

(X1max, X2nom) (X1nom, X2min)

(X1nom,X2min+) (X1nom,X2max-)

(X1nom,X2max)

两输入变量程序的边界值测试用例

边界值分析法测试实例——三角形问题

输入变量a、b、c为三角形的边,整数a、b、c必须满足以下条件:

c1. c4.

c2. c5.

c3. c6.

由输入判断三角形的类型:

若没有满足c1、c2、c3中的任何一个条件,则输出消息“输入值不在运行的范围内”; 若三条边相等,则输出―等边三角形‖;

若只有两条边相等,则输出―等腰三角形‖;

若没有边相等,则输出―不等边三角形‖;

若没有满足c4、c5、c6中的任何一个条件,则输出“非三角形”;

健壮性测试

健壮性测试是边界值分析的一种简单扩展,用于观察极限情况时系统的表现。

基本思想:测试时输入变量取

★最小值(min)

★略高于最小值(min+)

★正常值(nom) 边界值分析法

★略低于最大值(max-)

★最大值(max)

★略超过最大值(max+)

★略低于最小值(min-) 极限情况

两输入变量程序的健壮性测试用例

健壮性测试实例——NextDate函数

NextDate是一个有三个变量(月份、日期和年)的函数。函数返回输入日期的下一天。

变量月份、日期和年都为整数,且满足以下条件:

c1.

c2.

c3.

测试用例设计如下表:

边界值分析的局限性

(包括健壮性分析)

适用条件:被测程序是多个独立变量的函数

独立性:边界值分析要求各变量是完全独立的,不适合用于测试变量间存在相互依赖关系的程序。

例如:Nextdate函数的边界值测试并不充分,因为没有考虑2月和闰年的情况。

第三章 黑盒测试

等价类测试

动机

希望进行完备的测试

希望避免冗余

等价类的划分

根据等价关系对输入或输出数据的集合进行划分

将集合划分为互不相交的子集(无冗余性)

这些子集的并是整个集合(完备性)

测试思想

通过每个等价类中的一个元素标识测试用例

例如,在三角形问题中,测试用例(5,5,5)、(6,6,6)、(100,100,100)都可以测试等边三角形,但可以认为在程序中这三个测试用例具有“相同的处理”,因此这些用例是冗余的。

弱一般等价类 强一般等价类

考虑单缺陷假设 考虑多缺陷假设

测试用例使用每个 测试用例集合为

等价类中的一个值 等价类笛卡儿积

弱健壮等价类测试

考虑单缺陷假设、无效值

对于有效输入,使用每个有效类的一个值

对于无效输入,使用一个无效值,并保持其余的值都有效的

强健壮等价类测试

考虑多缺陷假设、无效值

从所有等价类(包括若干无效等价类)笛卡儿乘积中选取

等价类测试实例——三角形问题

输入变量a、b、c为三角形的边,整数a、b、c须满足:

c1. c4.

c2. c5.

c3. c6.

对输出进行等价类划分:

R1={等边三角形}

R2={等腰三角形}

R3={不等边三角形}

R4={非三角形}

弱一般等价类测试用例

(强一般等价类相同)

弱健壮等价类测试用例

(此处仅考虑了a,b,c的无效值)

强健壮等价类测试用例

等价类测试实例——NextDate函数

NextDate是一个有三个变量(月份、日期和年)的函数。函数返回输入日期的下一天。

变量月份、日期和年都为整数,且满足以下条件:

c1.

c2.

c3.

测试用例设计如下表:

等价类测试实例

——NextDate函数(方法一)

M1={月: 1<=月<=12}

D1={日: 1<=日<=31}

Y1={年: 1812<=年<=2012}

M2={月: 月<1}

M3={月: 月>12}

D2={日: 日<1}

D3={日: 日>31}

Y2={年: 年<1812}

Y3={年: 年>2012}

弱一般等价类测试用例

弱健壮等价类测试

强健壮等价类测试

等价类测试实例

——NextDate函数(方法二)

等价类划分:

M1={月: 有30天的小月}

M2={月: 有31天的大月}

M3={月: 此月是2月}

D1={日: 1<=日期<=28}

D2={日: 日期=29}

D3={日: 日期=30}

D4={日: 日期=31}

Y1={年: 年是闰年}

Y2={年: 年是平年}

弱一般等价类测试用例

强一般等价类测试用例

强一般等价类测试用例

强一般等价类测试用例

等价类测试用例

弱一般等价类测试用例数为4个

强一般等价类测试用例数为:

3个(月类)x 4个(日类)x 2(年类)= 24个 弱健壮等价类测试用例数为:8个

强健壮等价类测试用例数为(对每个变量加上2个无效类): 5 x 6 x 4 = 120个

?请同学自己思考各测试用例

等价类测试用例——佣金问题

佣金程序功能:生成销售报告,计算总销售额及佣金。 问题背景:

步枪销售商售出的枪机45美元,枪托30美元,枪管30美元。 销售限额是每个月可卖70个枪机,80个枪托和90个枪管。 佣金的计算方法:

1. 销售额<=1000的部分收10%;

2. 销售额为(1000, 1800] 的部分收15%;

3. 销售额 >1800的部分收20%.

等价类的划分

有效类

L1={枪机: 1<=枪机<=70}

S1={枪托: 1<=枪托<=80}

B1={枪管: 1<=枪管<=90}

无效类

L2={枪机: 枪机<1}

L3={枪机: 枪机>70}

S2={枪托: 枪托<1}

S3={枪托: 枪托>80}

B2={枪管: 枪管<1}

B3={枪管: 枪管>90}

弱一般等价类测试

弱健壮等价类测试

强健壮等价类测试

等价类测试的指导方针

等价类测试的弱形式(一般或健壮)不如对应的强形式的测试全面。

如果实现语言强类型(无效值会引起运行时错误),则不要使用健壮形式的测试。 如果错误条件非常重要,适合进行健壮形式的测试。

如果输入数据以离散区间和几何定义,进行等价类测试是适合,此外也适用于如果变量值越界就会出现故障的系统。

与边界值测试结合,等价类测试可得到加强。

如果程序函数很复杂,则等价类测试是被指示的。

强等价类测试假设变量是独立的,相应的测试用例相乘会引起冗余问题。

在发现“合适”的等价关系之前可能需要进行多次尝试。

第三章 黑盒测试

基于决策表的测试

决策表也称判定表,是分析和表达多逻辑条件下执行不同操作的情况的工具。

在所有的功能性测试方法中,基于决策表的测试方法是最严格的,因为决策表具有逻辑严格性。

决策表测试能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏,设计出完整的测试用例集合。

读书指南决策表

? 规则合并(化简):将具有相同动作,并且其条件项之间存在着极为相似关系的两条或多条规则合并为一条规则

决策表的组成

决策表的建立步骤

条件

c1: a<b+c

c2: b<a+c

c3: c<a+b

c4: a=b

c5: a=c

c6: b=c

行动

非三角形

不等边三角形

等腰三角形

等边三角形

不可能

决策表测试实例——NextDate函数

利用等价类

M1={月份:每月有30天}

M2={月份:每月有31天,

12月除外}

M3={月份:此月是12月}

M4={月份:此月是2月}

D1={日期:1<=日期<=27}

D2={日期:日期=28}

D3={日期:日期=29}

D4={日期:日期=30}

D5={日期:日期=31}

Y1={年:年是闰年}

Y2={年:年是平年}

测试用例表

NextDate函数的测试用例

决策表测试的使用范围

If-then-else逻辑突出

输入变量之间存在逻辑关系

涉及输入变量子集的计算

输入与输出之间存在因果关系

?总体而言,基于决策表的测试通常适用于要产生大量决策的情况(如三角形问题),或在输入变量之间存在重要的逻辑关系的情况(如NextDate函数)。

第三章 黑盒测试

错误推测法

依靠经验和直觉猜测程序中可能存在的各种错误,从而有针对性地编写检查这些故障的测试用例。

对于有经验的工程师来说,错误猜测有时是最有效的发现bug的测试设计方法。 功能性测试方法总结

总结

边界值分析

基于定义域,不识别数据或逻辑关系

很容易自动化实现

设计工作量小

生成的测试用例数比较多

测试用例执行时间长

等价类技术

考虑数据依赖关系

标识等价类时需要更多的判断和技巧

等价类标识出以后的处理也是机械的

设计工作量和测试用例数属中等

决策表技术

又要考虑数据的逻辑依赖关系

所得测试用例可以是完备的

测试数量在一定意义上是最少的

需要通过多次迭代

设计工作量很大

THE END

第 四 章

白盒测试的基本概念

白盒测试:把程序看成装在一个透明的盒子里,程序的结构和处理过程完全可见,按照程序的内部逻辑测试程序,以检查程序中的每条通路是否都能按照预先要求正确工作。

白盒测试针对被测单元的内部进行,它的突出特点是基于被测程序的源代码,而不是基于软件的规格说明书。

白盒测试方法的分类

静态测试:着重在于纠正软件系统在描述、表示和规格上的错误,是进一步测试的前提,方法包括:

桌面检查(Desk checking)

代码评审(Code reading/review)

走查(Walkthroughs)

动态测试:根据程序的控制结构设计测试用例,要求:

保证一个模块中的所有独立路径至少执行一次

对所有逻辑值均需测试True和False

在上下边界及可操作范围内运行所有循环

检查内部数据结构以确保其有效性

逻 辑 覆 盖

逻辑覆盖以程序的内部逻辑结构为基础,主要分以下几种方式:

1 语 句 覆 盖

语 句 覆 盖

测试用例:

a = 10, b = 5

2 判定覆盖(分支覆盖)

3 条 件 覆 盖

判定覆盖 vs 条件覆盖

判定覆盖:

(1)a = 5, b = 5

覆盖了分支一

(2)a = 15, b = 15

覆盖了分支二

4 判定/条件覆盖

5 条件组合覆盖

条件覆盖 vs 条件组合覆盖

条件覆盖 (3个条件6个结果):

(1) a = 5, b = 7, c = 6(全真)

(2) a = 7, b = 9, c = 4(全假)

1. 语句覆盖

a = 5, b = 5, nReturn = 11 语句覆盖率100%

2. 判定覆盖

a = 5, b = 5, nReturn = 11

a = 15, b = 15 nReturn = 0 判定覆盖率100%

3. 条件覆盖

a = 5, b = 15 nReturn = 1

a = 15, b = 5 nReturn = 10条件覆盖率100%

?上面三种覆盖率都达到了100%,很好!但是,仔细分析可以看出,nReturn的结果一共有四种可能的返回值:0、1、 10、11, 而上面每种测试方式只覆盖了部分返回值,可见以上任一覆盖方式虽然覆盖率很高,但是并没有测试完全。

路 径 覆 盖

?路径覆盖将所有可能的返回值都测试到了,这正是它被很多人认为是“最强的覆盖”的原因。

路 径 覆 盖

六种形式的逻辑覆盖

★各种测试方法都不能保证程序的正确性,但测试的目的并不是为了保证其正确,而是为了尽可能找出程序中隐藏的故障。

(e)两个串行的

分支结构的N-S图

★最少测试用例数=(5*3+1)*3=48

基本路径测试

又称独立路径测试,是指在程序控制流图的基础上,分析控制构造的环路复杂性,导出独立可执行路径集合,设计测试用例的方法。

设计出的测试用例要保证在测试中,程序的每一个独立可执行路径至少要执行一次。循环体最多只执行一次。

path1:1 – 11

path2:1 - 2 - 3 - 4 - 5 - 10 - 1 – 11

path3:1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 – 11

path4:1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11

导出程序流程图的拓扑结构—流图(控制流程图)

计算流图的环路复杂性

确定只包含独立路径的基本路径集

设计测试用例

int test2( int x, int y )

{

int k = 0;

if (x > 0)

{

if ( y == 0 )

k = x + 100;

else

{

if ( y == 1 )

k = k + 10;

else

k = 20;

}

}

return k;

}

循 环 测 试

跳过循环

只通过循环一次

通过循环两次

通过循环m次,其中m < n-1

通过循环n–1,n,n+1次

嵌套循环测试

对最内层循环做简单循环的全部测试。所有其它层的循环变量置为最小值。

逐步外推,对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值,所有其它嵌套内层循环的循环变量取“典型”值。

反复进行,直到所有各层循环测试完毕。

对全部各层循环同时取最小循环次数,或者同时取最大循环次数

串接循环测试

如果串接循环的各个循环都彼此独立,则可以使用简单循环的方法来测试串接循环。

当循环不独立时,使用测试嵌套循环的方法来测试串接循环。

面向对象的白盒测试

类测试一般有两种主要的方式:功能性测试和结构性测试,即对应于传统结构化软件的黑盒测试和白盒测试。

结构性测试要考虑程序的代码是否正确,对类中的方法进行测试,它把类作为一个单元来进行测试。测试分为两层:第一层考虑类中各独立方法的代码;第二层考虑方法之间的相互作

用。

对于一个类的测试要保证类在其状态的代表集上能够正确工作,构造函数的参数选择以及消息序列的选择都要满足这一准则。

面向对象的白盒测试——方法的单独测试

结构性测试的第一层是考虑各独立的方法,这可以与过程的测试采用同样的方法,两者之间最大的差别在于方法改变了它所在实例的状态,这就要取得隐藏的状态信息来估算测试的结果,传给其它对象的消息被忽略,而以桩来代替,并根据所传的消息返回相应的值,测试数据要求能完全覆盖类中代码,可以用传统的测试技术来获取。

面向对象的白盒测试——方法的综合测试

第二层要考虑一个方法调用本对象类中的其它方法和从一个类向其它类发送信息的情况。单独测试一个方法时,只考虑其本身执行的情况,而没有考虑动作的顺序问题,测试用例中加入了激发这些调用的信息,以检查它们是否正确运行了。对于同一类中方法之间的调用,一般只需要极少甚至不用附加数据,因为方法都是对类进行存取,故这一类测试的准则是要求遍历类的所有主要状态。

程序插桩方法是借助往被测程序中插入操作来实现测试目的的方法。该法是软件动态测试中的一种基本测试手段,有着广泛的应用。

如果我们想要了解一个程序在某次运行中所有可执行语句被覆盖的情况,或是每个语句的实际执行次数,最好的办法是利用插桩技术。

程序插桩时需要着重考虑:

探测哪些信息;

在程序的什么部位设置探测点;

需要设置多少个探测点。

域测试(Domain Testing)

域测试是一种基于程序结构的测试方法。

Howden把程序中出现的错误分为域错误、计算型错误和丢失路径错误三种。

如果程序的控制流有错误,对于某一特定的输入可能执行的是一条错误路径,这种错误称为路径错误,也叫做域错误。

如果对于特定输入执行的是正确路径,但由于赋值语句的错误致使输出结果不正确,则称此为计算型错误。

另外一类错误是丢失路径错误。

域测试是主要针对域错误进行的程序测试。

域测试方法基于对输入空间的分析。

测试的理想结果就是检验输入空间中的每一个输入元素是否都产生正确的结果。 域测试正是在分析输入域的基础上,选择适当的测试点以后进行测试的。

域测试有两个致命的弱点:一是为进行域测试对程序提出的限制过多,二是当程序存在很多路径时,所需的测试点也很多。

符号测试方法

基本思想是允许程序的输入不仅仅是具体的数值数据,而且包括符号值,符号值可是基本符号变量值,也可是这些符号变量值的一个表达式。

普通测试执行的是算术运算,符号测试则是执行代数运算。

符号测试方法使用问题的关键在于开发出比传统的编译器功能更强,能够处理符号运算的编译器和解释器。

Z路径覆盖测试方法

Z路径覆盖是路径覆盖的一种变体。对于语句较少的简单程序,路径覆盖是具有可行性的,但对于源代码很多的复杂程序,或者对于含有较多条件语句和较多循环体的程序来说,需要测试的路径数目会成倍增长,难以实现。为解决这个问题,采用简化循环方法的路径覆盖就是Z路径覆盖。

简化循环就是减少循环次数,即不考虑循环体的形式和复杂度如何,也不考虑循环体实际需要执行多少次,只考虑循环一次和零次两种情况。

Z路径覆盖

a图和b图表示了两种最典型的循环控制结构 。a图先比较循环条件后执行循环体,循环体可能执行也可能不执行。当限定循环次数为0和1次,这就和图c的条件结构一样了。 b图是先执行循环体后比较循环条件。假设循环体被执行一次,再经过条件判断跳出循环,那么其效果就和图c的条件结构只执行右分支的效果一样了。

Any Questions

第 五 章

软件缺陷的概念

简单说,缺陷就是存在于软件(文档、数据、程序)之中的那些不希望,或不可接受的偏差,而导致软件产生的质量问题。

软件缺陷的种类

软件未达到软件规格说明书中规定的功能;

软件超出软件规格说明书中指明的范围;

软件未达到软件规格说明书中指出的应达到 的目标;

软件运行出现错误;

软件测试人员认为软件难于理解,不易使用,运行速度慢,或者最终用户认为软件使用效果不好。

(1)功能不正常

(2)软件在使用上不方便

(3)软件的结构未做良好规划

(4)功能不充分

(5)与软件操作者的互动不良

(6)使用性能不佳

(7)未做好错误处理

(8)边界错误

(9)计算错误

(10)使用一段时间所产生的错误

(11)控制流程的错误

(12)在大数据量压力之下所产生的错误

(13)在不同硬件环境下产生的错误

(14)版本控制不良所产生的错误

(15)软件文档的错误

软件缺陷的修复

不论测试计划多么完善,测试执行多么努力,仍不能保证所有软件缺陷都被发现,也不能保证发现了的缺陷都被修复。有些软件缺陷可能会完全被忽略,还有一些可能推迟到软件后续版本中修复。

软件缺陷未被修复的原因

(1)没有足够的时间

(2)不算真正的软件缺陷

(3)修复的风险太大

(4)不值得修复

报告软件缺陷的基本原则

1.尽快报告软件缺陷

2.有效地描述软件缺陷

3.在报告软件缺陷时不做任何评价

4.补充和完善软件缺陷报告

有效的软件缺陷的描述

软件缺陷分析

缺陷发现率

缺陷潜伏期

缺陷潜伏期又称阶段潜伏期,是一种特殊类型的缺陷分布度量。在实际测试工作中,发现缺陷的时间越晚,这个缺陷所带来的损害就越大,修复这个缺陷所耗费的成本就越多。

缺陷密度

软件缺陷密度是一种以平均值估算法来计算出软件缺陷分布的密度值:

测试文档

测试文档是对要执行的软件测试及测试的结果进行描述、定义、规定和报告的任何书面或图示信息,对测试阶段工作的指导与评价具有重要作用。

根据测试文档所起的不同作用,通常把它分成两类,即前置作业文档和后置作业文档。前者包括测试计划及测试用例的文档;后者是在测试完成后提交的,主要包括软件缺陷报告和分析总结报告。

主要测试文档

测试设计规格说明文档

测试用例规格说明文档

测 试 日 志

软件测试计划

测试计划就是描述所有要完成的测试工作,包括被测试项目的背景、目标、范围、方式、资源、进度安排、测试组织,以及与测试有关的风险等方面。

制定测试计划的原则

1.制定测试计划应尽早开始

2.保持测试计划的灵活性

3.保持测试计划简洁和易读

4.尽量争取多渠道评审测试计划

5.计算测试计划的投入

制定测试计划时可能出现的问题

1.与开发者意见不一致

2.缺乏测试工具

3.培训不够

4.管理部门缺乏对测试工作的理解和支持

5.缺乏用户的参与

6.测试时间不足

7.过分依赖测试人员

8.测试人员处于进退两难的状态

9.不得不说“不”

测试进度表

自动化测试的定义

自动化测试就是使用软件工具来代替手工进行的一系列动作。它具有良好的可操作性、可重复性和高效率等特点。

自动化测试的目的是减轻手工测试的工作量,以达到节约资源(包括人力、物力等),保证软件质量,缩短测试周期的效果。

通常是使用脚本或者其他代码驱动应用程序。这一切可以通过可视用户界面(如浏览器)完

成,也可以通过直接命令(从客户端发向服务器,以模仿浏览器发送的命令)完成自动化测试。

自动化测试大都属于回归测试的范畴。

自动化测试优点

提高测试效率

降低对软件新版本进行回归测试的开销

完成手工测试不能或难以完成的测试

具有一致性和可重复性

更好地利用资源

降低风险,增加软件信任度

自动化测试的局限性

不能完全取代手工测试和手工测试工程师

软件自动化测试可能降低测试的效率

测试人员期望自动测试发现大量的新错误

如果缺乏测试经验,测试的组织差、文档少或不一致,则自动测试的效果比较差 软件自动化测试工具本身的问题

自动化测试的作用和优势

产生可靠的系统

改进测试工作质量

减少测试工作量并加快测试进度

产生可靠的系统

需求定义的改进

性能测试的改进

负载/压力测试的改进

高质量测量与测试最佳化

改进与开发组人员之间的关系

改进系统开发生存周期

改进测试工作质量

改进多平台兼容性测试

改进软件兼容性测试

改进普通测试执行

使测试集中于高级测试问题

执行手工测试无法完成的测试

重现软件缺陷的能力

测试无需用户干预

减少测试工作量并加快测试进度

善于使用测试工具来进行测试,其节省时间并加快测试工作进度是毋庸置疑的,这也是自动化测试的主要优点。 尽管测试工作量一开始可能增多,但在自动化测试工具实施

的第一次重复之后,测试工具投资回报就将显现出来,因为测试人员的生产率提高了。

下表7-1列出了采用手工和自动化测试方式完成各测试步骤所需工作量的基准对比结果。该测试涉及1750个测试程序和700个错误。表7-1中的数字反映出通过测试自动化,测试工作总量减少75%。

软件测试工具的分类

捕获错误用途工具

一般用途工具

GUI自动化用途工具

软件产品功能、性能测试用途工具

测试管理工具

测试辅助工具

捕获错误用途的工具

开发人员自行编写的测试工具

利用所使用的开发工具的调试功能或工具

购买专业的调试软件

GUI自动化用途测试工具

Robot(Rational公司)

WinRunner(Mercury Interactive公司)

QA Wizard(Seaoine Software公司)

专用代码测试工具

BoundsCheck (Visual C++)

CodeReview (Visual Basic)

JCheck (Java)

Junit (Java)

CppUnit (C++)

白盒静态测试工具

静态测试工具直接对代码进行分析,不需要运行代码,也不需要对代码编译链接,生成可执行文件。

静态测试工具一般是对代码进行语法扫描,找出不符合编码规范的地方,根据某种质量模型评价代码的质量,生成系统的调用关系图等。

静态测试工具的代表有Telelogic公司的Logiscope软件、PR公司的PRQA软件。 白盒动态测试工具

动态测试工具与静态测试工具不同,动态测试工具的一般采用“插桩”的方式,向代码生成的可执行文件中插入一些监测代码,用来统计程序运行时的数据。

与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。

动态测试工具的代表有Compuware公司的DevPartner软件、Rational公司的Purify系列 、 开

源测试框架 JUnit

黑盒测试工具

黑盒测试工具的一般原理:利用脚本的录制(Record)/回放(Playback),模拟用户的操作,然后将被测系统的输出记录下来同预先给定的标准结果比较。

黑盒测试工具的代表:

Rational公司的TeamTest、Robot

Compuware公司的QARun

MI公司的WinRunner 、LoadRunner

Radview公司的WebLoad

Microsoft公司的WebStress

测试管理工具

Rational公司的Test Manager

Compuware公司的TrackRecord

自动化测试工具

单元测试(白盒), xUnit家族:PhpUnit, NUnit, CppUnit, JUnit, DBUnit, HttpUnit

集成测试: 写脚

系统测试(黑盒):HP的QTP, IBM的RFT, Borland的SilkTest

网站测试要求

有足够好的性能,不要在并发用户很多的时候响应速度很慢

有足够好的兼容性,当使用IE之外的浏览器时,仍旧能够正常使用该网站

有足够强的安全性,至少不期望自己的用户名和密码被他人轻易获得

有良好的正确性,当点击购买某本图书的链接时,不期望出现的是一张音乐CD页面 发生故障的原因

Web应用系统的用户数目可能在某个时间段迅速增加,其增加的速度和用户的总数量可能令系统的设计和开发者始料不及。

用户的使用环境五花八门,有的使用Windows系统,有点用户使用Linux或者其他系统,有的用户使用IE浏览器,有的用户使用Netscape,有的用户使用的显示器可以支持1024×768分辨率,有的显示器只支持800×600。

网络上的人为攻击、病毒攻击日渐频繁和强大。

在一个Web应用系统中,存在大量的页面链接,而且,这些链接是在不断地更新之中,稍有不慎,某个链接就可能出错。

负载测试的重点——并发用户数量

并发用户数量:指在某个时间内,并发用户数量达到甚至超过软件设计上限时的系统反应情况。如前述的电子商务网站,需要测试并发用户在5000人的时候系统的反应,此外还需要测试并发用户在10000人的时候的系统反应情况,这样可以知道系统的个别极端情况下的运行状态。如果这个时候只是反应速度很慢(相应时间超过5000人的时候的状况),那是可以接受的。但如果这个时候出现了数据丢失、系统无响应的情况,就需要对原因进行分析,并解决问题。

负载测试的重点——吞吐量

吞吐量是指软件系统在一定时间内可以完成的事物的数量。例如,每分钟能够完成的购买次数就是一个很重要的吞吐量指标。

系 统 排 错

系统排错:根据测试时所发现的错误,找出原因和具体的位置,并进行改正。

排错工作主要由程序开发人员进行,也就是说,谁开发的程序由谁来排错。

排 错 过 程

排错过程开始于一个测试用例的执行,若测试结果与期望结果有出入,即出现了错误征兆,排错过程首先是要找出错误原因,然后对错误进行修正。

排错过程有两种可能:一种是能确定错误原因并进行纠正;另一种是未找出错误原因,只能对错误进行推测,直到找到错误并进行纠正。

错误的特殊性质

错误的外部征兆远离引起错误的内部原因,对于高度耦合的程序结构,此类想象更为严重。 纠正一个错误造成了另一错误现象(暂时)的消失。

某些错误征兆只是假象。

因操作人员一时疏忽造成的某些错误征兆不易追踪。

错误是由于分时而不是程序引起的。

输入条件难以精确地再构造。

错误征兆时有时无(嵌入式系统常见)。

错误是由于把任务分布在若干台不同处理机上运行而造成的。

常 用 排 错 方 法

1. 原始类排错法:是最常用也是最低效的方法,主要思想是“通过计算机找错”,如程序插桩。

2. 回溯法:能成功地用于程序的排错,方法是“顺藤摸瓜”,即从错误出现的地方开始,人工沿着控制流程往回追溯。

常 用 排 错 方 法

3. 归纳和演绎法:采用“分治”的概念,首先基于错误出现有关的所有数据,假想一个错误原因,用这些数据证明或反驳它;或者一次列出所有可能的原因,通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端,则立即精化数据,进一步进行深入的测试。

有时修改一处老问题会引入几个新问题,有时程序越改越乱,这时应注意以下三个问题:

1. 导致这个错误的原因在程序其他部分还可能存在吗?

2. 本次修改可能对程序中相关的逻辑和数据造成什么影响?引起什么问题?

3. 上次遇到的类似问题是如何排除的?

软件测试概述

1. 简述软件测试的意义。

解:随着计算机技术的迅速发展和广泛深入的应用,软件质量问题已成为开发和使用软件人员关注的焦点。而由于软件本身的特性,软件中的错误是不开避免的。不断改进的开发技术和工具只能减少错误的发生,但是却不可能完全避免错误。因此为了保证软件质量,必须对软件进行测试。软件测试是软件开发中必不可少的环节,是最有效的排除和防治软件缺陷的手段,是保证软件质量、提高软件可靠性的最重要手段。

2. 什么是软件缺陷?它的表现形式有哪些?

解:从产品内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题;从外部看,软件缺陷是系统所需实现的某种功能的失效或违背。

它的表现形式主要有以下几种:(1)软件未达到产品说明书中已经标明的功能;(2)软件出现了产品说明书中指明不会出现的错误;(3)软件未达到产品说明书中虽未指出但应当达到的目标;(4)软件功能超出了产品说明书中指出的范围;(5)软件测试人员认为软件难以理解、不易使用,或者最终用户认为该软件使用效果不良。

3. 简单分析软件缺陷产生的原因,其中那个阶段引入的缺陷最多,修复成本又最低? 解:软件缺陷产生的主要原因有:需求规格说明错误;设计错误;程序代码有误;其他。其中在需求分析阶段引入的缺陷最多,修复的成本又最低。

4. 当用户登录某网站购物完毕并退出后,忽然想查查购物时付账的总金额,于是按了浏览

器左上角的“退回”按钮,就又回到了退出前的网页,你认为该购物软件有缺陷吗?如果有,属于哪一类?

解:有缺陷。其所属类别与软件产品说明书的要求有关。

5. 什么是软件测试?简述其目的与原则。

解:软件测试是为了尽快尽早地发现在软件产品中所存在的各种软件缺陷而展开的贯穿整个软件开发生命周期,对软件产品(包括阶段性产品)进行验证和确认的活动过程。

测试目的:(1)证明:获取系统在可接受风险范围内可用的信心;尝试在非正常情况和条件下的功能和特性;保证一个工作产品是完整的并且可用或可被集成。 (2)检测:发现缺陷、错误和系统不足;定义系统的能力和局限性;提供组件、工作产品和系统的质量信息。

(3)预防:澄清系统的规格和性能;提供预防或减少可能制造错误的信息;在过程中尽早检测错误;确认问题和风险,并且提前确认解决这些问题和风险的途径。

测试过程中应注意和遵循的原则:(1)测试不是为了证明程序的正确性,而是为了证明程序不能工作。(2)测试应当有重点。(3)事先定义好产品的质量标准。(4)软件项目一启动,软件测试也就开始,而不是等到程序写完才开始进行测试。(5)穷举测试是不可能的。

(6)第三方进行测试会更客观,更有效。(7)软件测试计划是做好软件测试工作的前提。

(8)测试用例是设计出来的,不是写出来的。(9)对发现错误较多的程序段,应进行更深入的测试。(10)重视文档,妥善保存一切测试过程文档。

6. 件测试阶段是如何划分的?

解:软件测试的阶段划分为:规格说明书审查;系统和程序设计审查;单元测试;集成测试;确认测试;系统测试;验收测试。

7. 简述软件开发的几个模式,并说明每种模式对软件测试的影响。

解:大棒模式简单,计划、进度安排和正规开发过程几乎没有,其开发过程是非工程化的。大棒模式的软件测试通常在开发任务完成后进行,很难回头修复存在的问题,测试工作只是向客户报告软件经过测试后发现的情况。

边写边改模式通常最初只有粗略的想法就进行简单的设计,然后开始较长的反复编写、测试和修复过程,在认为无法更精细地描述软件产品要求时就发布产品。该模式下,软件测试人员将和程序员一起陷入可能是长期的循环往复过程。

瀑布模式将软件生命周期的各项活动规定为按照固定顺序相连的若干个阶段性工作,形如瀑布流水,最终得到软件产品。软件测试在后期展开,使得开发中出现的问题直到开发后期才显露,失去了及早纠正的机会。

快速原型模式首先构造一个功能简单的原型系统,然后通过对原型系统逐步求精,不断扩充完善得到最终的软件系统。原型系统在扩充完善过程中不断被检查、测试和修改。

螺旋模式是瀑布模式与边写边改模式演化结合的形式,并加入了风险评估所建立的软件开发模式,其主要思想是在开始时不必详细定义所有细节,而是从小开始,定义重要功能,尽量实现,接受客户反馈,进入下一阶段并重复上述过程,直到获得最终产品。测试在每个阶段都要进行,并从最初就参与。

8. 简述软件测试过程。

解:软件测试过程主要包括如下6个活动:测试计划;测试需求分析;测试设计;测试规程实现;测试执行;总结生成报告。

9. “软件测试能够保证软件的质量”这句话对吗?软件测试和软件质量之间是什么关系? 解:不对。软件测试是保障软件质量的手段之一,但不是唯一手段。测试是产品高质量的必要非充分条件,软件测试不能决定软件质量。

10. 判断以下说法是否正确。

(1)软件测试和软件调试是同一回事。

(2)软件测试是可以无穷尽的。

(3)测试是为了证明软件的正确性。

(4)测试过程中应重视测试的执行,可以轻视测试的设计。

(5)测试不能修复所有的软件故障。

(6)因为测试工作简单,对软件产品影响不大,所以可以把测试作为新员工的一个过渡工作,或安排不合格的开发人员做测试。

解:(1)(2)(3)(4)(6)错误,(5)正确。

11. 简述软件开发进程与测试进程的关系。

解:软件测试是一个贯穿软件开发生命周期的活动,它可以是一个与开发并行的过程,也可以是在开发完成某个阶段任务之后的活动。

第2章 软件测试方法与过程

1.对软件测试的复杂性进行归纳分析。

解:软件测试的复杂性在于:无法对程序进行完全的测试;测试无法保证被测程序中无遗留错误;不能修复所有的软件故障。

2.分别解释什么是静态测试、动态测试、黑盒测试、白盒测试、人工测试和自动化测试。 解:所谓静态测试是指不运行被测软件,仅通过分析或检查等其他手段达到检测的目的。 所谓动态测试是指通过运行被测软件,检查运行结果与预期结果的差异,并分析运行效率和健壮性等性能。

黑盒测试是指在对程序进行的功能抽象的基础上,将程序划分成功能单元,然后对每个功能单元生成测试数据进行测试。用这种方法进行测试时,被测程序被当作打不开的黑盒,因而无法了解其内部构造,因此又称为功能测试。

白盒测试又称为结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能。

广义上,人工测试是人为测试和手工测试的统称。人为测试的主要方法有桌前检查,代码审查和走查。手工测试指的是在测试过程中,按测试计划一步一步执行程序,得出测试结果并进行分析的测试行为。

自动化测试指的是利用测试工具来执行测试,并进行测试结果分析的测试行为。

3.如果没有软件规格说明或需求文档,可以进行动态黑盒测试吗?为什么? 解:不行。因为黑盒测试是基于软件规格说明的测试。

4.在单元测试中,所谓单元是如何划分的?

解:单元测试的对象通常是软件设计的最小逻辑单元,单元的划分在面向过程的结构化程序中一般是函数或子过程,在面向对象的程序中可以是类或类的成员函数。

5.简述单元测试的主要任务。

解:单元测试的主要任务是:模块接口测试;局部数据结构测试;路径测试;错误处理测试;边界测试。

6.如果开发时间紧迫,是否可以跳过单元测试而直接进行集成测试?为什么?

解:不可以。因为没有经过单元测试的模块会遗留大量的缺陷到集成测试阶段,而在集成测试阶段对这些缺陷定位困难,导致后续工作展开困难,修复缺陷成本成指数级增长。

7.什么是驱动模块和桩模块?为下面的函数构造一个驱动模块。

int divide(int a, int b)

{

int c;

if (b==0) {printf("除数不能为0"); return 0;}

c=a/b;

return c;

}

解:驱动模块是用以模拟被测模块的上级模块,它接收测试数据,传送数据给被测模块,启动被测模块,最后输出实测结果。

桩模块用以模拟被测模块工作过程中所调用的子模块。

函数驱动模块:

void main( )

{

int x,y,z;

scanf(―%d%d‖,&x,&y);

z=divide(x,y);

printf(―%d‖,z);

}

8.什么是回归测试?什么时候进行回归测试?

解:回归测试就是重新运行现有测试用例测试原有功能,以便确定变更是否达到了预期的目的,检查变更是否损害了原有的正常功能。每当软件发生变化时就应进行回归测试。

9.集成测试有哪些不同的集成方法?简述不同方法的特点。

解:集成测试通常有一次性集成、自顶向下集成、自底向上集成和混合集成4种集成方法。

一次性集成方法需要的测试用例数目少,测试方法简单、易行。但是由于不可避免存在模块间接口、全局数据结构等方面的问题,所以一次运行成功的可能性不大;如果一次集成的模块数量多,集成测试后可能会出现大量的错误,给程序的错误定位与修改带来很大的麻烦;即使集成测试通过,也会遗漏很多错误进入系统测试。

自顶向下集成在测试的过程中,可以较早地验证主要的控制和判断点;一般不需要驱动程序,减少了测试驱动程序开发和维护的费用;可以和开发设计工作一起并行执行集成测试,能够灵活的适应目标环境;容易进行故障隔离和错误定位。但是在测试时需要为每个模块的下层模块提供桩模块,桩模块的开发和维护费用大;桩模块不能反映真实情况,重要数据不能及时回送到上层模块,导致测试不充分;涉及复杂算法和真正I/O的底层模块最易出问题,在后期才遇到导致过多的回归测试。

自底向上集成可以尽早的验证底层模块的行为;提高了测试效率;一般不需要桩模块;容易对错误进行定位。但是直到最后一个模块加进去之后才能看到整个系统的框架;驱动模块的设计工作量大;不能及时发现高层模块设计上的错误。

混合集成具有自顶向下和自底向上两种集成策略的优点,但是在被集成之前,中间层不能尽早得到充分的测试。

10.系统测试主要包括哪些内容?

解:系统测试主要包括强度测试、性能测试、恢复测试、安全测试、可靠性测试、安装测试、容量测试和文档测试。

11.验收测试是由谁完成的?通常包含哪些过程?

解:验收测试是以用户为主的测试,软件开发人员和QA(质量保证)人员也应参加。通常包含α测试和β测试过程。

12.分析比较面向对象的软件测试与传统的软件测试的异同。

解:传统的单元测试的对象是软件设计的最小单位——模块。当考虑面向对象软件时,单元的概念发生了变化,此时最小的可测试单位是封装的类或对象,而不再是个体的模块。传统单元测试主要关注模块的算法实现和模块接口间数据的传递,而面向对象的单元测试主要考察封装在一个类中的方法和类的状态行为。

面向对象软件没有层次的控制结构,因此传统的自顶向下和自底向上集成策略就不再适合,它主要有以下两种集成策略: 基于类间协作关系的横向测试;基于类间继承关系的纵向测试。

系统测试一般不考虑内部结构和中间结果,因此面向对象软件系统测试与传统的系统测试差别不大。

面向对象软件测试的整体目标和传统软件测试的目标是一致的,即以最小的工作量发现尽可能多的错误,但是面向对象测试的策略和战术有很大不同。测试的视角扩大到包括复审分析和设计模型,此外,测试的焦点从过程构件(模块)移向了类。

第3章 黑盒测试

1.分析黑盒测试方法的特点。

解:黑盒测试又称为功能测试或数据驱动测试,主要针对软件界面、软件功能、外部数据库访问以及软件初始化等方面进行测试。

优点:1)比较简单,不需要了解程序内部的代码及实现;2)与软件的内部实现无关;3)从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题;4)基于软件开发文档,所以也能知道软件实现了文档中的哪些功能;5)在做软件自动化测试时较为方便。 缺点:1)不可能覆盖所有的代码,覆盖率较低,大概只能达到总代码量的30%;2)自动化测试的复用性较低。

2.健壮等价类测试与标准等价类测试的主要区别是什么?

解:主要区别在于健壮等价类测试在标准等价类的基础上还要进行有效取值范围之外的输入(无效输入)的测试。

3.试用等价分类法测试党政管理系统中党员出生年月的输入设计是否符合要求,假设出生年月格式为yyyymmdd。

解:

输入数据

出生年月日 无效等价类 ①8位数字字符 有效等价类 ②有非数字字符

③少于8个数字符

④多于8个数字符

对应数值 月份对应数值 日期对应值

⑤在19090101-19900101之间 ⑧在1-12之间

111,3,5,7,8,10,12○

月在1-31之间 124,6,9,11月在1-30之间 ○13闰年2月在1-29之间 ○14非闰年2月在1-28之间 ○

⑥<19090101

⑦>19900101 ⑨等于"00 " ⑩>12 15等于"00 " ○16>31 ○172,4,6,9,11月等于"31 " ○182月等于"30 " ○19非闰年2月等于"29" ○

4.找零钱最佳组合:假设商店货品价格(R)皆不大于100元(且为整数),若顾客付款在100元内(P),求找给顾客之最少货币个(张)数?(货币面值50元(N50),10元(N10),5元(N5),1元(N1)四种。试根据边界值法设计测试用例。

解:1)分析输入的边界情况: R > 100 0 < R < = 100 R <= 0 P > 100 R<= P <= 100 P < R

2)分析零钱最佳组合的输出情况: N50 = 1 N50 = 0 4>N10>= 1 N10 = 0 N5 = 1 N5 = 0 4>N1>= 1 N1 = 0

3)分析规格中每一决策点之情形,以RR1,RR2,RR3表示计算要找50,10,5元货币数时的剩余金额。 R > 100 R <= 0 P > 100 P < R

RR1 >= 50 RR2 >= 10 RR3 >= 5

4)根据上述的输入/输出条件组合出可能的情况:

R > 100 R <= 0

0 < R <= 100, P > 100 0 < R <= 100, P < R

0 < R <= 100, R <= P <= 100, RR = 50 0 < R <= 100, R <= P <= 100, RR = 49 0 < R <= 100, R <= P <= 100, RR = 10 0 < R <= 100, R <= P <= 100, RR = 9 0 < R <= 100, R <= P <= 100, RR = 5 0 < R <= 100, R <= P <= 100, RR = 4 0 < R <= 100, R <= P <= 100, RR = 1 0 < R <= 100, R <= P <= 100, RR = 0

5)为满足以上各种情形,测试用例设计如下:

测试用例 test1 test2 test3

货品价格R

101 0 -1

付款金额P

- - -

test4 test5 test6 test7 test8 test9 test10 test11 test12 test13

100 100 50 51 90 91 95 96 99 100

101 99 100 100 100 100 100 100 100 100

5.试为三角形问题中的直角三角形开发一个决策表和相应的测试用例。注意,会有等腰直角三角形。

解:判断构成的是否为直角三角形的问题的决策表设计如下:

c1:a<b+c? c2:b<a+c? c3:c<a+b? c4:a2+b2=c2? c5: a2+c2=b2? c6: b2+c2=a2? a1:非三角形 a2:直角三角形 a3:非直角三角形 a4:不可能

用例ID DT1 DT2 DT3 DT4 DT5 DT6 DT7 DT8 DT9 DT10 DT11

F - - - - - X

T F - - - - X a 4 1 1 ? ? ? 3 ? 3 5 2

T T F - - - X b 1 4 2 ? ? ? 4 ? 5 3 3 T T T T T T X

T T T T T F X c 2 2 4 ? ? ? 5 ? 4 4 4

T T T T F T X

T T T T F F X

T T T F T T X

T T T F T F X

T T T F F T X

T T T F F F X

根据该决策表设计测试用例如下:

预期输出 非三角形 非三角形 非三角形 不可能 不可能 不可能 直角三角形 不可能 直角三角形 直角三角形 非直角三角形

6.现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,所有记录分为3组,如图:

(1)标题:该组只有一个记录,其内容是成绩报告的名字。

(2)各题的标准答案:每个记录均在第80个字符处标以数字2。该组的记录:

第一个记录:第1~3个字符为试题数(1~999)。第10~59个字符是1~50题的标准答案(每个合法字符表示一个答案)。

第二个记录:是第51~100题的标准答案。

…….

(3)学生的答案:每个记录均在第80个字符处标以数字3。每个学生的答卷在若干个记录中给出。

学号:1~9个字符

1~50题的答案:10~59。当大于50题时,在第二、三、……个记录中给出。

学生人数不超过200,试题数不超过999。

程序的输出有4个报告:

a)按学号排列的成绩单,列出每个学生的成绩、名次。

b)按学生成绩排序的成绩单。

c)平均分数及标准偏差的报告

d)试题分析报告。按试题号排序,列出各题学生答对的百分比。

采用边界值分析方法,分析和设计测试用例。分别考虑输入条件和输出条件,以及边界条件。采用错误推测法补充设计一些测试用例。

解:输入条件及相应的测试用例如下:

输出条件及相应的测试用例表如下:

采用错误推测法还可补充设计一些测试用例:

? 程序是否把空格作为回答

? 在回答记录中混有标准答案记录

? 除了标题记录外,还有一些的记录最后一个字符即不是2也不是3

? 有两个学生的学号相同 ? 试题数是负数

第4章 白盒测试方法

1.简述白盒测试用例的设计方法,并进行分析总结。

解:白盒测试用例设计方法主要有逻辑覆盖和独立路径测试。

从覆盖源程序语句的详尽程度分析,逻辑覆盖主要有以下不同的覆盖标准:语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。实际项目中,由于程序内部的逻辑存在不确定性和无穷性,尤其对于大规模复杂软件,不必采用所有的覆盖指标,而应根据实际情况选择合适的覆盖指标。

独立路径测试是在程序控制流图的基础上,通过分析控制结构的环路复杂性,导出可执行的独立路径集合,从而设计出相应的测试用例。设计出的测试用例要保证被测程序的每条可执行的独立路径至少被执行一次。独立路径测试给出了满足路径覆盖指标所需测试用例的下限,同时给出了语句覆盖的上限,它可以确保对所有相互独立的决策结果进行测试。

2.分析归纳逻辑覆盖的各种策略,并比较每种覆盖的特点,分析在怎样的情况下采用何种覆盖方式。

解:语句覆盖是选择足够多的测试数据,使被测程序中每个语句至少执行一次。语句覆盖是最弱的逻辑覆盖标准。

判定覆盖又叫分支覆盖,它不仅每个语句必须至少执行一次,而且每个判定表达式的每种可能的结果都应该至少执行一次。判定条件覆盖比语句覆盖强,但是对程序逻辑的覆盖程度仍然不高。

条件覆盖的含义是,使判定表达式中的每个条件都取到各种可能的结果。条件覆盖通常比判定覆盖强,但是也可能有相反的情况:虽然每个条件都取到了两个不同的结果,判定表达式却始终只取一个值。

判定/条件覆盖的含义是,选取足够多的测试数据,使得判定表达式中的每个条件都取到各种可能的值,而且每个判定表达式也都取到各种可能的结果。但有时判定/条件覆盖也并不比条件覆盖更强。

条件组合覆盖是更强的逻辑覆盖标准,它要求选取足够的测试数据,使得每个判定表达式中条件的各种可能组合都至少出现一次。满足条件组合覆盖标准的测试数据,也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。因此,条件组合覆盖是前述几种覆盖标准中最强的。但是,满足条件组合覆盖标准的测试数据并不一定能使程序中的每一条路径都执行到。 路径覆盖的定义是选取足够多测试数据,使程序的每一条可能路径都至少执行一次。但在实际问题中,一个不太复杂的程序,其路径数都可能是一个庞大的数字,以致要在测试中覆盖所有的路径是不可能实现的。即使对于路径数有限的程序做到了路径覆盖,也不能保证被测程序的正确性。

3.对图所示程序段进行语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖方法进行测试用例设计。

图4.14 练习题3

解:语句覆盖:x=90,y=90

x=79,y=90

x=70,y=60

判定覆盖:同上

条件覆盖:同上

判定/条件覆盖:同上

条件组合覆盖:错误!未找到引用源。 x>=80,y>=80

错误!未找到引用源。 x>=80,y<80

错误!未找到引用源。 x<80,y>=80

错误!未找到引用源。 x<80,y<80

错误!未找到引用源。 x>=90,y>=90,x+y>=140 错误!未找到引用源。 x>=90,y<90,x+y>=140 错误!未找到引用源。 x<90,y>=90,x+y>=140 错误!未找到引用源。 x<90,y<90,x+y>=140

错误!未找到引用源。 x>=90,y>=90,x+y<140 不存在 错误!未找到引用源。 x>=90,y<90,x+y<140 错误!未找到引用源。 x<90,y>=90,x+y<140 错误!未找到引用源。 x<90,y<90,x+y<140

x=90,y=90

x=90,y=70

x=70,y=90

x=70,y=70

x=100,y=30

x=30,y=100

x=80,y=50

路径覆盖:同语句覆盖

4.请下述语句按照各种覆盖方法设计测试用例。

if (a>2 && b<3 && (c>4 || d<5))

{

statement;

}

else

{

statement;

}

解:语句覆盖:a=3,b=2,c=5,d=5

a=2,b=2,c=5,d=5

判定覆盖:同上

条件覆盖:a=3,b=2,c=5,d=5

a=2,b=4,c=3,d=4

判定/条件覆盖:同条件覆盖

条件组合覆盖:错误!未找到引用源。 a>2,b<3,c>4,d<5 错误!未找到引用源。 a>2,b<3,c>4,d>=5 错误!未找到引用源。 a>2,b<3,c<=4,d<5 错误!未找到引用源。 a>2,b<3,c<=4,d>=5 错误!未找到引用源。 a>2,b>=3,c>4,d<5 错误!未找到引用源。 a>2,b>=3, c>4,d>=5 错误!未找到引用源。 a>2,b>=3, c<=4,d<5 错误!未找到引用源。 a>2,b>=3, c<=4,d>=5 错误!未找到引用源。 a<=2,b<3,c>4,d<5 错误!未找到引用源。 a<=2, b<3,c>4,d>=5 错误!未找到引用源。 a<=2, b<3,c<=4,d<5 错误!未找到引用源。 a<=2, b<3,c<=4,d>=5 错误!未找到引用源。 a<=2, b>=3,c>4,d<5 错误!未找到引用源。 a<=2, b>=3, c>4,d>=5 错误!未找到引用源。 a<=2, b>=3, c<=4,d<5 错误!未找到引用源。 a<=2, b>=3, c<=4,d>=5 测试数据略

5.针对test函数按照基本路径测试方法设计测试用例。 int Test(int i_count, int i_flag)

{

int i_temp = 0;

while (i_count>0)

{

if (0 == i_flag)

{

i_temp = i_count + 100;

break;

}

else

{

if (1 == i_flag) {

i_temp = i_temp + 10; }

else

{

i_temp = i_temp + 20; }

}

i_count--;

}

return i_temp;

}

解:int Test(int i_count, int i_flag)

{

1 int i_temp=0;

2 while (i_count>0)

{

3 If (0==i_flag)

{

4 i_temp=i_count+100; 5 break;

}

6 else

{

7 If (1==i_flag)

{

8 i_temp=i_temp+10; }

9 else

{

10 i_temp=i_temp+20; }

}

11 i_count--;

}

12 return i_temp;

}

程序控制流图:

程序环路复杂度:CC=4

基本路径集:path1 1-2-3-6-7-8-11-2-12 Path2 1-2-12

Path3 1-2-3-4-5-12

Path4 1-2-3-6-7-9-10-11-2-12 设计测试用例:

6.对如图4.15所示的N-S

图4.15 练习题6

解:(2+2*2)*2=12

第5章 软件测试管理及自动化测试基础

1.简述软件测试自动化的意义。

解:软件测试自动化的意义是:(1)提高测试效率;(2)降低对软件新版本进行回归测试的

开销;(3)完成手工测试不能或难以完成的测试;(4)具有一致性和可重复性;(5)更好地利用资源;(6)降低风险,增加软件信任度。 2.在运用软件自动化测试时,应注意哪些缺点和事项?

解:应注意:(1)软件自动化测试可能降低测试的效率;(2)测试首次运行时,可能发现大量错误,但当进行过多次测试后,发现错误的机率会相对较小,除非对软件进行了修改或在不同的环境下运行;(3)如果缺乏测试经验,测试的组织差、文档少或不一致,则自动化测试的效果比较差;(4)技术问题。作为第三方的技术产品,如果不具备解决问题的能力和技术支持或者产品适应环境变化的能力不强,将使得软件自动化工具的作用大大降低。

3.软件测试工具主要分为哪个大类?

解:根据测试方法不同,分为白盒测试工具和黑盒测试工具。

根据测试的对象和目的,分为单元测试工具、功能测试工具、负载测试工具、性能测试工具和测试管理工具等。

4.了解时下常用的自动化测试用具,并对这些工具进行针对性说明。

解:略。

5.简述软件测试管理过程。

解:首先由一位对整个系统设计熟悉的设计人员编写测试大纲,明确测试的内容和测试通过的准则,设计完整合理的测试用例,以便系统实现后进行全面测试。

然后在实现组将所开发的程序经验证后,提交测试组,由测试负责人组织测试,测试一般可按下列方式组织: (1)测试人员仔细阅读有关资料,包括规格说明、设计文档、使用说明书及在设计过程中形成的测试大纲、测试内容及测试的通过准则,全面熟悉系统,编写测试计划,设计测试用例,作好测试前的准备工作。(2)为了保证测试的质量,将测试过程分成几个阶段,即:代码审查、单元测试、集成测试、确认测试和系统测试。

6.简述软件测试管理的主要功能。

解:软件测试管理的主要功能是:测试控制对象的编辑和管理;测试流程控制和管理;统计分析和决策支持

7.试选择一个小型的应用系统,做功能测试计划并设计测试用例。

解:略。

第6章 WinRunner测试工具

1.列举几种WR学习软件GUI的不同方式。

解:(1)使用 RapidTest Script wizard 学习软件每个窗体中所有GUI对象的属性。

(2)通过录制脚本的方法学习被录制的那部分软件中所有的GUI对象的属性。

(3)使用GUI Map Editor 学习单个GUI对象、窗体或某个窗体中所有GUI对象的属性。

2.分别简述WR中同步点和检查点的作用。

解:当测试人员执行测试时,所测试的应用程序每次操作的响应时间并不一定,有时快,有时慢,导致执行输入动作的时间也需要等待。在测试脚本中插入同步点,当WinRunner执行到同步点时,会暂停执行以等待应用程序某些状态的改变后,再继续执行,以避免应用程序响应的时间超过 WinRunner 等待的时间而导致测试执行失败。

设定检查点可以检查所设定区域的显示是否和预期结果相符。通过检查点的设置以及对各点处输出信息的编程定义,可以在脚本运行结果单中查看各项测试内容是否都已通过。在功能测试中,检查点可以用在以下两个方面:检查应用程序经过修改后对象状态是否发生变化;检查对象数据是否和预期数据一致。

3.比较WinRunner中GUIde Map File per Test和Global GUI Map File两种模式的区别。

4.简述利用WinRunner进行测试的过程可分为哪几个阶段,即操作步骤是什么?

解:WR的测试过程分为以下六个阶段:(1) 创建GUI map;(2)创建测试;(3)调试测试;

(4)执行测试;(5)查看测试结果;(6)报告发现的错误。

5.给出WinRunner中将测试脚本转换为数据驱动测试脚本的一种实现步骤。

解:可以通过下列步骤将测试脚本转换成数据驱动测试脚本:(1)加上开启及关闭数据表的指令;(2)加上循环并读取数据表的每一笔数据;(3)将录制的固定值与检查点的值参数化为数据表的字段值。

网站首页网站地图 站长统计
All rights reserved Powered by 海文库
copyright ©right 2010-2011。
文档资料库内容来自网络,如有侵犯请联系客服。zhit326@126.com