CN103713995B - 用于确定测试数据的方法和设备 - Google Patents

Abstract

本发明的各实施方式总体上涉及用于确定测试数据的方法和设备。具体地，本发明公开一种确定在对软件进行测试中所使用的测试数据的方法，该方法涉及在使用一个或多个漏洞的知识来创建用于被测试软件的测试数据之前识别已知具有该一个或多个漏洞并且具有与被测试软件相似的结构的软件。

Description

用于确定测试数据的方法和设备

技术领域

本公开涉及潜在缺陷的识别。具体而言，本公开涉及但不限于在包括布置用于在其间传递数据的多个组件的计算机系统中的潜在缺陷的识别。

背景技术

活动的或运行的计算机系统通常具有潜在缺陷——亦称为漏洞(bug)。缺陷可导致意外的和/或不期望的计算机性能，并且可造成程序和/或系统崩溃。

在对终端系统用户的影响以及识别、隔离、修复和/或以经纠正形式再发布具有缺陷的软件方面，更加复杂和代价高昂的缺陷经常是涉及多个组件的交互或者在大型系统的情况中涉及多个子系统的交互的缺陷。

发明内容

本发明在权利要求书中陈述。

在一个示例中，描述一种计算机实现方法和一种包括用于执行该方法的处理器的设备。该方法用于导出用于在新软件(所要测试的软件)上使用的测试数据以便发现软件中的潜在缺陷或漏洞。确定新软件的软件结构对应于已知与缺陷相关联的软件结构。软件结构可涉及相关软件的仅一部分的结构元素，并且虽然其可包括例如在C编程语言中所采用的一个或多个“结构体(Struct)”，但也可以不包括任何此类“结构体”。检索关于与缺陷相关联的操作环境的信息，并继而使用该信息来创建用于测试新软件的测试数据——例如，通过设置该测试数据以包括检索到的信息。

当确定新软件的软件结构对应于与缺陷相关联的软件结构时，计算在代表新软件的软件结构的配置文件数据集与代表关联于缺陷的软件结构的配置文件数据集之间的相似性度量，并且如果该相似性度量满足预定准则，则确定新软件的软件结构充分对应于与所述缺陷相关联的软件结构。

代表所要测试的软件的软件结构的配置文件数据集可从新软件导出，并且代表与缺陷相关联的软件结构的配置文件数据集可从维护与相应缺陷相关联的多个软件结构的数据库的缺陷储库来检索。

一旦测试数据已经创建，则可将其用于测试新软件，并且如果对该测试数据的使用在新软件中引起缺陷，则可将代表新软件的结构的配置文件数据集和关于导致该缺陷的操作环境的信息中的一个或全部二者保存到一个或多个数据库。

本文描述的方法可由承载计算机可读指令的非暂时性计算机可读介质所承载，所述计算机可读指令布置用于在由处理器执行时执行这些方法。

在一个示例中，一种确定用于测试软件的测试数据的方法涉及在使用一个或多个漏洞的知识来创建用于被测试软件的测试数据之前识别已知具有所述一个或多个漏洞并具有与被测试软件相似的结构的软件。

附图说明

现将参考附图来说明本公开的示例，在附图中：

图1示出了可用于实现本公开的设备的框图；

图2示出了系统的示例架构配置文件，包括系统组件以及它们的相互关系；

图3以图形描绘了与用例相关的操作环境；

图4图示了对系统进行剖析的方法；

图5示出了创建测试数据的过程的流程图；以及

图6示出了配置用于执行图5的过程的系统的元组件的表示。

具体实施方式

现参考图1，其图示了适用于实现本公开的至少一部分的设备。具体而言，可包括通用计算机或类似的处理平台的设备100包括：与存储设备104通信的处理器102、用户输入106、显示器108、其他输出机构110和网络接口112。处理器102可包括微处理器、微控制器、数字信号处理器、类似的器件或其组合，优选地在存储设备104中所存储的可执行指令116的控制下操作。类似地，在操作期间，处理器102对也包括在存储设备104中的存储数据118以及可经由用户输入106或网络接口112提供(例如，来自数据库120)的其他输入数据进行操作。进一步地，基于由处理器102所进行的操作，可经由技术人员所周知的显示器108或其他输出机构110来输出数据。存储设备104可包括一个或多个存储器设备，包括但不限于：随机访问存储器(RAM)、只读存储器(ROM)、可移动式磁性或光学存储介质、硬盘驱动器等。

用户输入106允许用户与设备100交互，并且特别是允许用户经由一个或多个用户输入来控制由处理器102实现的处理。具体而言，用户输入106可包括用户选择设备，诸如鼠标、触摸屏、触摸板或本领域普通技术人员所知晓的类似的此类设备。显示器108可包括通常集成地或外部地随计算机一起使用的任何显示设备，诸如平板显示器、阴极射线管或其他类型的监视器。其他输出机构112可包括指示灯、发声器、扬声器或者常见于计算机中的向其用户提供信息的其他组件。网络接口112允许设备100相应地耦合至诸如万维网等公用或专用通信网络，或者诸如企业局域网或广域网等专属网络。

作为由程序及系统开发者所进行的发布前缺陷移除和质量保证过程的一部分，在计算机程序或系统发布时一般将会发现大量与该程序或系统相关的缺陷信息。该缺陷信息通常会包括关于可能或者可能已经与不同组件或子系统的交互相关联的缺陷的信息。

发明人洞察到，帕累托原理(Pareto principle)——其解释了对于许多事件，大约80％的结果来自于20％的原因——适用于涉及不同组件或子系统的交互的复杂系统中的软件缺陷。发明人通过采集关于先前已针对其他复杂系统识别出的缺陷的信息并采用该信息来提高缺陷识别效率而在技术上应用该洞察。

缺陷识别

在涉及创建新的系统或改进的系统的项目中，可运行测试以尝试识别缺陷从而可以移除该缺陷。测试的形式可以是可针对所有系统运行的例程测试，或者可以特定于系统。作为一个示例，系统的设计者或测试者可能具有关于可出现的可能的问题的直觉，并且因此测试可能期望引起这些问题。

对系统进行测试的一种方式是为其提供测试数据，作为系统执行的起始点。可以监控执行测试数据的系统，以便查看其是产生预期结果，还是产生另一结果或者崩溃、挂机、造成缓冲区溢出等。虽然测试数据可关于让系统执行的初始数据，例如在可执行程序被调用以供执行时传递给该程序的一组值，但其亦可关于一旦在程序已被调用的情况下供该程序处理的中间数据——例如，具有要向包括过程式编程语言组件的系统中的函数或者包括面向对象组件的系统中的数据对象传递的预定值的数据结构。因此，测试数据可包括中间信息——诸如某些变量或对象的值——其可使系统的中间元素能够得到测试，而无需为了抵达所要测试的位置而执行整个程序。

如果测试的结果被识别出缺陷，则可例如通过在缺陷储库或数据库中创建条目来采集已识别出缺陷这一事实和/或关于发生缺陷的操作环境的信息。一个示例缺陷储库包括与相应缺陷相关联的软件结构的数据库；该数据库可布置成不仅可对其数据进行访问，而且还能够向该数据库添加关于一个或多个软件结构和关联缺陷的新数据。关于发生缺陷的操作环境的信息可包括测试用例，或者造成该缺陷发生的用例数据——诸如两个或更多个组件之间的交互的详情。附加地或备选地，其可包括中间信息——诸如某些变量的值、某些对象的存在和可能的内容、在发生缺陷的点可用的空闲RAM量，等等。操作环境数据无需受限于在缺陷发生时记录的数据，而是可包括关于在缺陷之前的操作环境的信息，例如，如果若干个过程步骤在缺陷发生之前，则这些过程步骤中的每一个，并且可能还有与这些步骤中的每一个相关联的变量值、对象等，可被包括在操作环境数据之中。

除采集关于缺陷发生周围的操作环境的信息之外，还确定关于发生缺陷的系统的配置文件数据，并例如通过创建与对应的操作环境信息条目相关联或相链接的数据库条目而将该配置文件数据关联于操作环境信息。

系统剖析

为了能够采用所采集的关于给定缺陷及发生该缺陷的操作环境的信息来分析与发生缺陷的系统不同的系统，确定关于发生缺陷的系统的设置的配置文件数据，并将其关联于该缺陷在缺陷储库中的条目。配置文件数据可包括架构相关性、对系统的特定组件的指示以及/或者这些组件之间的相互关系，并且在图2中图示了一种示例系统设置，该图示出包括系统组件及其相互关系的系统的示例架构配置文件。在图2的顶部示出了一个分层体系结构，其中在3个层(标为层A、层B和层C)中示出了多个组件(标为Comp A至Comp J)。图2的底部提供对图2顶部的图解：参考标号210表示一层内的单个系统组件；参考标号212表示启用于组件上用以允许对系统中各个组件之间的运行时交互进行剖析的跟踪点(或挂钩)；参考标号214表示组件用来与系统中其他组件交互的接口；并且参考标号216表示组件之间通过接口的可能的运行时链接。

虽然图2的接口点本身未在图中顶部标出，但如果某一组件具有两个接口点，则可将最左侧的一个称为接口点1(IF 1)并将最右侧一个称为接口点2(IF 2)；如果某一组件仅具有一个接口点，则可将该接口点称为接口点1(IF 1)。这样的标记仅用于解释的目的，而技术人员将会认识到组件可具有不同数目的接口点并且可以有区别地对它们加以标记。

图2的系统的示例层包括：层A，对应于核心层；层B，对应于加载器层；以及层C，对应于组件层。

本领域技术人员将会认识到，虽然以上所述是参考具有分层架构的系统而描述的，但本文所述的方法可同样适用于不具有分层结构的系统。

系统中的示例组件包括：面向对象编程环境中的对象；过程式编程环境中的函数；交互计算机程序，诸如操作系统和运行于该操作系统之上的程序；以及在诸如安卓(Android)操作系统等分层架构中的不同系统元素，例如Java应用程序。

作为进一步的示例，可将复杂系统构建为“多层”架构，该架构可具有用于提供特定能力的“n”个层的系统组件。顶层组件可提供由运用系统的用户或动作者所采用的用户接口(UI)组件所需的服务，或者充当该服务的接口。中间件或中间层组件对顶层组件所需的各个功能加以简化和/或抽象，并且较低层组件对硬件组件加以抽象。银行应用是多层软件系统的一个示例。其中顶层可以是前端软件系统，诸如：账户管理应用、电子账簿、ATM前端应用等。中间层组件可提供银行应用所需的认证或安全服务，而较低层组件可包括布置用以与保存相关数据的数据库交互的数据库层。

此外，在嵌入式系统中，例如在智能电视中，多个系统组件可通过布置用于如下目的的UI组件的方式来提供特定能力：提供菜单选项；显示EPG(电子节目指南)；允许用户设置录像提醒，等等。可以存在布置用以与关键电视功能交互的核心组件——例如：解码AV信号并将其呈现在到电视屏幕上；或者提供像PiP(画中画)之类的复杂功能，在PiP中多个AV流一起被解码并呈现在屏幕上的多个“窗口”中。低层组件可与布置用以向电视中提供信号以供呈现的HDMI接口(高清多媒体接口)交互。还可以存在专用组件，例如布置用于提供数字生活网络联盟(DLNA)连接性，以供在网络上发现内容和将该内容呈现至电视上。作为一种可能性，可由系统实现支持智能电视内容发现和呈现的UPnP(通用即插即用)架构。

示例配置文件信息可包括系统的组件部分的列表、每个组件部分所交互的其他组件部分的列表、以及更复杂的系统信息。在市场上可购得多种系统剖析工具，这些工具包括：由IBM(New York,USA)提供的Rational Raphsody；由Imagix(San Luis Obispo,CA,USA)提供的Imagix 4D；UML建模语言；Intel的trace analyser(http://software.intel.com/en-us/articles/intel-trace-analyzer/)，其允许用户启动跟踪并理解MPI(消息传递接口)系统的运行时执行序列；以及Native POSIX Thread Library(NPTL http://nptltracetool.sourceforge.net/)，其为用于支持Linux软件中的跟踪能力以允许定义和启动用于观察当系统被执行时组件的运行时行为输出的跟踪点的开源软件项目。本领域技术人员将会理解，为了实现本文所述技术的目的，可以采用产生关于系统设置的配置文件数据的任何剖析工具。适合于随本文所述方法而采用的剖析工具可布置用于剖析系统以便识别出在执行特定的单个或多个用例或者一个或多个类型的用例时关于性能的系统瓶颈。作为另一可能性，适合于随本文所述方法而采用的剖析工具可布置用于在调试过程中剖析系统以帮助隔离和识别故障的根本原因。优选地，剖析工具提供对各个组件随时间推移的交互的指示以及/或者当执行特定测试用例时这些交互的序列。

虽然可对整个系统进行剖析以便提供配置文件数据，但作为另一可能性，仅对系统的一部分进行剖析。

图4图示了对系统进行剖析的可能的方法。在点410处，向建模级412提供对系统、用例信息或图表(表示定义角色(或动作者)与系统之间的交互以实现某一目标的步骤)以及/或者交互信息或图表的架构描述或定义，该建模级412解译其输入以创建配置文件数据。该配置文件数据可包括结构信息。作为一个可能性，配置文件数据包含关于可在系统的不同组件之间发生的不同交互的信息——图形地表示于414处。

当对系统进行建模以创建包含关于可在系统的不同组件之间发生的不同交互的信息的配置文件数据时，所创建的配置文件数据可以是整个系统的模型，使得系统的各个组件的“所有可能的”交互均由建模过程所采集。当已知系统具有缺陷时，配置文件数据可不包括系统的各个组件的“所有可能的”交互，并且可以备选地仅关于带来缺陷的交互的子集。当创建针对已知具有缺陷的系统的配置文件数据时，可以在从整体系统模型抽取交互子集之前对整个系统建模。

除存储创建的配置文件数据之外，还可例如在数据库120中存储与从中创建配置文件数据的整个系统或其一部分的建模有关的数据。

被剖析系统的操作环境的示例

在图3中示出了关于特定系统的操作环境的用例或集合的示例。图2中所示并于上文解释的图解同样适用于图3的系统，其描绘了可预期在针对图3的系统执行特定用例或测试用例并且开启剖析或者启动跟踪点时观察到的示例组件交互集合。在图3的示例中，出现来自系统310的各个跟踪点“tr”的以下跟踪输出：

在时间点1，在组件A的接口1上发生事件，

在时间点2，在组件B的接口1上发生事件，

在时间点3，在组件D的接口1上发生事件，

在时间点4，在组件E的接口2上发生事件，

在时间点5，在组件D的接口1上发生事件，

在时间点6，在组件H的接口1上发生事件，

在时间点7，在组件I的接口1上发生事件，

在时间点8，在组件G的接口1上发生事件，以及

在时间点9，在组件I的接口2上发生事件。

如果上述操作环境揭示出组件E中的缺陷，则把在组件E发生缺陷的信息连同关联的操作环境信息一起输入到缺陷储库中，其形式可以是：

T1->CompA.IF1

T2->Comp B.IF1

T3->CompD.IF1

T4->CompE.IF2

T5->CompD.IF1

T6->CompH.IF1

T7->CompI.IF1

T8->CompG.IF1

T9->CompI.IF2

具有相似配置文件的系统的识别

当要处理新系统以供潜在缺陷识别时，剖析该新系统。继而，使用新系统的配置文件数据来搜索缺陷储库以识别存储的与新系统的配置文件数据相同或相似的配置文件数据。当对新系统的配置文件数据与存储的配置文件数据进行比较以确定(例如，参照预定阈值)两个数据是否充分对应从而保证仿真带来造成存储的配置文件数据要被保存在缺陷储库之中的缺陷的操作环境时，可采用相似性度量。一种非常简单的相似性度量将在这两个配置文件包含相同组件(和/或相互联系)的情况下具有值1，否则具有值0。作为另一可能性，可给予每个相同组件(和/或相互联系)一个值，并采用总值作为对相似性的度量。本领域中技术人员将会认识到，为了确定两个配置文件是否对应以及/或者两个配置文件之间相似度的量，可以应用大量已知的相似性度量。例如，对于每个配置文件数据，组件和/或其相互关系可用图片或者以n-度数组及施加于其上的图像处理相似性度量来表示；示例相似性度量包括互相关、方差和、结构相似性、互信息，等等。

作为一个可能性，各个系统组件在其相应接口处的交互可使用图表来表示，其中不同的组件交互关联于图表的不同节点。继而可使用对遍历图表的路径的比较以及/或者对图表的节点的比较来评估两个不同配置文件的相似性。在这样的情况下，可例如通过计算各自表示不同配置文件的一对图表的节点之间的互相关度量来评价两个图表之间的相似性度量。

有利地，非二元相似性度量的使用支持对用于可能与构成数据储库的系统相当不同的系统的测试用例的确定。这在需要首先测试新的并且显著不同的系统时可能特别有用。作为一个可能性，可采用本文所述的方法来从一个平台识别用于在不同的其他平台上测试的测试用例。

确定测试用例

一旦已将存储的配置文件数据条目识别为具有与所要测试的新系统相似的配置文件，则从缺陷储库检索关于造成已知关联于所存储的配置文件数据的缺陷的操作环境的信息，并基于检索到的信息创建用于测试新系统的测试数据。

可将测试数据创建成与关于造成已知缺陷的操作环境的信息完全相同。作为另一可能性，测试数据可相似但不同于关于造成已知缺陷的操作环境的信息。例如，如果关于造成已知缺陷的操作环境的信息包含在于时间T2在组件A的接口1上提供数据元素B之前于时间T1向组件A的同一接口提供数据元素A，则测试数据可以是将呈送数据元素A和数据元素B的顺序调换，并且在将数据元素A提供于系统的组件A的接口1上之前于时间T1将数据元素B提供至组件A的同一端口。作为另一可能性，可以采用具有与数据元素B的值相似的值的新数据元素(数据元素C)来代替数据元素B。

本领域中技术人员将会认识到其他的方式，在其中可修改关于操作环境的信息以提供基于并且类似但不同于关于已知造成已知缺陷的操作环境的信息的测试数据。具体方式将会包括以预定的或随机/伪随机量，以及/或者通过调换信息的选定部分，来修改关于操作环境的信息的随机或伪随机地选定的特征。

一旦已创建测试用例，则可使其运行于新系统上以确定其是否造成缺陷。如果造成缺陷，则可采集关于新系统的配置文件的信息和关于所述缺陷所发生于的操作环境的信息并将其添加至缺陷储库。

图5示出了如本文所述创建测试数据的过程的流程图，而图6示出了配置用于执行图5的过程的系统的元组件的表示。在步骤510，处理器102创建用于所要测试的新系统的新配置文件数据。处理器102继而在步骤512从配置文件储库612检索一组配置文件数据。检索到的配置文件数据已于先前储存在配置文件储库612中，这是因为已知或预期检索到的配置文件数据与缺陷相关联。在步骤514，处理器102通过相似性度量的方式来评估检索到的配置文件数据与其在步骤510创建的新配置文件数据的相似性。如果相似性度量低于预定相似性阈值并且因此检索到的配置文件数据不与新配置文件数据充分相似，则过程返回到步骤512。如果相反，相似性度量高于预定相似性阈值，则处理器102继而在步骤518从缺陷储库614检索关于针对具有检索到的配置文件的系统发生缺陷的操作环境的信息。检索到的操作环境信息继而由处理器102在步骤520用于创建新系统的测试数据，处理器102在步骤522将该测试数据运行于新系统上。

作为一个可能性，为了高效地搜索缺陷，可首先将阈值设置成较高的值，使得只有具有与被测试系统非常相似的配置文件的系统才被用于测试数据的创建。随后，随着执行于每个步骤的图5的过程的循环而将阈值逐步降低，以便逐渐扩大搜索空间并于此同时首先识别最可能的缺陷。

由于复杂系统可在其组件之间具有非常大量的潜在交互，因此很少有时间测试所有可能的交互以确定对于每个给定的交互是否存在缺陷。此外，实际上，并非所有此类可能的交互在真实部署场景中都是似真的或可能的，并且因此不关注于此类交互是有帮助的。通过采用搜索空间中有可能关联于缺陷的区域的知识，显著提高了可在新系统中定位缺陷的效率。

在实际中，可能难以首先识别复杂的或困难的缺陷；本文所述的方法有利地支持在无需经历关联于首次识别的困难的情况下针对相似的缺陷进行测试。

作为一个可能性，将测试数据产生为测试程序，该测试程序将会导致与可能发生缺陷的操作环境相对应的执行序列。作为另一可能性，将测试数据产生为直接执行序列；在这样的情况下，可能需要强制进行一些交互并且可能要求测试工具。一种示例测试工具将会具有测试驱动程序组件，该测试驱动程序组件布置用于调用顶层API(应用程序接口)以便仿真特定用例的交互。由于组件交互可能因多重处理能力而并行发生，因此测试驱动程序可具有强制特定组件交互序列的能力。

在一个示例中，关于操作环境的信息符合约定的通用格式。因此，不论针对给定系统所采用的特定剖析方法如何，从各个被剖析系统生成的输出仍然是可比的/兼容的，并且能够以相同方式理解。

在一个示例中，配置文件数据符合约定的通用格式。如果使用不同的剖析工具来剖析不同的系统，则可使一个或多个所述剖析工具的输出经过适配器，以便将该输出转换成通用格式。

作为一个可能性，可在配置文件储库中以将相似的配置文件逻辑分组的方式存储配置文件数据，从而一旦已确定给定组中的一个配置文件与被测试系统的配置文件相似，则可使用该组中其他配置文件来导出测试数据，而无需进行额外的相似性度量计算。

作为一个可能性，一旦系统已得到剖析，则该系统的一个或若干个组件与其他组件具有比正常情况更多的交互变得显然。可将这样的一个或多个组件的知识当作缺陷可能与其相关联的提示，并且继而可定义与包括具有更多交互的一个或多个组件的系统的一部分相对应的新配置文件数据集以供与本文所述的方法一起使用。

本领域中技术人员将会意识到，虽然本文所述的方法可适用于测试同构型系统——例如：全都以相同的编程语言编写并且每个组件均由一个或多个测试执行方编译的系统，运行于相同操作系统(例如，移动领域中的安卓系统)中的系统，以及来自ERP领域或像基于Java开发等流行技术领域的像SAP之类的封闭/封装系统——但本文所述的系统可同样适用于可涉及多种技术、操作系统、编程语言等的异构型系统。由于可能并不存在针对给定异构型系统的单一剖析工具，因此可能需要采用多个不同的剖析工具并将它们的输出相结合以确定相似性度量。

虽然上文已在系统发布之前的缺陷识别方面进行了描述，但技术人员将会理解，本文所述方法可同样适用于持续的(发布后)缺陷识别和质量保证过程。

本文所述方法可在一个或多个计算机上实现以及由一个或多个计算机执行，并且可由包含机器可读指令的计算机可读信号和/或计算机可读介质来执行，所述机器可读指令布置用于在由处理器执行时执行一个或多个本文所述的方法。

本领域技术人员将会明白，虽然已单个地描述了在执行本文所述过程中所涉及的不同步骤，但这些步骤在适当情况下能够以组合的或并行的方式执行，并且/或者可以是全自动的或半自动的。

本领域技术人员将会理解，虽然出于解释说明目的而在本文中结合描述了多个不同的方法和设备特征，但这些特征中的每一个均可单独采用或者以任何其他组合采用，并且某一特征在特定示例中的存在并不意味着该特征对于实现该示例或另一示例而言是必要的。

Claims (15)

1.一种确定在发现软件内的潜在缺陷中使用的测试数据的计算机实现方法，该方法包括：

标识与系统相关联的配置文件数据和存储的与另一系统相关联的配置文件数据相似；

检索关于造成与所存储的配置文件数据相关联的缺陷的操作环境的信息；

基于所检索到的信息来创建用于通过以下操作测试与所述系统相关联的信息的测试数据：

使用所述关于操作环境的信息来确定所述缺陷的原因；以及

基于确定所述缺陷的所述原因来确定数据元素的布置，以通过以下至少一项来最小化未来缺陷：

修改与所述数据元素中的至少两个数据元素相关联的顺序；

或者

将所述数据元素中的数据元素用另一数据元素代替；以及

使用所述测试数据来测试与所述系统相关联的所述信息。

2.根据权利要求1所述的方法，其中标识所述配置文件数据和所存储的配置文件数据相似包括：

计算所述配置文件数据与所存储的配置文件数据之间的相似性的度量；以及

确定所计算出的相似性度量满足预定准则。

3.根据权利要求1所述的方法，还包括：

从所述系统导出所述配置文件数据。

4.根据权利要求1所述的方法，还包括：

从包括多个配置文件数据类型的存储设备检索所存储的配置文件数据。

5.根据权利要求1所述的方法，其中修改与所述至少两个数据元素相关联的所述顺序包括：

调换所述至少两个数据元素的所述顺序。

6.根据权利要求1所述的方法，还包括：

基于测试与所述系统相关联的所述信息，确定特定缺陷发生；以及

基于确定所述特定缺陷发生，存储关于与所述特定缺陷相关联的操作环境的信息。

7.根据权利要求1所述的方法，还包括：

存储所述配置文件数据；以及

使用所存储的配置文件数据来测试另一系统。

8.一种计算机可读介质，包括机器可读指令，该机器可读指令布置用于在由处理器执行时执行任一前述权利要求所述的方法。

9.一种用于确定在发现软件内的潜在缺陷中使用的测试数据的设备，该设备包含计算机处理器，该计算机处理器布置用于：

标识与系统相关联的配置文件数据和存储的与另一系统相关联的配置文件数据相似；

检索关于造成与所存储的配置文件数据相关联的缺陷的操作环境的信息；

基于所检索到的信息来创建用于通过以下操作测试与所述系统相关联的信息的测试数据：

使用所述关于操作环境的信息来确定所述缺陷的原因；以及基于确定所述缺陷的所述原因来确定数据元素的布置，以通过以下至少一项来最小化将来的缺陷：

修改与所述数据元素中的至少两个数据元素相关联的顺序；或者

将所述数据元素中的数据元素用另一数据元素代替；以及

使用所述测试数据来测试与所述系统相关联的所述信息。

10.根据权利要求9所述的设备，其中所述处理器布置用于：

计算所述配置文件数据与所存储的配置文件数据之间的相似性的度量；以及

确定所计算出的相似性度量满足预定准则。

11.根据权利要求9所述的设备，其中所述处理器布置用于从所述系统导出所述配置文件数据。

12.根据权利要求9所述的设备，其中所述处理器布置用于从包括多个配置文件数据类型的存储设备检索所存储的配置文件数据。

13.根据权利要求9所述的设备，其中所述处理器布置用于调换所述至少两个数据元素的所述顺序。

14.根据权利要求9所述的设备，其中所述处理器布置用于基于测试与所述系统相关联的所述信息，确定特定缺陷发生；以及

基于确定所述特定缺陷发生，存储关于与所述特定缺陷相关联的操作环境的信息。

15.根据权利要求9所述的设备，其中所述处理器布置用于存储所述配置文件数据；以及

使用所存储的配置文件数据来测试另一系统。