CN113609011B - 一种保险产品工厂的测试方法、装置、介质和设备 - Google Patents

Abstract

本发明提供一种保险产品工厂的测试方法、装置、介质和设备，该方法包括在测试系统中建立多个测试域；在每一个测试域下，针对不同的测试案例建立与测试案例对应的测试目录；将待测试案例导入对应的测试目录中；对测试目录中的每一条案例进行测试，并记录测试结果；针对测试结果为失败的案例，上传失败的案例对应的测试数据；对测试数据进行分析，依据分析结果重新验证失败的案例直至测试成功，同时更改测试结果。本发明实施例在产品工厂技术方案的基础上实现多个模块或者组件的并行测试时，提高了测试效率。

Description

一种保险产品工厂的测试方法、装置、介质和设备

技术领域

本发明涉及软件测试技术领域，具体涉及一种保险产品工厂的测试方法、装置、介质和设备。

背景技术

随着我国经济的快速发展，人们生活水平不断提高，风险保障意识也日益增强，为保险行业的快速发展提供了良好的外部环境，各个保险公司也因此不断推出符合人们需求的保险产品。现有的，在做产品测试时，以往的测试方法是针对单一产品或少量新发产品的端到端测试：当一个产品完全开发完成后，对产品按照契约到保全到理赔的顺序，从产品的规则、梳理计算、渠道等角度进行全覆盖，测试过程都是串行的。

发明人经过研究发现，现有的测试方法存在效率和规模上的局限：1是针对一款产品从开发到测试是是一个串行的过程，不能满足产品快速上线的要求；2是无法应对全量产品重构的大规模测试，难以保障测试的完整性和充分性。

发明内容

有鉴于此，本发明实施例的目的在于提供一种保险产品工厂的测试方法、装置、介质和设备，以实现对保险产品工厂的全面并行测试，提高测试效率。

为达上述目的，第一方面，本发明实施例提供了一种保险产品工厂的测试方法，包括：

在测试系统中建立多个测试域；

在每一个测试域下，针对不同的测试案例建立与所述测试案例对应的测试目录；

将待测试案例导入对应的测试目录中；

对所述测试目录中的每一条待测试案例进行测试，并记录测试结果；

针对所述测试结果为失败的案例，将所述失败的案例对应的测试数据上传到对应的测试目录；

对所述测试数据进行分析，依据分析结果重新验证所述失败的案例直至测试结果为成功，更改所述测试结果。

在一些可能的实施方式中，所述的多个测试域包括应用组装测试域、应用总装测试域和产品测试域中的任意一种或多种，其中：

在所述应用组装测试域下针对多个程序模块建立对应的模块测试目录，根据所述模块测试目录对每个程序模块进行覆盖测试；

在所述应用总装测试域下面针对不同的业务流程建立对应的流程测试目录，根据所述流程测试目录对所述不同的业务流程进行全生命周期的端到端的流程测试；

在所述产品测试域下针对不同的产品建立产品测试目录，根据所述产品测试目录对有修改产品条件和有修改产品部件的保险产品进行测试。

在一些可能的实施方式中，所述的根据所述模块测试目录对每个程序模块进行覆盖测试，具体可以包括：

从业务规则、打印通知、批处理、数理计算、报表和销售渠道方面对所述多个程序模块进行覆盖测试；

其中，在所述覆盖测试过程中遵循边界界定原则，所述边界界定原则是指在测试所述多个组件中的任意一个组件的功能时，当涉及与所述多个组件中的其它组件的交互协同测试时，由当前测试组件主导推进测试执行工作；当存在所述多个组件共同协作时，所述多个组件共同确保结果正确性。

在一些可能的实施方式中，所述的覆盖测试是指按照需求用例说明书对所述每个程序模块中的多个组件的功能点进行逐一测试，确保所述多个程序模块符合设计的要求且所述多个组件的功能正常。

在一些可能的实施方式中，所述的根据所述流程测试目录对所述不同的业务流程进行全生命周期的端到端的流程测试，具体可以包括：

从业务流程角度模拟用户场景、并串联业务流程的相关系统，进行全生命周期的端到端的流程测试。

在一些可能的实施方式中，所述的根据所述产品测试目录对有修改产品条件和有修改产品部件的保险产品进行测试，具体可以包括：

根据所述保险产品的类别，查找与所述保险产品对应的测试案例库，在所述测试案例库的基础上重新编写测试案例。

在一些可能的实施方式中，所述的应用总装测试域还包括专项测试子域，在所述的专项测试子域下针对专项业务建立专项测试子目录，通过所述专项测试子目录从业务层面针对预设功能或满足预设条件的功能做加强和补充测试，确保专项业务的功能正确性。

在一些可能的实施方式中，所述的专项测试子目录包括产品专项测试子目录和保单账户专项测试子目录；

通过所述产品专项测试子目录对所述保险产品实例化后的相关流程、数理算法、产品规则、保单和短信进行测试，以确保与所述保险产品具有关联性的配套系统对接的正确性；

通过所述保单账户专项测试子目录对保单账户变更的操作进行测试，以确保保单账户层面的正确性和客户层面账户累计情况场景实现的正确性。

在一些可能的实施方式中，所述的通过所述保单账户专项测试子目录对保单账户变更的操作进行测试，具体可以包括：

针对保单账户类型结合在售保险产品以及生产存量有效保单，选择保险产品进行测试；

针对每个保单账户，分析能够影响所述保单账户的业务操作；

对所述业务操作结合实际业务场景进行组合排列，形成包含至少两个业务操作的实际业务场景；

结合所述实际业务场景及所述保单账户的经验库，测试至少两个业务操作的实际业务场景，通过对同一账户进行两次及以上的业务操作，验证保单账户的正确性。

在一些可能的实施方式中，所述的从业务流程角度模拟用户场景，具体包括：

从客户行为角度，通过需求文档、历史经验值和用户意见分析客户的行为场景；

从系统实现角度，通过需求文档、历史经验值和开发建议分析复杂的业务场景；

从仿生产角度，通过生产缺陷、批处理需求和开发建议分析基于生产环境问题的业务场景。

在一些可能的实施方式中，所述的根据所述保险产品的类别，查找与所述保险产品对应的测试案例库，在所述测试案例库的基础上重新编写测试案例，具体可以包括：

根据所述保险产品对应的产品测试案例库，从所述产品测试案例库中提取原有保险产品的测试案例；

结合修改后的保险产品的条件和部件，在所述原有保险产品的测试案例的基础上进行修改获得新增或调整所述修改后的保险产品的测试案例。

第二方面，本发明提供了一种保险产品工厂的测试装置，包括：

测试域建立模块，用于在测试系统中建立多个测试域；

测试目录建立模块，用于在每一个测试域下，针对不同的测试案例建立与所述测试案例对应的测试目录；

导入模块，用于将待测试案例导入对应的测试目录中；

测试与记录模块，用于对测试目录中的每一条待测试案例进行测试，并记录测试结果；

上传模块，用于针对所述测试结果为失败的案例，将所述失败的案例对应的测试数据上传到对应的目录；

分析模块，用于对所述测试数据进行分析，依据分析结果重新验证所述失败的案例直至测试结果为成功，更改所述测试结果。

第三方面，本发明提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述任意一种保险产品工厂的测试方法。

第四方面，本发明提供了一种保险产品工厂的测试设备，其包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述任意一种保险产品工厂的测试方法。

上述技术方案具有如下有益效果：本发明实施例在测试系统中建立多个测试域；在每一个测试域下，针对不同的测试案例建立与测试案例对应的测试目录；导入待测试的案例并将案例按照与所述测试目录对应的类别导入测试目录中；对测试目录中的每一条案例进行测试，并记录测试结果；针对测试结果为失败的案例，上传失败的案例对应的测试数据；对测试数据进行分析，依据分析结果重新验证失败的案例直至测试成功，同时更改测试结果。本发明实施例在产品工厂技术方案的基础上进行测试时，例如产品实例化、梳理计算公式验证、规则引擎验证，都可以并行操作，在后续的测试中多个组件如契约、理赔等也可以并行测试，大大节约了测试时间，提高了测试效率。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例的一种保险产品工厂整体技术方案的示意图；

图2是本发明实施例的一种保险产品工厂的测试方法的流程图；

图3是本发明实施例的一种在测试系统中建立多个测试域的示意图；

图4是本发明实施例的一种保险产品工厂的测试装置的功能框图；

图5是本发明实施例的一种计算机可读存储介质的功能框图；

图6是本发明实施例的一种保险产品工厂的测试设备的功能框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

图1是本发明实施例的一种保险产品工厂整体技术方案的示意图，如图1所示，保险产品工厂主要包括如下三大模块：

分类产品装配模式与分层产品定义配置模块：保险产品的产品参数是分类产品装配模式结构化的成果，是构成产品装配模式的最基本的业务元素，表示保险产品的某种限制、限额、约束和规则。

通过对保险产品说明书和保险产品合约中的产品条件进行系统梳理与逻辑抽象，完成产品条件的参数化设计；这些参数分别描述了保险产品在不同对象上的特征，不同的特征形成了不同的保险产品，也体现了保险产品不同分类的本质。

这些保险产品的产品参数从应用范围的角度来看，也是不同的，可以将它们划分为基础模块(包括基础参数)、运营模块(包括运营参数)和渠道模块(包括渠道参数)。基础模块以保险产品的基础定义为主，描述保险产品的本质形态，例如保险产品的基本信息、保险期间、保费定义等；这类定义的应用范围最广，是应当普遍遵循的。运营模块指的产品运营过程中需要使用到的一些条件和限制，主要是从投核保、理赔和保全的角度去考虑，例如投保规则、保单组成等；这类定义的应用范围其次，是在运营过程中产生的。渠道模块是为了支持各渠道的销售和服务而制定的，包括销售管理、销售限制等；这类定义的应用范围最小，仅适用于某一个或某一类渠道。这三个模块的参数组成一个完整的产品，另外，部分参数会存在一定交叠，交叠的参数间是递进关系，在基础模块定义某一个参数后，运营模块可结合运营要求在基础模块的范围内去重新定义这个参数，渠道模块中又可以结合渠道特性在前面两个模块的基础上再次定义。保险产品真正销售时，需要结合三个模块的定义去匹配使用。

企业级产品装配线模块：产品装配线由一组产品部件类组成，定义了装配可售产品时应遵循的产品总体结构。保险产品的产品元件类由一组不可分割的产品参数组成，表达一个完整的业务概念，例如，投保条件元件、保费限制元件等；产品部件类是关系密切的一组元件类和参数的集合，具有内聚性和可重用性，并且可以体现产品的某项功能或某种特征，例如：缴费管理部件、短期保费部件等。将产品装配线中的部件类、元件类进行实例化并形成可售产品的过程就是产品装配。

产品发布与生效模块：装配后的可售产品由产品工厂发布到渠道销售类组件和产品运营类组件，通过产品构件服务等进行数据解析后生效。产品线描述保险产品业务线，比如“个人短期险产品”；产品组是产品线下的分类，是一组定义接近的基础产品组合，比如“个人短期医疗险”、“个人短期疾病险”等；基础产品描述了一类功能相近、业务规则相似的基础产品。基础产品即通过各渠道向客户销售的产品。

本发明主要解决保险行业在进行产品工厂建设时对保险公司全量的保险产品进行结构化重构所面临的大规模保险产品测试完整性和充分性的问题。本发明提供的保险产品工厂的测试方法结合了保险产品工厂技术方案、保险产品数量、保险产品精算与数理特点以及主流测试方法等，实现了保险产品工厂测试的完整性和充分性。具体的：

图2是本发明实施例的一种保险产品工厂的测试方法的流程图。如图2所示，其包括如下步骤：

S210，在测试系统中建立多个测试域。

S220，在每一个测试域下，针对不同的测试案例建立与测试案例对应的测试目录。

S230，将待测试案例导入对应的测试目录中。

图3是本发明实施例的一种在测试系统中建立多个测试域的示意图，如图3所示，在本实施例中，测试系统是一种专门用于测试的工具，在这个测试工具下面可以建立如应用组装测试域、应用总装测试域和产品测试域中的任意一种或多种测试域，需要说明的是，测试域的多少可以依据实际情况而定，此处不做限制；在每一个测试域下面都会针对不同的测试案例建立对应的测试目录，例如契约项目、保全项目和理赔项目等多个项目，测试的时候首先选择需要测试的域和对应的项目之后，将进入一个测试界面，例如进入一个绿灯测试的目录来测试一下连通性；再比如说测规则的案例，那么就建立一个规则目录，在这个项目下面导入所有待测试的案例，把案例分类放入目录下面，测试的时候就可以进入这个目录对每一条案例进行测试。

在一些实施例中，应用组装测试域下可以针对多个程序模块建立对应的模块测试目录，根据模块测试目录对每个程序模块进行覆盖测试。

具体的，对单个程序模块、组装的多个程序模块的覆盖测试，确保程序模块符合设计的要求，组装后的组件功能正常，消除程序模块间接口、组件联通服务与设计不符的缺陷。在测试过程中，针对每一个模块测试目录按照需求用例说明书对多个组件的功能点进行逐一测试；从业务规则、打印通知、批量处理、数理计算、报表和渠道方面进行覆盖保险产品的全覆盖测试，例如，对每一条业务规则进行一反多正，多反多正的方法进行覆盖，确保每一条业务规则都被击中，保证规则使用的正确性；电子打印纸质打印、邮件通知、微信通知或短信通知等，确保正常执行，执行后数据正确、时序正确；确保资金收付相关业务正确，如保费缴纳、续期缴费、理赔金赔付等，要支持多种收付费方式。

测试过程中遵循边界界定原则，其中，边界界定原则是指在测试多个组件中的任意一个组件的功能时，涉及与多个组件中的其他组件的交互协同测试时，由使用方主导推进测试执行工作。例如，当存在多组件共同协作时，多个组件共同确保结果正确性，在测试执行推进过程中应遵循边界界定原则。边界界定原则是指在测试某一组件功能时，可能涉及与其他组件的交互协同、交互测试时，应由当前测试组件推进测试执行工作；存在多组件共同协助时，各组件共同确保结果正确性(即各自负责各自功能逻辑及数理计算的正确性，由使用方推进测试进度)。

作为一个举例说明，在建信人寿项目中，测试寿险个人承保组件的承保功能时，会调用到寿险保单管理组件的相关交易，在这个场景下，如测试发现问题，应由寿险个人承保组件推进测试执行进度，主动排查问题，由寿险保单管理组件配合，各组件保证本组件功能正确。

本发明实施例在测试过程中，能够保证组件内功能流程正确性、保证组件内功能逻辑正确性、保证组件内规则逻辑正确性、保证组件内数理计算正确性以及保证组件间的功能联调正确性。

在一些实施例中，在应用组装测试域下还可以建立多个测试子域，例如，如果需要对保险产品工厂进行专项测试，那么可以在在应用组装测试域下建立多个测试子域，例如专项测试子域，即针对预设功能或满足预设条件的功能做加强和补充测试，例如，从业务重要性及复杂性出发，针对产品、保单账户、复杂业务做加强和补充测试，保障专项业务的功能正确性，其中复杂业务是指一些复杂场景的业务，比如红利已经发放，接到报案，发现理赔出险日在红利发放前，这时需要追回已发放红利。通过专项测试来发现专项相关功能的流程、数理计算、保单数据、客户触达类和其它配套系统处理相关缺陷，确保专项功能正确性，其中其它配套系统包括承保系统、理赔系统、呼叫中心系统、客户信息系统等。

在一些实施例中，还可以在专项测试子域下建立多个子目录，例如产品专项测试子目录和保单账户专项测试子目录，针对不同的测试子目录从业务的重要性的角度针对产品、保单账户、复杂业务做加强和补充测试，确保专项业务的功能正确性。比如说有几百种保险产品，有的是在售产品，有的是停售产品，那么我们从重要性的角度先针对这些在售产品进行测试，然后再测试存量保单在一定数量以上的停售产品。

其中，通过产品专项测试子目录对保险产品实例化后的相关流程、数理算法、产品规则、保单和短信进行测试，以确保与保险产品具有关联黏性的配套系统对接的正确性；具体来说，产品专项测试主要聚焦于产品定义本身的功能正确性，确保所有产品实例化后相关流程(例如契约、保全、理赔、续期和续保等)、数理算法(例如保额保费、风险保额、风险保费、初始扣费、生存金、满期金、红利、现金价值、账户价值、理赔金)、产品规则、保单、短信进行测试，以确保和产品关联黏性较高的配套系统对接的正确性(例如财务提数、报表、佣金、呼叫中心、短信等)。

作为一个举例说明，在进行产品专项测试的过程中，首先保证公司在售产品测试通过，再测试存量保单在2000以上的停售产品，最后测试剩余产品。例如，在建信人寿项目中，首先将保险产品分为6大类，包括万能险、分红险、年金险、普通寿险、健康险、投连险。这六类产品在案例设计时有一些共性的测试点，如保险产品的投核保规则、保险产品的累积风险保额和临分规则、续期续保流程保费计算、周边系统对接等，然后针对每一类保险产品都有一些差异性的案例设计，比如分红险比较关注“周年日红利计算”、“红利领取”、“领取方式变更”，健康险比较关注“住院、门急诊理赔责任正确性”、“重疾理赔责任正确性”、“等待期验证”等。案例设计完成评审通过后，导入到案例和缺陷管理工具中执行测试过程。

在一些实施例中，通过保单账户专项测试子目录对保单账户变更的操作在保单账户层面上进行测试，以确保针对保单账户的查询动作能够正常实现。保单账户测试主要确保各种针对账户变更的操作在保单账户层面能够正确实现，确保针对账户的查询动作能够正常实现，关注客户层面账户累计情况场景实现的正确性。作为一个举例说明，在建信人寿项目中，对权益账户的业务操作有13种，增加保额、万能险追加保费、定时定额追加保险费、解决回退、万能险部分领取等，对同一账户进行两次业务操作后，验证账户的正确性。例如，针对13种业务操作的两两组合，共169种场景都会保证测试通过。

具体的，针对账户类型结合在售产品以及生产存量有效保单，选择保险产品进行测试，或者针对特殊保险产品类型，比如多账户，存在风险保费的保险产品进行测试。针对每个账户，分析会影响账户的业务操作。对所有的业务操作结合实际业务场景进行组合排列，形成包含至少2个业务操作的业务场景，结合实际业务场景及保单账户经验库，测试至少2个业务操作的业务场景，通过对同一账户进行至少2次及以上业务操作后，验证保单账户的正确性。在一些实施例中，在应用总装测试域下面针对不同的业务流程建立对应的流程测试目录，根据流程测试目录对不同的业务流程进行全生命周期的端到端的流程测试。。

本实施例中，应用总装测试域从业务流程出发，保障流程的连续性和准确性。例如模拟用户场景，考虑业务层面的连续性，串联业务流程全部相关系统，完成全生命周期的端到端流程测试；另外，发现多应用集成所引入的功能缺陷，保证与多应用关联的功能场景能被正确处理。例如，在建信人寿项目中，通过梳理单场景、交叉场景、回溯场景等方式列举业务场景，具体场景有加保后理赔，理赔出险日回溯到加保生效日之前；红利发放，理赔出险日回溯到红利派发前等。同时从仿生产角度，分析近几年的生产事件，挑选发生比例较高的业务场景进行测试。

在一些实施例中，业务流程角度模拟用户场景主要包括：1、从客户行为视角，分析典型的客户行为场景，主要来源于需求文档、历史测试经验值、用户意见；2、从系统实现视角，分析复杂的业务场景，主要来源于需求文档、历史测试经验值、开发人员的开发建议；3、从“仿生产”视角，分析基于生产环境问题应用场景，主要来源于生产缺陷、根据业务的批处理需求、开发人员的开发建议，比如说在生产过程中容易出现问题程序，比再如说开发人员在开发过程中会有一些比较复杂的程序，那么就会建议测试人员对此处进行加强测试。

在一些实施例中，在产品测试域下针对不同的产品建立产品测试目录，根据产品测试目录对有修改产品条件和有修改产品部件的保险产品进行测试。

本实施例中，在产品测试域下主要根据保险产品对应的产品测试案例库，结合产品大类特性，从业务角度(例如契约、保全、理赔)，销售渠道(例如代理人、银保、网销等)来重新编写案例。例如，结合新产品的组成条件和组成部件，在原有测试案例的基础上进行修改获得新增或调整保险产品的测试案例。这样不仅可以提高案例库的复用率，保障格式规范、步骤和预期结果描述清晰，还可以提高案例编写效率，降低执行难度。例如，在建信人寿项目中，产品分为万能险、分红险、年金险、普通寿险、健康险、投连险六大类，如果有新增一款产品，可以先确定是哪一大类产品，比如是年金险，随后从案例库中提取年金险产品的案例，结合新产品的特性和条款，在这个基础上进行少量修改就可以完成案例设计了。

S240，对测试目录中的每一条案例进行测试，并记录测试结果。

S250，针对测试结果为失败的案例，将失败的案例对应的测试数据上传到对应的测试目录。

S260，对测试数据进行分析，依据分析结果重新验证失败的案例直至测试结果为成功，更改测试结果。

本实施例中，测试人员在测试过程中针对测试目录中的每一条案例逐一进行测试，如果执行通过，就将对应的案例在对应的测试目录中标记为成功，否则标记为失败。失败的案例要关联一个缺陷，把缺陷描述清楚以后在对应的测试目录下，并上通知开发人员处理，开发人员对测试数据进行分析后给出分析结果，并将该失败的案例设置为待验证，测试人员依据分析结果重新验证直至测试通过，如测试人员验证通过，缺陷标记为已解决，关联案例标记为成功，修改测试目录下的测试结果。

本发明实施例提供的一种保险产品工厂的测试方法，在产品工厂技术方案的基础上进行测试时，例如产品实例化、数理计算公式验证、规则引擎验证等各个模块都可以并行测试操作，在后续的测试中多个组件如契约、理赔等也可以并行测试，大大节约了测试时间，提高了测试效率；同时，本发明实施例通过创建不同的域来区分测试阶段，在每个测试域的下面通过建立不同的测试项目来区分组件，可以看到整体项目的测试进展，也可以分组件看到各个组件的测试情况，同时可以记录每一个案例的测试完成情况，便于及时处理，提高测试效率。

实施例二

图4是本发明实施例的一种保险产品工厂的测试装置的功能框图。如图4所示，该装置400包括：

测试域建立模块410，用于在测试系统中建立多个测试域；

测试目录建立模块420，用于在每一个测试域下，针对不同的测试案例建立与测试案例对应的测试目录；

导入模块430，用于将待测试案例导入对应的测试目录中；

测试与记录模块440，用于对测试目录中的每一条待测试案例进行测试，并记录测试结果；

上传模块450，用于针对测试结果为失败的案例，将所述失败的案例对应的测试数据上传到对应的测试目录；

分析模块460，用于对测试数据进行分析，依据分析结果重新验证失败的案例直至测试结果为成功，更改测试结果。

本发明实施例提供的一种保险产品工厂的测试装置，在产品工厂技术方案的基础上进行测试时，例如产品实例化、数理计算公式验证、规则引擎验证等模块都可以并行测试操作，在后续的测试中多个组件如契约、理赔等也可以并行测试，大大节约了测试时间，提高了测试效率。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

实施例三

本发明实施例的一种计算机可读存储介质500的功能框图。如图5所示，计算机可读存储介质内存储有计算机程序510，计算机程序510被处理器执行时实现：

在测试系统中建立多个测试域；

在每一个测试域下，针对不同的测试案例建立与测试案例对应的测试目录；

将待测试案例导入对应的测试目录中；

对测试目录中的每一条待测试案例进行测试，并记录测试结果；

针对测试结果为失败的案例，将失败的案例对应的测试数据上传到对应的测试目录；

对所述测试数据进行分析，依据分析结果重新验证失败的案例直至测试结果为成功，更改所述测试结果。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。当然，还有其他方式的可读存储介质，例如量子存储器、石墨烯存储器等等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

实施四

图6是本发明实施例的一种保险产品工厂的测试设备的功能框图。如图6所示，保险产品工厂的测试设备600包括一个或多个处理器601、通信接口602、存储器603和通信总线604，其中，处理器601，通信接口602，存储器603通过通信总线604完成相互间的通信。

存储器603，用于存放计算机程序；

处理器601，用于执行存储器603上所存放的程序时，实现：

在测试系统中建立多个测试域；

在每一个测试域下，针对不同的测试案例建立与测试案例对应的测试目录；

将待测试案例导入对应的测试目录中；

对测试目录中的每一条待测试案例进行测试，并记录测试结果；

针对测试结果为失败的案例，将失败的案例对应的测试数据上传到对应的测试目录；

对所述测试数据进行分析，依据分析结果重新验证失败的案例直至测试结果为成功，更改所述测试结果。

上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、电子设备及可读存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (14)

1.一种保险产品工厂的测试方法，其特征在于，包括：

在测试系统中建立多个测试域；通过创建不同的域来区分测试阶段，所述的多个测试域包括应用组装测试域、应用总装测试域和产品测试域；

在每一个测试域下，针对不同的测试案例建立与所述测试案例对应的测试目录；其中，在所述应用组装测试域下针对多个程序模块建立对应的模块测试目录；在所述应用总装测试域下面针对不同的业务流程建立对应的流程测试目录；在所述产品测试域下针对不同的产品建立产品测试目录；

将待测试案例导入对应的测试目录中；

对所述测试目录中的每一条待测试案例进行测试，并记录测试结果；

针对所述测试结果为失败的案例，将所述失败的案例对应的测试数据上传到对应的测试目录；

对所述测试数据进行分析，依据分析结果重新验证所述失败的案例直至测试结果为成功，更改所述测试结果。

2.根据权利要求1所述的方法，其特征在于，所述的多个测试域包括应用组装测试域、应用总装测试域和产品测试域中的任意一种或多种，其中：

在所述应用组装测试域下针对多个程序模块建立对应的模块测试目录，根据所述模块测试目录对每个程序模块进行覆盖测试；

在所述应用总装测试域下面针对不同的业务流程建立对应的流程测试目录，根据所述流程测试目录对所述不同的业务流程进行全生命周期的端到端的流程测试；

在所述产品测试域下针对不同的产品建立产品测试目录，根据产品测试目录对有修改产品条件和有修改产品部件的保险产品进行测试。

3.根据权利要求2所述的方法，其特征在于，所述的根据所述模块测试目录对每个程序模块进行覆盖测试，具体包括：

从业务规则、打印通知、批处理、数理计算、报表和销售渠道中的任意多个方面对所述多个程序模块进行覆盖测试；

其中，在所述覆盖测试过程中遵循边界界定原则，所述边界界定原则是指在测试多个组件中的任意一个组件的功能时，当涉及与所述多个组件中的其它组件的交互协同测试时，由当前测试组件主导推进测试执行工作；当存在所述多个组件共同协作时，所述多个组件共同确保结果正确性。

4.根据权利要求2或3所述的方法，其特征在于，所述的覆盖测试是指按照需求用例说明书对所述每个程序模块中的多个组件的功能点进行逐一测试，确保所述多个程序模块符合设计的要求且所述多个组件的功能正常。

5.根据权利要求2所述的方法，其特征在于，所述的根据所述流程测试目录对所述不同的业务流程进行全生命周期的端到端的流程测试，具体包括：

从业务流程角度模拟用户场景、并串联业务流程的相关系统，进行全生命周期的端到端的流程测试。

6.根据权利要求2所述的方法，其特征在于，所述的根据所述产品测试目录对有修改产品条件和有修改产品部件的保险产品进行测试，具体包括：

根据所述保险产品的类别，查找与所述类别对应的测试案例库，根据所述测试案例库的对有修改产品条件和有修改产品部件的保险产品进行测试。

7.根据权利要求2或5所述的方法，其特征在于，所述的应用总装测试域还包括专项测试子域，在所述的专项测试子域下针对专项业务建立专项测试子目录，通过所述专项测试子目录从业务层面针对预设功能或满足预设条件的功能做加强和补充测试，确保专项业务的功能正确性。

8.根据权利要求7所述的方法，其特征在于，所述的专项测试子目录包括产品专项测试子目录和保单账户专项测试子目录；

通过所述产品专项测子目录试对所述保险产品实例化后的相关流程、数理算法、产品规则、保单和短信进行测试，以确保与所述保险产品具有关联性的配套系统对接的正确性；

通过所述保单账户专项测试子目录对保单账户变更的操作进行测试，以确保保单账户层面的正确性和客户层面账户累计情况场景实现的正确性。

9.根据权利要求8所述的方法，其特征在于，所述的通过所述保单账户专项测试子目录对保单账户变更的操作进行测试，具体包括：

针对保单账户类型结合在售保险产品以及生产存量有效保单，选择保险产品进行测试；

针对每个保单账户，分析能够影响所述保单账户的业务操作；

对所述业务操作结合实际业务场景进行组合排列，形成包含至少两个业务操作的实际业务场景；

结合所述实际业务场景及所述保单账户的经验库，测试至少两个业务操作的实际业务场景，通过对同一账户进行两次及以上的业务操作，验证保单账户的正确性。

10.根据权利要求5所述的方法，其特征在于，所述的从业务流程角度模拟用户场景，具体包括：

从客户行为角度，通过需求文档、历史经验值和用户意见分析客户的行为场景；

从系统实现角度，通过需求文档、历史经验值和开发建议分析复杂的业务场景；

从仿生产角度，通过生产缺陷、批处理需求和开发建议分析基于生产环境问题的业务场景。

11.根据权利要求6所述的方法，其特征在于，所述的根据所述保险产品的类别，查找与所述保险产品对应的测试案例库，在所述测试案例库的基础上重新编写测试案例，具体包括：

根据所述保险产品对应的产品测试案例库，从所述产品测试案例库中提取原有保险产品的测试案例；

结合修改后的保险产品的条件和部件，在所述原有保险产品的测试案例的基础上进行修改获得新增或调整所述修改后的保险产品的测试案例。

12.一种保险产品工厂的测试装置，其特征在于，包括：

测试域建立模块，用于在测试系统中建立多个测试域；通过创建不同的域来区分测试阶段，所述的多个测试域包括应用组装测试域、应用总装测试域和产品测试域；

测试目录建立模块，用于在每一个测试域下，针对不同的测试案例建立与所述测试案例对应的测试目录；其中，在所述应用组装测试域下针对多个程序模块建立对应的模块测试目录；在所述应用总装测试域下面针对不同的业务流程建立对应的流程测试目录；在所述产品测试域下针对不同的产品建立产品测试目录；

导入模块，用于将待测试案例导入对应的测试目录中；

测试与记录模块，用于对测试目录中的每一条待测试案例进行测试，并记录测试结果；

上传模块，用于针对所述测试结果为失败的案例，将所述失败的案例对应的测试数据上传到对应的测试目录；

分析模块，用于对所述测试数据进行分析，依据分析结果重新验证所述失败的案例直至测试结果为成功，更改所述测试结果。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-11中任意一项所述的一种保险产品工厂的测试方法。

14.一种保险产品工厂的测试设备，其特征在于，其包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1-11中任一所述的一种保险产品工厂的测试方法。