基于大数据的数据核对方法、装置、电子设备及存储介质与流程

1.本技术涉及大数据技术领域，尤其涉及一种基于大数据的数据核对方法、装置、电子设备及存储介质。


背景技术：

2.随着我国经济的快速发展，人们生活水平不断提高，风险保障意识也日益增强，为保险行业的快速发展提供了良好的外部环境，各个保险公司也因此不断推出符合人们需求的保险产品。
3.现有的，开发人员根据保险产品的属性，在配置系统中进行统筹配置，便可以得到一款新的保险产品。对于配置获得的保险产品，为了保证其配置的正确性，需要对产品进行大量的测试工作，以确保保险产品能够顺利的投放市场。
4.但是保险产品种类多，不同保险产品的数据计算规则不同，针对不同的保险产品还有不同的运营活动，导致系统测试、回归测试任务繁重，耗时长。


技术实现要素：

5.鉴于以上内容，有必要提出一种基于大数据的数据核对方法、装置、电子设备及存储介质，以解决如何提高业务测试的效率这一技术问题。
6.本技术实施例提供一种基于大数据的数据核对方法包括：
7.获取待测试产品以及所述待测试产品对应的业务需求；
8.判断所述业务需求是否符合验证规则，若不符合验证规则，输出提示信息；
9.若符合验证规则，基于所述业务需求构建所述待测试产品对应的测试场景；
10.配置所述测试场景的环境配置参数，并根据所述测试场景的环境参数建立所述测试场景的数据库和所述数据库对应的测试接口；
11.使用压力测试工具连接所述数据库，通过数据插入脚本往所述数据库内插入待测数据、计费规则以及预期计费数据；
12.依据所述计费规则计算所述待测数据以得到实际的计费数据；
13.判断所述实际的计费数据与所述预期的计费数据是否匹配，若匹配，则测试下一个测试场景，若不匹配，则显示匹配错误。
14.本技术通过提前构造测试场景，减少了系统测试和回归测试时间，并且通过压力测试工具和测试接口，能够实现自动核对计费结果，减少了人力投入。
15.在一些实施例中，所述获取待测试产品包括：
16.获取多种产品并将所述多种产品进行分类以得到多种同类型产品；
17.比较所述多种同类型产品，输出同类型产品中符合预期的产品作为待测试产品。
18.如此，通过对保险公司的同类型产品的对比测评，获得具有符合用户预期的待测试产品，提高数据核对方法的有效性。
19.在一些实施例中，所述判断所述业务需求是否符合验证规则包括：
20.创建验证规则库；
21.解析所述业务需求以获得所述业务需求中的关键词条；
22.匹配所述关键词条和所述验证规则库，若所述验证规则库中不包含所述关键词条，则所述业务需求不符合所述验证规则，若所述验证规则库包含所述关键词条，则所述业务需求符合所述验证规则。
23.如此，通过对业务需求进行验证，使得发布的业务需求清楚规范，基于清楚规范的业务需求，减少构造测试场景时候的来回反馈修改业务需求的概率，进而减少系统测试和回归测试时间。
24.在一些实施例中，基于所述业务需求构建所述待测试产品对应的测试场景包括：
25.获取所述待测试产品的各个属性项及每个所述属性项对应的属性内容；
26.确定各个所述属性项之间的关联关系；
27.依据所述关联关系、各个所述属性项及每个所述属性项对应的属性内容创建测试表格；
28.将各个属性项及每个属性项对应的属性内容导入至测试表格中，生成测试数据表；
29.依据所述测试数据表，配置每个所述属性项的属性值；
30.组合已配置属性值的各个属性项并生成所述待测试产品对应的测试场景。
31.如此，基于业务需求自动生成测试场景，提升了对产品测试的效率。
32.在一些实施例中，使用压力测试工具连接所述数据库，通过数据插入脚本往所述数据库内插入待测数据、计费规则以及预期计费数据包括：
33.调用压力测试工具获取数据配置文件，所述数据配置文件配置有所述待测数据；
34.依据所述压力测试工具根据所述数据配置文件生成包含有插入语句的数据插入脚本；
35.执行所述数据插入脚本，在所述待测数据属于常数型数据时，将所述插入语句指定的所述待测数据作为测试数据插入数据库。
36.如此，通过在压力测试工具的配置页面输入数据配置文件，便可快速地获取到数据配置文件中的待测数据。根据数据配置文件来生成包含有插入语句的数据插入脚本，通过运行该数据插入脚本，将数据配置文件中的待测数据作为测试数据插入数据库，由于待测数据已预先进行设置，因此可以快速获取到测试数据，有效地提高测试效率。而且，由于数据插入脚本是根据数据配置文件生成，即便系统升级改造或接口升级改造，均无需测试人员重新编写脚本，进一步提高了测试效率。
37.在一些实施例中，依据所述计费规则计算所述待测数据以得到实际的计费数据包括：
38.获取所述测试接口的访问信息与所述测试接口的协议类型对应的请求报文模板；
39.根据所述访问信息、所述请求报文模板生成所述测试接口的接口测试用例；
40.判断所述测试接口是否需要对所述数据库进行操作，若所述接口需要对数据库进行操作，确定所述数据库的数据库类型；
41.将所述数据库类型对应的数据库脚本添加到所述接口测试用例；
42.在所述接口测试用例中添加系统函数，所述系统函数基于所述计费规则与待测数
据进行计算，得到实际的计费数据。
43.如此，通过获取测试接口的访问信息与所述测试接口的协议类型对应的请求报文模板，根据所述访问信息、所述请求报文模板生成所述测试接口的接口测试用例。本实施例可快速生成测试接口的接口测试用例，并且支持不同的协议类型和不同的数据库类型，提高了系统的兼容性。
44.在一些实施例中，所述方法还包括获取预期计费数据，包括：
45.确定所述测试场景的包名和类名，其中，所述包名包括所述测试场景对应的所述预期计费数据的存储路径信息，所述类名包括所述测试场景对应的所述预期计费数据的文件名称；
46.针对所述测试场景，根据所述存储路径信息和所述文件名称，获取所述测试场景对应的所述预期计费数据。
47.如此，根据测试场景的包名和类名，自动获取测试场景对应的所述预期数据，不需要测试人员的参与，能有效减少测试人员的工作量，提高测试效率。
48.本技术实施例还提供一种基于大数据的数据核对装置，包括：
49.获取单元，用于获取待测试产品以及所述待测试产品对应的业务需求；
50.判断单元，用于判断所述业务需求是否符合验证规则，若不符合验证规则，输出提示信息，若符合验证规则，基于所述业务需求构建所述待测试产品对应的测试场景；
51.配置单元，用于配置所述测试场景的环境参数，并根据所述测试场景的环境参数建立所述测试场景的数据库和所述数据库对应的测试接口；
52.导入单元，用于使用压力测试工具连接所述数据库，通过数据插入脚本往所述数据库内插入待测数据、计费规则以及预期计费数据；
53.计算单元，用于依据所述计费规则计算所述待测数据以得到实际的计费数据；
54.匹配单元，用于判断所述实际的计费数据与预期的计费数据是否匹配，若匹配，则测试下一个测试场景，若不匹配，则显示匹配错误。
55.上述基于大数据的数据核对装置通过提前构造测试场景，减少了系统测试和回归测试时间，并且通过压力测试工具和测试接口，能够实现自动核对计费结果，减少了人力投入。
56.本技术实施例还提供一种电子设备，包括：
57.存储器，存储有计算机可读指令；及
58.处理器，执行所述存储器中存储的计算机可读指令以实现上述的基于大数据的数据核对方法。
59.本技术实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机可读指令，所述计算机可读指令被处理器执行时实现上述的基于大数据的数据核对方法。
60.上述电子设备和计算机可读存储介质可通过提前构造测试场景，减少了系统测试和回归测试时间，通过压力测试工具和测试接口，实现自动核对计费结果，提高了作业效率。
附图说明
61.图1是本技术一实施例数据核对方法的流程示意图。
62.图2是本技术一实施例构建测试场景的方法的流程示意图。
63.图3是本技术一实施例的调用测试接口启动计费规则的方法的流程示意图。
64.图4是本技术一实施例数据核对装置的示意图
65.图5是本技术一实施例电子设备的示意图。
具体实施方式
66.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
67.本技术实施例提供的基于大数据的数据核对方法由电子设备执行，相应地，基于大数据的数据核对装置运行于电子设备中。本技术通过提前构造测试场景，减少了系统测试和回归测试时间，并且通过压力测试工具和测试接口，能够实现自动核对数据计费结果，减少了人力投入。
68.结合附图，以下将对本技术的一些实施例进行详细说明。
69.如图1所示，是本技术实施例一提供的基于大数据的数据核对方法的流程图，本方法可以应用于对保险产品、信贷产品等佣金计算，本实施例以保险产品为例，包括以下步骤，根据不同的需求，该流程图中的步骤可以改变，某些可以省略。
70.s1，获取待测试产品。
71.其中产品可以为保险产品，通过大数据技术接入保险公司的产品，将市场上同类型的保险产品进行集合分类。
72.将不同保险公司的同类型产品进行比较，将大量的同质化产品基于所属险种的特点从不同的维度进行对比测评。
73.通过大数据计算、智能分析，基于险种特点“解剖”所测评产品，将同类型产品的共有特点、独特属性等进行解读，输出同类保险产品中最优的保险产品作为待测试产品。所述待测试产品包括各种保险产品，比如家化产品，消金产品等。
74.在一个可选的实施方式中，所述获取待测试产品包括：
75.获取多种产品并将所述多种产品进行分类以得到多种同类型产品；
76.比较所述多种同类型产品，输出同类型产品中符合预期的产品作为待测试产品。其中，符合预期的产品是指同类保险产品中最优的保险产品。
77.基于大数据技术将保险公司的保险产品进行深挖掘聚合在一起，通过对保险公司的同类型产品对比测评，帮助用户更好地从大量同质化的产品中选择满足其需求的高性价比产品进行测试。
78.用户可以选择需要测评的险种如重疾险、多次赔付重疾险、寿险、养老险等。选择险种后，根据所选择的险种所特有的属性，将数据库中各保险公司所对应险种中具备相同产品属性的产品归类，比如选择的险种是寿险，基于寿险所特有的大类属性将数据库中各保险公司具有寿险大类属性的险种先归类为寿险，再根据寿险的保障期限是定期还是终
身，进一步细分为定期寿险和终身寿险。用户可以将不同保险公司的众多同类型的产品进行比较测评，所选择的保险公司及产品的数量更多、选择面更广。
79.每一险种产品所具有的属性通过保险公司数据、险种和产品数据、产品属性数据建立测评系统的数据系统，使用户在测评时，可以轻松接触到更多的保险公司及产品和服务，通过比较测评找到更适合推广的产品。比如某一重疾险产品的属性，包括重疾的保障范围、重疾病种种类、保障额度、保障期限、赔付条件、赔付次数、轻症病种种类、保障额度、赔付次数、赔付额度以及身故、全残等。
80.测评的分析方式和测评维度从保险行业的专业角度和消费者的需求两条主线结合进行分析。从专业角度将产品属性进行详细“解剖”，比如从保险附加条款、保障病种合理性等维度进行测评，并结合消费者希望能买到满足其需求的质优价廉的好产品的心理诉求，从保障需求、保费比较等维度进行测评。从而挑选出性价比高、更适合消费者需求，更利于销售人员推广的保险产品。
81.s2，获取待测试产品对应的业务需求。
82.所述待测试产品的业务需求包括“家化产品的佣金按照基础比例计算”或者“家化产品的佣金按照特殊比例计算”或者“消金产品的佣金按照首贷的数额进行计算”等。
83.当需要对待测试产品进行测试时，发送测试请求，其中，测试请求包含待测试产品对应的业务需求文档，接收到测试请求时，获取业务需求文档，并读取业务需求文档中包含的业务需求。
84.本技术实施例通过自动读取业务需求文档中包含的业务需求，减少了人工投入，提升了测试效率。
85.s3，判断业务需求是否符合验证规则。
86.若不符合验证规则，输出提示信息，返回执行步骤s2，若符合验证规则，执行步骤s4。
87.在一个可选的实施例中，判断业务需求是否符合验证规则，若不符合验证规则，输出提示信息，若符合验证规则，基于业务需求构建待测试产品对应的测试场景包括以下子步骤：
88.s301(图未示)，创建预设验证规则库，在预设验证规则库中设置验证规则。
89.例如，验证规则可以为：
90.1、业务需求信息中不包含*、￥等特殊字符。
91.2、业务需求信息中必须包含时间信息等等。
92.s302(图未示)，将业务需求与预设验证规则库中的验证规则进行匹配，判断业务需求是否符合验证规则；若不符合验证规则，输出提示信息，若符合验证规则，基于业务需求构建待测试产品对应的测试场景。
93.判断业务需求与验证规则匹配，包括以下内容，
94.解析业务需求获得业务需求中的关键词条。
95.验证规则库包含有常用的词条，获取到关键词条之后，查询验证规则库，在验证规则库中不包含关键词条时，输出提示信息，返回执行步骤s2，重新获取业务需求。
96.本技术通过对业务需求进行验证，使得发布的业务需求清楚规范，基于清楚规范的业务需求，减少构造测试场景时的来回反馈修改业务需求的概率，进而减少系统测试和
回归测试时间。
97.在一个可选的实施例中，还可以通过提示信息提示业务人员更新验证规则库。
98.比如：业务需求为家化产品的佣金按照基础比例计算，解析业务需求的关键词条为：家化产品、佣金、基础比例。查询验证规则库，佣金未在验证规则库中存在，则提示：请更新验证规则库；或者，确定业务需求输入错误，提示输入新的业务需求。
99.通过对业务需求进行验证，使得发布的业务信息清楚规范，减少了产品测试过程中沟通时间和沟通成本。
100.s4，基于业务需求构建待测试产品对应的测试场景。
101.如图2所示，步骤s4包括以下子步骤：
102.s401，获取业务需求中包含的待测试产品的各个属性项及每个属性项对应的属性内容。
103.本实施例中，业务需求中包含描述待测试产品的多个属性项和每个属性项对应的属性内容，当从业务需求中获取待测试产品的各个属性项时，同时获取每个属性项对应的属性内容。
104.例如，属性项可以包括被保人年龄、被投关系、被保人社保、被保人性别、险种等。属性内容可以为各个属性项中包含的具体内容，例如当属性项为被保人年龄时，属性内容可以包含被保人的年龄段，例如可以为0～9岁，11～12岁等年龄区间。例如当属性项为被投关系时，其属性内容可以是：父母、本人、子女和配偶等。
105.s402，确定各个属性项之间的关联关系。
106.本实施例中，各个属性项之间存在关联关系，为了分析各个属性项，需要确定各个属性项之间的关联关系，例如，属性项被投人保险和属性项险种存在关联关系。
107.s403，依据关联关系、各个属性项及每个属性项对应的属性内容创建测试表格。
108.s404，将各个属性项及每个属性项对应的属性内容导入至测试表格中，生成测试数据表。
109.s405，在测试数据表中，选取待测试保险产品的多个属性项，为每个属性项配置属性值；将已配置属性值的各个属性项进行组合，生成待测试产品对应的测试场景。
110.s5，配置测试场景的环境配置参数，并根据测试场景的环境参数建立测试场景的数据库和数据库对应的测试接口。
111.环境参数可以包括文件配置参数、注册表配置参数。
112.在一个可选的实施例中，配置测试场景的环境参数，并根据测试场景的环境参数建立测试场景的数据库包括以下子步骤：
113.s501(图未示)，解析业务需求，获得业务需求中的所述关键词条，关键词条包括产品信息和产品功能信息。
114.s502(图未示)，判断关键词条对应的环境配置参数的类型，如果环境配置参数包括文件配置参数，则根据文件配置参数创建对应的文件；如果环境配置参数包括注册表配置参数，则根据注册表配置参数调用操作系统提供的应用程序编程接口创建对应的注册表。
115.s503(图未示)，根据环境配置参数建立测试场景的数据库。
116.在实际应用中，不同的业务需求所需的环境配置参数会存在区别，为此，在本技术
实施例中可以预先为不同的业务需求配置好对应的环境配置参数，并根据业务需求中的关键词条信息从而确定出对应的环境配置参数，根据环境配置参数建立测试场景的数据库，提高了本技术实施例中所提供的方案的通用性。
117.比如，业务需求的表现形式为xml文件，xml(extensible markup language，可扩展标记语言)是一种用于标记文件使其具有结构性的标记语言，xml文件通过xml语言携带环境配置数据，环境配置数据包括多种不同的测试场景数据库对应的环境配置参数，并通过一定的结构和标签来区分各个不同的测试场景数据库与匹配的环境配置参数在xml文件的位置。由于xml的标签没有被预定义，可根据业务需要自行定义标签，使得xml文件的生成更灵活方便。测试时，只需要解析xml文件，查找与测试场景配置信息匹配的环境配置参数来建立对应的测试场景数据库。解析xml文件时，只需要在xml文件中查找关键词条所在位置，就可获取对应的环境配置参数。
118.s6，使用压力测试工具连接数据库，通过数据插入脚本往数据库内插入待测数据、计费规则以及预期计费数据。
119.在一个可选的实施例中，使用压力测试工具连接数据库，通过数据插入脚本往数据库内插入待测数据、计费规则以及预期计费数据包括以下子步骤：
120.s601(图未示)，调用压力测试工具获取数据配置文件，数据配置文件配置有待测数据。
121.s602(图未示)，通过压力测试工具根据数据配置文件生成包含有插入语句的数据插入脚本。
122.s603(图未示)，执行数据插入脚本，在待测数据属于常数型数据时，将插入语句指定的待测数据作为测试数据插入数据库。
123.比如，通过压力测试工具根据数据配置文件生成包含有sql插入语句的数据插入脚本。
124.运行数据插入脚本中各sql插入语句，当待测数据属于常数型数据时，将sql插入语句指定的待测数据作为测试数据插入数据库。
125.通过在压力测试工具的配置页面输入数据配置文件，便可快速地获取到数据配置文件中的待测数据。根据数据配置文件来生成包含有插入语句的数据插入脚本，通过运行该数据插入脚本，将数据配置文件中的待测数据作为测试数据插入数据库，由于待测数据已预先进行设置，因此可以快速获取到测试数据，有效地提高测试效率。而且，由于数据插入脚本是根据数据配置文件生成，即便系统升级改造或接口升级改造，均无需测试人员重新编写脚本，提高了测试效率。
126.s7，通过调用测试接口启动计费规则，对待测数据计算，得到实际的计费数据。
127.在一个可选的实施例中，如图3所示，通过调用测试接口启动计费规则，对待测数据计算，得到实际的计费数据包括以下子步骤：
128.s701，获取测试接口的访问信息与测试接口的协议类型对应的请求报文模板。
129.s702，根据访问信息、请求报文模板生成测试接口的接口测试用例。
130.s703，判断测试接口是否需要对数据库进行操作，若测试接口需要对数据库进行操作，确定数据库的数据库类型。
131.s704，将数据库类型对应的数据库脚本添加到接口测试用例。
132.s705，在接口测试用例中添加系统函数，系统函数基于计费规则与待测数据进行计算，得到实际的计费数据。
133.本实施例通过获取测试接口的访问信息与测试接口的协议类型对应的请求报文模板；根据访问信息、请求报文模板生成测试接口的接口测试用例；判断测试接口是否需要对数据库进行操作，若测试接口需要对数据库进行操作，确定数据库的数据库类型；将数据库类型对应的数据库脚本添加到接口测试用例，本实施例可快速生成测试接口的接口测试用例，并且支持不同的协议类型和不同的数据库类型。
134.在一些实施例中，获取预期计费数据包括：
135.确定测试场景的包名和类名，其中，包名包括测试场景对应的预期计费数据的存储路径信息，类名包括测试场景对应的预期计费数据的文件名称；
136.针对测试场景，根据存储路径信息和文件名称，获取测试场景对应的预期计费数据。
137.s8，判断实际的计费数据与预期的计费数据是否匹配，若匹配，执行步骤s9，若不匹配，执行步骤s10。
138.s9，对下一个测试场景进行测试。
139.s10，显示匹配错误,结束执行。
140.在一个可选的实施例中，判断实际的计费数据与预期的计费数据是否匹配，若匹配，则对下一个测试场景进行测试，若不匹配，显示匹配错误包括：
141.在接口测试用例中添加断言信息，断言信息用于判断实际的计费数据与预期的计费数据是否匹配，若匹配，则对下一个测试场景进行测试，若不匹配，显示匹配错误。
142.测试场景是与业务需求匹配的，不同的保险产品对应不同的测试场景，比如家化产品的测试场景，消金产品的测试场景，经营贷/消费贷的测试场景等。
143.在本实施例中，压力测试工具为jmeter，在jmeter是基于java的压力测试工具，用于对软件做压力测试，压力测试工具jmeter的返回消息前增加bean shell函数，bean shell是嵌入式java源代码解释器，能够动态地执行标准java语法；在beanshell函数中通过prev获取返回消息，返回消息是一串符合规定格式的字符串，通过vars获取用户定义的变量，vars是操作jmeter变量，提供读取/写入访问变量的方法，prev是获取采样的结果；在beanshell函数中导入外部断言，传入接口断言需要的业务场景，输入字段列表、接口的返回消息，得到断言框架的判断结果。
144.上述基于大数据的数据核对方法通过提前构造测试场景，减少系统测试和回归测试时间，通过压力测试工具和测试接口，实现自动核对计费结果，提高了作业效率。
145.本技术实施例还提供一种基于大数据的数据核对装置10，包括获取单元101、判断单元102、配置单元103、导入单元104、计算单元105及匹配单元106。
146.获取单元101，用于获取待测试产品以及待测试产品对应的业务需求。
147.其中产品可以为保险产品，获取单元101通过大数据技术接入保险公司的产品，将市场上同类型的保险产品进行集合分类。
148.获取单元101将不同保险公司的同类型产品进行比较，将大量的同质化产品基于所属险种的特点从不同的维度进行全方位地对比测评。
149.获取单元101通过大数据计算、智能分析，基于险种特点全方位地“解剖”所测评产
品，将同类型产品的共有特点、独特属性等进行全方位解读，输出同类保险产品中最优的保险产品作为待测试产品。
150.业务需求包括“家化产品的佣金按照基础比例计算”或者“家化产品的佣金按照特殊比例计算”或者“消金产品的佣金按照首贷的数额进行计算”等。
151.获取单元101还用于后去待测试保险产品的测试请求，其中，测试请求包含待测试保险产品对应的业务需求文档，获取单元101接收到测试请求时，获取业务需求文档，并读取业务需求文档中包含的业务需求。
152.本技术实施例通过获取单元101自动读取业务需求文档中包含的业务需求，减少了人工投入，提升了测试效率。
153.判断单元102，与获取单元101连接，用于判断业务需求是否符合验证规则，若不符合验证规则，输出提示信息，若符合验证规则，基于业务需求构建待测试产品对应的测试场景。
154.其中，判断单元102还用于创建预设验证规则库，在预设验证规则库中设置验证规则。
155.例如，验证规则可以为：
156.1、业务需求信息中不包含*、￥等特殊字符。
157.2、业务需求信息中必须包含时间信息等等。
158.判断单元102还用于将业务需求与预设验证规则库中的验证规则进行匹配，判断业务需求是否符合验证规则；若不符合验证规则，输出提示信息，若符合验证规则，基于业务需求构建待测试产品对应的测试场景。
159.判断单元102判断业务需求与验证规则匹配，包括以下内容，
160.判断单元102解析业务需求获得业务需求中的关键词条。
161.验证规则库包含有常用的词条，获取到关键词条之后，判断单元102查询验证规则库，在验证规则库中不包含关键词条时，判断单元102输出提示信息，返回执行步骤s2，重新获取业务需求。
162.本技术通过判断单元102，对业务需求进行验证，使得发布的业务需求清楚规范，基于清楚规范的业务需求，减少构造测试场景时候的来回反馈修改业务需求的概率，进而减少系统测试和回归测试时间。
163.在一个可选的实施例中，判断单元102还可以通过提示信息提示业务人员更新验证规则库。
164.比如：业务需求为家化产品的佣金按照基础比例计算，解析业务需求的关键词条为：家化产品、佣金、基础比例。判断单元102查询验证规则库，佣金未在验证规则库中存在，则提示：请更新验证规则库，或者，确定业务需求输入错误，提示输入新的业务需求。
165.通过判断单元102，对业务需求进行验证，使得发布的业务信息清楚规范，减少了产品测试过程中沟通时间和沟通成本。
166.配置单元103，与判断单元102连接，用于配置测试场景的环境参数，并根据测试场景的环境参数建立测试场景的数据库和数据库对应的测试接口。
167.环境参数可以包括文件配置参数、注册表配置参数。
168.在一个可选的实施例中，配置单元103配置测试场景的环境参数，并根据测试场景
的环境参数建立测试场景的数据库包括以下子步骤：
169.配置单元103解析业务需求，获得业务需求中的关键词条，关键词条包括产品信息和产品功能信息。
170.配置单元103判断关键词条对应的环境参数的类型，如果环境参数包括文件配置参数，则根据文件配置参数创建对应的文件；如果环境参数包括注册表配置参数，则根据注册表配置参数调用操作系统提供的应用程序编程接口创建对应的注册表。
171.配置单元103根据环境参数建立测试场景的数据库。
172.比如，业务需求的表现形式为xml文件，xml(extensible markup language，可扩展标记语言)是一种用于标记文件使其具有结构性的标记语言，xml文件通过xml语言携带环境配置数据，环境配置数据包括多种不同的测试场景数据库对应的环境配置参数，并通过一定的结构和标签来区分各个不同的测试场景数据库与匹配的环境配置参数在xml文件的位置。由于xml的标签没有被预定义，可根据业务需要自行定义标签，使得xml文件的生成更灵活方便。测试时，只需要解析xml文件，查找与测试场景配置信息匹配的环境配置参数来建立对应的测试场景数据库。解析xml文件时，只需要在xml文件中查找关键词条所在位置，就可获取对应的环境配置参数。
173.在实际应用中，不同的业务需求所需的环境配置参数会存在区别，为此，在本技术实施例中可以预先为不同的业务需求配置好对应的环境配置参数，并根据业务需求中的关键字信息从而确定出对应的环境配置参数，根据环境配置参数建立测试场景的数据库，提高了本技术实施例中所提供的方案的通用性。
174.导入单元104，与配置单元103连接，用于使用压力测试工具连接数据库，通过数据插入脚本往数据库内插入待测数据、计费规则以及预期计费数据。
175.在一个可选的实施例中，导入单元104使用压力测试工具连接数据库，通过数据插入脚本往数据库内插入待测数据、计费规则以及预期计费数据包括以下子步骤：
176.导入单元104调用压力测试工具获取数据配置文件，数据配置文件配置有待测数据。
177.导入单元104通过压力测试工具根据数据配置文件生成包含有插入语句的数据插入脚本。
178.导入单元104执行数据插入脚本，在待测数据属于常数型数据时，将插入语句指定的待测数据作为测试数据插入数据库。
179.比如，通过压力测试工具根据数据配置文件生成包含有sql插入语句的数据插入脚本。
180.运行数据插入脚本中各sql插入语句，当待测数据属于常数型数据时，将sql插入语句指定的待测数据作为测试数据插入数据库。
181.通过在压力测试工具的配置页面输入数据配置文件，便可快速地获取到数据配置文件中的待测数据。根据数据配置文件来生成包含有插入语句的数据插入脚本，通过运行该数据插入脚本，将数据配置文件中的待测数据作为测试数据插入数据库，由于待测数据已预先进行设置，因此可以快速获取到测试数据，有效地提高测试效率。而且，由于数据插入脚本是根据数据配置文件生成，即便系统升级改造或接口升级改造，均无需测试人员重新编写脚本，提高了测试效率。
182.计算单元105，与导入单元104连接，用于依据计费规则计算待测数据以得到实际的计费数据。
183.其中，计算单元105通过调用测试接口启动计费规则，对待测数据计算，得到实际的计费数据包括以下子步骤：
184.计算单元105获取测试接口的访问信息与测试接口的协议类型对应的请求报文模板。
185.计算单元105根据访问信息、请求报文模板生成测试接口的接口测试用例。
186.计算单元105确定数据库的数据库类型。
187.计算单元105将数据库类型对应的数据库脚本添加到接口测试用例。
188.计算单元105在接口测试用例中添加系统函数，系统函数基于计费规则与待测数据进行计算，得到实际的计费数据。
189.本实施例通过获取测试接口的访问信息与测试接口的协议类型对应的请求报文模板；根据访问信息、请求报文模板生成测试接口的接口测试用例；判断测试接口是否需要对数据库进行操作，若测试接口需要对数据库进行操作，确定数据库的数据库类型；将数据库类型对应的数据库脚本添加到接口测试用例，本实施例可快速生成测试接口的接口测试用例，并且支持不同的协议类型和不同的数据库类型。
190.匹配单元106，与计算单元105连接，用于判断实际的计费数据与预期的计费数据是否匹配，若匹配，则测试下一个测试场景，若不匹配，则显示匹配错误。
191.实施例三
192.本技术实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机可读指令，计算机可读指令被处理器执行时实现上述的基于大数据的数据核对方法实施例中的步骤，例如图1至图3中所示的步骤。
193.实施例四
194.参阅图5所示，为本技术实施例四提供一种电子设备的结构示意图。在本技术较佳实施例中，所述电子设备20包括但不限于存储器201和处理器202，以及存储在存储器201中并可在处理器202上允许的计算机可读指令，例如基于大数据的数据核对程序。
195.本领域技术人员可以理解，所述示意图仅仅是电子设备20的示例，并不构成对电子设备1的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述电子设备20还可以包括输入输出设备、网络接入设备、总线等。
196.处理器202可以是中央处理单元(central processing unit，cpu)，还可以包括其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者处理器也可以是任何常规的处理器等。处理器202是电子设备20的控制中心和运算核心，利用各种接口和线路连接整个电子设备20的各个部分，及执行电子设备20的操作系统以及安装的各类应用程序、程序代码等。
197.示例性的，所述计算机可读指令可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器201中，并由所述处理器202执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段，该计算机
可读指令段用于描述所述计算机可读指令在所述电子设备20中的执行过程。例如，所述计算机可读指令可以被分割成获取单元101、判断单元102、配置单元103、导入单元104、计算单元105及匹配单元106。
198.存储器201可用于存储计算机程序和/或模块/单元，处理器202通过运行或执行存储在存储器201内的计算机程序和/或模块/单元，以及调用存储在存储器201内的数据，实现电子设备20的各种功能。存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(smart media card,smc)，安全数字(secure digital,sd)卡，闪存卡(flash card)、至少一个磁盘存储器件、闪存器件、或其他存储器件。
199.所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实现所述实施例方法中的全部或部分流程，也可以通过计算机可读指令相关的硬件来完成，所述的计算机可读指令可存储于一计算机可读存储介质中，所述计算机可读指令在被处理器执行时，可实现所述各个方法实施例的步骤。
200.此处描述的计算机可读指令可以从计算机可读存储介质下载到相应的计算处理设备，或者通过网络(例如，互联网，局域网，广域网和网络)下载到外部计算机或外部存储设备或无线网络。该网络可以包括铜传输电缆、光传输纤维、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器，每个计算处理设备中的网络适配器卡或网络接口从网络接收计算机可读指令，并转发该计算机可读指令以存储在各个计算处理设备内的计算机可读存储介质中。
201.用于执行本技术的操作的计算机可读指令可以是汇编程序指令，指令集架构(isa)指令，机器指令，机器相关指令，微码，固件指令，状态设置数据，集成电路的配置数据，或以一种或多种编程语言(包括面向对象的编程语言，例如smalltalk，c 等)和过程编程语言(例如“c”编程语言或类似编程)的任意组合编写的源代码或目标代码语言。计算机可读指令可以完全在用户计算机上，作为独立软件包执行；可以部分在用户计算机上并且部分在远程计算机上或完全在远程计算机或服务器上执行。在后一种情况下，远程计算机可以通过任何类型的网络(包括局域网(lan)或广域网(wan))连接到用户计算机，或者可以与外部计算机建立连接(用于例如，通过使用internet服务提供商的internet)。在一些实施例中，包括例如可编程逻辑电路，现场可编程门阵列(fpga)或可编程逻辑阵列(pla)的电子电路可以通过利用计算机可读指令的状态信息来个性化计算机可读指令。
202.附图中的流程图和框图示出了根据本技术的各种实施例的装置，方法和计算机程序产品的可能实现的体系结构，功能和操作。就这一点而言，流程图或框图中的每个方框可以代表指令的模块，片段或部分，其包括用于实现指定的逻辑功能的一个或多个可执行指令。在一些替代实施方式中，方框中指出的功能可以不按图中指出的顺序发生。例如，取决于所涉及的功能，实际上可以基本上同时执行连续示出的两个框，或者有时可以以相反的顺序执行这些框。还应注意，框图和/或流程图的每个方框以及框图和/或流程图的方框的组合可以由执行指定功能或动作或基于特定目的的基于硬件的专用系统来实现。
203.已经出于说明的目的给出了本技术的各种实施例的描述，但并不意图是穷举的或将本技术限制为所公开的形式。在不脱离本技术的范围和精神的情况下，许多修改和变化
对于本领域普通技术人员将是显而易见的。选择和描述实施例是为了最好地解释本技术的原理和实际应用，并使本领域的其他普通技术人员能够理解本技术的各种实施例，这些实施例具有各种适合于预期的特定用途的修改。