CN115952097A - 一种测试方法、装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请提供一种测试方法、装置、电子设备及计算机可读存储介质，涉及计算机技术领域。该测试方法，包括：获取所述测试用例中的元数据引用数据对应的元数据；基于所述元数据运行所述测试用例，得到测试结果。通过引用元数据来运行测试用例，即使在源代码更改接口或者页面数据发生变化时，只需要更改元数据，无需针对每一个测试用例进行修改，降低了人力成本和维护成本。实现了解决现有技术中，每当源代码更改接口或者页面数据发生变化时，都需要重新适配和修改自动化测试用例，极大的耗费了人力成本和维护成本的问题。

Description

一种测试方法、装置、电子设备及计算机可读存储介质

技术领域

本申请涉及计算机的技术领域，具体而言，涉及一种测试方法、装置、电子设备及计算机可读存储介质。

背景技术

自动化测试通常是依据测试用例中描述的规程，通过调用接口或捕获对应的页面元素一步步执行测试，得到测试结果。但每当源代码更改接口或者页面数据发生变化时，都需要重新适配和修改自动化测试用例，极大的耗费了人力成本和维护成本。

发明内容

本申请提供一种测试方法、装置、电子设备及计算机可读存储介质，以解决现有技术中，每当源代码更改接口或者页面数据发生变化时，都需要重新适配和修改自动化测试用例，极大的耗费了人力成本和维护成本的问题。

第一方面，本申请提供一种测试方法，包括：获取所述测试用例中的元数据引用数据对应的元数据；基于所述元数据运行所述测试用例，得到测试结果。

本申请实施例中，通过引用元数据来运行测试用例，即使在源代码更改接口或者页面数据发生变化时，只需要更改元数据，无需针对每一个测试用例进行修改，降低了人力成本和维护成本。

结合上述第一方面提供的技术方案，在一些可能的实施方式中，若所述测试用例包括动态数据，所述动态数据为页面元素数据，在所述基于所述元数据运行所述测试用例，得到测试结果后，所述方法还包括：基于所述测试结果包括的页面元素数据更新所述测试用例中的动态数据。

本申请实施例中，通过在测试用例总设置动态数据，进而实现利用页面元素数据对测试用例中动态数据的自动更新，从而无需针对每一个测试用例进行人工修改，降低了人力成本和维护成本。

结合上述第一方面提供的技术方案，在一些可能的实施方式中，在所述获取所述测试用例中的元数据引用数据对应的元数据之前，所述方法还包括：检测是否满足所述测试用例运行的前置条件；若不满足所述测试用例运行的前置条件，自动部署所述测试用例运行需求的预设前置条件；运行所述测试用例，得到测试结果。

本申请实施例中，通过预先检测是否满足测试用例运行的前置条件，并在不满足时自动部署前置条件，可以防止因前置条件不满足导致的测试用例运行失败的情况。

结合上述第一方面提供的技术方案，在一些可能的实施方式中，所述测试用例包括N个，检测是否满足测试用例运行的前置条件，包括：基于预先编号的N个测试用例，检测第i个测试用例运行的前置条件是否满足，其中，编号依次为1-N，i小于等于N，i、N均为正整数。

结合上述第一方面提供的技术方案，在一些可能的实施方式中，若所述第i个测试用例运行的前置条件不满足，在所述自动部署所述该测试用例运行需求的前置条件后，所述方法还包括：再次检测第i个测试用例运行的前置条件是否满足，若所述第i个测试用例运行的前置条件不满足，标记所述第i个测试用例；在每一个前置条件不满足的测试用例再次检测完成后，针对被标记的每一个测试用例，再次自动部署该测试用例运行需求的前置条件；运行再次检测后的所述测试用例，得到测试结果。

本申请实施例中，针对前置条件不满足的测试用例再次部署其运行需要的前置条件，通过两次部署前置条件，能防止因前置条件部署出错导致的测试用例前置条件不满足的情况。

结合上述第一方面提供的技术方案，在一些可能的实施方式中，在所述再次自动部署所述该测试用例运行需求的前置条件后，所述方法还包括：再次检测被标记的测试用例运行需求的前置条件是否满足；若不满足，生成该测试用例对应的错误报告，并检测下一个被标记的测试用例运行的前置条件是否满足。

本申请实施例中，在两次部署的前置条件均不满足时，确认该测试用例出现错误，不再为其部署前置条件，提高测试效率。

第二方面，本申请提供一种测试装置，包括：获取模块、处理模块，获取模块用于获取所述测试用例中的元数据引用数据对应的元数据；处理模块用于基于所述元数据运行所述测试用例，得到测试结果。

结合上述第二方面提供的技术方案，在一些可能的实施方式中，若所述测试用例包括动态数据，在运行所述测试用例，得到测试结果后，所述处理模块，还用于基于所述测试结果包括的页面元素数据更新所述测试用例中的动态数据。

第三方面，本申请实施例还提供了一种电子设备，包括：存储器和处理器，所述存储器和所述处理器连接；所述存储器，用于存储程序；所述处理器，用于调用存储于所述存储器中的程序，以执行如上述第一方面实施例和/或结合上述第一方面实施例的任一种可能的实施方式提供的方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被计算机运行时，执行如上述第一方面实施例和/或结合上述第一方面实施例的任一种可能的实施方式提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例示出的第一种测试方法的流程示意图；

图2为本申请实施例示出的第二种测试方法的流程示意图；

图3为本申请实施例示出的一种测试装置的结构框图；

图4为本申请实施例示出的一种电子设备的结构框图。

具体实施方式

术语“第一”、“第二”、“第三”等仅用于区分描述，并不表示排列序号，也不能理解为指示或暗示相对重要性。

此外，术语“水平”、“竖直”、“悬垂”等术语并不表示要求部件绝对水平或悬垂，而是可以稍微倾斜。如“水平”仅仅是指其方向相对“竖直”而言更加水平，并不是表示该结构一定要完全水平，而是可以稍微倾斜。

在本申请的描述中，需要说明的是，术语“内”、“外”、“左”、“右”、“上”、“下”等指示的方位或位置关系为基于附图所示的方位或位置关系，或者是该申请产品使用时惯常摆放的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

在本申请的描述中，除非另有明确的规定和限定，术语“设置”、“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。

下面将结合附图对本申请的技术方案进行详细地描述。

请参阅图1，图1为本申请实施例示出的一种测试方法的流程示意图，下面将结合图1对其包含的步骤进行说明。

S100：获取测试用例中的元数据引用数据对应的元数据。

其中，同一元数据可以被多个不同的测试用例引用，当该元数据被修改后，引用该元数据的测试用例的元数据引用数据对应的元数据也为修改后的元数据。

一种实施方式下，元数据可以应用在对驱动数据标记复用中，例如：测试创建虚拟机、编辑虚拟机、虚拟机克隆等功能，由于这些功能都具有相同的测试步骤，也即都需要先创建虚拟机，然后查询筛选该虚拟机等等，此时，这些相同的测试步骤所对应的驱动测试步骤数据是相同的，因此，可以将这些相同的测试步骤所对应的驱动测试步骤数据标记为元数据。在编写测试用例时，也仅需要针对其中一个功能点对应的驱动测试步骤数据进行编写，其它具有相同的测试步骤的测试用例对应该部分内容的，可以直接引用该元数据，从而避免了重复多次编写相同驱动测试步骤的代码，避免了代码冗余。当该相同的测试步骤实现过程发生改变时，只需改动对应元数据即可，从而节省了大量的修改代码时间，也能防止了漏改。

可选的，当测试系统版本迭代导致某些功能对应测试步骤或元素发生变化时，可以在PageData(测试步骤驱动数据文件)中修改元数据，其他具有相同步骤的测试用例引用该元数据，可以通过调用pageconfig配置文件中的元数据封装方法生效。

元数据封装方法指当我们定义某个功能对应的测试用例中具有相同测试步骤的部分为元数据时，对这部分相同的测试步骤进行标记(使用一个标记值)，后续其他测试用例使用到这部分相同的测试步骤时，通过调用pageconfig文件中的解析元数据中的方法时，即可直接引用该部分数据。

其中，pageconfig文件用于定义标记值，且该pageconfig文件中包括有元数据和标记值的对应关系。在调用pageconfig文件时，pageconfig文件基于测试用例中的标记值获取对应的元数据，并引用该元数据，以使调用pageconfig文件的测试用例引用该部分元数据。

其中，测试用例的获取过程可以是，首先需要对待测功能进行梳理，分析出哪些功能对应的测试点能够进行自动化测试。针对不能实现自动化的测试点，分析无法自动化测试的原因，确定能否借助其它辅助工具来实现自动化测试；之后将分析结果进行评审后输出自动化测试需求文档。

在得到分析结果后，按照功能点对应的Web页面进行划分，需要注意的是，该页面是功能测试点的最终实现页面。划分好功能点之后，按照测试点编写自动化测试用例。

S200：基于元数据运行测试用例，得到测试结果。

在获取到元数据后，即可基于元数据和测试用例进行测试，得到测试结果。

测试用例中的部分参数需要随着页面元素数据变化，为了降低修改测试用例的成本，一种实施方式下，若测试用例包括动态数据，动态数据为页面元素数据，在基于元数据运行测试用例，得到测试结果后，还可以先获取页面元素数据，然后基于该页面元素数据更新测试用例中的动态数据。

其中，动态数据可以是在编写测试用例时预先标记好的，由于不同的测试用例可能使用同一个动态数据，因此，当将出现在测试用例中的每一个动态数据进行标记后，在基于页面元素数据更该动态数据时，所有被标记的该同一个动态数据均进行更新。

例如，数据A为动态数据，且测试用例1、测试用例2中均包括有该数据A，在基于页面元素数据更该数据A时，测试用例1和测试用例2中的数据A均更新。

动态数据可以应用在测试执行数据和测试驱动数据中，在执行自动化测试的过程中，很多页面数据会发生改变，测试数据也会因环境或功能的变化而发生变化；这些变化的数据往往在很多测试用例中引用，每次发生变化时都需要对其进行一一替换。因此，将测试用例中这些变化的数据标记为动态数据，对动态数据进行变量标记，通过参数化方法调用，当数据发生变化时，只需修改对应变量的值即可。

当页面功能变化导致动态数据或期望结果发生改变时，通过修改已标记的动态数据对应的值，调用参数化pageconfig配置文件中的参数化方法来实现对变量的引用，从而实现对页面功能或数据变化后自动化代码的快速更新。

一种实施方式下，在获取到页面元素数据后，还可以判断该页面元素数据是否正确。其中，判断页面元素数据的方法可以是封装在配置文件的方法中，直接调用该方法即可。

其中，可以预设有标准数据，在获取到页面元素数据后，将其与对应的标准数进行对比，若两者相同，则确认页面元素数据正确，若两者不相同，认为页面元素数据错误。

若页面元素正确，则更新动态数据。若页面元素错误，则重新获取该页面元素数据。并在获取到正确的页面元素数据后，再次执行测试用例。

需要注意的是，由于自动化测试用例区别于手工用例，自动化测试用例要有对应的前置条件。测试用例的前置条件即为实现一个功能需要满足的前提条件。如果测试用例的前置条件不满足，可能导致测试用例无法执行。

一种实施方式下，在获取测试用例中的元数据引用数据对应的元数据之前，还可以先检测是否满足测试用例运行的前置条件，若不满足测试用例运行的前置条件，自动部署测试用例运行需求的预设前置条件。最后运行测试用例，得到测试结果。

例如，验证创建虚拟机功能的测试用例的前置条件可以是，存在计算资源：vCPU、vMEM，存在存储资源：vStorage，存在虚拟网络：vNET等。在利用该测试用例验证创建虚拟机功能之前，需要先检测这些条件是否满足，若不满足，在执行测试用例之前需要提前部署好这些前置条件。此处举例仅为便于理解，不应作为对本申请的限制。

或者，也可以是先针对每一个测试用例部署其运行需要的前置条件，在部署完成后，针对每一个测试用例，检测其运行需要的前置条件是否满足，在不满足时i，再次部署该测试用例运行需要的前置条件。最后运行测试用例，得到测试结果。

可选的，当测试用例包括N个时，检测是否满足测试用例运行的前置条件的方式可以是，基于预先编号的N个测试用例，检测第i个测试用例运行的前置条件是否满足，其中，编号依次为1-N，i小于等于N，i、N均为正整数。

例如，当存在测试用例1、测试用例2、测试用例3这3个测试用例时，首先检测测试用例1运行的前置条件是否满足，然后检测测测试用例2运行的前置条件是否满足，最后测测试用例3运行的前置条件是否满足。

需要注意的是，此处检测每一个测试用例运行的前置条件是否满足时，无论检测结果是满足还是不满足，得到检测结果后，都继续检测下一个测试用例运行的前置条件是否满足。

当第i个测试用例运行的前置条件不满足时，在自动部署该测试用例运行需求的前置条件后，还可以再次检测第i个测试用例运行的前置条件是否满足，若第i个测试用例运行的前置条件不满足，标记第i个测试用例。之后在每一个前置条件不满足的测试用例再次检测完成后，针对被标记的每一个测试用例，再次自动部署该测试用例运行需求的前置条件。最后运行再次检测后的测试用例，得到测试结果。

针对前置条件不满足的测试用例再次部署其运行需要的前置条件，通过两次部署前置条件，能防止因前置条件部署出错导致的测试用例前置条件不满足的情况。

例如，当存在测试用例1、测试用例2、测试用例3、测试用例4这4个测试用例时，可以是在自动部署该测试用例1运行需求的前置条件后，再次检测测试用例1运行的前置条件是否满足，若测试用例1运行的前置条件不满足，标记测试用例1。同理对测试用例2、测试用例3、测试用例4进行检测。若其中测试用例1、测试用例3被标记，则在再次检测测试用例4运行的前置条件是否满足后，再次部署测试用例1、测试用例3的前置条件，之后再次检测测试用例1、测试用例3运行的前置条件是否满足。

或者，也可以是在针对每一个测试用例部署了前置条件后，再针对每一个测试用例再次检测其运行的前置条件是否满足。

例如，当存在测试用例1、测试用例2、测试用例3、测试用例4这4个测试用例时，首先针对测试用例1、测试用例2、测试用例3、测试用例4依次检测每一个测试用例运行的前置条件是否满足，若不满足，为其部署前置条件。然后针对每一个测试用例，再次检测其运行的前置条件是否满足，若不满足，标记该测试用例。之后在每一个前置条件不满足的测试用例再次检测完成后，针对被标记的每一个测试用例，再次自动部署该测试用例运行需求的前置条件。最后运行再次检测后的测试用例，得到测试结果。

一种实施方式下，在再次自动部署该测试用例运行需求的前置条件后，还可以再次检测被标记的测试用例运行需求的前置条件是否满足；若不满足，生成该测试用例对应的错误报告，并检测下一个被标记的测试用例运行的前置条件是否满足。在两次部署的前置条件均不满足时，确认该测试用例出现错误，不再为其部署前置条件，提高测试效率。

可选的，自动化测试用例还设置有对应的后置条件。测试用例的后置条件即一条测试用例执行完之后恢复初始化状态。如果测试用例的后置条件不满足，可能导致测试用例执行后有大量残留数据，进而导致占用大量内存。

例如，验证创建虚拟机功能的测试用例执行完之后，需要通过后置执行步骤删除掉该虚拟机及对应的磁盘等配置，避免占用大量资源，也即后置条件为删除掉该虚拟机及对应的磁盘等配置。

为了便于理解上述的测试方法，请参阅图2，图2为本申请实施例示出的一种测试方法的流程示意图。需要注意的是，图2所示的测试方法仅为本申请提供的测试方法的众多实施例中的一种，不应将图2所示的测试方法作为对本申请的限制。

如图2所示，首先部署环境的前置条件和每一个测试用例的前置条件，然后基于预先编号的N个测试用例，检测第i个测试用例运行的前置条件是否满足。若第i个测试用例运行的前置条件满足，运行第i个测试用例，得到检测结果。其中，环境的前置条件指针对该测试方法的最基本配置要求，例如添加存储、网络配置、环境资源配置等(CPU(centralprocessing unit，中央处理器)、内存等)，没有这些前置条件，所有功能都无法正常使用。

若第i个测试用例运行的前置条件不满足，自动部署该测试用例运行需求的前置条件。然后再次检测第i个测试用例运行的前置条件是否满足。若第i个测试用例运行的前置条件满足，运行第i个测试用例，得到检测结果。

若第i个测试用例运行的前置条件不满足，标记第i个测试用例；并在每一个前置条件不满足的测试用例再次检测完成后，针对被标记的每一个测试用例，再次自动部署该测试用例运行需求的前置条件；之后运行再次检测后的测试用例，得到测试结果。

最后再次检测被标记的测试用例运行需求的前置条件是否满足；若不满足，生成该测试用例对应的错误报告，并检测下一个被标记的测试用例运行的前置条件是否满足。若被标记的测试用例运行需求的前置条件满足，运行该测试用例，得到检测结果。

图2所示的测试方法的各个步骤的实现原理在前文以叙述清楚，为简要描述，此处不再赘述。

其中，运行测试用例，得到检测结果的过程可以是，首先调用测试用例对应的测试步骤驱动方法(驱动方法通过调用对应的测试数据实现运行)。在功能步骤执行完成后，执行后置测试条件方法清理测试数据。最后自动记录返回测试结果至TestCase中的用例方法，调用测试用例数据(即测试用例预期结果)与返回的测试结果进行比较，如一致则用例通过，不一致则在日志中和截图中输出报错信息。

可选的，还可以对测试结果进行分析，确认各个功能存在的问题，记录并标记对应的测试用例，以便后续修复后重新执行验证。

最后还可以发送测试和分析报告给相关人员，其中，整个自动化测试用例的执行过程可在jenkins上通过CI/CD流程实现。CI/CD流程具体指项目持续集成持续交付。在配置好jenkins后，可以实现从开发编码到最终生成测试报告全自动化的过程(从开发上传代码后触发jenkins实现编译打包，然后测试环境自动升级新版本包，升级好之后自动批量执行自动化代码，执行完之后自动生成测试报告，自动发送测试报告)。

本申请提供的测试方法可以应用于产品的快速迭代测试。通过动态数据的应用，实现了对代码参数的快速修改和数据的更新。此外，自动部署前置条件以及前置条件的判断方法，可以保障测试用例正常的运行。由于现有的产品具备的快速迭代和版本定制化的特点，本方案有效的解决了测试用例在频繁修改的过程中维护困难的问题，并最终达到自动化测试快速适配高效响应的目的。

本申请提供的测试方法还可以应用于超融合等不同系统平台测试。基于动态数据的自动化测试框架中的各模块之间通过导入和调用的方式建立联系，模块或文件内部改动不会对其他模块造成影响。另外测试用例的执行过程也是相互独立的，应用到任何的Web平台都可适配，只需修改对应测试用例即可，使得本方案具有很强的兼容性，可快速实现自动化跨平台运行。其中，自动化测试框架中不同的模块的功能不同，通过不同模块之间的调用实现动态数据的自动化测试。

本申请提供的测试方法也可以用于功能测试，针对功能测试前环境的部署和版本升级场景测试前测试数据的准备。在新测试环境搭建好之后，需要配置好环境的前置条件，如资源池、存储、网络等。对于已部署好的环境，则可以检查环境的前置条件状态是否正常，不正常则记录并重新创建恢复。

或者，也可以应用于版本升级场景测试，此时，需要对比升级前后系统各模块的功能是否正常，因此升级前需要准备测试数据，例如创建各种类型的虚拟机、磁盘、虚拟网络设备等等。通过自动部署升级前置条件和判断方法来保障升级测试数据准确性和有效性。

针对上述两种场景，本方案不仅能节省大量的时间和人工成本，而且还保障了测试前置数据和条件的完整和正确。

基于同样的发明构思，本申请还提供一种测试装置，如图3所示，该测试装置100包括获取模块110和处理模块120。

获取模块110，用于获取所述测试用例中的元数据引用数据对应的元数据。

处理模块120，用于基于所述元数据运行所述测试用例，得到测试结果。

若所述测试用例包括动态数据，在运行所述测试用例，得到测试结果后，所述处理模块120，还用于基于所述测试结果包括的页面元素数据更新所述测试用例中的动态数据。

处理模块120，还用于在所述获取所述测试用例中的元数据引用数据对应的元数据之前，检测是否满足所述测试用例运行的前置条件；若不满足所述测试用例运行的前置条件，自动部署所述测试用例运行需求的预设前置条件；运行所述测试用例，得到测试结果。

处理模块120，具体用于基于预先编号的N个测试用例，检测第i个测试用例运行的前置条件是否满足，其中，编号依次为1-N，i小于等于N，i、N均为正整数。

处理模块120，还用于若所述第i个测试用例运行的前置条件不满足，在所述自动部署所述该测试用例运行需求的前置条件后，再次检测第i个测试用例运行的前置条件是否满足，若所述第i个测试用例运行的前置条件不满足，标记所述第i个测试用例；在每一个前置条件不满足的测试用例再次检测完成后，针对被标记的每一个测试用例，再次自动部署该测试用例运行需求的前置条件；运行再次检测后的所述测试用例，得到测试结果。

处理模块120，还用于在所述再次自动部署所述该测试用例运行需求的前置条件后，再次检测被标记的测试用例运行需求的前置条件是否满足；若不满足，生成该测试用例对应的错误报告，并检测下一个被标记的测试用例运行的前置条件是否满足。

本申请实施例所提供的测试装置100，其实现原理及产生的技术效果和前述测试方法实施例相同，为简要描述，装置实施例部分未提及之处，可参考前述测试方法实施例中相应内容。

请参阅图4，其为本申请实施例提供的一种电子设备200。所述电子设备200包括：收发器210、存储器220、通讯总线230、处理器240。

所述收发器210、所述存储器220、处理器240各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线230或信号线实现电性连接。其中，收发器210用于收发数据。存储器220用于存储计算机程序，如存储有图3中所示的软件功能模块，即测试装置100。其中，测试装置100包括至少一个可以软件或固件(firmware)的形式存储于所述存储器220中或固化在所述电子设备200的操作系统(operating system，OS)中的软件功能模块。所述处理器240，用于执行存储器220中存储的可执行模块，例如测试装置100包括的软件功能模块或计算机程序。此时，处理器240，用于获取所述测试用例中的元数据引用数据对应的元数据；基于所述元数据运行所述测试用例，得到测试结果。

其中，存储器220可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

处理器240可能是一种集成电路芯片，具有信号的处理能力。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(FieldProgrammable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器240也可以是任何常规的处理器等。

其中，上述的电子设备200，包括但不限于个人电脑、服务器等。

本申请实施例还提供了一种非易失性计算机可读取存储介质(以下简称存储介质)，该存储介质上存储有计算机程序，该计算机程序被计算机如上述的电子设备200运行时，执行上述所示的测试方法。该计算机可读存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

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

获取所述测试用例中的元数据引用数据对应的元数据；

基于所述元数据运行所述测试用例，得到测试结果。

2.根据权利要求1所述的方法，其特征在于，若所述测试用例包括动态数据，所述动态数据为页面元素数据，在所述基于所述元数据运行所述测试用例，得到测试结果后，所述方法还包括：

基于所述测试结果包括的页面元素数据更新所述测试用例中的动态数据。

3.根据权利要求1所述的方法，其特征在于，在所述获取所述测试用例中的元数据引用数据对应的元数据之前，所述方法还包括：

检测是否满足所述测试用例运行的前置条件；

若不满足所述测试用例运行的前置条件，自动部署所述测试用例运行需求的预设前置条件；

运行所述测试用例，得到测试结果。

4.根据权利要求3所述的方法，其特征在于，所述测试用例包括N个，检测是否满足测试用例运行的前置条件，包括：

基于预先编号的N个测试用例，检测第i个测试用例运行的前置条件是否满足，其中，编号依次为1-N，i小于等于N，i、N均为正整数。

5.根据权利要求4所述的方法，其特征在于，若所述第i个测试用例运行的前置条件不满足，在所述自动部署所述该测试用例运行需求的前置条件后，所述方法还包括：

再次检测第i个测试用例运行的前置条件是否满足，若所述第i个测试用例运行的前置条件不满足，标记所述第i个测试用例；

在每一个前置条件不满足的测试用例再次检测完成后，针对被标记的每一个测试用例，再次自动部署该测试用例运行需求的前置条件；

运行再次检测后的所述测试用例，得到测试结果。

6.根据权利要求5所述的方法，其特征在于，在所述再次自动部署所述该测试用例运行需求的前置条件后，所述方法还包括：

再次检测被标记的测试用例运行需求的前置条件是否满足；

若不满足，生成该测试用例对应的错误报告，并检测下一个被标记的测试用例运行的前置条件是否满足。

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

获取模块，用于获取所述测试用例中的元数据引用数据对应的元数据；

处理模块，用于基于所述元数据运行所述测试用例，得到测试结果。

8.根据权利要求7所述的测试装置，其特征在于，若所述测试用例包括动态数据，在运行所述测试用例，得到测试结果后，所述处理模块，还用于基于所述测试结果包括的页面元素数据更新所述测试用例中的动态数据。

9.一种电子设备，其特征在于，包括：存储器和处理器，所述存储器和所述处理器连接；

所述存储器，用于存储程序；

所述处理器，用于调用存储于所述存储器中的程序，以执行如权利要求1-6中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被计算机运行时，执行如权利要求1-6中任一项所述的方法。

Images