CN109840206A - 数据测试方法、装置、终端及存储介质 - Google Patents

Abstract

本发明公开了一种数据测试方法、装置、终端及存储介质，所述方法包括首先获取待测应用的测试脚本以及与所述测试脚本相应的业务逻辑和测试数据，其中不同的测试数据对应所述待测应用中不同的功能模块；然后将所述业务逻辑和各测试数据编写入预设电子表格中；接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块；最后执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试，最终得到的测试结果数据在预设电子表格中，测试人员能够第一时间非常清楚地掌握各项测试结果数据。在待测应用需要更新时，可直接在预设电子表格中进行维护，提高了测试人员的工作效率。

Description

数据测试方法、装置、终端及存储介质

技术领域

本发明涉及软件测试领域，尤其涉及一种数据测试方法、装置、终端及存储介质。

背景技术

软件测试是使用人工操作或者软件自动运行的方式来检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别的过程。

现今软件行业开始迅猛发展，软件的规模变的非常大，在一些大型软件开发过程中，测试活动需要花费大量的时间和成本，随着业务需求、用户业务要求的不断增多，目前的软件自动化测试工具都具有可重复执行，系统自动执行测试流程的特点，但是这些工具脚本前期发放成本较高，数据文件维护繁琐进而导致脚本维护不是很方便的问题；并且目前一般的数据测试模型中都包含测试数据，而相应的测试脚本中依然有业务逻辑，当脚本中的业务发生变化时那么就需要测试人员手动重新对测试脚本进行编辑，因此测试脚本在前期就需要投入较多的开发脚本，测试脚本维护以及测试数据的维护和管理就显得比较困难繁琐，故而影响了测试人员的工作效率。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于提供一种数据测试方法、装置、终端及存储介质，旨在解决目前数据文件维护繁琐影响相关人员的测试效率的问题。

为实现上述目的，本发明提供一种数据测试方法，所述包括以下步骤：

获取待测应用的测试脚本以及与所述测试脚本相应的业务逻辑和测试数据，其中不同的测试数据对应所述待测应用中不同的功能模块；

将所述业务逻辑和各测试数据编写入预设电子表格中；

接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块；

执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试。

优选地，所述将所述业务逻辑和各测试数据编写入预设电子表格中，具体包括：

将所述业务逻辑分解成多个关键字，将得到的多个关键字编写入预设电子表格中形成所述业务逻辑的表数据；

将各测试数据编写入预设电子表格中以形成各测试数据的表数据。

优选地，所述接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块，具体包括：

响应于用户基于所述待测应用的目标界面输入的触发事件，并确定与所述触发事件对应的界面元素；

根据所述触发事件从所述预设电子表格中选取目标测试数据的表数据，所述目标界面与所述目标测试数据相对应；

根据所述触发事件、所述触发事件对应的界面元素以及所述目标测试数据的表数据生成测试指令；

根据所述目标测试数据的表数据确定与所述目标测试数据对应的目标功能模块。

优选地，所述执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试，具体包括：

执行所述测试指令以调用所述业务逻辑的表数据对所述目标功能模块进行数据测试。

优选地，所述触发事件包括数据验证类型；

相应地，所述执行所述测试指令以调用所述业务逻辑的表数据对所述目标功能模块进行数据测试，具体包括：

执行所述测试指令，从所述测试指令中确定验证类型；

从业务逻辑的表数据中调用与所述验证类型对应的目标业务逻辑表数据，实现对所述目标功能模块进行数据测试。

优选地，所述触发事件还包括测试期望值；

相应地，所述执行所述测试指令，从所述测试指令中确定验证类型，具体包括：

执行所述测试指令，从所述测试指令中确定验证类型和测试期望值；

相应地，从业务逻辑的表数据中调用与所述验证类型对应的目标业务逻辑表数据，实现对所述目标功能模块进行数据测试之后，还包括：

判断所述目标功能模块的数据测试结果与所述测试期望值之间的差值是否处于预设误差阈值范围；

若是，则判定测试成功，若否，则判定测试失败。

优选地，所述预设电子表格为Excel表格；

相应地，所述执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试之后，还包括：

在所述Excel表格中对所述目标功能模块的数据测试结果进行展示。

此外，我实现上述目的，本发明还提出一种数据测试装置，所述装置包括：

获取模块，用于获取待测应用的测试脚本以及与所述测试脚本相应的业务逻辑和测试数据，其中不同的测试数据对应所述待测应用中不同的功能模块；

编写模块，用于将所述业务逻辑和各测试数据编写入预设电子表格中；

接收模块，用于接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块；

测试模块，用于执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试。

此外，我实现上述目的，本发明还提出一种终端，所述终端包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据测试程序，所述数据测试程序配置为实现如上所述的数据测试方法的步骤。

此外，我实现上述目的，本发明还提出一种存储介质，所述存储介质上存储有数据测试程序，所述数据测试程序被处理器执行时实现如上所述数据测试方法的步骤。

本发明的数据测试方法包括首先获取待测应用的测试脚本以及与所述测试脚本相应的业务逻辑和测试数据，其中不同的测试数据对应所述待测应用中不同的功能模块；然后将所述业务逻辑和各测试数据编写入预设电子表格中；接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块；最后执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试，最终得到的测试结果数据在预设电子表格中。只要对预设电子表格中每条数据进行测试，测试人员能够第一时间非常清楚地掌握各项测试结果数据。如果测试人员后续对该待测应用的模块的功能需求或者测试需求有变更，可以直接通过修改预设电子表格中对应的数据来对待测应用的模块的功能需求或者测试需求进行更新，可维护型很高，提高了测试人员的工作效。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的用于数据测试的终端的结构示意图；

图2为本发明一种数据测试方法第一实施例的流程示意图；

图3为本发明一种数据测试方法第二实施例的流程示意图；

图4为本发明一种数据测试装置的结构框图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

参照图1，图1为本发明实施例方案涉及的硬件运行环境的用于数据测试的终端结构示意图。

如图1所示，该终端可以包括：处理器1001，例如CPU，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对所述终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，所述存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及数据测试程序。

在图1所示的终端中，网络接口1004主要用于数据通信；用户接口1003主要用于连接与测试人员或者开发人员的交互的设备；本发明终端中的处理器1001、存储器1005可以设置在所述终端中，所述终端通过处理器1001调用存储器1005中存储的数据测试程序，并执行所述数据测试方法的步骤。

参照图2，图2是本发明一种数据测试方法的第一实施例流程示意图，所述数据测试方法包括以下步骤：

步骤S10：获取待测应用的测试脚本以及与所述测试脚本相应的业务逻辑和测试数据，其中不同的测试数据对应所述待测应用中不同的功能模块；

可理解的是，本实施例的执行主体为上述终端的处理器，所述待测应用是软件测试人员或开发人员需要测试的APP计算机应用程序软件，可以是装载于手机上的APP软件，也可以是装载于电脑终端上的程序软件，例如待测应用是一种商城管理APP应用程序，该商城管理APP应用程序可以根据按照功能的不同分成多个功能模块，例如商城管理APP应用程序可以具有一个发布视频的功能的模块，也可以具有一个维护视频的功能的模块等，也可以具有更多的功能模块。每个功能模块都对应至少一个测试脚本，本实施例中描述的测试脚本和目前常规的测试脚本一样，都是测试人员自己编写的程序脚本，而不同的测试脚本(即不同的功能模块)对应不同的业务逻辑和测试数据。

测试数据用于对功能模块进行测试，不同的测试数据对应所述待测应用中不同的功能模块。业务逻辑可理解为实现待测应用的某个的模块的功能需要执行的底层动作代码。

在具体实现中，为了区分，不同的功能模块都具有一个唯一的标识，不同的测试数据对应所述待测应用中不同的功能模块，为了表示测试脚本、测试脚本、业务逻辑、以及测试数据之间的关联性，可以表示如下：功能模块用modules-1表示代表该待测应用的第一个功能模块，与所述功能模块对应的有：测试脚本script-1，功能模块modules-1，业务逻辑1-logic-1，测试数据Test-Data-1-1-1。

步骤S20：将所述业务逻辑和各测试数据编写入预设电子表格中；

可以理解的是，一般的数据测试模型中都包含测试数据，而相应的测试脚本中依然有业务逻辑代码(即上述提到的底层动作代码)，当所述测试脚本中的业务逻辑发生变化时那么就需要测试人员手动重新对测试脚本进行编辑，因此测试脚本在前期就需要投入较多的开发脚本，测试脚本维护以及测试数据的维护和管理就显得比较困难繁琐。

本实施例中，以所述预设电子表格为Excel表格为例，不需要将测试人员输入的测试数据送入数据测试模型中，即测试脚本中不需要植入上述底层动作代码，测试人员在编写好测试用例后，直接将业务逻辑和与该业务逻辑对应的测试数据都集中编写入Excel表格中，当业务逻辑发送变化时，无需手动更改业务逻辑对应的测试脚本，进而能够提高测试效率。

具体地，本实施例以对某待测应用的功能模块modules-1进行测试为例，将本来应该在功能模块modules-1对应的测试脚本script-1的底层动作代码抽象为由关键字组成的表数据Action-1-Logic-1，即将对应的业务逻辑1-logic-1抽象为关键字组成的抽象代码，再将这些编写好的抽象代码编写入Excel表格中形成表数据Action-1-Logic-1。

即所述步骤S20具体包括：将所述业务逻辑分解成多个关键字，将得到的多个关键字编写入预设电子表格中形成所述业务逻辑的表数据。

同时，由于后续测试中测试人员或者开发人员可能还需要使用测试脚本script-1，因此需要在测试脚本script-1中编写对应的代码指针，所述指针用于将原本应该填写底层动作代码的位置指向Excel表格中由关键字组成的表数据Action-1-Logic-1。这样当待测应用出现因程序升级或者更新的原因致使其底层动作代码需要更改时，测试人员无需对测试脚本中的内容进行更改，只需要对应修改Excel中的对应代码即可，进而减少测试人员的工作量。

步骤S30：接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块。

可理解的是，常规的测试方法需要调用测试脚本，这样的缺陷在于第一不方便测试人员的后期维护，第二测试人员在进行测试时不能看见测试数据，对应测试人员来说很不方便。而本实施例中，测试人员可以直接打开Excel表格，从Excel表格中选取目标测试数据，所述终端的处理器基于测试人员选取的目标测试数据确定哪个模块是当前需要接受测试的目标待测试模。

步骤S40：执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试。

具体地，所述步骤S40具体包括执行所述测试指令以调用所述业务逻辑的表数据对所述目标功能模块进行数据测试，最后会对所述目标功能模块的数据测试结果进行展示。

在具体实现中，本实施例的商城管理APP应用程序的标识为modules-1的功能模块为发布视频模块，对应的业务逻辑1-logic-1的为具有发布视频功能，运维对视频操作权限的控制的底层动作代码，上述底层动作代码会抽象为由关键字组成的抽象代码，并写入Excel表格中形成表数据Action-1-Logic-1。当商城管理APP应用程序响应所述测试指令时，会调用表数据Action-1-Logic-1以执行发布视频以及对不同视频进行权限设置操作的步骤，终端的处理器确定上述目标功能模块为modules-1后，前台后视频状态会发生变更，同时操作栏中操作按钮也会相应地更新，以形成测试结果数据。而发生状态变更的测试结果数据全部在excel表格中，只要对excel表格中每条数据进行测试，即可覆盖全部视频状态以及操作视频的功能点，并且对各个测试状态及操作按钮一目了然，也就是说测试人员能够第一时间非常清楚地掌握各项测试结果数据。如果测试人员后续对该待测应用的模块的功能需求或者测试需求有变更，可以直接通过修改预设电子表格中对应的数据来对待测应用的模块的功能需求或者测试需求进行更新，可维护型很高，提高了测试人员的工作效率。

参照图3，图3本发明一种数据测试方法的第二实施例流程示意图，基于上述图2提出本发明数据测试方法的第二实施例；

本实施例中，所述步骤S30具体包括：

步骤S301：响应于用户基于所述待测应用的目标界面输入的触发事件，并确定与所述触发事件对应的界面元素；

步骤S302：根据所述触发事件从所述预设电子表格中选取目标测试数据的表数据，所述目标界面与所述目标测试数据相对应；

步骤S303：根据所述触发事件、所述触发事件对应的界面元素以及所述目标测试数据的表数据生成测试指令；

步骤S304：根据所述目标测试数据的表数据确定与所述目标测试数据对应的目标功能模块。

可理解的是，本实施例的待测应用以浏览器为例进行说明，将其功能模块的测试脚本script-1的底层动作代码抽象为由关键字组成的表数据：首先，对测试脚本script-1的操作进行解析，抽象为由关键字组成的表数据过程如下：操作＝操作命令+界面元素+输入值。浏览器的操作命令通常包括点击触发的动作和输入事件，它们统一表征为所述测试指令。界面元素可以包括界面按钮，文本框等控件，输入值通常是操作时需要被测试的目标功能模块的测试数据(即所述目标测试数据)。

此外，结合浏览器操作和验证点的需求，测试脚本script-1的底层动作代码还可以抽象为：操作＝动作+元素定位+测试数据。

进一步地，所述触发事件包括数据验证类型；

相应地，所述步骤S40具体包括：

步骤S401：执行所述测试指令，从所述测试指令中确定验证类型；

具体地，所述触发事件还包括测试期望值，本实施例的所述步骤S401具体包括：执行所述测试指令，从所述测试指令中确定验证类型和测试期望值；

步骤S402：从业务逻辑的表数据中调用与所述验证类型对应的目标业务逻辑表数据，实现对所述目标功能模块进行数据测试。

具体地，相应地，本实施例的所述步骤S402之后，还包括：判断所述目标功能模块的数据测试结果与所述测试期望值之间的差值是否处于预设误差阈值范围；若是，则判定测试成功，若否，则判定测试失败。

可理解的是，所述测试脚本需要一个验证点，验证点是判断是否执行成功的关键。验证点可由三部分组成，表征为：验证点＝验证类型+验证元素+测试期望值。其中验证类型表示使用哪种验证方式，验证方式主要有元素文本值、界面标题、比较元素属性值、及数据库值。验证元素即需要验证的界面元素。测试期望值一般为测试用例中希望得到的值，如果测试得到的结果数据和数据希望得到的值的之间相差不大，则表明测试成功，待测应用软件对应的功能模块的功能是正常的；如果测试得到的结果数据和数据希望得到的值的之间相差较大，则表明测试失败，软件开发人员需要对该测试应用的底层源代码进行进一步完善。

本实施例中测试人员通过操作待测应用的目标界面来调动预设电子表格中的测试数据对该测试应用进行测试，可使不是很资深的测试人员也能灵活的对待测应用软件进行测试，提高了测试人员的操作体验。

此外，参考图4，图4为本发明一种数据测试装置的结构框图，所述装置包括：

获取模块10，用于获取待测应用的测试脚本以及与所述测试脚本相应的业务逻辑和测试数据，其中不同的测试数据对应所述待测应用中不同的功能模块；

可理解的是，本实施例的数据测试装置可以是一种用于进行软件测试的计算机应用程序，并装置于上述终端中，本实施例的执行主体为上述终端的处理器，所述待测应用是软件测试人员或开发人员需要测试的APP计算机应用程序软件，可以是装载于手机上的APP软件，也可以是装载于电脑终端上的程序软件，例如待测应用是一种商城管理APP应用程序，该商城管理APP应用程序可以根据按照功能的不同分成多个功能模块，例如商城管理APP应用程序可以具有一个发布视频的功能的模块，也可以具有一个维护视频的功能的模块等，也可以具有更多的功能模块。每个功能模块都对应至少一个测试脚本，本实施例中描述的测试脚本和目前常规的测试脚本一样，都是测试人员自己编写的程序脚本，而不同的测试脚本(即不同的功能模块)对应不同的业务逻辑和测试数据。

测试数据用于对功能模块进行测试，不同的测试数据对应所述待测应用中不同的功能模块。业务逻辑可理解为实现待测应用的某个的模块的功能需要执行的底层动作代码。

在具体实现中，为了区分，不同的功能模块都具有一个唯一的标识，不同的测试数据对应所述待测应用中不同的功能模块，为了表示测试脚本、测试脚本、业务逻辑、以及测试数据之间的关联性，可以表示如下：功能模块用modules-1表示代表该待测应用的第一个功能模块，与所述功能模块对应的有：测试脚本script-1，功能模块modules-1，业务逻辑1-logic-1，测试数据Test-Data-1-1-1。

编写模块20，用于将所述业务逻辑和各测试数据编写入预设电子表格中；

可以理解的是，一般的数据测试模型中都包含测试数据，而相应的测试脚本中依然有业务逻辑代码(即上述提到的底层动作代码)，当所述测试脚本中的业务逻辑发生变化时那么就需要测试人员手动重新对测试脚本进行编辑，因此测试脚本在前期就需要投入较多的开发脚本，测试脚本维护以及测试数据的维护和管理就显得比较困难繁琐。

本实施例中，以所述预设电子表格为Excel表格为例，不需要将测试人员输入的测试数据送入数据测试模型中，即测试脚本中不需要植入上述底层动作代码，测试人员在编写好测试用例后，直接将业务逻辑和与该业务逻辑对应的测试数据都集中编写入Excel表格中，当业务逻辑发送变化时，无需手动更改业务逻辑对应的测试脚本，进而能够提高测试效率。

具体地，本实施例以对某待测应用的功能模块modules-1进行测试为例，将本来应该在功能模块modules-1对应的测试脚本script-1的底层动作代码抽象为由关键字组成的表数据Action-1-Logic-1，即将对应的业务逻辑1-logic-1抽象为关键字组成的抽象代码，再将这些编写好的抽象代码编写入Excel表格中形成表数据Action-1-Logic-1。

即所述编写模块20具体用于将所述业务逻辑分解成多个关键字，将得到的多个关键字编写入预设电子表格中形成所述业务逻辑的表数据。

同时，由于后续测试中测试人员或者开发人员可能还需要使用测试脚本script-1，因此需要在测试脚本script-1中编写对应的代码指针，所述指针用于将原本应该填写底层动作代码的位置指向Excel表格中由关键字组成的表数据Action-1-Logic-1。这样当待测应用出现因程序升级或者更新的原因致使其底层动作代码需要更改时，测试人员无需对测试脚本中的内容进行更改，只需要对应修改Excel中的对应代码即可，进而减少测试人员的工作量。

接收模块30，用于接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块。

可理解的是，常规的测试方法需要调用测试脚本，这样的缺陷在于第一不方便测试人员的后期维护，第二测试人员在进行测试时不能看见测试数据，对应测试人员来说很不方便。而本实施例中，测试人员可以直接打开Excel表格，从Excel表格中选取目标测试数据，所述终端的处理器基于测试人员选取的目标测试数据确定哪个模块是当前需要接受测试的目标待测试模。

测试模块40，执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试。

具体地，所述测试模块40具体用于执行所述测试指令以调用所述业务逻辑的表数据对所述目标功能模块进行数据测试，最后会对所述目标功能模块的数据测试结果进行展示。

在具体实现中，本实施例的商城管理APP应用程序的标识为modules-1的功能模块为发布视频模块，对应的业务逻辑1-logic-1的为具有发布视频功能，运维对视频操作权限的控制的底层动作代码，上述底层动作代码会抽象为由关键字组成的抽象代码，并写入Excel表格中形成表数据Action-1-Logic-1。当商城管理APP应用程序响应所述测试指令时，会调用表数据Action-1-Logic-1以执行发布视频以及对不同视频进行权限设置操作的步骤，终端的处理器确定上述目标功能模块为modules-1后，前台后视频状态会发生变更，同时操作栏中操作按钮也会相应地更新，以形成测试结果数据。而发生状态变更的测试结果数据全部在excel表格中，只要对excel表格中每条数据进行测试，即可覆盖全部视频状态以及操作视频的功能点，并且对各个测试状态及操作按钮一目了然，也就是说测试人员能够第一时间非常清楚地掌握各项测试结果数据。如果测试人员后续对该待测应用的模块的功能需求或者测试需求有变更，可以直接通过修改预设电子表格中对应的数据来对待测应用的模块的功能需求或者测试需求进行更新，可维护型很高，提高了测试人员的工作效率。

进一步地，基于上述本发明数据测试装置的第一实施例，提出本发明数据测试装置的第二实施例；

本实施例中，所述接收模块30还用于响应于用户基于所述待测应用的目标界面输入的触发事件，并确定与所述触发事件对应的界面元素；根据所述触发事件从所述预设电子表格中选取目标测试数据的表数据，所述目标界面与所述目标测试数据相对应；根据所述触发事件、所述触发事件对应的界面元素以及所述目标测试数据的表数据生成测试指令；根据所述目标测试数据的表数据确定与所述目标测试数据对应的目标功能模块。

可理解的是，本实施例的待测应用以浏览器为例进行说明，将其功能模块的测试脚本script-1的底层动作代码抽象为由关键字组成的表数据：首先，对测试脚本script-1的操作进行解析，抽象为由关键字组成的表数据过程如下：操作＝操作命令+界面元素+输入值。浏览器的操作命令通常包括点击触发的动作和输入事件，它们统一表征为所述测试指令。界面元素可以包括界面按钮，文本框等控件，输入值通常是操作时需要被测试的目标功能模块的测试数据(即所述目标测试数据)。

此外，结合浏览器操作和验证点的需求，测试脚本script-1的底层动作代码还可以抽象为：操作＝动作+元素定位+测试数据。

进一步地，所述触发事件包括数据验证类型和测试期望值；

相应地，所述测试模块40还用于执行所述测试指令，从所述测试指令中确定验证类型和测试期望值；从业务逻辑的表数据中调用与所述验证类型对应的目标业务逻辑表数据，实现对所述目标功能模块进行数据测试。判断所述目标功能模块的数据测试结果与所述测试期望值之间的差值是否处于预设误差阈值范围；若是，则判定测试成功，若否，则判定测试失败。

可理解的是，所述测试脚本需要一个验证点，验证点是判断是否执行成功的关键。验证点可由三部分组成，表征为：验证点＝验证类型+验证元素+测试期望值。其中验证类型表示使用哪种验证方式，验证方式主要有元素文本值、界面标题、比较元素属性值、及数据库值。验证元素即需要验证的界面元素。测试期望值一般为测试用例中希望得到的值，如果测试得到的结果数据和数据希望得到的值的之间相差不大，则表明测试成功，待测应用软件对应的功能模块的功能是正常的；如果测试得到的结果数据和数据希望得到的值的之间相差较大，则表明测试失败，软件开发人员需要对该测试应用的底层源代码进行进一步完善。

本实施例中测试人员通过操作待测应用的目标界面来调动预设电子表格中的测试数据对该测试应用进行测试，可使不是很资深的测试人员也能灵活的对待测应用软件进行测试，提高了测试人员的操作体验。

此外，本发明实施例还提出一种存储介质，所述存储介质上存储有数据测试程序，所述数据测试程序被处理器执行时实现如上所述数据测试程序方法的步骤。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，终端，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种数据测试方法，其特征在于，所述数据测试方法包括以下步骤：

获取待测应用的测试脚本以及与所述测试脚本相应的业务逻辑和测试数据，其中不同的测试数据对应所述待测应用中不同的功能模块；

将所述业务逻辑和各测试数据编写入预设电子表格中；

接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块；

执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试。

2.如权利要求1所述的方法，其特征在于，所述将所述业务逻辑和各测试数据编写入预设电子表格中，具体包括：

将所述业务逻辑分解成多个关键字，将得到的多个关键字编写入预设电子表格中形成所述业务逻辑的表数据；

将各测试数据编写入预设电子表格中以形成各测试数据的表数据。

3.如权利要求2所述的方法，其特征在于，所述接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块，具体包括：

响应于用户基于所述待测应用的目标界面输入的触发事件，并确定与所述触发事件对应的界面元素；

根据所述触发事件从所述预设电子表格中选取目标测试数据的表数据，所述目标界面与所述目标测试数据相对应；

根据所述触发事件、所述触发事件对应的界面元素以及所述目标测试数据的表数据生成测试指令；

根据所述目标测试数据的表数据确定与所述目标测试数据对应的目标功能模块。

4.如权利要求2-3任一项所述的方法，其特征在于，所述执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试，具体包括：

执行所述测试指令以调用所述业务逻辑的表数据对所述目标功能模块进行数据测试。

5.如权利要求4所述的方法，其特征在于，所述触发事件包括数据验证类型；

相应地，所述执行所述测试指令以调用所述业务逻辑的表数据对所述目标功能模块进行数据测试，具体包括：

执行所述测试指令，从所述测试指令中确定验证类型；

从业务逻辑的表数据中调用与所述验证类型对应的目标业务逻辑表数据，实现对所述目标功能模块进行数据测试。

6.如权利要求5所述的方法，其特征在于，所述触发事件还包括测试期望值；

相应地，所述执行所述测试指令，从所述测试指令中确定验证类型，具体包括：

执行所述测试指令，从所述测试指令中确定验证类型和测试期望值；

相应地，从业务逻辑的表数据中调用与所述验证类型对应的目标业务逻辑表数据，实现对所述目标功能模块进行数据测试之后，还包括：

判断所述目标功能模块的数据测试结果与所述测试期望值之间的差值是否处于预设误差阈值范围；

若是，则判定测试成功，若否，则判定测试失败。

7.如权利要求1-3任一项所述的方法，其特征在于，所述预设电子表格为Excel表格；

相应地，所述执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试之后，还包括：

在所述Excel表格中对所述目标功能模块的数据测试结果进行展示。

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

获取模块，用于获取待测应用的测试脚本以及与所述测试脚本相应的业务逻辑和测试数据，其中不同的测试数据对应所述待测应用中不同的功能模块；

编写模块，用于将所述业务逻辑和各测试数据编写入预设电子表格中；

接收模块，用于接收用户基于所述预设电子表格中的目标测试数据输入的测试指令，确定与所述目标测试数据对应的目标功能模块；

测试模块，用于执行所述测试指令以调用所述业务逻辑对所述目标功能模块进行数据测试。

9.一种终端，其特征在于，所述终端包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的数据测试程序，所述数据测试程序配置为实现如权利要求1至7中任一项所述的数据测试方法的步骤。

10.一种存储介质，其特征在于，所述存储介质上存储有数据测试程序，所述数据测试程序被处理器执行时实现如权利要求1至7中任一项所述数据测试方法的步骤。