CN114546849A - 代码测试方法及装置 - Google Patents

Abstract

本公开提供了一种代码测试方法及装置，涉及计算机技术，尤其涉及代码测试领域。具体实现方案为：根据至少一个测试用例对第一代码进行测试，得到各测试用例各自的第一测试结果，其中，第一代码为待上线的代码。根据至少一个测试用例以及各测试用例的第一测试结果，确定目标测试用例，其中，目标测试用例的第一测试结果为失败。获取目标测试用例对应的异常标识，并确定与异常标识匹配的目标场景。根据目标场景、目标测试用例以及第一代码，向目标设备发送测试报告，其中，测试报告中包括目标测试用例在第一代码中覆盖的语句。本公开的技术方案可以有效缩短代码测试的耗时。

Description

代码测试方法及装置

技术领域

本公开涉及计算机技术中的代码测试领域，尤其涉及一种代码测试方法及装置。

背景技术

在项目迭代开发的过程中，对项目代码进行测试是非常重要的环节，代码测试可以有效的保证项目运行的正确性和完整性。

目前，现有技术中在实现代码测试的时候，通常都是依赖于人工进行环境的配置以及测试过程的执行。并且在测试之后，针对发生异常的测试用例，还需要人工排查导致这些异常发生的原因。

因此，现有技术中依赖于人工进行代码测试，会导致代码测试的耗时较长。

发明内容

本公开提供了一种代码测试方法及装置。

根据本公开的第一方面，提供了一种代码测试方法，包括：

根据至少一个测试用例对第一代码进行测试，得到各所述测试用例各自的第一测试结果，其中，所述第一代码为待上线的代码；

根据所述至少一个测试用例以及各所述测试用例的第一测试结果，确定目标测试用例，其中，所述目标测试用例的第一测试结果为失败；

获取所述目标测试用例对应的异常标识，并确定与所述异常标识匹配的目标场景；

根据所述目标场景、所述目标测试用例以及所述第一代码，向目标设备发送测试报告，其中，所述测试报告中包括所述目标测试用例在所述第一代码中覆盖的语句。

根据本公开的第二方面，提供了一种代码测试装置，包括：

处理模块，用于根据至少一个测试用例对第一代码进行测试，得到各所述测试用例各自的第一测试结果，其中，所述第一代码为待上线的代码；

确定模块，用于根据所述至少一个测试用例以及各所述测试用例的第一测试结果，确定目标测试用例，其中，所述目标测试用例的第一测试结果为失败；

获取模块，用于获取所述目标测试用例对应的异常标识，并确定与所述异常标识匹配的目标场景；

发送模块，用于根据所述目标场景、所述目标测试用例以及所述第一代码，向目标设备发送测试报告，其中，所述测试报告中包括所述目标测试用例在所述第一代码中覆盖的语句。

根据本公开的第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面所述的方法。

根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面所述的方法。

根据本公开的第五方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序，所述计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从所述可读存储介质读取所述计算机程序，所述至少一个处理器执行所述计算机程序使得电子设备执行第一方面所述的方法。

根据本公开的技术解决了代码测试的耗时较长的问题。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1为本公开实施例提供的测试过程的实现示意图；

图2为本公开实施例提供的代码测试方法的流程图；

图3为本公开实施例提供的代码测试方法的流程图二；

图4为本公开实施例提供的第一测试用例和第二测试用例的关系示意图一；

图5为本公开实施例提供的第一测试用例和第二测试用例的关系示意图二；

图6为本公开实施例提供的第一测试用例和第二测试用例的关系示意图三；

图7为本公开实施例提供的场景和异常标识的对应关系示意图；

图8为本公开实施例介绍的生成测试报告的实现示意图一；

图9为本公开实施例介绍的生成测试报告的实现示意图二；

图10为本公开实施例介绍的生成测试报告的实现示意图三；

图11为本公开实施例提供的代码测试方法的流程示意图；

图12为本公开实施例的代码测试装置的结构示意图；

图13是用来实现本公开实施例的代码测试方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

为了更好的理解本公开的技术方案，下面对本公开所涉及的相关技术进行进一步的详细介绍。

随着计算机技术的不断发展，出现了越来越多的基于计算机技术而实现的项目，其中不同的项目通常可以为用户提供不同的服务。

在项目开发的过程中，通常需要进行项目的迭代，以实现对项目的更新和完善。以及在项目迭代的过程中，针对待上线的项目代码进行测试是非常重要的环节，以保证项目的正确性、完整性、安全性和质量。

其中，测试是一种实际输出与预期输出之间的审核或者比较过程。测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，并对其是否能满足设计要求进行评估的过程。

例如可以结合图1对项目测试的实现过程进行理解，图1为本公开实施例提供的测试过程的实现示意图。

如图1所示，假设当前存在待测试的项目代码，以及假设当前存在测试用例1，在测试用例1中比如说可以包括输入数据和预期输出，其中预期输出就是说在预期的情况下，将输入数据输入至待测试的项目代码所能够得到的输出。

参照图1，例如可以采用待测试的项目代码对输入数据进行处理，在待测试的项目代码处理完成之后，可以得到图1所示的实际输出。然后可以将实际输出和预期输出进行比较，从而得到测试结果。

具体的，若实际输出和预期输出一致，则可以确定测试用例1的测试结果为成功(测试通过)；若实际示出和预期输出不一致，则可以确定测试用例1的测试结果为失败(测试不通过)。

基于上述介绍的代码测试的过程，目前，现有技术中在实现代码测试的时候，通常都是依赖于人工进行环境的配置以及测试过程的执行。具体的，需要人工的手动触发部署和场景验证能力，并且出现异常场景时，需要投入品质保证(Qualtiy Assurance，qa)和研发工程师(Research and Development engineer，rd)来人力定位出现问题的位置。其中，rd可以定位自身代码，qa需要根据失败场景判断影响的业务场景。

然而，人工触发测试的实现会导致无法快速的触发回归验证，以及人工定位代码异常位置，会导致代码测试的耗时较长。

针对现有技术中的问题，本公开提出了如下技术构思：自动的触发代码的测试，并且针对失败的测试用例，可以自动的匹配异常的场景，并且自动的上报测试报告，在测试报告中可以直接指出当前的测试报告匹配的异常语句在哪里，这样就可以快速高效的实现针对代码的测试，并快速高效的实现针对异常问题的定位。

在上述介绍内容的基础上，下面结合具体的实施例对本公开提供的代码测试方法进行介绍。需要说明，本公开中各实施例的执行主体例如可以为服务器、处理器、微处理器、芯片等具备数据处理功能的设备，本实施例各实施例的具体的执行主体不做限制，其可以根据实际需求进行选择和设置，只要是具备数据处理功能以及数据收发功能的设备均可以作为本公开中各实施例的执行主体。

首先结合图2进行说明，图2为本公开实施例提供的代码测试方法的流程图。

如图2所示，该方法包括：

S201、根据至少一个测试用例对第一代码进行测试，得到各测试用例各自的第一测试结果，其中，第一代码为待上线的代码。

在本实施例中，为了实现对项目代码的自动化测试，比如说可以预先设置多个测试用例，在一种可能的实现方式中，预设的多个测试用例应该涵盖对项目代码的各自情况的全方位的测试，在实际实现过程中，实际的预设的测试用例可以根据实际需求进行选择和设置，本实施例对此不做限制。

以及，本实施例中的第一代码就是项目的待上线的代码，基于上述介绍可以确定的是，在项目的迭代过程中，是需要针对待上线的代码进行验证的，那么当前的第一代码实际上就是项目迭代的过程中，需要上线的代码，那么就需要针对第一代码进行测试。

因此在本实施例中，就可以根据至少一个测试用例对第一代码进行测试，从而得到各个测试用例各自的第一测试结果。其中，第一测试结果可以为成功，或者，第一测试结果可以为失败。

以及，针对任一个测试用例，在根据其对第一代码进行测试的时候，实际上就是采用第一代码对测试用例中的输入数据进行处理，从而得到实际输出，之后将实际输出和测试用例中的预期输出进行比较，以得到第一测试结果。其具体的实现方式已经在上述实施例中进行了截杀，此处对此不再赘述。

S202、根据至少一个测试用例以及各测试用例的第一测试结果，确定目标测试用例，其中，目标测试用例的第一测试结果为失败。

在得到各个测试用例的第一测试结果之后，例如可以在至少一个测试用例中确定目标测试用例，本实施例中的目标测试用例的第一测试结果为失败。

在一种可能的实现方式中，本实施例中比如说可以将第一测试结果为失败的所有的测试用例都确定为目标测试用例。或者，还可以将第一测试结果为失败的部分测试用例确定为目标测试用例，其中的部分测试用例比如说可以是因为代码本身所导致的测试结果为失败的测试用例。

S203、获取目标测试用例对应的异常标识，并确定与异常标识匹配的目标场景。

可以理解的是，本实施例中的每一个测试用例都是在第一代码处理之后，才会得到第一测试结果，其中，第一测试结果可能是成功，也可能是失败。

针对第一测试结果为失败的测试用例，表明其实际输出和预期输出是不同的，也就是说这些测试用例的输出是异常的。则例如可以获取到这部分测试用例对应的异常标识。其中，异常标识可以用于指示该测试用例的具体的异常情况，比如说是返回的内容错误，还是请求被拒绝，等等的之类的具体异常情况。

其中异常标识比如说可以是运行测试用例之后返回的字符串信息，或者还可以是预设的测试用例所对应的字符串信息。可以理解的是，每一个测试用例都是出于一定的测试目的而设计的，比如说某一个测试用例是为了测试“第一代码返回的检索结果的数量是否为预设数量”，那么在该测试用例的第一测试结果为失败的时候，就可以确定第一代码返回的检索结果的数量不是预设数量。则例如可以设置预设的字符串用于表示这种异常情况。

以及本实施例中，还可以针对每一个异常标识设置有各自对应的场景，用于指示当前的异常标识对应的是什么异常场景。例如上述示例中，对应的场景就可以是“返回结果数量异常”的场景。

则本实施例中可以在确定目标测试用例之后，例如可以获取目标测试用例所对应的异常标识，同时，可以确定与异常标识匹配的目标场景。

同时需要说明的是，尽管异常标识和场景之间存在直接的对应关系，但是因为异常标识通常表现为字符串的形式，因此不能直观的表达当前具体的异常情况，因此通过确定异常标识对应的目标场景，可以有效并直观的展示当前具体的异常情况。

S204、根据目标场景、目标测试用例以及第一代码，向目标设备发送测试报告，其中，测试报告中包括目标测试用例在第一代码中覆盖的语句。

在确定各个测试用例各自的第一测试结果之后，实际上针对第一代码的测试就已经结束了，并且上述还确定了目标测试用例所对应的目标场景，也就是说具体确定了当前是发生了什么异常，则可以根据目标场景、目标测试用例以及第一代码，确定测试报告。

可以理解的是，不同的测试用例在代码中的覆盖语句是不同的，其中测试用例在代码中的覆盖语句，实际上就是当前的测试用例所针对性的测试的部分。则为了快速有效的实现对代码中问题部分的定位，在一种可能的实现方式中，可以在测试报告中包括目标测试用例在第一代码中所覆盖的语句。

以及，在测试报告中比如说还可以包括目标场景、目标测试用例等等，本实施例对测试报告的具体内容不做限制，凡是与测试相关的内容，均可以作为测试报告中所包括的内容。

在确定测试报告之后，就可以向目标设备发送测试报告了，以使得相关的操作人员快速的了解当前的代码测试结果，并根据测试报告对代码进行相应的调试，以针对代码中的异常部分进行修复。

本公开实施例提供的代码测试方法，包括：根据至少一个测试用例对第一代码进行测试，得到各测试用例各自的第一测试结果，其中，第一代码为待上线的代码。根据至少一个测试用例以及各测试用例的第一测试结果，确定目标测试用例，其中，目标测试用例的第一测试结果为失败。获取目标测试用例对应的异常标识，并确定与异常标识匹配的目标场景。根据目标场景、目标测试用例以及第一代码，向目标设备发送测试报告，其中，测试报告中包括目标测试用例在第一代码中覆盖的语句。通过预设的测试用例对待上线的第一代码进行测试，得到各个测试用例的第一测试结果，并且根据在测试用例中确定第一测试结果为失败的目标测试用例，之后根据目标测试用例对应的异常标识确定当前异常的目标场景，并向目标设备发送测试报告，在测试报告中可以包括目标测试用例在第一代码中所覆盖的语句，从而可以有效的实现对代码的自动测试，并且快速的定位代码中的异常部分，以有效缩短代码测试的耗时。

在上述介绍的内容的基础上，下面结合图3至图7对本公开提供的代码测试方法进行进一步的详细介绍，图3为本公开实施例提供的代码测试方法的流程图二，图4为本公开实施例提供的第一测试用例和第二测试用例的关系示意图一，图5为本公开实施例提供的第一测试用例和第二测试用例的关系示意图二，图6为本公开实施例提供的第一测试用例和第二测试用例的关系示意图三，图7为本公开实施例提供的场景和异常标识的对应关系示意图。

如图3所示，该方法包括：

S301、根据至少一个测试用例对第一代码进行测试，得到各测试用例各自的第一测试结果，其中，第一代码为待上线的代码。

其中，S301的实现方式与S201介绍的实现方式类似，此处不再赘述。

S302、根据至少一个测试用例对第二代码进行测试，得到各测试用例各自的第二测试结果，其中，第二代码为已上线的代码。

在本实施例中，在对第一代码进行测试，得到各个测试用例各自的第一测试结果之后，可能会出现第一测试结果为失败的测试用例，为了确定这部分失败的测试用例是因为项目本身导致的失败，还是因为数据导致的失败，本实施例中还会根据至少一个测试用例对第二代码进行测试。

其中，第二代码为已上线的代码，也就是说第二代码是已经投入使用的代码，而基于上述介绍可以确定的是，第一代码是当前待上线的代码，因此本实施例中的第一代码和第二代码是不同的代码，可以理解，第一代码是在第二代码的基础上进行了迭代更新的代码。

那么当前为了确定在代码迭代之后，是否是代码本身出现了问题，则在根据至少一个测试用例对第一代码进行测试之后，还可以根据至少一个测试用例对第二代码进行测试。需要说明，针对第一代码进行测试的各个测试用例和针对第二代码进行测试的各个测试用例是相同的。

其中，根据至少一个测试用例对第一代码进行测试可以理解为线下测试，根据至少一个测试用例对第二代码进行测试可以理解为线上测试、

具体的，根据至少一个测试用例对第二代码进行测试，可以得到各测试用例各自的第二测试结果，同样的，第二测试结果可以为成功，还可以为失败。

S303、将第一测试结果为失败的测试用例确定为第一测试用例，以及，将第二测试结果为失败的测试用例确定为第二测试用例。

在对第一代码进行测试，得到各个测试用例各自的第一测试结果和第二测试结果之后，可以首先从测试用例中选择出测试结果为失败的测试用例。在一种可能的实现方式中，例如可以将第一测试结果为失败的测试用例确定为第一测试用例，以及将第二测试结果为失败的测试用例确定为第二测试用例。

S304、将第一测试用例和第二测试用例的交集部分，确定为第三测试用例。

当前确定的第一测试用例是第一代码对应的失败的测试用例，以及第二测试用例是第二代码对应的失败的测试用例。本实施例中可以将第一测试用例和第二测试用例的交集部分确定为第三测试用例，那么第三测试用例就是说在针对第一代码的测试中失败，并且在针对第二代码的测试中也失败的测试用例。

下面结合图示对第一测试用例和第二测试用例的可能的关系，以及对应的确定第三测试用例的实现进行介绍。

在一种可能的实现方式中，参照图4，假设存在多个第一测试用例，分别是测试用例1、测试用例2、测试用例3、测试用例4、测试用例5，而第二测试用例为空。也就是说针对第一代码的线下测试存在失败用例，而针对第二代码的线上测试不存在失败用例。

针对这种情况，可以理解，测试用例在未迭代的第二代码中均测试通过，而在迭代后的第一代码中存在测试不通过的情况，那么就有可能是代码迭代过程中，在第一代码中引入了错误或者异常，则需要针对第一代码对应的失败的测试用例进行进一步的处理。

在这种情况下，确定的第一测试用例和第二测试用例的交集部分实际上就是空，也就是说第三测试用例为空。

在另一种可能的实现方式中，参照图5，假设存在多个第一测试用例以及多个第二测试用例，并且第一测试用例和第二测试用例完全相同，比如说图5中，第一测试用例和第二测试用例均为测试用例1、测试用例2、测试用例3、测试用例4、测试用例5。也就是说针对第一代码的线下测试存在失败用例，并且针对第二代码的线上测试也存在失败测试用例，并且线上测试和线下测试发生失败的测试用例是完全相同的。

针对这种情况，可以理解，第一代码对应的失败测试用例和第二代码对应的失败测试用例完全相同，则表明并不是代码迭代所产生的问题，有可能是代码所依赖的数据出现问题，或者可能是测试用例的设计出现问题。

在这种情况下，确定的第一测试用例和第二测试用例的交集部分实际上就是第一测试用例，也就是说第三测试用例就等于第一测试用例，比如说在图5的示例中，第三测试用例就包括测试用例1、测试用例2、测试用例3、测试用例4、测试用例5。

因为当前这种情况并不是代码的问题导致的测试失败，则例如可以针对失败的测试用例的测试结果进行干扰。比如说将确定的第三测试用例的第一测试结果修改为成功，并向目标设备发送测试报告，其中，测试报告中还包括第一指示信息，其中，第一指示信息用于指示对第三测试用例的结果进行了修改。之后相关人员在接收到这个测试报告之后，可以确定测试过程中发生了异常，并且可以确定针对异常的结果进行了修改，之后例如可以针对数据、测试用例等等进行相应的检查。

在另一种可能的实现方式中，参照图6，假设存在多个第一测试用例以及多个第二测试用例，并且第一测试用例和第二测试用例不完全相同，比如说图5中，第一测试用例为测试用例1、测试用例4和测试用例3，以及第二测试用例为测试用例2、测试用例3、测试用例5。

也就是说针对第一代码的线下测试存在失败用例，并且针对第二代码的线上测试也存在失败测试用例，其中线上测试和线下测试发生失败的测试用例存在部分相同，也存在部分不相同，并不是完全相同的。

针对这种情况，可以理解，第一代码对应的失败测试用例和第二代码对应的失败测试用例不完全相同，那么其中相同的部分就类似上述的图5的情况，表明并不是代码迭代所产生的问题，有可能是代码所依赖的数据出现问题，或者可能是测试用例的设计出现问题。而其中不同的部分就类似上述的图4的情况，表明是代码迭代所产生的问题。

在这种情况下，确定的第一测试用例和第二测试用例的交集部分，实际上就是在第一代码的测试和第二代码的测试中均失败的测试用例。比如说在图6的示例中，第三测试用例就包括测试用例3。

基于上述图4至图6的介绍可以确定的是，当前需要关注的是第一测试用例中和第二测试用例的差异部分，那么为了确定差异部分，例如可以首先确定第一测试用例和第二测试用例的交集部分，得到第三测试用例。

S305、将第一测试用例中，除第三测试用例之外的测试用例，确定为目标测试用例。

因为当前需要关注的是第一测试用例和第二测试用例中的差异部分，而上述的第三测试用例是第一测试用例和第二测试用例的交集部分，因此在确定第三测试用例之后，就可以将第一测试用例中除第三测试用例之外的测试用例确定为目标测试用例的，此处的目标测试用例实际上就是第一测试用例和第二测试用例的差异部分的测试用例。

比如说在上述的图4的示例中，因为不存在交集部分，所以目标测试用例就是测试用例1、测试用例2、测试用例3、测试用例4、测试用例5；而在上述图5的示例中，因为不存在差异部分，因此目标测试用例为空；以及在上述图6的示例中，差异部分的目标测试用例就是测试用例1和测试用例4。

以及需要说明的是，上述介绍的几种情况均是针对第一代码的第一测试结果存在失败的，这是因为只有第一代码存在失败测试用例的时候，才会进行后续的操作，若第一代码不存在失败的测试用例，则表明第一代码的所有的测试用例都通过了，那么也就无需进行后续的异常查找的操作了。

同时，基于上述介绍可以确定的是，本实施例中既进行了针对第一代码的线下测试，又进行了针对第二代码的线上测试，之后根据线上测试的第一测试结果和线下测试的第二测试结果，确定了针对第一代码测试失败，而针对第二代码测试成功的目标测试用例，因此可以有效实现从多个测试用例中，筛选出因为代码迭代导致测试失败的测试用例，之后针对目标测试用例进行处理，从而可以有效减少测试处理的工作量，以提升测试处理的效率。

S306、获取目标测试用例对应的异常标识，并确定与异常标识匹配的目标场景。

其中，S306的实现方式与上述S203的实现方式类似，此处不再赘述。

下面结合图7对异常标识以及对应的场景的几种可能的实现方式进行介绍，如图7所示，例如可以设置有异常标识和场景的多种对应关系。

假设当前的项目a是用于根据条件筛选合适的房源，在图7中针对项目a示例性的列举出了8种场景。

其中，场景一为常量变更，其对应的异常标识比如说可以为异常标识1，本实施例中的异常标识通常为字符串，则异常标识1比如说可以是“title is wrong”，那么在确定某个测试用例对应的异常标识为“title is wrong”时，则可以确定当前匹配的场景为场景一“常量变更”。

以及，场景二为服务挂掉(panic)，其对应的异常标识比如说可以为异常标识2，异常标识2比如说可以是“HTTP Error 500”，那么在确定某个测试用例对应的异常标识为“HTTP Error 500”时，则可以确定当前匹配的场景为场景二“服务挂掉”。

以及，场景三为大量请求被拒绝，其对应的异常标识比如说可以为异常标识3，异常标识3比如说可以是“connection refused”，那么在确定某个测试用例对应的异常标识为“connection refused”时，则可以确定当前匹配的场景为场景三“大量请求被拒绝”。

以及，场景四为无召回，其对应的异常标识比如说可以为异常标识4，异常标识4比如说可以是“housing_resources is empty”，那么在确定某个测试用例对应的异常标识为“housing_resources is empty”时，则可以确定当前匹配的场景为场景四“无召回”。

以及，场景五为推荐态异常，其对应的异常标识比如说可以为异常标识5，异常标识5比如说可以是“wrong rec_flag_type”，那么在确定某个测试用例对应的异常标识为“wrong rec_flag_type”时，则可以确定当前匹配的场景为场景五“推荐态异常”。

以及，场景六为召回价格异常，其对应的异常标识比如说可以为异常标识6，异常标识6比如说可以是“wrong price”，那么在确定某个测试用例对应的异常标识为“wrongprice”时，则可以确定当前匹配的场景为场景六“召回价格异常”。

以及，场景七为召回时间异常，其对应的异常标识比如说可以为异常标识7，异常标识7比如说可以是“wrong commuting_time”，那么在确定某个测试用例对应的异常标识为“wrong commuting_time”时，则可以确定当前匹配的场景为场景七“召回时间异常”。

以及，场景八为房源小区类型异常，其对应的异常标识比如说可以为异常标识8，异常标识8比如说可以是“wrong data_type”，那么在确定某个测试用例对应的异常标识为“wrong data_type”时，则可以确定当前匹配的场景为场景八“房源小区类型异常”。

以及，还可以存在其他多种可能的场景，具体的场景的设置，以及场景所对应的异常标识均可以根据实际需求进行选择。

同时，本实施例中针对每一个场景，还可以设置其对应的标注编码，标注编码可以测试报告中一起返回给目标设备，这样的话，相应的操作人员通过查看标注编码，就可以快速的确定当前的异常场景是哪一个。

同时，还需要说明，上述介绍的异常标识，例如可以存储在测试用例所对应的日志数据中，其可以是测试用例的日志数据中的某一个字段，其可以是测试用例所预设的对应的标识，用于指示当前的测试用例失败时所反映的异常情况。或者还可以是运行第一代码后第一代码返回的标识，本实施例对此不做限制，其可以根据实际需求进行选择和设置。

以及基于上述介绍可以确定的是，仅仅通过确定异常标识是无法直观的表达出当前的异常情况的，因此还需要确定异常标识所对应的目标场景，从而快速直观的确定当前具体发生了什么样的异常情况。

S307、根据目标场景、目标测试用例以及第一代码，向目标设备发送测试报告，其中，测试报告中包括目标测试用例在第一代码中覆盖的语句。

在确定目标场景之后，本实施例中就可以根据目标场景、目标测试用例以及第一代码，向目标设备发送测试报告。

其中，测试报告中包括目标测试用例在第一代码中覆盖的语句。以及，在可能的实现方式中，本实施例中的测试报告还例如可以包括如下中的至少一种：测试报告中还包如下中的至少一种：目标测试用例的标识、目标测试用例的运行信息、目标场景的标识、目标测试用例对应的异常标识。

其中，目标测试用例的运行信息中，比如说可以包括目标测试用例的输入信息、目标测试用例的预期输出、目标测试用例的实际输出、目标测试用例的运行日志数据、目标测试用例的调试(debug)信息等等，本实施例对目标测试用例的运行信息不做限制，凡是与目标测试用例的运行相关的信息，均可以作为本实施例中的运行信息。

以及，在测试报告中所包括的信息，比如说还可以包括，测试的第一代码所属的分支(branch)、提交第一代码的操作人员的名单、等等，本实施例对测试报告的具体实现同样不做限制，其可以根据实际需求进行选择和设置。

本公开实施例提供的代码测试方法，通过预设的测试用例对第一代码进行线下测试，得到各个测试用例的第一测试结果，并且在针对第一代码的测试中存在失败的测试用例时，同时通过预设的测试用例对第二代码进行线上测试的，得到各个测试用例的第二测试结果，之后根据第一测试结果和第二测试结果，确定针对第一代码的测试和第二代码的测试的测试结果存在差集的目标测试用例，也就是说目标测试用例针对第一代码的测试是失败的，而针对第二代码的测试是成功的，从而可以从多个失败的测试用例中，初步的筛选出因为代码的迭代而导致失败的测试用例，并且之后针对筛选出的目标测试用例，确定其对应的目标场景，并生成对应的测试报告，从而可以有效的实现对第一代码的自动化测试，并且可以有效的降低代码测试的工作量，进一步的提升代码测试的效率，减少代码测试的耗时。

在上述实施例介绍的内容的基础上，本公开提供的代码测试方法，在不同的目标场景下，生成测试报告的处理逻辑是不同的，因此下面结合图示，对几种不同类型的目标场景下，生成测试报告的实现方式进行介绍。

首先结合图8对第一类型的场景下生成测试报告的实现进行介绍，图8为本公开实施例介绍的生成测试报告的实现示意图一。

如图8所示，第一类型的场景比如说可以包括：根据查询条件返回的结果为空。

其中，查询条件例如可以是测试用例中的输入数据中预设的查询条件，第一代码在根据查询条件进行相应的查询之后，返回的结果为空，那么也就是说实际输出为空，因为在测试用例中存在预设输出，预设输出是不为空的，因此可以确定当前的目标测试用例的测试结果为失败。

如图8所示，若确定当前的目标场景为根据查询条件返回的结果为空，也就是上述示例中介绍的场景四，则例如可以首先获取测试用例的输入数据中的用户标识，之后在日志数据中获取该用户标识所对应的召回数据和过滤数据，其中，召回数据是根据查询条件所召回的多个结果，而过滤数据是根据相应的过滤条件在召回数据中所过滤掉的结果。那么可以理解的是，召回数据和过滤数据的差集实际上就是第一代码返回的结果。在确定召回数据、过滤数据以及返回的结果之后，可以对这些信息进行暂存，以在后续的测试报告中返回给相应的设备。

以及，针对返回的结果为空的这种异常情况，本实施例中还可以获取当前的目标测试用例所覆盖的第一目标语句，并且判断在第一目标语句中是否对过滤条件或者召回条件进行了更新。

在一种可能的实现方式中，若确定在第一目标语句中对召回条件或者过滤条件进行了更新，则可以确定当前的目标测试用例的失败是符合预期的，也就是说可以确定是因为第一目标语句的更新，进而导致的目标测试用例的失败。

但是进一步的，此处第一目标语句的更新导致的目标测试用例的失败，有可能存在一下两种情况：

情况一、更新后的代码本身的编写有问题，比如说是代码逻辑上的问题，也有可能是代码编写的时候出现函数错误、输入错误等等；

情况二、能更新后的代码本身的编写没有问题，也就是说当前确定第一代码就是要进行这样的更新，当前的第一代码返回的结果为空是正常的，那么这种情况下目标测试用例的数据就应该进行更新了。

为了区分到底是上述的哪一种情况，本实施例中比如说可以向rd对应的通信接口发送确认信息，由rd目标测试用例覆盖的第一目标语句是否存在编写问题，在接收到rd返回的确认信息之后。

若确认信息是异常确认信息，则表示rd确定当前的目标测试用例所覆盖的第一目标语句是编写有问题，那么在这种情况下，就可以向目标设备发送测试报告，在测试报告中除上述介绍的内容之外，比如说还可以包括rd返回的异常确认信息、召回数据、过滤数据以及返回的结果、等等。

或者，若确认信息是正常确认信息，则表示rd确定当前的目标测试用例所覆盖的第一目标语句不存在编写问题，也就是说当前的第一代码返回的结果为空是正常的，那么这种情况下，比如说可以对目标测试用例的测试结果进行干预，将目标测试用例的测试结果修改为成功，并向目标设备发送测试报告，在测试报告中还可以包括指示信息，其中，指示信息用于指示对目标测试用例的结果进行了修改。

在另一种可能的实现方式中，若确定第一目标语句中未对过滤条件以及召回条件进行更新，则可以确定是在原来的过滤条件和召回条件的基础上，出现了返回的结果为空的情况，这种情况可以确定是不符合预期的，因此可以确定是代码故障(bug)，可以直接向目标设备发送测试报告。

上述介绍了第一类型的场景的一种可能的实现方式，本实施例中的第一类型的场景，可以描述为，可以确定第一代码中的相应语句发生更新，但是无法确定语句的更新是否为想要的更新，需要进行进一步的判断。

其次，结合图9对第二类型的场景下生成测试报告的实现进行介绍，图9为本公开实施例介绍的生成测试报告的实现示意图二。

如图9所示，第二类型的场景包括如下中的至少一种：根据查询条件返回的结果数量小于预设数量、根据查询条件返回的结果不满足查询条件、返回常量与预期常量不同。

参照图9，若确定当前的目标场景为根据查询条件返回的结果数量小于预设数量，也就是上述示例中介绍的场景五，根据查询条件返回的结果数量小于预设数量，比如说正常应该返回4个推荐结果，但是当前只返回了一个推荐结果。

针对这种情况，可以判断返回的第一个结果是否为预设类型，因为在本实施例中的设计中，若返回的第一个结果为预设类型，则根据查询条件返回的结果数量小于预设数量是正常的。

示例性的，比如说当前的项目是用于根据输入条件查询合适房源的项目，则预设类型比如说可以是无房源小区，那么比如说如果返回的第一个为无房源小区，则根据查询条件查询得到的房源结果的数量不满足预设数量4个是正常的，这种情况下，返回的房源数量通常只有1个。

因此在一种可能的实现方式中，若确定返回的第一个结果为预设类型，则可以确定当前的目标测试用例的实际输出是没有问题的，因此可以对目标测试用例的测试结果进行干预，将目标测试用例的测试结果修改为成功，并向目标设备发送测试报告，在测试报告中还可以包括第二指示信息，其中，第二指示信息用于指示对目标测试用例的结果进行了修改。

以及在另一种可能的实现方式中，若确定返回的第一个结果不是预设类型，那么可以确定当前的根据查询条件返回的结果数量小于预设数量是不正常的，也就是说确定目标测试用例确实是失败的结果，则可以直接向目标设备发送测试报告。

以及参照图9，若确定当前的目标场景为返回常量与预期常量不同，也就是上述示例中介绍的场景一，比如说一些常量信息“非暂无相关结果，为您推荐条件相似的小区及房源”不符合预期，其中具体的常量信息可以根据实际需求进行确定。

针对这种情况，可以获取目标测试用例在第一代码中所覆盖的第二目标语句，在第二目标语句中就包括上述待返回的预设常量，则可以判断返回常量与第二目标语句中的预设常量是否相同。

在一种可能的实现方式中，若确定返回常量与第二目标语句中的预设常量相同，则表示当前的返回常量的输出是没有问题的，有可能是第二目标语句中的预设常量发生了更新，从而导致返回常量和预期常量不相同。因此针对这种情况，可以对目标测试用例的测试结果进行干预，将目标测试用例的测试结果修改为成功，并向目标设备发送测试报告，在测试报告中还可以包括第二指示信息，其中，第二指示信息用于指示对目标测试用例的结果进行了修改。

以及在另一种可能的实现方式中，若确定返回常量与第二目标语句中的预设常量不相同，则表示当前的返回常量不是因为第二目标语句的更新，才和预期常量不同的，那么可以确定当前的返回常量于预期常量不同本身就是异常的，也就是说确定目标测试用例确实是失败的结果，则可以直接向目标设备发送测试报告。

以及参照图9，若确定当前的目标场景为根据查询条件返回的结果不满足查询条件，也就是上述示例中介绍的场景六以及场景七，比如说针对召回价格异常，就是说根据输入条件召回的房源不是输入条件中的选择价格范围内的；以及比如说针对召回时间异常，就是说根据输入条件召回的房源不是输入条件中的选择时间范围内的。

针对这种情况，可以获取目标测试用例在第一代码中所覆盖的第二目标语句，在第二目标语句中就包括上述召回的具体处理逻辑，在召回处理中存在一种类型叫做多方案召回，其中多方案召回是指在输入条件的基础上，选择多种类型的结果进行召回。

比如说当前的输入条件是价格在5000元一类，通勤时间在20分钟以内，基于这个条件进行房源的筛选。而多方案召回就是指，在价格5000元和通勤时间20分钟以内的基础上，可以的交通方式包括步行、驾车、打车、公共交通、等等多种出行方式，结合这些交通方式在价格5000元和通勤时间20分钟的基础上，筛选出满足条件的房源。

因此本实施例中在获取测试用例所覆盖的第二目标语句之后，可以判断第二目标语句中是否为多方案召回。

在一种可能的实现方式中，若第二目标语句中为多方案召回，则可以进一步确定在第二目标语句中的召回预值是否发生变更，其中召回预值比如说就可以包括上述介绍的：驾车、公共交通、步行、等等。其中召回预值的设置是可以根据实际的场景和需求进行设计的，只要其可以保证针对返回结果的筛选设置了多种可能的方案即可。

其中，若确定第二目标语句中的召回预值发生了变更，则可以确定当前的查询条件返回的结果不满足查询条件，是因为召回预值的变更所导致的。比如说原先的召回预值设置的是公共交通和步行，之后召回预值发生了变化，变成了公共交通和驾车。可以理解，步行20分钟内到达的房源和驾车20分钟内到达的房源必然是不同的，因此会导致当前返回的实际结果和预期结果不同(预期结果是根据原来的召回预值设置的)，从而会导致当前的目标测试用例的测试结果为失败。因此针对这种情况，就需要对目标测试用例的测试结果进行干预，将目标测试用例的测试结果修改为成功，并向目标设备发送测试报告，在测试报告中还可以包括第二指示信息，其中，第二指示信息用于指示对目标测试用例的结果进行了修改。

在另一种可能的实现方式中，若第二目标语句中不是多方案召回，那么就表明当前的根据查询条件所返回的结果一定要是满足查询条件的，这样才是正常的现象，因此针对这种情况，可以确定当前目标测试用例的测试结果就是失败的，之后可以直接向目标设备发送测试报告。

基于上述介绍可以确定的是，针对第二类型的场景，在确定返回结果与第二目标语句相匹配时，可以对目标测试用例的结果进行干预；在返回结果与第二目标语句不匹配时，可以直接发送测试报告。

其中，返回结果与第二目标语句相匹配，是指返回结果满足第二目标语句对应的输出，也就是说按照当前的第二目标语句进行结果的输出的话，输出的正是当前的返回结果。

其次，结合图10对第三类型的场景下生成测试报告的实现进行介绍，图10为本公开实施例介绍的生成测试报告的实现示意图三。

如图10所示，第三类型的场景包括如下中的至少一种：被拒绝的请求的数量大于预设阈值、服务失败。

参照图10，若确定当前的目标场景为被拒绝的请求的数量大于预设阈值，也就是上述示例中介绍的场景三，大量请求被拒绝，则可以直接确定服务异常，进而向目标设备发送测试报告。这种情况下在发送测试报告时，比如说是向负责qa的相关人员发送测试报告。

以及，参照图10，若确定当前的目标场景为服务失败(panic)，也就是上述示例中介绍的场景二，则可以直接确定第一代码bug，进而向目标设备发送测试报告。这种情况下在发送测试报告时，比如说是向负责rd的相关人员发送测试报告。

上述介绍了在不同的场景下，生成并发送测试报告的几种不同的实现方式，以及在一种可能的实现方式中，上述介绍的测试报告中所包括的目标测试用例的运行信息，例如可以是在存储在目标链接中。

比如说在确定上述介绍的各种信息之后，可以确定目标测试用例和目标场景之间的对应关系，之后生成目标测试用例和目标场景之间的对应关系的目标链接，通过打开目标链接，可以获取到目标测试用例和目标场景之间的对应关系，以及目标测试用例的运行信息。

在测试报告中，测试报告的标题比如说可以包括：第一代码所属的分支、失败的目标测试用例的标识、目标场景、发现问题的阶段、触发人员，例如：触发branch(master)_失败case(:search_house_zhengzhou_walk”)_上报问题的场景(服务panic)_发现问题阶段(准入阶段)_触发者(xx)，以及在具体的任务结果回传中，比如说可以展示如下信息：

“xx，租房自动化case失败1个，部署的分支＝xique-407。无因为数据失败导致的case，全部属于自身项目导致的失败，失败case和业务场景的对应关系详见：aaa.html”，其中，aaa.html就是目标链接，相关的操作人员通过打开目标链接，就可以查看相关的测试报告的内容。

本实施例中对测试报告的具体实现方式不做限制，只要在测试报告中可以包括上述介绍的相关内容即可，其具体的展示方式可以根据实际需求进行选择和设置。

基于上述介绍可以确定的是，本实施例中针对不同的场景，设置有各自对应的生成以及发送测试报告的逻辑，从而可以针对多种不同的情况，全面且快速的实现测试报告的自动触发生成、自动发送、自动定位代码异常位置，从而可以快速有效的实现对第一代码的测试，有效的缩短了代码测试的耗时。

以及本公开提供的代码测试方法中，还针对代码的提交(marge)进行了监测，在监测到代码的提交的时候，可以自动的触发代码对应的环境的配置，之后基于配置的环境自动的执行上述介绍的代码测试过程，从而可以有效的实现代码测试的全过程均自动触发，进一步的降低了人工干预的程度，缩短了代码测试的耗时。

在上述介绍内容的基础上，下面可以结合图11对本公开提供的代码测试方法的整体实现流程进行进一步的介绍，图11为本公开实施例提供的代码测试方法的流程示意图。

如图11所示，本实施例提供的代码测试方法中，可以自动的实现对代码分支的监听，也就是说监测提交的代码，在监测到提交的代码之后，可以自动的实现环境的部署。其中监听分支和环境部署的具体实现，也可以理解为图11中所示的代码提交、编译产出、代码扫描、代码发布的步骤。

在部署完环境之后，就可以进行代码的测试了，基于多个预设测试用例对第一代码进行测试，之后进行测试用例的定位。

在测试用例定位中，首先可以进行初判策略，在初判策略中，可以确定的线上测试(对应第二代码)和线下测试(对应第一代码)的交集。此处确定的交集对应上述介绍的三种情况。

第一种情况是线上测试和线下测试的失败case完全不同，交集为空，在这种情况下可以确定失败case是项目导致的，需要在后续的场景定位中再进行具体处理。

第二种情况是线上测试和线下测试的失败case完全相同，交集就是线下测试的失败case，在这种情况下可以确定失败case并不是项目导致的，则可以对失败case的测试结果进行干预。

第三种情况是线上测试和线下测试的失败case存在部分相同，还有部分不相同，则可以确定不相同的差集部分是项目导致的，之后针对不相同的差集部分进行后续的场景定位的处理。

上述介绍的内容的定位中，需要进行场景定位的处理的失败case，实际上就上述实施例中介绍的目标测试用例，之后通过确定目标测试用例所对应的目标场景，并依据不同的场景所对应的处理逻辑进行相应的处理，以生成场景定位的测试报告。

在生成测试报告之后，就可以进行结果通知，也就是将测试报告发送给目标设备，在结果通知中可以自动标注代码中的异常位置，并自动上报给相应的通信接口，从而可以最大程度的实现代码测试的自动化处理。

综上所述，本公开提供的代码测试方法，采用微测试的思路，能够对变更代码给予实时测试并实时反馈，且针对异常场景能够给出辅助定位信息，解决排查耗时久的问题。结合场内流水线的自动监听机制，监听代码变更，自动触发部署和场景回归，解决人为参与的过程，做到触发无感知；另增加了场景回归后的辅助定位能力，降低人工排查的时间投入，并自动上报异常问题；且自动测试完成之后自动将结果实时回传给代码修改的同学，达到微测试闭环。

图12为本公开实施例的代码测试装置的结构示意图。如图12所示，本实施例的代码测试装置1200可以包括：处理模块1201、确定模块1202、获取模块1203、发送模块1204。

处理模块1201，用于根据至少一个测试用例对第一代码进行测试，得到各所述测试用例各自的第一测试结果，其中，所述第一代码为待上线的代码；

确定模块1202，用于根据所述至少一个测试用例以及各所述测试用例的第一测试结果，确定目标测试用例，其中，所述目标测试用例的第一测试结果为失败；

获取模块1203，用于获取所述目标测试用例对应的异常标识，并确定与所述异常标识匹配的目标场景；

发送模块1204，用于根据所述目标场景、所述目标测试用例以及所述第一代码，向目标设备发送测试报告，其中，所述测试报告中包括所述目标测试用例在所述第一代码中覆盖的语句。

一种可能的实现方式中，所述确定模块1202具体用于：

根据所述至少一个测试用例对第二代码进行测试，得到各所述测试用例各自的第二测试结果，其中，所述第二代码为已上线的代码；

将所述第一测试结果为失败的测试用例确定为第一测试用例，以及，将所述第二测试结果为失败的测试用例确定为第二测试用例；

根据所述第一测试用例和所述第二测试用例，确定目标测试用例。

一种可能的实现方式中，所述确定模块1202具体用于：

将所述第一测试用例和所述第二测试用例的交集部分，确定为第三测试用例；

将所述第一测试用例中，除所述第三测试用例之外的测试用例，确定为所述目标测试用例。

一种可能的实现方式中，所述处理模块1201还用于：

在将所述第一测试用例和所述第二测试用例的交集部分，确定为第三测试用例之后，将所述第三测试用例的第一测试结果修改为成功，并向目标设备发送测试报告，其中，所述测试报告中还包括第一指示信息，其中，所述第一指示信息用于指示对所述第三测试用例的结果进行了修改。

一种可能的实现方式中，所述发送模块1204具体用于：

若所述目标场景为第一类型，则获取所述目标测试用例在所述第一代码中覆盖的第一目标语句；

若所述第一目标语句中对过滤条件或者召回条件进行了更新，则在接收到针对所述更新的过滤条件或者召回条件的异常确认信息之后，向目标设备发送测试报告；

若所述第一目标语句中未对过滤条件以及召回条件进行更新，则直接向目标设备发送测试报告；

其中，所述第一类型的场景包括如下中的至少一种：根据查询条件返回的结果为空。

一种可能的实现方式中，所述发送模块1204具体用于：

若所述目标场景为第二类型，则获取所述目标测试用例在所述第一代码中覆盖的第二目标语句；

获取所述目标测试用例对应的返回结果；

根据所述返回结果和所述目标语句，向目标设备发送测试报告；

其中，所述第二类型的场景包括如下中的至少一种：根据查询条件返回的结果数量小于预设数量、根据查询条件返回的结果不满足所述查询条件、返回常量与预期常量不同。

一种可能的实现方式中，所述发送模块1204具体用于：

若所述返回结果与所述第二目标语句相匹配，则将所述目标测试用例的结果修改为成功，并向目标设备发送测试报告，其中，所述测试报告中还包括第二指示信息，其中，所述第二指示信息用于指示对所述目标测试用例的结果进行了修改。

若所述返回结果与所述第二目标语句不匹配，则直接向目标设备发送测试报告。

一种可能的实现方式中，所述发送模块1204具体用于：

若所述目标场景为第三类型，则直接向所述目标设备发送测试报告；

其中，所述第三类型的场景包括如下中的至少一种：被拒绝的请求的数量大于预设阈值、服务失败。

一种可能的实现方式中，所述测试报告中还包括如下中的至少一种：所述目标测试用例的标识、所述目标测试用例的运行信息、所述目标场景的标识、所述目标测试用例对应的异常标识。

本公开提供一种代码测试方法及装置，应用于计算机技术中的代码测试领域，以达到缩短代码测试的耗时的目的。

需要说明的是，本实施例中的人头模型并不是针对某一特定用户的人头模型，并不能反映出某一特定用户的个人信息。需要说明的是，本实施例中的二维人脸图像来自于公开数据集。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

根据本公开的实施例，本公开还提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。

图13示出了可以用来实施本公开的实施例的示例电子设备1300的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图13所示，设备1300包括计算单元1301，其可以根据存储在只读存储器(ROM)1302中的计算机程序或者从存储单元1308加载到随机访问存储器(RAM)1303中的计算机程序，来执行各种适当的动作和处理。在RAM 1303中，还可存储设备1300操作所需的各种程序和数据。计算单元1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

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

计算单元1301可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1301的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1301执行上文所描述的各个方法和处理，例如代码测试方法。例如，在一些实施例中，代码测试方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1308。在一些实施例中，计算机程序的部分或者全部可以经由ROM1302和/或通信单元1309而被载入和/或安装到设备1300上。当计算机程序加载到RAM 1303并由计算单元1301执行时，可以执行上文描述的代码测试方法的一个或多个步骤。备选地，在其他实施例中，计算单元1301可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行代码测试方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、复杂可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (21)

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

根据至少一个测试用例对第一代码进行测试，得到各所述测试用例各自的第一测试结果，其中，所述第一代码为待上线的代码；

根据所述至少一个测试用例以及各所述测试用例的第一测试结果，确定目标测试用例，其中，所述目标测试用例的第一测试结果为失败；

获取所述目标测试用例对应的异常标识，并确定与所述异常标识匹配的目标场景；

根据所述目标场景、所述目标测试用例以及所述第一代码，向目标设备发送测试报告，其中，所述测试报告中包括所述目标测试用例在所述第一代码中覆盖的语句。

2.根据权利要求1所述的方法，其中，根据所述至少一个测试用例以及各所述测试用例的第一测试结果，确定目标测试用例，包括：

根据所述至少一个测试用例对第二代码进行测试，得到各所述测试用例各自的第二测试结果，其中，所述第二代码为已上线的代码；

将所述第一测试结果为失败的测试用例确定为第一测试用例，以及，将所述第二测试结果为失败的测试用例确定为第二测试用例；

根据所述第一测试用例和所述第二测试用例，确定目标测试用例。

3.根据权利要求2所述的方法，其中，根据所述第一测试用例和所述第二测试用例，确定目标测试用例，包括：

将所述第一测试用例和所述第二测试用例的交集部分，确定为第三测试用例；

将所述第一测试用例中，除所述第三测试用例之外的测试用例，确定为所述目标测试用例。

4.根据权利要求3所述的方法，将所述第一测试用例和所述第二测试用例的交集部分，确定为第三测试用例之后，所述方法还包括：

将所述第三测试用例的第一测试结果修改为成功，并向目标设备发送测试报告，其中，所述测试报告中还包括第一指示信息，其中，所述第一指示信息用于指示对所述第三测试用例的结果进行了修改。

5.根据权利要求1-4任一项所述的方法，其中，根据所述目标场景、所述目标测试用例以及所述第一代码，向目标设备发送测试报告，包括：

若所述目标场景为第一类型，则获取所述目标测试用例在所述第一代码中覆盖的第一目标语句；

若所述第一目标语句中对过滤条件或者召回条件进行了更新，则在接收到针对所述更新的过滤条件或者召回条件的异常确认信息之后，向目标设备发送测试报告；

若所述第一目标语句中未对过滤条件以及召回条件进行更新，则直接向目标设备发送测试报告；

其中，所述第一类型的场景包括如下中的至少一种：根据查询条件返回的结果为空。

6.根据权利要求1-4任一项所述的方法，其中，根据所述目标场景以及所述第一代码，向目标设备发送测试报告，包括：

若所述目标场景为第二类型，则获取所述目标测试用例在所述第一代码中覆盖的第二目标语句；

获取所述目标测试用例对应的返回结果；

根据所述返回结果和所述目标语句，向目标设备发送测试报告；

其中，所述第二类型的场景包括如下中的至少一种：根据查询条件返回的结果数量小于预设数量、根据查询条件返回的结果不满足所述查询条件、返回常量与预期常量不同。

7.根据权利要求6所述的方法，其中，根据所述返回结果和所述目标语句，向目标设备发送测试报告，包括：

若所述返回结果与所述第二目标语句相匹配，则将所述目标测试用例的结果修改为成功，并向目标设备发送测试报告，其中，所述测试报告中还包括第二指示信息，其中，所述第二指示信息用于指示对所述目标测试用例的结果进行了修改；

若所述返回结果与所述第二目标语句不匹配，则直接向目标设备发送测试报告。

8.根据权利要求1-4任一项所述的方法，其中，根据所述目标场景以及所述第一代码，向目标设备发送测试报告，包括：

若所述目标场景为第三类型，则直接向所述目标设备发送测试报告；

其中，所述第三类型的场景包括如下中的至少一种：被拒绝的请求的数量大于预设阈值、服务失败。

9.根据权利要求1-8任一项所述的方法，所述测试报告中还包括如下中的至少一种：所述目标测试用例的标识、所述目标测试用例的运行信息、所述目标场景的标识、所述目标测试用例对应的异常标识。

10.一种代码测试装置，包括：

处理模块，用于根据至少一个测试用例对第一代码进行测试，得到各所述测试用例各自的第一测试结果，其中，所述第一代码为待上线的代码；

确定模块，用于根据所述至少一个测试用例以及各所述测试用例的第一测试结果，确定目标测试用例，其中，所述目标测试用例的第一测试结果为失败；

获取模块，用于获取所述目标测试用例对应的异常标识，并确定与所述异常标识匹配的目标场景；

发送模块，用于根据所述目标场景、所述目标测试用例以及所述第一代码，向目标设备发送测试报告，其中，所述测试报告中包括所述目标测试用例在所述第一代码中覆盖的语句。

11.根据权利要求10所述的装置，其中，所述确定模块具体用于：

根据所述至少一个测试用例对第二代码进行测试，得到各所述测试用例各自的第二测试结果，其中，所述第二代码为已上线的代码；

将所述第一测试结果为失败的测试用例确定为第一测试用例，以及，将所述第二测试结果为失败的测试用例确定为第二测试用例；

根据所述第一测试用例和所述第二测试用例，确定目标测试用例。

12.根据权利要求11所述的装置，其中，所述确定模块具体用于：

将所述第一测试用例和所述第二测试用例的交集部分，确定为第三测试用例；

将所述第一测试用例中，除所述第三测试用例之外的测试用例，确定为所述目标测试用例。

13.根据权利要求12所述的装置，所述处理模块还用于：

在将所述第一测试用例和所述第二测试用例的交集部分，确定为第三测试用例之后，将所述第三测试用例的第一测试结果修改为成功，并向目标设备发送测试报告，其中，所述测试报告中还包括第一指示信息，其中，所述第一指示信息用于指示对所述第三测试用例的结果进行了修改。

14.根据权利要求10-13任一项所述的装置，其中，所述发送模块具体用于：

若所述目标场景为第一类型，则获取所述目标测试用例在所述第一代码中覆盖的第一目标语句；

若所述第一目标语句中对过滤条件或者召回条件进行了更新，则在接收到针对所述更新的过滤条件或者召回条件的异常确认信息之后，向目标设备发送测试报告；

若所述第一目标语句中未对过滤条件以及召回条件进行更新，则直接向目标设备发送测试报告；

其中，所述第一类型的场景包括如下中的至少一种：根据查询条件返回的结果为空。

15.根据权利要求10-13任一项所述的装置，其中，所述发送模块具体用于：

若所述目标场景为第二类型，则获取所述目标测试用例在所述第一代码中覆盖的第二目标语句；

获取所述目标测试用例对应的返回结果；

根据所述返回结果和所述目标语句，向目标设备发送测试报告；

其中，所述第二类型的场景包括如下中的至少一种：根据查询条件返回的结果数量小于预设数量、根据查询条件返回的结果不满足所述查询条件、返回常量与预期常量不同。

16.根据权利要求15所述的装置，其中，所述发送模块具体用于：

若所述返回结果与所述第二目标语句相匹配，则将所述目标测试用例的结果修改为成功，并向目标设备发送测试报告，其中，所述测试报告中还包括第二指示信息，其中，所述第二指示信息用于指示对所述目标测试用例的结果进行了修改；

若所述返回结果与所述第二目标语句不匹配，则直接向目标设备发送测试报告。

17.根据权利要求10-13任一项所述的装置，其中，所述发送模块具体用于：

若所述目标场景为第三类型，则直接向所述目标设备发送测试报告；

其中，所述第三类型的场景包括如下中的至少一种：被拒绝的请求的数量大于预设阈值、服务失败。

18.根据权利要求10-17任一项所述的装置，所述测试报告中还包括如下中的至少一种：所述目标测试用例的标识、所述目标测试用例的运行信息、所述目标场景的标识、所述目标测试用例对应的异常标识。

19.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-9中任一项所述的方法。

20.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-9中任一项所述的方法。

21.一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现权利要求1-9中任一项所述方法的步骤。

Images