CN106294120A - 测试代码的方法、设备和计算机程序产品 - Google Patents

Abstract

本公开的实施例提供了测试代码的方法、设备和计算机程序产品。该方法包括标识代码中的多个测试点以及将要被指派多个测试点的多个测试值。多个测试点中的至少一个测试点将被指派以两个或更多测试值。该方法还包括将一个目标测试用例与测试用例集进行比较。目标测试用例和测试用例集均与多个测试点相关联。该方法进一步包括响应于确定目标测试用例中被指派给多个测试点中至少两个测试点的测试值的每种组合均存在于测试用例集中，将目标测试用例排除在测试用例集之外。

Description

测试代码的方法、设备和计算机程序产品

相关申请的交叉引用

本申请要求于2015年6月26日提交的中国专利申请号201510364946.0的优先权。

技术领域

本公开的实施例涉及软件测试领域，并且更具体地，涉及用于测试代码的测试代码的方法、设备和计算机程序产品。

背景技术

软件测试指的是在预设条件下运行软件产品的代码，以评估运行结果是否符合预期。软件测试人员可以通过设计测试用例来模拟特定运行条件，并且然后利用测试用例对软件产品进行测试。测试用例可以与软件产品的代码中的多个测试点(例如，代码中包括的变量)相关联。在不同的测试用例中，多个测试点中的至少一个测试点可以被指派不同的测试值。

随着软件规模的不断增大和软件复杂性的日益增加，在软件产品测试时需要考虑的测试点数量持续增长，这进而导致软件产品测试用例的数量也成指数增加，加剧了软件测试的复杂度。传统方案无法在测试的覆盖率和测试效率之间取得令人满意的平衡。

发明内容

本公开的实施例提供一种测试软件产品的代码的方案。

根据本公开的第一方面，提供了一种测试代码的方法。该方法包括标识代码中的多个测试点以及将要被指派多个测试点的多个测试值。多个测试点中的至少一个测试点将被指派以两个或更多测试值。该方法还包括将一个目标测试用例与测试用例集进行比较。目标测试用例和测试用例集均与多个测试点相关联。该方法进一步包括响应于确定目标测试用例中被指派给多个测试点中至少两个测试点的测试值的每种组合均存在于测试用例集中，将目标测试用例排除在测试用例集之外。这方面实施例还包括相应的计算机程序产品。

根据本公开的第二方面，提供了一种用于测试代码的设备。该设备包括至少一个处理单元。该至少一个处理单元被配置为标识代码中的多个测试点以及将要被指派多个测试点的多个测试值。多个测试点中的至少一个测试点将被指派以两个或更多测试值。该至少一个处理单元还被配置为将一个目标测试用例与测试用例集进行比较。目标测试用例和测试用例集均与多个测试点相关联。该至少一个处理单元进一步被配置为响应于确定目标测试用例中被指派给多个测试点中至少两个测试点的测试值的每种组合均存在于测试用例集中，将目标测试用例排除在测试用例集之外。

提供发明内容部分是为了简化的形式来介绍对概念的选择，它们在下文的具体实施方式中将被进一步描述。发明内容部分无意标识本公开的关键特征或主要特征，也无意限制本公开的范围。

附图说明

通过结合附图对本公开示例性实施例进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施例中，相同的参考标号通常代表相同部件。

图1示出了根据本公开的一个实施例的测试代码的过程的流程图；

图2示出了根据本公开的一个实施例的用于测试代码的***的框图；

图3示出了根据本公开的一个实施例的用于测试代码的设备的结构框图；以及

图4示出了可以用来实施本公开内容的实施例的示例设备的示意性框图。

具体实施方式

下面将参考附图中示出的若干示例实施例来描述本公开的原理。虽然附图中显示了本公开的优选实施例，但应当理解，描述这些实施例仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。

在常规的软件测试过程中，可能涉及如下多个方面的工作：

(1)软件测试人员根据软件产品的使用情况和功能说明并且可以在软件开发团队的协助下，标识出软件产品的代码中的测试点以及与测试点对应的测试值。

(2)软件测试人员设计多个测试用例以针对所有测试点将所有测试值进行迭代。通常，软件测试人员每次将会针对特定的测试点设计一个或多个测试用例，以覆盖该测试点的测试值。在这些测试用例中，其他测试点可能会被指派固定的测试值。

(3)针对所有测试点设计好的测试用例集将提供至测试***，用于测试软件产品的代码。这个测试过程可以在测试***上自动进行。可以依据每个测试用例来执行一次代码，并且判断执行结果是否符合预期。

(4)在测试过程完成之后，确定代码覆盖率，以便判断该测试过程是否充分。代码覆盖率用于度量在本次测试过程中软件产品中的被执行的代码行的数量。

(5)在集成步骤之后，所有测试用例被固定下来并且软件测试进入维护模式。之后，除了某些基于确定的代码缺陷获得的测试用例之外，将不再添加新的测试用例。因此，当需要再次测试该产品时，只有这些已有的测试用例会被使用。

发明人通过研究发现，上述软件测试过程存在如下问题和不足：

(1)由于软件测试人员在设计测试用例时的局限性，多个测试用例在用于测试代码时可能会涉及相同的测试操作。例如，在针对特定测试点设计的多个测试用例之中，如果仅该测试点的测试值发生变化而其他测试点总是被指派相同的测试值，那么这些测试点的相同测试点的组合总是被重复执行。这将会导致时间和处理资源过多浪费在对相同操作的测试上，使得测试效率低下。此外，软件测试人员总是一次性设计出可能的所有测试用例并且将测试用例集成到测试***中。在每次期望测试该软件的代码时，相同的测试用例总是被重复测试。这也是无法达到有效测试的目的。

(2)代码覆盖率虽然是一种用于判断衡量测试覆盖率(测试性能)的常用指标，但是在软件性能测试、***测试等测试场景下，比代码覆盖率更需要被关注的是涉及软件产品的不同输入的交互覆盖率。这种输入的交互可以由不同测试用例中测试点的不同测试值的组合来表示。但是，代码覆盖率则无法衡量这些输入的交互的覆盖情况。由于没有衡量的指标，软件测试人员将难以在设计测试用例时将这些不同的输入交互考虑在内，并且后期也无法继续改进测试用例，从而可能难以检测出代码中的潜在问题。

(3)需要设计的软件测试用例的数目将随着测试点和对应的测试值的数目的增长而成指数型增长。例如，假设存在P个测试点并且其中第i个测试点的测试值数目是V_i，那么在常规的测试过程中，为了覆盖所有的测试值，可能需要设计个测试用例。这不但增加了测试人员的工作量，而且也是非常耗费时间和资源的过程。

(4)在常规的软件测试中，所有测试用例在集成之后将进入回归测试用例池中，并且此后几乎不存在新的测试用例的添加。这使得后续对该代码的测试运行(例如，在维护模式中需要再次测试时)的测试覆盖率几乎变为静态，难以得到进一步的改进。

(5)与完整测试运行(即，基于全部测试用例的测试)相比，可能期望更频繁地执行这些测试用例的子集(由于时间和处理资源的局限性)。对于频繁执行的子集的选择通常依赖于专家的推荐。然而，这种严重依赖于专家经验的测试用例选择无法确保每次测试运行的测试覆盖率能够最大化。而且，在除了被推荐的测试用例之外的其他测试用例往往需要等到完整测试运行(其很少被执行)时才会被执行。这使得频繁执行的测试运行的测试覆盖率即使从长期的角度来衡量也没有得到提升。

鉴于以上问题中的一个或一些问题以及鉴于其他潜在问题，本公开的实施例提供了一种软件测试的方案。在该方案中，在确定用于测试代码的测试用例集时，考虑不同测试点的各种测试值的组合，以使得能够用较少的测试用例实现较高的与输入交互有关的测试覆盖率。

图1是根据本公开的实施例的测试代码的过程100的流程图。过程100可以由测试***来实施。理解的是，过程100还可以包括附加的步骤和/或省略的步骤。此外，步骤之间的顺序不限于图1中所示出的顺序，任何其他可行的顺序(包括并行执行)均在本公开的范围之内。

在步骤110，标识软件产品的代码中的多个测试点以及将要被指派多个测试点的多个测试值。本文中所使用的术语“测试点”指的是在代码中定义的可以被赋值的变量或语句。测试值指的是可能被指派相应的测试点的值。在一些实施例中，测试点和对应的测试值的确定可以由用户(例如，软件测试人员)基于测试场景、使用情况、代码的功能说明和/或软件开发人员的协助来确定并且向测试***输入。备选地或附加地，也可以由测试***自动分析代码，以给出将要用于测试的测试点与测试值的推荐。用户可以通过选择并且确认这些推荐来向***标识测试点和测试值。

所标识的多个测试点中的至少一个测试点将被指派两个或更多测试值。也就是说，测试值的数目大于测试用例的数目。由此，可能需要基于这些测试点和测试值生成多个测试用例。在一些实施例中，可以存储多个测试点、多个测试值以及它们之间的对应关系，以便后续使用。例如，可以将多个测试点和对应的测试值以表格的形式存储。当然，还可以以其他方式进行存储，只需要能够标识出测试点和测试值之间的对应关系即可。假设从代码中标识出四个测试点A、B、C和D并且每个测试点均具有三个不同的测试值(仅为了方便，实际上每个测试点的测试值的数目可以不同)，那么这些测试点与测试值的对应关系可以由表1示出。

表1：测试点-测试值对应表

接下来，在步骤120，将目标测试用例与测试用例集进行比较。在本公开的实施例中，为了获得用于测试代码的测试用例集，可以判断某个测试用例(目标测试用例)是否能够存在于测试用例集中。目标测试用例与测试用例集的比较将在以下详细描述。

在本公开的实施例中，目标测试用例与测试用例集中的测试用例均与多个测试点相关联。在不同的测试用例中，多个测试点中的至少一个测试点可以被指派不同的测试值。假设从代码中标识出P个测试点并且第i个测试点的测试值具有V_i个值，那么一个测试用例可以被表示为：

TC＝{(TP_i,TV_j):1<＝i<＝P,1<＝j<＝V_i} (1)

其中TC表示一个测试用例，TP_i表示该测试用例中测试点且i将从1到P进行取值，TV_j表示在该测试用例中该测试点TP_i对应的测试值且该测试值可以从该测试点的V_i个测试值中任选的第j个值。例如，基于以上表1的示例中的测试点和测试值，一个测试用例可以被表示为TC＝{A1、B2、C1、D1}，其中测试点A被指派它的第一个测试值A1，测试点B被指派它的第二个测试值B2并且以此类推。

在一些实施例中，测试用例集中可以已经包括多个测试用例。这些测试用例可以是由软件测试人员以常规的方式手动设计的测试用例。在这些情况中，目标测试用例可以是从该测试用例集中取出的测试用例。

在另外一些实施例中，还可以自动地基于所标识的测试点和测试值来生成测试用例。具体地，可以通过随机地从多个测试值为多个测试点指派测试值来生成目标测试用例。在一些实施例中，在生成测试用例时还需要考虑一些测试值的组合约束。例如，可能存在一些约束指示某些测试点的某些测试值必需同时存在于一个测试用例中或者不能够同时存在于一个测试用例中等等。在生成新的测试用例的实施例中，测试用例集中可以首先不包括任何测试用例，并且然后通过自动生成一个目标测试用例并且判断所生成的目标测试用例是否能够存在于该测试用例集中来不断的扩大该测试用例集。

在某些实施例中，在步骤120对目标测试用例与测试用例集的比较，可以是目标测试用中测试点的测试值的组合与测试用例集中存在的测试值的组合的比较。在一些实施例中，可以存在测试值的多种类型的组合。不同数目的测试点的测试值的组合可以被称为不同类型的组合。例如，对于测试用例TC＝{A1、B2、C1、D1}而言，可以考虑每两个测试点的测试值的各个组合(例如，(A1、B2)、(A1、C1)、(A1、D1)、(B2、C1)和(C1、D1))，每三个测试点的各个组合((A1、B2、C1)、(A1、C1、D1)、(A1、B2、D1)和(A1、C1、D1))或者更多测试点的组合。测试点的测试值的不同组合可以反映出该软件产品在实际使用中可能对应的不同用户交互场景。

如本文中所使用的，t个测试点对应的测试值的组合可以被称为t阶组合，其中t可以大于1并且小于总的测试点数目。对于给定的多个测试点和多个测试值，它们的t阶组合的数目是固定的。通常期望用于测试代码的测试用例能够尽可能的覆盖所有这些t阶组合或者至少覆盖2阶组合。

例如，假设代码中标识出P个测试点并且第i个测试点的测试值具有V_i个值，这些测试点与测试值的t阶组合的总数目可以通过如下公式来计算：

$C_t(1,...,P)=\underset{j=1}{\overset{P-t+1}{\&Sigma;}}\left(V_j{C}_{i-1}\right(j+1,...,P\left)\right)---\left(2\right)$

其中C_t(1,...,P)表示t阶组合的总数目，V_j表示第j个测试点的测试值的数目，并且其中：

C₀(j,...,P)＝C₀＝1(1≤j≤P+1) (3)

例如，对于上文给出的表1中所示的4个测试点和每个测试点3个测试值，基于以上公式(2)和(3)，可以确定它们的2阶组合的总数目为：

$C_2(1,...,4)=\underset{j=1}{\overset{4-2+1}{\&Sigma;}}\left(V_j{C}_{2-1}\right(j+1,...,4\left)\right)=54---\left(4\right)$

在本公开的实施例中，期望测试用例集中的测试点的测试值的组合能够涵盖较多的各阶组合。因此，在步骤130中，响应于确定目标测试用例中被指派多个测试点中至少两个测试点的测试值的每种组合均存在于测试用例集中，将目标测试用例排除在测试用例集之外。也就是说，通过确定目标测试用例是否能够使得测试用例集存在的组合的数目增加来判断目标测试用例是否存在于该测试用例集中。如果目标测试用例的组合均存在于测试用例集中，则说明该目标测试用例无法为测试用例集增加新的组合，那么可以将该测试用例排除出该测试用例集。

假设对于以上表1中所示的4个测试点和每个测试点3个测试值，测试用例集中已经存在如下表2所示的七个测试用例。

表2：测试用例集

这个测试用例集中包括的2阶组合如以下表3所示：

表3：表2的测试用例集的2阶组合

假如需要判断表2中的目标测试用例7应当保存在测试用例集中还是应当被排除在测试用例集中，则可以确定测试用例7的2阶组合中的每个组合是否均存在于其余6个测试用例组成的测试用例集所包括的组合中。根据表3可以看出，测试用例7的每个2阶组合((A1、B1)、(A1,C2)、(A1,D2)、(B1,C2)、(B1,D2)、(C2,D2))在之前6个测试用例的集合所包括的组合中均已经出现。因此，可以确定将测试用例7排除出该测试用例集。

以上给出了基于2阶组合来确定是否排除目标测试用例的示例。在一些实施例中，还可以附加地或者备选地以基于更高阶的组合来确定是否排除目标测试用例。例如，可以确定测试用例7的所有3阶组合是否均存在测试用例集中的3阶组合中。在一些实施例中，可以由用户来设置基于哪些类型的组合来对目标测试用例和测试用例集进行比较。也就是说，可以由用户设置一个或多个阶数t。在一些实施例中，阶数t可以是默认的，例如被设置为2。

通常，如果目标测试用例的至少一个低阶组合(例如2阶组合)不存在于测试用例集中，那么可以直接确定它的至少一个高阶组合(例如3阶组合)也不会存在于测试用例集中。但是，如果它的所有低阶组合均存在于测试用例集中，则如果需要的话可以继续确定它的每个高阶组合(例如3阶或者更高阶组合)是否均存在于测试用例集中。在一些实施例中，如果低阶组合均存在于测试用例集的情况中、但是至少一个高阶组合不存在于该集合中，则可以不将该目标测试用例排除出测试用例集。例如，对于以上表2中的测试用例7，虽然它的所有2阶组合均存在于其余6个测试用例的集合中(如表3所示)，但是至少它的三阶组合(A1、B1、C2)并未存在于其他测试用例集中，则可以将测试用例7保留在该测试用例集中。

在一些实施例中，如上文所述，用于比较的测试用例集可以包括用户已经设计的多个测试用例或者可以是空集。在已经存在的多个测试用例的集合的情况中，可以逐个取出目标测试用例，并且将其与剩余的测试用例集进行比较以确定是否应当将该目标测试用例移除。如果目标测试用例的t阶(例如2阶和/或更高阶)组合均存在于测试用例集中，则将该目标测试用例从该测试用例集中移除。

对于测试用例集是空集并且可以自动生成测试用例的情况，第一个测试用例可以与t阶组合的空集进行比较并且因而可以被直接添加至测试用例集中。随后生成的目标测试用例的测试点的测试值的t阶组合可能已经存在于测试用例集中，那么就新生成的目标测试用例将不会被添加到测试用例集中。

在一些实施例中，如果确定目标测试用例的测试点的测试值的t阶组合可能已经存在于测试用例集，可以将该测试用例指示给用户(例如软件测试人员)以供确认。然后，响应于用户的确认，将该目标测试用例排除出测试用例集。

在一些实施例中，如果确定目标测试用例中被指派给多个测试点中至少两个测试点的测试值的至少一个组合不同于测试用例集中至少两个测试点的测试值的每个组合，则可以将目标测试用例添加到测试用例集中。例如，如果目标测试用例为TC＝{A1、B3、C2、D2}，可以确定测试点A和B在该测试用例中的测试值的组合是(A1、B3)并且根据表3中测试用例1至6的2阶组合集可以看出，测试点A和B的测试值组合(A1、B3)不同于测试用例集中这个测试点的任何测试值组合。因此，目标测试用例为TC＝{A1、B3、C2、D2}可以被添加到表2的测试用例集中，例如作为该集合中的测试用例7。

在一些实施例中，在确定出目标测试用例能够向测试用例集增加新的组合的情况下，还可以基于对目标测试用例的用户选择来将目标测试用例添加到测试用例集中。例如，可以将目标测试用例推荐给用户以供选择，并且响应于用户的选择来将其添加至测试用例集中。

备选地或附加地，还可以基于测试用例集中包括的测试值的不同组合的数目或者包括的已有测试用例的数目来确定是否将目标测试用例添加到测试用例集中。在一些实施例中，可以设置目标的组合数目(例如2阶组合的目标或者更高阶组合的目标)或者可以设置目标的测试用例的数目。当测试用例集中的不同组合的数目或者测试用例的数目尚未达到目标时，才将目标测试用例添加到该集合中。通常，可以基于预定的测试目标、测试***的运行能力、每轮测试运行的处理资源、或者预定的运行时间来约束目标测试用例的数目或者测试值的目标组合数目。

通过利用过程100，可以使得所获得的测试用例集能够覆盖更多的可能的组合。在一些实施例中，可以使用测试用例集来测试代码，并且可以将测试用例集中包括的测试值的不同组合的数目作为衡量本轮测试的性能的度量。具体地，可以比较测试用例集中包括的测试值的不同组合的数目与多个测试点的多个测试值的不同组合的总数目以获得测试覆盖率。在一些实施例中，可以基于预定阶的组合来衡量该测试覆盖率。例如，可以基于每两个测试点的测试值的2阶组合来衡量该测试覆盖率。在另外一些实施例中，还可以基于多个不同阶数的组合来确定多个的测试覆盖率。如本文中所使用的，基于测试值的组合确定的代码的测试覆盖率可以被称为测试覆盖率或者组合覆盖率。在一些实施例中，可以保存测试用例集的2阶或者更高阶的组合、例如上文描述的表3列出的组合，以便于方便后续计算测试覆盖率。

举例而言，在以上表2的示例中，根据过程100，可以从该表2的测试用例集中排除测试用例7并且保留其余6个测试用例。然后，可以使用这6个测试用例来测试代码。根据表3列出的这6个测试用例的2阶组合的情况可以看出，这6个测试用例包括36个不同的2阶组合。基于公式(4)确定出表1的示例中的4个测试点以及它们的相应测试值应当存在总共54个不同的2阶组合。因此，在使用所保留的6个测试用例来测试代码的情况中，本次测试的2阶测试覆盖率可以是36/54＝2/3。当然还可以相应地计算3阶或者更高阶测试覆盖率。

由此可见，对于已经存在的测试用例集(例如由软件测试人员设计的测试用例集)而言，使用过程100可以从该集合中排除具有冗余的t阶组合的测试用例，从而使得能够使用较少的测试用例获得同样的组合测试覆盖率。

备选地，在可以自动生成测试用例的情况中，可以尽可能地生成能够给出较大的测试覆盖率(例如，约70％、90％或者100％的2阶测试覆盖率)的测试用例集。例如，在以上表2的示例中，如果已经生成测试用例1至6，并且确定测试用例7不能被添加到该集合中，则可以继续生成新的测试用例，以覆盖更多的2阶组合。在一个示例中，可以继续生成如下的三个测试用例并且将三个测试用例添加到测试用例集中，从而达到100％的2阶测试覆盖率。

表4：新增的测试用例

在表4的示例中，所生成的测试用例7至9中的每个测试用例可以与测试用例集中包括的组合进行比较，以便确定其是否能够向该集合中增加新的组合(例如2阶组合)。如果确定一个测试用例至少能够向该测试用例集中添加至少一个新的组合，则可以将其添加到测试用例集中。

应当理解的是，表2(除去其中的测试用例7)结合表4组成的测试用例集能够覆盖四个测试点(A、B、C和D)以及它们相应的三个测试值的全部54个2阶组合。但是，实际在生成测试用例的过程中，可能难以准确地确定出如表4所示的三个测试用例以正好弥补测试用例集中的组合缺失，特别是当所标识的测试点和测试值的数目较大时。因此，为了达到目标的组合数目或者测试覆盖率，实际上可能需要生成更多的测试用例。

如以上所提及的，由于处理资源等的限制，每一轮的代码测试所能运行的测试用例的数目可能是有限的。因此，可能需要通过设置目标的组合数目或者测试覆盖率、或者通过设置测试用例数目来约束测试用例集。也就是说，每个测试用例集包括的测试用例的数目可能是有限的。在一些情况中，即使获得的测试用例集中的2阶组合的覆盖率较高、例如最高达到100％，但是该测试用例集中的更高阶组合(例如3阶组合或者4阶组合)的覆盖率可能也并未达到期望的水平。

另一方面，对于给定的测试点和测试值，可以存在的较大数目的不同测试用例。例如，存在P个测试点并且每个测试点的测试值数目均是V(仅为了方便，实际上每个测试点的测试值的数目可以不同)，那么可能存在最多V^P个不同测试用例(在不考虑测试值之间的相互约束的情况下)。每个测试用例集无法涵盖所有这些测试用例。

为了能够进一步提高各阶组合的覆盖率并且还为了能够测试可能的更多的不同测试用例，在一些实施例中，在过程100中，如果确定目标测试用例中被指派多个测试点中至少两个测试点的测试值的每种组合均存在于测试用例集中，则可以将目标测试用例与另外的测试用例集进行比较。如果确定目标测试用例中被指派给多个测试点中至少两个测试点的测试值的至少一个组合不同于另外的测试用例集中至少两个测试点的测试值的每个组合，可以将目标测试用例添加到另外的测试用例集中。也就是说，可以所生成的目标测试用例如果无法被添加到当前的测试用例集中，则可以在一个或者多个其他测试用例集中被继续使用。

如上文所述，目标测试用例通过随机地为测试点指派测试值来生成。通过这样的方式，如果一个测试用例集无法满足更高的测试覆盖率或者无法包括更多的不同测试用例，但是还可以基于其他测试用例集来继续测试代码。在一些实施例中，当存在多个测试用例集时，可以随机从多个测试用例集中选择一个、一些或者全部测试用例集来测试代码。从长期的角度来看，多个测试用例集的使用使得各阶的测试覆盖率得到提升并且覆盖了更多不同的测试用例。

在一些实施例中，如果需要频繁且快速地测试代码的应用场景，也可以随机地从多个测试用例集中选择一个或多个而不是全部测试用例集来测试代码。由于在测试用例集的生成过程中已经使得测试用例集中的测试用例能够获得较大的组合测试覆盖率，因此即使每次仅运行全部测试用例集中的一部分测试用例集，也能够获得较高的测试覆盖率。这相对于依赖人工选择部分测试用例的方式而言，更能够确保每次测试运行的有效性。

上文参考某些示例实施例讨论了基于测试用例集来对代码的测试。在本公开的一些实施例，为了进一步促进代码的测试，还可以借助测试点的接口函数来测试代码。具体地，当确定所标识的测试点之后，可以基于测试点生成与多个测试点对应的多个接口函数。当所选用的测试用例集确定之后，可以其包括的相应测试用例中多个测试点的测试值作为多个接口函数的输入。然后在代码运行时，通过调用这些接口函数来运行代码，以获得代码运行的结果。在传统的代码测试过程中，软件测试人员需要针对每个测试用例编写或以自动的方式生成对应的可执行脚本以用于测试代码。因此，在测试用例数量过多的时候，测试过程将会消耗更多的时间。然而，通过设计接口函数，可以方便地处理不同的测试用例而不需要花费大量的时间用于测试用例的脚本化。

在一些实施例中，可能通过测试过程查找到代码的缺陷。具体地，对于每个测试用例而言，均可以对应一个预期结果。如果使用该测试用例运行代码之后的结果与预期结果不一致，则说明该测试用例对应于缺陷。在这种情况下，可以记录该缺陷对应的测试用例并且将该测试用例告知用户。用户可以基于报告的测试用例确定出应当修改代码。在一些情况下，代码的修改可能导致一个或多个新测试点以及可以被指派这些测试点的新的测试值，或者还可能导致已有的测试点的新测试值。在这些情况中，仍然可以依照过程100继续生成目标测试用例，并且确定目标测试用例是否能够进一步被包括在测试用例集中。

不同于传统测试过程中仅能够已知的单个新的测试用例增加到测试用例集中，通过过程100，目标测试用例的增加仍然考虑了不同测试点(已有的测试点与新的测试点)的不同测试值的组合，从而可以获得更多的测试用例来实现较好的测试覆盖率。因此，基于新的测试点或者测试值产生的新的组合可以被增加到测试用例集中，以便下一次继续基于新的测试用例集来测试代码。由此可见，过程100不仅有利于在软件测试初始时期获得较好的测试覆盖率和有效的测试，并且还能够有利于后续产品维护阶段持续实现覆盖率和测试效率的提升。

在一个示例中，通过代码测试，用户发现了一个产品缺陷并且确定除了原先的A、B、C三个测试点之外还应当增加新的测试点D，并且测试点D具有三个测试值D1、D2和D3。基于新的测试点，可以继续依据过程100生成对应的测试用例集，如以下表5所示。从表5可以，该测试用例集中能够将测试点D的多个测试值与先前的测试点的测试值之间的各种组合考虑在内。

表5：新增测试点之后的测试用例集

图2是根据本公开的实施例的用于测试代码的***200的结构框图。***200仅是用于实现一些实施例的代码测试过程的***的具体示例。应当理解的是，***200可以包括更多或更少的功能块。

如图2所示，***200包括测试标识器201，用于从待测试的代码中标识出测试点和测试值。在202中，可以存储所标识的测试点和测试值可以被制作成测试点与测试值对应表，并且还可以用于存储这些测试点的测试值的不同组合表。基于测试点与测试值对应表，测试用例生成器205可以生成测试用例，并且将生成的测试用例放入测试用例集206中。测试用例生成器205在生成测试用例时还参考测试要求207。测试要求207可以包括例如对于测试值的组合的约束。例如，测试要求207可以规定某些测试点的特定测试值应当或者不应当出现在同一个测试用例中。

测试用例移除器215可以确定是否应当从测试用例集中移除某个测试用例。对于测试用例的移除可以基于该测试用例是否能够像测试用例集增加新的t阶组合(t可以大于等于2并且小于所标识的测试点的数目)来确定。在一些实施例中，确定要被删除的测试用例可以存储在测试用例移除报告216中以便提供给用户。

所获得的测试用例集206可以被提供至测试运行器208中用于测试代码。在一些实施例中，所标识的测试点可以被提供至测试开发203中以便于开发与这些测试点对应的测试点接口函数204。测试运行器208可以调用这些接口函数，并且将相应的测试用例中执行的测试点的测试值用作这些接口函数的输入。通过这些接口函数，可以快速地执行代码的测试。代码运行的结果可以被存储到测试报告209中。在一些实施例中，测试报告209可以包括每个测试用例的运行结果以及该测试用例的预期结果。

为了分析在每次测试运行中是否发现代码的缺陷，测试报告209可以被提供至缺陷分析器210中。缺陷分析器210通过对测试报告209进行分析，可以将可能的缺陷存储在缺陷报告212并且在需要的时候将其提供给用户。在一些实施例中，如果缺陷分析器210分析出应当继续测试产品的代码中的新的测试点和对应的测试值或者已有的测试点的新的测试值211，则可以将这些信息合并至202中的测试点与测试值对应表，以便于测试用例生成器205使用这些信息继续生成新的测试用例。

在一些实施例中，测试覆盖率分析器213还可以依据所存储的测试值组合表202、测试用例生成器205生成的测试用例以及测试用例移除器215移除的测试用例来确定每次测试运行的测试覆盖率。测试覆盖率分析器213还可以生成测试覆盖率报告214用于提供给用户。

在以上的实施例中，***200被描述为根据自动生成的测试用例来执行测试过程。在进一步的实施例中，还可以将已经被设计的测试用例结合至***200中。***200然后可以基于已有的测试用例来执行代码测试过程。例如，已有的测试用例可以被添加至测试用例集206中。在这种情况下，***200的各个功能块可以继续执行以上所述的操作。

图3是根据本公开的实施例的用于测试代码的设备300的结构框图。如图所示，该设备300包括：测试标识器310，被配置为标识所述代码中的多个测试点以及将要被指派多个测试点的多个测试值。多个测试点中的至少一个测试点将被指派以两个或更多测试值。设备300还包括测试用例比较器320，被配置为将一个目标测试用例与测试用例集进行比较。目标测试用例和测试用例集均与多个测试点相关联。设备300进一步包括测试用例确定器330，被配置为响应于确定目标测试用例中被指派给多个测试点中至少两个测试点的测试值的每种组合均存在于测试用例集中，将目标测试用例排除在测试用例集之外。

在一些实施例中，设备300可以进一步包括测试用例生成器，被配置为通过随机地从多个测试值为多个测试点指派测试值来生成目标测试用例。

在一些实施例中，目标测试用例存在于测试用例集中。测试用例确定器330可以被配置为从测试用例集中移除目标测试用例。

在一些实施例中，测试用例确定器330可以进一步被配置为响应于确定目标测试用例中被指派给多个测试点中至少两个测试点的测试值的至少一个组合不同于测试用例集中至少两个测试点的测试值的每个组合，将目标测试用例添加到测试用例集中。

在一些实施例中，测试用例确定器330可以进一步被配置为基于以下各项中的至少一项来将目标测试用例添加到测试用例集中：对目标测试用例的用户选择，测试用例集中包括的测试值的不同组合的数目，以及测试用例集中包括的已有测试用例的数目。

在一些实施例中，设备300可以进一步包括：代码测试器，被配置为使用测试用例集来测试代码，以及覆盖率确定器，被配为比较测试用例集中包括的测试值的不同组合的数目与多个测试点的多个测试值的不同组合的总数目以获得测试覆盖率。

在一些实施例中，代码测试器可以进一步被配置为：生成与多个测试点对应的多个接口函数，将测试用例集中的相应测试用例中多个测试点的测试值作为多个接口函数的输入，以及调用多个接口函数来运行代码。

在一些实施例中，以上测试用例集是第一测试用例集，并且测试用例确定器330可以进一步被配置为：响应于确定目标测试用例中被指派多个测试点中至少两个测试点的测试值的每种组合均存在于第一测试用例集中，将目标测试用例与第二测试用例集进行比较；响应于确定目标测试用例中被指派给多个测试点中至少两个测试点的测试值的至少一个组合不同于第二测试用例集中至少两个测试点的测试值的每个组合，将目标测试用例添加到第二测试用例集中；以及随机地从第一测试用例集和第二测试用例集中选择至少一个测试用例集来测试代码。

图4示出了可以用来实施本公开内容的实施例的示例设备400的示意性框图。设备400可以用于实现图2的用于测试代码的***和/或图3的用于测试代码的设备300。如图所示，设备400包括中央处理单元(CPU)401，其可以根据存储在只读存储器(ROM)402中的计算机程序指令或者从存储单元408加载到随机访问存储器(RAM)403中的计算机程序指令，来执行各种适当的动作和处理。在RAM 403中，还可存储设备400操作所需的各种程序和数据。CPU401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。

设备400中的多个部件连接至I/O接口405，包括：输入单元406，例如键盘、鼠标等；输出单元407，例如各种类型的显示器、扬声器等；存储单元408，例如磁盘、光盘等；以及通信单元409，例如网卡、调制解调器、无线通信收发机等。通信单元409允许设备400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理单元401执行上文所描述的各个方法和处理，例如过程100，可由。例如，在一些实施例中，过程100可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元408。在一些实施例中，计算机程序的部分或者全部可以经由ROM 402和/或通信单元409而被载入和/或安装到设备400上。当计算机程序加载到RAM 403并由CPU 401执行时，可以执行上文描述的过程100的一个或多个步骤。

本领域的技术人员应当理解，上述本公开的方法的各个步骤可以通过通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本公开不限制于任何特定的硬件和软件结合。

应当理解，尽管在上文的详细描述中提及了设备的若干装置或子装置，但是这种划分仅仅是示例性而非强制性的。实际上，根据本公开的实施例，上文描述的两个或更多装置的特征和功能可以在一个装置中具体化。反之，上文描述的一个装置的特征和功能可以进一步划分为由多个装置来具体化。

以上所述仅为本公开的可选实施例，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原则之内，所作的任何修改、等效替换、改进等，均应包含在本公开的保护范围之内。

Claims (17)

1.一种测试代码的方法，包括：

标识所述代码中的多个测试点以及将要被指派所述多个测试点的多个测试值，所述多个测试点中的至少一个测试点将被指派以两个或更多测试值；

将一个目标测试用例与测试用例集进行比较，所述目标测试用例和所述测试用例集均与所述多个测试点相关联；以及

响应于确定所述目标测试用例中被指派给所述多个测试点中至少两个测试点的测试值的每种组合均存在于所述测试用例集中，将所述目标测试用例排除在所述测试用例集之外。

2.根据权利要求1所述的方法，进一步包括：

通过随机地从所述多个测试值为所述多个测试点指派测试值来生成所述目标测试用例。

3.根据权利要求1所述的方法，其中所述目标测试用例存在于所述测试用例集中，并且将所述目标测试用例排除在所述测试用例集之外包括从所述测试用例集中移除所述目标测试用例。

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

响应于确定所述目标测试用例中被指派给所述多个测试点中至少两个测试点的测试值的至少一个组合不同于所述测试用例集中所述至少两个测试点的测试值的每个组合，将所述目标测试用例添加到所述测试用例集中。

5.根据权利要求4所述的方法，其中将所述目标测试用例添加到所述测试用例集中包括：

基于以下各项中的至少一项，将所述目标测试用例添加到所述测试用例集中：

对所述目标测试用例的用户选择，

所述测试用例集中包括的测试值的不同组合的数目，以及

所述测试用例集中包括的已有测试用例的数目。

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

比较所述测试用例集中包括的测试值的不同组合的数目与所述多个测试点的所述多个测试值的不同组合的总数目，以确定所述测试用例集的测试覆盖率。

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

以所述测试用例集中的相应测试用例中所述多个测试点的测试值作为输入，调用与所述多个测试点对应的多个接口函数以测试所述代码，所述多个接口函数将所述相应测试用例中的所述测试值指派给对应的测试点。

8.根据权利要求1至7中任一项所述的方法，其中所述测试用例集是第一测试用例集，所述方法进一步包括：

响应于确定所述目标测试用例中被指派所述多个测试点中至少两个测试点的测试值的每种组合均存在于所述第一测试用例集中，将所述目标测试用例与第二测试用例集进行比较；

响应于确定所述目标测试用例中被指派给所述多个测试点中至少两个测试点的测试值的至少一个组合不同于所述第二测试用例集中所述至少两个测试点的测试值的每个组合，将所述目标测试用例添加到所述第二测试用例集中；以及

随机地从所述第一测试用例集和所述第二测试用例集中选择至少一个测试用例集来测试所述代码。

9.一种用于测试代码的设备，包括：

至少一个处理单元，被配置为：

标识所述代码中的多个测试点以及将要被指派所述多个测试点的多个测试值，所述多个测试点中的至少一个测试点将被指派以两个或更多测试值；

将一个目标测试用例与测试用例集进行比较，所述目标测试用例和所述测试用例集均与所述多个测试点相关联；以及

响应于确定所述目标测试用例中被指派给所述多个测试点中至少两个测试点的测试值的每种组合均存在于所述测试用例集中，将所述目标测试用例排除在所述测试用例集之外。

10.根据权利要求9所述的设备，其中所述至少一个处理单元进一步被配置为：

通过随机地从所述多个测试值为所述多个测试点指派测试值来生成所述目标测试用例。

11.根据权利要求9所述的设备，其中所述目标测试用例存在于所述测试用例集中，并且所述至少一个处理单元进一步被配置为从所述测试用例集中移除所述目标测试用例。

12.根据权利要求9所述的设备，其中所述至少一个处理单元进一步被配置为：

响应于确定所述目标测试用例中被指派给所述多个测试点中至少两个测试点的测试值的至少一个组合不同于所述测试用例集中所述至少两个测试点的测试值的每个组合，将所述目标测试用例添加到所述测试用例集中。

13.根据权利要求12所述的设备，其中所述至少一个处理单元进一步被配置为：

基于以下各项中的至少一项，将所述目标测试用例添加到所述测试用例集中：

对所述目标测试用例的用户选择，

所述测试用例集中包括的测试值的不同组合的数目，以及

所述测试用例集中包括的已有测试用例的数目。

14.根据权利要求9所述的设备，其中所述至少一个处理单元进一步被配置为：

比较所述测试用例集中包括的测试值的不同组合的数目与所述多个测试点的所述多个测试值的不同组合的总数目，以确定所述测试用例集的测试覆盖率。

15.根据权利要求9所述的设备，其中所述至少一个处理单元进一步被配置为：

以所述测试用例集中的相应测试用例中所述多个测试点的测试值作为输入，调用与所述多个测试点对应的多个接口函数以测试所述代码，所述多个接口函数将所述相应测试用例中的所述测试值指派给对应的测试点。

16.根据权利要求9至15中任一项所述的设备，其中所述测试用例集是第一测试用例集，所述至少一个处理单元进一步被配置为：

响应于确定所述目标测试用例中被指派所述多个测试点中至少两个测试点的测试值的每种组合均存在于所述第一测试用例集中，将所述目标测试用例与第二测试用例集进行比较；

响应于确定所述目标测试用例中被指派给所述多个测试点中至少两个测试点的测试值的至少一个组合不同于所述第二测试用例集中所述至少两个测试点的测试值的每个组合，将所述目标测试用例添加到所述第二测试用例集中；以及

随机地从所述第一测试用例集和所述第二测试用例集中选择至少一个测试用例集来测试所述代码。

17.一种用于测试代码的计算机程序产品，所述计算机程序产品被有形地存储在非瞬态计算机可读介质上并且包括机器可执行指令，所述机器可执行指令在被执行时使机器执行根据权利要求1至8任一项所述的方法的步骤。