CN114328228A - 基于测试用例扩展的软件错误验证方法、装置及系统 - Google Patents

Abstract

本发明提供了基于测试用例扩展的软件错误验证方法、装置及系统。该方法，包括：在检测到发生第一执行错误时，提取已经执行的操作的第一集合；从所述第一集合中，提取多个所述已经执行的操作，组合得到第一扩展用例，所述第一扩展用例中设置有至少一个针对所述第一执行错误的判定点；检测所述第一扩展用例的执行，在所述至少一个针对所述第一执行错误的判定点，检测到所述第一执行错误的生成。综上，本发明提供的基于测试用例扩展的软件错误验证方法，通过从最大化的操作的组合的方式中，筛选可以定位到错误的最少操作的组合，便于定位导致问题的关键操作步骤，节约了测试时间。

Description

基于测试用例扩展的软件错误验证方法、装置及系统

技术领域

本发明涉及软件测试技术领域，特别是基于测试用例扩展的软件错误验证方法、装置及系统。

背景技术

随着半导体产业快速发展，检测集成电路功能的完整性、以确保集成电路生产制造质量的自动测试设备(Automatic Test Equipment，ATE)飞速发展，应用于ATE的测控软件也日益繁多。

任一款软件或多或少都会存在漏洞(Bug)，为了进一步改善和优化这些软件，提高软件应用时的稳定性和可靠性，需要将这些漏洞找出，并予以解决。软件测试(SoftwareTesting)，正是针对软件漏洞所提出的一个解决途径。软件测试时，按照测试方案对被试软件进行功能测试或性能测试，并对测试过程中可能出现的问题，如软件错误，进行分析、定位和评估。

提高软件测试效率，缩短软件测试消耗的时间，或以较少的工作量实现较大的测试覆盖面、测试更多的使用情景，是软件测试领域急需解决的问题。

发明内容

本发明的主要目的在于提供基于测试用例扩展的软件错误验证方法、装置及系统，以对应解决上述技术问题中的一个或多个。

第一方面，本发明提供一种基于测试用例扩展的软件错误验证方法，用于自动测试设备，包括：在检测到发生第一执行错误时，提取已经执行的操作的第一集合；

从第一集合中，提取多个已经执行的操作，组合得到第一扩展用例，第一扩展用例中设置有至少一个针对第一执行错误的判定点；

检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成。

在一些实施中，还包括：检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，均检测不到第一执行错误的生成，但检测到第二执行错误时，将第二执行错误与第一扩展用例关联；

第一执行错误与第二执行错误不同。

在一些实施中，在检测到第一执行错误的生成之后，还包括：

针对第一扩展用例，提取已经执行的操作的第二集合；

从第二集合中，提取多个已经执行的操作，组合得到第二扩展用例，第二扩展用例中设置有至少一个针对第一执行错误的判定点；

检测第二扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成。

在一些实施中，已经执行的操作由被试软件执行；

被试软件已经执行的操作由测试软件触发。

在一些实施中，被试软件和测试软件运行在自动测试设备上。

第二方面，本发明提供一种基于测试用例扩展的软件错误验证装置，包括：

第一测试单元，用于在检测到发生第一执行错误时，提取已经执行的操作的第一集合；

用例生成单元，用于从第一集合中，提取多个已经执行的操作，组合得到第一扩展用例，第一扩展用例中设置有至少一个针对第一执行错误的判定点；

第二测试单元，用于检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成。

在一些实施中，第二测试单元，还用于：检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，均检测不到第一执行错误的生成，但检测到第二执行错误时，将第二执行错误与第一扩展用例关联；第一执行错误与第二执行错误不同。

在一些实施中，第二测试单元，还用于：在检测到第一执行错误的生成之后，

针对第一扩展用例，提取已经执行的操作的第二集合；

从第二集合中，提取多个已经执行的操作，组合得到第二扩展用例，第二扩展用例中设置有至少一个针对第一执行错误的判定点；

检测第二扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成。

在一些实施中，已经执行的操作由被试软件执行；

被试软件已经执行的操作由测试软件触发；

被试软件和测试软件运行在自动测试设备上。

第三方面，本发明提供一种基于测试用例扩展的软件错误验证系统，包括：

用例生成设备、自动测试设备、被试软件、测试软件、根据第二方面中说明的软件错误验证装置；

软件错误验证装置的第一测试单元及第二测试单元运行在自动测试设备上；

软件错误验证装置的用例生成单元运行在用例生成设备；

用例生成单元生成的第一扩展用例中包括的操作由被试软件执行；

被试软件针对第一扩展用例中包括的操作的执行由测试软件触发；

被试软件和测试软件运行在自动测试设备上。

综上，本发明提供的基于测试用例扩展的软件错误验证方法、装置及系统，用于自动测试设备时，先设计包括较少操作或较少的操作的组合的测试用例，并在检测到执行错误之后，针对这个执行错误，找到触发这个执行错误的最少操作的组合。并且，只在测试用例发生执行错误时，才执行找到触发这个执行错误的最少操作的组合，整体上节省了针对自动测试设备上运行的被试软件的测试时间。

以及，从尽可能多的操作的组合方式中，筛选可以定位到执行错误的最少操作的组合，便于从尽可能大的范围内，充分筛选及比较，以定位导致问题的关键操作步骤。

并且，生成了多种扩展用例，丰富了测试用例的数量，增加了测试情景的数量，有利于进一步披露被试软件潜在的问题。

附图说明

图1为本申请实施例一个基于测试用例扩展的软件错误验证方法的流程示意图；

图2为本申请实施例另一个基于测试用例扩展的软件错误验证方法的流程示意图；

图3为本申请实施例再一个基于测试用例扩展的软件错误验证方法的流程示意图；

图4为本申请实施例基于测试用例扩展的软件错误验证装置及系统的组成示意图；

图5为利用本申请实施例的软件错误验证方法进行软件测试时的流程示意图；

图6为现有的软件测试的流程示意图。

具体实施方式

下面参见图1至图6对本发明所述的基于测试用例扩展的软件错误验证方法、装置及系统进行详细说明。

通常，执行软件测试(Software Testing)时，会在运行被试软件的设备上触发被试软件运行一系列的测试用例(Test Case)，并在各测试用例中执行一系列的操作(Operation)，或操作的组合。并通过在判定点比较生成的实际结果和预期结果是否相同来判断被试软件的功能的正确性或性能的可靠性。不同测试情景下的测试用例可以用来模拟用户使用被试软件时触发的多种多样的使用场景。如，根据被试软件向用户展示的功能，如针对人机交互界面提供的操作按钮，按照其展示的执行逻辑，或根据人类语言解析出的语义逻辑，或者根据工程实施上的技术逻辑，来设计操作的组合。

在设计测试用例时，既要使得测试用例的覆盖面广、测试情景多，又要使得用例的执行时间短，用例占用的存储空间小。但受限于测试时间、测试逻辑、测试成本等，不可能进行全覆盖测试，如构造出针对所有操作的所有组合排列，这将导致测试情景过多，用例占用的存储空间也过多，发生“测试组合爆炸”现象，如，很多测试情景是用户使用中不会发生的情景，既浪费时间又占用空间。

如图4所示，为了对ATE设备200的测控软件(也即被试软件210)进行软件测试，需要开发测试软件100。测试软件及被试软件可以存储在ATE设备200的内部存储器件或可访问的外部存储器件。测试人员根据ATE测控软件提供的命令、编程接口、或人机交互界面的控件等操作元素(以下称操作)，根据ATE测控软件提供的功能描述或性能描述，设计测试方案和测试用例，并将各测试用例代码化为可以在ATE设备200上独立运行的应用程序。

应该理解为，ATE测控软件提供的操作是向用户、测试人员或维护人员开放的标准的操作，分别具有预先设定的执行逻辑、执行内容、或执行对象等，用于实现预先设定功能或预先设定性能。

测试人员还可以在测试用例的基础上，通过对至少一个测试用例的调用或组合，形成可以在ATE设备200上运行的测试脚本。测试人员还可以在形成针对被试软件的测试方案时，通过对至少一个测试用例分别对应的应用程序、和/或测试脚本的调用或组合，形成测试软件。

应该理解为，以上被试软件是ATE测控软件，为应用程序，并不涉及与ATE设备的硬件有关的驱动程序的测试。

如图4所示，针对被试软件210进行测试时，测试软件100及被试软件210分别运行在ATE设备200上，并由测试软件100调用被试软件210，触发被试软件执行预先设计的针对多个操作的测试用例的执行，并生成实际结果，如实际结果为ATE设备响应输入A的输出B，或执行设备访问C后，设备访问返回的状态量D。实际结果既可以是与预期结果相同或相似的数据或信息，也可以是与预期结果之间不具有任何相关性的数据或信息。

应该理解为，软件测试通常是自动化执行的，并就执行后的实际结果自动进行判断比较，在本次测试执行结束之前，不需要人工干预。

通常，针对被试软件确定的测试方案包括多个测试用例，并按照执行顺序的先后将这些测试用例进行编号以标识各测试用例，如，测试方案U中包括测试用例1、测试用例2、…、测试用例m、…、测试用例mm，测试用例1最先被执行，测试用例mm最后被执行。每一个测试用例中，包括多个操作，并按照执行顺序的先后将这些操作进行编号以标识各操作，如图6所示，测试用例1中包括操作1、操作2、…、操作n、…、操作nn(图中未示出)，操作1最先被执行，操作nn最后被执行。测试用例中的各操作按照其执行逻辑被组合后，实现预先设定的测试情景。

另外，测试用例中还包括多个判定点。如，测试用例1中，在操作n之后，设定有判定点11。判定点由测试用例指定，用于确定自上一个判定点之后、截止当前，被试软件是否发生了执行错误。执行错误的表现方式，或执行错误的类型可以有多种，在形成测试用例时已经预先指定，如，对应于各判定点，被试软件执行的预期结果可以记录在测试用例内、测试脚本中，也可以记录在其他被试软件可以访问到的文件中。具体地，可以是针对某一个操作设置一个判定点，也可以是针对多个连续的操作设置一个判定点。

执行软件测试时，可能发生错误的时机是预先指定的，这些判定点在测试用例中的位置及判定点的数量是预先设定的，也即，每一次执行软件测试时，执行的判定点的数量是预先确定的，发生执行错误的数量不大于判定点的数量。但是，在测试用例没有执行之前，无法预测会在测试用例的哪一个判定点出错。

在ATE设备执行测试软件，实施前述的测试方案U时，从执行测试用例1开始，由被试软件触发测试软件执行如图6所示的操作1开始，依次执行各操作，直到执行完成操作n，这时，被试软件执行得到实际结果B11。响应于判定点11，测试软件将获取的预期结果A11，与获取的被试软件执行的实际结果B11进行比较。若比较之后，确定被试软件发生了执行错误(Error)，则记录测试结果，这时，测试结果包括：执行结果比较的时间、实际结果B11、预期结果A11等。若比较之后，确定被试软件执行正确，则记录测试结果，这时，测试结果包括：执行结果比较的时间、实际结果B11、预期结果A11等。以上响应于判定点11的处理，可以认为是一个检测发生执行错误的过程。

自然地，如果在先执行的操作生成的数据不会被在后执行的操作或测试用例引用时，也可以在整个测试用例或测试方案完成之后，再进行针对各实际结果与预期结果的比较，并记录测试结果。

记录测试结果后，针对判定点11的执行结束；继续执行测试用例1中记载的其他操作，并在执行到其他判定点1*时(*对应的正整数不为1)类似地执行前述的检测发生执行错误的过程。并在测试用例1执行完成之后，继续后续的执行测试用例2等，直到完成整个测试方案U。

在整个测试方案U完成之后，根据记录的测试结果，进行分析和评估，并定位到产生各执行错误的测试用例、操作、操作组合或测试情景。

可以看出，上述在实施软件测试时，在判断被试软件发生了执行错误之后，并不中止或中断执行，而是继续执行后续的操作或测试用例，直到完成整个测试方案。这就导致只有在ATE设备执行了完整的测试方案之后，才可以启动针对各执行错误的错误验证工作和问题定位工作。通常一个测试方案完整地执行一次耗时较长，因此，上述方法难以及时、快速地针对已经披露出的软件错误进行验证和定位，不必要地延长了软件测试的工作周期，降低了工作效率。

本申请实施例的基于测试用例扩展的软件错误验证方法、装置和系统，针对判断出的被试软件的每一个执行错误，在检测到执行错误发生时，就针对该执行错误生成新的测试用例，尝试进行错误验证和问题定位，因此能够及时、快速地针对已经披露出的软件错误进行验证和定位，提高软件测试的效率。这时，生成的新的测试用例或者可以复现该执行错误，或者可以触发新的执行错误。因此，可以增加测试的覆盖面、测试情景，或进一步披露被试软件的潜在错误。

如图1所示，本申请实施例的基于测试用例扩展的软件错误验证方法，包括：

步骤S11：在检测到发生第一执行错误时，提取已经执行的操作的第一集合。

在ATE设备执行测试软件时，会生成工作日志，日志中记载已经执行的各操作、各测试用例或各测试方案。并且，日志中也会记录执行各操作时，依次生成的各种状态量、过程量、设备硬件参数等变量的数值，如ATE设备响应输入A的输出B，或执行设备访问C后，设备访问返回的状态量D。

在检测到设置在某操作之后的某判定点确定被试软件发生了第一执行错误时，根据工作日志，提取自上一次错误验证或定位之后、截止当前、已经执行的全部操作，并形成第一集合。或者，提取当前的测试用例中，截止当前、已经执行的全部操作，并形成第一集合。

在第一集合中，已经执行的全部操作按照其执行时间的先后顺序进行排序。这时，第一集合中，相同执行内容的同一操作可能会出现多次，也即，操作O1先后多次被执行。但是，操作O1与在先的至少一个操作O1B和/或在后的任一操作O1A组合而成的操作组OG11，与其他包括有操作O1的操作组OG12不同。其中，操作组OG11和操作组OG12不同，包括：操作组OG11和操作组OG12中包括的操作的数量不同，和/或各操作被执行的先后顺序不同。

上述检测发生第一执行错误的过程与前述相同，不再赘述。

以上步骤S11可以由当前版本的测试软件V1在ATE设备200上运行来实施，这时，测试软件V1中还包括测试用例，并且，该测试用例中包括的操作被执行时，发生第一执行错误。

步骤S12：从第一集合中，提取多个已经执行的操作，组合得到第一扩展用例，第一扩展用例中设置有至少一个针对第一执行错误的判定点。

在检测到测试用例发生执行错误时，此时导致问题发生的软硬件环境可能还没有改变，因此要尽可能多的进行错误验证和定位尝试，以尽可能获取丰富的潜在错误，如除外第一执行错误之外的其他执行错误，以及确定包括的操作的数量最少的测试用例。

从第一集合中，提取多个已经执行的操作，组合得到第一扩展用例的目的是通过有限次数的尝试，搜索到包括有尽量少的操作的测试用例来验证第一执行错误，以便通过比第一集合更小的其他集合来定位被试软件发生第一执行错误的原因，进而定位导致执行错误的问题所在。

在从第一集合中，提取多个已经执行的操作时，提取规则可以是针对全部操作进行数学意义上的排列组合，如，在第一集合中包括M个执行内容不同的不同操作时，依次枚举包括有2个、3个、直到包括M-1个的操作的排列组合，也即，自i取2的数值开始，直到i取M-1的数值结束，分别得到

个依次包括i个操作的排列组合，也即分别得到

个依次包括i个操作的第一扩展用例。这时，任一第一扩展用例中包括的操作的数量均不大于已经执行的全部操作的数量，也即第一集合中包括的操作的数量。

以及，根据以上排列组合的结果，可以由人类专家就其可行性进行审核，并筛选出符合被试软件的执行逻辑的排列组合作为可选的第一扩展用例。

在从第一集合中，提取多个已经执行的操作时，提取规则还可以是与当前测试用例的测试情景相结合，根据其展示的执行逻辑，或者根据人类语言解析出的语义逻辑，或者工程实施上的技术逻辑，来提取多个操作并组合，得到一个或多个第一扩展用例。

如此，前述的多个第一扩展用例，是通过数学意义上的排列组合或结合预先设定的执行逻辑结合生成的，扩展用例的数量丰富，差异性大，从而可以增加更多测试情景，进一步地披露被试软件中可能潜在的导致执行错误的问题。

针对以上基于已经执行的操作组合得到的第一扩展用例，参照前述针对判定点的说明，在对应的操作之后，设置判定点，并将对应的预期结果关联到该判定点，以在ATE设备执行软件测试时，响应该判定点，并检测是否发生第一执行错误，以复现第一执行错误。

在根据不同的预期结果和各自对应的实际结果都可以确定发生第一执行错误时，为了避免虚警或误判，可以设置多个不同的判定点，并就不同的预期结果和各自对应的实际结果分别判定是否发生了第一执行错误。

并且，第一扩展用例中，还可以设置响应与第一执行错误相关的其他执行错误的其他判定点，或者针对被试软件的一些通用的执行错误的判定点。

参照前述描述，步骤S12可以由用例生成设备执行，并生成多个扩展用例设备。随后，还可以将第一扩展用例代码化，形成可以在ATE设备上运行的应用程序，并作为新版本的测试软件V2在ATE设备上运行，以继续测试被试软件。

步骤S13：检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成。

上述检测发生第一执行错误的过程与前述相同，不再赘述。

以上步骤S13也可以由新版本的测试软件V2在ATE设备上运行来实施。

步骤S11是在初始生成的测试情景相对简单的测试用例中，尝试性地发现第一执行错误；而步骤S13则是在检测到第一执行错误后才执行的，其目的在于从第一扩展用例中复现出第一执行错误，通过验证软件错误的方法，确定导致执行错误的最小的操作的组合，以便于进行问题定位。

如，在一个执行步骤S11至S13的实施例中，当前检测到第一执行错误的测试用例X包含第1至第10个共10个操作，而生成的某一个第一扩展用例Y1中仅包含第8、第9、第10个操作，而另一个第一扩展用例Z1仅包含第9、第10个操作。这时，若执行第一扩展用例Y1或第一扩展用例Z1都可以复现第一执行错误，那么可以确定仅包含第9和第10个操作的第一扩展用例Z1可能会直接导致第一执行错误，或确定包含第8、第9及第10个操作的第一扩展用例Y1可能会间接导致第一执行错误。随后，可以设计更简单的扩展用例来进一步进行针对第一执行错误的验证，如参照下述的步骤S15至S17。

因为第一扩展用例是通过数学上的排列组合的方式枚举地生成的，因此，不一定能够复现第一执行错误，可能会出现新的不同于第一执行错误的其他测物，也可能不会出现任何的执行错误。因此，如图2所示，本申请实施例的基于测试用例扩展的软件错误验证方法，还可以包括：步骤S14：检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，均检测不到第一执行错误的生成，但检测到第二执行错误时，将第二执行错误与第一扩展用例关联，并作为新的测试用例和/或新的测试情景。

这里的关联，是指在检测到第二执行错误时，第一扩展用例中已经执行的全部操作，可以作为可能直接或间接导致第二执行错误的操作的集合。

如，在一个执行步骤S11至S14的实施例中，当前检测到第一执行错误的测试用例X包含第1至第10个共10个操作，但是，执行仅包括第8和第9个操作的第一扩展用例W1时，检测不到第一执行错误的生成，但检测到第二执行错误。

随后，可以就第二执行错误与第一扩展用例，将第二执行错误作为新的第一执行错误，就第一扩展用例，执行步骤S11至步骤S13的软件错误验证方法，以就第二执行错误实施软件错误验证及问题定位，不再赘述。

步骤S14中，检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，还可以检测到第三执行错误、第四执行错误等。这时，将第三执行错误、第四执行错误等同地视为第二执行错误，重复以上针对第二执行错误的处理即可。

如此，在执行第一扩展用例时，可以披露被试软件更多的执行错误，增加了针对被试软件的测试情景，也增加了测试的覆盖面，从而有利于在较短的测试时间内，及时、快速地完成错误验证和问题定位，提高软件测试的效率。

以上步骤S14可以由新版本的测试软件V2在ATE设备上运行来实施。

另一方面，因为被试软件的执行错误的产生原因可能仅由个别操作导致，而与其他的操作无关。而前述的枚举出全部的第一扩展用例，并分别利用步骤S11至S14测试各扩展用例以复现第一执行错误或披露其他的执行错误，尽管可以做到不遗漏，但是将消耗较多的测试时间。因此可以先选择包含的操作的数量较多的一些第一扩展用例来复现第一执行错误，并在已经确定可以复现第一执行错误的第一扩展用例中选择其包括的全部操作的子集，也即下述的第二集合中进一步提取各第二扩展用例，以进一步确定包括更少的操作的数量的测试用例。

如图3所示，在步骤S13中检测到第一执行错误的生成之后，还包括：

步骤S15：针对第一扩展用例，提取已经执行的操作的第二集合；

步骤S16：从第二集合中，提取多个已经执行的操作，组合得到第二扩展用例，第二扩展用例中设置有至少一个针对第一执行错误的判定点。

步骤S17：检测第二扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成。

以上，步骤S15至步骤S17，在操作的数量已经减少的第二集合的基础上，相似地执行S11至步骤S13，旨在进一步寻找操作的数量更少的集合，也即，搜索包括尽量少的操作的测试用例来验证第一执行错误，以更准确地定位被试软件发生第一执行错误的原因，进而定位导致第一执行错误的问题所在。这时，任一第二扩展用例中包括的操作的数量均不大于第二集合中包括的操作的数量。

这时，执行第一扩展用例和第二扩展用例，都可以检测发生第一执行错误，但第二扩展用例中包括的操作的数量更少。

如，根据第一扩展用例Y1可以定位到第9和第10个操作导致第一执行错误，根据第二扩展用例Y2可以定位到第9个操作导致第一执行错误。以及，执行仅包括第10个操作的第二扩展用例W2，还可以检测到第二执行错误。

以及，在步骤S17，检测不到第一执行错误的生成，而检测到其他的执行错误的生成之后，处理的方法参照步骤S14，不再赘述。

以及，在步骤S17之后，可以针对第二扩展用例，和第一执行错误，将第二扩展用例作为新的第一扩展用例，重复步骤S15至步骤S17，继续搜索包括的操作的数量更少的扩展用例，不再赘述。

如此，在检测到测试用例发生执行错误时，直接中断当前测试用例的执行，而转入针对执行错误的验证和定位动作。并在验证和定位工作完成之后，更新测试用例，并继续测试用例的执行，从而实现了及时、快速地验证被试软件的执行错误和定位问题，提高了测试效率。

如此，在测试整个过程中，可以实现用例的复杂度和用例的覆盖面的取舍与平衡。在初期，设计相对简单的测试用例。通过测试用例在执行中发生的执行错误，进一步丰富测试用例和测试情景，逐渐增加用例的复杂度(如，用例中包括更多种类的操作及操作的组合)和覆盖面(如，用例中包括更多种类的操作及操作的组合)。

综上，本发明提供了一种软件测试的工程化方法，先设计包括较少操作或操作的组合的测试用例，并在检测到执行错误之后，针对这个执行错误，找到触发这个执行错误的最少操作的组合。并且，只在测试用例发生执行错误时才执行错误验证步骤，节约了测试时间通过从最大化的操作的组合的方式中，筛选可以定位到错误的最少操作的组合，便于定位导致问题的关键操作步骤。在生成扩展用例时，丰富了测试用例的数量，增加了测试情景的数量，有利于披露被试软件潜在的问题。

本发明的软件验证方法，在软件测试中发现问题后，并不立即执行后续测试或停止测试，而是通过自动扩展用例并执行扩展后用例的方式，增加测试覆盖面和可能的测试情景，并通过尝试回溯已经执行过的操作，找出导致执行错误发生的关键操作。

如图4所示，本申请实施例的基于测试用例扩展的软件错误验证装置400，包括：第一测试单元410，用于在检测到发生第一执行错误时，提取已经执行的操作的第一集合；用例生成单元420，用于从第一集合中，提取多个已经执行的操作，组合得到第一扩展用例，第一扩展用例中设置有至少一个针对第一执行错误的判定点；

第二测试单元430，用于检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成。

在一些实施中，第二测试单元430，还用于：检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，均检测不到第一执行错误的生成，但检测到第二执行错误时，将第二执行错误与第一扩展用例关联；第一执行错误与第二执行错误不同。

在一些实施中，第二测试单元430，还用于：在检测到第一执行错误的生成之后，针对第一扩展用例，提取已经执行的操作的第二集合；从第二集合中，提取多个已经执行的操作，组合得到第二扩展用例，第二扩展用例中设置有至少一个针对第一执行错误的判定点；检测第二扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成。

如图4所示，本申请实施例的基于测试用例扩展的软件错误验证系统1000，包括：用例生成设备300、自动测试设备200、被试软件210、测试软件100、前述的软件错误验证装置400；软件错误验证装置的第一测试单元410及第二测试单元430运行在自动测试设备上；软件错误验证装置的用例生成单元420运行在用例生成设备300；用例生成单元420生成的第一扩展用例中包括的操作由被试软件210执行；被试软件210针对第一扩展用例中包括的操作的执行由测试软件100触发；被试软件210和测试软件100运行在自动测试设备上。

如图5所示，基于测试用例扩展的软件错误验证系统用于对ATE设备上运行的ATE测控软件，也即被试软件，实施前述的测试方案U时，首先使得测试软件运行在ATE设备上，并调用被试软件，以触发被试软件执行包括有多个操作(如操作1、操作2、…、操作n)的测试用例的执行。这时，测试软件中包括第一测试单元、测试方案U对应的各测试用例。在第一测试单元检测到发生第一执行错误时，提取已经执行的操作的第一集合。

随后，由运行在用例生成设备上的用例生成单元从第一集合中，提取多个已经执行的操作，组合得到第一扩展用例。应该理解为，这时，测试软件在ATE设备上的运行暂停，等待用例生成设备生成第一扩展用例。在第一扩展用例生成之后，将第一扩展用例代码化后的应用程序在新版本的测试软件中，这时，新版本的测试软件中可以不再包括第一测试单元、初始阶段的测试用例，但是，必须包括第二测试单元和第一扩展用例。

随后，使得新版本的测试软件运行在ATE设备上，并调用被试软件，以触发被试软件执行第一扩展用例中包括的多个操作；并由第二测试单元检测第一扩展用例的执行，在至少一个针对第一执行错误的判定点，检测到第一执行错误的生成，以复现第一执行错误。

参考前述的说明，在针对第一执行错误的错误验证完成之后，可以继续针对测试方案U的测试。

在一些实施例中，用例生成设备可以实施在PC机上，或任何的具有处理器的计算设备上，如，也可以设置在前述的自动测试设备上。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

Claims (10)

1.一种基于测试用例扩展的软件错误验证方法，其特征在于，用于自动测试设备，所述方法，包括：

在检测到发生第一执行错误时，提取已经执行的操作的第一集合；

从所述第一集合中，提取多个所述已经执行的操作，组合得到第一扩展用例，所述第一扩展用例中设置有至少一个针对所述第一执行错误的判定点；

检测所述第一扩展用例的执行，在所述至少一个针对所述第一执行错误的判定点，检测到所述第一执行错误的生成。

2.根据权利要求1所述的方法，其特征在于，还包括：

检测所述第一扩展用例的执行，在所述至少一个针对所述第一执行错误的判定点，均检测不到所述第一执行错误的生成，但检测到第二执行错误时，将所述第二执行错误与所述第一扩展用例关联；

所述第一执行错误与所述第二执行错误不同。

3.根据权利要求1所述的方法，其特征在于，

在所述检测到所述第一执行错误的生成之后，还包括：

针对所述第一扩展用例，提取已经执行的操作的第二集合；

从所述第二集合中，提取多个所述已经执行的操作，组合得到第二扩展用例，所述第二扩展用例中设置有至少一个针对所述第一执行错误的判定点；

检测所述第二扩展用例的执行，在所述至少一个针对所述第一执行错误的判定点，检测到所述第一执行错误的生成。

4.根据权利要求1至3中任一项所述的方法，其特征在于，

所述已经执行的操作由被试软件执行；

所述被试软件已经执行的操作由测试软件触发。

5.根据权利要求4所述的方法，其特征在于，

所述被试软件和所述测试软件运行在所述自动测试设备上。

6.一种基于测试用例扩展的软件错误验证装置，其特征在于，包括：

第一测试单元，用于在检测到发生第一执行错误时，提取已经执行的操作的第一集合；

用例生成单元，用于从所述第一集合中，提取多个所述已经执行的操作，组合得到第一扩展用例，所述第一扩展用例中设置有至少一个针对所述第一执行错误的判定点；

第二测试单元，用于检测所述第一扩展用例的执行，在所述至少一个针对所述第一执行错误的判定点，检测到所述第一执行错误的生成。

7.根据权利要求6所述的装置，其特征在于，

所述第二测试单元，还用于：检测所述第一扩展用例的执行，在所述至少一个针对所述第一执行错误的判定点，均检测不到所述第一执行错误的生成，但检测到第二执行错误时，将所述第二执行错误与所述第一扩展用例关联；所述第一执行错误与所述第二执行错误不同。

8.根据权利要求6所述的装置，其特征在于，

所述第二测试单元，还用于：在所述检测到所述第一执行错误的生成之后，

针对所述第一扩展用例，提取已经执行的操作的第二集合；

从所述第二集合中，提取多个所述已经执行的操作，组合得到第二扩展用例，所述第二扩展用例中设置有至少一个针对所述第一执行错误的判定点；

检测所述第二扩展用例的执行，在所述至少一个针对所述第一执行错误的判定点，检测到所述第一执行错误的生成。

9.根据权利要求6至8中任一项所述的装置，其特征在于，

所述已经执行的操作由被试软件执行；

所述被试软件已经执行的操作由测试软件触发；

所述被试软件和所述测试软件运行在自动测试设备上。

10.一种基于测试用例扩展的软件错误验证系统，其特征在于，包括：

用例生成设备、自动测试设备、被试软件、测试软件、根据权利要求6至9中任一项所述的软件错误验证装置；

所述软件错误验证装置的第一测试单元及第二测试单元运行在所述自动测试设备上；

所述软件错误验证装置的用例生成单元运行在所述用例生成设备；

所述用例生成单元生成的第一扩展用例中包括的操作由所述被试软件执行；

所述被试软件针对第一扩展用例中包括的操作的执行由所述测试软件触发；

所述被试软件和所述测试软件运行在所述自动测试设备上。

Images