软件测试理解

软件缺陷与故障
1.软件缺陷和软件故障案例
当今人类的生存和发展已经离不开各种各样的信息服务，为了获取这些信息，需要计算机网络或通信网络的支持，这里包含着不公需要计算机硬件等基础设施或设备，还需要程式各样的、功能各异的计算机软件。

软件在电子信息领域时辰我处不在。

然而，软件是由人编写开发的，是一种逻辑思维的产品，尽管现在软件开发都采取了一系列有效措施，不断地提高软件开发的质量，但仍然无法完全避免软件（产品）会存在各种各样的缺陷。

对于软件故障或缺陷，依据危害程度的不同，可分为轻、重不同级别。

以下是六例软件缺陷和故障的案例分析，借此说明软件缺陷和故障问题有时会造成的相当严重的损失和灾难。

（1）美国迪斯尼公司的狮子王游戏软件bug。

这是一个典型的软件兼容性问题。

1994年，美国迪斯尼公司发布向少年儿童的多媒体游戏软件“狮子王动画故事书”。

经过迪斯尼公司的大力促销活动，销售异常地火爆，使该软件游戏几乎成为当年秋季全美少年儿童必买的游戏。

但产品售后不久，该公司的客户支持部的电话就一直不断，愤怒的儿童家长和玩不成游戏的孩子们大量投拆该游戏软件的缺陷，一时间各种报纸和电视媒体也大量报道了这一游戏软件的各种问题。

后经调查证实，造成这一严重问题的原因是迪斯尼公司没有对该游戏软件在已投入市场上使用的各种PC机型上进行正确的测试，也就是说游戏软件对硬件环境的兼容性没有得到保证。

该游戏软件的开发该程序的程序员的机器硬件系统上工件是政党的，但在大众使用的常见系统中却存在不兼容问题。

该软件故障使迪斯尼公司声誉大损，并为改正软件缺陷和故障付出了沉重的代价。

（2）美国航天局火星登陆事故。

1992年月日2月3日，美国航天局的火星极地登陆飞船在试图登陆火星表面时突然失踪。

负责这一太空发展项目的错误修正委员会的专家们观测到的并分析了这一故障，确定出现该故障的原因可能是由于某一数据们被意外地更改，而造成灾难性的后果，并得出该问题应该在内部测试时就予以解决的结论。

简要地说，火星登陆的过程是这样的：当飞船快要降落到火星表面时，它将打开着陆降落伞以减缓飞船的下落速度。

在降落伞打开后的几秒钟内，飞船的三条支撑脚将迅速撑开，并在预定的地点着陆。

在飞船距离火星表面1800y高空时，飞船将丢弃降落伞，同进点燃登陆推进器，控制稳定飞船的下降速度，使其在余下高度里缓慢降落到火星表面。

然而，美国航天局为了节省研制经费，简化了确定何时关闭登陆推进器的装置。

为了替代其他大空船上通常使用的贵重的着陆雷达系统，设计师们在登陆飞船的支撑脚上安装了一个简易廉价的触电开关，并在计算机中设置了一个数据们来控制关闭登陆推进器的燃料。

很明确，飞船的支撑腿在没有着地之前，推进器引擎就会一直处于着火工作状态。

遗憾的是，在事后的分析测试中发现，当飞船的支撑脚迅速打开准备着陆时，机械震动很容易触发着地触电开关，导致设置了错误的数据位，关闭了登陆推进器的燃料。

设想当飞船开始进入着陆动作时，由于机械震动的缘故，触发了着地触电开关，计算机极有可能关闭了推进器的燃料，也就是说使得登陆推进器提前停止了工作，使火星登陆飞船加速下坠1800m之后直接冲向火星表面，撞成碎片。

这一事故的后果非常严重，损失巨大，然而起因却如此简单，是软件设计中的缺陷。

事实是飞船登陆飞行发射之前，飞船各部位的工作过程经过了多个小组的测试，其中一个小组测试飞船的支撑脚落地打开过程，另一个小组测试此后的着陆过程。

前一个小组没有注意到着陆数据位是否已经置位，因为这不属于他们负责的范围；而后一个小组总是在开始测试之前重置计算机，进行数据的初始化，清除数据位。

双方的独立工作都很
好，但从未在一起进行过集成（系统）测试，使系统测试中的衔接问题隐藏起来，从而导致了这一灾难性事故的发生。

（3）跨世纪“千年虫”问题。

这是一个非常著名的计算机软件缺陷问题，在上世纪末的最后几年中，全世界的各类计算机硬件系统、软件系统和应用系统都为“千年虫”问题而付出了巨大的代价。

20世纪70年代，一位负责开发公司工资系统的程序员当时所使用的计算机内存空间很小，迫使他在程序设计时要考虑节省每一个字节，以减少对系统内存的占用。

其中节约内存的措施之一就是把表示年份的4位数，例如1973，缩减为2位，即73。

因为工资系统极度依赖数据处理，会有大量的数据占用内存空间，所以节约每一个字节的意义很大，该程序员的这一方法确实节省了可观的存储空间。

他采用这一措施的出发点主要是认为只有在到了2000年时程序在计算00或01这样的年份时才会出现问题，但在到达2000年时，程序早已不用或都修改升级了。

而在1995年，这位程序员退休了，但他所编制的程序仍在使用，没有谁会想到进入程序去检查2000年兼容的问题，更不用说去做修改了。

计算机系统在处理2000年份问题（以及与年份相关的其他问题）时，软、硬件系统中存在的问题隐患被业界称为“千年虫”的问题。

据不完全统计，从1998年初全球开始进行“千年虫”问题的大检查，特别是金融、保险、军事、科学、商务等领域花费了大量的人力、物力对现有的各种各样的程序进行检查、修改和更正，据有关资料统计，公此项费用就达数百亿美元。

（4）爱国者导弹防御系统炸死自家人。

美国爱国者导弹系统首次应用于海湾战争中，以对抗伊拉克的飞毛腿系统。

尽管爱国者导弹防御系统在这次战争中屡建功勋，多次成功拦截飞毛腿导弹，但确实也有几次在对抗中失利，其中有一枚爱国者导弹在沙特阿拉伯的多哈炸死了28名美军士兵。

事后，分析专家得出造祸于这一结果的结论是爱国都导弹防御系统中一个软件系统的缺陷所致。

一个很小的系统时钏错误积累起来就可能延时14个小时，造成跟踪推动准确度。

在那次的多哈袭击战中，导弹系统的重要时刻被延时100多个小时，造成了这一慧剧。

（5）Windows 2000中文输入法漏洞。

在安装微软的Windows 2000简体中文版的过程中，在默认情况下会同进安装各种简体中文输入法。

随后这些装入的输入法可以在Windows 2000系统用户登录界面中使用，以便用户能够使用基于字符的用户表示和密码登录系统。

然而，在默认安装的情况下，Windows 2000中的简体中文输入法不能正确检测当前的状态，导致了在系统登录界面中提供了不应有的功能，即出现了下面的问题：
在Windows 2000用户登录界面中，当用户输入用户名时，用Crtl+Shift组合键将输入法切换到全拼输入法状态下，同时在登录界面的屏幕的左下角将出现输入法状态条。

用鼠标右键单击状态条并在出现的菜单中选择“帮助”项，再将鼠标移到“帮助”项上，在弹出选择项里选择“输入法入门”，随后即弹出“输入法操作指南”帮助窗口。

再用鼠标右键单击“选项”，并选择“跳至URL”，此时将出现Windows 2000的系统安装路径并要求填入路径的空白栏。

如果该操作系统安装在C盘上，在空白栏中填入“C：\windowsnt\system32”，并单击“确定”按钮，在“输入法操作指南”右边的框里就公出现C:\widowsnt\system32目录下的内容了。

也就是说这样的操作成功地了身份的难顺利地进入了系统的system32目录，当然也说可以进行各种各样的操作了。

此软件缺陷被披露后，微软公司推出了该输入法的漏洞补丁，并在Windows 2000 Server Pack2以后的补丁中都包含了对该漏洞的修补，但对于没有进行打补丁的用户来说，系统仍处于不安全的状态之中。

（6）金山词霸bug。

在国内，“金山词霸”是一个很著名的词典软件，应用范围极
大，对使用中文操作的用户帮助很大，但它也存在不少bug。

例如输入“dynamically”（力学，动力学），词霸会出现其他不同的单词“dynamite n.炸药”的显示错误。

诸如上述的软件错误或漏洞不仅仅是这几例，一些著名软件的缺陷、错误经常在Internet 上被用户披露或者指出，同时也不断有经过个性的软件版本在发布。

2.软件缺陷定义
从以上软件故障或缺陷的实例中可以看到软件发生错误时造成的灾难性危害或对用户的各种影响。

那么，这些事件的共同特点有哪些呢？首先，软件开发过程可能没有按照预期的规则或目标要求进行；其次，软件虽然都经过了测试，但并不能保证完全排队了存在（特别是潜在）的错误。

对于软件测试来说，其任务就是要发现软件中所隐藏的错误，找出那些不明显的、小到难以察觉的、简单而细微的错误，达到这具目的，这是对软件测试人员的最大挑战。

上述所有实例中的软件问题在软件工程或软件测试中都被称为软件缺陷或软件故障。

在不引起误解的情况下，不管软件存在问题的规模和危害是大还是小，由于都会产生软件使用上的各种障碍，所以将这些问题统称为软件缺陷。

对于软件缺陷的精确定义，通常有下列5条描述：
（1）软件未达到产品说明书中标明的功能；
（2）软件出现了产品说明书中指明不会出现的错误；
（3）软件未达到产品说明书中虽未指出但应当达到的目标；
（4）软件功能超出了产品说明书指明的范围；
（5）软件测试人员认为软件难以理解、不易使用，或者最终认为该软件使用效果不良。

为了对于上5条描述进行理解，这里以日常我们所使用的计算器内的嵌入式软件来说明上述每条定义的规则。

计算器说明书一般声称该计算器将准确无误确地进行加、减、乘、除运算。

如果测试人员或用户按选定了两个数值后，随意按下了“+”号键，结果没有任何反应，根据每一条规则，这是一个软件缺陷；如果得到错误答案，根据每条规则，同样是软件缺陷。

假如计算器产品说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按敲键盘后，计算器停止接受输入或没有了反应，根据第二条规则，这也是一个软件缺陷。

若在进行测试时，发现聊了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定，根据第三条规则，这也是软件缺陷。

若在进行测试过程中发现，因为电池没电而导致了计算不正确，但半成品说明书未能指出在此情况下应如何进行处理，根据第四条规则，这也应算做软件缺陷。

第五条的规则说明了无论测试人员或者是最终用户，若发现计算器某些地方不好用，比如，按键太小，显示屏在亮光下无法看清等，也都应算做是软件缺陷。

3.软件缺陷的特征
软件缺陷的特征的两个。

软件缺陷的第一个特征是软件的特殊性决定了缺陷不易看到，即“看不到”；第二个特征是发现了缺陷，但不易找到问题发生的原因所在，即“看到但是抓不到”。

通过大量的测试理论研究及测试实践经验的积累，典型的软件缺陷产生的原因被归纳为以下几种类型：
（1）需求解释有错误；
（2）用户需求定义错误；
（3）需求记录错误；
（4）设计说明有误；
（5）编码说明有误；
（6）程序代码有误；
（7）数据输入有误；
（8）测试错误；
（9）问题修改不正确；
（10）不正确的结果是由于其他的缺陷而产生。

二软件缺陷产生的原因
软件测试是在软件投入运行之前，对软件需求分析、设计规格说明和编码实现的最
终审定。

那为什么还会产生软件缺陷呢？经过软件测试专家们的研究发现，表现在程序
中的故障并不一定是由编码过程所引起的，大多数的软件缺陷并非来自编码过程中的错
误，从小项目到大项目都基本上证明了这一点。

因其软件缺陷很可能是在系统详细设计
阶段、概要设计阶段，甚至是在需求分析阶段就存在的问题所导致，即使是针对源程序
进行的测试所发现的故障的根源也可能存在于软件开发前期的各个阶段。

大量的事实表
明，导致软件缺陷的最大原因是软件产品说明书。

在多数情况下，软件产品说明书并没Array有写得明确、清楚或者描述不全面，或者
在软件开发过程中对过程中对需求、产品
功能经常更改，或者开发小组的人员之间
没有很好地进行交流与沟通，没有很好地
组织开发与测试流程。

因为，制作软件产
品开发计划是非常重要的，如果计划没有
做好，软件缺陷就会出现，这在所难免。

软件缺陷产生的第二大来源是设计方
案，这是实施软件计划的关键环节。

如图1.1所示是软件缺陷产生的原因
分布图，图中占据大部分的是由于软件产
品说明书（需求）而产生的软件缺陷。

测试步骤：测试步骤详细规定了如何设置、执行、评估特定的测试用例。

如图 1.2
所示是一个测试生命周期模型。

其中：（1）、（2）、（3）可能引入故障，或导致其他阶段的故障，为第一阶段；
（4）测试发现事故，为第二阶段；
（5）、（6）、（7）清除故障，为第三阶段；
（7）在故障排除的过程中可能使以前正确招待的程序出现错误，引入了新的故障。

三软件测试的基本问题
一个软件生命周期包括制定计划、需求分析定义、软件设计、程序编码、软件测试、软件运行、软件维护、软件停用等8个阶段。

软件测试的根本目的是为了保证软件质量。

ANSI/IEEE Std 729-1983 文件中，软件质量反映以下三个方面：
①软件需求是度量软件质量的基础。

②在各种标准中定义开发准则，用来指导软件人员用工程化的方法来开发软件。

③往往会有一些隐藏的需求没有明确的提出。

如果软件只满足那些精确定义的需
求，而没有满足那些隐含的需求，软件质量也不能得到保证。

软件质量内涵包括：正确性、可靠性、可维护性、可读性（文档、注释）、结构化可测试性、可移植性、可扩展性、用户界面友好性、易学、易用、健壮性。

软件测试的对象：软件测试不仅仅是对程序的测试，而是贯穿于软件定义和开发的整个过程。

因此，软件开发过程中的产生的需求分析、概要设计、详细设计以及编码等各个阶段所得到的文档，包括需求规格说明、详细设计、运行、直到结束使用的全过程中，主要横跨以下两个测试阶段。

第一个阶段：单元测试阶段，即在每个模块编写出以后所做的必要测试。

第二个阶段：综合测试阶段，即在完成单元测试后进行的测试，如集成测试、系统测试、验收测试等。

软件测试设计的关键问题包括以下四个方面：
⑴测试由谁来执行。

通常软件产品的开发设计包括开发者和测试者两种角色。

开发
者通过开发而形成产品，如以下所列的分析、设计、编码调试或文档编制等。

测试者通过测试来检测产品中是否存在缺陷，包括根据特定目的而设计测试用例、构造测试。

执行测试和评价测试结果等。

通常的做法是开发者（机构或组织）负责自己代码的单元测试，而系统测试则由一些独立的测试人员或专门的测试机构运行。

⑵测试什么。

测试经验表明，通常表现在程序中的故障，并不一定是由编码所
引起。

他可能是在详细设计阶段、概要设计阶段，甚至是需求分析阶段的问题所至。

即使对原程序进行测试，所发现故障的根源也可能是在开发前期的某个阶段。

要排除故障、修正错误，也必须追溯到前期的工作。

事实上，软件需求分析、设计和实施阶段是软件故障的主要来源。

⑶什么时候进行测试。

测试可以是一个于开发并行的过程，还可以是在开发完成某个阶段任务之后的活动或者是开发结束后的活动，即模块开发结束后可以进行测试，也可以推迟在各模块转陪成为一个完整的程序之后再进行测试。

开发经验证明，随着开发的不断深入，没有进行测试的模块对整个软件的潜在破坏作用更明显。

⑷怎样进行测试。

软件“规范”说明了软件本身应该达到的目标，程序“实现”则是一种对应各种输入如何产生输出结果的算法。

换言之，规范界做了一个软件要做什么，而程序实现则规定了软件应该怎样做。

对软件的测试就是根据软件的功能规范说明和程序实现利用各种测试手法，生成有效的测试用例，对软件进行测试。

要实现软件质量保正，主要有两种途径：首先通过贯穿软件工程各种有效的技术方法和措施使得尽量在软件开发期间减少错误，其次就是通过分析和测试软件来发现和纠正错误，因此，软件测试是软件质量的重要保证。

对一个系统的测试越多，就越能确保她的正确性。

然而，软件测试通常不能保证系统的运行百分之百地正确。

因此，软件测试在确保软件质量方面的主要贡献在于它能发现那些在一开始就应避免的错误。

软件质量保证的使命首先是避免错误。

1.2.2 软件测试的基本理论
1.软件测试的目的
测试的目的是要证明程序中有故障存在，并且是最大地找出最多的错误。

测试力求设计出最能暴露出问题的用例。

测试不是为了显示程序是正确的，而是应从软件包含有缺陷和故障这个假定去进行测试活动，并从中发现尽可能多的问题。

实现这个目的的关键是如何合理地设计测试用例，在设计测试用例进，要着重考虑那些易于发现程序错误的方法策略与具体数据。

测试是以发现故障为为目的并为发现故障而执行程序的过程。

综上所述，软件测试的目的包括以下三点：
（1）测试是程序的执行过程，目的在于发现错误；不能证明程序的正确性，仅限于处理有限种的情况。

（2）检查系统是否满足需求，这也是测试的期望目标。

（3）一个好的测试用例在于发现还未曾发现的错误；成功的测试是发现了错误的测试。

2.软件测试的原因
依据上述软件测试的目的，软件测试的原则是：
（1）尽早地和及地测试应作为软件开发人员的座右铭，测试应当从软件半成品开发初始阶段即开始；
（2）测试用例应当由测试数据和与之对应的预期结果这两部分组成；
（3）在程序提交测试后，应当由专门的测试人员进行测试，避免由程序设计都自行检查程序；
（4）测试用例应包括合理的输入条件和不合理的输入条件；
（5）严格执行测试计划，排除测试的随意性；
（6）充分注意测试当中的群体现象，测试经验表明，约一半（47%）的错误仅与系统中4%的程序模块有关；
（7）应对每一个测试结果做全面的检查；
（8）保存测试计划、测试用例、出错统计和最终分析报告，为维护工作提供充分的资料。

3. 测试的开发各阶段的作用
（1）项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。

（2）需求分析阶段：确定测试需求分析/系统测试计划的制定，评审后成为管理项目。

测试需求分析是对产品生命周期中测试所需求的资源、配置、每阶段评判通过的规约；系统测试计划则是依据软件的需求规格说明书，制定测试计划和设计相应的测试用例。

（3）详细设计和概要设计阶段：确保集成测试计划和单元测试计划完成。

（4）编码阶段：由开发人员进行自己负责部分的测试代码。

在项目较大时，由专人进行编码阶段的测试任务。

（5）测试阶段（单元测试、集成测试、系统测试）：依据测试代码进行测试，并提交相应的测试状态报告和测试结束报告。

软件测试按照不同的划分方法，有不同的几种分类：
●按照软件测试用例的设计方法而论，软件测试可以分为白盒测试法和黑盒
测试法，这是具体的测试方法。

●按照软件测试的策略和过程来分类，软件测试可分为单元测试、集成测试、
系统测试、验证测试和确认测试，这是软件测试的策略和步骤。

按照软件测试的策略和过程来分类，测试是软件质量保证的最重要环节。

4.测试信息流程
测试信息流程如图1.3所示，测试过程中需要三类输入。

（1）软件配置：包括软件需求规格说明、软件设计规格说明、源代码等。

（2）测试配置：包括测试计划、测试用例、测试驱动程序等。

（3）测试工具：为提高测试效率，采用测试工具支持测试工作，包括测试数据自动生成程序、驱动测试的测试数据库等。

图1.3 测试信息流程
5. 软件测试的周期性
软件生命周期是由制定计划、需求分析定义、软件设计、程序编码、软件测试、
软件运行、软件维护、软件停用8个阶段构成。

而软件测试的周期性是“测试——改错——再测试——再改错”这样一个循环过程，如图1.4所示。

功能冻结
图1.4 软件测试的周期性
6.测试停止的依据
因要受到测试成本或其他方面的条件制约，测试最终是要终止的。

通常有5类终止测试的标准或依据。

第一类标准：测试超过了预定时间，则终止测试。

这类标准不能用来衡量软件测试的质量。

第二类标准：执行了所有的测试用例，但并没有发现故障，则终止测试。

这类标准对测试并无好的指导作用，相反却有可能默认测试人员没有编出更好的、能暴露出更多故障的测试用例。

第三类标准：使用特定的测试用例设计方案作为判断测试终止的基础。

这类标准仍然是一个主观的衡量尺度，无法保证测试人员准确、严格地使用某种测试方式。

这类标准只是给出了测试用例设计的方法，并非确定的目标，并且这类标准只对某些测试阶段适用。

第四类标准：正面指出终止测试的具体要求，即终止测试的标准可定义为查出某一预订数目的故障，如规定发现并修改了多少个故障就可停止测试。

对系统测试的标准是，发现并修改若干个故障或至少系统要运行一定时间，如几个月等。

使用第四类标准需要解决两个问题：第一个问题是如何知道将要查处的故障数目。

另一个问题是可能会过高地估计了故障的总数目。

解决问题的途径是根据过去的经验和软件开发业界常用的一些平均值方法做出决断（关于这方面的详细论述请查阅有关资料）。

第五类标准：根据单位时间内查出故障的数量决定是否终止测试。

这个标准看似容易，但实际操作中要用到较多直觉和判断。

通常使用图表表示某个测试阶段中单位时间检查出的故障数量，通过分析图，确定应继续测试还是终止测试。

1.2.3 软件测试和缺陷修复的代价
软件通常需要靠有计划、有条理的开发过程来建立。

从需求、设计、编码测试一直到交付用户公开使用后的整个过程中，都有可能产生和发现缺陷。

随着整
个开发过程的时间推移，在需求阶段没有被修正的错误总是或缺陷有可能不断扩。