CN111382081A - 分录验证测试方法和装置 - Google Patents

Abstract

本发明公开了分录验证测试方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：确定目标应用组件，按照预设的案例生成规则，生成目标应用组件对应的核算场景案例；接收分录验证测试请求，按照预设的测试规则执行目标应用组件对应的核算场景案例，获得交易流水信息和会计分录；根据交易流水信息和所述会计分录进行验证测试，获得验证测试结果。该实施方式能够保证核算场景的全覆盖，还可以建立有序、高效的交易核算协同验证机制，提高分录验证测试的准确性。

Description

分录验证测试方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种分录验证测试方法和装置。

背景技术

目前国内银行交易和会计核算基本秉承紧耦合的传统，大部分国内银行还是采用与交易绑定的核算处理模式，分录产生机制按不同业务场景与交易功能绑定。由于交易与会计核算绑定会对快速响应市场变化以及加速产品创新产生制约影响，为了解决这个问题，利用独立的会计引擎实现交易与核算分离，使对客服务组件只专注于交易确认和对客服务，将会计确认和核算处理交由会计引擎等专门组件完成。

但是，在交易与核算分离模式下，现有的分录验证手段已不再适用，具体表现在以下几个方面：

1)现有分录验证通过测试人员发起，完成交易并产生分录，并验证业务服务的功能以及核算处理的准确性，因此需要测试人员具备客户体验、业务处理流程、业务服务功能以及会计核算方面的经验，而在精细化分工的背景下，很难物色到综合客户、产品、核算等方面能力的测试人员；

2)在交易与核算分离模式下，前端在完成其业务服务处理后即返回服务反馈信息，其核算流水准实时地或采用批量方式发送至会计引擎，因此从测试结果生成时间上，无法保证前端服务和会计核算同步验证，导致无法验证核算正确性；

3)在交易与核算分离模式下，分录验证主要验证分录规则和核算流水的准确性，而现有分录验证技术方案注重交易结果，不检查账务核算结果，因此无法满足测试需要。

发明内容

有鉴于此，本发明实施例提供一种分录验证测试方法和装置，能够保证核算场景的全覆盖，还可以建立有序、高效的交易核算协同验证机制，提高分录验证测试的准确性。

为实现上述目的，根据本发明实施例的第一方面，提供了一种分录验证测试方法。

本发明实施例的一种分录验证测试方法，包括：确定目标应用组件，按照预设的案例生成规则，生成所述目标应用组件对应的核算场景案例；接收分录验证测试请求，按照预设的测试规则执行所述目标应用组件对应的核算场景案例，获得交易流水信息和会计分录；根据所述交易流水信息和所述会计分录进行验证测试，获得验证测试结果。

可选地，所述按照预设的案例生成规则，生成所述目标应用组件对应的核算场景案例，包括：确定所述目标应用组件对应的验证场景；基于业务功能、产品和核算三要素组合全覆盖的原则，获取所述验证场景对应的案例目的、所述验证场景对应的案例范围和所述验证场景对应的案例验证方法；根据所述案例目的、所述案例范围和所述案例验证方法，生成所述目标应用组件对应的核算场景案例。

可选地，所述验证场景包括以下选项中至少一项：普通核算场景、段值变更场景、分录录入场景、数据同步场景。

可选地，在生成所述目标应用组件对应的核算场景案例之后，所述方法还包括：利用预设的案例审核标准对所述核算场景案例进行审核，对不符合所述预设的案例审核标准的案例进行优化；利用预设的案例验证标准对所述核算场景案例进行验证，对不符合所述预设的案例验证标准的案例进行优化。

可选地，所述预设的案例审核标准包括以下选项中至少一项：案例需要覆盖所有核算场景、案例需要覆盖产品到核算类型映射、案例需要覆盖冲正的场景、案例需要覆盖跨机构、跨系统的场景、案例需要覆盖自贸区业务、案例需要覆盖段值变更的场景；以及

所述预设的案例验证标准包括以下选项中至少一项：验证明细分录符合案例描述的场景、验证明细分录与业务标准分录一致、验证明细分录中自贸区域与业务场景一致、验证明细分录中每个机构表内科目借贷必须相等、验证明细分录中每个自贸区域内表内科目借贷必须相等、验证明细分录跨自贸往来分录结果正确、验证明细分录中的清算分录需要与清算规则一致。

可选地，所述方法还包括：预先编制人工会计分录表，根据核算规则参数生成系统会计分录表；分析所述人工会计分录表和所述系统会计分录表之间的差异，获取存在的问题，并对所述存在的问题进行优化处理。

可选地，所述预设的测试规则包括以下选项中至少一项：典型场景测试、全面测试、回归测试；以及

所述按照预设的测试规则执行所述目标应用组件对应的核算场景案例，包括：若所述预设的测试规则为典型场景测试，执行典型场景对应的典型核算场景案例；若所述预设的测试规则为全面测试，执行所述目标应用组件对应的所有核算场景案例；若所述预设的测试规则为回归测试，执行所述目标应用组件对应的经过优化的核算场景案例。

可选地，在按照预设的测试规则执行所述目标应用组件对应的核算场景案例之后，所述方法还包括：执行交易检查。

可选地，所述根据所述交易流水信息和所述会计分录进行验证测试，获得验证测试结果，包括：对所述会计分录进行分录验证测试，获得分录验证测试结果；根据所述交易流水信息和所述会计分录进行总分验证测试，获得总分验证测试结果。

可选地，在获得验证测试结果之后，所述方法还包括：根据所述验证测试结果生成差错报告，对所述差错报告进行排查分析，获得差错问题，利用预设的差错调整方法对所述差错问题进行处理。

为实现上述目的，根据本发明实施例的第二方面，提供了一种分录验证测试装置。

本发明实施例的一种分录验证测试装置，包括：生成模块，用于确定目标应用组件，按照预设的案例生成规则，生成所述目标应用组件对应的核算场景案例；执行模块，用于接收分录验证测试请求，按照预设的测试规则执行所述目标应用组件对应的核算场景案例，获得交易流水信息和会计分录；测试模块，用于根据所述交易流水信息和所述会计分录进行验证测试，获得验证测试结果。

可选地，所述生成模块还用于：确定所述目标应用组件对应的验证场景；基于业务功能、产品和核算三要素组合全覆盖的原则，获取所述验证场景对应的案例目的、所述验证场景对应的案例范围和所述验证场景对应的案例验证方法；根据所述案例目的、所述案例范围和所述案例验证方法，生成所述目标应用组件对应的核算场景案例。

可选地，所述验证场景包括以下选项中至少一项：普通核算场景、段值变更场景、分录录入场景、数据同步场景。

可选地，所述生成模块还用于：利用预设的案例审核标准对所述核算场景案例进行审核，对不符合所述预设的案例审核标准的案例进行优化；利用预设的案例验证标准对所述核算场景案例进行验证，对不符合所述预设的案例验证标准的案例进行优化。

可选地，所述预设的案例审核标准包括以下选项中至少一项：案例需要覆盖所有核算场景、案例需要覆盖产品到核算类型映射、案例需要覆盖冲正的场景、案例需要覆盖跨机构、跨系统的场景、案例需要覆盖自贸区业务、案例需要覆盖段值变更的场景；以及

所述预设的案例验证标准包括以下选项中至少一项：验证明细分录符合案例描述的场景、验证明细分录与业务标准分录一致、验证明细分录中自贸区域与业务场景一致、验证明细分录中每个机构表内科目借贷必须相等、验证明细分录中每个自贸区域内表内科目借贷必须相等、验证明细分录跨自贸往来分录结果正确、验证明细分录中的清算分录需要与清算规则一致。

可选地，所述装置还包括优化模块，用于：预先编制人工会计分录表，根据核算规则参数生成系统会计分录表；分析所述人工会计分录表和所述系统会计分录表之间的差异，获取存在的问题，并对所述存在的问题进行优化处理。

可选地，所述预设的测试规则包括以下选项中至少一项：典型场景测试、全面测试、回归测试；以及

所述执行模块还用于：若所述预设的测试规则为典型场景测试，执行典型场景对应的典型核算场景案例；若所述预设的测试规则为全面测试，执行所述目标应用组件对应的所有核算场景案例；若所述预设的测试规则为回归测试，执行所述目标应用组件对应的经过优化的核算场景案例。

可选地，所述装置还包括检查模块，用于：执行交易检查。

可选地，所述测试模块还用于：对所述会计分录进行分录验证测试，获得分录验证测试结果；根据所述交易流水信息和所述会计分录进行总分验证测试，获得总分验证测试结果。

可选地，所述装置还包括差错调整模块，用于：根据所述验证测试结果生成差错报告，对所述差错报告进行排查分析，获得差错问题，利用预设的差错调整方法对所述差错问题进行处理。

为实现上述目的，根据本发明实施例的第三方面，提供了一种电子设备。

本发明实施例的一种电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现本发明实施例的分录验证测试方法。

为实现上述目的，根据本发明实施例的第四方面，提供了一种计算机可读介质。

本发明实施例的一种计算机可读介质，其上存储有计算机程序，程序被处理器执行时实现本发明实施例的分录验证测试方法。

上述发明中的一个实施例具有如下优点或有益效果：利用预设的案例生成规则生成目标应用组件对应的核算场景案例，保证核算场景的全覆盖，同时可以完成测试案例准备工作，然后在案例执行阶段可以按照预设的测试规则执行核算场景案例，并利用获得的交易流水信息和会计分录进行验证测试，获得测试结果，从而可以建立有序、高效的交易核算协同验证机制，提高分录验证测试的准确性。此外，本发明实施例的分录验证测试方法中，还建立了投产后账务一致性保障机制，确保系统投产后账务处理的正确及连续性。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的分离验证测试方法的主要步骤的示意图；

图2是根据本发明实施例的业务功能、产品、核算三要素的映射示意图；

图3是根据本发明实施例的生成核算场景案例的方法的主要流程的示意图；

图4是根据本发明实施例的差错报告的示意图；

图5和图6是根据本发明实施例的差错调整方法的示意图；

图7是根据本发明实施例的分离验证测试装置的主要模块的示意图；

图8是本发明实施例可以应用于其中的示例性系统架构图；

图9是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

以下是本发明实施例中涉及的技术术语的详细解释：

交易，是指对于银行与客户界面合同关系变化的实际有效确认，是双方权利义务关系得以确立的具体实现，其目的在于确立经济事实真实发生，这是产品/交易组件所承载的本质上的功能。

核算，是指按照特定规则对于经济事实(不仅限于银行与客户的合同关系，还包括了其他能够影响银行经济利益的事项)的反映和表达，其目的在于为利益相关者提供有用的信息。

会计引擎，相当于一个独立的应用组件，是指按照统一的、独立的会计核算规则，基于交易信息和计量信息，自动产生会计分录的处理模块，能够满足会计准则和信息披露的要求，也是交易与核算分离主题的关键组件。

会计分录，是指预先确定每笔经济业务所涉及的科目名称，以及计入科目的方向和金额的一种记录，会计分录是由应借应贷方向、对应科目名称及应记金额三要素构成，其中，科目可以包括：库存现金、银行存款、交易性金融资产、应收账款、其他应收款、在途物资、原材料、生产成本、库存商品、长期股权投资、固定资产、累计折扣、固定资产清理、工程物资、短期借款、应付票据、应付账款、其他应付款、应付职工薪酬、应交税费、应付股利、长期借贷、实收资本、管理费用、财务费用、利润分配、所得税费用等。

分录验证测试，是指通过渠道发起交易，在确保渠道客户体验、产品功能正确的前提下，验证分录生成的准确性。

当前交易与会计核算绑定对快速响应市场变化以及加速产品创新产生了制约影响，主要体现在以下几个方面：无法快速响应产品创新、无法适应全球多会计准则、无法满足精细化管理对多层次多维度信息的要求、不能适应财会体制改革后有效控制风险的要求。因此，通过建立独立、统一的会计引擎，实现交易与核算分离的目标，使对客服务组件只专注于交易确认和对客服务，而将会计确认和核算处理交由会计引擎等专门组件完成。相应地，在管理职责的划分上，对于交易过程特别是柜面业务的控制与核算质量控制在职责和手段上也采取相对分离的策略。

交易与核算分离，一方面要实现银行运营、对客服务和交易与核算分离；另一方面要将内部管理和考核与核算相对分离，财务会计组件处在这场变革的核心位置，承前启后，既要保障在分离的架构下，前台业务能顺利地运转，又要从科目体系、核算规则到核算流程上都要进行重大变革，财务会计的每一项变革，都会涉及到与核算相关的所有产品组件和运营组件的变革，其中，产品组件和运营组件都属于应用组件。财务会计组件不仅要做好自身需求的实施，还要配合各应用组件做好核算相关的分析，推进各应用组件的实施落地，才能呈现真正的变革效果。这是一个以核算为切入点，对银行多年沉淀下来的业务处理流程和规则在分离的架构下进行重新梳理、规整的系统工程，会涉及全行业务、系统流程的变化，因此，各组件协同、有效推进和质量把关是项目成败的关键。

在交易与核算分离模式下，在系统中处理完成一笔业务后生成会计分录需要经过如下步骤：业务人员在前端各应用组件发起交易办理业务或系统批处理发起交易，交易成功后应用组件返回前端信息，并通过准实时或定时批量方式发送核算流水；核算流水通过消息或文件方式异步数据传输通道到达会计引擎；会计引擎接收核算流水后对其进行合法性检查。通过合法性检查的流水，再根据流水中的信息与会计引擎配置的核算规则等参数进行匹配生成会计分录，并对无法产生分录的记录出错原因；会计引擎自动进行法人内机构间清算；前端各应用组件在交易成功后自动进行法人内跨组件、跨区域的清算，并在核算流水中体现。其中，跨组件是指交易场景会有组件组合交易，比如贷转存，贷款组件与存款组件各提供半边服务，就是跨组件组合交易。

现有分录验证测试采用业务处理和核算的一体化测试方法，主要包含以下流程：测试人员根据已编制的测试案例通过前端各应用组件的操作界面发起交易请求；作为服务方的产品组件接收交易请求后，执行相应处理，并返回交易响应信息；前端接收到交易响应信息，通过界面显示、凭证、报表等展现给测试人员，测试人员确定业务处理及核算处理是否正确。

但是，在精细化分工、交易与核算分离的大背景下，现有分录验证技术方案具有如下缺点：1)现有技术方案需要测试人员同时验证业务服务的功能以及核算处理的准确性，需要测试人员具备客户体验、业务处理流程、业务服务功能以及会计核算方面的经验，因此现有技术方案对人员要求较高；2)在交易与核算分离的模式下，产品组件往往在完成其业务服务处理后即返回服务反馈信息，其核算流水或准实时地通过消息发送至引擎，或采用批量方式发送至引擎，因此现有技术方案从测试结果生成时间上，无法保证前端服务和会计核算同步验证；3)在交易与核算分离模式下的分录验证主要验证分录规则和核算流水的准确性，在测试阶段上往往是保证在业务处理准确性的前提下进行的，因此现有技术方案无法满足测试需要。

在交易核算分离的新架构下，要进行从交易至会计引擎、至总账的全面核算正确性测试对项目而言是个挑战，特别是应用组件到会计引擎，新建的会计引擎不仅要验证自身功能正确性、还要全面验证核算参数设置是否正确、前端应用组件上送数据是否正确，三位一体才能保障核算分录演绎正确。针对测试研究，本发明实施例提供了一种基于分录与核算分离的分录验证测试方法。图1是根据本发明实施例的分离验证测试方法的主要步骤的示意图，如图1所示，分离验证测试方法的主要步骤可以包括：

步骤S101，确定目标应用组件，按照预设的案例生成规则，生成目标应用组件对应的核算场景案例；

步骤S102，接收分录验证测试请求，按照预设的测试规则执行目标应用组件对应的核算场景案例，获得交易流水信息和会计分录；

步骤S103，根据交易流水信息和会计分录进行验证测试，获得验证测试结果。

其中，目标应用组件是指接入会计引擎的交易组件，比如存款组件、贷款组件等，考虑到可能存在一些应用组件不需要接入会计引擎，因此本发明实施例中首先可以根据项目组账务线需求，确定目标应用组件。

业务人员在前端目标应用组件发起交易办理业务，交易成功后目标应用组件返回前端信息，并通过准实时或定时批量方式将核算流水发送至会计引擎，然后会计引擎生成会计分录。其中，准实时是指在要求的时间内必须到达，否则数据无效，不会对系统造成巨大的损失；会计分录是由应借应贷方向、对应科目名称及应记金额三要素构成。本发明实施例需要对分录进行验证测试，考虑到针对不同的核算流水生成的会计分录是不同的，也就是说不同的应用组件的业务场景和核算场景是不同的，因此在确定目标应用组件之后，需要按照预设的案例生成规则，生成该目标应用组件对应的核算场景案例。核算场景案例是指针对不同核算场景对应的分录测试案例，通过执行核算场景案例A，能够生成核算场景案例A对应的流水信息和对应的会计分录。

本发明实施例的分录验证测试方法中，在测试安排上制定目标清晰、划分统一的测试计划，首先在步骤S101中预先生成目标应用组件对应的核算场景案例，从而在测试准备阶段完成测试案例准备。然后在测试执行阶段，接收到分录验证测试请求之后，可以利用核算场景案例直接通过核算场景对接识别的核算参数，由会计引擎自动加载交易流水驱动会计分录自动生成，无需人工干预，降低了管理成本。

此外，在执行案例过程中，由于案例生成标准为穷举所有核算场景案例，有些应用组件对应的案例数量巨大，不可能全部人工执行与核对，因此可以人工与自动化测试相结合，针对案例较少的应用组件的项目组，人工执行全部核算场景案例，对于案例较多的应用组件的项目组，人工执行案例可以覆盖所有核算条件，自动化测试案例覆盖所有条件的排列组合，这样就可在保证测试效果的同时，大幅提升测试效率。

预设的测试规则可以包括：典型场景测试、全面测试和回归测试。其中，典型场景测试是指利用典型场景对应的典型核算场景案例进行测试；全面测试是指利用目标应用组件对应的所有核算场景案例进行测试；回归测试是指利用目标应用组件对应的经过优化的核算场景案例进行测试。预设的测试规则可以为进行三轮测试，第一轮测试进行典型场景测试，第二轮进行全面测试，第三轮进行回归测试。

还有，执行某核算场景案例，可以获取到执行该核算场景案例得到的交易流水信息和会计分录，然后利用交易流水信息和会计分录进行验证测试，获得验证测试结果，这样就完成了分录验证测试。

值得注意的是，本技术方案在进行分录验证测试的过程中，可以采用端到端验证和日终核对相结合的方式。端到端验证要求结合核算场景制定目标应用组件的核算场景案例，审核案例是否覆盖所有核算场景及核算规则，案例执行时关注于渠道及目标应用组件客户体验及处理准确性，在验证处理准确的基础上，验证会计分录准确性。日终核对可以包括总账与分户账余额核对、以及所有组合交易的账务一致性核对。

本发明实施例的分录验证测试方法中，利用预设的案例生成规则生成目标应用组件对应的核算场景案例，保证核算场景的全覆盖，同时可以完成测试案例准备工作，然后在案例执行阶段可以按照预设的测试规则执行核算场景案例，并利用获得的交易流水信息和会计分录进行验证测试，获得测试结果，从而可以建立有序、高效的交易核算协同验证机制，提高分录验证测试的准确性。

现有交易核算一体化测试方法中，需要业务人员按业务场景逐笔手工录入，再由人工核对匹配该业务场景的核算流水的正确性，对测试人员的资质要求较高。而本申请实施例的分录验证测试方法中，能够利用核算场景案例直接通过核算场景对接识别的核算参数，由会计引擎自动加载交易流水驱动会计分录自动生成，无需人工干预，降低了管理成本，因此，核算场景案例的生成是本发明实施例的分录验证测试方法的重要组成部分。作为本发明的一个可参考实施例，按照预设的案例生成规则，生成目标应用组件对应的核算场景案例，可以包括：

步骤S1011，确定目标应用组件对应的验证场景；

步骤S1012，基于业务功能、产品和核算三要素组合全覆盖的原则，获取验证场景对应的案例目的、验证场景对应的案例范围和验证场景对应的案例验证方法；

步骤S1013，根据案例目的、案例范围和案例验证方法，生成目标应用组件对应的核算场景案例。

针对不同的验证场景，生成不同的验证场景对应的核算场景案例，因此需要获取各验证场景对应的案例目的、案例范围和案例验证方法，然后生成具体的核算场景案例。需要注意的是，生成核算场景案例的原则是要保证业务功能、产品、核算三要素组合全覆盖，核算三要素包括核算类型、原子动作和金额类型，图2是根据本发明实施例的业务功能、产品、核算三要素的映射示意图，也就是生成的核算场景案例需要覆盖业务功能、产品、核算三要素的所有组合。或者说，本发明实施例中，需要在核算场景与业务场景的结合下生成核算场景案例，即生成的核算场景案例需要从产品、合约生命周期、业务场景三个维度覆盖所有核算场景；以及在业务场景需要从正交易、当日冲正交易、隔日调账交易三个维度细分。其中，产品可以包括：活期存储、定期存储、个人贷款、集团贷款等；合约生命周期可以包括：开支、透支、转存、转非应技、核销等；业务场景可以包括：现金、转账、代理批量、扣费等；冲正交易是对一笔正交易的反交易，比如一笔取款，当超时收不到回应时或其他原因交易不正确，需要对原始取款发一个冲正交易，防止交易失败，但又下了客户帐，此外如果一期账单发卡银行错收了客户的资金，或者持卡人在还款交易最后一天已经全部还清但银行却错收了滞纳金和利息的，如果待银行核实之后属实的，银行方也会把这笔多收金额反方向记账，即减去那笔多收金额，这也称之为冲正；隔日调账交易就是T+1日后，对异常账务处理的手工事后调账。

其中，验证场景可以包括以下选项中至少一项：普通核算场景、段值变更场景、分录录入场景、数据同步场景。接下来，结合不同的验证场景进行讨论说明。

一、普通核算场景

案例目的：验证每个业务场景与核算场景的组合下，入账信息是否提供正确，会计引擎生成的明细分录是否正确，入账信息是指应用组件发生至会计引擎的交易流水信息。

案例范围：

1)要求凡接入会计引擎的各应用组件，其对应的测试案例原则上应能满足核算场景全覆盖(从核算规则视角)及产品业务场景全覆盖(从业务场景视角)；

2)对于产品与核算类型映射参数中的每一条记录，根据会计引擎所提供的核算类型+业务事件+金额类型，编写相关案例，即产品/费种到核算类型的映射参数逐条需要有案例验证，其中核算类型可以为产品、内部帐类型、费用类型、实物类型等，业务事件是指在业务场景下具体的操作事件，如在贷款业务中，业务事件可以为发放或者归还，金额类型用于反映某一特定业务含义的余额或发生额；

3)每个核算类型对应的原子动作+金额类型需要全覆盖，原子动作相当于是操作动作，比如存款业务中，原子动作可以为存入；

4)针对一个“核算类型+业务事件+金额类型”组合，应用组件可能有多处逻辑会使用，案例应覆盖所有逻辑；

5)有当日错帐冲正功能的交易均需进行冲正验证，其中冲正是为系统认为可能交易失败时采取的补救手法，如一笔交易在终端已经置为成功标志，但是发送到主机的账务交易包没有得到响应，即终端交易超时，所以不确定该笔交易是否在主机端也成功完成，为了确保用户的利益，终端重新向主机发送请求，请求取消该笔交易的流水，如果主机端已经交易成功，则回滚交易，否则不处理，然后将处理结果返回给终端；

6)支持自贸区业务的案例，需要验证如下场景：同一自贸区内跨系统业务、同一自贸区内不跨系统业务、跨系统跨自贸业务、不跨系统跨自贸业务。

案例验证方法：验证明细分录是否生成，且明细分录中所登记需要应用组件核对的信息是否正确；验证明细分录中的科目是否正确；借贷是否平衡，如机构内平衡、区域内平衡等；在案例描述情况下，核算分录是否正确。

二、段值变更场景，其中段值是财务中的COA(全称为chart of account)段值。

案例目的：验证应用组件在COA段值变更场景下，入账信息是否提供正确。

案例范围：

1)对于每一个核算类型，就其可能发生的COA段值变更场景(机构变更、核算类型变更、责任中心变更、期限变更、客户类型变更、集团往来变更等)，编写相关案例；

2)每一种COA段值变更，可能有多种场景，例如机构变更会有部分机构撤并、账户转移两种场景，核算类型变更可能会对应各个产品条件的变更场景，且有从核算类型A变更为B、变更为C等不同场景，案例应覆盖所有场景；

3)可能会有多个COA段值一并变更，如核算类型与期限一起变更，案例应覆盖所有场景；

案例验证方法：验证明细分录是否生成，且明细分录中所登记需要应用组件核对的信息是否正确；验证明细分录中的科目是否正确；借贷是否平衡(机构内平衡、区域内平衡等)；在案例描述情况下，核算分录是否正确。

三、分录录入场景

案例目的：对于存在分录录入接入会计引擎的应用组件，验证其产生的分录是否可被会计引擎成功接收。

案例范围：按应用组件产生会计分录的功能范围及业务范围，编写相关案例

四、数据同步场景

案例目的：验证应用组件发布产品与核算类型映射表数据同步一致性，以及对会计引擎传输会计日期变更信号的功能。

案例范围：编写一个对数据集成层发布产品与核算类型映射参数的案例；编写一个对会计引擎传输会计日期变更信号的案例。

案例方法：验证产品与核算类型映射参数经数据集成层最终被会计引擎成功装载；验证会计日期变更信号被会计引擎成功处理。

需要注意的是，本发明实施例的分录验证测试方法中，需要保证会计引擎的正常工作，即需要对会计引擎的功能和核算规则配置的正确性进行提前验证，只有在会计引擎可以正常工作，能够保证会计分录的准确生成的前提下，执行的分录验证测试才具有意义。所以，作为本发明的再一个可参考实施例，分录验证测试方法还可以包括：预先编制人工会计分录表，根据核算规则参数生成系统会计分录表；分析人工会计分录表和系统会计分录表之间的差异，获取存在的问题，并对存在的问题进行优化处理。

此外，本发明实施例中在生成核算场景案例之后，需要对生成的核算场景案例进行审核验证，只有在案例审核验证通过之后，才可以将生成的核算场景案例进行投产，因此需要选择合适的测试机构进行审核验证。测试机构范围要能涵盖各类核算场景，从而可以满足案例执行与核对的集中管理要求。为防干扰，需要指定专用测试机构，选用的测试机构须考虑操作的业务种类较为完善，且自身总账初始化账务平衡，具体可以参考如下原则选取：如有试点分行，试点行必须选取；如有转换数据，原则上所挑的机构必须有转换数据，要求新开数据和转换数据都在该机构测试；选择业务品种丰富的机构，保证所有案例都能在这样的机构里实施；考虑到跨自贸区及跨机构场景，选择一级分行；建议挑选两家分行，每个分行至少挑选三家机构；考虑符合组件账务性交易控制的其他要求；考虑对机构特殊性需求，选择如总行级或者分行级的账务中心、金融市场部等集中业务处理的机构。

在分录验证测试方法中，核算场景案例需要由应用组件、会计引擎在交易处理、分录生成、总分核对多道工序中协同验证，避免控制不当使测试执行陷入混乱。且在应用组件功能还不稳定的情况下，避免过多无效案例、应用缺陷，对账务正确性核对的干扰。因此，在生成核算场景案例之后，需要对案件进行审核验证，也就是审核验证生成的核算场景案例是否符合测试要求。所以，作为本发明的还一个可参考实施例，在生成目标应用组件对应的核算场景案例之后，分录验证测试方法还可以包括：利用预设的案例审核标准对核算场景案例进行审核，对不符合预设的案例审核标准的案例进行优化；利用预设的案例验证标准对核算场景案例进行验证，对不符合预设的案例验证标准的案例进行优化。

其中，预设的案例审核标准可以包括以下选项中至少一项：案例需要覆盖所有核算场景、案例需要覆盖产品到核算类型映射、案例需要覆盖冲正的场景、案例需要覆盖跨机构、跨系统的场景、案例需要覆盖自贸区业务、案例需要覆盖段值变更的场景；以及预设的案例验证标准可以包括以下选项中至少一项：验证明细分录符合案例描述的场景、验证明细分录与业务标准分录一致、验证明细分录中自贸区域与业务场景一致、验证明细分录中每个机构表内科目借贷必须相等、验证明细分录中每个自贸区域内表内科目借贷必须相等、验证明细分录跨自贸往来分录结果正确、验证明细分录中的清算分录需要与清算规则一致。

图3是根据本发明实施例的生成核算场景案例的方法的主要流程的示意图。如图3所示，生成核算场景案例的方法的主要流程可以包括：

步骤S301，确定目标应用组件和目标应用组件对应的验证场景；

步骤S302，基于业务功能、产品和核算三要素组合全覆盖的原则，获取验证场景对应的案例目的、验证场景对应的案例范围和验证场景对应的案例验证方法；

步骤S303，根据案例目的、案例范围和案例验证方法，生成目标应用组件对应的核算场景案例；

步骤S304，利用预设的案例审核标准对核算场景案例进行审核，对不符合预设的案例审核标准的案例进行优化；

步骤S305，利用预设的案例验证标准对核算场景案例进行验证，对不符合预设的案例验证标准的案例进行优化。

其中，验证场景可以包括以下场景中至少一种：普通核算场景、段值变更场景、分录录入场景、数据同步场景。还有在步骤S304对核算场景案例进行审核之前，需要对会计引擎的功能和核算规则配置的正确性进行提前验证，具体的，需要预先编制人工会计分录表，根据核算规则参数生成系统会计分录表，分析人工会计分录表和系统会计分录表之间的差异，获取存在的问题，并对存在的问题进行优化处理，因为只有在会计引擎可以正常工作，能够保证会计分录的准确生成的前提下，执行的分录验证测试才具有意义，才可以对生成的核算场景案例进行有限审核验证。

此外，在执行步骤S304之前，还需要选择合适的测试机构进行审核验证。测试机构范围要能涵盖各类核算场景，从而可以满足案例执行与核对的集中管理要求，具体可以参考如下原则选取：如有试点分行，试点行必须选取；如有转换数据，原则上所挑的机构必须有转换数据，要求新开数据和转换数据都在该机构测试；选择业务品种丰富的机构，保证所有案例都能在这样的机构里实施；考虑到跨自贸区及跨机构场景，选择一级分行；建议挑选两家分行，每个分行至少挑选三家机构；考虑符合组件账务性交易控制的其他要求；考虑对机构特殊性需求，选择如总行级或者分行级的账务中心、金融市场部等集中业务处理的机构。

还有，步骤S304中的预设的案例审核标准可以包括以下选项中至少一项：案例需要覆盖所有核算场景、案例需要覆盖产品到核算类型映射、案例需要覆盖冲正的场景、案例需要覆盖跨机构、跨系统的场景、案例需要覆盖自贸区业务、案例需要覆盖段值变更的场景。以及步骤S305中的预设的案例验证标准可以包括以下选项中至少一项：验证明细分录符合案例描述的场景、验证明细分录与业务标准分录一致、验证明细分录中自贸区域与业务场景一致、验证明细分录中每个机构表内科目借贷必须相等、验证明细分录中每个自贸区域内表内科目借贷必须相等、验证明细分录跨自贸往来分录结果正确、验证明细分录中的清算分录需要与清算规则一致。

生成核算场景案例是本发明实施例的重要组成部分，利用生成的核算场景案例进行测试是分录验证测试方法的另一组成部分，具体可以包括：执行核算场景案例、根据案例执行结果进行验证测试。在步骤S102中已经介绍，预设的测试规则包括以下选项中至少一项：典型场景测试、全面测试、回归测试。

本发明实施例中，按照预设的测试规则执行目标应用组件对应的核算场景案例，可以包括：若预设的测试规则为典型场景测试，执行典型场景对应的典型核算场景案例；若预设的测试规则为全面测试，执行目标应用组件对应的所有核算场景案例；若预设的测试规则为回归测试，执行目标应用组件对应的经过优化的核算场景案例。本发明实施例中可以进行三轮测试，第一轮测试进行典型场景测试，执行典型场景对应的典型核算场景案例，若测试通过之后，则可以进行第二轮全面测试，若测试不通过，则需要将问题反馈，对典型核算场景案例进行修正；第二轮进行全面测试，也就是执行目标应用组件对应的所有核算场景案例，若测试不通过，则需要将问题反馈，分析存在问题的案例，进行修正；第三轮进行回归测试，对优化后的核算场景案例进行测试，此处的优化可以是对存在问题的案例进行修正后的案例，也可以是根据业务需求自主优化后的案例。

本发明实施例中，在按照预设的测试规则执行目标应用组件对应的核算场景案例之后，分录验证测试方法还可以包括：执行交易检查。具体的，在执行核算场景案例之后，可以对该案例对应的交易进行检查，检查交易是否成功执行，检查交易对应的核算场景是否完整。基于交易和核算分录的分录验证测试方法中，需要从交易至会计引擎、至总账的全面核算正确性测试。特别是交易组件到核算引擎，新建的独立会计引擎不仅要验证自身功能正确性，还要全面验证核算参数设置是否正确。此步骤的目的是验证应用组件上传的交易流水信息是否正确，只有在保证交易流水正确的前提下，生成的会计分录才具有意义，对会计分录进行的测试才有价值。

在执行核算场景案例至，可以根据案例执行结果进行验证测试，作为本发明的还一个可参考实施例，根据交易流水信息和会计分录进行验证测试，获得验证测试结果，可以包括：对会计分录进行分录验证测试，获得分录验证测试结果；根据交易流水信息和会计分录进行总分验证测试，获得总分验证测试结果。

验证测试的目的是：验证能够通过会计引擎产生正确的分录。从业务场景视角，需要覆盖涉及核算的业务功能、产品，从核算场景视角，需要覆盖核算场景、分录规则相关核算要素；验证应用组件和会计引擎能够协同完成总分核对，确保分户账余额累计和总账更新结果一致，包括总账更新处理检验、以及总分账核对处理检验。应用组件完成交易，并将交易流水信息发送至会计引擎，然后会计引擎生成会计分录，检查会计分录生成正确性，包括借代平衡检查、跨系统往来平衡检查。并且会计引擎汇总分录作为总账当日发生提交至总账，总账入账，更新总账余额，而且应用组件将分户余额发送至总账，最后总账将分户余额映射到科目余额，与实际总账科目余额比对，检查总分核对是否平衡，此外，总分核对可以分机构、分科目、分来源核对。

在验证测试方法上，可以采用端到端验证和日终核对相结合的方式，端到端验证要求制定应用组件对应的核算场景案例，审核案例是否覆盖所有核算场景及核算规则，案例执行时关注渠道及应用组件客户体验及处理准确性，在验证准确的基础上，验证核算准确性。日终核对可以包括测试机构的总账与分户账余额核对、以及所有组合交易的账务一致性核对。

本发明实施例的分录验证测试方法可以将测试流程分为三段：案例执行准入检查、案例执行控制、、案例执行结果检查，能够合理控制测试执行节凑，使上下游联动通畅，有效避免较多应用缺陷对账务正确性核对的干扰，提高测试效率。在执行案例过程中，由于案例设计标准为穷举所有核算条件(核算类型、原子动作、金额类型)的排列组合，有些应用组件对应的案例数量巨大，不可能全部人工执行与核对，因此需要人工与自动化测试相结合，针对核算案例较少的应用序具，人工执行全部核算条件排列组合案例，对于核算案例较多的应用案例，人工执行案例覆盖所有核算条件，自动化测试案例覆盖所有条件的排列组合。这样就可在保证测试效果的同时，大幅提升测试效率。在案例评审标准中，需要核算场景的完整性、核算类型核算条件的覆盖率、人工测试和工具测试方法确定等；在案例验证标准中，需要验证交易成功执行、核算场景完整、明细分录生成、冲正交易正确等；在交易执行检查中，需要验证交易成功执行、核算场景完整等；还需要验证会计分录的正确性；在总分核对验证中，可以分机构、分科目、分来源核对总分。

此外，本发明实施例的分录验证测试方法中，还建立了投产后账务一致性保障机制，确保系统投产后账务处理的正确及连续性，兜底测试。所以，本发明实施例中，在获得验证测试结果之后，分录验证测试方法还可以包括：根据验证测试结果生成差错报告，对差错报告中的差错问题进行排查分析，利用预设的差错调整方法，对差错问题进行处理。

图4是根据本发明实施例的差错报告的示意图，从图4中可以看出，生成的差错报告可以包括：差错报告的作用、对应的差错场景、报告出具方、报告流转方和报告处理方，然后对差错报告中的差错问题进行排查分析。

其中，针对总分不平的排查方法为：各组件从ITSM(即集中运营方)中获取总分差错报告；组件分析报告中发生不平的COA组合、及不平差额；组件分析报告中分户账映射失败、总账入账失败信息(总账提供支持)，如果与总分不平现象吻合则问题已查明；组件分析组件与引擎流水不一致报告、会计分录生成失败报告(引擎提供支持)，如果与总分不平现象吻合则问题已查明；组件提请查询总账当日成功明细(总账提供支持)，与组件分户明细进行比对，定位原因。针对跨系统往来不平的排查方法为：各组件从ITSM中获取跨系统往来不平报告；在跨系统往来不平数据中，通过流水号\套号，可查询到对方组件记账信息，与其沟通双方为何不一致；若第二步无法找到对方，则通过帐号，交易发起渠道，交易线报文日志，获得组合交易相关方，与其沟通双方为何不一致。针对组件与引擎流水不一致的排查方法为：各组件从ITSM中获取流水不一致报告；组件提请会计引擎支持，会计引擎通过自身交易日志确认是数据传输丢失还是其它异常(如报文含乱码)；若为数据传输丢失，则由基础组件定位原因。若为其它异常则由相关组件定位原因。针对会计分录生成失败的排查方法为：各组件从ITSM中获取会计分录生成失败报告，其中内容已足够应用组件定位原因(引擎提供支持)。

对差错报告进行排查分析，获取到差错问题之后，可以利用预设的差错调整方法，对差错问题进行处理。图5和图6是根据本发明实施例的差错调整方法的示意图，在图中，详细介绍了针对具体的差错形态，也就是差错问题，获取对应的调整内容和解决方法。此外，本发明实施例中，还提供了未预测到差错场景的调整措施，具体为各组件准备通用修改合约数据工具和通用生成账务流水工具，以备生产出现现有调账交易/工具不支持的差错场景。

根据本发明实施例的分录验证测试技术方案，利用预设的案例生成规则生成目标应用组件对应的核算场景案例，保证核算场景的全覆盖，同时可以完成测试案例准备工作，然后在案例执行阶段可以按照预设的测试规则执行核算场景案例，并利用获得的交易流水信息和会计分录进行验证测试，获得测试结果，从而可以建立有序、高效的交易核算协同验证机制，提高分录验证测试的准确性。此外，本发明实施例的分录验证测试方法中，还建立了投产后账务一致性保障机制，确保系统投产后账务处理的正确及连续性。

图7是根据本发明实施例的分录验证测试装置的主要模块的示意图。如图7所示，分录验证测试装置700可以包括：生成模块701、执行模块702和测试模块703。

其中，生成模块701可用于：确定目标应用组件，按照预设的案例生成规则，生成目标应用组件对应的核算场景案例；执行模块702可用于：接收分录验证测试请求，按照预设的测试规则执行目标应用组件对应的核算场景案例，获得交易流水信息和会计分录；测试模块703可用于：根据交易流水信息和会计分录进行验证测试，获得验证测试结果。

本发明实施例中，生成模块701还可用于：确定目标应用组件对应的验证场景；基于业务功能、产品和核算三要素组合全覆盖的原则，获取验证场景对应的案例目的、验证场景对应的案例范围和验证场景对应的案例验证方法；根据案例目的、案例范围和案例验证方法，生成目标应用组件对应的核算场景案例。

本发明实施例中，验证场景可以包括以下选项中至少一项：普通核算场景、段值变更场景、分录录入场景、数据同步场景。

本发明实施例中，生成模块701还可用于：利用预设的案例审核标准对核算场景案例进行审核，对不符合预设的案例审核标准的案例进行优化；利用预设的案例验证标准对核算场景案例进行验证，对不符合预设的案例验证标准的案例进行优化。

本发明实施例中，预设的案例审核标准可以包括以下选项中至少一项：案例需要覆盖所有核算场景、案例需要覆盖产品到核算类型映射、案例需要覆盖冲正的场景、案例需要覆盖跨机构、跨系统的场景、案例需要覆盖自贸区业务、案例需要覆盖段值变更的场景；以及

预设的案例验证标准可以包括以下选项中至少一项：验证明细分录符合案例描述的场景、验证明细分录与业务标准分录一致、验证明细分录中自贸区域与业务场景一致、验证明细分录中每个机构表内科目借贷必须相等、验证明细分录中每个自贸区域内表内科目借贷必须相等、验证明细分录跨自贸往来分录结果正确、验证明细分录中的清算分录需要与清算规则一致。

本发明实施例中，分录验证测试装置700还可以包括优化模块(图中未示出)，该优化模块可用于：预先编制人工会计分录表，根据核算规则参数生成系统会计分录表；分析人工会计分录表和系统会计分录表之间的差异，获取存在的问题，并对存在的问题进行优化处理。

本发明实施例中，预设的测试规则可以包括以下选项中至少一项：典型场景测试、全面测试、回归测试；以及

执行模块702还可用于：若预设的测试规则为典型场景测试，执行典型场景对应的典型核算场景案例；若预设的测试规则为全面测试，执行目标应用组件对应的所有核算场景案例；若预设的测试规则为回归测试，执行目标应用组件对应的经过优化的核算场景案例。

本发明实施例中，分离验证测试装700置还可以包括检查模块(图中未示出)，该检查模块可用于：执行交易检查。

本发明实施例中，测试模块703还可用于：对会计分录进行分录验证测试，获得分录验证测试结果；根据交易流水信息和会计分录进行总分验证测试，获得总分验证测试结果。

本发明实施例中，分离验证测试装700置还可以包括差错调整模块(图中未示出)，该差错调整模块可用于：根据验证测试结果生成差错报告，对差错报告进行排查分析，获得差错问题，利用预设的差错调整方法对差错问题进行处理。

从以上描述可以看出，本发明实施例的分录验证测试装置，利用预设的案例生成规则生成目标应用组件对应的核算场景案例，保证核算场景的全覆盖，同时可以完成测试案例准备工作，然后在案例执行阶段可以按照预设的测试规则执行核算场景案例，并利用获得的交易流水信息和会计分录进行验证测试，获得测试结果，从而可以建立有序、高效的交易核算协同验证机制，提高分录验证测试的准确性。此外，本发明实施例的分录验证测试方法中，还建立了投产后账务一致性保障机制，确保系统投产后账务处理的正确及连续性。

图8示出了可以应用本发明实施例的分录验证测试方法或分录验证测试装置的示例性系统架构800。

如图8所示，系统架构800可以包括终端设备801、802、803，网络804和服务器805。网络804用以在终端设备801、802、803和服务器805之间提供通信链路的介质。网络804可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备801、802、803通过网络804与服务器805交互，以接收或发送消息等。终端设备801、802、803上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备801、802、803可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器805可以是提供各种服务的服务器，例如对用户利用终端设备801、802、803所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息--仅为示例)反馈给终端设备。

需要说明的是，本发明实施例所提供的分录验证测试方法一般由服务器805执行，相应地，分录验证测试装置一般设置于服务器805中。

应该理解，图8中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图9，其示出了适于用来实现本发明实施例的终端设备的计算机系统900的结构示意图。图9示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有系统900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括生成模块、执行模块和测试模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，生成模块还可以被描述为“确定目标应用组件，按照预设的案例生成规则，生成目标应用组件对应的核算场景案例地模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：确定目标应用组件，按照预设的案例生成规则，生成目标应用组件对应的核算场景案例；接收分录验证测试请求，按照预设的测试规则执行目标应用组件对应的核算场景案例，获得交易流水信息和会计分录；根据交易流水信息和所述会计分录进行验证测试，获得验证测试结果。

根据本发明实施例的技术方案，利用预设的案例生成规则生成目标应用组件对应的核算场景案例，保证核算场景的全覆盖，同时可以完成测试案例准备工作，然后在案例执行阶段可以按照预设的测试规则执行核算场景案例，并利用获得的交易流水信息和会计分录进行验证测试，获得测试结果，从而可以建立有序、高效的交易核算协同验证机制，提高分录验证测试的准确性。此外，本发明实施例的分录验证测试方法中，还建立了投产后账务一致性保障机制，确保系统投产后账务处理的正确及连续性。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (13)

1.一种分录验证测试方法，其特征在于，包括：

确定目标应用组件，按照预设的案例生成规则，生成所述目标应用组件对应的核算场景案例；

接收分录验证测试请求，按照预设的测试规则执行所述目标应用组件对应的核算场景案例，获得交易流水信息和会计分录；

根据所述交易流水信息和所述会计分录进行验证测试，获得验证测试结果。

2.根据权利要求1所述的方法，其特征在于，所述按照预设的案例生成规则，生成所述目标应用组件对应的核算场景案例，包括：

确定所述目标应用组件对应的验证场景；

基于业务功能、产品和核算三要素组合全覆盖的原则，获取所述验证场景对应的案例目的、所述验证场景对应的案例范围和所述验证场景对应的案例验证方法；

根据所述案例目的、所述案例范围和所述案例验证方法，生成所述目标应用组件对应的核算场景案例。

3.根据权利要求2所述的方法，其特征在于，所述验证场景包括以下选项中至少一项：普通核算场景、段值变更场景、分录录入场景、数据同步场景。

4.根据权利要求1所述的方法，其特征在于，在生成所述目标应用组件对应的核算场景案例之后，所述方法还包括：

利用预设的案例审核标准对所述核算场景案例进行审核，对不符合所述预设的案例审核标准的案例进行优化；

利用预设的案例验证标准对所述核算场景案例进行验证，对不符合所述预设的案例验证标准的案例进行优化。

5.根据权利要求4所述的方法，其特征在于，所述预设的案例审核标准包括以下选项中至少一项：案例需要覆盖所有核算场景、案例需要覆盖产品到核算类型映射、案例需要覆盖冲正的场景、案例需要覆盖跨机构、跨系统的场景、案例需要覆盖自贸区业务、案例需要覆盖段值变更的场景；以及

所述预设的案例验证标准包括以下选项中至少一项：验证明细分录符合案例描述的场景、验证明细分录与业务标准分录一致、验证明细分录中自贸区域与业务场景一致、验证明细分录中每个机构表内科目借贷必须相等、验证明细分录中每个自贸区域内表内科目借贷必须相等、验证明细分录跨自贸往来分录结果正确、验证明细分录中的清算分录需要与清算规则一致。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

预先编制人工会计分录表，根据核算规则参数生成系统会计分录表；

分析所述人工会计分录表和所述系统会计分录表之间的差异，获取存在的问题，并对所述存在的问题进行优化处理。

7.根据权利要求1所述的方法，其特征值在于，所述预设的测试规则包括以下选项中至少一项：典型场景测试、全面测试、回归测试；以及

所述按照预设的测试规则执行所述目标应用组件对应的核算场景案例，包括：

若所述预设的测试规则为典型场景测试，执行典型场景对应的典型核算场景案例；

若所述预设的测试规则为全面测试，执行所述目标应用组件对应的所有核算场景案例；

若所述预设的测试规则为回归测试，执行所述目标应用组件对应的经过优化的核算场景案例。

8.根据权利要求1所述的方法，其特征在于，在按照预设的测试规则执行所述目标应用组件对应的核算场景案例之后，所述方法还包括：执行交易检查。

9.根据权利要求1所述的方法，其特征在于，所述根据所述交易流水信息和所述会计分录进行验证测试，获得验证测试结果，包括：

对所述会计分录进行分录验证测试，获得分录验证测试结果；

根据所述交易流水信息和所述会计分录进行总分验证测试，获得总分验证测试结果。

10.根据权利要求1所述的方法，其特征在于，在获得验证测试结果之后，所述方法还包括：

根据所述验证测试结果生成差错报告，对所述差错报告进行排查分析，获得差错问题，利用预设的差错调整方法对所述差错问题进行处理。

11.一种分录验证测试装置，其特征在于，包括：

生成模块，用于确定目标应用组件，按照预设的案例生成规则，生成所述目标应用组件对应的核算场景案例；

执行模块，用于接收分录验证测试请求，按照预设的测试规则执行所述目标应用组件对应的核算场景案例，获得交易流水信息和会计分录；

测试模块，用于根据所述交易流水信息和所述会计分录进行验证测试，获得验证测试结果。

12.一种电子设备，其特征在于，包括：

一个或多个处理器；

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

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-10中任一所述的方法。

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

Images