一种测试用例生成方法、装置及相关设备

技术领域

本申请涉及云计算技术领域，尤其涉及一种测试用例生成方法、装置及相关设备。

背景技术

静态测试是一种重要的对程序代码进行测试的方法。在静态测试的过程中，可以对代码的静态特性(例如代码的语法、结构和过程等)进行分析，从而找出代码的故障。与动态测试相比，静态测试不需要运行代码，所以静态测试的效率更高，可以降低软件生命开发周期。另外，静态测试的结果还可以用于为动态测试提供参考。

静态分析工具是静态测试中所使用的工具，用于对代码的静态特性进行分析。静态分析工具的性能优劣，与静态测试的测试效果直接相关。因此，对静态分析工具的优化和测试就非常重要。对静态分析工具的一种测试手段是，利用静态分析工具对故障已知的测试用例进行测试，并比较测试结果和测试用例的故障是否匹配。如此，可以确定静态分析工具检测故障的能力，从而有针对地对静态分析工具进行更新优化。

但是，目前的测试用例大多存在缺陷，导致对静态分析工具的测试不够充分，无法准确地、全面地测试出静态分析工具内部的缺陷和问题。

发明内容

有鉴于此，本申请提供了一种测试用例生成方法，用于生成能够充分地对静态分析工具进行测试的测试用例。本申请还提供了对应的装置、计算设备集群、芯片、计算机可读存储介质以及计算机程序产品。

第一方面，本申请提供了一种测试用例生成方法，该方法生成的测试用例能够充分地对静态分析工具进行测试。该方法具体可以由测试用例生成装置执行。具体地，在执行本申请提供的生成测试用例生成方法时，测试用例生成装置首先可以从第一代码中确定第一目标位置。其中，第一代码是不包括第一故障类型的故障代码的代码。第一目标位置是第一代码中能够被注入第一故障类型的故障代码的位置。并且，在第一代码实际运行的过程中，位于第一目标位置的第一故障类型的故障代码可能导致第一故障类型的故障发生。也就是说，如果第一代码在第一目标位置存在第一故障类型的故障代码，那么在满足某种条件时，就会发生第一故障类型的故障。因此，注入第一目标位置的第一故障类型的故障代码，是可以被特定的输入值触发的。那么第一目标位置注入第一故障类型的故障代码理论上可以被静态分析工具检测到。在确定了第一目标位置之后，测试用例生成装置可以在第一代码的第一目标位置注入第一故障类型的故障代码，以得到第一测试用例。这样，利用第一测试用例对第一静态分析工具进行测试，就可以准确地衡量出第一静态分析工具检测第一故障类型的故障代码的能力。实际上，由于第一故障类型的故障代码被注入第一代码的第一目标位置，理论上静态分析工具可以检测出第一测试用例中第一故障类型的故障代码。那么如果第一静态分析工具没有从第一测试用例的第一目标位置检测出第一故障类型的故障代码，说明第一静态分析工具出现了“漏报”的问题，第一静态分析工具检测第一故障类型的故障代码的能力有限。如果第一静态分析工具从第一测试用例中未插入第一故障类型的故障代码的位置检测出了第一故障类型的故障代码，说明第一静态分析工具出现了“误报”的问题，第一静态分析工具不能准确地检测出第一故障类型的故障代码。这样，生成的第一测试用例能够准确地、充分地衡量第一静态分析工具检测第一故障类型的故障代码的能力。并且，自动生成用于对静态分析工具进行测试的测试用例，可以避免使用现有的测试用例集合进行测试，从而满足了测试用例的复杂性的要求。并且，如果调整注入第一代码的故障代码，可以得到不同的测试用例，使得测试用例足够全面，且不会出现落后的问题。

在一些可能的实施方式中，测试用例生成装置可以先确定多个候选位置，再从多个候选位置中确定第一目标位置。其中，候选位置是第一代码中能够被注入第一故障类型的故障代码的位置。可以理解的是，虽然候选位置可以被注入第一故障类型的故障代码，但是候选位置的第一故障类型的故障代码可能在实际运行的过程中不会被触发。在确定了多个候选位置之后，测试用例生成装置可以根据每个候选位置的前置条件，从多个候选位置中确定第一目标位置。候选位置的前置条件根据第一代码中位于候选位置之前的代码确定，用于衡量该候选位置的故障代码能够在实际运行过程中被触发。

在一些可能的实施方式中，测试用例生成装置可以根据代码的分支情况确定第一目标位置。具体地，对于多个候选位置中的第一候选位置，测试用例生成装置可以吸纳根据第一代码确定第一候选位置的第一前置条件。第一前置条件用于描述第一代码中位于第一候选位置之前的代码的分支情况。根据第一前置条件，测试用例生成装置可以判断第一候选位置之前代码的分支情况与第一故障类型是否匹配。若二者不匹配，说明第一故障类型的处理逻辑与第一候选位置处代码的处理逻辑存在冲突。这样，如果将第一故障类型的故障代码注入第一候选位置，第一故障类型的故障代码就不会在实际的运行过程中被触发。相反地，若二者匹配，说明第一故障类型的处理逻辑与第一候选位置处代码的处理逻辑之间没有冲突。那么注入第一候选位置的第一故障类型的故障代码就可以在实际的运行过程中被触发。因此，测试用例生成装置可以将第一候选位置确定为第一目标位置。

在一些可能的实施方式中，测试用例生成装置还可以判断候选位置是否为死代码。其中，死代码是指代码中在实际运行过程中不会被执行的部分。显然，如果第一故障类型的故障代码被注入死代码中，第一故障类型的故障代码不会再实际的运行过程中被执行，静态分析工具也无法检测出第一故障类型的故障代码。因此，在将第一候选位置确定为第一目标位置之前。测试用例生成装置还可以先根据第一候选位置的前置条件，判断第一候选位置是否为死代码中的位置，从而确定第一候选位置是第一代码在实际运行过程中能够被运行的代码。

在一些可能的实施方式中，第一代码是不包括第一故障类型的故障代码的代码。相应地，第一代码可以是技术人员通过网络或其他方式获取到的代码。或者，第一代码也可以是测试用例生成装置生成的代码。

在一些可能的实施方式中，第一代码可以是根据实际需求生成的。具体地。在生成第一代码之前，测试用例生成装置可以先获取第一代码的代码生成信息。第一代码的代码生成信息用于指示第一代码的分支情况。接着，测试用例生成装置可以根据第一代码的分支情况，自动生成对应的第一代码。这样，由技术人员手动设置第一代码的分支情况，也可以满则测试中复杂性和多样性的需求。

在一些可能的实施方式中，第一代码中变量的数量也可以根据实际需求进行设定。具体地，第一代码的代码生成信息中还可以包括第一代码中变量的数量。那么在生成第一代码时，测试用例生成装置可以先根据第一代码中变量的数量和第一代码的分支情况，生成第一代码的控制流图。在第一代码的控制流图中，第一代码中的变量为节点，节点之间的连接关系根据第一代码的分支情况确定。在生成了第一代码的控制流图之后，测试用例生成装置可以根据预设指令集填充控制流图，从而得到对应的第一代码。这样，由于控制流图是随机生成的，在固定变量数量和分支情况的基础上，可以随机生成大量的控制流图，从而得到大量测试用例，满足测试中多样性和复杂性的需求。

在一些可能的实现方式中，可以对生成的代码进行调整，以便代码中存在第一故障类型的代码。具体地，测试用例生成装置可以先根据控制流图和预设指令集生成原始的第一代码，然后对原始的第一代码进行扫描，排除原始的第一代码中第一故障类型的故障代码。

第二方面，本申请提供一种测试用例生成装置，所述装置包括：目标位置确定模块，用于确定第一代码中的第一目标位置，在所述第一代码运行过程中，位于所述第一目标位置的第一故障类型的故障代码存在导致第一故障类型的故障发生的可能性；故障注入模块，用于在所述第一代码的所述第一目标位置中注入所述第一故障类型的故障代码，得到第一测试用例，所述第一测试用例用于测试第一静态分析工具检测所述第一故障类型的故障代码的能力。

在一些可能的实施方式中，所述目标位置确定模块，具体用于对所述第一代码进行分析，确定多个候选位置，所述候选位置为所述第一代码中能够被注入第一故障类型的故障代码的位置；根据所述多个候选位置中每个候选位置的前置条件，从多个候选位置中确定第一目标位置，所述前置条件根据所述第一代码中位于所述候选位置之前的代码确定。

在一些可能的实施方式中，所述多个候选位置包括第一候选位置，所述目标位置确定模块，具体用于确定所述第一候选位置的第一前置条件，所述第一前置条件用于描述所述第一代码中位于所述第一候选位置之前的代码的分支情况；根据所述第一候选位置的前置条件，将所述第一候选位置确定为所述第一目标位置，所述第一代码中位于所述第一候选位置之前的代码的分支情况，与所述第一故障类型相匹配。

在一些可能的实施方式中，所述目标位置确定模块，具体用于根据所述第一候选位置的前置条件，确定所述第一候选位置为所述第一代码运行过程中能够被运行的代码。

在一些可能的实施方式中，所述第一代码为不包括所述第一故障类型的故障代码的代码，所述装置还包括代码获取模块，和/或，代码生成模块；所述代码获取模块，用于获取所述第一代码；所述代码生成模块，用于生成所述第一代码。

在一些可能的实施方式中，所述装置包括代码生成模块，所述装置还包括信息获取模块；所述信息获取模块，用于获取第一代码的代码生成信息，所述第一代码的代码生成信息用于指示所述第一代码的分支情况；所述代码生成模块，具体用于根据所述第一代码的代码生成信息，生成所述第一代码。

在一些可能的实施方式中，所述第一代码的代码生成信息还包括第一代码中变量的数量，所述代码生成模块，具体用于根据所述第一代码中变量的数量和所述第一代码的分支情况，生成控制流图；根据所述控制流图和预设指令集，生成所述第一代码。

在一些可能的实施方式中，所述代码生成模块，还用于对所述第一代码进行扫描，确定所述第一代码不包括所述第一故障类型的故障代码。

第三方面，本申请提供一种计算设备集群，所述计算设备包括至少一个计算设备，所述至少一个计算设备包括至少一个处理器和至少一个存储器；所述至少一个存储器用于存储指令，所述至少一个处理器执行所述至少一个存储器存储的该指令，以使所述计算设备集群执行上述第一方面或第一方面任一种可能实现方式中的测试用例生成方法。需要说明的是，该存储器可以集成于处理器中，也可以是独立于处理器之外。所述至少一个计算设备还可以包括总线。其中，处理器通过总线连接存储器。其中，存储器可以包括可读存储器以及随机存取存储器。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在至少一个计算设备上运行时，使得所述至少一个计算设备执行上述第一方面或第一方面的任一种实现方式所述的测试用例生成方法。

第五方面，本申请提供了一种包含指令的计算机程序产品，当其在至少一个计算设备上运行时，使得所述至少一个计算设备执行上述第一方面或第一方面的任一种实现方式所述的测试用例生成方法。

附图说明

图1为本申请实施例提供的模型更新装置的一种应用场景示意图；

图2为本申请实施例提供的模型更新方法的一种信令交互图；

图3为本申请实施例提供的确定目标参数的方法的一种信令交互图；

图4为本申请实施例提供的一种计算设备的结构示意图；

图5为本申请实施例提供的一种计算设备集群的结构示意图。

具体实施方式

下面将结合本申请中的附图，对本申请提供的实施例中的方案进行描述。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。

静态分析工具对故障的检测能力，是决定静态测试效果的重要原因。因此，为了更好地对代码进行故障排除，可以对静态分析工具进行测试，并根据测试结果对静态分析工具进行优化。接着，可以再对优化后的静态分析工具进行测试，从而不断优化静态分析工具。

在对静态分析工具的测试过程中，可以利用静态分析工具对故障已知的测试用例进行测试，从而得到测试用例的测试结果。接着，可以比较测试结果与测试用例已知的故障是否匹配，从而判断静态分析工具是否有检测出故障的能力。在实际的应用场景中，程序代码可能出现多种多样的故障。相应地，对静态分析工具的测试中可以使用多个测试用例，且不同测试用例可以对应不同的故障类型。其中，测试用例对应的故障类型，是指测试用例中被注入的故障的故障类型。测试用例用于检测静态分析工具对该测试用例对应的故障类型的故障的检测能力。

但是，目前的测试用例大多存在缺陷，导致对静态分析工具的测试不够充分，无法准确地、全面地测试出静态分析工具内部的缺陷和问题。

例如，在一些应用场景中，可以利用已有的测试用例集合对静态分析工具进行测试。而测试用例集合中的测试用例是有限的、固定的。这样，存在测试用例复杂性不足的问题，不能全方位地对静态分析工具进行测试。并且，随着技术的发展，代码的复杂度越来越高，导致代码中可能不断出现新的故障类型的故障，或者，原有故障类型可能以不同的方式在代码中实现。也就是说，测试用例集合可能会出现落后过期等问题，对静态分析工具的测试效果较差。

另外，如果反复利用固定的测试用例集合进行测试和优化，会让静态分析工具朝着该测试用例集合的方向特化发展。即，对静态分析工具的优化可能是针对测试用例集合的方向进行的，并没有考虑到程序代码的实际情况。这样，优化后得到的静态分析工具虽然能够很好地分析出测试用例集合中各个测试用例的故障，但是对实际代码中故障的检测能力可能相对较差。也就是说，利用测试用例集合对静态分析工具的测试可能存在测试片面的问题，导致测试效果不佳。

为此，在一些其他可能的实现方式中，可以利用已有的代码自动生成测试用例。例如，可以先获取原始代码，然后在原始代码中注入故障代码。其中，故障代码是会导致故障的代码，注入故障代码包括在原始代码中故障代码，也可以包括将原始代码中的代码修改为会导致故障的故障代码。会导致某个故障类型的故障出现的代码，可以被称为该故障类型的故障代码。例如，在下文的介绍中，会导致第一故障类型的故障出现的代码，可以被称为第一故障类型的故障代码。上述过程又可以被称为故障注入。

具体地，在向原始代码中注入K类型的故障时，首先可以对原始代码进行分析，确定原始代码中可能导致K类型的故障发生的代码所在的位置。接着，可以将能够导致K类型的故障代码插入第一代码中上述位置，和/或，可以将第一代码中上述位置的代码调整为将能够导致K类型的故障代码。这样，随着原始代码的不同和故障代码注入的位置的不同，得到的测试用例也不同。其中，原始代码可以是开源程序的代码，也可以是已有的程序代码。

上述实现方式虽然一定程度上解决了测试用例复杂性不足的问题，但是生成的测试用例存在缺陷，仍然存在测试不充分不准确的问题。具体地，该测试不充分不准确的问题至少可以体现在以下三个方面。

第一方面，被注入故障代码的原始代码是开源代码或已有的程序代码，本身就可能存在故障代码，那么测试用例中存在的故障代码多于被注入的故障代码。这样，利用静态分析工具对该测试用例进行测试，得到的结果可能与注入的故障不匹配。

例如，假设原始代码X中包括3处可能导致K类型的故障的故障代码。在生成测试用例时，在原始代码X中额外的3个位置加入了可能导致K类型的故障的故障代码。利用该测试用例对静态分析工具进行测试，静态分析工具测试出的K类型的故障代码的数量可能大于3处。这样，在不了解原始代码X中已经存在了K类型的故障代码的基础上，测试人员会认为静态分析工具存在误报的问题。或者，如果静态分析工具仅测试出了3处K类型的故障代码，说明静态分析工具不能够准确地检测出测试用例中全部K类型的故障代码。但是在不了解原始代码X中已经存在了K类型的故障的基础上代码，测试人员会认为静态测试工具不存在漏报的问题。无论是上述那种情况，都会导致测试结果与静态分析工具的实际情况不一致。

也就是说，由于原始代码可能存在的缺陷，根据利用原始代码生成测试用例测试静态分析工具，得到的结果可能与静态分析工具的实际情况不一致。

第二方面，由于原始代码是被获取到的代码，原始代码中可能出现不会被执行的代码。这部分代码可以被称为死代码。相应地，如果故障代码被注入到死代码中，由于死代码不会被执行，静态分析装置在对测试用例进行测试时，就无法发现死代码中的故障代码。这样，无法确定静态分析装置能否对故障进行检测。

第三方面，原始代码中存在原始的处理逻辑，而原始的处理逻辑可能与待注入的故障代码的处理逻辑相冲突。如果故障代码的处理逻辑与代码的原始处理逻辑相冲突，故障代码可能会被代码的原始处理逻辑遮盖，那么故障代码可能无法被静态分析工具检测出。也就是说，如果将故障代码注入原始代码中处理逻辑与故障的处理逻辑相冲突的位置，即使静态分析工具具有分析出该故障代码的能力，静态分析工具也可能无法检测出测试用例中的故障代码。

结合实际情况进行说明。假设原始代码X中声明了一个小于64的整型变量A，且原始代码包括分支P1和分支P2。其中分支P1对应的处理逻辑为“如果变量A的取值大于32，则执行步骤S1”。分支P2对应的处理逻辑为“如果变量A的取值小于或等于32，则执行步骤S2”。假设待注入的故障代码的处理逻辑为“变量值超过声明的最大值”，且故障被注入分支P2。那么故障对应的变量A的取值为大于64的整数。显然，A大于64与分支P2的前置条件(即“变量A的取值小于或等于32”)存在冲突。这样，被注入的故障代码的处理逻辑就会被原始代码的处理逻辑遮掩。那么在对故障分析装置进行测试时，故障分析装置就无法发现测试用例中存在“变量值超过声明的最大值”这一故障对应的故障代码。

综上所述，在传统的测试静态分析工具的方法中，使用的测试用例可能存在缺陷，导致对静态分析工具的测试效果不佳。

基于此，本申请实施例提供了一种测试用例生成方法，该方法可以由计算机设备或计算机设备集群执行，以生成用于对静态分析工具进行测试的测试用例。具体可以由运行于计算机设备或计算机设备集群的测试用例生成装置执行。

具体地，在执行本申请实施例提供的测试用例生成方法时，测试用例生成装置首先可以在第一代码中确定第一目标位置。其中，第一代码是被注入故障代码的、不包括第一故障类型的故障代码的代码。第一目标位置是第一故障类型的故障可以被注入的位置。即，第一目标位置可以插入第一故障类型的故障代码，和/或，第一目标位置的代码可以被为第一故障类型的故障代码。并且，在代码运行的过程中，位于第一目标位置的故障代码存在导致第一故障类型的故障发生的可能。也就是说，如果在第一目标位置注入第一故障类型的故障代码，那么在第一代码运行的过程中，可能发生第一故障类型的故障。在确定了第一目标位置之后，测试用例生成装置可以在第一代码的第一目标位置中注入第一故障类型的故障代码，得到第一测试用例。例如，测试用例生成装置可以在第一代码的第一目标位置中插入第一故障类型的故障代码，或者将第一代码中第一目标位置的代码修改为可能导致第一故障类型的故障的代码。由于第一故障类型的故障代码被注入到第一目标位置，而第一目标位置是在第一代码运行的过程中，可能导致第一故障类型的故障发生的位置。因此，在对第一测试用例测试的过程中，第一目标位置的故障代码理论上能够静态测试工具被检测到。所以，如果第一静态分析工具没有检测到第一目标位置的故障代码，说明第一静态分析工具存在漏报的问题。或者，如果第一静态分析工具在第一测试用例中没有插入故障代码的位置检测出了故障代码，说明第一静态分析工具存在误报的问题。这样，生成的第一测试用例能够准确地、充分地衡量第一静态分析工具检测第一故障类型的故障代码的能力。

并且，自动生成用于对静态分析工具进行测试的测试用例，可以避免使用现有的测试用例集合进行测试，从而满足了测试用例的复杂性的要求。并且，如果调整注入第一代码的故障代码，可以得到不同的测试用例，使得测试用例足够全面，且不会出现落后的问题。

作为一种示例，上述测试用例生成装置可以被部署于一台计算设备，例如可以被部署于计算机或服务器。可选地，如果测试用例生成装置被部署于多台计算设备，不同的计算设备可以用于执行不同的步骤。可选地，部署有测试用例生成装置的计算设备或计算设备集群，和用于对静态分析工具进行测试的计算设备或计算设备集群可以相同，也可以不同。

例如，在图1所示的应用场景中，测试用例生成装置100可以包括目标位置确定模块110和故障注入模块120。其中目标位置确定模块110与故障注入模块120连接。

实际应用时，目标位置确定模块110用于在第一代码中确定第一目标位置。故障注入模块120用于在第一代码的第一目标位置中注入第一故障类型的故障代码。

实际应用时，上述测试用例生成装置100可以通过软件实现，或者可以通过硬件实现。下面分别进行说明。

测试用例生成装置100作为软件功能单元的一种举例，可以包括运行在计算实例上的代码。其中，计算实例可以包括物理主机(计算设备)、虚拟机、容器中的至少一种。进一步地，上述计算实例可以是一台或者多台。例如，测试用例生成装置100可以包括运行在多个主机/虚拟机/容器上的代码。需要说明的是，用于运行该代码的多个主机/虚拟机/容器可以分布在相同的区域(region)中，也可以分布在不同的region中。进一步地，用于运行该代码的多个主机/虚拟机/容器可以分布在相同的可用区(availability zone，AZ)中，也可以分布在不同的AZ中，每个AZ包括一个数据中心或多个地理位置相近的数据中心。其中，通常一个region可以包括多个AZ。

同样，用于运行该代码的多个主机/虚拟机/容器可以分布在同一个虚拟私有云(virtual private cloud，VPC)中，也可以分布在多个VPC中。其中，通常一个VPC设置在一个region内，同一region内两个VPC之间，以及不同region的VPC之间跨区通信需在每个VPC内设置通信网关，经通信网关实现VPC之间的互连。

测试用例生成装置100作为硬件功能单元的一种举例，测试用例生成装置100可以包括至少一个计算设备，如服务器等。或者，测试用例生成装置100也可以是利用专用集成电路(application-specific integrated circuit，ASIC)实现、或可编程逻辑器件(programmable logic device，PLD)实现的设备等。其中，上述PLD可以是复杂程序逻辑器件(complex programmable logical device，CPLD)、现场可编程门阵列(field-programmable gate array，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合实现。

测试用例生成装置100包括的多个计算设备可以分布在相同的region中，也可以分布在不同的region中。测试用例生成装置100包括的多个计算设备可以分布在相同的AZ中，也可以分布在不同的AZ中。同样，测试用例生成装置100包括的多个计算设备可以分布在同一个VPC中，也可以分布在多个VPC中。其中，所述多个计算设备可以是服务器、ASIC、PLD、CPLD、FPGA和GAL等计算设备的任意组合。

接下来，对测试用例生成过程的各种非限定性的具体实施方式进行详细描述。

参阅图2，为本申请实施例中测试用例生成方法的一种流程示意图。该方法可以应用于上述图1所示的应用场景中，或者也可以是应用于其它可适用的应用场景中。下面以应用于图1所示的应用场景为例进行说明。

具体地，图2所示的测试用例生成方法具体可以包括：

S201：目标位置确定模块110确定第一代码中的第一目标位置。

为了测试第一静态分析工具检测第一故障类型的故障的能力，可以生成包括第一故障类型的故障代码的测试用例。为此，测试用例生成装置100可以在第一代码中插入第一故障类型的故障代码，以得到对应的测试用例。为了确保测试用例中的故障代码在理论上可以被静态分析工具检测到，测试用例生成装置100可以选择第一故障类型的故障代码插入第一代码中的位置。具体地，测试用例生成装置100中的目标位置确定模块110可以先在第一代码中确定第一目标位置。

下面分别对第一代码和第一目标位置进行介绍。

其中，第一代码是不包括第一故障类型的故障代码的代码。这样，第一代码不包括第一故障类型的故障，在对根据第一代码得到的测试用例进行测试时，第一静态分析工具得到的测试结果不会受到第一代码中原有的第一故障类型的故障代码的影响。也就是说，如果利用第一测试用例对第一静态分析工具进行测试，得到的测试结果中指示第一测试用例在没有注入第一故障类型的故障代码的位置存在第一故障类型的故障代码，则可以说明第一静态分析装置将第一测试用例中正常的代码误判为了第一故障类型的故障代码，存在误报的问题。

在一些可能的实现方式中，第一代码可以是测试用例生成装置100获取的、包括第一故障类型的故障代码的代码。或者，在一些其他可能的实现方式中，第一代码也可以是测试用例生成装置100生成的。关于生成第一代码的详细介绍可以参见后文图3对应实施例的说明，这里不再赘述。

第一目标位置是第一代码中能够被注入第一故障类型的故障代码的位置。并且，在第一目标位置注入了第一故障类型的故障代码之后的第一代码运行的过程中，存在发生第一故障类型的故障的可能。也就是说，如果利用第一测试用例对第一静态分析工具进行测试，得到的测试结果中指示第一测试用例在第一目标位置不存在第一故障类型的故障代码，则可以说明第一静态分析装置没有发现第一目标位置注入的故障代码，第一静态分析装置不能够完全准确地检测出第一测试用例中所有第一故障类型的故障代码，第一静态分析装置存在误报的问题。

上面对第一目标位置进行了介绍，下面介绍目标位置确定模块110确定第一目标位置的方法。

根据前文介绍可知，第一目标位置是第一代码在实际的运行过程中，可能发生第一故障类型的故障的位置。即，第一目标位置不但是可以被注入第一故障类型的故障代码的位置，而且第一目标位置还是第一代码实际运行过程中能够被执行的位置，以及，第一目标位置对应的处理逻辑与第一故障类型的处理逻辑不冲突。

为了确保第一目标位置满足上述条件，目标位置确定模块110可以对第一代码进行多次筛选。具体地，目标位置确定模块110可以先从第一代码中确定能够注入第一故障类型的故障代码的位置，然后再逐一判断每个位置如果被注入了第一故障类型的故障代码，该故障代码能够在第一代码运行的过程中被触发。

其中，能够第一代码中能够被注入第一故障类型的故障代码的位置可以被称为候选位置。也就是说，第一代码中位于候选位置附近的代码，满足发生第一故障类型的基本条件。如果在第一代码的候选位置注入第一故障类型的故障代码，那么被注入的故障代码在理论上存在被运行的可能。

根据前文介绍可知，即使在代码中合适的位置(即候选位置)注入了故障代码，使得故障代码存在理论上被运行的可能。但是由于代码本身的特性，该故障代码在实际的运行的过程中不会被触发，不会引起故障。这种不会引起故障的故障代码无法被静态分析工具检测，从而影响对静态分析工具的测试。

因此，在确定了候选位置之后，目标位置确定模块110可以从多个候选位置中确定一个或多个目标位置。位于目标位置的第一故障类型的故障代码，在实际的运行过程中存在被触发的可能性，可能会引起第一故障类型的故障。如果目标位置确定模块110确定了一个目标位置，那么该目标位置前述为第一目标位置。如果目标位置确定模块110确定了多个目标位置，那么多个目标位置中的一个目标位置为前述第一目标位置。

目标位置的数量可以根据第一代码的实际情况确定，也可以结合测试需求确定。例如，假设测试人员需要一个包括3处第一故障类型的故障代码的测试用例，那么目标位置确定模块110可以从多个候选位置中确定3个目标位置。

假设多个候选位置中包括第一候选位置。下面以第一候选位置为例，介绍目标位置确定模块110判断候选位置是否为目标位置的方法。

在本申请实施例中，目标位置确定模块110可以通过分析候选位置的前置条件，判断候选位置是否为目标位置。其中，前置条件根据第一代码中位于候选位置之前的代码确定。也就是说，如果第一候选位置的前置条件，指示位于第一位置的第一故障类型的故障代码，在实际的运行过程中存在被触发的可能性，那么目标位置确定模块110可以将第一候选位置确定为目标位置(例如确定为第一目标位置)。相反地，如果第一候选位置的前置条件，指示位于第一位置的第一故障类型的故障代码，在实际的运行过程中不存在被触发的可能性，那么目标位置确定模块110可以将第一候选位置确定为非目标位置。可选地，第一候选位置的前置条件，又可以被称为第一前置条件。

具体地，根据前文介绍可知，死代码和冲突的处理逻辑是导致故障代码在实际运行过程中不被触发的两个原因。相应地，目标位置确定模块110可以根据分别判断第一候选位置对应的处理逻辑是否与第一故障类型的处理逻辑冲突，以及判断第一候选位置是否为死代码。下面分别进行介绍。

在第一种可能的实现方式中，目标位置确定模块110判断第一候选位置的处理逻辑是否与第一故障类型的处理逻辑冲突。

其中，第一候选位置对应的处理逻辑，是指执行到第一候选位置的代码时，计算机设备的处理逻辑。第一候选位置的处理逻辑可以是第一代码中第一候选位置的前置部分的处理逻辑。第一候选位置的前置部分是第一代码中，在计算机设备执行第一候选位置的代码之前被执行的代码部分。也就是说，在执行第一候选位置对应的代码之前，第一候选位置的前置部分的代码已经被执行。那么第一候选位置对应的处理逻辑，可以被视为第一候选位置的前置部分的处理逻辑确定。

在本申请实施例中，目标位置确定模块110可以根据第一代码的控制流图确定第一候选位置的前置部分。具体地，目标位置确定模块110可以对第一代码进行分析，得到第一代码的控制流图。第一代码的控制流图用于指示第一代码中各个变量之间的逻辑关系和运算关系。其中，变量之间的运算关系，用于指示某个变量是通过何种方式计算得到的。变量之间的逻辑关系，用于指示第一代码运行过程中的变量之间的条件关系。

可选地，第一代码的控制流图可以是树形图。在该树形图中，每个节点为第一代码中的一个变量，节点之间的上下级关系用于指示变量之间的运算关系(子节点是根据父节点运算得到的)，节点之间的连接关系用于指示变量之间的逻辑关系和运算关系。节点之间的分支关系对应第一代码中变量之间的逻辑分支关系。其中，逻辑分支关系表示变量在满足某个条件下会根据某种方式进行处理，而在变量满足另一个条件下会根据另一种方式进行处理。

例如，如果树形图中节点A分别对应节点B和节点C两个子节点，说明节点A对应的变量可以通过处理方式1得到节点B对应的变量，且节点A对应的变量可以通过处理方式2的得到节点C对应的变量。在处理方式1和处理方式2不能同时执行的情况下，第一代码中还包括判断条件，用于判断通过处理方式1处理节点A对应的变量还是通过处理方式2处理节点A对应的变量。例如，第一代码可以判断节点A对应的变量是否满足条件D，如果节点A对应的变量不满足条件D，可以通过处理方式2处理节点A对应的变量。

在上述描述的实施例中，树形图在节点A处出现了分别对应节点B和节点C的两条分支。在第一代码的处理逻辑中，节点A对应的变量在被处理之前存在条件D的判断，且存在处理方式1和处理方式2的两条分支的选择。

在获取到第一代码的控制流图之后，目标位置确定模块110可以在第一代码的控制流图中确定第一候选位置，然后沿着第一候选位置，确定第一候选位置的前置部分。根据前文介绍可知，第一候选位置的前置部分是执行第一候选位置的代码之前被执行的部分，那么在第一代码的控制流图中，第一候选位置的前置部分为从起点到达第一候选代码所在的分支的路径。该路径在经过控制流图中分支时所满足的条件即为第一候选位置的前置部分的处理逻辑。

结合上文例子进行说明。假设第一候选位置对应节点C，那么第一候选位置的前置部分包括从节点A到节点C这一段路径。第一候选位置的处理逻辑包括“节点A对应的变量满足条件D”。

第一故障类型的处理逻辑，是指发生第一故障类型的故障时，代码需要的处理逻辑。也就是说，只有满足了第一故障类型的处理逻辑，才能够发生第一故障类型的故障。如果不满足第一故障类型的处理逻辑，第一故障类型的故障就不会发生。因此，如果第一故障类型的处理逻辑与第一候选位置的处理逻辑冲突，在运行过程中就不会按照第一故障类型的处理逻辑执行，第一故障类型的故障在理论上不会被触发。这样，由于第一故障类型的故障在理论上不会被触发，静态分析工具在分析测试用例时，就不会发现位于第一候选位置的第一故障类型的故障代码。因此，为了确保位于第一候选位置的第一故障类型的故障代码在理论上能够被静态分析工具检测出，目标位置确定模块110可以在第一候选位置的处理逻辑与第一故障类型的处理逻辑不冲突的情况下，再将第一候选位置确定为目标位置。如果第一候选位置的处理逻辑与第一故障类型的处理逻辑冲突，目标位置确定模块110确定第一候选位置为非目标位置。

在实际的应用场景中，目标位置确定模块110可以基于符号执行技术判断第一候选位置的处理逻辑与第一故障类型的处理逻辑是否冲突，从而确保注入的故障代码能够被真实的输入值所触发，保证第一候选位置的第一故障类型的故障代码在理论上能够被静态分析工具检测到。具体地，可以基于符号执行技术进行输入值的符号化，并追踪第一目标位置的执行路径，从而针对该执行路径上的条件分支约束进行约束求解，判断第一候选位置的处理逻辑与第一故障类型的处理逻辑是否冲突。

在第二种可能的实现方式中，目标位置确定模块110判断第一候选位置是否属于死代码。

死代码是指代码中不会被执行的代码。例如，死代码可以是没有开头的循环代码。或者，死代码可以是分支条件无法满足的分支。如果第一故障类型的故障代码被注入死代码中，由于死代码不会被执行，死代码中的故障代码不会被任意输入值触发，静态分析工具不会对死代码中的故障进行扫描，也就无法发现死代码中的故障代码。因此，目标位置确定模块110可以判断第一候选位置是否属于死代码。如果第一候选位置属于死代码，目标确定模块110可以将第一候选位置确定为非目标位置。如果第一候选位置不属于死代码，目标确定模块110可以将第一候选位置确定为目标位置。

在实际的应用场景中，目标位置确定模块110可以基于符号执行技术判断第一候选位置是否属于死代码，从而确保注入的故障代码能够被真实的输入值所触发，保证第一候选位置的第一故障类型的故障代码在理论上能够被静态分析工具检测到。

可以理解的是，上述两种实现方式可以单独实现，也可以组合实现。例如，在一些可能的实现方式中，第一代码为不包括死代码的代码，例如第一代码为自动生成的代码。那么为了提高测试用例的生成效率，目标位置确定模块110可以不对第一候选位置是否为死代码进行判断，仅判断第一候选位置的处理逻辑与第一故障类型的处理逻辑是否冲突。

在确定了第一目标位置之后，目标位置确定模块110可以向故障注入模块120发送第一目标位置的标识，以使故障注入模块120在第一代码的第一目标位置注入故障代码。可选地，如果目标位置确定模块110确定了多个目标位置，目标位置确定模块110可以向故障注入模块120分别发送每个目标位置的标识，以使故障注入模块120向多个目标位置分别注入故障代码。

S202：故障注入模块120在第一代码的第一目标位置中注入第一故障类型的故障代码。

在确定了第一代码中的第一目标位置之后，故障注入模块120可以向第一目标位置中注入第一故障类型的代码，从而得到第一测试用例。用于被注入了第一故障类型的故障代码，第一测试用例可以用于测试第一静态分析工具对第一故障类型的故障代码的检测能力。

具体地，故障注入模块120可以将第一代码中第一目标位置的代码，修改为能够导致第一故障类型的故障的代码。或者，故障注入模块120也可以生成或获取能够导致第一故障类型的故障的代码，并将该代码插入第一代码中的第一目标位置。

在本申请实施例中，第一故障类型的故障代码被注入第一代码的目标位置中。而位于目标位置的故障代码，在代码的实际运行过程中，存在导致第一故障类型的故障发生的可能性。也就是说，位于目标位置的第一故障类型的故障代码，能够被某个输入值触发。因此，得到的第一测试用例中的故障代码，在理论上可以被静态分析工具检测到。那么如果第一静态分析工具没有检测到第一测试用例中所有第一故障类型的故障代码，说明第一静态分析工具存在漏报的问题，第一静态分析工具检测第一故障类型的故障代码的能力不足。或者，如果第一静态分析工具在没有被注入第一故障类型的故障代码的位置检测到第一故障类型的故障代码，说明第一静态分析工具存在误报的问题，第一静态分析工具检测第一故障类型的故障代码的不够准确。如此，生成的测试用例可以准确地、全面地对静态测试工具进行测试。

在图2对应的实现方式中，可以在第一代码中注入第一故障类型的代码。其中，第一代码可以是通过网络获取的、不包括第一故障类型的故障代码的代码，也可以是由技术人员手动编写的不包括第一故障类型的故障代码的代码。具体地，第一代码可以是测试用例生成装置中的代码获取模块获取到的。而在一些可能的实现方式中，为了使得测试用例更加多样，第一代码可以是随机生成的代码。下面结合图3进行详细介绍。

参阅图3，为本申请实施例中生成第一代码的方法的一种流程示意图。该方法可以应用于上述图1所示的应用场景中，或者也可以是应用于其它可适用的应用场景中。在图3对应的应用场景中，测试用例生成装置100还包括信息获取模块130和代码生成模块130。可以理解的是，由于信息获取模块130和代码生成模块130。在图2对应的实现方式中为可选项，因此在图1中信息获取模块130和代码生成模块140通过虚线表示。下面以应用于图1所示的应用场景为例进行说明。

具体地，图3所示的生成第一代码的方法具体可以包括：

S301：信息获取模块130获取第一代码的代码生成信息。

为了生成第一代码，测试用例生成装置100可以先获取第一代码的相关信息。具体地，测试用例生成装置100中的信息获取模块130可以获取第一代码的代码生成信息。第一代码的代码生成信息是用于随机生成第一代码的相关信息。例如，信息获取模块130可以接收用户输入的第一代码的代码生成信息。或者，信息获取模块130可以从存储模块中读取预先存储的第一代码的代码生成信息。

具体地，第一代码的代码生成信息可以用于指示第一代码的分支情况。第一代码的分支情况是指第一代码的控制流图的分支情况。根据前文介绍可知，第一代码的分支情况用于指示第一代码中具体的判断步骤。可选地，第一代码的分支情况可以包括第一代码所包括的分支数量，即第一代码的控制流图中树形结构分支的数量。

在一些可能的实现方式中，第一代码的代码生成信息中还可以包括第一代码中变量的数量。这样，根据第一代码中变量的数量和第一代码的分支情况，代码横撑模块140可以生成第一代码的控制流图。

在获取到第一代码的代码生成信息之后，信息获取模块130可以向代码生成模块140发送第一代码的代码生成信息，以使代码生成模块140根据第一代码的代码生成信息生成第一代码。

S302：代码生成模块140根据第一代码的代码生成信息，生成第一代码。

在获取到第一代码的代码生成信息之后，代码生成模块140可以根据第一代码的代码生成信息生成第一代码。例如，在一些可能的实现方式中，第一代码的代码生成信息可以包括第一代码对应的伪代码，那么代码生成模块140可以将第一代码对应的伪代码转换为能够被计算机设备执行的第一代码。或者，在一些其他可能的实现方式中，第一代码的代码生成信息包括第一代码的控制流图。那么代码生成模块140可以根据第一代码的控制流图和指令集，生成对应的第一代码。其中，指令集包括多个指令对应的代码。代码生成模块140可以在第一代码的控制流图的基础上进行指令的填充，以得到对应的第一代码。

可以理解的是，无论是伪代码还是控制流图，其中都包括第一代码的分支情况。

又或者，在一些其他可能的实现方式中，第一代码的代码生成信息包括第一代码的分支情况和第一代码变量中变量的数量。那么在生成第一代码时，代码生成模块140可以向生成第一代码的控制流图，然后填充第一代码的控制流图，得到第一代码。下面进行详细介绍。

为了灵活地生成第一代码，代码生成模块140首先可以根据代码生成信息生成第一代码的控制流图。具体地，如果代码生成信息中包括第一代码中变量的数量和第一代码的分支情况，那么代码生成装置140可以先生成与第一代码中变量的数量一致的多个节点。接着，代码生成装置140可以随机生成节点之间的连接关系，并根据连接关系将多个节点连接为树形图。在生成的树形图中，节点之间的分支与第一代码的分支数量相匹配。在生成控制流时，代码生成装置140可以先通过随机算法构造从第一个节点到最后一个节点之间控制流的跳转关系，然后基于跳转关系构造程序控制流图，计算程序执行的拓扑排序。

在得到第一代码的控制流图之后，代码生成模块140可以根据第一代码的控制流图生成第一代码的原始代码。具体地，代码生成模块140可以根据预先设置的指令集(后称预设指令集)，确定第一代码的树形图中节点之间连线对应的指令，从而生成对应的程序代码。在本申请实施例中，根据熟悉第一代码的树形图和预设指令集生成的代码，可以被称为第一代码的原始代码，又称原始的第一代码。

可以理解的是，由于原始的第一代码是根据树形图和预指令集自动生成的，原始的第一代码中可能存在缺陷。因此，为了得到能够用于测试用例的生成的第一代码，代码生成模块140可以对原始的第一代码进行扫描，以确保得到的代码中不包括第一故障类型的故障代码，并且，得到的代码可以被静态分析工具所识别。

下面以第一故障类型为指针故障类型为例，对代码生成模块140根据原始的第一代码得到第一代码的过程进行说明。

由于第一故障类型为指针故障类型，那么根据第一代码所生成的测试用例(例如第一测试用例)是针对指针相关类型的故障。因此，可以吸纳基于抽象解释理论，将程序内部的状态改变抽象为指针指向关系的改变，从而将原始的第一代码的控制流图抽象为指针指向图。接着，可以利用程序状态传递算法，描述执行了原始的第一代码在执行每一条语句之后对指针指向关系的改变。接着，可以生成原始的第一代码的函数摘要。原始的第一代码的函数照耀用于描述调用函数时函数调用点与返回点的指针指向图的映射关系，并执行输入时输入参数的别名关系。这样，可以确保原始的第一代码不包括指针相关的故障代码。

在本申请实施例中，测试用例生成装置100既可以在已有的代码中注入故障代码。也可以自动生成代码并在其中注入故障代码。如此，可以生成大量的原始代码，从而得到大量的测试用例，满足对静态分析工具的测试中多样性的需求。

需要说明的是，本实施例中，对于测试用例生成装置100内的各个模块的划分以及功能描述仅作为一种示例。比如，在其他实施例中，目标位置确定模块110可以用于执行上述测试用例生成方法中的任意步骤，类似的，故障注入模块120、信息获取模块130和代码生成模块140均可以用于执行上述测试用例生成方法中的任意步骤，并且，目标位置确定模块110、故障注入模块120、信息获取模块130和代码生成模块140可负责实现的步骤，通过标位置确定模块110、故障注入模块120、信息获取模块130和代码生成模块140分别实现测试用例生成方法中不同的步骤来实现测试用例生成装置的全部功能。

上述图2和图3所示实施例中，针对测试用例生成过程中所涉及到的测试用例生成装置100(包括目标位置确定模块110、故障注入模块120、信息获取模块130和代码生成模块140可以是配置于计算设备或者计算设备集群上的软件，并且，通过在计算设备或者计算设备集群上运行该软件，可以使得计算设备或者计算设备集群实现上述装置所具有的功能。下面，基于硬件设备实现的角度，对测试用例生成的过程中所涉及的装置进行详细介绍。

图4示出了一种计算设备的结构示意图，上述测试用例生成装置110可以部署在该计算设备上，该计算设备可以是云环境中的计算设备(如服务器)，或边缘环境中的计算设备，或终端设备等具体可以用于实现上述图2所示实施例中目标位置确定模块110和故障注入模块120的功能，或者用于实现图3所示实施例中信息获取模块130和代码生成模块140的功能。

如图4所示，计算设备400包括处理器410、存储器420、通信接口430和总线440。处理器410、存储器420和通信接口430之间通过总线440通信。总线440可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extendedindustry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口430用于与外部通信，例如接收第一代码或者第一代码的代码相关信息等。

其中，处理器410可以为中央处理器(central processing unit，CPU)、专用集成电路(application specific integrated circuit,ASIC)、图形处理器(graphicsprocessing unit,GPU)或者一个或多个集成电路。处理器410还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述装置中各个模块的功能可以通过处理器410中的硬件的集成逻辑电路或者软件形式的指令完成。处理器410还可以是通用处理器、数据信号处理器(digital signal process,DSP)、现场可编程逻辑门阵列(field programmablegate array,FPGA)或者其他可编程逻辑器件，分立门或者晶体管逻辑器件，分立硬件组件，可以实现或者执行本申请实施例中公开的方法、步骤及逻辑框图。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，结合本申请实施例所公开的方法可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器、闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器420，处理器410读取存储器620中的信息，结合其硬件完成第一消息发送装置、代码显示装置或第二消息发送装置中的部分或全部功能。

存储器420可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。存储器420还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，HDD或SSD。

存储器420中存储有可执行代码，处理器410执行该可执行代码以执行前述测试用例生成装置110所执行的方法。

具体地，在实现图2所示实施例的情况下，且图2所示实施例中所描述的目标位置确定模块110和故障注入模块120为通过软件实现的情况下，执行图2中的目标位置确定模块110和故障注入模块120的功能所需的软件或程序代码存储在存储器420中，测试用例生成装置100与其它设备的交互通过通信接口430实现，处理器用于执行存储器420中的指令，实现测试用例生成装置100所执行的测试用例生成方法。

或者，在实现图3所示实施例的情况下，且图3所示实施例中所描述信息获取模块130和代码生成模块140为通过软件实现的情况下，执行图3中的信息获取模块130和代码生成模块140的功能所需的软件或程序代码存储在存储器420中，代码显示装置220与其它设备的交互通过通信接口430实现，处理器用于执行存储器420中的指令，实现测试用例生成装置100所执行的测试用例生成方法。

图5示出的一种计算设备集群的结构示意图。其中，图5所示的计算设备集群50包括多个计算设备，上述测试用例生成装置100可以分布式地部署在该计算设备集群50中的多个计算设备上。如图5所示，计算设备集群50包括多个计算设备500，每个计算设备500包括存储器520、处理器510、通信接口530以及总线540，其中，存储器520、处理器510、通信接口530通过总线540实现彼此之间的通信连接。

处理器510可以采用CPU、GPU、ASIC或者一个或多个集成电路。处理器510还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，第一消息发送装置210的部分功能可用通过处理器510中的硬件的集成逻辑电路或者软件形式的指令完成。处理器510还可以是DSP、FPGA、通用处理器、其他可编程逻辑器件，分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的部分方法、步骤及逻辑框图。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器、闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器520，在每个计算设备550中，处理器510读取存储器520中的信息，结合其硬件可以完成测试用例生成装置100的部分功能。

存储器520可以包括ROM、RAM、静态存储设备、动态存储设备、硬盘(例如SSD、HDD)等。存储器720可以存储程序代码，例如，用于实现目标位置确定模块110的部分或者全部程序代码、用于实现故障注入模块120的部分或者全部程序代码、用于实现信息获取模块130的部分或者全部程序代码、用于实现代码生成模块140的部分或者全部程序代码等。针对每个计算设备500，当存储器520中存储的程序代码被处理器510执行时，处理器510基于通信接口530执行测试用例生成装置100所执行的部分方法，如其中一部分计算设备400可以用于执行上述目标位置确定模块110和故障注入模块120所执行的方法，另一部分计算设备500用于执行上述信息获取模块130和代码生成模块140所执行的方法。存储器520还可以存储数据，例如：处理器510在执行过程中产生的中间数据或结果数据，例如，上述控制流图、第一代码和第一目标位置等。

每个计算设备500中的通信接口503用于与外部通信，例如与其它计算设备500进行交互等。

总线540可以是外设部件互连标准总线或扩展工业标准结构总线等。为便于表示，图5中每个计算设备500内的总线540仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

上述多个计算设备500之间通过通信网络建立通信通路，以实现测试用例生成装置100的功能。任一计算设备可以是云环境中的计算设备(例如，服务器)，或边缘环境中的计算设备，或终端设备。

此外，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在一个或者多个计算设备上运行时，使得该一个或者多个计算设备执行上述实施例测试用例生成装置的各个单元所执行的方法。

此外，本申请实施例还提供了一种计算机程序产品，所述计算机程序产品被一个或者多个计算设备执行时，所述一个或者多个计算设备执行上述实施例测试用例生成装置的各个单元所执行的方法。

该计算机程序产品可以为一个软件安装包，在需要使用前述实施例提供的任一方法的情况下，可以下载该计算机程序产品并在计算机上执行该计算机程序产品。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，单元之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、ROM、RAM、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，训练设备，或者网络设备等)执行本申请各个实施例所述的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。

所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、训练设备或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、训练设备或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的训练设备、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(Solid State Disk，SSD))等。