CN110489325A

CN110489325A - 车险数据测试方法、装置、测试平台及车险测试系统

Info

Publication number: CN110489325A
Application number: CN201910616468.6A
Authority: CN
Inventors: 吴宏平; 贺勇军
Original assignee: Weimin Insurance Agency Co Ltd
Current assignee: Weimin Insurance Agency Co Ltd
Priority date: 2019-07-09
Filing date: 2019-07-09
Publication date: 2019-11-22

Abstract

本发明涉及互联网技术领域，公开一种车险数据测试方法、装置、测试平台及车险测试系统。方法包括：获取业务测试指令，从预设测试用例库遍历出业务测试指令指向的目标测试用例，各个测试用例共用相同的测试字段，接收在目标测试用例下的测试字段输入的车险用例数据，并将目标测试用例与车险用例数据组装成访问请求，向服务器发送访问请求，以使服务器根据访问请求返回用例执行结果，呈现用例执行结果。由于各个测试用例共用相同的测试字段，测试人员只需在测试用例的关键字段输入对应的车险用例数据，无需针对每类车险业务人工输入待测的测试字段及其测试数据，因此，此类作法的测试效率高，满足车险业务种类繁多的需求，并能够全流程测试。

Description

车险数据测试方法、装置、测试平台及车险测试系统

技术领域

本发明涉及互联网技术领域，尤其涉及一种车险数据测试方法、装置、测试平台及车险测试系统。

背景技术

随着互联网技术的发展，保险行业的发展速度越来越快，其中，车险作为保险行业的一个分支，其发展速度受到关注。

一般的，保险公司需要互联网车险平台为其提供软件技术支持，以扩展车险业务，因此，为了保证保险公司与车险平台之间业务的顺畅，在投放市场前，车险平台需要与保险公司作业务测试。

测试时，传统保险公司目前主要是通过相关接口请求测试工具进行联调测试，例如，采用诸如postman或jmeter的测试工具进行联调测试，此类测试工具功能比较开放，主要面向技术人员，测试所需的协议参数全部依赖用户输入，响应结果也依赖人工分析判断。由于车险业务种类比较繁多，测试时，测试人员需要针对不同的车险输入测试字段，导致测试效率比较低。

发明内容

本发明实施例的一个目的旨在提供一种车险数据测试方法、装置、测试平台及车险测试系统，其能够提高测试效率。

在第一方面，本发明实施例提供一种车险数据测试方法，应用于测试平台，所述方法包括：

获取业务测试指令；

从预设测试用例库遍历出所述业务测试指令指向的目标测试用例，其中，所述预设测试用例库包括多个测试用例，各个所述测试用例共用相同的测试字段；

接收在所述目标测试用例下的测试字段输入的车险用例数据，并将所述目标测试用例与所述车险用例数据组装成访问请求；

向服务器发送所述访问请求，以使所述服务器根据所述访问请求返回用例执行结果；

呈现所述用例执行结果。

在第二方面，本发明实施例提供一种车险数据测试装置，应用于测试平台，所述装置包括：

测试项目管理器，用于获取业务测试指令，从预设测试用例库遍历出所述业务测试指令指向的目标测试用例，其中，所述预设测试用例库包括多个测试用例，各个所述测试用例共用相同的测试字段；

测试执行引擎，用于接收在所述目标测试用例下的测试字段输入的车险用例数据，并将所述目标测试用例与所述车险用例数据组装成访问请求，向服务器发送所述访问请求，以使所述服务器根据所述访问请求返回用例执行结果，呈现所述用例执行结果。

在一些实施例中，所述装置还包括：

用例构建模块，用于构建测试用例；

用例组合模块，用于组合各个所述测试用例，以构成预设测试用例库。

在一些实施例中，所述用例构建模块包括：

用例新增单元，用于获取用例新增指令；

页面呈现单元，用于根据所述用例新增指令，呈现用例新增页面，所述用例新增页面包括用例名称框及用例描述框；

数据接收单元，用于接收在所述用例名称框输入的用例名称，以及在所述用例描述框输入的用例描述内容；

用例构建单元，用于根据所述用例名称及所述用例描述内容，构建测试用例。

在一些实施例中，所述装置还包括：

模板模块，用于获取在数据校验模板输入的车险基础数据；

校验启动模块，用于启动所述数据校验模板校验所述车险基础数据，若校验成功，向所述服务器发送所述数据校验模板；若校验失败，生成第一提示信息，根据所述第一提示信息获取重新输入的车险基础数据，并重复执行启动所述数据校验模板校验重新输入的车险基础数据。

在一些实施例中，所述校验启动模块具体用于：将所述数据校验模板组装成校验请求，选择测试接口，通过所述测试接口向所述服务器发送所述校验请求，以使所述服务器根据所述校验请求返回数据校验结果。

在一些实施例中，所述校验启动模块还具体用于：获取接口调用请求，所述接口调用请求封装有接口调用字段，选择与所述接口调用字段对应的接口作为测试接口。

在一些实施例中，所述测试接口包括报价接口、投保接口和/或出单接口。

在一些实施例中，所述数据校验结果包括校验成功结果与校验失败结果，所述装置还包括：

端对端测试模块，用于当所述数据校验结果为校验成功结果时，通过小程序进行端对端测试；

第一信息提示模块，用于当所述数据校验结果为校验失败结果时，生成所述第一提示信息。

在一些实施例中，所述数据校验模板包括Excel模板。

在一些实施例中，所述目标测试用例的数量为多个。

在一些实施例中，所述业务测试指令对应的业务类型为至少两种。

在一些实施例中，所述测试项目管理器还具体用于：解析所述业务测试指令，得到业务标识，所述业务标识用于标识车险业务类型，每项所述车险业务类型均对应一个或多个测试用例；从预设测试用例库遍历出与所述业务标识对应的测试用例作为目标测试用例。

在一些实施例中，所述用例数据输入在预设数据模板中，所述测试执行引擎具体用于：启动所述预设数据模板校验所述车险用例数据，若校验成功，得到在所述目标测试用例下的测试字段输入的车险用例数据；若校验失败，生成第二提示信息，根据所述第二提示信息获取重新输入的车险用例数据，并重复执行启动所述预设数据模板校验所述车险用例数据。

在一些实施例中，所述装置还包括：

测试进度跟踪模块，用于生成全部目标测试用例共用的任务编号，获取在所述任务编号下全部目标测试用例的用例执行结果，根据所述全部目标测试用例的用例执行结果，生成测试图表。

在第三方面，本发明实施例提供一种测试平台，包括：

至少一个处理器；和

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的车险数据测试方法。

在第四方面，本发明实施例提供一种非易失性计算机可读存储介质，所述非易失性计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使测试平台执行上述的车险数据测试方法。

在第五方面，本发明实施例提供一种车险测试系统，包括：

上述的测试平台；和

服务器，所述服务器与所述测试平台通讯连接。

在本发明各个实施例提供的车险数据测试方法中，首先，获取业务测试指令，从预设测试用例库遍历出业务测试指令指向的目标测试用例，其中，预设测试用例库包括多个测试用例，各个测试用例共用相同的测试字段；其次，接收在目标测试用例下的测试字段输入的车险用例数据，并将目标测试用例与车险用例数据组装成访问请求；再次，向服务器发送访问请求，以使服务器根据访问请求返回用例执行结果；最后，呈现用例执行结果。一方面，由于各个测试用例共用相同的测试字段，测试人员只需在测试用例的关键字段输入对应的车险用例数据，无需针对每类车险业务人工输入待测的测试字段及其测试数据，因此，此类作法的测试效率高，能够满足车险业务种类繁多的需求。另一方面，从整体角度看本方法，其能够全流程地完成测试，减少测试人员参与的时间，相对地缩短平台对接时间。再一方面，由于测试用例比较直观友好，测试人员容易操作测试用例以完成测试。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1a是本发明实施例提供的一种测试系统的结构示意图；

图1b是本发明另一实施例提供的一种测试系统的结构示意图；

图1c是本发明实施例提供的一种测试平台的软件架构示意图；

图1d是本发明实施例提供的一种测试平台的部署示意图；

图2a是本发明实施例提供的一种后台服务器的结构示意图；

图2b是本发明实施例提供的一种后台服务器的数据流转关系的示意图；

图2c是本发明实施例提供的一种执行引擎的结构示意图；

图2d是图2c中的执行引擎的执行过程的流程示意图；

图3a是本发明实施例提供的车险数据测试方法的一个可选的流程示意图；

图3b是本发明实施例提供的一种测试页面的示意图；

图3c是本发明实施例提供的一种车险用例数据的局部示意图；

图3d是图3c中车险用例数据的另一局部示意图；

图3e是本发明实施例提供的一种上传车险用例数据的示意图；

图3f是本发明实施例提供的呈现用例执行结果的示意图；

图3g是本发明另一实施例提供的车险数据测试方法的一个可选的流程示意图；

图3h是本发明实施例提供的测试图表的示意图；

图4a是本发明实施例提供的构建测试用例的流程示意图；

图4b是本发明实施例提供的一种用例新增页面的示意图；

图4c是本发明另一实施例提供的车险数据测试方法的一个可选的流程示意图；

图4d是本发明实施例提供的上传Excel模板的示意图；

图5是本发明实施例提供的一种用例数据执行结果的示意图；

图6a是本发明实施例提供的一种车险数据测试装置的示意图；

图6b是图6a中的用例构建模块的结构示意图；

图7是本发明实施例提供的一种测试平台的结构示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，如果不冲突，本发明实施例中的各个特征可以相互结合，均在本发明的保护范围之内。另外，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。再者，本发明所采用的“第一”、“第二”、“第三”等字样并不对数据和执行次序进行限定，仅是对功能和作用基本相同的相同项或相似项进行区分。

对本发明进行详细说明之前，对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。

1)车险：指根据法律规定实行的中国大陆地区市场销售的“机动车交通事故责任强制保险”和“机动车商业保险”两款保险产品。

2)测试平台：指为开展车险业务提供技术支撑的，可以同时为多家保险公司提供服务的软件系统，例如车险平台，保险代理车险平台。

3)险种：指车险种类，总的来说，车险可以分为交强险和商业车险，交强险是强制性车险，商业车险则可以根据自身需要选择购买。

4)保险公司：指依保险法和公司法设立的公司法人。保险公司收取保费，将保费所得资本投资于债券、股票、贷款等资产，运用这些资产所得收入支付保单所确定的保险赔偿。

5)业务类型：指保险公司为用户提供的服务类型，包括续保、脱保、转保。

请参阅图1a，图1a是本发明实施例提供的一种测试系统的结构示意图。如图1a所示，该测试系统100包括测试平台11及服务器12。

测试平台11与服务器12通信连接，以完成车险业务的测试，例如：测试平台11对接服务器12，测试平台11向服务器12发送访问请求，访问请求携带车险数据，服务器12处理车险数据，得到测试结果，并向测试平台11发送测试结果，其中，测试结果包括报价测试结果、投保测试结果及出单测试结果。

请参阅图1b，该测试平台11包括测试平台接口110，测试平台接口110包括多个接口，例如：报价接口、投保接口、出单接口等，相应的，服务器12包括服务器接口120，例如：报价接口、投保接口、出单接口，测试平台11调用测试平台接口，通过网关连接服务器12的服务器接口，从而实现测试平台与服务器之间的通信连接。

在一些实施例中，报价接口封装有车险报价控制逻辑，投保接口封装有车险投保控制逻辑，出单接口封装有车险出单控制逻辑，测试时，测试人员可在测试平台11调用对应的接口将访问请求发送至服务器12对应的接口。

在一些实施例中，测试平台11的数量可以为一个，亦可以为多个，测试平台可以采用计算机终端、服务器、移动终端等设备。

服务器12的数量为多个，多个服务器12可构成服务器集群，例如：该服务器集群包括：第一服务器、第二服务器，…，第N服务器，或者，该服务器集群可以是一个云计算服务中心，该云计算服务中心包括若干台服务器，服务器作为保险公司服务器，用于对接保险公司的业务人员或开发人员。

在一些实施例中，测试平台11可被预先配置有多层软件架构，例如，请参阅图1c，测试平台11的软件架构包括：业务层、测试层以及接口层，其中，业务层用于确定业务合作模式，测试层用于确认测试点，并生成相应的测试案例，接口层用于对接保险公司的服务器。具体的，以下对业务层、测试层以及接口层作进一步说明：

1、业务层说明

保险公司具体会要求那些业务合作模式，根据业务合作选择勾选相应的业务合作模式，业务场景主要依照保险公司是否为该保险公司上年业务或者是双方决议合作模式作为判断，双方合作模式包含有上线地区是否有监管要求或者特殊流程，从而决定整体系统支持程度。

其中，业务合作模式包括：

(1)业务类型：续/脱/转；

具体的，续/脱/转分别指的是续保、脱保以及转保，其中，续保指的是车险续保，脱保指的是车险脱保，转保指的是车险转保，放弃之前投保的保险公司，转入其他保险公司进行投保。

(2)是否实名、是否短信认证；

具体的，是否实名指的是车辆是否实名制，是否短信认证指的是是否需要对车主进行短信认证；

(3)是否有节假日翻倍；

具体的，是否有节假日翻倍，指的是机动车第三者责任保险附加法定节假日限额翻倍险，简称三者节假日翻倍险。

2、测试层说明：业务场景决定后，根据对应的业务层勾选，生成对应的“测试案例”，测试层主要针对互联网车险个性场景，决定需要确认的测试点，测试点包括：

(1)险种方案；

险种方案包括：最低保障方案、基本保障方案、经济保险方案以及最佳保障方案，最低保险方案指的是险种组合第三者责任险，其保障范围只对第三者的损失负赔偿责任；基本保障方案指的是险种组合车辆损失险+第三者责任险，其保障范围只投保基本险，不含任何附加险；经济保险方案指的是险种组合车辆损失险+第三者责任险+不计免赔特约险+全车盗抢险；最佳保障方案指的是全险，包括交强险+第三者险+车损险+不计免赔。

(2)补录车牌；

补录车牌指的是对车牌号码进行补录。

(3)去年数据；

去年数据指的是去年车辆的保险情况。

(4)续保车牌报价；

续保车牌报价指的是对需要续保的车牌进行报价。

(5)三者不一致；

三者不一致指的是第三者责任险与之前的不一致，需要更换第三者责任险的情况。

3、接口层说明；

用于与保险公司、外部第三方对接实际车险主流程提供相应的调用接口，接口层包括：报价接口、短信验证接口、投保接口、实名认证接口、投保状态接口、出单接口等。

在一些实施例中，如前，测试平台可由多台电子设备搭建而成，请参阅图1d，该测试平台11包括负载均衡服务器111(load-balancing server)、前端服务器112、后台服务器113以及后台数据库114，其中，负载均衡服务器11连接前端服务器12，前端服务器12连接后台服务器13，后台服务器13连接后台数据库14。

负载均衡服务器111是本测试平台的域名服务器，通过域名解析各类用户请求，一般的，用户请求首先到达负载均衡服务器，然后由此服务器根据各个实际处理服务器状态将请求具体分配到某个实际处理服务器中，对外公开的域名与IP地址均为负载均衡服务器。负载均衡控制与管理软件安装在该负载均衡服务器上，负载均衡服务器一般只做负载均衡任务分配，但不是实际对网络请求进行处理的服务器。

前端服务器112用于放置网站文件，通过前端界面供用户进行浏览。在一些实施例中，前端服务器包括但不限于：Apache服务器、IIS服务器(Internet InformationServer)、Nginx服务器等，其中，Nginx作为一个小巧且高效的HTTP服务器，也可以做一个高效的负载均衡反向代理，通过Nginx服务器接受用户的请求并分发到多个进程，从而极大提高应用的并发能力。

后台服务器113用于对后台应用进行部署，后台服务器113通过后台数据库进行数据存储，在本发明实施例中，后台服务器为Tomcat服务器。

后台数据库114包括Oracle数据库、SQL数据库、MySQL数据库中的至少一个或多个，优选地，本发明实施例中的后台数据库为MySQL数据库。

在一些实施例中，后台服务器113可被预先配置各类用于测试的模块，例如，请参阅图2a，后台服务器113包括：测试用例管理模块1131、测试项目管理模块1132、执行引擎1133以及项目报告模块1134，其中，测试用例管理模块1131连接测试项目管理模块1132，测试项目管理模块1132连接执行引擎1133，执行引擎1133连接项目报告模块1134。

测试用例管理模块1131用于指定资源类型(http/grpc)，访问地址，授权方式，授权参数，输入，输出，并通过javascript脚本断言输出是否符合预期，生成测试用例，并根据测试用例，生成测试任务，将测试任务发送到测试项目管理模块。

测试项目管理模块1132用于将测试任务抽象为项目，并关联项目需要测试的测试案例，其中，测试项目管理模块还用于设置项目成员，设置项目通用参数。

执行引擎1133用于测试案例的执行，并断言输入输出是否满足预期，同时存储测试结果，并将测试结果发送到项目报告模块。

项目报告模块1134用于生成项目的执行进度，并对该项目进行耗时统计。

请参阅图2b，图2b是本发明实施例提供的一种后台服务器的数据流转关系的示意图。如图2b所示，该后台服务器的数据流转关系为：

测试用例管理模块1131指定资源类型、授权参数以及并通过javascript脚本断言输出是否符合预期，生成测试用例，并根据测试用例，生成测试任务，将测试任务发送到测试项目管理模块。

测试项目管理模块1132接收所述测试用例管理模块发送的测试任务，所述测试任务包括多个测试用例，所述测试项目管理模块将测试任务抽象为项目，并关联项目需要测试的测试案例，其中，所述测试项目管理模块还用于设置项目成员，设置项目通用参数，并将相应的数据发送到执行引擎。

执行引擎1133接收所述测试项目管理模块发送的数据，对单用例进行测试执行，对组合用例进行测试执行，并断言输入输出是否满足预期，生成测试结果并存储测试结果，以及，将所述测试结果发送到所述项目报告模块。

项目报告模块1134接收所述执行引擎发送的测试结果，并根据所述测试结果，记录案例执行结果、耗时、测试报告以及项目维度记录。

请参阅图2c，执行引擎1133包括：数据读取模块21、逻辑处理模块22以及执行实现模块23。

数据读取模块21包括：数据读取接口以及测试案例数据读取单元、测试资源数据读取单元以及测试项目参数读取单元，其中，所述数据处理接口连接测试案例数据读取单元、测试资源数据读取单元以及测试项目参数读取单元。

数据读取接口用于负责数据读取，其中，所述测试案例数据读取单元用于负责测试案例数据读取，所述测试资源数据读取单元用于负责测试资源数据读取，所述测试项目参数读取单元用于负责测试项目参数的读取。

逻辑处理模块22包括：逻辑处理接口以及报文加密解密单元、授权和签名单元以及脚本执行单元，所述逻辑处理接口连接报文加密解密单元、授权和签名单元以及脚本执行单元。

逻辑处理接口用于执行前后的逻辑处理，其中，所述报文加密解密单元用于负责执行前后报文的加密解密，所述授权和签名单元用于负责授权和签名，所述脚本执行单元用于负责脚本执行，对输入和输出进行再次加工，在本发明实施例中，所述脚本为Javascript脚本。

执行实现模块23包括：执行实现接口以及案例执行单元、资源执行单元以及协议执行单元，所述执行实现接口连接所述案例执行单元、资源执行单元以及协议执行单元。

执行实现接口用于执行的实现，其中，所述案例执行单元用于负责执行案例，所述资源执行单元用于负责执行资源，所述协议执行单元用于负责协议执行，在本发明实施例中，所述协议为超文本传输协议(HyperText Transfer Protocol，HTTP)，简称HTTP协议。

请参阅图2d，图2d是图2c中的执行引擎的执行过程的流程示意图；其中，执行引擎作为核心部件，同时满足多种类型的测试案例和多种类型的API协议的执行。如图2d所示，该执行引擎的执行过程，包括：

步骤S201：输入参数；

具体的，输入测试参数。

步骤S202：初始化工作；

具体的，所述初始化工作包括：测试案例信息读取、上下文创建、请求参数的读取；获取已经注册的适配当前协议类型的数据读取接口executor，即上述的数据读取接口。

步骤S203：准备工作；

具体的，执行前的准备工作，包括协议必须信息的填充、业务参数拼装、用户输入数据的拼装、签名、报文加解密。

步骤S204：执行请求；

具体的，通过使用适配的数据读取接口执行访问请求或API请求。

步骤S205：生成测试结果；

具体的，执行后的加工逻辑，负责存储输入、输出，断言测试结果。

步骤S206：输出测试结果。

可以理解的是，所述测试案例数据读取单元、测试资源数据读取单元以及测试项目参数读取单元、报文加密解密单元、授权和签名单元以及脚本执行单元、案例执行单元、资源执行单元以及协议执行单元均为通过代码编程实现的函数方法，用于执行相应的功能，例如：数据读取接口(DataProvider)、逻辑处理接口(ExcuteListener)以及执行实现接口(Excutor)是执行引擎的主要接口，分别负责数据读取、执行前后的逻辑处理、执行的实现。

其中，测试案例数据读取单元通过TestCaseDataProvider函数方法实现，负责测试案例数据读取，测试资源数据读取单元通过ResourceDataProvider函数方法实现，负责测试资源数据读取，测试项目参数读取单元通过ProjectPrarameterProvider函数方法实现，负责测试项目参数的读取，报文加密解密单元通过CryptionListener函数方法实现，负责执行前后报文的加密解密，授权和签名单元通过AuthorizationListener函数方法实现负责授权和签名，脚本执行单元通过ScriptListener函数方法实现，负责script脚本执行，对输入和输出进行再次加工，案例执行单元通过TestCaseExcutor函数方法实现负责执行案例，资源执行单元通过ResurceExcutor函数方法实现，负责执行资源，协议执行单元通过RestfulExcutor函数方法实现，负责http协议执行。

请参阅图3a，图3a是本发明实施例提供的车险数据测试方法的一个可选的流程示意图。如图3a所示，车险数据测试方法S300包括：

S31：获取业务测试指令；

在本实施例中，业务测试指令用于测试对应车险业务类型下的业务逻辑是否正确，其中，每类业务测试指令指向对应业务类型的车险业务，车险业务包括续保、脱保、转保等业务类型，在一些实施例中，业务测试指令对应的业务类型为至少两种，例如，第一业务测试指令对应续保业务类型，第二业务测试指令对应脱保业务类型，第三业务测试指令对应转保业务类型，以此类推。测试时，测试人员可以测试多种业务场景下的各类业务逻辑是否正确，因此，本实施例的方法能够实现多场景的案例测试，提高整体测试覆盖度。

在一些实施例中，测试平台还可以为用户提供一些特性业务选项，例如，特性业务选项包括：选择验证类型、选择是否三者翻倍、填写任务代码、选择保险公司等等，验证类型包括实名短信验证、实名非短信验证、非实名短信验证等等，当用户勾选了“实名短信验证”，在“是否三者翻倍”打叉，填写“任务代码”为001，选择“保险公司A”，于是，测试平台将选择的业务类型及特性业务封装成业务测试指令，向服务器发送，以便服务器产生出既符合业务类型的测试结果，又符合业务特性选择的测试结果，从而能够满足互联网车险业务类型繁多的需求。

在本实施例中，业务测试指令的获取方式比较繁多，例如，用户登录测试平台，在测试平台的测试页面选择业务类型或者业务类型与特性业务的组合，于是，测试平台便分发出业务测试指令。再例如，测试人员远程向测试平台发送业务测试指令，于是，测试平台便可得到业务测试指令。

S32：从预设测试用例库遍历出业务测试指令指向的目标测试用例，其中，预设测试用例库包括多个测试用例，各个测试用例共用相同的测试字段；

在本实施例中，测试用例用于为了测试车险业务而构建的测试数组，可以理解的是，在每项车险业务类型下，其可对应一个测试用例，亦可以对应多个测试用例。

请参阅图3b，在图3b中，其包括8个测试用例，有续保及脱保的两种业务类型，其中，对于续保业务类型，其对应4个测试用例。对于脱保业务类型，其对应4个测试用例。

请一并参阅图3b、图3c及图3d，其中，考虑到页面未能够清晰显示一副测试用例的示意图，故将测试用例截断并以图3c及图3d分别显示。由图3b、图3c及图3d可知，每个测试用例皆包括多种测试字段，每个测试用例的测试字段包括任务号、保司、案例代码、业务类型标识、组合方案、三者翻倍、上年数据、续保车牌报价、三者是否一致、被保人姓名、被保人身份证号码、投保人姓名、投保人身份证号码、车主姓名、车主身份证号码、车牌号码、车架号、投保地区编码、号牌种类、发动机号、品牌型号、初登日期、过户车标志、过户日期、精友车型编码等等。在每个测试字段对应的输入框内，用户可以向对应的输入框输入车险用例数据。可以理解的是，对于一些重要的车险用例数据，属于必填的部分，例如：被保人姓名、被保人身份证号码、投保人姓名、投保人身份证号码、车主姓名、车主身份证号码、车牌号码、车架号、投保地区编码，而对于一些非必要的车险用例数据，则属于选填的部分，例如：号牌种类、发动机号、品牌型号、初登日期、过户车标志、过户日期、精友车型编码。

由图3b、图3c及图3d可知，各个测试用例共用相同的测试字段，测试时，当某个业务类型不需要某个测试字段时，其可以不在该测试字段内填写车险用例数据。当某个业务类型需要某个测试字段时，其便在该测试字段内填写车险用例数据。于是，测试平台向服务器发送访问请求时，所述访问请求携带的数据包括填写车险用例数据的测试字段。

在本实施例中，在续保业务类型中，假设组合方案为单交的测试用例无需填写“发动机号”的号码、“品牌型号”的号码，则测试人员不在测试字段“发动机号”及“品牌型号”填写对应号码。在脱保业务类型中，假设组合方案为交商(商业基础)的测试用例需要填写“发动机号”的号码、“品牌型号”的号码，则测试人员便在测试字段“发动机号”及“品牌型号”填写对应号码。

在测试续保业务类型或脱保业务类型中，测试人员无需如传统技术一样，需要在报文中填写“续保业务”或“脱保业务”所需的测试字段，并且，通过友好的填写界面，其能够降低技术人员操作的门槛。并且，由于各个测试用例共用相同的测试字段，测试人员只需在测试用例的关键字段输入对应的车险用例数据，无需针对每类车险业务人工输入待测的测试字段及其测试数据，因此，此类作法的测试效率高，能够满足车险业务种类繁多的需求。

在本实施例中，当用户勾选了对应的业务类型后，于是，测试平台便生成业务测试指令指向的目标测试用例，例如，业务测试指令指向续保业务类型，于是，测试平台便生成与续保业务类型的测试用例，并将所述测试用例作为目标测试用例。

可以理解的是，“目标测试用例”与“测试用例”是相对而言，当业务测试指令指向脱保，与脱保业务类型的测试用例则为目标测试用例。当业务测试指令指向转保，与转保业务类型的测试用例则为目标测试用例，以此类推。因此，在一些实施例中，目标测试用例的数量可以为至少两个，测试平台可以同时测试多个目标测试用例，一方面，提高测试场景覆盖率，另一方面，其能够提高测试效率。

预设测试用例库用于存储预先构建的测试用例，其中，此处的测试用例可以为任意业务类型下的测试用例，当多种业务类型下的测试用例汇聚一起时，便可构成预设测试用例库。

可以理解的是，所述预测测试用例库包括若干个测试用例，每一测试用例的用例名称、用例分组、用例输入描述、用例输出描述、预期结果、用例资源均可以相同或不同，从而在预测测试用例库中保存有多个测试用例，用户可以通过输入业务测试指令，选择相应的多个测试用例，例如：用例分组相同的若干个测试用例。

在一些实施例中，从预设测试用例库遍历出业务测试指令指向的目标测试用例的方式比较繁多，例如，业务测试指令携带有业务标识，业务标识用于标识车险业务类型，每项车险业务类型均对应一个或多个测试用例，例如，续保车险业务对应第一业务标识，脱保车险业务对应第二业务标识，转保车险业务对应第三业务标识，其中，续保车险业务对应编号为001、002、003、004这四个测试用例，脱保车险业务对应编号为005、006这两个测试用例，转保车险业务对应编号为007、008、009这三个测试用例，当测试平台接收到业务测试指令，测试平台解析业务测试指令，得到业务标识，从预设测试用例库遍历出与业务标识对应的测试用例作为目标测试用例，例如，所述业务测试指令封装第一业务标识，于是，测试平台根据第一业务标识提取出001、002、003、004这四个测试用例作为目标测试用例。

在一些实施例中，在测试之前，测试平台可以预先构建测试用例，再组合各个测试用例，以构成预设测试用例库。例如，用户通过输入或选择相应的任务号、保险公司名称、案例代码、业务类型标识、组合方案、是否包含三者翻倍、上年数据(续保)、续保车牌报价等信息，生成单一的测试用例，通过组合每一测试用例，从而构建预设测试用例库。当测试平台获取到业务测试指令，测试平台解析业务测试指令，获取业务测试指令中的标识数据，例如：业务类型、地区类型、组合方案、是否上线三者翻倍、任务代码、保险公司等标识数据中的一个或多个，并根据标识数据，从后台数据库的预设测试用例库中遍历与标识数据对应的测试用例，标识数据对应的测试用例即业务测试指令指向的目标测试用例。在本实施例中，预设测试用例库保存在后台服务器的后台数据库中，后台服务器为Tomcat服务器，后台数据库为MySQL数据库。

S33：接收在目标测试用例下的测试字段输入的车险用例数据，并将目标测试用例与车险用例数据组装成访问请求；

在本实施例中，车险用例数据的接收方式比较繁多，例如，通过在测试平台的界面上选取文件，即选取相应的测试文件，测试平台将根据选择的测试文件，确定测试文件对应的参数，例如：保险公司、车牌号、业务类型、车架号、地区码、投保人姓名、状态以及导入时间，通过测试平台的界面进行呈现，用户可以在测试文件中输入车险用例数据。再例如，在图3b所示的页面显示有“导出数据模板”的按钮控件，通过单击所述按钮控件，于是便呈现图3c及图3d所示的预设数据模板，其中，车险用例数据可以输入在预设数据模板中。请参阅图3e，等测试人员输完车险用例数据后，单击上传按钮控件，于是，测试平台加载填写有车险用例数据的预设数据模板，并且测试平台将目标测试用例与车险用例数据组装成访问请求。

在一些实施例中，测试人员在预设数据模板填写车险用例数据时，启动预设数据模板校验车险用例数据，若校验成功，得到在目标测试用例下的测试字段输入的的车险用例数据，若校验失败，生成第二提示信息，根据第二提示信息获取重新输入的车险用例数据，并重复执行启动预设数据模板校验所述车险用例数据的步骤。例如，预设数据模板自动检查车险用例数据的输入格式是否合法，若合法，则校验成功，若非法，则校验失败，于是，用户需要重新在预设数据模板输入车险用例数据，直至预设数据模板自动检查车险用例数据的输入格式是合法的。

S34：向服务器发送访问请求，以使服务器根据访问请求返回用例执行结果；

在本实施例中，用例执行结果包括用例执行成功结果与用例执行失败结果，用例执行成功结果用于指示服务器能够成功执行测试平台发送的在对应业务类型下的车险用例数据，用例执行成功结果用于指示服务器未能够成功执行测试平台发送的在对应业务类型下的车险用例数据。

在本实施例中，测试平台向服务器发送访问请求，其中，访问请求携带业务类型标识及其车险用例数据，测试平台解析访问请求，从访问请求提取出业务类型标识及车险用例数据，服务器根据业务类型标识，选择与之对应的测试逻辑，结合车险用例数据进行测试，并向测试平台返回用例执行结果。

S35：呈现用例执行结果。

在本实施例中，测试平台接收服务器发送的用例执行结果，并在测试界面上呈现用例执行结果。

请参阅图3f，测试平台在此页面上表征用例执行结果，例如，在“出单”项目下显示有“出单成功”或“投保成功”等等状态。在“出单回调”中，当测试人员确认测试结果无误后，可以在单击“未确认”，于是，测试平台便可以关闭此测试用例。

总体而言，从整体角度看本方法，其能够全流程地完成测试，减少测试人员参与的时间，相对地缩短平台对接时间。并且，由于测试用例比较直观友好，测试人员容易操作测试用例以完成测试。

一般的，测试人员偶尔忘记测试完某个业务类型下的全部测试用例，或者，测试容易失败而无法找出原因，因此，为了避免上述情况，在一些实施例中，请一并参阅图3g和图3h，车险数据测试方法S300还包括：

S36：生成全部目标测试用例共用的任务编号；

S37：获取在任务编号下全部目标测试用例的用例执行结果；

S38：根据全部目标测试用例的用例执行结果，生成测试图表。

在本实施例中，在遍历出业务测试指令指向的目标测试用例时，与此同时，测试平台生成如图3b所示的在任务编号“task-001”下的全部目标测试用例，例如，目标测试用例全部在续保业务类型下。

当每个目标测试用例被填写对应的车险用例数据，并且被运行后，得到每个目标测试用例的用例执行结果，测试平台便可以记录每个目标测试用例的用例执行结果，诸如，记录成功次数、失败次数、成功率、平均耗时及是否已被执行。

于是，当测试平台抓取到每个目标测试用例的用例执行结果，便可以根据全部目标测试用例的用例执行结果，生成测试图表，例如，测试平台可以显示哪个目标测试用例还未被执行或者成功失败与否等等。

通过测试图表，测试人员可以确认目前何种业务类型尚未测通，确保交叉测试覆盖程度、整体测试进度及覆盖情况。

在一些实施例中，在预先构建测试用例时，为了提高满足互联网车险种类繁多的需求，请一并参阅图4a与图4b，构建测试用例步骤包括：

S41、获取用例新增指令；

S42、根据用例新增指令，呈现用例新增页面，用例新增页面包括用例名称框及用例描述框；

S43、接收在用例名称框输入的用例名称，以及在用例描述框输入的用例描述内容；

S44、根据用例名称及用例描述内容，构建测试用例。

在本实施例中，用例新增指令用于指示测试平台呈现用例新增页面，用例新增指令的获取方式比较繁多，例如，测试平台存在新增用例控件，测试人员单击新增用例控件，新增用例控件分发出用例新增指令，于是，测试平台呈现如图4b所示的用例新增页面。

在用例新增界面中，用例名称框用于输入用例名称，例如：单商业，多种险别调整报价，用例描述框包括用例输入描述框以及用例输出描述框，用例输入描述框用于输入用例输入描述，例如：多种险别调整报价，注：请求报文中保单生效起日和讫日为Null，此种场景是去年保交强，调整报价时，追加商业，剔除交强继续下单，也可能是去年在本司只有商业，所述用例输出描述框用于输入用例输出描述，例如：1、请注意有些险别没有传送保额的请根据车身价计算并返回；2、投保的玻璃破损险别中的玻璃类型。

在一些实施例中，用例新增界面还包括用例分组框、预期结果框及用例资源框，用例分组框用于输入或选择用例分组，例如：业务测试用例。预期结果框用于输入预期结果，例如：报价成功。用例资源框用于添加用例资源，例如：车险续保报价接口。

通过向用例新增界面中的用例名称框输入用例名称和用例描述框中输入用例描述，用例描述包括用例输入描述以及用例输出描述，并且，通过向用例分组框中输入或选择用例分组，向预期结果框中输入预期结果，向用例资源框中输入或选择相应的用例资源，并确认对用例新增界面的修改，点击确认修改后将用例新增界面的数据上传到测试平台，后台服务器将根据用例新增界面的数据，生成测试用例。

在一些实施例中，为了验证测试平台是否能够正常地向服务器发送测试数据或者检测服务器是否正常向测试平台发送测试数据，于是，在一些实施例，在获取业务测试指令之前，请一并参阅图4c与图4d，车险数据测试方法S300还包括：

S45、获取在数据校验模板输入的车险基础数据；

S46、启动数据校验模板校验车险基础数据；

S47、若校验成功，向服务器发送数据校验模板；

S48、若校验失败，生成第一提示信息，根据第一提示信息获取重新输入的车险基础数据，并返回S46。

在本实施例中，测试平台通过提供数据校验模板的方式，供用户输入车险基础数据，用户通过在数据校验模板中输入车险基础数据，车险基础数据包括车辆信息、相关人信息、投保地区编码信息。车险基础数据中的车险信息包括：车牌号码以及车架号，相关人信息包括：被保人姓名、被保人身份证号码、投保人姓名、投保人身份证号码、车主姓名、车主身份证号码。在用户通过数据校验模板输入该车险基础数据后，所述测试平台将获取车险基础数据，具体的，测试平台的后台服务器将获取车险基础数据。

在本实施例中，通过数据校验校验车险基础数据的格式是否正确填写，若车险基础数据中的每一项信息均正确填写，则校验成功，若车险基础数据中存在至少一项信息填写错误，则校验失败。

在一些实施例中，数据校验模板可以选择Excel模板等等任意合适校验模板，其中，数据校验模板自带校验功能，当输入的车险基础数据未符合数据校验模板的数据格式要求时，测试平台生成第一提示信息，于是，测试人员根据第一提示信息，重新在数据校验模板内输入车险基础数据，接着，测试平台再启动数据校验模板校验车险基础数据，直至校验成功，从而得到正确的车险基础数据。

在一些实施例中，如前所述，测试平台配置有报价接口、投保接口和/或出单接口，为了测试服务器与测试平台之间的报价接口或投保接口或出单接口是否通畅，在向服务器发送所述数据校验模板的过程中，将数据校验模板组装成校验请求，并且选择测试接口，通过测试接口向服务器发送校验请求，以使服务器根据校验请求返回数据校验结果，例如，测试接口包括报价接口、投保接口和/或出单接口，校验请求对应的业务类型为续保是否成功报价或者投保或者出单，于是，测试平台将校验请求发送服务器对应的接口，以检测服务器与测试平台之间的报价接口或投保接口或出单接口是否通畅，例如，测试平台选择报价接口，并通过报价接口将校验请求发送给服务器，以检测服务器是否能够实现正常报价，再例如，测试平台选择投保接口，并通过投保接口将校验请求发送给服务器，以检测服务器是否能够实现正常投保，再例如，测试平台选择出单接口，并通过出单接口将校验请求发送给服务器，以检测服务器是否能够实现正常出单。

可以理解的是，测试平台可以依序调用报价接口、投保接口及出单接口，访问服务器，以便测试平台与服务器测试对应车险业务类型下的车险业务是否正常完成报价-投保-出单这个业务过程，例如，测试平台调用报价接口访问服务器，服务器向测试平台返回报价成功信息。于是，测试平台根据报价成功信息，调用投保接口访问服务器，服务器向测试平台返回投保成功信息。于是，测试平台根据投保成功信息，调用出单接口访问服务器，服务器向测试平台返回出单成功信息。至此，测试平台已完整测试整个车险业务的全部过程。

在一些实施例中，测试接口还包括短信验证接口、实名认证接口和投保状态接口中的至少一种或者两种以上的组合，在测试平台完成报价或投保或出单时，测试平台还可以调用其它测试接口，已完成特殊业务的需求，例如，在投保时，测试平台还可以调用短信验证接口，向对应测试用户的手机发送短信，当测试用户通过手机返回短信验证码时，测试平台判断所述短信验证码是否匹配预先生成的验证码，若是，则测试平台继续执行未完成的投保逻辑，若否，则测试平台暂停执行未完成的投保逻辑。

再例如，在投保时，测试平台还可以调用实名认证接口，向对应测试用户的手机发送实名认证请求，当测试用户通过手机完成实名认证后，向测试平台发送实名认证完成请求。测试平台根据实名认证完成请求，记录所述测试用户的实名认证信息。

再例如，为了查询某个用户的投保状态，以便根据所述用户的投保状态实现其它业务逻辑，于是，测试人员还可以通过测试平台下发投保状态查询指令，测试平台根据投保状态查询指令，调用投保状态接口访问服务器，以使服务器返回所述用户的投保状态。

可以理解的是，测试平台还可以预先配置实现其它业务逻辑的测试接口，并不局限本文所阐述的上述测试接口。

总体而言，通过向测试平台配置用于实现不同业务逻辑的测试接口，一方面，其不仅能够正常完成报价-投保-出单等基础业务的测试，另一方面，其还满足不同车险业务类型所需的验证需求等等需求。

在一些实施例中，选择测试接口时，测试人员可以向测试平台下发接口调用请求，于是测试平台获取接口调用请求，接口调用请求封装有接口调用字段，选择与接口调用字段对应的接口作为测试接口。或者，在一些实施例中，当测试平台将数据校验模板组装成校验请求后，测试平台自动选择测试接口进行调用。

在一些实施例中，数据校验结果包括校验成功结果与校验失败结果，当数据校验结果为校验成功结果时，通过小程序进行端对端测试。由于数据校验结果为校验成功结果的车险基础数据是满足保险公司的保险规则以及相关的保险法律或条例的，于是，后续测试人员还可以借用该车险基础数据实现内部的小程序的端对端测试，例如，测试人员通过在小程序平台上进行接口对接、数据测试等测试操作，确保小程序平台与服务器之间的正常交互，根据小程序平台与服务器之间的测试操作，生成测试结果，测试结果包括正常结果以及异常结果。

当数据校验结果为校验失败结果时，生成第一提示信息，第一提示信息用于提示重新在Excel模板输入车险基础数据。

为了详细阐述本发明实施例提供的车险数据测试方法的工作原理，本实施例结合图5作出进一步的阐述，如下所示：

如图5所示，该车险数据测试方法，应用于车险测试系统，所述车险测试系统包括：保险平台、测试平台以及小程序平台，其中，上述各个实施例所阐述的服务器构成保险平台，保险平台与测试平台以及小程序平台之间相互通信连接。

车险数据测试方法流程如下：

S51：选择业务测试场景；

在本实施例中，业务测试场景包括：续保、脱保、转保等测试场景。所述保险公司的业务人员或技术人员通过登录所述测试平台，在测试平台的用户界面上选择业务测试场景，并将选择的业务测试场景通过业务测试指令的方式发送到测试平台。

S52：生成需覆盖测试用例；

S53：导出目标测试用例；

在本实施例中，测试平台接收到业务测试指令后，解析业务测试指令，在预设测试用例库中遍历业务测试场景对应的目标测试用例。

S54：准备测试数据，检查测试数据；

接收与测试用例对应的测试数据，并通过预设数据模板对测试数据进行校验，若校验成功，则进入S55：上传测试数据；

S55：上传测试数据；

S56：生成测试数据；

测试平台根据保险公司上传的测试数据，生成相应的测试数据，并将测试数据发送到保险平台，以使保险平台执行测试数据。

S57：执行用例；

保险平台接收测试数据后，将执行测试用例。

S58：记录用例执行结果；

测试平台记录保险公司平台对测试用例的用例执行结果，通过业务覆盖图表的形式对用例执行结果进行呈现，并将用例执行结果发送到保险平台，以使保险平台的工作人员查看用例执行情况。

S59：查看用例执行情况；

保险公司的工作人员查看用例执行情况，请再参阅图3h，保险公司的工作人员可以查看用例平均响应时间、用例成功率、失败率、平均耗时、是否已执行等执行情况。

S510：判断案例是否完全覆盖，若是，则进入S511；若否，则返回S57；

保险公司的工作人员根据用例执行情况，例如：用例成功率、失败率等信息，判断所述测试场景是否已完全覆盖，若是，则将用例执行情况发送到小程序平台，以使小程序平台进行进一步的验收；若否，则返回S57：继续执行用例，重复进行直至测试场景完全覆盖；

S511：提交验收；

保险公司平台将用例执行情况发送到小程序平台，以使小程序平台的工作人员对测试执行情况进行验收。

S512：判断是否完全覆盖，若是，则测试完成，若否，则进入步骤S513；

小程序平台的工作人员根据用例执行情况，检查用例覆盖情况，判断用例是否完全覆盖，若是，则测试完成，若否，则进入S513；

S513：通知保险公司测试人员，重新检查覆盖情况；

小程序平台向保险公司平台发送提示消息，通过提示消息提示保险公司测试人员，以使保险公司测试人员重新检查用例覆盖情况，直至小程序平台的工作人员确定用例完全覆盖，此时测试完成。

在本实施例中，通过保险公司平台检查覆盖情况之后，进一步小程序平台对覆盖情况进行检查，能够确保用例覆盖完全，提高整体测试覆盖度。

需要说明的是，在上述各个实施例中，上述各步骤之间并不必然存在一定的先后顺序，本领域普通技术人员，根据本发明实施例的描述可以理解，不同实施例中，上述各步骤可以有不同的执行顺序，亦即，可以并行执行，亦可以交换执行等等。

作为本发明实施例的另一方面，本发明实施例提供一种车险数据测试装置。其中，车险数据测试装置可以为软件模块，所述软件模块包括若干指令，其存储在存储器内，处理器可以访问该存储器，调用指令进行执行，以完成上述各个实施例所阐述的车险数据测试方法。

在一些实施例中，车险数据测试装置亦可以由硬件器件搭建成的，例如，车险数据测试装置可以由一个或两个以上的芯片搭建而成，各个芯片可以互相协调工作，以完成上述各个实施例所阐述的车险数据测试方法。再例如，车险数据测试装置还可以由各类逻辑器件搭建而成，诸如由通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、单片机、ARM(Acorn RISC Machine)或其它可编程逻辑器件、分立门或晶体管逻辑、分立的硬件组件或者这些部件的任何组合而搭建成。

请参阅图6a，图6a是本发明实施例提供的一种车险数据测试装置的示意图。如图6a所示，车险数据测试装置600包括测试项目管理器61与测试执行引擎62。

测试项目管理器61用于获取业务测试指令，从预设测试用例库遍历出业务测试指令指向的目标测试用例，其中，预设测试用例库包括多个测试用例，各个测试用例共用相同的测试字段。

测试执行引擎62用于接收在目标测试用例下的测试字段输入的车险用例数据，并将目标测试用例与车险用例数据组装成访问请求，向服务器发送访问请求，以使服务器根据访问请求返回用例执行结果，呈现用例执行结果。

一方面，由于各个测试用例共用相同的测试字段，测试人员只需在测试用例的关键字段输入对应的车险用例数据，无需针对每类车险业务人工输入待测的测试字段及其测试数据，因此，此类作法的测试效率高，能够满足车险业务种类繁多的需求。另一方面，从整体角度看本方法，其能够全流程地完成测试，减少测试人员参与的时间，相对地缩短平台对接时间。再一方面，由于测试用例比较直观友好，测试人员容易操作测试用例以完成测试。

在一些实施例中，请再参阅图6a，车险数据测试装置600还包括：用例构建模块63及用例组合模块64。

用例构建模块63用于构建测试用例；

用例组合模块64用于组合各个测试用例，以构成预设测试用例库。

在一些实施例中，请参阅图6b，用例构建模块63包括：用例新增单元631、页面呈现单元632、数据接收单元633及用例构建单元634。

用例新增单元631用于获取用例新增指令；

页面呈现单元632用于根据用例新增指令，呈现用例新增页面，用例新增页面包括用例名称框及用例描述框；

数据接收单元633用于接收在用例名称框输入的用例名称，以及在用例描述框输入的用例描述内容；

用例构建单元634用于根据用例名称及所述用例描述内容，构建测试用例。

在一些实施例中，请再参阅图6a，车险数据测试装置600还包括：模板模块65及校验启动模块66。

模板模块65用于获取在数据校验模板输入的车险基础数据；

校验启动模块66用于启动数据校验模板校验车险基础数据，若校验成功，向服务器发送所述数据校验模板；若校验失败，生成第一提示信息，根据第一提示信息获取重新输入的车险基础数据，并重复执行启动数据校验模板校验重新输入的车险基础数据。

在一些实施例中，校验启动模块66具体用于：将数据校验模板组装成校验请求，选择测试接口，通过测试接口向服务器发送所述校验请求，以使服务器根据校验请求返回数据校验结果。

在一些实施例中，校验启动模块66还具体用于：获取接口调用请求，接口调用请求封装有接口调用字段，选择与接口调用字段对应的接口作为测试接口。

在一些实施例中，测试接口包括报价接口、投保接口和/或出单接口。

在一些实施例中，数据校验结果包括校验成功结果与校验失败结果，请再参阅图6a，车险数据测试装置600还包括：端对端测试模块67及第一信息提示模块68。

端对端测试模块67用于当数据校验结果为校验成功结果时，通过小程序进行端对端测试；

第一信息提示模块68用于当数据校验结果为校验失败结果时，生成第一提示信息。

在一些实施例中，数据校验模板包括Excel模板。

在一些实施例中，目标测试用例的数量为多个。

在一些实施例中，业务测试指令对应的业务类型为至少两种。

在一些实施例中，测试项目管理器61还具体用于：解析业务测试指令，得到业务标识，业务标识用于标识车险业务类型，每项车险业务类型均对应一个或多个测试用例；从预设测试用例库遍历出与业务标识对应的测试用例作为目标测试用例。

在一些实施例中，用例数据输入在预设数据模板中，测试执行引擎62具体用于：启动预设数据模板校验车险用例数据，若校验成功，得到在目标测试用例下的测试字段输入的车险用例数据；若校验失败，生成第二提示信息，根据第二提示信息获取重新输入的车险用例数据，并重复执行启动预设数据模板校验车险用例数据。

请再参阅图6a，车险数据测试装置600还包括：测试进度跟踪模块69，测试进度跟踪模块69用于生成全部目标测试用例共用的任务编号，获取在所述任务编号下全部目标测试用例的用例执行结果，根据所述全部目标测试用例的用例执行结果，生成测试图表。

需要说明的是，上述车险数据测试装置可执行本发明实施例所提供的车险数据测试方法，具备执行方法相应的功能模块和有益效果。未在车险数据测试装置实施例中详尽描述的技术细节，可参见本发明实施例所提供的车险数据测试方法。

图7是本发明实施例提供的一种测试平台的结构示意图。如图7所示，该测试平台700包括一个或多个处理器71以及存储器72。其中，图7中以一个处理器71为例。

处理器71和存储器72可以通过总线或者其他方式连接，图7中以通过总线连接为例。

存储器72作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本发明实施例中的车险数据测试方法对应的程序指令/模块。处理器71通过运行存储在存储器72中的非易失性软件程序、指令以及模块，从而执行各种功能应用以及数据处理，即实现上述方法实施例提供的车险数据测试方法以及上述装置实施例的各个模块或单元的功能。

存储器72可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器72可选包括相对于处理器71远程设置的存储器，这些远程存储器可以通过网络连接至处理器71。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

所述程序指令/模块存储在所述存储器72中，当被所述一个或者多个处理器71执行时，执行上述任意方法实施例中的车险数据测试方法。

本发明实施例的测试平台700以多种形式存在，在执行以上描述的图7所示的各个步骤；也可实现所述的各个单元的功能时，上述测试平台700包括但不限于：塔式服务器、机架式服务器、刀片式服务器及云服务器。

本发明实施例还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个处理器执行，例如图7中的一个处理器71，可使得上述一个或多个处理器可执行上述任意方法实施例中的车险数据测试方法。

本发明实施例还提供了一种计算机程序产品，所述计算机程序产品包括存储在非易失性计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被测试平台执行时，使所述测试平台执行上述的车险数据测试方法。

以上所描述的装置或设备实施例仅仅是示意性的，其中所述作为分离部件说明的单元模块可以是或者也可以不是物理上分开的，作为模块单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络模块单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

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

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；在本发明的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本发明的不同方面的许多其它变化，为了简明，它们没有在细节中提供；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims

1.一种车险数据测试方法，应用于测试平台，其特征在于，所述方法包括：

获取业务测试指令；

呈现所述用例执行结果。

2.根据权利要求1所述的方法，其特征在于，在获取业务测试指令之前，所述方法还包括：

构建测试用例；

组合各个所述测试用例，以构成预设测试用例库。

3.根据权利要求2所述的方法，其特征在于，所述构建测试用例，包括：

获取用例新增指令；

根据所述用例新增指令，呈现用例新增页面，所述用例新增页面包括用例名称框及用例描述框；

接收在所述用例名称框输入的用例名称，以及在所述用例描述框输入的用例描述内容；

根据所述用例名称及所述用例描述内容，构建测试用例。

4.根据权利要求1所述的方法，其特征在于，在获取业务测试指令之前，所述方法还包括：

获取在数据校验模板输入的车险基础数据；

启动所述数据校验模板校验所述车险基础数据；

若校验成功，向所述服务器发送所述数据校验模板；

若校验失败，生成第一提示信息，根据所述第一提示信息获取重新输入的车险基础数据，并重复执行启动所述数据校验模板校验重新输入的车险基础数据。

5.根据权利要求4所述的方法，其特征在于，所述向所述服务器发送所述数据校验模板，包括：

将所述数据校验模板组装成校验请求；

选择测试接口；

通过所述测试接口向所述服务器发送所述校验请求，以使所述服务器根据所述校验请求返回数据校验结果。

6.根据权利要求5所述的方法，其特征在于，所述选择测试接口，包括：

获取接口调用请求，所述接口调用请求封装有接口调用字段；

选择与所述接口调用字段对应的接口作为测试接口。

7.根据权利要求6所述的方法，其特征在于，所述测试接口包括报价接口、投保接口和/或出单接口。

8.根据权利要求5所述的方法，其特征在于，所述数据校验结果包括校验成功结果与校验失败结果，所述方法还包括：

当所述数据校验结果为校验成功结果时，通过小程序进行端对端测试；

当所述数据校验结果为校验失败结果时，生成所述第一提示信息。

9.根据权利要求4所述的方法，其特征在于，所述数据校验模板包括Excel模板。

10.根据权利要求1所述的方法，其特征在于，所述目标测试用例的数量为至少两个。

11.根据权利要求1所述的方法，其特征在于，所述业务测试指令对应的业务类型为至少两种。

12.根据权利要求1至11任一项所述的方法，其特征在于，所述从预设测试用例库遍历出所述业务测试指令指向的目标测试用例，包括：

解析所述业务测试指令，得到业务标识，所述业务标识用于标识车险业务类型，每项所述车险业务类型均对应一个或多个测试用例；

从预设测试用例库遍历出与所述业务标识对应的测试用例作为目标测试用例。

13.根据权利要求1至11任一项所述的方法，其特征在于，所述车险用例数据输入在预设数据模板中，所述接收在所述目标测试用例下的测试字段输入的车险用例数据，包括：

启动所述预设数据模板校验所述车险用例数据；

若校验成功，得到在所述目标测试用例下的测试字段输入的车险用例数据；

若校验失败，生成第二提示信息，根据所述第二提示信息获取重新输入的车险用例数据，并重复执行启动所述预设数据模板校验所述车险用例数据。

14.根据权利要求1至11任一项所述的方法，其特征在于，所述方法还包括：

生成全部目标测试用例共用的任务编号；

获取在所述任务编号下全部目标测试用例的用例执行结果；

根据所述全部目标测试用例的用例执行结果，生成测试图表。

15.一种车险数据测试装置，应用于测试平台，其特征在于，所述装置包括：

16.一种测试平台，其特征在于，包括：

至少一个处理器；和

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-14任一项所述的车险数据测试方法。

17.一种非易失性计算机可读存储介质，其特征在于，所述非易失性计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使测试平台执行如权利要求1-14任一项所述的车险数据测试方法。

18.一种车险测试系统，其特征在于，包括：

如权利要求16所述的测试平台；和

服务器，所述服务器与所述测试平台通讯连接。