CN105159827B - 一种面向gui软件的可靠性加速测试方法 - Google Patents

Abstract

本发明公开了一种面向GUI软件的可靠性加速测试方法，步骤如下：1、提取标识词与特征，形成标识词链和特征集合；2、进行等价类划分；3、将每一步输入内容归到相应等价类下；4、将基础测试用例集合划分为各类结构信息与内容信息均相同的测试用例集合；5、根据映射关系，将测试用例的每一步输入内容转化为失效信息或者正常信息，并进行标识；6、按序执行测试，筛选各类测试用例执行效果为失效和第一个执行效果为正常的测试用例；7、累加相邻失效间隔之间用例的执行时间作为失效数据进行软件可靠性评估。优点：基于运行分类的思想，减少测试用例数量和测试时间提高GUI软件可靠性测试效率，保证失效数据可进行定量的软件可靠性评估。

Description

一种面向GUI软件的可靠性加速测试方法

技术领域

本发明属于软件可靠性测试技术领域，涉及软件可靠性测试中的加速测试方法，具体涉及一种面向GUI软件的可靠性加速测试方法。

背景技术

随着计算机技术的迅猛发展，计算机软件已经渗透到越来越多的领域，特别是航空航天、金融和医疗等关系国计民生的关键领域。在这些领域中，软件系统规模庞大、逻辑复杂，对可靠性的要求往往非常高。因此，软件可靠性工程越来越受到人们的重视。

软件可靠性测试是提高软件质量与可靠性的重要措施之一，逐渐成为国内外软件可靠性工程的主要研究方向；软件可靠性测试的主要特征是按照用户实际使用软件的方式来测试软件，它可以满足用户对软件的可靠性要求、评价软件可靠性水平及验证软件产品是否达到可靠性要求。

软件可靠性测试通常根据软件可靠性测试剖面生成测试用例，软件可靠性测试剖面是指软件各种使用行为及其概率分布的一种模型，在软件可靠性测试剖面的基础上应用数理统计相关知识进行大量随机抽样获得测试用例。当测试用例集合足够大时，能够保证对软件使用情况的有效覆盖。

但是，伴随着测试用例集的扩充，执行软件可靠性测试的代价会越来越高，当被测软件系统规模庞大、逻辑过于复杂时，付出的代价甚至无法承受。所以，软件可靠性测试在实际工程中的应用就会受到极大限制；因此，软件的可靠性加速测试就显得尤为必要。

软件可靠性加速测试的目的在于减少软件可靠性测试的成本，并且给出具有一定置信度的可靠性评估。自上个世纪八十年代末九十年代初以来，软件可靠性测试在将近二十年的发展中已经取得了一定的成果，但是对软件可靠性加速测试却没有形成统一的明确的认识。

现有技术中，硬件可靠性试验的加速强度测试，通过施加强度激励发现产品缺陷以保证系统拥有高可靠性和健壮性，软件可靠性工程借用硬件可靠性工程的基本概念，将硬件可靠性加速试验的相关概念和方法应用到软件可靠性加速测试的研究。

比如，Chan给出了软件的加速强度测试的定义和对相关概念的理解，将软件加速强度测试视为通过施加加速应力、进行失效分析和采取纠正措施发现软件产品缺陷，以获取系统可靠性和健壮性，它结合硬件说明了软件加速强度测试中的基本可靠性规律。但是目前对于软件可靠性加速测试通常以强度测试为手段提高测试效率，发现更多的缺陷作为测试的目标。

软件可靠性加速测试包括以下几点：

(1)、对于测试的输入(激励)，测试输入能够合理准确地生成，同时考虑整合与转换带来的测试效率的提高；

(2)、对测试过程而言，可靠性测试效率应得到提高，即在相同测试量内，软件可靠性增长的速度要提高；相同测试量如测试时间相同或测试用例数目相同等；或达到相同的可靠性要求所需要的测试量要小，测试量比如时间短，测试用例数目少。

(3)、对于测试结果的定量分析，给出合理的评估，软件可靠性评估结果的可信程度达到一定的水平；

(4)、对软件质量而言，应强调测试本身的查错能力，尽可能地多发现软件缺陷，特别是重要的软件缺陷。

无论是测试输入的生成和整合转换，还是合理有效地加快测试过程，或是某种条件下能够给出具有一定可信度的可靠性评估结果，都认为是对可靠性测试的一种加速，纳入到软件可靠性测试加速的概念中来。

图形用户界面(Graphical User Interface，简称GUI，又称图形用户接口)指采用图形方式显示的计算机操作用户界面，是用户与计算机交流的主要方式，对GUI软件测试方法的研究也越来越受到学术界和工业界的重视。进行GUI软件测试时主要面临以下几个方面的困难：

(1)、GUI软件输入组合空间存在爆炸问题，而且每个输入序列都会导致GUI软件出现不同的状态。

(2)、测试数据对软件使用情况的覆盖情况会影响对GUI软件测试结果的评价。

(3)、在GUI软件测试过程中，测试用例必须逐步执行并对软件当前状态进行验证，当发现软件错误后需要立即停止测试。

(4)、GUI软件需要进行回归测试，随着软件版本的更新，会影响软件输入与输出之间的映射关系。

现有的软件可靠性加速测试方法有：提高严酷度的软件可靠性加速测试方法、基于加速因子的软件可靠性加速测试方法、基于灰盒分析的软件可靠性加速测试方法、基于重要度抽样的软件可靠性加速测试方法、基于过程的软件可靠性加速测试方法等。

但是考虑到GUI软件测试中的难点，以上的软件可靠性加速测试方法并不完全适用：提高环境严酷度的软件可靠性加速测试方法，其难点在于如何将在恶劣环境下得到的测试结果转化到标准使用环境下得到可靠性评估结果，目前还没有很好的解决方法；基于加速因子的软件可靠性加速测试方法，对加速因子没有约定俗成的定义，其计算更多来自于经验；基于灰盒测试的软件可靠性加速测试方法，虽然可以解决通过总体分布类型的假设检验保证测试数据满足运行剖面的统计特征，但是仍然无法保证利用覆盖信息辅助得到的测试数据能够从整体上满足用例生成的随机性，存在“使实际使用中后发生的输入提前发生的可能性大大提高”的问题，此顺序问题会造成“可靠性估计值与实际值的偏差可否忽略”成为一个不确定的问题；基于重要度抽样的软件可靠性加速测试方法，利用重要度抽样技术，提高某些关键度高的操作的发生概率，这种方法更加适用于安全关键类型软件上面；基于过程的软件可靠性加速测试方法，利用人工智能领域的一些聚类方法，实现对测试用例集合的分类，由于GUI软件的测试输入复杂多样，范围波动大，外加这些聚类方法不仅实现起来难度大，并不利于在工程上应用和推广，其效果也未必理想。

由于软件可靠性测试不考虑被测软件的结构特征以及其他测试信息，完全按照“构造剖面—抽样生成测试用例—执行测试—收集结果—进行评估”的过程，所以测试用例集在常见功能点上过于重复，导致测试用例之间具有“局部相同，整体相似”的特点，可以考虑分类以减少测试用例数目，减少测试时间提高测试效率。

Musa曾经指出：对运行进行有效的分类通过一定的策略在运行类中对运行进行选择，就可以在理论上改进软件可靠性测试的效率。如果运行类中的一个运行成功执行，则非常有可能这个运行类的所有运行都能够成功执行。类似地，如果运行类中的一个运行出现失效，则非常有可能这个运行类的所有运行都会出现同样的失效。这意味着运行类中的每个运行都可以近似看作是该运行类中的所有运行的代表。通过运行各运行类中的小部分运行，在理论上可以达到提高可靠性测试效率的目的。

软件测试理论中的等价类划分，通过对相似输入进行整合，减少测试用例的数目，从而提高测试效率。那么在软件可靠性测试中是否也存在某种等价类，通过运行“等价类”中的某个个体就可以测试整个“等价类”，软件可靠性测试仍可利用这种思路来提高测试的效率。

软件可靠性测试用例直接或间接的反映了软件的实际使用方式，构建测试剖面时，对于发生概率较高的操作或行为，通常会设置较高的发生概率或转移概率，因此随机生成足够多测试用例以满足软件使用模型，被赋予较高概率的操作往往会出现在大量测试用例中，而且许多测试用例往往是相似甚至相同的。

在实际中，GUI软件功能的针对性较强，完成某一功能的执行路径是基本确定的。在采用操作剖面的形式对软件的使用情况进行建模之后，可以直接获取每个功能模块所包含的使用情况。

进行GUI软件可靠性测试时，每一步输入所需的测试数据分为以下几种：正常输入，异常输入或者边界输入。结合等价类划分规则以及输入数据类型，将每一步输入情况的等价类情况进行更加细致的划分。

以上的这种基于操作剖面的聚类方法，虽然考虑了测试用例执行的数据信息，但是难以直观的观察测试用例执行效果之间的关系。通过执行测试用例，仅能判定该结果与预期输出是否一致，从而判定出有无缺陷。根据软件发生失效的机理：程序的输入使软件的缺陷得到了执行，被执行的缺陷使该程序缺陷所在位置之后的数据状态发生变化，错误的程序数据状态被传播到程序输出并使输出结果错误。所以，软件发生失效的过程大致如下：“输入数据----缺陷被执行----产生错误输出----发生失效”。若能将软件输入、软件缺陷及其发生的失效之间建立一种映射关系，就能根据软件发生失效的情况找出缺陷所在位置并且修改软件缺陷，也可以根据软件输入对软件是否会发生失效进行判断。

发明内容

本发明的目的是针对GUI软件，考虑GUI软件的测试难点，基于运行分类的思想提出了一种面向GUI软件的可靠性加速测试方法，提高GUI软件的可靠性测试效率，利用GUI软件可靠性测试获得的测试数据进行软件可靠性评估。

一种面向GUI软件的可靠性加速测试方法，步骤如下：

步骤一：针对GUI软件可靠性测试所生成的基础测试用例集合中的每个测试用例，提取测试用例的标识词与特征，分别形成该测试用例的标识词链和特征集合。

标识词为测试用例所包含的一个操作步骤，用w_j表示；

特征代表测试用例的一个操作步骤所对应的输入内容，用c_j表示；

每个测试用例由多个不同的标识词和特征组成；

将每个测试用例的标识词与特征进行组合，形成测试用例的表达式为：

T_i＝{(w₁,c₁),(w₂,c₂),...,(w_j,c_j),...}；

T_i为一个测试用例；(w_j,c_j)为测试用例T_i的标识词与特征组合；i＝1,2,...,n，n为整数；

提取测试用例T_i所包含的标识词w_j，形成标识词链W＝{w₁,w₂,...,...w_j,...,w_n}；

提取测试用例T_i所包含的特征c_j，形成特征集合C＝{c₁,c₂,...,...c_j,...,c_n}；

j＝1,2,...,n，n为整数。

测试用例的标识词链体现了测试用例的结构信息，特征集合体现了测试用例的内容信息。

步骤二、对测试用例中每个特征对应的输入内容进行等价类划分，得到每个特征的等价类划分结果；

针对每个特征c_j所对应的输入内容，将具有相同输出结果的输入内容合为一类，作为一个等价类，依次对特征c_j中所有输入内容进行分类，得到属于特征c_j的所有等价类结果。

步骤三、将每个测试用例的每一步的输入内容，根据对应特征的等价类划分结果，归到相应的等价类下。

每个特征均包括多个等价类，对每个等价类命名为：特征+序号；序号按整数由小到大排列，最后的序号代表了特征划分后所形成的等价类数目。

步骤四：根据测试用例的结构信息与内容信息，对基础测试用例集合进行划分，得到结构信息与内容信息均相同的各类测试用例集合。

基于结构信息的测试用例划分方法如下：

步骤401、将基础测试用例集合中第一个测试用例放入用例库中作为一类；

步骤402、依次按顺序对基础测试用例集合中的测试用例标识词链进行匹配分类；

依次从基础测试用例集合中按顺序选取测试用例作为待对比用例，与用例库中各类测试用例的标识词链逐类匹配；

步骤403、判断待对比用例的标识词链是否与用例库中某类用例的标识词链完全相同；

如果待对比用例的标识词链与用例库中某类用例的标识词链完全相同，则将待对比用例放在该类别下，否则，在用例库中增加一个类别，并将待对比用例放入新增加的类别下；

步骤404、判断当前的待对比测试用例T_i是否为基础测试用例集合中的最后一个用例，如果是，转到步骤405；如果不是，转到步骤402；

步骤405、经过分类后的测试用例形成包含不同类别的用例库，每类测试用例的标识词链和对应位置的特征均相同，同类中的测试用例包含相同的结构信息。

基于内容信息的测试用例划分方法，如下：

步骤1、对每一类结构信息相同的测试用例集合，依次将每个测试用例的每步输入内容，根据输入内容所属的等价类，用等价类的命名进行替换。

步骤2、选取每类测试用例中的第一个测试用例作为一个子类；

步骤3、依次选取该类测试用例集合中的测试用例作为待对比用例，与该类测试用例中的子类进行等价类命名的匹配；

步骤4、判断待对比用例的特征等价类的命名与子类对应位置的特征等价类的命名是否相同，如果依次对应位置的等价类的命名均相同，则将待对比用例放在对应的子类下；否则，将待对比用例作为一个新的子类并增加到用例库中；

步骤5、判断当前的待对比用例是否为该类中的最后一个测试用例；如果“是”，进入步骤6；否则，进入步骤3；

步骤6、判断是否对所有结构信息相同的测试用例集合都进行了子类划分，如果“是”，进入步骤7；否则，进入步骤2；

步骤7、经过分类后的基础测试用例集合形成包含不同类别测试用例集合的用例库，各类测试用例在结构信息和内容信息上均是相同的。

步骤五：对结构信息和内容信息均相同的各类测试用例，根据软件输入与软件失效之间的映射关系，将每个测试用例中的每一步输入内容转化为失效信息或者正常信息，并在测试用例中的输入内容所在位置进行标识。

步骤六：对经过步骤五标识后的测试用例按序执行测试，筛选各类测试用例执行效果为“失效”且各类测试用例中第一个执行效果为“正常”的测试用例。

步骤601、在对每个测试用例的每一步输入内容完成失效信息或正常信息的标识后，按照基础测试用例集合中的编号顺序开始执行第一条测试用例，进行软件可靠性测试；

步骤602、在测试用例执行过程中，对测试用例的每一步输入内容，参考软件输入与软件失效之间的映射关系，判断软件当前输入能否引起GUI软件失效，并且对测试用例中所标识的失效信息与正常信息进行处理；

在测试人员对当前的软件状态进行验证后，如果测试用例的当前输入内容不能引起GUI软件失效，则在基础测试用例集合中，同等价类输入内容所对应的失效信息便不存在；

如果测试用例当前的输入内容引起软件失效，则在当前的测试用例输入内容所在的位置保留标识的失效信息，同时对该测试用例不再继续执行可靠性测试；在基础测试用例集合的后续测试用例中，将属于同等价类的测试用例输入内容所对应的位置标识的失效信息全部删除；

测试人员对软件状态的验证过程，也保证了软件输入与软件失效之间映射关系的正确性。

步骤603、判断当前测试用例中是否含有失效信息；如果“是”，则将其执行效果标识为“失效”，进入步骤605；否则，将其执行效果标识为“正常”，进入步骤604；

测试用例的筛选与执行过程是同时进行的，所要筛选并执行的测试用例就是每一类用例集合中执行效果标识为“失效”与第一个执行效果标识为“正常”的测试用例，并且记录所筛选用例的执行时间。

步骤604、判断当前的测试用例是否为某类测试用例集合中第一个执行效果标识为“正常”的测试用例。如果“是”，该类测试用例中的后续用例不执行测试，将后续测试用例的执行效果都标识为“正常”。否则，进入步骤605；

步骤605、判断当前所执行的用例是否为基础测试用例集合中的最后一个测试用例。

如果“是”，则完成对基础测试用例集合的用例执行效果标识；否则，返回步骤602按序执行基础测试用例集合中的下一个测试用例。

步骤七：对执行效果为“失效”的测试用例，累加相邻失效间隔之间测试用例的执行时间作为失效数据进行软件可靠性评估。

本发明的优点在于：

(1)一种面向GUI软件的可靠性加速测试方法，通过对软件输入域进行等价类划分，有效的缓解了软件输入组合空间爆炸问题；

(2)一种面向GUI软件的可靠性加速测试方法，能够保证测试用例集合中的软件执行路径能够对被测软件的使用方式进行有效覆盖；

(3)一种面向GUI软件的可靠性加速测试方法，不存在因测试数据的随机性而导致的可靠性估计值与实际值的偏差问题；

(4)一种面向GUI软件的可靠性加速测试方法，可以充分利用到在软件前期的开发和测试过程中总结的软件缺陷信息与软件失效信息；

(5)一种面向GUI软件的可靠性加速测试方法，可以在可靠性加速测试过程中有效地指导测试用例执行；

(6)一种面向GUI软件的可靠性加速测试方法，能够产生可用于软件可靠性评估的失效数据；

(7)一种面向GUI软件的可靠性加速测试方法，与常规的软件可靠性测试方法相比，提高了可靠性测试效率并且能够提供具有一定置信度的可靠性评估结果。

附图说明

图1为本发明一种面向GUI软件的可靠性加速测试方法的流程图；

图2为基于结构信息的测试用例划分方法流程图；

图3为基于内容信息的测试用例划分方法流程图；

图4为软件输入、软件缺陷、软件失效之间的网络映射关系示意图；

图5为测试用例由输入信息转化为失效信息的示意图；

图6为被测软件的顶层使用剖面；

图7为常规的软件可靠性测试情况下模型质量分析结果；

图8为基于分类的软件可靠性加速测试情况下模型质量分析结果；

具体实施方式

下面将结合附图和实施例对本发明作进一步的详细说明。

本发明一种面向GUI软件的可靠性加速测试方法，是基于分类的软件可靠性加速测试方法，包括三个方面：测试用例集合分类、测试用例对比和筛选以及失效数据收集。

GUI软件的运行结果与软件的初始状态、测试历史和当前测试输入都有关系，所以最终能够划分为一类的用例，在结构信息与内容信息两方面都应是高度相似甚至是相同的。通过对软件输入内容进行等价类划分，将基础测试用例集合中操作路径相同并且相应软件输入内容均属于同一等价类的测试用例合为一类，即将结构信息相同且内容信息相同的测试用例合为一类，以保证同类用例的执行时间与执行效果是相同的，可以在同类用例集合中完成执行时间与执行效果上的替换，能够减少测试工作量。

通过对软件失效机理的探讨及对软件失效的归纳总结，结合测试用例执行顺序以及随着软件缺陷的修改而发生变化的软件输入与软件失效之间的映射关系，在测试用例执行过程中对测试用例执行效果进行标识，筛选出需要执行的测试用例，形成测试用例执行策略，指导软件可靠性加速测试情况下的用例执行。

最后，根据测试用例执行策略，执行所筛选的测试用例，根据加速测试情况下的失效数据收集方法，在得到失效数据后，进行软件可靠性评估。

一种面向GUI软件的可靠性加速测试方法，如图1所示，包括以下几个步骤：

步骤一：针对进行GUI软件可靠性测试所生成的基础测试用例集合，提取集合中每一个测试用例的标识词与特征，分别形成标识词链和特征集合。

根据软件需求规格说明与软件设计说明，将被测GUI软件的基本功能进行细化；根据所构建的被测软件可靠性测试剖面，从起始节点开始到终止节点结束，明确功能实现路径，通过遍历剖面路径生成基础测试用例集合；根据被测软件的功能路径和软件界面元素中的输入内容，定义测试用例的标识词和特征；

测试用例以动宾短语形式出现，包含一个动作和动作的受体，例如，“喝水”是一个有效的测试用例，而“喝”和“水”却不是。动宾结构作为软件的输入，经过提取宾语定义为特征，动词作为测试用例的标识词。将标识词链作为特征定位与提取的基础，在测试用例中起识别定位的作用，有助于后面行测试用例的识别、比对和筛选；

标识词为测试用例所包含的一个操作步骤，用w_j表示；特征为测试用例的一个操作步骤所对应的输入内容，用c_j表示；每个测试用例由多个不同的标识词和特征组成；

将每个测试用例的标识词与特征进行组合，形成测试用例的操作过程表达式为：

T_i＝{(w₁,c₁),(w₂,c₂),...,(w_j,c_j),...}；

T_i为测试用例；(w_j,c_j)为测试用例T_i的标识词与特征组合；i＝1,2,...,n，n为整数；

提取测试用例T_i所包含的标识词w_j，形成标识词链W＝{w₁,w₂,...,...w_j,...,w_n}；标识词链是使用软件动态过程的静态表达，区分开不同的使用路径，辅助对相同使用路径下特征的对比，通过识别标识词链来明确特征位置。

提取测试用例T_i所包含的特征c_j，形成特征集合C＝{c₁,c₂,...,...c_j,...,c_n}；j＝1,2,...,n，n为整数。

测试用例的标识词链体现了测试用例的结构信息，特征集合体现了测试用例的内容信息。

步骤二、对测试用例中每个特征对应的输入内容进行等价类划分，得到每个特征的等价类划分结果；

对每个特征c_j所对应的软件输入内容，结合GUI软件输入内容的数据类型及等价类划分规则进行等价类划分，将对应相同输出结果的输入内容合为一类，得到属于特征c_j的所有等价类。每个特征c_j均包括多个等价类，对每个等价类命名为：特征+序号；序号按整数由小到大排列，最后的序号代表了特征c_j划分后所形成的等价类数目；

步骤三、将每个测试用例的每一步输入内容，根据当前输入内容的等价类划分结果，归到相应等价类下。

根据每个特征的所有的等价类划分结果，将测试用例中的每一步输入内容划分到相应的等价类。

比如：测试用例T₁中的一个操作步骤为：输入密码；特征为：密码；

如果在对密码中的输入内容进行等价类划分后，其中将1-10中的整数数字合为一个等价类，将11-20中的整数数字合为一个等价类，则它们是属于“密码”输入内容的不同的2个等价类，分别命名为：密码1类和密码2类。如果测试用例中的输入为8，将8归到密码1类，如果测试用例中的输入为19，将19归为密码2类。

步骤四：根据测试用例的结构信息与内容信息，对基础测试用例集合进行划分，得到结构信息与内容信息均相同的各类测试用例集合。

对测试用例集合进行分类的目的是：使每一类测试用例在执行时间和执行效果是相同的。通过执行一条或几条测试用例来确定整个类的测试用例的执行时间和执行效果。基于分类的软件可靠性加速测试技术，以减少测试用例数量为手段达到减少测试时间提高测试效率的目的，同时又能够保证得到的失效数据可用来进行定量的软件可靠性评估。

根据各功能使用路径与标识词链的对应关系，将标识词链完全匹配的用例合为一类，保证了同类用例对软件的使用路径相同，同时也保证了同类用例的结构信息是相同的，基于结构信息的测试用例划分，如图2所示，步骤如下：

步骤401、将基础测试用例集合中第一个测试用例放入用例库中作为一类；

步骤402、依次按顺序对基础测试用例集合中的测试用例标识词链进行匹配分类；

依次从基础测试用例集合中按顺序选取测试用例作为待对比用例，与用例库中各类测试用例的标识词链逐类匹配；

步骤403、判断待对比用例的标识词链是否与用例库中某类用例的标识词链完全相同；

如果待对比用例的标识词链与用例库中某类用例的标识词链完全相同，则将待对比用例放在相应的类别下，否则，在用例库中增加一个类别，并将待对比用例放入新增加的类别下；

步骤404、判断当前的待对比测试用例T_i是否为基础测试用例集合中的最后一个用例，如果是，转到步骤405；如果不是，转到步骤402；

步骤405、经过分类后的测试用例形成包含不同类别的用例库，每类测试用例的标识词链和对应位置的特征均相同，同类测试用例集合中的测试用例包含相同的结构信息。

对于结构信息相同的测试用例，结合对动宾输入中宾语特征的等价类划分结果，将对应位置的软件输入均属同一等价类的测试用例合为一类。

基于内容信息的测试用例划分方法，如图3所示，如下：

步骤1、对每一类结构信息相同的测试用例集合，依次将每个测试用例的每步输入内容，根据输入内容所属的等价类，用等价类的命名进行替换。

步骤2、选取每类测试用例中的第一个测试用例作为一个子类；

步骤3、依次选取该类测试用例集合中的测试用例作为待对比用例，与该类测试用例中的子类进行等价类命名的匹配；

步骤4、判断待对比用例的特征等价类的命名与子类对应位置的特征等价类的命名是否相同，如果依次对应位置的等价类的命名均相同，则将待对比用例放在对应的子类下；否则，将待对比用例作为一个新的子类并增加到用例库中；

步骤5、判断当前的待对比用例是否为该类中的最后一个测试用例；如果“是”，进入步骤6；否则，进入步骤3；

步骤6、判断是否对所有结构信息相同的测试用例集合都进行了子类划分，如果“是”，进入步骤7；否则，进入步骤2；

步骤7、经过分类后的基础测试用例集合形成包含不同类别测试用例集合的用例库，各类测试用例在结构信息和内容信息上均是相同的。

基础测试用例集合经过划分后，同类用例的结构信息与内容信息是相同的。在不考虑内存等硬件设备在长时间运行后对用例执行效果的影响的情况下，基础测试用例集合经过划分后，同类用例的执行时间与执行效果是相同的，如果发生失效，则失效发生的模式与位置也是相同的。

步骤五：对结构信息和内容信息均相同的各类测试用例，根据软件输入与软件失效之间的映射关系，将每个测试用例中的每一步输入内容转化为失效信息或者正常信息，并在测试用例中的输入内容所在位置进行标识；

根据软件失效机理，由于软件在开发过程中产生错误，当软件执行不当的输入时，触发软件中存在的缺陷，从而引起软件发生故障，使用户认为软件发生失效。通过对软件失效机理的探讨及对软件失效的归纳总结，可在对测试用例输入内容等价类划分的基础上，建立软件输入、软件缺陷、软件失效之间网络映射关系，如图4所示。

通过映射关系，根据软件发生失效的情况，找出缺陷所在位置，以便于修改软件缺陷。根据GUI软件界面元素，软件输入可能是单点输入，也可能是组合输入。最终，通过软件输入与软件失效之间的映射关系，指导测试用例完成由输入信息到失效信息的转化，如图5所示。

其中，有些软件失效是由于触发单一的软件缺陷所引起，有些软件失效需要联合触发多个软件缺陷才会发生。转化后的测试用例保持结构不变，可根据软件输入(Vi)所属的等价类及软件输入与软件失效之间的映射关系，来获得用例中失效信息(C(Vi))存在的具体情况。

步骤六：对经过失效信息和正常信息标识后的测试用例，按照基础测试用例集合中的测试用例编号顺序执行测试，筛选各类测试用例集合中执行效果为“失效”和第一个执行效果为“正常”的测试用例；

在测试执行过程中，标识测试用例的执行效果并筛选出需要被执行的测试用例；

对基础测试用例集合中的用例进行执行效果标识的前提条件是程序中的错误是独立的，并且排错过程中不会引入新的错误。对测试用例进行执行效果标识是在测试用例执行过程中逐个完成的。当软件输入不能引起软件失效时，同等价类的输入不会引起软件失效；当软件输入引起软件失效时，在软件缺陷被修改后，同等价类的输入也不会引起软件失效。

当进行软件可靠性增长测试时，步骤五中的软件输入与软件失效之间的映射关系，会随着软件缺陷的修改而发生变化。结合测试用例执行顺序以及随着软件缺陷的修改而发生变化的软件输入与软件失效之间的映射关系，对测试用例执行效果进行判断与标识。

具体实施过程，包括：

步骤601、在对每个测试用例的每一步输入内容完成失效信息或正常信息的标识后，按照基础测试用例集合中的编号顺序开始执行第一条测试用例，进行软件可靠性测试；

步骤602、在测试用例执行过程中，对测试用例的每一步输入内容，参考软件输入与软件失效之间的映射关系，判断软件当前输入能否引起GUI软件失效，并且对测试用例中所标识的失效信息与正常信息进行处理；

在测试人员对当前的软件状态进行验证后，如果测试用例的当前输入内容不能引起GUI软件失效，则在基础测试用例集合中，同等价类输入内容所对应的失效信息便不存在；

如果测试用例当前的输入内容引起软件失效，则在当前的测试用例输入内容所在的位置保留标识的失效信息，同时对该测试用例不再继续执行可靠性测试；在基础测试用例集合的后续测试用例中，将属于同等价类的测试用例输入内容所对应的位置标识的失效信息全部删除；

比如：某条测试用例的“密码”中输入数值为8，属于“密码1类”，引起软件失效，则在当前测试用例执行位置保留失效信息；当下一条测试用例“密码”中的输入值为7，属于“密码1类”时，由于在软件缺陷被修改后，属于同等价类的软件输入不会再引起软件失效，则将测试用例中对“密码1类”所标识的失效信息删除。

步骤603、判断当前测试用例中是否存在失效信息；如果“是”，则将其执行效果标识为“失效”，进入步骤605；否则，将其执行效果标识为“正常”，进入步骤604；

测试用例的筛选与执行过程是同时进行的，所要筛选并执行的测试用例就是每一类用例集合中执行效果标识为“失效”与第一个执行效果标识为“正常”的测试用例，并且记录所筛选用例的执行时间。

步骤604、判断当前的测试用例是否为某类测试用例集合中第一个执行效果标识为“正常”的测试用例。如果“是”，该类测试用例中的后续用例不执行测试，将后续用例的执行效果都标识为“正常”。否则，进入步骤605；

步骤605、判断当前所执行的用例是否为基础测试用例集合中的最后一个用例。如果“是”，则完成对基础测试用例集合的用例执行效果标识；否则，返回步骤602按序执行基础测试用例集合中的下一条测试用例。

步骤七：对执行效果为“失效”的测试用例，累加相邻失效间隔之间测试用例的执行时间，作为失效间隔数据进行软件可靠性评估。

将基础测试用例集合中的测试用例依序在时间轴上排开，将执行效果为“失效”的测试用例序号标出，将相邻失效间隔之间测试用例的执行时间作为失效间隔数据，进行软件可靠性评估。

相邻失效间隔之间测试用例的执行时间计算方法为：在同类测试用例集合中，使用第一个执行效果标识为“正常”的测试用例的执行时间，替换同类中后续测试用例的执行时间；第一个执行效果为“失效”的测试用例的执行时间，加上中间执行效果为“正常”的测试用例的执行时间和第二个执行效果为“失效”的测试用例的执行时间。

加速测试方法实施效果分析：

对加速效率从用例执行测试数目和执行测试时间两方面，综合常规可靠性测试与可靠性加速测试两种情况，来对加速效率进行分析：

(1)、从测试用例执行数目的角度

在对基础测试用例集合进行分类后，筛选并执行的测试用例N_m共有

N_m＝D+M (1)

D表示对基础测试用例集合进行划分后的类别数，M表示执行效果标识为“失效”的用例数；

则基于分类方法进行软件可靠性加速测试，测试效率E_N提高了

其中，N表示基础测试用例集合中的测试用例数目。

(2)、从测试用例执行时间的角度

根据失效数据收集方法，常规可靠性增长测试执行过程的测试时间T_a为

t_i表示第i个用例的执行时间；N为整数。

基于分类的软件可靠性加速测试执行过程的测试时间T_b为

其中，V表示各类用例集合中第一个执行效果标识为“正常”的用例编号集合，S表示执行效果标识为“失效”的用例编号集合。

从而，基于分类方法进行可靠性加速测试的测试效率提高了

常规可靠性增长测试情况下，进行可靠性评估后得到被测软件可靠性参数K_a；基于分类的软件可靠性加速测试方法，进行可靠性评估后得到被测软件的可靠性参数数K_b。

为了保证测试加速方法的有效性，应设定阈值α，使两种情况下的可靠性参数是否满足以下关系,来验证加速情况下评估结果的有效性：

实施例：

本实施例来源于某系统中的指挥调度管理软件，属于GUI类型软件。根据被测的指挥调度管理软件在系统中的交联关系，搭建测试环境并执行测试。在前期的软件开发与测试过程中，共发现22个软件失效，并且总结了引起软件失效的软件输入以及修改软件缺陷的方法，并且软件缺陷被修改过程中不会影响其他的软件缺陷存在。

使用软件可靠性剖面构造技术，借助剖面构造工具构建被测软件的使用剖面，生成1000个XML格式的测试用例文档。在常规的软件可靠性测试情况下，当按序执行测试用例，在执行到第498个用例时，发生第22个失效。

1、确定基础测试用例集合。

在此假设在第498个用例执行后再无失效发生，将前498个用例确定为可靠性加速测试情况下的基础测试用例集合。

2、完成基础测试用例集合的划分。

通过使用剖面以及软件的需求规格说明和设计说明可以看出，软件的功能最后都要具体到一组输入操作，软件的很多使用(操作)都是通过在特定的页面中录入信息来实现的。对于被测软件，用于生成其可靠性测试用例的顶层使用剖面，如图6所示。由图中可以看出，一次完整的使用可以理解为软件一组功能组合按照某些特定的顺序的实现，如果将顶层使用剖面中的包(package)进一步展开，就得到更加细化的功能展开，而且各个功能相对独立。顶层使用剖面的包(package)中的每条使用路径代表了该模块每种使用方式，将使用路径中的每步操作定义为标识词，则可得到各使用路径的标识词链，按照一定的顺序进行组合后便形成用例的标识词链。

对软件界面中所要录入的信息，结合其输入范围、数据类型，根据等价类划分方法进行等价类划分，并保证同等价类的输入对应相同的输出结果。根据软件使用剖面，明确被测软件的操作路径并提取标识词链与特征集合，根据特征所对应的被测软件界面元素，对界面元素中的输入数据进行等价类划分。

例如，在“身份验证”软件界面中，宾语特征包括“用户名、密码、确定按钮、取消按钮”，则分别对“用户名”、“密码”、“确定”按钮、“取消”按钮中的输入内容，结合输入范围与数据类型进行等价类划分，并保证同等价类的输入对应相同的输出结果。以此类推，对其他软件功能界面中的界面元素中的输入数据进行等价类划分。

最终，将这498个XML格式的用例文档经过划分后，形成219个类。

3、测试用例完成由输入信息到失效信息的转化。

根据在软件前期的开发与测试过程中总结的信息，找到引起软件失效的软件输入以及所要修改的软件缺陷，建立软件输入、软件缺陷、软件失效的映射关系。首先，结合软件输入等价类划分结果，判断用例的每步输入信息所属的等价类；然后，根据映射关系将用例的输入内容由输入信息转化为失效信息。

4、在测试执行过程中，标识测试用例的执行效果并筛选需要被执行的测试用例。

按照测试用例执行效果标识方法并且参考常规的软件可靠性测试过程中的用例执行结果，筛选每类用例集合中发生失效的测试用例与第一个执行效果为“正常”的测试用例，共241个。

5、收集失效数据并进行软件可靠性评估。

在同类用例中，使用第一个执行效果标识为“正常”的测试用例替换同类用例中后续用例的执行时间。

常规的软件可靠性测试情况下失效间隔时间数据如表1。

表1 常规可靠性增长测试情况下的失效间隔时间数据表

失效序号	失效间隔时间	失效用例编号
			1	8840	(1，2)3
2	23400	(4-18)19
			3	22160	(20-31)32
4	9566	(33-47)48
			5	51620	(49-61)62
6	11900	(63-76)77
			7	4560	(78-93)94
8	5190	(95-105)106
			9	3880	(107-124)125
10	21120	(126-137)138
			11	84040	(139-153)154
12	14100	(155-168)169
			13	140850	(170-197)198
14	148760	(199-254)255
			15	45520	(256-287)288
16	54320	(289-301)302
			17	49910	(303-334)335
18	13750	(336-347)348
			19	4660	(349-362)363
20	181940	(364-399)400
			21	219850	(401-431)432
22	250000	(433-497)498

基于分类的软件可靠性加速测试情况下失效间隔时间数据如表2。

表2 可靠性增长加速测试情况下的失效间隔时间数据表

失效序号	失效间隔时间	失效用例编号
			1	8840	(1，2)3

2	24450	(4-18)19
			3	21350	(20-31)32
4	9665	(33-47)48
			5	50925	(49-61)62
6	12050	(63-76)77
			7	4470	(78-93)94
8	5290	(95-105)106
			9	3985	(107-124)125
10	21590	(126-137)138
			11	83940	(139-153)154
12	14150	(155-168)169
			13	142150	(170-197)198
14	148760	(199-254)255
			15	44780	(256-287)288
16	53920	(289-301)302
			17	51910	(303-334)335
18	14155	(336-347)348
			19	4569	(349-362)363
20	182540	(364-399)400
			21	223855	(401-431)432
22	252212	(433-497)498

软件可靠性评估过程中，使用拉普拉斯法来分析可靠性趋势，使用指数模型、Duane模型、J-M模型、Sch模型、M-O模型、YOO模型、G-O模型作为待选模型，使用U图、Y图、PLR图作为最优模型的评判依据。

对常规的软件可靠性测试情况下的失效数据，综合以上三条模型评判标准，结合各模型质量分析结果，如图7所示，选择J-M模型进行软件可靠性评估，模型预计结果如图所示，可靠性指标MTTF＝740775s，约合205.77h，预计200h后的可靠度R＝0.37834262；对基于分类的软件可靠性加速测试情况下的失效数据，综合以上三条模型评判标准，结合各模型质量分析结果，如图8所示，选择J-M模型进行软件可靠性评估，模型预计结果如图所示，可靠性指标MTTF＝767961s，约合213.3h，预计200h后的可靠度R＝0.39158719。

6、加速测试方法实施效果分析

从测试用例执行结果可看出：基于分类的软件可靠性加速测试方法与常规的软件可靠性测试方法相比，发现失效的能力基本一致；使用了约少51.6％的测试用例；对两组失效时间数据进行软件可靠性评估，常规可靠性测试下所得的平均失效间隔时间为740775s，加速测试下所得的平均时效间隔时间为767961s，误差为3.67％，在可接受范围内(要求小于5％)。

Claims (4)

1.一种面向GUI软件的可靠性加速测试方法，其特征在于，包括如下步骤：

步骤一、针对GUI软件可靠性测试所生成的基础测试用例集合中的每个测试用例，提取测试用例的标识词与特征，分别形成该测试用例的标识词链和特征集合；

标识词为测试用例所包含的一个操作步骤，用w_j表示；

特征代表测试用例的一个操作步骤所对应的输入内容，用c_j表示；

将每个测试用例的标识词与特征进行组合，形成测试用例的表达式为：

T_i＝{(w₁,c₁),(w₂,c₂),...,(w_j,c_j),...}；

T_i为一个测试用例；(w_j,c_j)为测试用例T_i的标识词与特征组合；i＝1,2,...,n，n为整数；

提取测试用例T_i所包含的标识词w_j，形成标识词链W＝{w₁,w₂,...,...w_j,...,w_n}；

提取测试用例T_i所包含的特征c_j，形成特征集合C＝{c₁,c₂,...,...c_j,...,c_n}；

j＝1,2,...,n，n为整数；

测试用例的标识词链体现了测试用例的结构信息，特征集合体现了测试用例的内容信息；

步骤二、对测试用例中每个特征对应的输入内容进行等价类划分，得到每个特征的等价类划分结果；

针对每个特征所对应的输入内容，将具有相同输出结果的输入内容合为一类，作为一个等价类，依次对特征中所有输入内容进行分类，得到属于特征的所有等价类划分结果；

对某个特征的某个等价类命名为：特征+序号；序号按整数由小到大排列，最后的序号代表了特征划分后所形成的等价类数目；

步骤三、将每个测试用例的每一步的输入内容，根据对应特征的等价类划分结果，归到相应的等价类下；

步骤四、根据测试用例的结构信息与内容信息，对基础测试用例集合进行划分，得到结构信息与内容信息均相同的各类测试用例集合；

步骤五、对结构信息和内容信息均相同的各类测试用例，根据软件输入与软件失效之间的映射关系，将每个测试用例中的每一步输入内容转化为失效信息或者正常信息，并在测试用例中的输入内容所在位置进行标识；

步骤六、对经过步骤五标识的测试用例按序执行测试，筛选各类测试用例执行效果为失效且各类测试用例中第一个执行效果为正常的测试用例；

步骤七、对执行效果为失效的测试用例，累加相邻失效间隔之间测试用例的执行时间作为失效数据进行软件可靠性评估。

2.如权利要求1所述的一种面向GUI软件的可靠性加速测试方法，其特征在于，所述的步骤四具体为：

基于结构信息的测试用例划分方法如下：

步骤401、将基础测试用例集合中第一个测试用例放入用例库中作为一类；

步骤402、依次按顺序对基础测试用例集合中的测试用例标识词链进行匹配分类；

依次从基础测试用例集合中按顺序选取测试用例作为待对比用例，与用例库中各类测试用例的标识词链逐类匹配；

步骤403、判断待对比用例的标识词链是否与用例库中某类用例的标识词链完全相同；

如果待对比用例的标识词链与用例库中某类别用例的标识词链完全相同，则将待对比用例放在该类别下，否则，在用例库中增加一个类别，并将待对比用例放入新增加的类别下；

步骤404、判断当前的待对比测试用例是否为基础测试用例集合中的最后一个用例，如果是，转到步骤405；如果不是，转到步骤402；

步骤405、经过分类后的测试用例形成包含不同类别的用例库，每类测试用例的标识词链和对应位置的特征均相同，同类中的测试用例包含相同的结构信息；

基于内容信息的测试用例划分方法，如下：

步骤1、对每一类结构信息相同的测试用例集合，依次将每个测试用例的每步输入内容，根据输入内容所属的等价类，用等价类的命名进行替换；

步骤2、选取每类测试用例中的第一个测试用例作为一个子类；

步骤3、依次选取该类测试用例集合中的测试用例作为待对比用例，与该类测试用例中的子类进行等价类命名的匹配；

步骤4、判断待对比用例的特征等价类的命名与子类对应位置的特征等价类的命名是否相同，如果依次对应位置的等价类的命名均相同，则将待对比用例放在对应的子类下；否则，将待对比用例作为一个新的子类并增加到用例库中；

步骤5、判断当前的待对比用例是否为该类中的最后一个测试用例；如果是 ，进入步骤6；否则，进入步骤3；

步骤6、判断是否对所有结构信息相同的测试用例集合都进行了子类划分，如果是，进入步骤7；否则，进入步骤2；

步骤7、经过分类后的基础测试用例集合形成包含不同类别测试用例集合的用例库，各类测试用例在结构信息和内容信息上均是相同的。

3.如权利要求1所述的一种面向GUI软件的可靠性加速测试方法，其特征在于，所述的步骤六具体为：

步骤601、在对每个测试用例的每一步输入内容完成失效信息或正常信息的标识后，按照基础测试用例集合中的编号顺序开始执行第一条测试用例，进行软件可靠性测试；

步骤602、在测试用例执行过程中，对测试用例的每一步输入内容，参考软件输入与软件失效间的映射关系，判断软件当前输入能否引起GUI软件失效，并且对测试用例中所标识的失效信息与正常信息进行处理；

在测试人员对当前的软件状态进行验证后，如果测试用例的当前输入内容不能引起GUI软件失效，则在基础测试用例集合中，同等价类输入内容所对应的失效信息便不存在；

如果测试用例当前的输入内容引起软件失效，则在当前的测试用例输入内容所在的位置保留标识的失效信息，同时对该测试用例不再继续执行可靠性测试；在基础测试用例集合的后续测试用例中，将属于同等价类的测试用例输入内容所对应的位置标识的失效信息全部删除；

步骤603、判断当前测试用例中是否存在失效信息；如果是，则将其执行效果标识为失效，进入步骤605；否则，将其执行效果标识为正常，进入步骤604；

测试用例的筛选与执行过程是同时进行的，所要筛选并执行的测试用例就是每一类用例集合中执行效果标识为失效与第一个执行效果标识为正常的测试用例，并且记录所筛选用例的执行时间；

步骤604、判断当前的测试用例是否为某类测试用例集合中第一个执行效果标识为正常的测试用例；如果是，该类测试用例中的后续用例不执行测试，将后续用例的执行效果都标识为正常；否则，进入步骤605；

步骤605、判断当前所执行的用例是否为基础测试用例集合中的最后一个用例；

如果是，则完成对基础测试用例集合的用例执行效果标识；否则，返回步骤602按序执行基础测试用例集合中的下一条测试用例。

4.如权利要求1所述的一种面向GUI软件的可靠性加速测试方法，其特征在于，所述的步骤七具体为：将基础测试用例集合中的测试用例依序在时间轴上排开，将执行效果为失效的测试用例序号标出，将相邻失效间隔之间测试用例的执行时间作为失效间隔数据，进行软件可靠性评估；

相邻失效间隔之间测试用例的执行时间计算方法为：在同类测试用例集合中，使用第一个执行效果标识为正常的测试用例的执行时间，替换同类中后续测试用例的执行时间；第一个执行效果为失效的测试用例的执行时间，加上中间执行效果为正常的测试用例的执行时间和第二个执行效果为失效的测试用例的执行时间。