软件测试基础教材

软

件

测

试

基

础

教

材

目录

第一章软件测试的概述1

1.1软件的相关知识概述1

1.1.1软件的含义1

1.1.2软件的生存周期1

1.1.3软件测试的生命周期3

1.2软件质量保证4

1.2.1软件质量保证(SQA)的定义4

122SQA的目标4

1.2.3SQA的任务4

1.2.4SQA与软件测试的关系5

1.3为什么需要测试6

1.3.1软件系统的重要性6

1.3.2测试和质量6

13.3测试是否充分7

1.3.4测试在软件生命周期中所担当的角色7

1.4软件缺陷与软件故障7

1.4.1软件缺陷的定义和类型7

1.4.2软件缺陷产生的原因8

1.4.3软件缺陷的构成9

1.5软件测试的定义9

1.5.1软件测试的概念9

1.5.2软件测试的目的9

1.5.3软件测试的原则10

1.5.4软件测试的任务10

1.5.5软件测试的职责10

1.6软件测试用例设计11

1.6.1软件测试用例的基本概念和用途11

1.6.2编制测试用例的规范12

1.63测试用例的设计技术及原则13

1.7软件测试工程师的职业素养15

1.7.1软件测试工程师的工作15

1.7.2软件测试工程师的职业素质16

第二章组织和管理测试团队18

2.1测试团队的任务和比例18

2.1.1测试团队的任务18

2.1.2测试人员与开发人员的比例18

2.2测试团队的构成和职责19

2.2.1测试团建的基本构成19

2.2.2测试人员的职责19

2.3测试团队的管理和发展21

23.1树立良好的测试团队意识21

2.3.2激励测试团队的方法22

II

2.3.3从PSP到TSP再到CMM23

2.3.4知识共享和岗位培训25

笫三章黑盒常用测试方法26

3.1等价类划分法26

3.1.1等价类的数学定义26

3.1.2划分等价类26

3.1.3等价类划分的原则26

3.1.4等价类划分法设计测试用例的步骤27

3.1.5等价类划分的类型27

3.1.6用等价类划分法解决一个实例29

3.1.7等价类划分法小结30

3.2边界值分析法30

321边界值分析法概要30

3.2.2边界值分析法的原则31

3.2.3确定边界值分析法取值原则的几种方法31

3.2.4边界值分析法的目标33

3.2.5边界值分析法设计测试用例的步骤33

3.2.6用边界值分析法解决一个实例33

3.2.7边界值分析法小结34

3.3因果图法34

3.3.1因果图法的来源34

332因果图法的特点34

3.3.3原因之间的约束关系35

3.3.4结果之间的约束关系35

3.3.5原因和结果之间的关系35

3.3.6如何根据因果图转换为判定表36

3.3.7因果图法设计测试用例的步骤36

3.3.8用因果图法解决一个实例36

3.3.9因果图法小结39

3.4错误推测法39

3.4.1借识推测法的概念39

3.4.2错误推测方法的基本思想39

3.43错误推测法设计测试用例的步骤40

3.4.4用错误推测法解决一个实例40

3.4.5错误推测法小结40

3.5场景法40

3.5.1场景法介绍40

3.5.2用例场景的定义41

3.5.3为什么引入用例场景41

3.5.4场景法设计测试用例的步骤41

3.5.5用场景法解决一个实例42

3.5.6场景法小结46

第四章使用黑盒测试方法编写测试用例46

4.1规贝I]46

III

4.2阶段划分46

4.3阶段目标47

4.4课后作业47

第五章功能性测试的测试方法一47

5.1软件故障模型48

5.1.1故障模型简介48

5.1.2故障模型框架48

5.2输入非法数据48

5.2.1示例48

522缺陷产生的原因49

5.2.3发现这类问题的方法49

5.2.4小结49

5.3输入默认值50

5.3.1示例50

5.3.2缺陷产生的原因51

5.3.3发现这类问题的方法52

5.3.4小结52

5.4输入特殊字符52

5.4.1示例52

5.4.2缺陷产生的原因52

5.4.3发现这类问题的方法53

5.4.4小结53

5.5输入使缓冲区溢出的数据54

5.5.1示例54

552缺陷产生的原因54

5.53发现这类问题的方法54

5.5.4小结55

5.6输入产生错误的合法数据组合55

5.6.1示例55

5.6.2缺陷产生的原因56

S.6.3发现这类问题的方法56

5.6.4小结57

5.7产生同一个输入的各种可能输出57

5.7.1示例57

5.7.2缺陷产生的原因57

5.73发现这类问题的方法57

5.7.4小结57

5.8产生不符合业务规则的无效输出57

5.8.1示例57

5.8.2缺陷产生的原因58

5.8.3发现这类问题的方法58

5.8.4小结58

第六章功能性测试的测试方法编写测试用例一59

6.1规则59

6.2阶段划分59

6.3阶段目标59

6.4课后作业60

第七章功能性测试的测试方法二60

7.1输出属性修改后的结果60

7.1.1示例60

7.1.2缺陷产生的原因60

7.1.3发现这类问题的方法61

7.1.4小结61

7.2页面刷新61

7.2.1示例61

7.2.2缺陷产生的原因61

7.23发现这类问题的方法61

7.2.4小结62

7.3数据溢出62

7.3.1示例62

7.3.2缺陷产生的原因62

7.3.3发现这类问题的方法62

7.3.4小结63

7.4数据不符合约束条件63

7.4.1示例63

7.4.2缺陷产生的原因63

7.4.3发现这类问题的方法63

7.4.4小结64

7.5操作符导致的问题64

7.5.1示例64

7.5.2缺陷产生的原因64

7.53发现这类问题的方法64

7.5.4小结64

7.6递归调用自身65

7.6.1示例65

7.6.2缺陷产生的原因65

7.63发现这类问题的方法65

7.6.4小结65

7.7计算结果溢出65

7.7.1示例65

7.7.2缺陷产生的原因66

7.73发现这类问题的方法66

7.7.4小结66

7.8数据共享或关联功能计算出错66

7.8.1示例66

7.8.2缺陷产生的原因67

7.8.3发现这类问题的方法67

7.8.4小结68

V

第八章功能性测试的测试方法编写测试用例二68

8.1规贝I」68

8.2阶段划分68

8.3阶段目标68

8.4课后作业69

第九章功能性测试的测试方法三69

9.1文件系统超载69

9.1.1示例69

9.1.2缺陷产生的原因69

9.1.3发现这类问题的方法70

9.1.4小结70

9.2介质忙或不可用70

9.2.1示例70

9.2.2缺陷产生的原因71

9.2.3发现这类问题的方法71

9.2.4小结71

9.3介质损坏72

9.3.1示例72

9.3.2缺陷产生的原因72

9.33发现这类问题的方法72

9.3.4小结72

9.4介质名不合法72

9.4.1示例72

9.4.2缺陷产生的原因72

9.4.3发现这类问题的方法73

9.4.4小结73

9.5设置介质访问权限73

9.5.1示例73

9.5.2缺陷产生的原因74

9.5.3发现这类问题的方法74

9.5.4小结74

9.6文件内容损坏74

9.6.1示例74

962缺陷产生的原因75

9.63发现这类问题的方法75

9.6.4小结75

第十章功能性测试的测试方法编写测试用例三75

10.1规则75

10.2阶段划分76

10.3阶段目标76

10.4课后作业77

第十一章功能和界面的测试方法一77

11.1控件测试77

11.1.1文本框的测试77

11.1.2按钮的测试79

11.1.3单选按钮的测试80

11.1.4复选框的测试81

11.1.5列表框的测试82

11.1.6组和列表框的测试83

11.1.7up-down控件文本框的测试84

11.1.8滚动条的测试86

11.1.9控件混合使用的测试87

第十二章功能和界面的测试方法编写测试用例一89

12.1规则89

12.2阶段划分90

12.3阶段目标90

12.4课后作业91

第十三章功能和界面的测试方法二91

13.1功能测试用例91

13.1.1编辑操作91

13.1.2插入操作92

13.1.3鼠标操作94

13.2界面测试用例95

13.2.1窗体95

13.2.2控件98

13.2.3菜单99

13.2.4特殊属性100

13.2.5界面设计的总体原则101

第十四章功能和界面的测试方法编写测试用例二101

14.1规则101

14.2阶段划分102

14.3阶段目标102

14.4课后作业102

第十五章安装卸载测试方法103

15.1安装卸载测试用例103

15.1.1安装测试103

15.1.2运行测试106

15.1.3卸载测试107

15.1.4加密测试108

第十六章兼容性和易用性测试方法110

16.1设计兼容性测试用例110

16.1.1示例110

16.1.2产生的原因110

16.1.3解决方法111

16.2设计易用性测试用例116

16.2.1易用性测试的内容116

16.2.2界面的标准119

第十七章缺陷管理121

VII

17.1软件缺陷的描述121

17.2软件缺陷的基本组成121

17.3软件缺陷的属性122

17.3.1软件bug的标识123

17.3.2软件bug的类型123

17.3.3软件bug严重程度123

17.3.4软件bug优先级123

17.3.5软件bug状态124

17.3.6软件bug管理常用的工具Bugzilla124

第十八章使用缺陷管理系统136

18.1规则136

18.2阶段划分136

18.3阶段目标136

18.4课后作业138

第十九章软件测试计划与测试策略138

19.1软件测试计划138

19.1.1测试计划规格说明138

19.1.2制定测试计划的目的139

19.1.3制定测试计划的作用139

19.1.4制定测试计划139

19.2软件测试策略142

19.2.1测试策略的概念142

19.2.2影响测试策略的因素142

19.2.3确定测试策略142

19.3风险分析147

19.3.1软件风险分析148

19.3.2如何进行风险分析148

19.3.3计划风险与应急措施154

第二十章制定软件测试计划154

20.1规则154

20.2阶段划分154

20.3阶段目标154

20,4课后作业154

第二十一章软件测试的流程155

21.1软件测试流程155

21.1.1产品调研155

21.1.2测试需求说明156

21.1.3测试的策略和记录156

21.1.4测试资源配置156

21.1.5时间计划表156

21.1.6搭建测试环境156

21.1.7设计测试用例157

21.1.8跟踪缺陷157

21.1.9测试计划评审158

VIII

第二十二章编写缺陷报告161

22.1规则161

22.2阶段划分161

22.3阶段目标162

22.4上机提示162

22.5课后作业162

第二十三章软件评审技术162

23.1软件评审的目的162

23.2评审的度量及应用163

23.2.1软件评审的角色和职能163

23.2.2软件评审流程163

23.2.3评审类型163

2文档评审164

3过程评审164

23.2.4评审方法和技术165

23.3小结166

第二十四章软件测试经验166

24.1测试人员的服务对象166

24.2测试人员关注失效，客户才能关注成功167

24.3什么是“完备的”测试167

24.4能事不关己高高挂起吗168

24.5怎样看待直觉168

24.6关于规格说明书168

24.7”它没有问题”的真正含义169

24.8怎样快速产生测试思路169

24.9是自己的报告成为一种有效的销售工具170

24.10缺陷报告代表的是测试人员170

24.11努力使缺陷报告更有价值171

24.12永远不要假设明显的程序缺陷已经写入报告171

24.13隐藏在缺陷背后的安全隐患171

24.14明确严重登记和优先级的差别172

24.15通过现象看本质172

24.16编写缺陷报告的几条经验性原则172

24.17使用冒烟测试检验版本173

24.18设计测试计划要结合实际情况173

24.19正确认识测试文档模板173

IX

第一章软件测试的概述

1.1软件的相关知识概述

1.1.1软件的含义

软件（英语：Software）是一系列按照特定顺序组织的电脑数据和指令的集合。

一般来说软件被划分为编程语言、系统软件、应用软件和介于这两者之间的中间件。其

中系统软件为计算机使用提供最基本的功能，但是并不针对某一特定应用领域。而应用软件

则恰好相反，不同的应用软件根据用户和所服务的领域提供不同的功能。

软件并不只是包括可以在计算机上运行的电脑程序，与这些电脑程序相关的文档，一般

也被认为是软件的一部分。简单的说，软件就是程序加文档的集合体。软件被应用于世界的

各个领域，对人们的生活和工作都产生了深远的影响。

其中：

•程序是按事先设计的功能和性能要求执行的指令序列。

•文档是与程序开发、维护和使用有关的图文材料。

1.1.2软件的生存周期

软件生命周期（SDLC,SystemsDevelopmentLifeCycle,SDLC）是软件的产生直到报废或停止使

用的生命周期。

周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运

行、维护升级到废弃等阶段，这种按时间分层的思想方法是软件工程中的一种思想原则，即

按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提

高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指

导意义正在逐步减少。

•瀑布模型

瀑布模型是将软件生命周期的各项活动规定为依照固定顺序连接的若干阶段工作，形如瀑布

流水（如下图所示），最终得到软件产品。在每一个阶段结束时，项目小组进行审查，并决

定是否进入下一步。

1

•螺旋模型

1988年，BarryBoehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型

模蛰结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

•迭代模型

迭代式模型是RUP（RationalUn而edProcess,统一软件开发过程，统一软件过程）推荐的周

期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）

的全部开发活动和使用该发布必需的所有其他外围元素。

所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）

需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的

瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会

产生一个可以发布的产品，这个产品是最终产品的一个子集。

2

迭代

第一次送代第二次迭代••••••第N次迭代

强

信求分析中

弱//\,，0

强_____?、上

7

项目计划中—

1

弱/9丁

强:

播要设计中一:-7

弱T—

/

强1

详细设计中1

-/1N

弱-"广*-,

9P

强—

编同及单元4试中1-H

11

弱B1

强11

/f

集成测试中■一

j1

弱Y■­11

1

强一；r1

系统溯试中

X7

弱7\}'

1.1.3软件测试的生命周期

通过学习软件生命周期的瀑布模型、螺旋模型以及迭代模型，可以了解软件产品开发的

基本过程。那么，软件测试的生命周期又是什么样子？如下图所示，展示了软件测试的生命

周期。

0始一）

需求调研

/^\通

过

＜性评＞-T准备:段

制定测试一

不通过

＜评审J＞—T

不通过过

执行测试

调优阶段”

WJuLi/

（结束）-报告阶段y［达标）＞~

3

实践证明，尽管人们在开发软件的过程中使用了许多保证软件质量的方法和技术，但开

发出的软件中还会隐藏许多错误和缺陷。规模大、复杂性高的软件更是如此。所以。严格的

软件测试对于保证软件质量具有重要作用。

1.2软件质量保证

1.2.1软件质量保证(SQA)的定义

软件质量保证(SQA-So代wareQualityAssurance)是建立一套有计划，有系统的方法，来向

管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活

动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立

计划、标准和过程。这些将使软件项目满足机构方针的要求。

1.2.2SQA的目标

•遵循《软件质量保证计划》进行软件质量保证活动；

•客观地验证软件开发过程和软件产品是否遵守可用的标准、规程和要求：

•确保将软件质量保证的活动和结果通知受影响的项目组和人员；

・高层管理者关注在软件项目中不能解决的偏差事件和不合格项。

1.2.3SQA的任务

•SQA参与制定计划

SQA参与制定计划包括SDP和阶段计划，在SDP活动中，SQA主要是参与到软件过程

的剪裁、复审估算、参与评估风险等。然后，SQA参与复审SDP,其目的，除了熟悉项目的

计划外，还需要复审查看是否SDP与纳入项目的客户的需求一致，计划能否满足客户的需

求的，在SDP修正中，涉及到上述内容的，也需要SQA参与。然后，SQA也会参与阶段计

划的制定，主要是复审阶段计划是否满足阶段的目标。

•SQA参与复审纳入项目的需求

此时SQA主要是作为嵬审者的角色,第审纳入的需求描述是否清晰、一致、需求的可

行性等。

•SQA制定SQA审计计划

在制定计划的同时，SQA也需要制定SQA审计计划，在制定SDP的时候，SQA制高层

的审计计划，主要是计划有那些内容需要SQA审计的。然后，在制定阶段计划的时候，SQA

需要制定具体的审计计划，包括每次审计的时间，审计的对象等。

•SQA参与进度复审或里程碑复审活动

SQA在参与进度复审或里程碑复审活动中，主要是一方面了解项目的进度，另一方面,

复审项目在进度复审中采取的一些修正行动的时候，是否满足客户的需求，是否可行等，而

在里程碑复审中，则复审项目当前的状态是否满足里程碑的标准(CriteriaofMilestone),是否

达到里程碑的目标。

•SQA审计

另外，SQA的主要活动是按照制定的SQA审计计划对项目进行审计，审计的内容包括

过程审计和工作产品审计。过程审计主要是审计项目开展的软件活动是否和计划、与OSSP

4

一致，工作产品审计主要是审计工作产品是否满足标准和约束条件。

•SQA阶段总结

由于公司很多项目都是采用迭代模式的开发，项目开发周期较长，所以有必要在项目某

个阶段结束的时候，对SQA在这个阶段的活动进行一个总结，主要是对一些经验教训进行

分析，找出这些问题背后的原因，提出一些可行性的解决方案，目的是为了提高质量保证的

水平。

•跟踪问题处理

SQA应跟踪问题处理过程，直到问题解决。跟踪的问题包括日常发现的产品问题、过程

问题、项目风险、评审发现的问题、测试发现的问题等。如果不能和项目组就解决方案达成

一致，可向公司高层反映。

•度量和报告

SQA应善于根据过程规范和经验发现项目运行中的问题，并做到紧急问题、重要问题随

时汇报，其它问题周期性汇报.SQA需要随时收集数据并保障数据的有效性、真实性。定期

汇总数据、统计分析并产生度量报告。SQA应协助项目组和SEPG针对不良趋势和问题采取

纠正或预防措施。

•质量推进

质量推进主要包括提高全员的质量意识和推进、解释过程的执行两个方面。这项工作需

要在日常工作中循序渐进地、坚持不懈地实施，这样做的目的是为了营造公司的一种质量文

化氛围，理解和支持SQA的工作。

・过程制定

如果项目或组织需要制定过程规范，SQA应组织相关人员来完成过程制定工作。一般情

况下，过程制定应由遵守和执行该过程的人员负责。所有制定的过程都必须经过评审，并由

SQA检查执行情况。

•过程改进

过程改进是一项长期的任务。SQA应注意随时发现、听取过程执行中问题和改进工作的

方法，并进行阶段性的总结（比如质量报告等），以不断改进过程，提高过程能力。

•学习和研究

SQA要不断学习和研究，尽量保持与领域最新的知识、方法同步，找出提高产品质量和

工作效率的方法与过程。学习的内容主要包括管理领域和开发领域。管理领域包括质量管理

（TQM、IS09000、CMM、RUP、MSF、XP等）、软件度量（PSM、GQM、SPC、SixSigma）、

项目管理、配置管理等。开发领域包括需求工程、设计、编码、测试等各阶段的开发和管理

方法。

•质量培训

项目或组织需要时，SQA需要向相关人员进行质量管理方面的培训或咨询。

1.2.4SQA与软件测试的关系

软件测试和软件质量保证是软件质量工程的两个不同层面的工作。软件测试只是软件质

量保证工作的一个重要环节。

软件测试（SQC）是为使产品满足质量要求所采取的作业技术和活动，它包括检验、纠

正和反馈。比如SQC进行检验发现不良品后将其剔除，然后将不良信息反馈给相关部门采

取改善措施。因此SQC的控制范围主要是在工厂内部，其目的是防止不合格品投入、转序、

出厂。确保产品满足质量要求及只有合格品才能交付给客户。

软件质量保证（SQA）是为满足顾客要求提供信任，即使顾客确信你提供的产品能满足

他的要求。因此需从市场调查开始及以后的评审客户要求、产品开发、接单及物料采购、进

5

料检验、生产过程控制及出货、售后服务等各阶段留下证据，证实工厂每一步活动都是按客

户要求进行的。

1.3为什么需要测试

131软件系统的重要性

计算机是由硬件和软件组成，而操作系统就是基础的软件，它控制和管理计算机的软硬

件资源，如果没有它，硬件将是一堆废铁，除非你会用01代码。其他的应用软件就是所有

工作与生活中的主要或辅助工具，那么，计算机软件的重要性包括哪些呢？

操作系统的作用主要体现在以下两仝方面：管理系统中的各种资源，包括硬件资源和软

件资源。

在计算机系统中，所有硬件部件（如CPU、存储器、输入/输出设备等）称为硬件资源；

而程序和数据等信息称为软件资源。

操作系统对每一种资源的管理都必须进行以下几项工作：

•决定分配资源策略

包括选择某种资源分配策略，决定谁有权限可以获得这种资源，何时可以获得，可以获

得多少，如何退回资源等等。

•监视资源

监视资源包括需要知道该资源有多少，资源的状态如何，它们都在哪里，谁在使用，可

供分配的又有多少，资源的使用历史等等。

•回收资源

回收资源是指在使用者放弃某种资源之后，对该种资源进行善后处理，如果是可重复使

用的资源，则进行回收、整理，以备再次使用。

•分配资源

分配资源是指按照已决定的资源分配策略，对符合条件的申请者分配某种资源，并进行

相应的管理事务处理。

13.2测试和质量

软件测试和软件质量保证是软件质量工程的两个不同层面的工作。软件测试只是软件质

量保证工作的一个重要环节。

软件测试是为使产品满足质量要求所采取的作业技术和活动，它包括检验、纠正和反馈。

比如软件测试进行检验发现不良品后将其剔除，然后将不良信息反馈给相关部门采取改善措

施。因此软件测试的控制范围主要是在工厂内部，其目的是防止不合格品投入、转序、出厂。

确保产品满足质量要求及只有合格品才能交付给客户。

软件质量保证是为满足顾客要求提供信任，即使顾客确信你提供的产品能满足他的要求。

软件质量保证的目的不是为了保证产品质量，保证产品质量是软件测试的任务。

软件质量保证主要是提供确信。因此需对了解客户要求开始至售后服务的全过程进行管

理。这就要求企业建立品管体系，制订相应的文件规范各过程的活动并留下活动实施的证据，

以便提供信任。软件测试和软件质量保证的主要区别前者是保证产品质量符合规定，后者是

建立体系并确保体系按要求运作，以提供内外部的信任。同时软件测试和软件质量保证又有

相同点：即软件测试和软件质量保证都要进行验证，如软件测试按标准检测产品就是验证产

品是否符合规定要求，软件质量保证的内审，就是验证体系运作是否符合标准要求。

6

测试并非像大家平时认知的那样，不动脑,天天对着屏幕点鼠标，虽然做测试门槛不高，

但真正能做好做精，更需要正确的方法和勤奋的学习。

1.3.3测试是否充分

一个成功的测试包括两个主要方面：一是软件在所有的（或足够多的）测试用例上是正

确的;二是测试用例是充分的，即软件在测试用例上的表现能够充分地反应软件的总体表现。

软件测试的充分性是从软件在有限多个测试用例上的行为判断软件在所有输入数据上

的行为的逻辑基础。良好的软件测试充分性准则应该具有如下基本性质：

•空测试对任何软件都是不充分的。空测试用例集意味着软件未被测试。

•对任何软件都存在有限的充分测试集合。因为测试必须在有限的时间内完成，所以充分

的测试集合必须是有限的。这一性质成为有限性。

•如果一个软件系统在一个测试用例集合上的测试是充分的，那么再多测一些数据也应该

是充分的。这一性质成为单调性。

•及时对软件所有成分都进行了充分的测试，也并不意味着整个软件的测试已经充分了。

这一性质称为反复合性。

•即使对一个软件系统整体的测试是充分的，也并不意味着软件系统中各个成分都已经充

分地得到了测试。这一性质称为反分解性。

•软件测试的充分性应该与软件的需求和软件的实现都相关。

•软件越复杂，需要测试的数据也越多。这一性质成为复杂性。

•测试得越多，进一步测试所能得到的充分性增长就越少。

13.4测试在软件生命周期中所担当的角色

在任何生命周期模型中，一个好的测试都应该具有下面几个特点：

•每个开发活动都有相对应的测试活动；（开发需要测试来验证）

•每个测试级别都有其特有的测试目标；

•对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计；

•在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审。

1.4软件缺陷与软件故障

1.4.1软件缺陷的定义和类型

软件缺陷（Defect）,常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在

的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。缺陷的存在会导致软件产品

在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看,

缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题：从产品外部看，缺陷是系

统所需要实现的某种功能的失效或违背。

软件缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型：

•软件没有实现产品规格说明所要求的功能模块；

•软件中出现了产品规格说明指明不应该出现的错误；

•软件实现了产品规格说明没有提到的功能模块；

•软件没有实现虽然产品规格说明没有明确提及但应该实现的目；

7

•软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。

1.4.2软件缺陷产生的原因

在软件开发的过程中，软件缺陷的产生是不可避免的。那么造成软件缺陷的主要原因有

哪些？从软件本身、团队工作和技术问题等角度分析，就可以了解造成软件缺陷的主要因素。

软件缺陷的产生主要是由软件产品的特点和开发过程决定的。主要有以下几个方面：

从软件本身角度考虑：

•需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。

•系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不

到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、

类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法

调用、对象状态变化等方面问题。

•对程序逻辑路径数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错

误。

•对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时

间上不协调，不一致性带来的问题。

•没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统

安全性、可靠性的隐患。

•系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式

或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数

据量很大。从而会引起强度或负载问题。

•由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。

•新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

从团队工作角度考虑：

•系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。

•不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差,

编程人员对系统设计规格说明书某些内容重视不够，或存在误解。

•对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。

•项目组成员技术水平参差不齐，新员工较多，或培训不够等原因也容易引起问题。

从技术方面考虑：

・算法错误：在给定条件下没能给出正确或准确的结果。

•语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，

只能在测试运行时发现。

•计算和精度问题：计算的结果没有满足所需要的精度。

•系统结构不合理、算法选择不科学，造成系统性能低下。

•接口参数传递不匹配，导致模块集成出现问题。

•从项目管理问题角度考虑：

•缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容

易挤掉需求分析、评审、测试等时间，遗留的缺陷会比较多。

•由于技术欠佳，系统分析时，对客户的需求了解不透彻，或者和用户的沟通存在一些困

难。

•开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进

行，工作不够充分，结果也就不完整。不准确，错误较多；周期短，还给各类开发人员

造成太大的压力，引起一些人为的错误。

8

•开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。

•文档不完善，风险评估不足等。

1.4.3软件缺陷的构成

软件缺陷是由：属性名称、措述、缺陷标识(Identifier)构成的。缺陷标识是标记某个

缺陷的一组符号。每个缺陷必须有一个唯一的标识缺陷类型(Type),缺陷类型是根据缺陷

的自然属性划分的缺陷种类。缺陷严重程度(Severity)缺陷严重程度是指因缺陷引起的故

障对软件产品的影响程度。缺陷优先级(Priority)缺陷的优先级指缺陷必须被修夏的紧急程

度。缺陷状态(Status)缺陷状态指缺陷通过一个跟踪修复过程的进展情况。缺陷起源(Origin)

缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。缺陷来源(Source)缺陷来源指

引起缺陷的起因。缺陷根源(RootCause)缺陷根源指发生错误的根本因素。

1.5软件测试的定义

1.5.1软件测试的概念

在1979年出版的一本经典著作《软件测试艺术》中，对软件测试进行了这样的定义：

软件测试就是“为了发现错误而执行程序或者系统的过程”。这一定义明确了软件测试的根

本目的是为了发现程序中的错误。Myers撰写该著作的时期，软件测试通常在软件产品开发

的后期开始，主要目的就是寻找产品运行过程中的缺陷。因此，他对软件测试所下的这一定

义被人们广泛接受，反映了人们在当时对软件测试所持的观点。随着这一定义被广泛使用，

人们发现了定义中存在的不足。于是，1983年在IEEE提出的软件工程标准术语中，调整了

对软件测试的定义，即“使用人工或自动手段来运行或测试某个系统的过程，其目的在于检

验它是否满足规定的需求或弄清预期结果与实际结果之间的差别二更新后的定义除吸收了

从前人们对软件测试定义中的精华外，还明确指出，软件测试作为保证软件质量的一个重要

手段，其主要任务是在已设计测试用例的基础上检验软件各个部分，以及整个系统是否正确、

完整地实现了预定的功能，以确保软件质量。今天，人们对软件测试有了更进一步的认识,

从广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。例如。设计评审、

单元测试、系统测试。从狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软

件产品质量中存在的质量问题，同时对产品质量进行客观的评价。现代软件开发领域的人多

数工作者都对测试有直观的认识，最常见的看法如下：

•保证程序和相应的规范说明一致。

•发现软件中的缺陷。

•确保软件不做不必要的事情。

•确保系统合理地执行。

•明确在系统失败之前可以让系统正常运行到何种程度。

•明确发布给用户的系统中有哪些风险。

1.5.2软件测试的目的

基于不同的立场，存在着两种完全不同的测试目的。从用户的角度出发，普遍希望通过

软件测试暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。从软件开发者的角度出

发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的

9

要求，确立人们对软件质量的信心。GrenfordJ.Myers曾对软件测试的目的提出过以下观点：

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

•好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

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

换言之，测试的目的是想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺

陷。如果我们成功地实施了测试，我们就能够发现软件中的错误。测试的附带收获是，它能

够证明软件的功能和性能与需求说明相符合。实施测试收集到的测试结果数据为可靠性分析

提供了依据。测试不能表明软件中不存在错误，它只能说明软件中存在错误。

然而，这种观点指出测试是以查找错误为中心，而不是为了演示软件的正确功能。但是

只从字面意思理解，可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误

的测试就是没有价值的测试，实际上并非如此！

•测试并不仅仅是为了找出错误。通过分析错误产生的原因和错误的发生趋势，可以帮助

项目管理者发现当前软件开发过程中的缺陷，以便及时改进；

•这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性；

•没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。

1.5.3软件测试的原则

•应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭；

•测试用例应由测试输入数据和对应的预期输出结果这两部分组成；

・程序员应避免检查自己的程序；

•在设计测试用例时，应包括合理的输入条件和不合理的输入条件；

•充分注意测试中的群集现象。经验表明测试后程序中残存错误数目与该程序中己发现的

错误数目成正比；

•严格执行测试计划，排除测试的随意性；

•应当对每一个测试结果做全面检查；

•妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。

1.5.4软件测试的任务

•根据软件测试各个阶段会有如下几方面的任务：

•制定测试大纲；

•制作测试数据；

・单元测试（程序测试）；

・功能测试；

・性能测试；

•集成测试（子系统测试）；

•系统测试；

•验收测试；

•写出测试报告书；

•提交下一阶段工作所需的系统运行、维护手册的草案。

1.5.5软件测试的职责

•根据软件设计需求制定测试计划，设计测试数据和测试用例；

10

•有效地执行测试用例，提交测试报告；

•准确地定位并跟踪问题，推动问题及时合理地解决；

•完成对产品的集成测试与系统测试，对产品的软件功能、性能及其它方面的测试。

1.6软件测试用例设计

1.6.1软件测试用例的基本概念和用途

学员在学习过程中会遇到以下类似问题：不知道是否较全面地测试了所有内容，测试的

覆盖率无法衡量，对新版本的重复测试很难实施，存在大量冗余测试影响测试效率等。接下

来将采用编写测试用例的方法解决以上提及的问题。

测试用例是指为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期

望结果的一个特定的集合。测试压例控制软件测试的执行过程，它是对每个测试项目的进一

步实例化。换句话说，测试用例就是记下要进行什么测试，进行测试的具体步骤，以及测试

执行是否正确的标准。测试用例来自于测试需求，它是对测试需求的一个细化，它是整个测

试的基础，测试用例覆盖系统的程度决定了测试的覆盖程度。如果没有测试用例，就只能按

照测试人员的心情进行测试了。

测试用例的编写是个费时费力的事情,通常编写测试用例的时间比实际执行测试的时间

还要长。许多人对编写测试用例的原因很不理解，他们认为功能测试只要对应着的需求或者

程序的菜单一项项地去测试就可以了，这样写来写去很浪费时间，而且有没有什么实际意义，

不如多花时间去执行测试。其实编写测试用例的好处主要表现在以下几个方面：

•组织性：

编写测试用例有利于测试的组织。在开始实施测试之前设计好测试用例。可以避免盲目

测试，并可以提高测试效率。

•功能覆盖：

测试用例可以确保功能不被遗漏。要确保所开发的软件能让最终用户满意，最好的办法

就是明确阐述最终用户的期望，对这些期望进行核实并确认其有效性，测试用例直接反

应了这些要核实的需求，令测试的实施重点突出、目的明确，以确保用户需要的功能不

被遗漏。

•重复性：

在项目进行期间对不同软件版本必须要多次重复执行同样的测试，以寻找新的软件缺陷,

保证老的软件缺陷已被修复。没有测试用例光凭脑子不可能记住执行了哪些测试用例及

执行情况，这样就很难重复原有的测试。

•跟踪：

通过对测试用例的统计，例如统计执行了多少测试用例？多少通过？多少失败？以确定

下一步测试的重点，缺陷多的模块可以在后续的测试中重点进行测试。

•测试确认：

在少数高风险的测试中，例如医疗、航天等行业。不允许出现任何问题，必须证明却是

按照计划执行了所有的测试用例。发布忽略了某些测试用例的软件是十分危险的。通过

测试用例可以对测试过程进行有效的监督，可以准确、有效地评估测试，并对测试是否

完成有个量化的结果。

11

1.6.2编制测试用例的规范

•对于每个功能，从类型1至类型N依次撰写相应用例；

•对于不满足要求的非常规类型，可以不写相应的用例；

•对于边界、空值、格式错误、溢出这几个类型，一个功能如有多个数据项测试类型相同，

则可以放在一个用例里；

•测试用例均为最小的用例覆盖要求：对于没有提及的用例类型，根据业务需求情况，撰

写相应用例；

•在测试过程中，输入数据可在测试用例规定的范围内做一定变化。

常规的测试用例：

•对于一个功能一个模块（页面），每个数据项输入或选中典型的取值，生成一个用例；

•对于一个功能多个模块（页面），多个模块（页面）一起生成一个用例；

•对于多个功能一个模块（页面），每个功能生成一个用例；

•每个功能操作需覆盖，如删除对话框点击确定、取消分别生成2个用例步骤；

•输入框测试，在允许范围内尽可能覆盖多的字符类别，如中文、英文、数字等；

•对于每个功能点，必须通过一组（一个或多个）用例满足其业务覆盖：对于某条记录的

每个状态，对于能进行的每个操作，都生成一个用例（即对业务功能流程中的每个角色，

每个功能操作，生成一个用例）。

初始化的测试用例：

进入功能模块（页面）后，某些控件会初始化填入数据，生成一个用例确保所有的初始

数据正确。

边界的测试用例：

•每个数据项，生成一个边界用例（含最大、最小两个边界值）；

•字符串数据以字符串长度为计量单位；

•布尔值数据的所有取值都需测试；

•