单元测试用例生成方法、装置、设备及存储介质

技术领域

本申请涉及自动化测试技术领域，尤其涉及一种单元测试用例生成方法、装置、设备及存储介质。

背景技术

随着数字化转型的大背景下，越来越多企业引入DevOps(DevelopmentOperations，过程、方法与系统的统称)模式来提高业务产品的持续交付效率，随着DevOps模式引入，需推动开发负责质量的主要工作，实现测试左移。开发人员既要进行业务逻辑开发，也要进行各种测试工作，如编写单元测试自动化用例、接口自动化用例；而从测试金字塔模型来看，单元测试用例容易发现业务代码中的问题，且易于实现自动化，但是单元测试用例的编写一般需要人为介入，这无疑会增加开发的工作量及成本，降低单元测试用例的生成效率。

发明内容

本申请所要解决的技术问题在于，提供一种单元测试用例生成方法、装置、设备及存储介质，能够提高单元测试用例的生成效率。

为了解决上述技术问题，一方面，本申请实施例提供了一种单元测试用例生成方法，包括：

获取目标业务的目标代码；所述目标代码包括至少一个源代码单元，以及与所述至少一个源代码单元各自对应的信息采集代码；

在基于目标系统测试用例对所述至少一个源代码单元进行系统测试的过程中，基于所述信息采集代码，得到所述至少一个源代码单元对应的目标输入信息和目标输出信息；

基于所述目标输入信息和所述目标输出信息，生成与所述目标系统测试用例关联的第一单元测试用例；所述第一单元测试用例用于在所述目标代码发生变更时，对变更后目标代码中的源代码单元的执行逻辑进行测试。

另一方面，本申请实施例提供了一种单元测试用例生成装置，包括：

目标代码获取模块，用于获取目标业务的目标代码；所述目标代码包括至少一个源代码单元，以及与所述至少一个源代码单元各自对应的信息采集代码；

信息采集模块，用于在基于目标系统测试用例对所述至少一个源代码单元进行系统测试的过程中，基于所述信息采集代码，得到所述至少一个源代码单元对应的目标输入信息和目标输出信息；

第一单元测试用例生成模块，用于基于所述目标输入信息和所述目标输出信息，生成与所述目标系统测试用例关联的第一单元测试用例；所述第一单元测试用例用于在所述目标代码发生变更时，对变更后目标代码中的源代码单元的执行逻辑进行测试。

另一方面，本申请提供了一种设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如上述的单元测试用例生成方法。

另一方面，本申请提供了一种计算机存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行如上述的单元测试用例生成方法。

实施本申请实施例，具有如下有益效果：

本申请通过获取包括源代码单元，以及与源代码单元对应的信息采集代码；在基于目标系统测试用例对源代码单元进行系统测试的过程中，基于信息采集代码，得到与源代码单元对应的目标输入信息和目标输出信息；这里的信息采集代码可实现在采集目标系统测试用例对源代码单元进行系统测试时，自动对源代码单元的输入信息和输出信息进行提取，从而提高了对源代码单元的输入输出信息提取的便利性和效率；然后基于目标输入信息和目标输出信息，生成与目标系统测试用例关联的第一单元测试用例，由于第一单元测试用例是基于信息采集代码自动提取的输入信息和输出信息生成的，而不需要人为介入，从而能够降低人力成本，提高单元测试用例的生成效率；进一步地，通过系统测试过程中采集的源代码单元的输入输出信息生成单元测试用例，能够避免人为编写代码的错误，提高单元测试用例的准确性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。

图1是本申请实施例提供的实施环境示意图；

图2是本申请实施例提供的一种单元测试用例生成方法流程图；

图3是本申请实施例提供的一种输入输出信息确定方法流程图；

图4是本申请实施例提供的第一单元测试用例生成方法流程图；

图5是本申请实施例提供的第一单元测试用例更新方法流程图；

图6是本申请实施例提供的第二单元测试用例生成方法流程图；

图7是本申请实施例提供的一种单元测试用例变异生成方法流程图；

图8是本申请实施例提供的单元测试用例的变异示意图。

图9是本申请实施例提供的单元测试用例生成流程图。

图10是本申请实施例提供的单元测试流程图。

图11是本申请实施例提供的一种单元测试用例生成装置示意图。

图12是本申请实施例提供的一种设备结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述。显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先对本说明书实施例中涉及的相关名词做以下解释：

AOP技术：Aspect Oriented Programming，面向切面编程，对业务处理过程中的切面进行提取，动态地将代码切入到指定的方法、位置上。

Hook技术：又称为钩子函数，在系统未调用函数前，先捕获调用信息并进行加工处理，然后在调用源函数执行原来操作。

系统测试：侧重于可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。

单元测试：是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

请参阅图1，其示出了本申请实施例提供的实施环境示意图，该实施环境可包括：至少一个第一终端110和第二终端120，所述第一终端110和所述第二终端120可通过网络进行数据通信。

具体地，第一终端110可采用已有的系统测试用例或单元测试用例对目标业务的目标代码进行测试；在基于系统测试用例对目标代码进行测试时，可自动采集目标代码中各源代码单元的输入输出信息，生成相应的单元测试用例；对于生成的单元测试用例，第一终端110可发送至第二终端120进行存储，以便于第一终端110在需要用到单元测试用例时，可从第二终端120处获取。另外，对于目标业务的目标代码也可存储在第二终端120，当第一终端110需要对目标代码进行测试时，从第二终端120获取目标代码到本地进行测试。

第一终端110可以基于浏览器/服务器模式(Browser/Server，B/S)或客户端/服务器模式(Client/Server，C/S)与第二终端120进行通信。第一终端110可以包括：智能手机、平板电脑、笔记本电脑、台式电脑、数字助理、智能可穿戴设备、车载终端、服务器等类型的实体设备，也可以包括运行于实体设备中的软体，例如应用程序等。本申请实施例中的第一终端110上运行的操作系统可以包括但不限于安卓系统、IOS系统、linux、windows等。

第二终端120与第一终端110可以通过有线或者无线建立通信连接，第二终端120可以包括一个独立运行的服务器，或者分布式服务器，或者由多个服务器组成的服务器集群，其中服务器可以是云端服务器。

为了解决现有技术中单元测试用例的生成效率低的问题，本申请实施例提供了一种单元测试用例生成方法，该方法的执行主体可以为上述的第一终端，具体地，该方法可包括：

S210.获取目标业务的目标代码；所述目标代码包括至少一个源代码单元，以及与所述至少一个源代码单元各自对应的信息采集代码。

目标代码可以是指能够实现目标业务的业务逻辑的代码。源代码单元可以是指软件测试中最小可测试单元，对于不同的程序语言，源代码单元的具体含义可能不同，例如C语言中源代码单元可以指一个函数，Java里源代码单元可以指一个类，图形化的软件中源代码单元可以指一个窗口或一个菜单等。

目标业务源代码中可包括一个或多个源代码单元，即目标业务的业务逻辑可通过执行这一个或者多个源代码单元来实现。通过在目标业务源代码的至少一个源代码单元中注入与至少一个源代码对应的信息采集代码，即对每个源代码单元进行信息采集代码的注入，能够得到与目标业务对应的目标代码。其中，信息采集代码与目标业务源代码相独立，信息采集代码不用于实现相关的业务逻辑，而是用于采集源代码单元的输入输出信息。

对于信息采集代码的具体注入方式可基于AOP技术或者Hook技术进行实现，通过AOP或者Hook注入编译生成采集插桩版本的目标代码。

S220.在基于目标系统测试用例对所述至少一个源代码单元进行系统测试的过程中，基于所述信息采集代码，得到所述至少一个源代码单元对应的目标输入信息和目标输出信息。

测试用例(Test Case)是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

系统测试用例能够用于对整体业务逻辑的实现进行测试，基于目标系统测试用例对所述至少一个源代码单元进行系统测试是指对包含至少一个源代码单元的目标业务源代码进行测试，并不会对信息采集代码进行测试。

在采用系统测试用例执行系统测试过程中，各源代码单元均会有相应的输入输出信息，通过各源代码单元对应的信息采集代码可采集到每个源代码单元的输入输出信息。

具体请参阅图3，其示出了一种输入输出信息确定方法，该方法可包括：

S310.通过所述信息采集代码采集所述至少一个源代码单元的输入信息和输出信息。

S320.对所述输入信息和所述输出信息进行序列化处理，得到所述目标出入信息和所述目标输出信息。

信息采集代码所采集到的信息是源代码单元的实际输入输出信息，以源代码单元为函数进行说明，信息采集代码采集到的输入信息可以为函数的输入参数，输出信息可以为函数的返回值。

进一步地，还可以对采集到的输入信息和输出信息进行序列化处理，得到目标输入信息和目标输出信息，并存储；序列化能够将对象的状态信息转换为可以存储或传输的形式，从而便于对输入输出数据进行存储和维护，提升数据的可读性。

S230.基于所述目标输入信息和所述目标输出信息，生成与所述目标系统测试用例关联的第一单元测试用例；所述第一单元测试用例用于在所述目标代码发生变更时，对变更后目标代码中的源代码单元的执行逻辑进行测试。

基于目标输入信息和目标输出信息可生成相应的第一单元测试用例，具体请参阅图4，其示出了第一单元测试用例生成方法，该方法可包括：

S410.对所述目标输入信息和所述目标输出信息进行反序列化处理，得到反序列化处理后的输入信息和输出信息。

S420.对所述输入信息进行参数化处理，得到参数化输入信息。

S430.基于所述参数化输入信息和所述输出信息，生成所述第一单元测试用例。

反序列化处理是序列化处理的逆向过程，将反序列化之后的输入信息作为参数化测试的测试输入，将反序列化之后的输出信息作为参数化测试的测试输出；进一步地，参数化是自动化测试脚本的一种常用技巧，可将脚本中的某些输入使用参数来代替，脚本在运行时，根据需要选取不同的参数值作为输入。

参数化的使用场景可以包括：

1.若要求每次访问接口的数据不一样时，需要用到参数化，更好地模拟用户情况，例如压力测试；

2.需要多次获取同一数据，则可以用一个参数来代替，在需要的地方使用这一个变量就可以了。

通过对测试用例的输入信息进行参数化处理，能够将测试用例与测试数据分离开，测试用例能过读取不同测试数据进行执行，便于对输入参数进行统一管理。

与目标系统测试用例关联的第一单元测试用例是指，该第一单元测试用例是基于目标系统测试用例进行系统测试生成的，即该第一单元测试用例与该目标系统测试用例具有关联关系，相应可建立关联关系，例如生成的第一单元测试用例可携带有相关联的系统测试用例的用例标识，这样可直接基于该标识确定与第一单元测试用例关联的系统测试用例。

第一单元测试用例是基于目标代码生成的，可用于对变更后的目标代码中源代码单元的实现逻辑或者执行逻辑进行测试，测试变更后的目标代码中源代码单元的原有功能是否发生变更。第一单元测试用例可作为挖掘core/crash场景测试用例的种子，辅助变异生成更多用例。

请参阅图5，其示出了第一单元测试用例更新方法，该方法可包括：

S510.基于所述第一单元测试用例对所述变更后目标代码中的至少一个源代码单元进行单元测试，得到单元测试结果。

S520.当所述单元测试结果指示存在测试失败的第一单元测试用例时，确定与所述测试失败的第一单元测试用例关联的关联系统测试用例。

S530.基于所述关联系统测试用例对所述变更后目标代码中的至少一个源代码单元进行系统测试，得到系统测试结果。

S540.基于所述系统测试结果对所述测试失败的第一单元测试用例进行更新。

具体地，对于目标代码中的每个源代码单元，可对应一个或者多个第一单元测试用例，在具体对变更后目标代码中的源代码单元进行测试时，可仅对一个源代码单元进行测试，也可同时对多个源代码单元进行测试。

当采用第一单元测试用例对变更后目标代码中源代码单元进行测试，并测试成功时，说明相应的被测试源代码单元的功能没有发生变更；当测试失败时，需要进一步确定测试失败的原因，并更具失败原因确定是否需要更新第一单元测试用例。

当存在测试失败的第一单元测试用例时，可根据第一单元测试用例与系统测试用例的关联关系，确定与测试失败的第一单元测试用例对应的关联系统测试用例。采用关联系统测试用例对变更后目标代码中除信息采集代码以外的代码进行测试，得到系统测试结果。

当系统测试结果指示基于关联系统测试用例测试成功时，说明整个业务系统实现逻辑没有发生变化，而是被测试源代码单元发生了变更，此时可对相应的第一单元测试用例进行更新；具体更新所采用的信息是在关联系统测试用例对变更后目标代码中除信息采集代码以外的代码进行测试时，由被测试源代码单元的信息采集代码进行采集得到的。当系统测试结果指示基于关联系统测试用例测试失败时，相应会生成测试报告，告知开发人员确定代码修改是否有误。

例如，对于源代码单元A，有相应的第一单元测试用例a，其中第一单元测试用例a中的输入信息为x，输出信息为y；在代码发生变更后，源代码单元A对应源代码单元A’，A和A’可能相同，也可能不同；那么在采用第一单元测试用例a对其进行测试时，输入是x，输出为y’，若y和y’不相同，则说明第一单元测试用例a测试失败。此时确定与第一单元测试用例a对应的目标系统测试用例b，并基于目标系统测试用例b执行系统测试，若目标系统测试用例b测试成功，则说明整体业务逻辑没有发生变化，而是源代码单元A发生了变更，此时可基于系统测试过程中对源代码单元A’采集的输入输出信息对相应的第一单元测试用例a进行更新。

从而在存在测试失败的第一单元测试用例时，基于在系统测试过程中采集到的源代码单元的输入输出信息对第一单元测试用例进行更新，能够提高第一单元测试用例更新的便利性和效率。

进一步地，还可对变更后代码单元中的源代码单元的异常状态进行测试；具体请参阅图6，其示出了第二单元测试用例生成方法，第二单元测试用例可用于触发core或者crash场景，core或者crash场景是指程序执行的过程中因异常终止或崩溃的场景；该方法可包括：

S610.对所述变更后目标代码进行静态分析，得到所述变更后目标代码中每个源代码单元的代码特征信息。

S620.基于所述代码特征信息，生成与所述每个源代码单元对应的第二单元测试用例；所述第二单元测试用例用于对所述变更后目标代码中的代码单元的异常状态进行测试。

静态分析是指用自动化工具软件对程序源代码进行检查，以分析程序行为的技术，应用于程序的正确性检查、安全缺陷检测、程序优化等；静态分析有助于在项目早期发现以下问题：变量声明了但未使用、变量类型不匹配、变量在使用前未定义、不可达代码、死循环、数组越界、内存泄漏等。

本申请实施例中的静态分析可以是基于AST分析或者静态代码分析工具(如cppcheck、TscanCode)对源码进行分析并提炼出代码特征信息，代码特征信息包括函数的参数个数、类型、返回类型、所属类或结构体，函数的分支表达式、循环表达式特征，以及类或结构体的构造函数、成员属性、命名空间等信息。

接着，利用分析出来的参数类型及内部特征等信息，逐一构造测试用例，测试用例包括被测函数的类名及函数名，指定构造函数的输入参数，以及被测函数的输入参数等。

然后，基于模板生成自动化测试用例，模板主要分为四个部分，分别是类对象参数定义，类对象实例化，函数调用参数定义，以及不出现core/crash的断言，相关代码实现如下所示：

TEST(BankAccount,test_deposit){

//类对象参数定义

string cartId＝"test"；

int balance＝101；

//类对象实例化

BankAccount bankAccount＝new BankAccount(cartId,balance)；

//函数调用参数定义

int amount＝100；

//不出现core或crash的断言

ASSERT_NO_DEATH(bankAccount.deposit(amount))

采用基于静态分析生成的第二单元测试用例对源业务代码进行测试，能够提高代码的鲁棒性。

对生成的第二单元测试用例进行执行，可能出现多个相同的core/crash问题，需要进行问题去重。去重规则会根据函数名，core/crash代码行及堆栈信息特征等进行判断。对于core/crash问题，根据运行过程中的检测工具(如valgrind、Address Sanitizer)采集到的运行信息及堆栈信息，并结合经验库，预估出错原因。

由于第二单元测试用例是基于变更后目标代码进行静态代码分析得到的，无法提前理解业务特征，可结合与目标代码对应的第一单元测试用例和第二单元测试用例，利用数据变异技术，进一步生成新的第二单元测试用例。具体请参阅图7，其示出了一种单元测试用例变异生成方法，该方法可包括：

S710.对所述第一单元测试用例以及所述第二单元测试用例进行数据变异处理，得到模糊测试用例；所述模糊测试用例用于对所述变更后目标代码中的源代码单元的异常状态进行测试。

S720.基于所述模糊测试用例对所述变更后目标代码中的源代码单元进行单元测试，得到被测试源代码单元的分支覆盖率。

S730.基于所述被测试源代码单元的分支覆盖率，对所述第一单元测试用例的权重进行调整；所述权重用于表征在进行数据变异处理过程中所述第一单元测试用例被选中的概率信息。

模糊变异技术Fuzzer是一种通过产生一系列非法的、非预期的或者随机的输入信息给目标程序，从而完成自动化的触发和挖掘目标程序中的安全漏洞的软件测试技术。

本申请实施例中结合数据变异技术对第一单元测试用例以及第二单元测试用例中的数据进行有机组合，生成相应的模糊测试用例。采用模糊测试用例对变更后目标代码中的源代码单元进行测试，采用分支率采集工具采集模糊测试用例的分支覆盖率作为模糊测试用例的反馈。

对于第一单元测试用例和第二单元测试用例的变异示意图可参阅图8，从图8中可以看出，在常规core/crash场景的单元测试用例的流程中插入Fuzzer模糊变异生成器，结合两种用例进行变异生成，并对执行的模糊测试用例收集分支覆盖率，作为变异反馈，对有效变异的种子提升权重，便于找到更多深入路径。基于变异生成的模糊测试用例进行单元测试能够提高代码分支的覆盖率，也增加了挖掘更为深入的core/crash场景用例的机率。本申请通过获取包括源代码单元，以及与源代码单元对应的信息采集代码；在基于目标系统测试用例对源代码单元进行系统测试的过程中，基于信息采集代码，得到与源代码单元对应的目标输入信息和目标输出信息；这里的信息采集代码可实现在采集目标系统测试用例对源代码单元进行系统测试时，自动对源代码单元的输入信息和输出信息进行提取，从而提高了对源代码单元的输入输出信息提取的便利性和效率；然后基于目标输入信息和目标输出信息，生成与目标系统测试用例关联的第一单元测试用例，由于第一单元测试用例是基于信息采集代码自动提取的输入信息和输出信息生成的，而不需要人为介入，从而能够降低人力成本，提高单元测试用例的生成效率；进一步地，通过系统测试过程中采集的源代码单元的输入输出信息生成单元测试用例，能够避免人为编写代码的错误，提高单元测试用例的准确性。

由本实施例上述内容可知，单元测试用例的生成方法可包括第一单元测试用例生成方法，以及第二单元测试用例生成方法，第一单元测试用例可以是通过系统测试采集到的业务场景的单元测试用例；第二单元测试用例是用于生成core/crash场景的单元测试用例。请参阅图9，其示出了core场景的单元测试用例以及业务场景的单元测试用例生成流程图，其中core场景的单元测试用例的断言判断源代码单元是否出现core情况，有core就断言为假，而没有就断言为真，用于挖掘源代码单元潜在问题；而业务场景的单元测试用例是根据采集的入参值及返回值，能断言相同的入参值能否返回相同的返回值，若返回值相同，断言为真，否则断言为假。

本实施例所提供的方法可以提供给开发人员，以快速实现单元测试用例的自动生成，既能生成挖掘能触发core的单元测试用例，也能根据系统测试采集到的函数调用实时信息生成具有断言的单元测试用例。请参阅图10，其示出了单元测试流程图，开发人员提交代码后，自动生成方案会分析代码，并结合上一个版本采集的业务场景的单元测试用例，生成并执行core场景的单元测试用例，会输出core场景的测试报告；开发人员需要介入判断是否修复问题，如果需要，就需要重新提交代码。

在提交代码后，也会执行上一个版本采集的业务场景的单元测试用例，若存在某些单元测试用例执行不通过，需要开发人员介入判断是否需要修复；若因业务逻辑修改导致原来单元测试用不通过，开发人员无需修改，让其通过继续执行系统测试，即可重新采集到最新版本的单元测试用例。

本实施例所提供的方法通过对源代码进行静态分析与提炼，根据模板生成能触发core场景的自动化测试用例，并对问题进行去重及分析，挖掘出代码潜在问题；然后对源代码进行AOP/Hook注入编译生成采集插桩版本，对该版本运行系统测试用例，采集到系统测试的所执行函数的入参及返回值，并对其进行序列化并存储起来，根据采集到入参及返回值生成单元测试用例，若在执行单元测试过程中返回值不一致，就会执行对应的系统测试，验证采集到的单元测试用例的有效性。对于存储起来的单元测试用例可作为挖掘core/crash场景测试用例的种子，辅助变异生成更多用例。从而通过代码静态分析，挖掘出会触发core的单元测试用例，并实现自动化生成、验证与分析，便于提高代码鲁棒性；对系统测试进行插桩采集正常场景的单元测试用例，通过参数化入参生成单元测试用例，能实现自动化生成断言，便于版本快速迭代验证；利用系统测试采集到的单元测试用例作为种子，变异生成更多能触发core/crash场景的单元测试用例；实现单元测试用例的自动化生成，减少人为介入编写的工作量，也把测试工作前置，能更快发现问题和减少修改问题的成本。

相应地，请参阅图11，其示出了一种单元测试用例生成装置，该装置可包括：

目标代码获取模块1110，用于获取目标业务的目标代码；所述目标代码包括至少一个源代码单元，以及与所述至少一个源代码单元各自对应的信息采集代码；

信息采集模块1120，用于在基于目标系统测试用例对所述至少一个源代码单元进行系统测试的过程中，基于所述信息采集代码，得到所述至少一个源代码单元对应的目标输入信息和目标输出信息；

第一单元测试用例生成模块1130，用于基于所述目标输入信息和所述目标输出信息，生成与所述目标系统测试用例关联的第一单元测试用例；所述第一单元测试用例用于在所述目标代码发生变更时，对变更后目标代码中的源代码单元的执行逻辑进行测试。

进一步地，所述装置还包括：

第一测试模块，用于基于所述第一单元测试用例对所述变更后目标代码中的至少一个源代码单元进行单元测试，得到单元测试结果；

关联系统测试用例确定模块，用于当所述单元测试结果指示存在测试失败的第一单元测试用例时，确定与所述测试失败的第一单元测试用例关联的关联系统测试用例；

第二测试模块，用于基于所述关联系统测试用例对所述变更后目标代码中的至少一个源代码单元进行系统测试，得到系统测试结果；

更新模块，用于基于所述系统测试结果对所述测试失败的第一单元测试用例进行更新。

进一步地，所述信息采集模块1120包括：

第一采集模块，用于通过所述信息采集代码采集所述至少一个源代码单元的输入信息和输出信息；

序列化处理模块，用于对所述输入信息和所述输出信息进行序列化处理，得到所述目标出入信息和所述目标输出信息。

进一步地，所述第一单元测试用例生成模块1130包括：

反序列化处理模块，用于对所述目标输入信息和所述目标输出信息进行反序列化处理，得到反序列化处理后的输入信息和输出信息；

参数化处理模块，用于对所述输入信息进行参数化处理，得到参数化输入信息；

第一生成模块，用于基于所述参数化输入信息和所述输出信息，生成所述第一单元测试用例。

进一步地，所述装置还包括：

静态分析模块，用于对所述变更后目标代码进行静态分析，得到所述变更后目标代码中每个源代码单元的代码特征信息；

第二生成模块，用于基于所述代码特征信息，生成与所述每个源代码单元对应的第二单元测试用例；所述第二单元测试用例用于对所述变更后目标代码中的代码单元的异常状态进行测试。

进一步地，所述装置还包括：

数据变异处理模块，用于对所述第一单元测试用例以及所述第二单元测试用例进行数据变异处理，得到模糊测试用例；所述模糊测试用例用于对所述变更后目标代码中的代码单元的异常状态进行测试；

第三测试模块，用于基于所述模糊测试用例对所述变更后目标代码中的源代码单元进行单元测试，得到被测试源代码单元的分支覆盖率；

权重调整模块，用于基于所述被测试源代码单元的分支覆盖率，对所述第一单元测试用例的权重进行调整；所述权重用于表征在进行数据变异处理过程中所述第一单元测试用例被选中的概率信息。

进一步地，所述装置还包括：

代码注入模块，用于在目标业务源代码的所述至少一个源代码单元中注入与所述至少一个源代码单元对应的信息采集代码，得到所述目标代码。

上述实施例中提供的装置可执行本申请任意实施例所提供方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的方法。

本实施例还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行如本实施例上述任一方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如本实施例上述任一方法。

进一步地，图12示出了一种用于实现本申请实施例所提供的方法的设备的硬件结构示意图，所述设备可以参与构成或包含本申请实施例所提供的装置。如图12所示，设备10可以包括一个或多个(图中采用102a、102b，……，102n来示出)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图12所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，设备10还可包括比图12中所示更多或者更少的组件，或者具有与图12所示不同的配置。

应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到设备10(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中所述的方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种播放器预加载方法或一种播放器运行方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至设备10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括设备10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与设备10(或移动设备)的用户界面进行交互。

本实施例上述的任一方法均可基于图12所示的设备进行实施。

本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤和顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或中断产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

本实施例中所示出的结构，仅仅是与本申请方案相关的部分结构，并不构成对本申请方案所应用于其上的设备的限定，具体的设备可以包括比示出的更多或更少的部件，或者组合某些部件，或者具有不同的部件的布置。应当理解到，本实施例中所揭露的方法、装置等，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分仅仅为一种逻辑功能的划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元模块的间接耦合或通信连接。

基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员还可以进一步意识到，结合本说明书所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但这种实现不应认为超出本申请的范围。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。