一种全局业务数据驱动自动测试方法、装置、设备和介质

摘要

本发明提供一种全局业务数据驱动自动测试方法、装置、设备和介质，方法包括对业务交易案例进行测试点分析，生成基准库案例；根据交易类型的不同，定义不同的交易版本，编写交易的逻辑流程脚本生成交易模板，抽取出变量字段，设计变量字段所需的具体测试数据或数据需求；统筹基准库案例数据需求，根据交易业务维度创建所需的数据模型，定义数据模型下的测试数据属性；创建不同的测试环境，依据已分析的数据模型，在每个环境下按数据属性逐个填入测试数据；根据给定的测试任务范围选定测试环境，自动获取案例的交易模板以及案例对应的测试数据，执行案例。本发明优点：以业务维度规范化的管理多环境下业务测试数据，可选择性的复用测试数据。

权利要求

1.一种全局业务数据驱动自动测试方法，其特征在于：所述方法包括：

对业务交易案例进行测试点分析，生成基准库案例；

根据交易类型的不同，定义不同的交易版本，在交易版本中填写交易字段参数；在交易版本下编写交易的逻辑流程脚本生成交易模板，从逻辑流程脚本中抽取出变量字段，并结合已分析的业务交易案例的测试点，设计变量字段所需的具体测试数据或数据需求；

统筹基准库案例的数据需求，根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性；创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据；

根据管理端给定的测试任务范围，选定测试环境；基于选定的测试环境，自动获取案例的交易模板以及案例数据需求所对应的测试数据，执行案例的测试操作；

所述的根据交易业务维度创建所需的数据模型具体为：

创建结构树，定义模块类别；具体包括：根据不同的业务维度来定义模块的类别；将同一维度下公共的、使用频率较高的数据，独立设计为一个公共模块；将同一维度下的其它数据，依据交易业务类型分别建立对应的模块；

在模块类别下，创建数据模型；具体包括：结合基准库案例分析所涉及的数据模型，将数据模型添加到对应的模块类别下。

2.根据权利要求1所述的一种全局业务数据驱动自动测试方法，其特征在于：所述方法还包括：在项目管理中对管理端下发的测试任务进行维护，对测试任务中涉及的测试任务范围进行引用；同时，提供相关资源的导入和导出功能。

3.根据权利要求1所述的一种全局业务数据驱动自动测试方法，其特征在于：所述的并定义数据模型下的测试数据属性具体为：分析数据模型的数据信息；具体包括：结合基准库案例分析出数据模型至少所需包括的数据信息；

分析数据字段属性；具体包括：根据实际的业务操作流转，分析测试案例所覆盖的各种类型及状态测试数据；增加字段属性态与不同业务系统之间的关联功能：给予字段默认的属性态值，在测试执行取数时，若业务系统下具有给定的属性态值，则取该业务系统下给定的属性态值；若业务系统下无给定的属性态值，则取默认的属性态值。

4.根据权利要求1所述的一种全局业务数据驱动自动测试方法，其特征在于：所述的创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据具体为：对基准库案例或部分交易案例配置对应的环境信息，从而创建出不同的测试环境；

对任一数据模型，选定测试环境；

对该数据模型按照所列出的字段要素依次填入测试数据，测试数据的来源包括：来源一：通过分析设计SQL语句从指定的环境存量数据中查询获取；

来源二：通过设计UI脚本或接口脚本实现自动化数据准备，再通过项目管理批量导入至对应的数据模型中；

区分测试数据的性质，具体包括：测试数据包括消耗型数据和非消耗型数据；对于消耗型数据，仅实现案例与数据1:1的关系；对于非消耗型数据，则可供基准库中的多个案例通过数据需求实现调用，从而实现案例与数据N：1的关系；测试数据拥有状态标记，在被案例调用执行时，根据测试数据的特性，对每个测试数据均进行状态标记。

5.根据权利要求1所述的一种全局业务数据驱动自动测试方法，其特征在于：在执行案例测试操作的过程中，所调用的测试数据均在数据池上进行记录和展示；对于发生变更且已设置数据需求的测试数据，则在测试通过后，自动更新数据管理中对应的测试数据信息。

6.一种全局业务数据驱动自动测试装置，其特征在于：所述装置包括分析管理模块、设计管理模块、数据管理模块以及执行管理模块；

所述分析管理模块，用于对业务交易案例进行测试点分析，生成基准库案例；

所述设计管理模块，用于根据交易类型的不同，定义不同的交易版本，在交易版本中填写交易字段参数；在交易版本下编写交易的逻辑流程脚本生成交易模板，从逻辑流程脚本中抽取出变量字段，并结合已分析的业务交易案例的测试点，设计变量字段所需的具体测试数据或数据需求；

所述数据管理模块，用于统筹基准库案例的数据需求，根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性；创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据；

所述执行管理模块，用于根据管理端给定的测试任务范围，选定测试环境；基于选定的测试环境，自动获取案例的交易模板以及案例数据需求所对应的测试数据，执行案例的测试操作；

所述的根据交易业务维度创建所需的数据模型具体为：

创建结构树，定义模块类别；具体包括：根据不同的业务维度来定义模块的类别；将同一维度下公共的、使用频率较高的数据，独立设计为一个公共模块；将同一维度下的其它数据，依据交易业务类型分别建立对应的模块；

在模块类别下，创建数据模型；具体包括：结合基准库案例分析所涉及的数据模型，将数据模型添加到对应的模块类别下。

7.根据权利要求6所述的一种全局业务数据驱动自动测试装置，其特征在于：所述装置还包括项目管理模块；

所述项目管理模块，用于在项目管理中对管理端下发的测试任务进行维护，对测试任务中涉及的测试任务范围进行引用；同时，提供相关资源的导入和导出功能。

8.根据权利要求6所述的一种全局业务数据驱动自动测试装置，其特征在于：所述的并定义数据模型下的测试数据属性具体为：分析数据模型的数据信息；具体包括：结合基准库案例分析出数据模型至少所需包括的数据信息；

分析数据字段属性；具体包括：根据实际的业务操作流转，分析测试案例所覆盖的各种类型及状态测试数据；增加字段属性态与不同业务系统之间的关联功能：给予字段默认的属性态值，在测试执行取数时，若业务系统下具有给定的属性态值，则取该业务系统下给定的属性态值；若业务系统下无给定的属性态值，则取默认的属性态值；

所述的创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据具体为：对基准库案例或部分交易案例配置对应的环境信息，从而创建出不同的测试环境；

对任一数据模型，选定测试环境；

对该数据模型按照所列出的字段要素依次填入测试数据，测试数据的来源包括：来源一：通过分析设计SQL语句从指定的环境存量数据中查询获取；

来源二：通过设计UI脚本或接口脚本实现自动化数据准备，再通过项目管理批量导入至对应的数据模型中；

区分测试数据的性质，具体包括：测试数据包括消耗型数据和非消耗型数据；对于消耗型数据，仅实现案例与数据1:1的关系；对于非消耗型数据，则可供基准库中的多个案例通过数据需求实现调用，从而实现案例与数据N：1的关系；测试数据拥有状态标记，在被案例调用执行时，根据测试数据的特性，对每个测试数据均进行状态标记。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1至5任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至5任一项所述的方法。

说明书

一种全局业务数据驱动自动测试方法、装置、设备和介质

技术领域

[0001] 本发明涉及计算机技术领域，特别涉及一种全局业务数据驱动自动测试方法、装置、设备和介质。

背景技术

[0002] 在当前的自动化测试领域中，很多自动化测试系统通过分析、设计、执行来实现自动化测试流程，而作为自动化测试主要来源之一的测试数据并没有很好的在系统层面进行统筹考虑，导致在实际测试过程中，测试数据的分析及准备作为一项独立于系统的活动进行，从而导致管理不够规范、数据冗余、更新维护工作量大，不利于测试人员进一步的了解所需测试数据类型及数据量，造成管理难度大、测试效率低、数据难以移植复用。

[0003] 针对以上问题，现有期刊、专利文献提及了一些应对的措施和方法，如期刊《信息化研究》2015年01期论文《一种数据驱动的软件接口自动化测试框架的设计与实现》，提出了一种自动化接口测试框架，采用形式化语言XML存储数据，实现数据与脚本的分离和基于关键字的的自动化测试用例生成功能，有效地缩短了接口测试时间，提高了软件测试工作效率。

[0004] 专利文献包括：公开号为105260297B，公开日为2017‑12‑05的中国发明专利公开了一种测试数据管理系统和方法，系统包括管理端、存储单元、测试端及调度执行器，实现测试管理系统和自动化测试系统将对应的数据信息进行统一化管理以及方便对测试数据及时的查看。公开号为110471967A，公开日为2019‑11‑19的中国发明专利公开了一种测试数据管理系统及方法，用于管理测试产生的测试数据，系统包括数据整合平台、数据存储器和网站服务器，数据整合平台通过对不同平台的测试数据进行跨平台整合，以统一的数据格式存储至数据存储器，使得网站服务器可以直接调用服务器中的测试数据，以达到节省数据传递所需的时间及流量。公开号为1877543A，公开日为2006‑12‑13的中国发明专利公开了一种数据驱动的自动化测试方法，系统包括测试平台、函数库、测试工具/仪器和被测设备，通过测试平台中的运行引擎获取关联模块的数据信息并加载函数库，驱动测试逻辑对被测设备进行测试，有效降低维护成本、提高测试效率。公开号为109408398A，公开日为2019‑03‑01的中国发明专利公开了一种接口自动化测试装置及方法，包括源数据模块、数据分析模块、数据转换模块、自动化测试执行模块、测试结果收集显示模块等，通过提取并分析源数据模块中的接口源数据，以获取接口测试用数据，用以自动生成测试用例与执行，有效提升工作效率。

[0005] 虽然上述自动化测试管理系统和方法均提及了自动化测试流程中的测试数据，但对测试数据的管理未进行全局性地整合规划，测试数据只是对应于项目案例测试所需而产生，存在数据量大，部分冗余的现状，不利于对数据进行全局性规范化管理；同时，覆盖交易业务逻辑所需的业务测试数据类型繁多，未根据有关维度对测试数据进行归类管理，不利于后期选择性地复用测试数据；也未实现测试执行中对测试数据的共享或独占控制、执行后对测试数据信息地自动更新，存在测试数据调用冲突及测试数据信息滞后。

发明内容

[0006] 本发明要解决的技术问题，在于提供一种全局业务数据驱动自动测试方法、装置、设备和介质，解决现有自动化测试流程中未对多环境下测试数据进行全局性整合规划、测试数据调用冲突、数据信息更新滞后以及执行前需要耗费时间提前生成可执行脚本，导致不利于对数据进行规范化管理、不利于选择性复用测试数据以及降低可执行效率的问题。

[0007] 第一方面，本发明提供了一种全局业务数据驱动自动测试方法，所述方法包括：

[0008] 对业务交易案例进行测试点分析，生成基准库案例；

[0009] 根据交易类型的不同，定义不同的交易版本，在交易版本中填写交易字段参数；在交易版本下编写交易的逻辑流程脚本生成交易模板，从逻辑流程脚本中抽取出变量字段，并结合已分析的业务交易案例的测试点，设计变量字段所需的具体测试数据或数据需求；

[0010] 统筹基准库案例的数据需求，根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性；创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据；

[0011] 根据管理端给定的测试任务范围，选定测试环境；基于选定的测试环境，自动获取案例的交易模板以及案例数据需求所对应的测试数据，执行案例的测试操作。

[0012] 进一步的，所述方法还包括：

[0013] 在项目管理中对管理端下发的测试任务进行维护，对测试任务中涉及的测试任务范围进行引用；同时，提供相关资源的导入和导出功能。

[0014] 进一步的，所述的根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性具体为：

[0015] 创建结构树，定义模块类别；具体包括：根据不同的业务维度来定义模块的类别；将同一维度下公共的、使用频率较高的数据，独立设计为一个公共模块；将同一维度下的其它数据，依据交易业务类型分别建立对应的模块；

[0016] 在模块类别下，创建数据模型；具体包括：结合基准库案例分析所涉及的数据模型，将数据模型添加到对应的模块类别下；

[0017] 分析数据模型的数据信息；具体包括：结合基准库案例分析出数据模型至少所需包括的数据信息；

[0018] 分析数据字段属性；具体包括：根据实际的业务操作流转，分析测试案例所覆盖的各种类型及状态测试数据；增加字段属性态与不同业务系统之间的关联功能：给予字段默认的属性态值，在测试执行取数时，若业务系统下具有给定的属性态值，则取该业务系统下给定的属性态值；若业务系统下无给定的属性态值，则取默认的属性态值。

[0019] 进一步的，所述的创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据具体为：

[0020] 对基准库案例或部分交易案例配置对应的环境信息，从而创建出不同的测试环境；

[0021] 对任一数据模型，选定测试环境；

[0022] 对该数据模型按照所列出的字段要素依次填入测试数据，测试数据的来源包括：

[0023] 来源一：通过分析设计SQL语句从指定的环境存量数据中查询获取；

[0024] 来源二：通过设计UI脚本或接口脚本实现自动化数据准备，再通过项目管理批量导入至对应的数据模型中；

[0025] 区分测试数据的性质，具体包括：测试数据包括消耗型数据和非消耗型数据；对于消耗型数据，仅实现案例与数据1:1的关系；对于非消耗型数据，则可供基准库中的多个案例通过数据需求实现调用，从而实现案例与数据N：1的关系；测试数据拥有状态标记，在被案例调用执行时，根据测试数据的特性，对每个测试数据均进行状态标记。

[0026] 进一步的，在执行案例测试操作的过程中，所调用的测试数据均在数据池上进行记录和展示；对于发生变更且已设置数据需求的测试数据，则在测试通过后，自动更新数据管理中对应的测试数据信息。

[0027] 第二方面，本发明提供了一种全局业务数据驱动自动测试装置，所述装置包括分析管理模块、设计管理模块、数据管理模块以及执行管理模块；

[0028] 所述分析管理模块，用于对业务交易案例进行测试点分析，生成基准库案例；

[0029] 所述设计管理模块，用于根据交易类型的不同，定义不同的交易版本，在交易版本中填写交易字段参数；在交易版本下编写交易的逻辑流程脚本生成交易模板，从逻辑流程脚本中抽取出变量字段，并结合已分析的业务交易案例的测试点，设计变量字段所需的具体测试数据或数据需求；

[0030] 所述数据管理模块，用于统筹基准库案例的数据需求，根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性；创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据；

[0031] 所述执行管理模块，用于根据管理端给定的测试任务范围，选定测试环境；基于选定的测试环境，自动获取案例的交易模板以及案例数据需求所对应的测试数据，执行案例的测试操作。

[0032] 进一步的，所述装置还包括项目管理模块；

[0033] 所述项目管理模块，用于在项目管理中对管理端下发的测试任务进行维护，对测试任务中涉及的测试任务范围进行引用；同时，提供相关资源的导入和导出功能。

[0034] 进一步的，所述的根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性具体为：

[0035] 创建结构树，定义模块类别；具体包括：根据不同的业务维度来定义模块的类别；将同一维度下公共的、使用频率较高的数据，独立设计为一个公共模块；将同一维度下的其它数据，依据交易业务类型分别建立对应的模块；

[0036] 在模块类别下，创建数据模型；具体包括：结合基准库案例分析所涉及的数据模型，将数据模型添加到对应的模块类别下；

[0037] 分析数据模型的数据信息；具体包括：结合基准库案例分析出数据模型至少所需包括的数据信息；

[0038] 分析数据字段属性；具体包括：根据实际的业务操作流转，分析测试案例所覆盖的各种类型及状态测试数据；增加字段属性态与不同业务系统之间的关联功能：给予字段默认的属性态值，在测试执行取数时，若业务系统下具有给定的属性态值，则取该业务系统下给定的属性态值；若业务系统下无给定的属性态值，则取默认的属性态值；

[0039] 所述的创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据具体为：

[0040] 对基准库案例或部分交易案例配置对应的环境信息，从而创建出不同的测试环境；

[0041] 对任一数据模型，选定测试环境；

[0042] 对该数据模型按照所列出的字段要素依次填入测试数据，测试数据的来源包括：

[0043] 来源一：通过分析设计SQL语句从指定的环境存量数据中查询获取；

[0044] 来源二：通过设计UI脚本或接口脚本实现自动化数据准备，再通过项目管理批量导入至对应的数据模型中；

[0045] 区分测试数据的性质，具体包括：测试数据包括消耗型数据和非消耗型数据；对于消耗型数据，仅实现案例与数据1:1的关系；对于非消耗型数据，则可供基准库中的多个案例通过数据需求实现调用，从而实现案例与数据N：1的关系；测试数据拥有状态标记，在被案例调用执行时，根据测试数据的特性，对每个测试数据均进行状态标记。

[0046] 第三方面，本发明提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面所述的方法。

[0047] 第四方面，本发明提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面所述的方法。

[0048] 本发明实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：规范化的管理业务测试数据；通过引入数据管理功能，自动化流程的所有活动都可以在系统中进行管理，特别是数据的可视化管理，可便于每次测试执行前，了解各类测试数据的类型及测试的数据量。选择性的复用测试数据；以业务维度对数据模型进行分类，同一基准库案例在不同项目上同时进行自动化回归测试时，可以根据案例范围，有针对性地导出对应的测试数据及其他资源再导入到新项目中，省去了以往整个基准库重新部署的操作；此外，测试数据可以根据项目业务需要按层级批量导出，供手工业务测试使用。数据一致性同步；通过设置数据需求功能，在测试执行时自动获取对应的数据，且在执行完成后，自动更新数据信息，能够保持数据的一致性。提升执行效率；测试执行只需选择对应的测试环境，即可在执行时自动获取交易模板及所需的测试数据，改变了以往更新交易模板或测试数据需要重新生成可执行交易脚本的行为，有效的提升了案例的执行效率。

[0049] 上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

[0050] 下面参照附图结合实施例对本发明作进一步的说明。

[0051] 图1为本发明实施例一中一种全局业务数据驱动自动测试方法的执行流程图；

[0052] 图2为本发明实施例二中一种全局业务数据驱动自动测试装置的结构示意图；

[0053] 图3为本发明实施例三中电子设备的结构示意图；

[0054] 图4为本发明实施例四中介质的结构示意图。

具体实施方式

[0055] 本申请实施例通过提供一种全局业务数据驱动自动测试方法、装置、设备及介质，用于解决现有自动化测试流程中未对多环境下测试数据进行全局性整合规划、测试数据调用冲突、数据信息更新滞后以及执行前需要耗费时间提前生成可执行脚本，导致不利于对数据进行规范化管理、不利于选择性复用测试数据以及降低可执行效率的技术问题。

[0056] 实施例一

[0057] 本实施例提供一种全局业务数据驱动自动测试方法，如图1所示，所述方法包括：

[0058] 对业务交易案例进行测试点分析，生成基准库案例；在具体实施时，当有新的业务交易案例产生时，就需要对新的业务交易案例进行测试点分析，并创建新的基准库案例。同时，在具体生成基准库案例时，可基于对交易字段的属性态进行分析来生成自动化测试案例；也可直接导入手工测试案例进行复用来生成新交易的自动化测试案例；

[0059] 根据交易类型的不同，定义不同的交易版本，在交易版本中填写交易字段参数，所述交易字段参数可以包括字段名称、参数类型、参数长度、字段默认值、所属报文体等信息；同时，在需要扩展新字段参数时，可根据需要直接新增交易版本或在原始交易版本的基础上进行更新；

[0060] 在交易版本下编写交易的逻辑流程脚本生成交易模板，从逻辑流程脚本中抽取出变量字段；在具体实施时，对于UI交易和接口交易可分别设计生成不同的交易模板；对于发往核心系统及电子银行服务平台等通用接口交易，可设计交易模板由主控、请求头、请求体、应答头、应答体五个部分组成，主控用于定义交易码、编码格式、通讯方式及交易主要流程分支设计，交易的具体业务操作及处理逻辑则根据实际业务流程分别填写于请求头、请求体、应答头、应答体四部分中。对于普通UI界面操作交易，可根据交易业务不同的界面操作流程进行设计，如账户开户，可设计为开户主流程逻辑及客户信息维护逻辑两个部分。同时，对于前期已定义的字段参数，在交易模板中若参数没有实际的测试点，或在该交易所分析的案例测试点中只能为某一特定数值，则可直接在交易模板中赋予该参数为空或默认值，而对于随着测试案例覆盖的业务规则不同，导致某些参数需要随着不同的测试点而赋予不同的测试数据时，则这些字段在交易模板中将被定义为变量并进行抽取。

[0061] 结合已分析的业务交易案例的测试点，设计变量字段所需的具体测试数据或数据需求；在具体实施时，需根据已分析的业务交易案例生成的测试点，并结合交易模板中抽取出来的变量参数，对每个测试案例涉及的各个变量参数填入测试数据或数据需求。对于公用及受测试环境改变而变化等类型的测试数据可以存放到数据管理中，此处只需在抽取出来的变量中设置数据需求，以实现执行测试时该变量能够依据数据需求，从数据管理指定的数据模型中准确地获取所需测试数据，从而可避免相同性质的测试数据重复填写，以及因测试环境改变需要不断更新每个测试案例对应的测试数据。

[0062] 统筹基准库案例的数据需求，根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性；创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据，从而全局性、规范化的管理各个环境的测试数据；

[0063] 根据管理端给定的测试任务范围，选定测试环境；基于选定的测试环境，自动获取案例的交易模板以及案例数据需求所对应的测试数据，执行案例的测试操作。

[0064] 在本实施例中，所述方法还包括：

[0065] 在项目管理中对管理端下发的测试任务进行维护，对测试任务中涉及的测试任务范围进行引用；同时，提供相关资源的导入和导出功能，即在具体实施时，可对交易模板、函数、测试案例、测试数据等进行导入或导出操作，以实现不同项目间相关资源的复用。

[0066] 所述的根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性具体为：

[0067] 创建结构树，定义模块类别；具体包括：根据不同的业务维度来定义模块的类别；将同一维度下公共的、使用频率较高的数据，独立设计为一个公共模块；将同一维度下的其它数据，依据交易业务类型分别建立对应的模块，例如，针对中间业务、卡业务、电子银行服务平台等，可分别建立对应的模块；

[0068] 在模块类别下，创建数据模型；具体包括：结合基准库案例分析所涉及的数据模型，将数据模型添加到对应的模块类别下，以便于在测试时可根据所选的测试任务范围，只更新对应模块下的数据模型的测试数据；例如，对于机构、柜员、证件等公共类型的数据，可以添加到公共模块下；又如，对于一卡通信息、社保卡信息、农民工卡信息等类型的数据，则可以依据业务类型添加到卡业务模块类别下；具体的数据类型层级结构如表1：

[0069] 表1数据模型层级结构

[0070]

[0071]

[0072] 分析数据模型的数据信息；具体包括：结合基准库案例分析出数据模型至少所需包括的数据信息，以足够满足案例正常测试的执行；例如，对于柜员数据模型，结合某一基准库案例需求，可能至少应包括柜员名称、柜员号、柜员密码、柜员级别、所属机构、有无尾箱等必要信息；

[0073] 分析数据字段属性；具体包括：根据实际的业务操作流转，分析测试案例所覆盖的各种类型及状态测试数据，例如，对于账号，按照实际业务办理及操作存在正常、挂失、冻结、销户等属性，具体如以下表2：

[0074] 表2数据模型要素表

[0075]

[0076]

[0077] 增加字段属性态与不同业务系统之间的关联功能，以解决同一个字段在不同系统中属性态值不一致的问题：给予字段默认的属性态值，在测试执行取数时，若业务系统下具有给定的属性态值，则取该业务系统下给定的属性态值；若业务系统下无给定的属性态值，则取默认的属性态值；以“币种”字段为例，展示“币种”在不同业务系统中的属性值，具体如以下表3：

[0078] 表3业务系统‑字段属性取值对应表

[0079]

[0080] 由上述可知，本发明通过对自动化基准案例库做好数据模型的规划，能够避免数据模型重复设计，存放杂乱无章，无法快速定位到所需数据模型位置的问题。同时，以树形层级方式对数据模型进行划分归类，可以有效避免冗余设计，且能够直观了解、快速定位所需数据模型所在位置。

[0081] 在本实施例中，所述的创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据具体为：

[0082] 对基准库案例或部分交易案例配置对应的环境信息，从而创建出不同的测试环境；其中，环境信息可包括所属环境、IP地址、通讯方式、字符集等内容。对于已配好环境信息的基准库案例，在执行测试时，可直接选择已配置的测试环境执行具体测试操作；

[0083] 对任一数据模型，选定测试环境；

[0084] 对该数据模型按照所列出的字段要素依次填入测试数据，测试数据的来源包括：

[0085] 来源一：通过分析设计SQL语句从指定的环境存量数据中查询获取；

[0086] 来源二：通过设计UI脚本或接口脚本实现自动化数据准备，再通过项目管理批量导入至对应的数据模型中；

[0087] 区分测试数据的性质，具体包括：测试数据包括消耗型数据和非消耗型数据；对于消耗型数据，仅实现案例与数据1:1的关系；对于非消耗型数据，则可供基准库中的多个案例通过数据需求实现调用，从而实现案例与数据N：1的关系；测试数据拥有状态标记，在被案例调用执行时，根据测试数据的特性，对每个测试数据均进行状态标记。在具体实施时，根据测试数据的特性，每个测试数据均会被标记为未使用、锁定、共享、已使用等状态之一：对于设置“共享”的测试数据，则同一时刻可被多个执行案例获取使用；对于设置“锁定”的测试数据，说明已被某个执行案例获取使用，则其他执行案例需从其他可被使用状态的测试数据中获取，若无满足状态的测试数据，则该执行案例将暂停执行；

[0088] 本发明通过正确标记每个测试数据的使用状态，能够避免非可共用数据被多个执行案例的脚本同时调用，进而可避免引起数据冲突问题。对于业务交易的测试执行操作后会改变测试数据的属性，则通过在案例中设置数据需求，可在测试通过后，自动更新测试数据信息，以确保测试数据信息会随着业务操作的进行而自动更新；以“柜员”为例，展示该数据模型下的测试数据，如表4：

[0089] 表4数据模型‑测试数据表

[0090]

[0091]

[0092] 在本实施例中，在执行案例测试操作的过程中，所调用的测试数据均在数据池上进行记录和展示；对于发生变更且已设置数据需求的测试数据，则在测试通过后，自动更新数据管理中对应的测试数据信息。在具体实施时，测试执行过程中的日志、截图、报表信息等可实时查看，同时报表数据也会自动上传给管理端，便于管理人员查阅。

[0093] 通过引入本发明具有全局业务数据管理功能的技术方案，有效地管理了各个环境的测试数据，改变了以往按不同环境版本分库部署存放测试数据的现状，以往部署一个独立的基准库需耗费30分钟，引入后不仅无需再进行分库部署操作，而且能够按照不同项目测试需求，按层级的导出相应业务层级下的测试数据进行复用；

[0094] 在前期的自动化回归测试中，多个案例对同一测试数据的使用容易引起冲突，如同一柜员在多个测试案例中被采用，则已登录柜员被后续案例执行释放，通过本发明中增加对测试数据性质的判断与控制，则不同案例在执行测试时，不仅需要获取所需测试数据，而且需要保证测试数据当前是可使用状态，从而提高了数据获取的准确性及测试数据的利用率。

[0095] 在执行测试时，只需选择对应测试环境，即可根据选择的测试案例范围，在执行时自动读取案例对应的交易模板及数据管理中的测试数据，省去了以往在执行前需要花时间生成可执行测试脚本，在以往400多个案例生成可执行测试脚本大概要花掉1分钟，在服务器资源一定的情况下，生成时间与案例数呈非线性增长关系，在以往的测试任务中，在一个客户端上生成20000多个案例的可执行测试脚本，至少需要耗费200分钟，而通过本发明的技术方案，同样的工作量每次可节约至少200分钟。

[0096] 基于同一发明构思，本申请还提供了与实施例一中的方法对应的装置，详见实施例二。

[0097] 实施例二

[0098] 在本实施例中提供了一种全局业务数据驱动自动测试装置，如图2所示，所述装置包括分析管理模块、设计管理模块、数据管理模块以及执行管理模块；

[0099] 所述分析管理模块，用于对业务交易案例进行测试点分析，生成基准库案例；在具体实施时，当有新的业务交易案例产生时，就需要对新的业务交易案例进行测试点分析，并创建新的基准库案例。同时，在具体生成基准库案例时，可基于对交易字段的属性态进行分析来生成自动化测试案例；也可直接导入手工测试案例进行复用来生成新交易的自动化测试案例；

[0100] 所述设计管理模块，用于根据交易类型的不同，定义不同的交易版本，在交易版本中填写交易字段参数，所述交易字段参数可以包括字段名称、参数类型、参数长度、字段默认值、所属报文体等信息；同时，在需要扩展新字段参数时，可根据需要直接新增交易版本或在原始交易版本的基础上进行更新；

[0101] 在交易版本下编写交易的逻辑流程脚本生成交易模板，从逻辑流程脚本中抽取出变量字段；在具体实施时，对于UI交易和接口交易可分别设计生成不同的交易模板；对于发往核心系统及电子银行服务平台等通用接口交易，可设计交易模板由主控、请求头、请求体、应答头、应答体五个部分组成，主控用于定义交易码、编码格式、通讯方式及交易主要流程分支设计，交易的具体业务操作及处理逻辑则根据实际业务流程分别填写于请求头、请求体、应答头、应答体四部分中。对于普通UI界面操作交易，可根据交易业务不同的界面操作流程进行设计，如账户开户，可设计为开户主流程逻辑及客户信息维护逻辑两个部分。同时，对于前期已定义的字段参数，在交易模板中若参数没有实际的测试点，或在该交易所分析的案例测试点中只能为某一特定数值，则可直接在交易模板中赋予该参数为空或默认值，而对于随着测试案例覆盖的业务规则不同，导致某些参数需要随着不同的测试点而赋予不同的测试数据时，则这些字段在交易模板中将被定义为变量并进行抽取。

[0102] 结合已分析的业务交易案例的测试点，设计变量字段所需的具体测试数据或数据需求；在具体实施时，需根据已分析的业务交易案例生成的测试点，并结合交易模板中抽取出来的变量参数，对每个测试案例涉及的各个变量参数填入测试数据或数据需求。对于公用及受测试环境改变而变化等类型的测试数据可以存放到数据管理中，此处只需在抽取出来的变量中设置数据需求，以实现执行测试时该变量能够依据数据需求，从数据管理指定的数据模型中准确地获取所需测试数据，从而可避免相同性质的测试数据重复填写，以及因测试环境改变需要不断更新每个测试案例对应的测试数据。

[0103] 所述数据管理模块，用于统筹基准库案例的数据需求，根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性；创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据，从而全局性、规范化的管理各个环境的测试数据；

[0104] 所述执行管理模块，用于根据管理端给定的测试任务范围，选定测试环境；基于选定的测试环境，自动获取案例的交易模板以及案例数据需求所对应的测试数据，执行案例的测试操作。

[0105] 在本实施例中，所述装置还包括项目管理模块；

[0106] 所述项目管理模块，用于在项目管理中对管理端下发的测试任务进行维护，对测试任务中涉及的测试任务范围进行引用；同时，提供相关资源的导入和导出功能，即在具体实施时，可对交易模板、函数、测试案例、测试数据等进行导入或导出操作，以实现不同项目间相关资源的复用。

[0107] 所述的根据交易业务维度创建所需的数据模型，并定义数据模型下的测试数据属性具体为：

[0108] 创建结构树，定义模块类别；具体包括：根据不同的业务维度来定义模块的类别；将同一维度下公共的、使用频率较高的数据，独立设计为一个公共模块；将同一维度下的其它数据，依据交易业务类型分别建立对应的模块，例如，针对中间业务、卡业务、电子银行服务平台等，可分别建立对应的模块；

[0109] 在模块类别下，创建数据模型；具体包括：结合基准库案例分析所涉及的数据模型，将数据模型添加到对应的模块类别下，以便于在测试时可根据所选的测试任务范围，只更新对应模块下的数据模型的测试数据；例如，对于机构、柜员、证件等公共类型的数据，可以添加到公共模块下；又如，对于一卡通信息、社保卡信息、农民工卡信息等类型的数据，则可以依据业务类型添加到卡业务模块类别下；具体的数据类型层级结构如表1：

[0110] 表1数据模型层级结构

[0111]

[0112] 分析数据模型的数据信息；具体包括：结合基准库案例分析出数据模型至少所需包括的数据信息，以足够满足案例正常测试的执行；例如，对于柜员数据模型，结合某一基准库案例需求，可能至少应包括柜员名称、柜员号、柜员密码、柜员级别、所属机构、有无尾箱等必要信息；

[0113] 分析数据字段属性；具体包括：根据实际的业务操作流转，分析测试案例所覆盖的各种类型及状态测试数据，例如，对于账号，按照实际业务办理及操作存在正常、挂失、冻结、销户等属性，具体如以下表2：

[0114] 表2数据模型要素表

[0115]

[0116] 增加字段属性态与不同业务系统之间的关联功能，以解决同一个字段在不同系统中属性态值不一致的问题：给予字段默认的属性态值，在测试执行取数时，若业务系统下具有给定的属性态值，则取该业务系统下给定的属性态值；若业务系统下无给定的属性态值，则取默认的属性态值；以“币种”字段为例，展示“币种”在不同业务系统中的属性值，具体如以下表3：

[0117] 表3业务系统‑字段属性取值对应表

[0118]

[0119] 由上述可知，本发明通过对自动化基准案例库做好数据模型的规划，能够避免数据模型重复设计，存放杂乱无章，无法快速定位到所需数据模型位置的问题。同时，以树形层级方式对数据模型进行划分归类，可以有效避免冗余设计，且能够直观了解、快速定位所需数据模型所在位置。

[0120] 在本实施例中，所述的创建不同的测试环境，依据已分析的数据模型，在每个测试环境下按数据属性逐个填入测试数据具体为：

[0121] 对基准库案例或部分交易案例配置对应的环境信息，从而创建出不同的测试环境；其中，环境信息可包括所属环境、IP地址、通讯方式、字符集等内容。对于已配好环境信息的基准库案例，在执行测试时，可直接选择已配置的测试环境执行具体测试操作；

[0122] 对任一数据模型，选定测试环境；

[0123] 对该数据模型按照所列出的字段要素依次填入测试数据，测试数据的来源包括：

[0124] 来源一：通过分析设计SQL语句从指定的环境存量数据中查询获取；

[0125] 来源二：通过设计UI脚本或接口脚本实现自动化数据准备，再通过项目管理批量导入至对应的数据模型中；

[0126] 区分测试数据的性质，具体包括：测试数据包括消耗型数据和非消耗型数据；对于消耗型数据，仅实现案例与数据1:1的关系；对于非消耗型数据，则可供基准库中的多个案例通过数据需求实现调用，从而实现案例与数据N：1的关系；测试数据拥有状态标记，在被案例调用执行时，根据测试数据的特性，对每个测试数据均进行状态标记。在具体实施时，根据测试数据的特性，每个测试数据均会被标记为未使用、锁定、共享、已使用等状态之一：对于设置“共享”的测试数据，则同一时刻可被多个执行案例获取使用；对于设置“锁定”的测试数据，说明已被某个执行案例获取使用，则其他执行案例需从其他可被使用状态的测试数据中获取，若无满足状态的测试数据，则该执行案例将暂停执行；

[0127] 本发明通过正确标记每个测试数据的使用状态，能够避免非可共用数据被多个执行案例的脚本同时调用，进而可避免引起数据冲突问题。对于业务交易的测试执行操作后会改变测试数据的属性，则通过在案例中设置数据需求，可在测试通过后，自动更新测试数据信息，以确保测试数据信息会随着业务操作的进行而自动更新；以“柜员”为例，展示该数据模型下的测试数据，如表4：

[0128] 表4数据模型‑测试数据表

[0129]

[0130] 在本实施例中，在执行案例测试操作的过程中，所调用的测试数据均在数据池上进行记录和展示；对于发生变更且已设置数据需求的测试数据，则在测试通过后，自动更新数据管理中对应的测试数据信息。在具体实施时，测试执行过程中的日志、截图、报表信息等可实时查看，同时报表数据也会自动上传给管理端，便于管理人员查阅。

[0131] 通过引入本发明具有全局业务数据管理功能的技术方案，有效地管理了各个环境的测试数据，改变了以往按不同环境版本分库部署存放测试数据的现状，以往部署一个独立的基准库需耗费30分钟，引入后不仅无需再进行分库部署操作，而且能够按照不同项目测试需求，按层级的导出相应业务层级下的测试数据进行复用；

[0132] 在前期的自动化回归测试中，多个案例对同一测试数据的使用容易引起冲突，如同一柜员在多个测试案例中被采用，则已登录柜员被后续案例执行释放，通过本发明中增加对测试数据性质的判断与控制，则不同案例在执行测试时，不仅需要获取所需测试数据，而且需要保证测试数据当前是可使用状态，从而提高了数据获取的准确性及测试数据的利用率。

[0133] 在执行测试时，只需选择对应测试环境，即可根据选择的测试案例范围，在执行时自动读取案例对应的交易模板及数据管理中的测试数据，省去了以往在执行前需要花时间生成可执行测试脚本，在以往400多个案例生成可执行测试脚本大概要花掉1分钟，在服务器资源一定的情况下，生成时间与案例数呈非线性增长关系，在以往的测试任务中，在一个客户端上生成20000多个案例的可执行测试脚本，至少需要耗费200分钟，而通过本发明的技术方案，同样的工作量每次可节约至少200分。

[0134] 由于本发明实施例二所介绍的装置，为实施本发明实施例一的方法所采用的装置，故而基于本发明实施例一所介绍的方法，本领域所属人员能够了解该装置的具体结构及变形，故而在此不再赘述。凡是本发明实施例一的方法所采用的装置都属于本发明所欲保护的范围。

[0135] 基于同一发明构思，本申请提供了实施例一对应的电子设备实施例，详见实施例三。

[0136] 实施例三

[0137] 本实施例提供了一种电子设备，如图3所示，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时，可以实现实施例一中任一实施方式。

[0138] 由于本实施例所介绍的电子设备为实施本申请实施例一中方法所采用的设备，故而基于本申请实施例一中所介绍的方法，本领域所属技术人员能够了解本实施例的电子设备的具体实施方式以及其各种变化形式，所以在此对于该电子设备如何实现本申请实施例中的方法不再详细介绍。只要本领域所属技术人员实施本申请实施例中的方法所采用的设备，都属于本申请所欲保护的范围。

[0139] 基于同一发明构思，本申请提供了实施例一对应的存储介质，详见实施例四。

[0140] 实施例四

[0141] 本实施例提供一种计算机可读存储介质，如图4所示，其上存储有计算机程序，该计算机程序被处理器执行时，可以实现实施例一中任一实施方式。

[0142] 本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD‑ROM、光学存储器等)上实施的计算机程序产品的形式。

[0143] 本发明是参照根据本发明实施例的方法、装置、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

[0144] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

[0145] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

[0146] 综上所述，本发明具有如下优点：规范化的管理业务测试数据；通过引入数据管理功能，自动化流程的所有活动都可以在系统中进行管理，特别是数据的可视化管理，可便于每次测试执行前，了解各类测试数据的类型及测试的数据量。选择性的复用测试数据；以业务维度对数据模型进行分类，同一基准库案例在不同项目上同时进行自动化回归测试时，可以根据案例范围，有针对性地导出对应的测试数据及其他资源再导入到新项目中，省去了以往整个基准库重新部署的操作；此外，测试数据可以根据项目业务需要按层级批量导出，供手工业务测试使用。数据一致性同步；通过设置数据需求功能，在测试执行时自动获取对应的数据，且在执行完成后，自动更新数据信息，能够保持数据的一致性。提升执行效率；测试执行只需选择对应的测试环境，即可在执行时自动获取交易模板及所需的测试数据，改变了以往更新交易模板或测试数据需要重新生成可执行交易脚本的行为，有效的提升了案例的执行效率。

[0147] 虽然以上描述了本发明的具体实施方式，但是熟悉本技术领域的技术人员应当理解，我们所描述的具体的实施例只是说明性的，而不是用于对本发明的范围的限定，熟悉本领域的技术人员在依照本发明的精神所作的等效的修饰以及变化，都应当涵盖在本发明的权利要求所保护的范围内。