计算机软件测试论文.docx
《计算机软件测试论文.docx》由会员分享，可在线阅读，更多相关《计算机软件测试论文.docx（10页珍藏版）》请在冰豆网上搜索。
计算机软件测试论文
计算机软件可靠性测试概述
-----计算机软件测试论文
昆明理工大学信息院
计算机应用技术
时间：
2010-12-18
软件测试的定义是在1983年由IEEE在软件工程标准术语中给出的：
使用人工或自动手段来运行或评价某个系统或系统部件的过程，其目的在于检验它是否满足规定的需求；或是弄清预期结果和实际结果之间的差别。
该定义非常明确地指出了软件测试是以检验是否满足需求为目标。
软件测试是为了找出错误和缺陷而进行的，而不是为了证明软件的正确性。
保证软件产品的质量，需要从软件开发过程、开发技术水平、软件测试等多方面进行保障。
而软件测试又是保障软件质量的最重要的手段之一。
软件可靠性测试是软件开发过程中的一个环节，软件可靠性测试的目的是对软件的可靠性进行验证。
是软件生命周期的一个重要阶段和关键步骤。
通过排除软件测试中发现的错误和缺陷，可以有效实现软件可靠性的增长。
随着软件规模的不断扩大，软件功能的不断增加，软件测试的难度进一步提高，软件产品的可靠性也更加难以度量。
由于目前在软件可靠性方面还没有建立起权威性的管理体系和规范，建立的许多软件可靠性模型在一定程度上描述了软件可靠性，但均存在局限性，至今尚无哪一个模型能够适合广泛的应用。
因此从事软件可靠性测试与评估研究是一个具有理论价值和实际意义的工作。
一.软件测试
软件测试指为了发现错误而执行程序的过程。
它是根据软件开发各阶段的规格说明和程序的内部结构精心设计一批测试用例，用这些测试用例去执行程序，以发现程序错误的过程。
软件测试追求的是通过系统的测试方法，发现软件中的错误。
软件测试是软件开发过程中一个非常重要的阶段。
其目标是在精心控制的环境下执行程序，以发现程序中的错误，给出程序可靠性的鉴定。
1.1静态分析
静态分析的基本特征是在对软件进行分析、审查和测试时不实际运行被测程序。
而是采用其它手段达到检测的目的。
由专用的软件测试工具评审软件文档或程序，度量程序静态复杂度，检查软件是否符合编程标准，借以发现编写的程序的不足之处，减少错误出现的概率。
静态分析是对被测程序进行特性分析的一些方法的总称。
这些方法本身各有自己的目标和步骤。
比如，有的是要收集一些程序信息，以利于查找程序中的各种欠缺和可疑的程序构造：
有的只是从程序中提出语义的或结构要点，供进一步分析。
静态分析只是对代码进行扫描分析，检测它的语法规则等是否规范，以发现程序的不足之处。
它主要是为软件的质量保证提供依据，以提高软件的可靠性和易维护性。
静态分析包含对软件开发过程中的软件需求、设计和编码所生成的文档的检验。
（1）需求分析阶段
检验需求分析文档与用户要求是否一致：
检验所有参加项目人员对需求分析文档和用户要求的理解是否正确。
（2）设计阶段
检验设计（概要设计和详细设计）是否与需求分析文档一致；设计的结构化程序及每个模块是否合理；检验每个模块是否符合系统规范要求；检验模块与系统间的组合，特别重要的输入及边界条件下的组合。
（3）编码阶段
逐行地阅读、校验书面程序是否正确，以便发现代码中的错误，及对计算机环境规范方面的差错。
1.2动态测试
“动态测试”也就是要经过程序运行测试用例而进行的测试，所以动态测试常称“程序测试”。
程序测试通常有“黑盒测试”和“白盒测试”之分。
如果软件产品具备的功能已经知道，测试软件产品的每一个功能是否达到了预期的要求，这种测试称为黑盒测试；如果知道软件程序的内部活动方式，测试程序内部活动是否符合设计要求，这种测试称为“白盒测试”。
黑盒测试（Black-BoxTesting）又称功能测试，数据驱动测试（DataDrivingTesting）或基于规格说明的测试。
在进行黑盒测试时，仅把软件当作一个黑盒，只需知道程序输出和输入之间的关系或者程序的功能。
因此，黑盒测试是从用户的观点出发的测试。
它是从软件需求出发，根据软件需求规格说明设计测试用例，并根据测试用例的要求运行被测程序的测试方法。
它较少关心程序内部的实现过程，侧重于程序的执行结果，将被测程序看成是不可见的黑盒子，因此被称为黑盒测试。
黑盒测试着重于验证软件功能和性能的正确性，其典型测试项目包括功能测试、性能测试、边界测试、强度测试等。
白盒测试（White—BoxTesting）又称结构测试，逻辑驱动测试或基于程序的测试。
采用这一测试方法，测试者必须看到被测的源程序，分析程序的内部结构，并根据其内部构造设计测试用例。
白盒测试是一种按照程序内部的逻辑结构和编码结构设计并执行测试用例的测试方法。
采用这种测试方法，测试者需要掌握被测程序的内部结构。
白盒测试通常根据覆盖准则设计测试用例，使程序中的每个语句、每个条件分支、每个控制路径都在程序测试中受到检验。
白盒测试需要运行程序，并能在运行过程中跟踪程序的执行路径。
黑盒测试是以用户的角度来看待软件的质量，从输入数据与输出数据的对应关系，也就是根据程序外部表现特性进行的测试，而不考虑程序内部的逻辑结构和工作状况。
黑盒测试技术依赖软件的规格说明书，假设软件的规格说明书是正确的，通过划分程序的输入和输出域来确定测试用例。
如果软件规格说明的规定有误，用黑盒测试方法是发现不了的。
反之，白盒测试只根据程序的内部结构进行测试，测试用例的设计要保证测试时程序的所有语句至少执行一次，而且要检查所有的逻辑条件。
如果程序结构本身有问题，比如说程序逻辑有错误，或是有遗漏，那就无法发现。
黑盒测试和白盒测试各自有各自得优缺点，相互之间构成互补关系，在规划测试时需要把黑盒测试与白盒测试结合起来。
1.3软件测试过程
软件测试过程，可分为五个步骤：
单元测试、子系统测试、系统测试、验收测试和平行运行。
单元测试:
在设计好的软件系统中，每个模块完成一个清晰定义的子功能，而且每个模块又是相对独立的。
因此，每个模块可以作为一个单独的测试单元，而且也比较容易设计测试用例。
单元测试的目的，是保证每个模块作为一个单元能正确运行。
在这个测试中所发现的错误，往往是编码和详细设计的错误。
集成测试:
把软件单元逐步组装成一个计算机软件配置项的过程叫“软件集成"。
把软件逐步组装，同时一并进行测试，直到整个系统成为一体的有序进行的测试叫“集成测试”，也叫“计算机软件部件测试”、“组装测试”或“综合测试”。
确认测试:
集成测试完成后，软件接口缺陷已经发现并纠正，这时可以对软件进行确认测试。
确认测试是通过黑盒测试来验证软件功能及性能与要求规范是否一致。
当发现与需求规范有差别，要列出一个缺陷表。
系统测试:
将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。
系统测试的目的在于通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约所指定的要求。
系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来进行。
二.软件可靠性
2.1软件可靠性定义
软件可靠性是软件质量因素中最基本、最重要的因素。
1983年，IEEE计算机学会对“软件可靠性”这一术语作了专门的定义：
在规定的条件下，在规定的时间内，软件不引起系统失效的概率，该概率是系统输入和输出的函数，也是软件中存在的缺陷的函数；系统输入将确定是否会遇到已存在的错误（如果错误存在的话）：
在规定的时间周期内，在规定的条件下程序执行所要求的功能的能力。
根据定义，软件可靠性包含了以下3个要素：
规定的时间、规定的条件、所要求的功能。
规定的时间：
软件可靠性只是体现在其运行阶段，所以将“运行时间”作为“规定时间"的度量。
“运行时间”包括软件系统运行后工作与挂起（开启但空闲）的累计时间。
由于软件运行的环境与程序路径选取的随机性，软件的失效为随机事件，所以运行时间属于随机变量。
规定的条件：
条件指软件的运行环境。
它涉及软件系统运行时所需的各种支持要素，如支持硬件、操作系统、其他支持软件、输入数据格式和范围以及操作规程等。
不同的环境条件下软件的可靠性是不同的。
具体地说，规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求，并假定其他一切因素都是理想的。
有了明确规定的环境条件，还可以有效判断软件失效的责任在用户方还是研制方。
所要求的功能：
软件可靠性还与规定的任务和功能有关。
由于要完成的任务不同，软件的运行剖面会有所区别，则调用的子模块就不同（即程序路径选择不同），其可靠性也就可能不同。
所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。
2.2软件可靠性度量
软件可靠性度量是指对软件产品具有可靠性程度的定量评价。
软件可靠性度量参数是描述软件可靠性的依据，确定其指标要求是评估软件可靠性的必要步骤，一般的软件可靠性参数有：
可靠度:
是指软件在规定的条件下、规定的时间段内完成预定的功能的概率。
或者说是软件在规定时间内无失效发生的概率。
该参数是关于软件失效行为的概率描述，是软件可靠性的基本定义。
失效概率:
失效概率是失效时间少于或等于t的概率。
失效强度：
失效强度是失效概率的密度函数。
失效率:
失效率是指在t时刻尚未发生失效的条件下，在t时刻后单位时间内发生失效的概率。
失效率是失效概率F（t）的条件概率密度，又称条件失效强度。
平均失效时间:
平均失效时间次失效时间的均值。
平均失效间隔时间：
平均失效间隔时间是指2次相邻失效时间间隔的均值。
三.软件可靠性测试
3.1软件可靠性测试定义
软件可靠性测试是指在预期的使用环境中，为检出软件缺陷，验证和评估是否达到用户对软件可靠性需求而组织实施的一种软件测试。
软件可靠性测试是面向故障的测试，每一次测试均代表用户将要完成的一组操作，使得测试成为最终软件产品运行的预演。
软件可靠性测试包括可靠性增长测试和可靠性验证测试。
可靠性增长测试和可靠性验证测试从不同的角度理解、分析和处理故障数据。
在可靠性增长测试中，测试以迭代方式进行，根据测试过程中所检出和跟踪到的故障，使用基于软件可靠性增长模型和统计推理的可靠性评估方法进行故障强度估计和测试进展跟踪。
可靠性验证测试是软件产品发放前进行的最后测试，它是最终检验而不是调试。
可靠性验证测试的目标是确定一个软件产品在风险限度之内的可接收程度。
软件可靠性测试是在预期的使用环境中或仿真环境下，按照运行剖面组织实施的测试。
在使用中发生概率高的缺陷通常最先得以暴露，而实际高发生概率的缺陷即是影响软件可靠性的主要缺陷，排除这些缺陷可以有效地实现可靠性增长，提高软件可靠性。
软件可靠性测试过程中，可以根据用户给定的可靠性要求确定测试方案，生成测试用例，进行可靠性验证测试。
软件可靠性测试及其失效数据分析，不仅可以验证软件可靠性是否满足给定需求，跟踪软件可靠性的增长情况，指导软件测试和交付，而且可以预测未来可能达到的可靠性水平，从而为软件开发及其管理提供决策依据。
软件可靠性测试是指为了保证和验证软件的可靠性要求而对软件进行的测试。
其采用的是按照软件运行剖面（对软件实际使用情况的统计规律的描述）对软件进行随机测试的测试方法。
通过软件可靠性测试可以达到以下目的：
（1）有效地发现程序中影响软件可靠性的缺陷，从而实现可靠性增长：
软件可靠性是指“在规定的时间内，规定的条件下，软件不引起系统失效的能力，其概率度量称为软件可靠度。
软件的“规定的条件”主要包括相对不变的条件和相对变化的条件，相对不变的条件如计算机及其操作系统：
相对变化的条件是指输入的分布，用软件的运行剖面来描述。
按照软件的运行剖面对软件进行测试一般先暴露在使用中发生概率高的缺陷，然后是发生概率低的缺陷。
而高发生概率的缺陷是影响产品可靠性的主要缺陷，通过排除这些缺陷可以有效地实现软件可靠性的增长。
（2）验证软件可靠性满足一定的要求：
通过对软件可靠性测试中观测到的失效情况进行分析，可以验证软件可靠性的定量要求是否得到满足。
（3）估计、预计软件可靠性水平：
通过对软件可靠性测试中观测到的失效数据进行分析，可以评估当前软件可靠性的水平，预测未来可能达到的水平，从而为开发管理提供决策依据。
软件可靠性测试中暴露的缺陷既可以是影响功能需求的缺陷也可以是影响性能需求的缺陷。
软件可靠性测试方法从概念上讲是一种黑盒测试方法，因为它是面向需求、面向使用的测试，它不需要了解程序的结构以及如何实现等问题。
3.2软件可靠性测过程
软件可靠性测试活动包括：
测试数据、测试环境的准备、测试运行、可靠性数据收集、可靠性数据分析和失效纠正。
（1）构造运行剖面：
软件的运行剖面“是指对系统使用条件的定义。
即系统的输入值用其按时间的分布或按它们在可能输入范围内的出现概率的分布来定义”。
粗略地说，运行剖面是用来描述软件的实际使用情况的。
运行剖面是否能代表、刻画软件的实际使用取决于可靠性工程人员对软件的系统模式、功能、任务需求及相应的输入激励的分析，取决于他们对用户使用这些系统模式、功能、任务的概率的了解。
运行剖面构造的质量将对测试、分析的结果是否可信产生最直接的影响。
（2）选取测试用例：
软件可靠性测试采用的是按照运行剖面对软件进行可靠性测试的方法。
因此，可靠性测试所用的测试用例是根据运行剖面随机选取得到的。
（3）测试环境的准备：
为了得到尽可能真实的可靠性测试结果，可靠性测试应尽量在真实的环境下进行，但是在许多情况下，在真实的环境下进行软件的可靠性测试很不实际，因此需要开发软件可靠性仿真测试环境。
比如，对于多数嵌入式软件，由于与之交联的环境的开发常常与软件的开发是同步甚至是滞后的，因此无法及时进行软件可靠性测试：
有些系统中，由于交联的环境非常昂贵而无法用于需要进行大量运行的可靠性测试。
（4）可靠性测试运行：
即在真实的测试环境中或可靠性仿真测试环境中，用按照运行剖面生成的测试用例对软件进行测试。
（5）数据收集：
收集的数据包括软件的输入数据、输出结果，以便进行失效分析和进行回归测试：
软件运行时间数据，可以是CPU执行时间、日历时间、时钟时间等：
可靠性失效数据包括每次失效发生的时间或一段时间内发生的失效数，失效数据可以实时分析得到，也可以事后分析得到。
数据收集的质量对于最终的可靠性分析结果有着很大的影响，应尽可能采用自动化手段进行数据的收集，以提高效率、准确性和完整性。
（6）数据分析：
主要包括失效分析和可靠性分析。
失效分析是根据运行结果判断软件是否失效，以及失效的后果、原因等：
而可靠性分析主要是指根据失效数据，估计软件的可靠性水平，预计可能达到的水平，评价产品是否已经达到要求的可靠性水平。
为管理决策提供依据。
（7）失效纠正：
如果软件的运行结果与需求不一致，则称软件发生失效。
通过失效分析，找到并纠正引起失效的程序中的缺陷，从而实现软件可靠性的增长。
软件可靠性增长测试是为了满足用户对软件的可靠性要求、提高软件可靠性水平而对软件进行的测试。
是为了满足软件的可靠性指标要求，对软件进行测试一可靠性分析一修改一再测试—再分析一再修改的循环过程。
3.3软件可靠性评估
离开了准确的评价方法，可靠性保证措施的有效性难以判断。
目前在软件可靠性评价技术中，受到关注的主要有两种评价方法：
（1）基于软件可靠性测试的评估方法
软件可靠性验证方法是为了验证在给定的统计置信度下，软件当前的可靠性水平是否满足用户的要求而进行的测试，即用户在接收软件时，确定它是否满足软件规格说明书中规定的可靠性指标。
该种方法一般是在软件验收阶段进行的，在软件需求方参与的情况下实施。
其主要过程是根据现场测试（注意测试中不再进行故障剔除）的故障情况，利用某种或某些软件供需双方都认可的可靠性验收模型（比如Nelson模型㈨）进行可靠性的定量评价，以判断该软件是否达到了其需求说明书中约定的可靠度。
图3-1介绍了基于软件可靠性测试的评估方法的步骤。
图3-1软件可靠性测试的评估方法
（2）基于软件可靠性建模的评估方法
传统的软件可靠性估计方法一般是用可靠性增长模型（RGM）对软件可靠性进行评估和预测，因此可靠性建模是传统的软件可靠性估计过程的基础。
它确定产品是否达到了可靠性指标。
它要求根据系统测试中收集的失效数据．（如失效报告和测试时间），运用可靠性模型估计作为测试时间函数的各种产品可靠性参量。
图3-2显示了基于软件可靠性建模的可靠性评价的主要步骤。
图3-2基于可靠性建模的软件可靠性评估
3.4软件可靠性模型的局限性
如果将七十年代初出现的第一个有影响的软件可靠性模型作为开端，对软件可靠性模型进行系统化研究，所建立的软件可靠性模型已不下百余种。
然而，由于软件可靠性模型本身存在很多不足，使得模型的应用受到限制。
下面本文将给出软件可靠性模型存在的两个主要问题。
（1）没有通用的软件可靠性模型:
造成软件可靠性模型评价精度不高的原因之一是在没有通用模型的情况下，使用者选择模型时存在相当的困难。
他们常常凭经验做取舍，从而不可避免地导致有些模型的应用环境与建模者的建模假设相去甚远，因而客观上影响了模型的评价精度。
（2）软件可靠性模型的不足使软件可靠性模型并不能完全描述软件的故障行为
主要是因为：
（1）软件可靠性模型的假设本身就存在一定的失实情况
由于人们对软件失效的内在机理的认识还不完全，在建模时难免会做出大量不切实际的假设。
以随机过程软件可靠性模型为例，这类模型建模所涉及的主要假设有：
a）故障间隔时间具有独立性；
b）软件失效相互独立；
c）软件所有缺陷暴露率相同；
d）一旦发现软件缺陷就立即被清除掉，而且清除过程中不会引起新的软件缺陷：
e）测试用例的选取是随机的。
显然这些假设与现实相悖。
（2）软、硬件故障的差别
尽管软件、硬件故障的发生都具有随机性的特点，但它们的产生机理是不一样的。
软件的故障常常是由软件的缺陷或错误引起的，具有离散性，与硬件相比，它更适合用集合、格、群等数学工具而不是某种分布来表达；硬件故障却是由硬件部件的物理或化学变化造成的，即所谓的“行动损耗"，有一定的连续性和规律性，其行为常常可用偏微分方程描述，用分布曲线来表达。
所以从硬件技术借鉴而来的软件可靠性模型与软件的故障之间是有缝接口。
（3）测试的随机性
就软件而言，不可忽视测试的随机性。
软件故障具有离散性，因此样本空间中，某输入数据的输出很难用以代表相邻输入数据的输出。
而硬件则不同，它的故障行为有一定的连续性，可以用样本点的值来代表相邻点的值。
因此与硬件相比，软件的测试结果常常会随样本空间选择的不同而发生较大的变化。
影响样本空间选择的随机因素诸如测试工具、测试人员的素质、计算机环境、故障收集的时间标准等通过样本空间间接影响软件的测试结果。
这些测试结果直接决定了软件可靠性模型参数，然而软件的可靠性模型却没有考虑这些随机性。
四.结论
从软件测试和软件可靠性理论入手，对现有的软件可靠性技术进行了系统的研究。
总结出现有可靠性模型的特点并分析出现有可靠性模型所存在的局限性与不足。
在对已有的软件可靠性模型分析中，发现当前的可靠性评估技术，更多地关注于系统整体，都没有考虑子系统对整个系统的影响。
结合系统运行特点，将模型考虑到系统实际运行时，各子系统实际运行特点，以子系统为基本的评估单位，将各子系统的运行时间比例、重要度等因素综合计算每个子系统的可靠性，进而得到系统的可靠性。
这种基于模块任务的思想，建立起更符合系统在实际运行时的情形。
从而得到更加精确的可靠性数据。
结合实际情况实现新的计算机软件可靠性测试模型需要综合多方面因素，并且也是一个逐步完善与改进的过程。
升级会员 