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

本申请要求于2022年02月18日提交中国国家知识产权局、申请号为202210148526.9、申请名称为“创建测试用例的方法、装置、服务器及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

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

背景技术

在软件开发过程中，通常会对开发的软件进行测试，以检测和诊断该软件中存在的缺陷或者故障，从而开发人员通过根据测试结果对该软件进行调整，可以有效提高软件运行的正确性以及软件质量。

目前主流的一种测试方式，是对软件进行“单元”级别的测试。其中，被测试的“单元”，为该软件的程序代码中的基础部件，如程序代码中的类(class)、方法(method，或者称之为函数)等。在进行单元测试(unit test)时，软件开发者(或者测试人员)可以针对被测单元，编写至少一组测试用例(test case)，每组测试用例通常包括测试输入、测试断言以及测试框架代码。其中，测试输入是指被测单元中的参数取值，测试断言是指在测试输入下测试单元的预期输出结果，测试框架(test framework)是指用于支持测试用例编写和执行的基础程序代码，如辅助测试用例的执行、将测试单元实际输出的结果与测试断言进行比对等。然后，开发人员基于测试用例运行被测单元，并根据被测单元的实际输出与测试断言之间的比较结果，确定被测单元是否正确运行。

但是，这种人工编写测试用例的方式，生成测试用例的效率较低，从而影响软件开发的整体进度。

发明内容

本申请提供了一种生成测试用例的方法，用于提高生成测试用例的效率，从而加快软件开发的整体进度。此外，本申请还提供了一种生成测试用例的装置、计算设备、计算机可读存储介质以及计算机程序产品。

第一方面，本申请提供了一种生成测试用例的方法，该方法可以由生成测试用例的装置执行，具体实现时，装置获取与待测试的软件单元匹配的多个候选测试用例模板，该多个候选测试用例模板例如可以预先配置于该装置中，并且，该装置向用户呈现该多个候选测试用例模板，并基于该用户从多个候选测试用例模板中选中的目标测试用例模板和该软件单元的测试数据，生成用于测试该软件单元的测试用例。

如此，装置可以在用户对多个候选测试用例模板进行选择后，可以自动生成测试用例，无需用户通过人工编码的方式开发测试用例，以此可以有效提高生成测试用例的效率，从而可以加快软件开发的整体进度。而且，测试用例中的测试数据以及测试用例模板可以实现解耦，这样，在生成测试用例的过程中，用户可以不用学习和开发测试用例中的测试框架代码，这样可以降低对于用户的技术水平要求，也即可以降低测试用例的开发门槛。

在一种可能的实施方式中，待测试的软件单元例如可以是类、方法中的一种或者多种。如此，装置可以生成用于对软件中的类进行测试的测试用例，或者，生成用于对类中的一个或者多个方法进行测试的测试用例。实际应用场景中，用户可以根据实际需求确定将软件中的类或者方法作为待测试的软件单元。

在一种可能的实施方式中，装置所获取的多个候选测试用例模板可以分别属于多个不同的测试框架。具体地，该多个候选测试用例模板中包括第一候选测试用例模板以及第二候选测试用例模板，并且，第一候选测试用例模板属于第一测试框架，第二候选测试用例模板属于第二测试框架。如此，装置可以利用多个候选测试用例模板生成能够适用于多种测试框架的测试用例。

在一种可能的实施方式中，装置还可以向用户呈现待测试的软件单元中的方法，以便由用户对该方法中的参数进行赋值，从而装置获取用户设置的该方法的参数值，该参数值即为软件单元的测试数据。如此，可以由用户对方法中的参数进行人工赋值，这使得最终生成的测试用例中的参数取值更容易符合用户的开发习惯，方便后续针对该测试用例的维护和演进。

在一种可能的实施方式中，装置可以自动生成待测试的软件单元中的方法的参数值，该参数值为该软件单元的测试数据。如此，可以由装置自动生成测试数据，从而可以进一步提高生成测试用例的效率，降低生成测试用例的难度。

可选地，装置还可以向用户呈现待测试的软件单元中的方法，并且由用户对该方法中的部分参数进行人工赋值，该方法中的其余参数由装置进行自动化赋值。如此，用户可以根据实际应用场景中对于软件单元的测试需求，对相应的部分参数进行人工赋值，以提高该部分参数的可读性，便于后续对于生成的测试用例的维护。

在一种可能的实施方式中，装置在获取与待测试的软件单元匹配的多个候选测试用例模板时，具体可以是获取该软件单元对应的测试框架的标识，从而可以确定出与该标识相匹配的多个候选测试用例模板。

示例性地，装置可以从软件单元或者该软件单元所属的软件中获取该测试框架的标识，或者可以由用户将该测试框架的标识输入至装置中，本实施例对此并不进行限定。

在一种可能的实施方式中，装置在生成测试用例之前，还可以获取自定义的多个候选测试用例模板中的一个或者多个候选测试用例模板。例如，可以预先由技术人员针对一种或者多种测试框架开发多个测试用例模板，从而可以将技术人员所开发的测试用例模板作为候选测试用例模板。

在一种可能的实施方式中，装置在生成测试用例之前，可以基于代码库训练得到多个候选测试用例模板中的一个或者多个候选测试用例模板，以此实现候选测试用例模板的自动化生成。

在一种可能的实施方式中，装置可以通过对代码库中的多个测试用例进行聚类，生成该多个候选测试用例模板中的一个或者多个候选测试用例模板。实际应用时，装置也可以采用其它方式基于代码库生成候选测试用例模板。

第二方面，本申请提供一种生成测试用例的装置，所述生成测试用例的装置包括用于实现第一方面或第一方面任一种可能实现方式中的生成测试用例的方法的各个模块。

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

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

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

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

图1为本申请实施例提供的一示例性应用场景示意图；

图2为本申请实施例提供的又一示例性应用场景示意图；

图3为本申请实施例提供的一种生成测试用例的方法流程示意图；

图4为本申请实施例提供的一示例性输入界面示意图；

图5为本申请实施例提供的一示例性推荐界面示意图；

图6为本申请实施例提供的一种生成测试用例的方法流程示意图；

图7为本申请实施例提供的一示例性单元选择界面示意图；

图8为本申请实施例提供的一示例性配置界面示意图；

图9为本申请实施例提供的一示例性赋值界面示意图；

图10为本申请实施例提供的一种生成测试用例的装置结构示意图；

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

具体实施方式

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

参见图1，为本申请实施例提供的一种示例性应用场景示意图。如图1所示，在该场景中，用户100(如软件开发者或者软件测试人员)可以将已开发的软件导入用于生成测试用例的装置200中。装置200在导入软件后，可以遍历该软件对应的程序代码文件，确定一个或者多个等待被测试的软件单元，该软件单元为程序代码中的基础部件，如可以是按照较粗粒度进行划分的类，或者可以是按照较细粒度划分的方法(函数)等。为便于理解，此处以装置200为一个待测试的软件单元生成测试用例为例。装置200可以获取与待测试的软件单元匹配的多个候选测试用例模板，并向用户100呈现该多个候选测试用例模板，其中，每个候选测试用例模板中可以包括测试框架代码，该测试框架代码可以用于辅助测试用例的执行、将测试单元实际输出的结果与测试断言进行比对等。用户100可以对呈现的多个候选测试用例模板进行选择，以下将用户100选中的候选测试用例模板称之为目标测试用例模板。这样，装置200根据用户100选中的目标测试用例模板以及该软件单元的测试数据，生成用于测试该软件单元的测试用例。进一步地，装置200还可以将生成的测试用例输出给用户100。

实际应用时，装置200可以部署于本地。比如，当装置200通过软件实现时，该装置200可以作为插件安装在本地的终端设备，并且该插件运行后可以为用户100提供生成测试用例的服务。或者，装置200也可以是由硬件实现，如利用专用集成电路(application-specific integrated circuit，ASIC)实现，或可编程逻辑器件(programmable logicdevice，PLD)实现，上述PLD可以是复杂程序逻辑器件(complex programmable logicaldevice，CPLD)，现场可编程门阵列(field-programmable gate array，FPGA)，通用阵列逻辑(generic array logic，GAL)或其任意组合实现上述网元或模块的功能。

或者，装置200也可以是作为云服务部署于云端。相应的，部署于云端的装置200可以通过本地的终端设备300向用户100呈现相应的交互界面，用于与用户100进行交互，如图2所示。这样，在用户100请求生成测试用例后，云端的装置200可以为用户100提供生成测试用例的云服务。本实施例中，对于装置200的具体部署方式并不进行限定。

为便于理解，下面结合附图，对本申请的实施例进行描述。

参见图3，图3为本申请实施例提供的一种生成测试用例的方法流程示意图，图3所示的方法流程可以由上述生成测试用例的装置200实现。为便于理解和说明，下面以图3所示的生成测试用例的方法应用于图1所示的应用场景为例进行示例性说明，该方法具体可以包括：

S301：装置200获取与待测试的软件单元相匹配的多个候选测试用例模板。

其中，待测试的软件单元，可以是已开发的软件中的一个或者多个单元，如软件中的类、或方法等。例如，在一些实现场景中，用户100开发出软件后，可以通过对该软件中的一个或者多个单元(以下称之为软件单元)进行测试，以校验该软件中是否存在运行错误或者缺陷。此时，用户100可以借助装置200，生成该软件中的各个待测试的软件单元分别对应的测试用例。其中，用户100可以是前述的软件开发者，或者可以是用于负责软件测试的测试人员，本实施例对此并不进行限定。

作为一种获取软件单元的实现示例，装置200可以向用户呈现如图4所示的输入界面，并在该输入界面中提示用户100将已开发的软件导入装置200中。用户100可以点击该输入界面中的“导入”按钮，将已开发软件的程序代码文件导入装置200，从而装置200通过遍历该程序代码文件可以确定所要测试的一个或者多个软件单元。或者，用户100可以直接在该输入界面中导入待测试的软件单元对应的程序代码，以使得装置200获取待测试的软件单元，本实施例对此并不进行限定。

本实施例中，装置200可以预先配置有多个测试用例模板，并且，该多个测试用例模板可以适用于多种不同的测试框架，即利用该多个测试用例模板可以生成多种测试框架下的测试用例。示例性地，测试框架，例如可以是GoogleTest，JUnit或者TestNG等，本实施例对此并不进行限定。这样，装置200在获取到待测试的软件单元后，可以获取装置200中与该软件单元相匹配的多个测试用例模板。为便于区分，以下将与该标识相匹配的测试用例模板称之为候选测试用例模板。其中，该多个候选测试用例模板均可以用于生成同一测试框架下的测试用例。或者，该多个候选测试用例模板可以属于不同的测试框架。比如装置200所确定出的多个候选测试用例中可以包括第一候选测试用例模板以及第二候选测试用例模板，并且，第一候选测试用例模板属于第一测试框架，用于生成第一测试框架下的测试用例，第二候选测试用例模板属于第二测试框架，用于生成第二测试框架下的测试用例。

在一种可能的实施方式中，装置200可以获取该软件单元对应的一个或者多个测试框架的标识，从而装置200可以从预先配置的多个测试用例模板中确定与该标识相匹配的多个候选测试用例模板。

例如，用户100向装置200导入的软件中可以携带有测试框架的标识(如携带于该软件的头文件中)，从而装置200可以从该软件中解析出测试框架的标识，以便根据该标识确定多个候选测试用例模板。

又例如，用户100可以在该图4所示的输入界面上输入一个或者多个测试框架的标识，如测试框架的名称等，从而装置200可以根据用户100输入的测试框架的标识，确定与该标识相匹配的多个候选测试用例模板。

值得注意的是，上述各实现方式仅作为一些示例性说明。在其它实施例中，装置200也可以是通过其它方式获取测试框架标识，进一步地，装置200也可以是通过其它实现方式确定与待测试的软件单元相匹配的多个候选测试用例模板，本申请对此均不进行限定。

示例性地，装置200中的候选测试用例模板，可以预先由技术人员将其配置于装置200中。具体地，在装置200提供生成测试用例的服务之前，针对多种类型的测试框架，如GoogleTest，JUnit或者TestNG等，技术人员可以预先针对每种类型的测试框架，分别开发出该测试框架类型下的至少一个测试用例模板，然后将其配置于装置200中。这样，装置200可以将技术人员开发的测试用例模板，作为与该软件单元相匹配的多个候选测试用例模板中的一个或者多个候选测试用例模板。

而在另一种实现示例中，在装置200提供生成测试用例的服务之前，装置200(或者其它装置)可以从代码库中提取出上述多个候选测试用例模板。具体实现时，装置200可以获取代码库，如Github等，该代码库包括历史开发过程中，针对多个软件单元进行测试时分别采用的测试用例，从而装置200可以基于该代码库训练得到多个候选测试用例模板中的一个或者多个候选测试用例模板。比如，装置200可以通过对代码库中的多个测试用例进行聚类，生成候选测试用例模板。具体地，装置200可以采用预设的聚类算法，对代码库中的多个测试用例进行聚类，得到多个聚类集合，其中，每个聚类集合包括至少一个测试用例，并且，该聚类集合包括的测试用例中的测试框架代码对应于一种类型的测试框架，不同聚类集合对应于不同类型的测试框架。这样，装置200可以从多个聚类集合中提取出多个测试用例模板。比如，针对聚类集合包括的每个测试用例，装置200可以对该测试用例中的参数进行抽象化，以此实现根据测试用例提取得到测试用例模板；然后，装置200将得到多个测试用例模板进行去重，即可从聚类集合中提取出一个或者多个候选测试用例模板。

应当理解，上述两种实现方式仅作为示例性说明，实际应用时，也可以是通过其它方式为装置200配置多个候选测试用例模板。比如，在又一种实现示例，装置200在从代码库中提取出多个测试用例模板后，可以由技术人员进行人工校验并调整，从而将通过技术人员校验或者技术人员调整后的多个测试用例模板作为候选测试用例模板等。

S302：装置200向用户100呈现多个候选测试用例模板。

本实施例中，装置200所确定的多个候选测试用例模板中的每个候选测试用例模板，均可以用于生成测试用例。基于此，本实施例中，装置200将确定的多个候选测试用例模板呈现给用户100，由用户100选择利用哪个候选测试用例模板来生成测试用例。

具体实现时，装置200可以向用户100呈现推荐界面，该推荐界面中可以包括多个候选测试用例模板的标识，如名称等，并且，在该推荐界面中以列表的方式进行排布，如图5所示的候选测试用例模板1至候选测试用例模板N。相应地，用户100可以在该推荐界面中对候选测试用例模板进行选择，例如用户100可以在图5所示的推荐界面中点击候选测试用例模板对应的复选框，以选中该候选测试用例模板。

进一步地，该推荐界面中还可以为各个候选测试用例模板配置查看按钮，从而当用户100点击该查看按钮后，装置200可以在该推荐界面(如图5所示)或者跳转界面中呈现该候选测试用例模板的相关信息，如候选测试用例模板的简介、测试框架代码等，以便用户100通过查看候选测试用例模板的相关信息决定对哪个候选测试用例模板进行选择。

S303：装置200基于用户100从多个候选测试用例模板中选中的目标测试用例模板和待测试的软件单元的测试数据，生成用于测试该软件单元的测试用例。

具体实现时，装置200获取软件单元的测试数据，该测试数据可以由用户100进行设定，或者由装置200进行自动设定，本实施例对此并不进行限定。并且，在确定用户100所选中的候选测试用例模板后，装置200将该测试数据添加至该候选测试用例模板中，从而生成包括测试数据以及测试框架代码的测试用例。进一步地，装置200还可以将生成的测试用例输出给用户100，并对该测试用例进行保存，如保存在用户100预先指示的保存路径中。

如此，装置200可以在用户100对多个候选测试用例模板进行选择后，可以自动生成测试用例，无需用户100通过人工编码的方式开发测试用例，以此可以有效提高生成测试用例的效率，从而可以加快软件开发的整体进度。

而且，测试用例中的测试数据以及测试用例模板可以实现解耦，这样，在生成测试用例的过程中，用户100可以不用学习和开发测试用例中的测试框架代码，这样可以降低对于用户100的技术水平要求，也即可以降低测试用例的开发门槛。

在训练得到测试用例后，装置200(或者其它装置)可以利用生成的测试用例对待测试的软件单元进行测试，以校验该待测试的软件单元在运行过程中的正确性。因此，本实施例还可以进一步包括：

S304：装置200执行该测试用例，对待测试的软件单元进行测试。

具体实现时，装置200在执行测试用例的过程中，可以根据该测试用例中的测试数据，对待测试的软件单元中的多个参数进行赋值，并在完成参数赋值后运行该软件单元，得到该软件单元的执行结果。然后，装置200可以将该执行结果与测试用例中的测试断言(也即用户100预期软件单元输出的正确结果)进行比对，并且，当两个结果一致时，装置200可以确定该软件单元运行正确，并向用户100反馈用于指示软件单元运行正确的测试结果；而当两个结果不一致时，装置200可以确定该软件单元存在错误，并向用户100反馈用于指示软件单元运行错误的测试结果，以便用户100根据该测试结果对该软件单元进行相应的调整，如调整该软件单元中的代码逻辑等。

需要说明的是，本实施例中，是以装置200针对一个待测试的软件单元生成相应的测试用例并进行单元测试的过程进行示例性说明。实际应用时，针对已开发软件中的不同软件单元，装置200均可以采用上述实施例的过程，自动生成相应的不同的测试用例，对于生成其余各软件单元对应的测试用例的具体实现过程，可参见上述实施例的相关之处描述，在此不做重述。

上述图3所示的实施例中，主要介绍了装置200根据用户选择的候选测试用例模板生成测试用例的过程。在其它可能的实施例中，用户100不仅可以对候选测试用例模板进行选择，还可以对生成测试用例所需的部分或者全部测试数据进行人工赋值。下面，结合图6，对本申请实施例提供的另一种生成测试用例的方法的流程进行示例性介绍。如图6所示，该方法具体可以包括：

S601：装置200接收用户100输入的已开发软件的程序代码文件。

本实施例中，用户100可以在图4所示的输入界面上，将已开发的软件的程序代码文件导入装置200中，或者，装置200也可以是通过其它方式获取该已开发软件的程序代码文件。

S602：装置200根据程序代码文件，确定待测试的软件单元。

其中，待测试的软件单元，可以是已开发软件中的类，或者可以是软件中的类所包括的方法。

作为一种实现示例，当待测试的软件单元为已开发软件中的类时，装置200可以遍历该程序代码文件，确定该程序代码文件中包括的多个类，也即确定该程序代码文件中的多个软件单元，并且，用户100可以通过对部分或者全部单元进行测试来校验软件运行的正确性。为便于区分，本实施例中将装置200遍历得到的各个软件单元称之为候选软件单元。这样，装置200可以将所确定的多个候选软件单元呈现给用户100，并根据用户100针对该多个候选软件单元的选择操作，确定用户100所选中的候选软件单元。本实施例中将用户100所选中的候选软件单元确定为待测试的软件单元。

而在另一种实现示例中，当待测的软件单元为类中的方法时，装置200可以向用户100呈现如图7所示的软件单元选择界面。在图7所示的单元选择界面中，用户100可以输入程序代码文件中的类的名称，如图7中的类“TEST”，以指示装置200对属于该类的一个或者多个方法进行单元测试。然后，装置200可以根据程序代码文件以及用户输入的类的名称，确定属于该类的多个方法，从而在用户100点击右侧的下拉菜单按钮时，装置200可以向用户100呈现属于该类的多个方法的名称，如图7中的“test0(x:int，y:int,map:HashMap):int”、“test1(a:int，b:int):int”、“test2():int”等。这样，用户100可以从呈现的多个方法的名称中选择一个或者多个方法，并将用户100所选择的方法确定为待测试的软件单元。实际应用时，用户100选择该类下的所有方法，可以等效于用户100请求装置200将整个类作为待测试的软件单元。进一步地，用户还可以在该单元选择界面上输入其它信息，如用户100还可以输入图7中所示的测试用例保存路径等，以便后续装置200将生成的测试用例保存至用户100所指定的路径中。

当然，上述介绍的获取待测试的软件单元的具体实现过程仅作为一种实现示例，本实施例对此并不进行限定。比如，在其它实施例中，用户100也可以是直接向装置200导入一个单元所对应的程序文件代码，从而装置200可以直接将该单元确定为待测试的软件单元等。

S603：装置200确定待测试的软件单元中的参数。

其中，软件单元中的参数，是指该软件单元中需要被赋值的对象，例如方法(或者称之为函数)中的输入参数、成员变量、测试断言等。通常情况下，所生成的测试用例，包括该多个参数的取值，以便通过测试软件单元基于该多个参数的取值所产生的运行结果与预期的运行结果是否一致，来进一步判断该软件单元的正确性。

具体实现时，装置200可以通过遍历该单元对应的程序代码，确定该单元中的输入参数、成员变量、测试断言等多个参数。比如，假设软件单元对应的程序代码中的输入为test0(x:int，y:int,map:HashMap):int，则装置200可以确定该输入中的“x”、“y”以及“map”均为需要被赋值的参数。

S604：装置200向用户100呈现所确定出的多个参数。

S605：装置200响应于用户100针对该多个参数的赋值操作，确定该多个参数的取值。

本实施例中，可以由用户100对部分或者全部参数进行人工赋值，并且，各个参数被赋予的取值保存在后续所要生成的测试用例中。

在一种可能的实施方式中，装置200可以向用户100呈现配置界面，该配置界面中可以包括装置200所确定出的多个参数。这样，用户100可以在该配置界面中对多个参数分别进行赋值。这样，装置200可以根据用户100针对各个参数的赋值操作，确定每个参数在测试用例中的取值。比如，假设用户100针对参数“x”输入数值3，则装置200可以确定在所要生成的测试用例中定义该参数x的取值为3。

而在另一种可能的实现方式中，在装置200向用户100呈现包括多个参数的配置界面后，用户100可以对该多个参数中的部分参数进行赋值，而由装置200对其余参数进行自动赋值。比如，被测试的单元中可以包括逻辑分支A以及逻辑分支B，而用户100当前主要期望对该单元的逻辑分支A进行功能测试，则，用户100可以主要对该逻辑分支A所关联的参数进行人工赋值，而对于其余参数(也即逻辑分支B所关联的参数)可以交由装置200进行自动化赋值等。

具体实现时，用户100可以对多个参数中的第一参数执行第一赋值操作，从而装置200响应该第一赋值操作，将第一赋值操作所指示的值作为该第一参数的参数值；并且，用户可以对该多个参数中的第二参数执行第二赋值操作，从而装置200响应该第二赋值操作，生成随机值，如基于随机测试方法的Randoop工具生成随机值、或者基于动态符号执行技术的JBSE工具生成随机值、或者基于搜索技术的EvoSuite[5]工具生成随机值等，并将该随机值作为该第二参数的参数值。如此，用户100可以根据实际测试场景的需求，仅对部分参数的取值进行人工设置，而无需对所有参数均进行人工赋值。

举例来说，装置200可以向用户呈现如图8所示的配置界面，并且，该配置界面包括多个参数(方法的输入参数对应的参数)：“j:int”、“i:int”、“arrayList:ArrayList”、“ints:int[]”、“strings:String[]”、“strings:String[]”、“list:List”。用户100可以选择对呈现的哪些参数进行人工赋值，哪些参数由装置200进行自动赋值，具体可以是用户100针对各个参数，可以点击该参数对应的下拉菜单按钮，选择“模拟”(mock)选项表征对该参数进行人工赋值，选择“禁用”(disabled)选项表征由装置200对该参数进行自动赋值。然后，装置200可以在用户100配置完成后，呈现如图9所示的赋值界面，并由用户100在该赋值界面上对选择的各个参数进行人工赋值。类似地，用户100还可以在该赋值界面上对于成员变量、测试断言中用户选择的参数进行人工赋值。而对于未赋值的剩余参数，装置200可以在用户100完成人工赋值后，自动对各个参数进行赋值。

本实施例中，在确定单元中的多个参数分别对应的取值后，装置200利用相应的候选测试用例模板，基于各个参数的取值生成测试用例，以便利用该测试用例对单元进行测试，校验该软件单元运行的准确性。为此，本实施例中装置200可以继续执行如下步骤：

S606：装置200确定与待测试的软件单元匹配的多个候选测试用例模板。

S607：装置200响应用户100针对多个候选测试用例模板的选择操作，将用户100所选择的候选测试用例模板作为生成软件单元对应的测试用例所使用的目标测试用例模板。

本实施例中，装置200确定多个候选测试用例模板以及用户100所选中的目标测试用例模板的过程，可以参见图3所示实施例中的相关之处描述，在此不做重述。

S608：装置200根据多个参数的取值以及待测试单元对应的测试用例模板，生成测试用例。

具体实现时，装置200可以将所确定出的多个参数、各个参数的取值添加至测试用例模板中，通过自动化的代码组装即可生成用户100所需的测试用例。进一步地，装置200还可以将生成的测试用例输出给用户100，并将该测试用例保存在用户100所指示的保存路径中。

如此，装置200可以在用户100对待测试的单元中的参数进行赋值后，可以自动生成测试用例，无需用户100通过人工编码的方式开发测试用例，以此可以有效提高生成测试用例的效率，从而可以加快软件开发的整体进度。

而且，测试用例中的参数取值，是由用户100进行设置的，如此可以使得测试用例中的参数取值更容易符合用户100的开发习惯，方便后续针对该测试用例的维护和演进。

另外，测试用例中的测试数据(也即多个参数的取值)以及测试用例模板可以实现解耦，这样，在生成测试用例的过程中，用户100可以不用学习和开发测试用例中的测试框架代码，这样可以降低对于用户100的技术水平要求，也即可以降低测试用例的开发门槛。

值得注意的是，图6所示的步骤执行顺序仅作为一种实现示例，本实施例中对于各个步骤之间的执行顺序并不进行限定。比如，在其它实施例中，确定目标测试用例模板与确定参数值的过程可以同时执行，即步骤S606至S607可以与步骤S603至S605同时执行；或者装置200也可以先确定目标测试用例模板，再确定参数值，即先执行步骤S606至S607，再执行步骤S603至S605等。

在训练得到测试用例后，装置200(或者其它装置)可以利用生成的测试用例对待测试的软件单元进行测试，基于此，本实施例还可以进一步包括：

S609：装置200执行该测试用例，对待测试的软件单元进行测试。

具体实现时，装置200在执行测试用例的过程中，可以根据该测试用例中的测试数据(包括步骤S605中确定的多个参数的参数值)，对待测试的软件单元中的多个参数进行赋值，并在完成参数赋值后运行该软件单元，得到该软件单元的执行结果。然后，装置200可以将该执行结果与测试用例中的测试断言(也即用户100预期软件单元输出的正确结果)进行比对，并且，当两个结果一致时，装置200可以确定该软件单元运行正确，并向用户100反馈用于指示软件单元运行正确的测试结果；而当两个结果不一致时，装置200可以确定该软件单元存在错误，并向用户100反馈用于指示软件单元运行错误的测试结果，以便用户100根据该测试结果对该软件单元进行相应的调整，如调整该软件单元中的代码逻辑等。

需要说明的是，本实施例中，是以装置200针对一个待测试的软件单元生成相应的测试用例并进行单元测试的过程进行示例性说明。实际应用时，装置200针对单个待测试的单元，可以生成多个不同的测试用例，以测试该单元中的不同逻辑分支。其中，在生成不同测试用例的过程中，用户100可以针对不同参数进行人工赋值。或者，装置200也可以是针对各个待测试的软件单元分别生成相应的一个或者多个测试用例，并通过对各个待测试的单元分别完成测试，来校验软件运行的准确性以及软件质量。

上文结合图1至图9对本申请实施例提供的生成测试用例的方法进行了详细介绍，下面将结合附图从功能单元的角度对本申请实施例提供的生成测试用例的装置1000进行介绍。

参见图10所示的生成测试用例的装置1000的结构示意图，该生成测试用例的装置1000包括：

获取模块1001，用于获取与待测试的软件单元匹配的多个候选测试用例模板；

呈现模块1002，用于向用户呈现所述多个候选测试用例模板；

生成模块1003，用于基于所述用户从所述多个候选测试用例模板中选中的目标测试用例模板和所述软件单元的测试数据，生成用于测试所述软件单元的测试用例。

在一种可能的实施方式中，所述软件单元包括如下的一种或多种：类、方法。

在一种可能的实施方式中，所述多个候选测试用例模板中，第一候选测试用例模板属于第一测试框架，第二候选测试用例模板属于第二测试框架。

在一种可能的实施方式中，所述呈现模块1002，还用于向所述用户呈现所述软件单元中的方法；

所述获取模块1001，还用于获取所述用户设置的所述方法的参数值，所述参数值为所述软件单元的测试数据。

在一种可能的实施方式中，所述生成模块1003，还用于生成所述软件单元中的方法的参数值，所述参数值为所述软件单元的测试数据。

在一种可能的实施方式中，所述获取模块1001，用于：

获取所述软件单元对应的测试框架的标识；

确定与所述标识相匹配的所述多个候选测试用例模板。

在一种可能的实施方式中，所述获取模块1001，还用于获取自定义的所述多个候选测试用例模板中的一个或多个候选测试用例模板。

在一种可能的实施方式中，所述获取模块1001，还用于基于代码库，训练得到所述多个候选测试用例模板中的一个或多个候选测试用例模板。

在一种可能的实施方式中，所述获取模块1001，用于对所述代码库中的多个测试用例进行聚类，生成所述多个候选测试用例模板中的一个或多个候选测试用例模板。

根据本申请实施例的生成测试用例的装置1000可对应于执行本申请实施例中描述的方法，并且图10所示的生成测试用例的装置1000的各个模块的上述和其它操作和/或功能分别为了实现图3、图6中装置200所执行的各个方法的相应流程，为了简洁，在此不再赘述。

上述各实施例中，生成测试用例的过程也可以以单独的硬件设备实现。下面，对实现生成测试用例的过程的计算设备进行详细介绍。

图11提供了一种计算设备的结构示意图。图11所示的计算设备1100具体可以用于实现上述图3、图6所示实施例中生成测试用例的装置200的功能。

计算设备1100包括总线1101、处理器1102、通信接口1103和存储器1104。处理器1102、存储器1104和通信接口1103之间通过总线1101通信。总线1101可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extendedindustry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口1103用于与外部通信，例如接收软件开发者针对个不同版本的候选第三方库的选择操作等。

其中，处理器1102可以为中央处理器(central processing unit，CPU)。存储器1104可以包括易失性存储器(volatile memory)，例如随机存取存储器(random accessmemory，RAM)。存储器1104还可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，ROM)，快闪存储器，HDD或SSD。

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

具体地，在实现图3、图6所示实施例的情况下，且图3、图6所示实施例中所描述的生成测试用例的装置200为通过软件实现的情况下，实现生成测试用例的装置200的功能所需的软件或程序代码存储在存储器1104中，计算设备1100与其它设备的交互通过通信接口1103实现，如计算设备1100通过通信接口1103接收待测试的软件单元、向用户反馈生成的测试用例等。处理器用于执行存储器1104中的指令，实现生成测试用例的装置200所执行的方法。

此外，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算设备上运行时，使得计算设备执行上述图3、图6所示实施例所述的生成测试用例的方法。

本申请实施例还提供了一种计算机程序产品，所述计算机程序产品被计算机执行时，所述计算机执行前述生成测试用例的方法的任一方法。该计算机程序产品可以为一个软件安装包，在需要使用前述数据提供方法的任一方法的情况下，可以下载该计算机程序产品并在计算机上执行该计算机程序产品。

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

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

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

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