CN116662203A - 测试方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请涉及金融科技领域，公开了一种测试方法、装置、计算机设备及存储介质，包括：运行第一测试脚本对被测代码进行第一测试；监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据；根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数；根据目标数据生成第二测试脚本；运行第二测试脚本对被测代码进行第二测试，得到测试结果。本申请先通过第一测试脚本从整体层面对被测代码进行初步测试，再运行第二测试脚本对被测代码进行局部、有针对性、细粒度测试，可以覆盖更多的测试场景和代码，对被测代码进行更全面地充分测试，减少漏测，发现初步测试中未发现的隐藏问题，提高代码测试质量。

Description

测试方法、装置、计算机设备及存储介质

技术领域

本申请涉及软件测试及金融科技技术领域，尤其涉及一种测试方法、装置、计算机设备及存储介质。

背景技术

软件测试的目的是确定应用程序的某些功能是否可正常工作，并且达到程序所设计的结果，以便测试某个程序路径或核实是否满足某个特定需求。为提高测试效率，自动测试已取得大力发展。但是传统测试方案往往只覆盖常规的测试场景，无法覆盖全面和复杂的测试场景，且代码覆盖率无法保证。尤其对于金融科技领域，例如在银行线上业务快速发展，开放银行业务增长迅速的环境下，新产品/系统上架、产品/系统内容变更频繁，面对巨量的代码迭代更新，代码测试量较大，传统的代码测试效率和覆盖率难以满足需求。

发明内容

本申请的主要目的在于提供一种测试方法、装置、计算机设备及存储介质，可以解决现有技术中的无法全面覆盖测试场景和代码的技术问题。

为实现上述目的，本申请第一方面提供一种测试方法，该方法包括：

运行第一测试脚本对被测代码进行第一测试；

监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据；

根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数；

根据目标数据生成第二测试脚本；

运行第二测试脚本对被测代码进行第二测试，得到测试结果。

为实现上述目的，本申请第二方面提供一种测试装置，该装置包括：

第一运行模块，用于运行第一测试脚本对被测代码进行第一测试；

第一运行监测模块，用于监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据；

提取模块，用于根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数；

脚本生成模块，用于根据目标数据生成第二测试脚本；

第二运行模块，用于运行第二测试脚本对被测代码进行第二测试，得到测试结果。

为实现上述目的，本申请第三方面提供一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时，使得处理器执行以下步骤：

运行第一测试脚本对被测代码进行第一测试；

监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据；

根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数；

根据目标数据生成第二测试脚本；

运行第二测试脚本对被测代码进行第二测试，得到测试结果。

为实现上述目的，本申请第四方面提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行以下步骤：

运行第一测试脚本对被测代码进行第一测试；

监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据；

根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数；

根据目标数据生成第二测试脚本；

运行第二测试脚本对被测代码进行第二测试，得到测试结果。

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

本申请通过第一测试脚本从整体层面对被测代码进行初步测试，然后根据第一测试的覆盖率数据从被测代码中提取出目标数据，根据目标数据生成第二测试脚本，运行第二测试脚本对被测代码进行局部、有针对性、细粒度测试，可以覆盖更多的测试场景和代码，更全面地覆盖应用程序的不同路径和边界条件，提高测试覆盖率，对被测代码进行更全面地充分测试，减少漏测，发现初步测试中未发现的隐藏问题，提高测试效率和代码测试质量。尤其对于金融科技领域，例如在银行线上业务快速发展，开放银行业务增长迅速的环境下，新产品/系统上架、产品/系统内容变更频繁，面对巨量的代码迭代更新，代码测试量较大，本申请可以对巨量的金融科技应用程序的代码进行更全面测试，准确发现代码错误和缺陷，提高代码测试效率和覆盖率，满足金融金融领域的测试需求。

附图说明

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

其中：

图1为本申请实施例中测试方法的流程图；

图2为本申请实施例中测试装置的结构框图；

图3为本申请实施例中计算机设备的结构框图。

具体实施方式

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

本申请的测试方法应用于计算机设备中，计算机设备可以是终端或服务器。终端具体可以是台式终端或移动终端，移动终端具体可以是手机、平板电脑、笔记本电脑等中的至少一种。服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

如图1所示，在一个实施例中，提供了一种测试方法。该方法既可以应用于终端，也可以应用于服务器。该测试方法具体包括如下步骤：

S100：运行第一测试脚本对被测代码进行第一测试。

具体地，第一测试脚本是根据第一测试用例编写的。

测试用例是一个文档，是对一项特定的软件产品进行测试任务的描述，包括测试步骤、输入数据和期望的结果，其目的是确定应用程序的某个功能是否可正常工作，并且达到程序所设计的结果，以便测试某个程序路径或核实是否满足某个特定需求。测试用例是测试脚本的设计规格说明，测试脚本的设计依据测试用例。

例如，测试应用程序的“登录”功能，测试步骤为：输入用户账号和密码，点击“登录”按钮。其中，用户账号和密码的参数取值是输入数据。不同的输入数据，期望的结果可能不同。

在第一测试脚本中用户账号和密码的参数取值可以是固定值。在另一个具体实施例中，第一测试脚本中用户账号和密码中的至少一个为变量，由测试人员随机给定变量的输入数据，这样可以使用不同的输入数据对登录功能进行多次不同测试，以检测登录功能的各种状况。测试用例预期的结果也可以由测试人员定义，并提供给计算机设备。

本实施例通过自动化测试来运行第一测试脚本。运行第一测试脚本时会执行被测代码。被测代码中的有些语句可能被执行，有些语句可能未被执行。

另外，可以使用不同的测试框架来实现测试脚本的运行，例如使用JUnit、TestNG来运行测试脚本。当然，具体根据实际情况配置，本申请对此不作限制。

S200：监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据。

具体地，利用覆盖率工具来监测运行第一测试时被测代码的执行状况，采集分析得到第一覆盖率数据。覆盖率工具例如可以为Jacoco插件，本申请对此不做限制。

第一覆盖率数据例如可以包括语句覆盖率、分支覆盖率、方法覆盖率、类覆盖率、行覆盖率等其中的一种或多种。

语句覆盖率(Statement Coverage)：表示代码中每个语句被执行的次数。

分支覆盖率(Branch Coverage)：表示代码中每个条件语句的每个分支被执行的次数。

方法覆盖率(Method Coverage)：表示代码中每个方法被调用的次数。

类覆盖率(Class Coverage)：表示代码中每个类被使用的次数。

行覆盖率(Line Coverage)：表示代码中每行被执行的次数。

S300：根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数。

具体地，对第一覆盖率数据进行解析，生成覆盖率报告。在一个具体实施例中，覆盖率工具将收集的第一覆盖率数据存储在一个二进制文件中，使用覆盖率工具提供的分析工具来解析这个二进制文件，可以生成可视化的覆盖率报告。

生成的覆盖率报告通常是一个详细的报告文件，用于展示被测代码的覆盖情况。覆盖率报告可以以不同的形式存在，如HTML报告、XML报告或文本文件等。报告内容会根据具体的覆盖率工具和配置而有所差异，例如可以包括以下内容：

概览信息：报告的开头通常包含整体的概览信息，如被测代码的总行数、覆盖率统计概览等。

覆盖率统计：报告会给出代码覆盖率的统计数据，包括语句覆盖率、分支覆盖率、方法覆盖率等各个维度的覆盖率数据。这些统计数据可以以表格、图表或其他形式展示。

代码着色：报告会对被测代码进行着色，以区分已被执行代码和未被执行代码。例如已被执行代码使用绿色或其他醒目的颜色标识，未被执行代码使用灰色或其他颜色标识。

代码覆盖细节：报告会提供具体的代码覆盖情况细节，例如哪些代码行被执行、哪些分支被覆盖等。这可以帮助开发人员快速定位到未覆盖的代码部分。

文件和类级别的覆盖率：报告会按照文件和类的层次展示覆盖率数据，使开发人员能够更好地了解每个文件和类的覆盖情况。

具体的覆盖率报告内容和格式可能因使用的覆盖率工具而有所差异，可以根据具体工具的文档来了解报告的具体内容和展示形式。

根据覆盖率报告从被测代码中提取的目标数据可以包括一些隐藏参数，当然也可以包括第一测试脚本中的已知参数。例如，在“登录”这个测试中，测试人员可直接提供“用户账号”和“密码”两个已知参数的输入数据，但是在“登录”这个功能对应的被测代码中可能不仅仅包含“用户账号”和“密码”两个变量或参数，还可能包含一些中间变量或中间参数，这些中间变量或中间参数对于测试人员而言相对比较隐蔽，在现有技术中这些隐藏参数或隐藏变量一般也不被用于编写脚本。

S400：根据目标数据生成第二测试脚本。

具体地，本实施例通过第一测试得到的覆盖率数据和覆盖率报告提取出目标数据，特别是未执行代码中的变量或参数，依据包含隐藏参数或变量的目标数据编写第二测试用例。第二测试用例包括测试步骤、输入数据和期望的结果。测试步骤例如：输入参数1、参数2。输入数据为参数1和参数2的具体参数取值或参数赋值，期望的结果可以是在第一测试中参考1和参数2所对应的代码的输出。

基于第二测试用例生成对应的第二测试脚本。利用第二测试脚本对被测代码中的部分代码(被测子代码)进行有针对性地、细节化测试，可以发现在第一测试中未发现的隐藏问题。

其中，目标数据包括至少一个参数，可以对这些参数进行组合，生成不同的第二测试脚本，第二测试脚本中包括选取的参数。

S500：运行第二测试脚本对被测代码进行第二测试，得到测试结果。

具体地，第二测试脚本中的输入参数的输入数据(即参数取值或参数赋值)可以是在第二测试脚本中配置的固定取值。也可以将第二测试脚本中的输入参数作为变量，在测试过程中给这些输入参数进行不同赋值，以使用不同的测试数据对代码进行相同步骤的测试。

运行不同的第二测试脚本可以对被测代码中的不同子代码进行有针对性的测试，得到对应的测试结果。其中，对同一个第二测试脚本进行不同赋值，可以对同一个子代码进行多次测试。

本实施例可以实现测试脚本的自动化生成和执行，提高测试效率和准确性。

本实施例通过第一测试脚本从整体层面对被测代码进行初步测试，然后根据第一测试的覆盖率数据从被测代码中提取出目标数据，根据目标数据生成第二测试脚本，运行第二测试脚本对被测代码进行局部、有针对性、细粒度测试，可以覆盖更多的测试场景和代码，更全面地覆盖应用程序的不同路径和边界条件，提高测试覆盖率，对被测代码进行更全面地充分测试，减少漏测，发现初步测试中未发现的隐藏问题，提高测试效率和代码测试质量。尤其对于金融科技领域，例如在银行线上业务快速发展，开放银行业务增长迅速的环境下，新产品/系统上架、产品/系统内容变更频繁，面对巨量的代码迭代更新，代码测试量较大，本申请可以对巨量的金融科技应用程序的代码进行更全面测试，准确发现代码错误和缺陷，提高代码测试效率和覆盖率，满足金融金融领域的代码测试需求。

在一个实施例中，步骤S400具体包括：

从目标数据中选取至少一个参数，以所选参数作为输入参数生成测试脚本，得到包含输入参数的第二测试脚本，其中，第二测试脚本中的输入参数与第一测试脚本中的输入参数不完全相同。

具体地，结合提取的目标数据、测试目标和测试策略，根据选取的参数编写第二测试用例，根据第二测试用例生成第二测试脚本。

输入参数即第二测试脚本的输入数据对应的参数，第二测试脚本中的输入参数的参数取值可以是固定值(常数)。例如，在“登录”测试中，“用户账号”和“密码”这两个输入参数的参数取值均为固定值。

或者，第二测试脚本中的输入参数的参数取值为变量，即，将输入参数的参数取值参数化，输入参数的参数取值可以根据实际测试需求自定义。

例如，在“登录”测试中，“用户账号”和“密码”这两个输入参数的参数取值为变量，可以由测试人员为“用户账号”和“密码”提供不同的赋值。或者，预先设置多组“用户账号”和“密码”的赋值，将这些“用户账号”和“密码”的赋值存放在代码的数据结构中(比如数组、集合)，也可以存放在外部文件(比如json、csv、yaml、Excel)或数据库中，通过相应的读取技术自动读取到每组“用户账号”和“密码”的赋值，以实现数据驱动测试。

另外，还可以向测试人员展示目标数据，由测试人员选取输入参数，计算机设备根据测试人员选取的输入参数生成第二测试脚本。

本实施例从目标数据中选取与第一测试脚本的输入参数不完全相同的参数构建第二测试脚本，可对被测代码进行不同于第一测试的第二测试，可覆盖更多的测试场景和代码，对被测代码进行更全面地充分测试，减少漏测，发现初步测试中未发现的隐藏问题，提高代码测试质量。

在一个实施例中，步骤S400具体包括：

根据第一覆盖率数据确定未被执行代码；

从目标数据中选取至少一个参数，其中，所选参数包括未被执行代码中的至少一个参数；

以所选参数作为输入参数生成测试脚本，得到包含输入参数的第二测试脚本。

具体地，通过第一测试用例可能无法执行到被测代码中的全部代码，为了进一步测试未被执行代码的代码质量，本实施例提取出未被执行代码中的参数，将未被执行代码中的参数作为输入参数，进行第二测试用例编写，进而根据第二测试用例生成第二测试脚本。

其中，所选参数还可能包含被测代码中、与未被执行代码相关的其他参数，具体根据代码之间的调用逻辑或调用关系确定。

另外，输入参数即第二测试脚本的输入数据对应的参数，第二测试脚本中的输入参数的参数取值可以是固定值(常数)。或者，第二测试脚本中的输入参数的参数取值为变量，即，将输入参数的参数取值参数化，输入参数的参数取值可以根据实际测试需求自定义，以实现数据驱动测试。

本实施例选取未被测试代码中的参数进行第二测试脚本的编写，运行第二测试脚本对未被测试代码进行测试，可以提高被测代码的覆盖率，减少漏测，发现隐藏问题，提高测试质量。

在一个实施例中，目标数据还包含运行第一测试时已执行代码中的参数的实际赋值；

以所选参数作为输入参数生成测试脚本，得到包含输入参数的第二测试脚本，包括：

以所选参数作为输入参数、以所选参数的实际赋值作为对应输入参数的参数取值生成测试脚本，得到包含输入参数的第二测试脚本；或者，

根据所选参数的实际赋值生成新测试数据，以所选参数作为输入参数、以所选参数的新测试数据作为对应输入参数的参数取值生成测试脚本，得到包含输入参数的第二测试脚本。

具体地，目标数据包含的参数的实际赋值为第一测试中已被执行代码中的参数的实际赋值，是根据第一测试用例中的输入数据经过代码执行产生的中间变量的结果，未被执行代码中的参数的实际赋值是未知的。

如果所选参数存在对应的实际赋值，则将其实际赋值作为对应输入参数的参数取值。

如果所选参数不存在对应的实际赋值，则根据该所选参数在被测代码中的类型，为该所选参数随机生成赋值作为对应输入参数的参数取值。或者，由测试人员为该所选参数定义赋值。另外，测试人员可以根据实际测试结果，对测试数据进行调整和修改，以覆盖更多的测试场景和边界条件，实现了允许在测试过程中动态调整和扩展测试数据。这种动态性和灵活性使得测试更具有针对性和适应性。

新测试数据范围和规则具体可以根据被测应用程序的需求和规范，预定义测试数据的范围和生成规则。这些规则可以包括数据类型、取值范围、边界条件等。利用生成算法生成新测试数据：根据预定义的规则，利用生成算法自动生成符合条件的测试数据。

在另一个具体实施例中，还可以根据所选参数的实际赋值和类型随机生成新测试数据，这样可以验证所选参数在不同取值下被测代码的表现和质量。

新测试数据可以使用各种数据生成技术，如随机数据生成、边界值测试、等价类划分等，生成多样化的测试数据，以验证系统在不同数据情况下的稳定性和正确性。本实施例提供了更多样化和灵活的测试数据生成方法，它不仅可以使用随机数据生成，还可以根据具体的业务需求，结合领域知识和规则，生成更具代表性的测试数据。这样可以更好地模拟实际使用场景，提高测试的准确性和有效性。此方案解决了传统测试中对于测试数据的有限覆盖和静态测试用例的限制。

生成的新测试数据可以作为所选参数的固定取值，也可以将所选参数的参数取值作为变量，生成的新测试数据作为参数取值这个变量的赋值，以实现数据驱动测试。

基于数据驱动测试方案通过动态分析和监控测试过程中的代码覆盖率，收集和分析测试结果，可以更准确地评估测试的覆盖范围和质量，及时发现测试中的问题和潜在的缺陷。

基于数据驱动测试方案结合自动化测试框架和工具，实现数据驱动测试流程的自动化。这包括测试数据的自动生成、测试用例的自动执行和结果的自动分析。相比传统测试，减少了人工干预，提高了测试效率和可靠性。

数据驱动测试方案通过使用不同的测试数据，可以实现更全面的测试覆盖。它能够发现更多的代码路径、边界条件和异常情况，从而提高测试的质量和可靠性。与传统测试相比，数据驱动测试更注重对不同数据情况下的代码执行路径的覆盖。

本实施例可以根据所选参数在第一测试中的实际赋值进行第二测试脚本的编写，也可以根据所选参数的实际赋值生成新测试数据进行第二测试脚本的编写，实现了输入数据的多样化，可以对被测代码进行各种场景测试，充分测试被测代码的表现和质量。

在一个实施例中，步骤S400具体包括：

从目标数据中选取至少一个参数，以所选参数作为数据驱动测试的输入参数生成测试脚本，得到包含输入参数且用于数据驱动测试的第二测试脚本。

具体地，如果测试用例都是相同的操作步骤，只是测试数据(输入参数的给定值或取值)不同，那么可以通过数据驱动测试来实现相同测试用例对应的不同测试，以实现对被测代码的全面测试。

例如，如果输入数据是正确的用户账号和密码，则期望的结果可以是提示“登录成功”；如果输入数据是错误的用户账号和正确的密码，则期望的结果可以是提示“用户账号错误，请重新输入”；如果输入数据是正确的用户账号、密码为空，则期望的结果可以是提示“密码不能为空，请输入密码”等等。

本实施例结合数据驱动测试，利用选取参数生成用于数据驱动测试的第二测试脚本。该第二测试脚本中，所选参数为输入参数，但是输入参数的参数取值为变量，即，将参数取值参数化。参数取值对应的输入数据可以存放在代码的数据结构中(比如数组、集合)，也可以存放在外部文件(比如json、csv、yaml、Excel)或数据库中，通过相应的读取技术读取到输入数据实现数据驱动测试。

例如，对于“用户账号”和|“密码”这两个输入参数，为其预先定义有多组输入数据：

用户账号：user1，密码：123456

用户账号：user1，密码：456789

用户账号：user2，密码：456789

用户账号：空，密码：123456

用户账号：user1，密码：空

用户账号：*****，密码：123456

每读取一组输入数据，就得到“用户账号”和“密码”的一个取值，作为第二测试脚本的输入数据，以驱动第二测试脚本运行一次，并对被测代码进行一次第二测试。

数据驱动测试提供了更广泛的测试覆盖：通过使用不同的测试数据，可以覆盖更多的测试情况，包括边界值、异常情况等。这有助于发现潜在的问题和错误。

数据驱动测试提高了测试的可维护性和可扩展性：测试用例的输入和预期结果通过数据进行定义，而不是硬编码在测试代码中。这使得测试用例的维护和更新更加容易，并且可以轻松地添加新的测试数据来扩展测试覆盖范围。

数据驱动测试支持自动化测试：通过将测试数据和预期结果存储在外部数据源中(如Excel表格、CSV文件或数据库)，可以编写自动化脚本来读取和执行这些数据驱动的测试脚本，实现自动化的执行和报告，提高测试效率。

数据驱动测试提供了更好的可重复性和可验证性：通过使用同样的测试数据反复执行测试，可以确保测试结果的一致性和可重复性。此外，测试数据的定义和预期结果的验证也使得测试过程更加可验证，可以对测试结果进行准确的判断和比对。

综上，数据驱动测试具有更广泛的测试覆盖、提高测试可维护性和可扩展性、支持自动化测试以及提供更好的可重复性和可验证性等特殊点，使其在软件测试中具有重要的应用价值。

本实施例根据目标数据编写适用于数据驱动测试的第二测试脚本，可减少冗余代码，集中管理测试数据，方便测试维护，便于测试框架扩展，扩展测试覆盖范围。数据驱动测试方案可以通过自动化执行测试脚本实现快速的回归测试，节省时间和人力成本。

另外，如果业务变更导致被测代码更改，本申请可以简单修改第一测试脚本，运行修改后的第一测试脚本，提取的目标数据也会随之改变，进而第二测试脚本会同步更改，实现了测试的同步更新和快速测试，方便测试扩展和维护。

在一个实施例中，目标数据还包含运行第一测试时已执行代码中的参数的实际赋值；

步骤S500具体包括：

将目标赋值转换为可用于数据驱动测试的目标格式，其中，目标赋值包括所选参数的实际赋值、根据所选参数的实际赋值生成的新测试数据、根据所选参数的数据类型生成的新测试数据中的至少一种；

根据目标格式的目标赋值为第二测试脚本中的输入参数提供不同的输入值并运行第二测试脚本，得到不同输入值对应的测试结果。

具体地，数据驱动测试可以为输入参数提供不同的参数取值，以实现不同参数取值对应的不同测试。

如果所选参数为已执行代码中的参数，则其对应有实际赋值。

如果所选参数为未执行代码中的参数，则其不存在实际赋值，因此，可以根据该所选参数在未执行代码中的数据类型，为其随机生成相同数据类型的新测试数据。当然，也可以由测试人员根据该所选参数在未执行代码中的数据类型，为其定义相同数据类型的新测试数据。

本实施例中，输入参数的不同参数取值存放于外部文件中，外部文件可以为json格式、csv格式、yaml格式、Exce格式l中的任意一种。因此，需要将实际赋值和新测试数据转换为目标格式存储于外部文件中。例如，如果外部文件为csv格式的文件，则需要将实际赋值和新测试数据转换为csv格式(目标格式)存储于外部文件中，便于后续自动化测试。

通过读取外部文件中的目标赋值可以为第二测试脚本提供不同的输入值。每提供一组输入值，第二测试脚本运行一次，每运行一次得到对应的测试结果。

本实施例根据所选参数的数据类型或实际赋值，随机生成新测试数据，用于构建数据驱动测试的输入数据，可测试被测代码同一种功能在不同应用场景下的表现，覆盖更广泛的测试场景，提高代码测试质量。

本申请将自动化测试和数据驱动测试相结合，可以帮助开发人员更好地管理和监控应用程序代码，并提高测试效率和质量。与传统的测试方法相比，基于数据驱动测试方案具有更全面的测试覆盖、更高效的测试过程、更好的代码质量管理和更好的持续集成/持续交付支持等优点。这将有助于提高代码质量和稳定性，从而更好地满足用户需求。

在一个实施例中，目标数据还包括运行第一测试时已执行代码中的参数的实际赋值；

在得到测试结果之后，该方法还包括：

监测运行第二测试时被测代码的执行状况，得到第二覆盖率数据；

根据测试结果、提取的目标数据和第二覆盖率数据，生成测试报告。

具体地，根据目标数据中的参数可以生成至少一个第二测试用例。

第二测试用例用于测试被测代码中的部分代码(被测子代码)，每运行一个第二测试用例得到对应的第二覆盖率数据。该第二覆盖率数据包括了被测子代码的语句覆盖率、分支覆盖率、方法覆盖率、行覆盖率等其中的至少一种。

测试结果可以包括以下信息：测试通过/失败信息：指示每个测试用例是否通过或失败的结果；错误信息：如果测试失败，测试结果可能会包含有关失败原因的详细错误信息，如错误堆栈跟踪或断言失败信息；覆盖率指标：测试结果可以与覆盖率数据进行比较，以评估测试用例的质量；覆盖率指标可以包括代码行的覆盖率、分支覆盖率、方法覆盖率等；测试耗时：测试结果可能包含每个测试用例的执行时间或整个测试套件的总执行时间。

在代码中，一般方法或函数之间具有调用关系或被调用关系，即一个方法或函数的输出可能是另一个方法或函数的输入，因此，目标数据中已执行代码中的参数的实际赋值可能是一个第二测试脚本期望的结果。对该第二测试脚本的测试结果与期望的结果进行比对，可以确定该第二测试脚本的质量或被测子代码的质量，挖掘出被测子代码的隐藏问题。

另外，通过对第二覆盖率数据进行解析，可以生成测试报告。测试报告中可以包含如被测代码的总行数、覆盖率统计概览等，代码覆盖率的统计数据，包括语句覆盖率、分支覆盖率、方法覆盖率等各个维度的覆盖率数据。这些统计数据可以以表格、图表或其他形式展示。报告可以对被测试代码进行着色，以区分已执行的代码和未执行的代码。报告可以提供具体的代码覆盖情况细节，例如哪些代码行被执行、哪些分支被覆盖等。这可以帮助开发人员快速定位到未覆盖的代码部分。报告中还可以包含测试结果与对应的期望结果的比对结果等等，本申请对此不做限制。

测试报告还可以指示如果测试结果显示覆盖率较低，即某些代码行或分支未被测试覆盖到，那么可以认为测试用例或测试脚本的质量较低，需要编写更全面的测试用例来提高代码覆盖率。

测试失败相关代码：如果测试结果显示某些测试用例失败，可以通过覆盖率数据确定与失败相关的代码位置。这些代码可能存在错误或缺陷，需要进行修复和改进。

重复的测试用例：如果测试结果中出现了重复的失败测试用例，可以通过覆盖率数据确定这些用例涉及相同的代码路径，可能存在某些问题需要解决。

综上，通过比较测试结果与覆盖率数据，可以评估测试用例的质量并发现需要改进的代码部分。这提供了有关测试覆盖和质量的反馈，以帮助开发人员改进测试和代码的质量。

本实施例提供了更强大的结果分析和报告生成功能。它能够收集和分析测试结果，并生成详细的测试报告，包括代码覆盖率、错误率、通过率等指标。这样测试人员可以更方便地了解测试的整体情况，及时发现和解决问题。

本申请适用于对各种应用程序代码的测试，尤其对于金融科技领域，例如在银行线上业务快速发展，开放银行业务增长迅速的环境下，新产品/系统上架、产品/系统内容变更频繁，面对巨量的代码迭代更新，代码测试量较大，传统的代码测试效率和覆盖率难以满足需求，本申请可以对巨量的金融科技应用程序的代码进行更全面测试，准确发现代码错误和缺陷。

参考图2，本申请还提供了一种测试装置，该装置包括：

第一运行模块100，用于运行第一测试脚本对被测代码进行第一测试；

第一运行监测模块200，用于监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据；

提取模块300，用于根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数；

脚本生成模块400，用于根据目标数据生成第二测试脚本；

第二运行模块500，用于运行第二测试脚本对被测代码进行第二测试，得到测试结果。

在一个实施例中，脚本生成模块400，具体用于从目标数据中选取至少一个参数，以所选参数作为输入参数生成测试脚本，得到包含输入参数的第二测试脚本，其中，第二测试脚本中的输入参数与第一测试脚本中的输入参数不完全相同。

在一个实施例中，脚本生成模块400具体包括：

筛选模块，用于根据第一覆盖率数据确定未被执行代码；

参数确定模块，用于从目标数据中选取至少一个参数，其中，所选参数包括未被执行代码中的至少一个参数；

生成模块，用于以所选参数作为输入参数生成测试脚本，得到包含输入参数的第二测试脚本，其中，第二测试脚本中的输入参数与第一测试脚本中的输入参数不完全相同。

在一个实施例中，目标数据还包含运行第一测试时已执行代码中的参数的实际赋值；

生成模块，具体用于以所选参数作为输入参数、以所选参数的实际赋值作为对应输入参数的参数取值生成测试脚本，得到包含输入参数的第二测试脚本，其中，第二测试脚本中的输入参数与第一测试脚本中的输入参数不完全相同；

或者，

生成模块，具体用于根据所选参数的实际赋值生成新测试数据，以所选参数作为输入参数、以所选参数的新测试数据作为对应输入参数的参数取值生成测试脚本，得到包含输入参数的第二测试脚本。

在一个实施例中，脚本生成模块400，具体用于从目标数据中选取至少一个参数，以所选参数作为数据驱动测试的输入参数生成测试脚本，得到包含输入参数且用于数据驱动测试的第二测试脚本。

在一个实施例中，目标数据还包含运行第一测试时已执行代码中的参数的实际赋值；

第二运行模块500包括：

格式转换模块，用于将目标赋值转换为可用于数据驱动测试的目标格式，其中，目标赋值包括所选参数的实际赋值、根据所选参数的实际赋值生成的新测试数据、根据所选参数的数据类型生成的新测试数据中的至少一种；

输入及测试模块，用于根据目标格式的目标赋值为第二测试脚本中的输入参数提供不同的输入值并运行第二测试脚本，得到不同输入值对应的测试结果。

在一个实施例中，目标数据还包括运行第一测试时已执行代码中的参数的实际赋值；

该装置还包括：

第二运行监测模块，监测运行第二测试时被测代码的执行状况，得到第二覆盖率数据；

报告生成模块，用于根据测试结果、提取的目标数据和第二覆盖率数据，生成测试报告。

图3示出了一个实施例中计算机设备的内部结构图。该计算机设备具体可以是终端，也可以是服务器。如图3所示，该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，存储器包括非易失性存储介质和内存储器。该计算机设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现上述方法实施例中的各个步骤。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行上述方法实施例中的各个步骤。本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提出了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行以下步骤：

运行第一测试脚本对被测代码进行第一测试；

监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据；

根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数；

根据目标数据生成第二测试脚本；

运行第二测试脚本对被测代码进行第二测试，得到测试结果。

在一个实施例中，提出了一种计算机可读存储介质，存储有计算机程序，计算机程序被处理器执行时，使得处理器执行以下步骤：

运行第一测试脚本对被测代码进行第一测试；

监测运行第一测试时被测代码的执行状况，得到第一覆盖率数据；

根据第一覆盖率数据从被测代码中提取出目标数据，其中，目标数据包含被测代码中的参数；

根据目标数据生成第二测试脚本；

运行第二测试脚本对被测代码进行第二测试，得到测试结果。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种测试方法，其特征在于，所述方法包括：

运行第一测试脚本对被测代码进行第一测试；

监测运行所述第一测试时被测代码的执行状况，得到第一覆盖率数据；

根据所述第一覆盖率数据从所述被测代码中提取出目标数据，其中，所述目标数据包含所述被测代码中的参数；

根据所述目标数据生成第二测试脚本；

运行所述第二测试脚本对所述被测代码进行第二测试，得到测试结果。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标数据生成第二测试脚本，包括：

从所述目标数据中选取至少一个参数，以所选参数作为输入参数生成测试脚本，得到包含所述输入参数的第二测试脚本，其中，所述第二测试脚本中的输入参数与所述第一测试脚本中的输入参数不完全相同。

3.根据权利要求1所述的方法，其特征在于，所述根据所述目标数据生成第二测试脚本，包括：

根据所述第一覆盖率数据确定未被执行代码；

从所述目标数据中选取至少一个参数，其中，所选参数包括所述未被执行代码中的至少一个参数；

以所选参数作为输入参数生成测试脚本，得到包含所述输入参数的第二测试脚本，其中，所述第二测试脚本中的输入参数与所述第一测试脚本中的输入参数不完全相同。

4.根据权利要求2或3所述的方法，其特征在于，所述目标数据还包含运行所述第一测试时已执行代码中的参数的实际赋值；

所述以所选参数作为输入参数生成测试脚本，得到包含所述输入参数的第二测试脚本，包括：

以所选参数作为输入参数、以所选参数的实际赋值作为对应输入参数的参数取值生成测试脚本，得到包含所述输入参数的第二测试脚本，其中，所述第二测试脚本中的输入参数与所述第一测试脚本中的输入参数不完全相同；

或者，

根据所选参数的实际赋值生成新测试数据，以所选参数作为输入参数、以所选参数的新测试数据作为对应输入参数的参数取值生成测试脚本，得到包含所述输入参数的第二测试脚本。

5.根据权利要求1所述的方法，其特征在于，所述根据所述目标数据生成第二测试脚本，包括：

从所述目标数据中选取至少一个参数，以所选参数作为数据驱动测试的输入参数生成测试脚本，得到包含所述输入参数且用于数据驱动测试的第二测试脚本。

6.根据权利要求5所述的方法，其特征在于，所述目标数据还包含运行所述第一测试时已执行代码中的参数的实际赋值；

所述运行所述第二测试脚本对所述被测代码进行第二测试，得到测试结果，包括：

将目标赋值转换为可用于数据驱动测试的目标格式，其中，所述目标赋值包括所选参数的实际赋值、根据所选参数的实际赋值生成的新测试数据、根据所选参数的数据类型生成的新测试数据中的至少一种；

根据目标格式的目标赋值为所述第二测试脚本中的输入参数提供不同的输入值并运行所述第二测试脚本，得到不同输入值对应的测试结果。

7.根据权利要求1所述的方法，其特征在于，所述目标数据还包括运行所述第一测试时已执行代码中的参数的实际赋值；

在得到测试结果之后，所述方法还包括：

监测运行所述第二测试时被测代码的执行状况，得到第二覆盖率数据；

根据所述测试结果、提取的目标数据和所述第二覆盖率数据，生成测试报告。

8.一种测试装置，其特征在于，所述装置包括：

第一运行模块，用于运行第一测试脚本对被测代码进行第一测试；

第一运行监测模块，用于监测运行所述第一测试时被测代码的执行状况，得到第一覆盖率数据；

提取模块，用于根据所述第一覆盖率数据从所述被测代码中提取出目标数据，其中，所述目标数据包含所述被测代码中的参数；

脚本生成模块，用于根据所述目标数据生成第二测试脚本；

第二运行模块，用于运行所述第二测试脚本对所述被测代码进行第二测试，得到测试结果。

9.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，使得所述处理器执行如权利要求1至7中任一项所述方法的步骤。

10.一种计算机设备，包括存储器和处理器，其特征在于，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行如权利要求1至7中任一项所述方法的步骤。