接入系统的验收方法及装置与流程

本申请涉及一种接入系统的验收方法，具体而言，涉及一种接入系统的验收方法及装置。

背景技术：

随着经济的不断发展，支付活动的日益频繁，各类金融机构纷纷开展支付业务，越来越多的机构需要与央行的支付系统互联，成为支付系统的参与者，以便完成支付业务。由于支付系统的安全等级要求很高，在参与机构的接入系统正式接入之前，需要判定其已具备安全接入的条件，那么就需要一套严格的检测方法，即针对接入系统进行的接口验收测试。

进行接口验收测试，需要接入系统和被接入系统在网络连通的测试环境里。常规的做法是，参与机构的测试环境运行在自己的测试机房，通过vpn接入支付系统的测试环境，从而保障网络环境的安全。双方系统连通后，依据约定的接口功能进行测试，验证接入系统是否满足预期。支付系统主要通过业务报文与接入系统交互信息，各参与机构的接入系统实现方式虽然千差万别，但其报文接口是确定的。接入系统的验收，可以依据参与机构展开的业务，针对性地进行验收。

在现有技术中验收案例的确定和验收结果的核查主要依靠测试人员手工进行。随着支付业务和信息技术的发展，一方面参与机构的接入需求越来越多，另一方面参与机构接入系统的改造也越来越多，验收工作量快速增长，现有的人工验收的方式已经渐渐无法满足越来越多的验收工作。现有技术的人工验收方式中的验收案例需要根据验收人员的经验确定，即使有的方法中增加评审环节，也很难保障标准统一。其次，现有技术中在验收案例的测试过程中，测试信息的获取渠道主要靠人为沟通，核验方法也不够标准，有的通过业务系统客户端、有的通过应用日志，效率非常低下。

针对现有技术中接入系统验收时出现的验收效率低下、自动化和标准化程度较低的技术问题，目前尚未提出有效的解决方案。

技术实现要素：

本申请的主要目的在于提供一种接入系统方法，以解决现有技术中接入系统验收时出现的验收效率低下、自动化和标准化程度较低的技术问题。

为了实现上述目的，根据本申请的一个方面，提供了一种接入系统的验收方法，该方法包括：

获取接入系统的待验收业务；

确定出每个所述待验收业务对应的验收案例；

获取将所述接入系统作为验收对象来执行所述验收案例而产生的测试数据；

根据所述测试数据以及所述测试数据对应的验收案例的核验规则，得出所述接入系统的验收结果。

进一步的，所述测试数据包括：测试报文；

所述根据所述测试数据以及所述测试数据对应的验收案例的核验规则，得出所述接入系统的验收结果，包括：

通过验证所述测试报文是否满足对应的验收案例的报文要求，得出所述接入系统的验收结果。

进一步的，所述通过验证所述测试报文是否满足对应的验收案例的报文要求，得出所述接入系统的验收结果，包括：

提取所述测试报文的报文要素；

将所述报文要素代入到对应的验收案例的核验规则模型中；

运行所述核验规则模型，得出所述接入系统的验收结果。

进一步的，所述测试数据包括：测试报文以及测试处理结果；

所述根据所述测试数据以及所述测试数据对应的验收案例的核验规则，得出所述接入系统的验收结果，包括：

通过验证测试数据的测试报文是否满足对应的验收案例的报文要求以及验证测试数据的测试处理结果是否与对应的验收案例的预期结果相对应，得出所述接入系统的验收结果。

为了实现上述目的，根据本申请的另一方面，还提供了另一种接入系统的验收装置，该装置包括：

待验收业务获取单元，用于获取接入系统的待验收业务；

验收案例确定单元，用于确定出每个所述待验收业务对应的验收案例；

测试数据获取单元，用于获取将所述接入系统作为验收对象来执行所述验收案例而产生的测试数据；

核验单元，用于根据所述测试数据以及所述测试数据对应的验收案例的核验规则，得出所述接入系统的验收结果。

进一步的，所述测试数据获取单元，还用于获取将所述接入系统作为验收对象来执行所述验收案例而产生的测试报文；

所述核验单元，还用于通过验证所述测试报文是否与对应的验收案例的预期结果相对应，得出所述接入系统的验收结果。

进一步的，所述核验单元包括：

报文要素提取模块，用于提取所述测试报文的报文要素；

核验规则模型代入模块，用于将所述报文要素代入到对应的验收案例的核验规则模型中；

核验规则模型运行模块，用于运行所述核验规则模型，得出所述接入系统的验收结果。

进一步的，所述测试数据获取单元，还用于获取将所述接入系统作为验收对象来执行所述验收案例而产生的测试报文和测试处理结果；

所述核验单元，还用于通过验证测试数据的测试报文是否满足对应的验收案例的报文要求以及验证测试数据的测试处理结果是否与对应的验收案例的预期结果相对应，得出所述接入系统的验收结果。

为了实现上述目的，根据本申请的另一方面，还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述接入系统的验收方法中的步骤。

为了实现上述目的，根据本申请的另一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序在计算机处理器中执行时实现上述接入系统的验收方法中的步骤。

本申请的有益效果为：在本申请实施例中，事先根据以往的验收经验，为每种业务确定好对应的验收案例，以及确定出每个验收案例的核验规则。在验收时，在确定出参与机构的接入系统需要验收的业务之后，自动为每个需要验收的业务匹配出对应的验收案例，进而接入系统依次执行验收案例，通过将执行验收案例的执行结果与每个验收案例的核验规则进行对比，得出接入系统的验收结果。在本申请实施例中，在整个验收过程中，验收案例的确认、案例执行结果的获取、案例执行结果的核验以及验收结果的生成，全部自动化完成，大大的提高了验收效率。解决了现有技术依靠人工进行验收时出现的验收效率低下、自动化和标准化程度较低的技术问题。

附图说明

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

图1是本申请第一实施例接入系统的验收方法的流程图；

图2是本申请实施例接入系统的验收方法的应用场景图；

图3是本申请第二实施例接入系统的验收方法的流程图；

图4是本申请实施例通过核验规则模型对接入系统进行验收的流程图；

图5是本申请第三实施例接入系统的验收方法的流程图；

图6是本申请第四实施例接入系统的验收方法的流程图；

图7是本申请第一实施例确定待验收业务的方法的流程图；

图8是本申请第二实施例确定待验收业务的方法的流程图；

图9是本申请实施例接入系统的验收装置的结构框图；

图10是本申请实施例核验单元的结构框图；

图11是本申请实施例测试数据获取单元的结构框图；

图12是本申请实施例待验收业务获取单元的结构框图；

图13是本申请实施例待验收业务确定模块的结构框图；

图14是本申请实施例不同机构类型的必须验收业务和可选验收业务表；

图15是本申请实施例验收案例的测试内容与预期结果示例表。

具体实施方式

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

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本申请提供了一种针对接入系统的接口验收方法，该接入系统可以为各类金融参与机构，在参与机构想要开展支付业务时，需要与支付系统互联，成为支付系统的参与者，以便完成支付业务。由于支付系统的安全等级很高，在参与机构的接入系统正式接入之前，需要一套严格的检测方法，判定其已具备安全接入的条件，这就是针对接入系统进行的接口验收测试。

图2是本申请一可选实施例的接入系统的验收方法的应用场景图，该应用场景中包括：接入系统和验收系统。如图2所示的场景中，接入系统通过vpn接入验收系统的测试环境中，以保障网络环境的安全。在本场景中，接入系统与验收系统通过报文接口进行信息交互，以进行验收。如图2所示，验收系统还包括数据库，验收系统的数据库用于储存每个接入系统和验收系统之间所有来往的交互报文以及处理结果，以便后续跟进测试数据分析出接入系统的验收结果。如图2所示的场景图中还包括验收管理系统，验收管理系统中存储有多种验收案例以及每个验收案例的核验规则，以通过验收案例对接入系统进行验收。验收管理系统还用于接收并储存接入系统和验收系统在执行验收案例时产生的测试记录(包含报文的测试日志)，以便后续跟进测试记录分析出接入系统的验收结果。

如图2所示的应用场景图的接入系统的验收流程具体可以为：1、验收管理系统根据接入系统的待验收业务确定出接入系统的验收案例集，并将验收案例集发送给测试人员；2、测试人员根据验收案例集依次执行验收案例；3、接入系统作为案例执行者逐条执行验收案例，并记录下执行每个验收案例产生的测试记录，验收系统记录下接入系统在执行验收案例时与验收系统之间的交互报文以及处理结果，并储存在自身数据库中；4、测试人员将接入系统执行验收案例记录下的测试记录发送给验收管理系统，以使验收管理系统开始验收操作；5、验收管理系统根据测试记录从验收系统的数据库中获取对应的交互报文以及处理结果，以对验收案例进行核验；6、在验收管理系统完成对验收案例集中的每个验收案例的核验之后，生成核验结果并将核验结果发送给测试人员。

图1为本申请第一实施例接入系统的验收方法的流程图，如图1所示，本实施例的方法包括步骤s101至步骤s104。

步骤s101，获取接入系统的待验收业务。在本申请中，在对接入系统进行验收时，需要先确定出接入系统的所有需要验收的业务，即接入系统的待验收业务。在本实施例中，该待验收业务可以为参与机构自己选择的需要验收的业务，此外验收系统方也会根据该参与机构的机构类型来确定出该接入系统必须验收通过的业务，例如对应政策性银行来说则必须验收汇款业务等。

步骤s102，确定出每个所述待验收业务对应的验收案例。在本申请实施例中，事先根据以往的验收经验为每种验收业务都准备好对应的一或多个验收案例，且为每个验收案例都制定好对应的验收规则，这些验收案例和每个案例对应的验收规则事先储存在验收管理系统中，由验收管理系统为每个待验收业务确定出验收案例。在本申请实施例中，验收案例主要是针对业务执行时产生的业务报文来制作的，不同的业务执行产生的业务报文也不相同，因此建立业务报文与验收案例的对应关系是可行的。在本申请的可选实施例中，在确定出每个所述待验收业务对应的验收案例后，还会生成针对该接入系统所有待验收业务的验收案例集，在后续的验收案例执行和核验时，只有验收案例集中的所有验收案例都通过核验时，该接入系统才算验收通过。

在本申请的可选实施例中，该验收案例中可以包括：案例执行步骤、发起报文、接收报文、验收点和预期结果等。例如支付类往账业务的验收案例，案例的执行流程为：接入系统发送报文t1给验收系统，验收系统受理该往账报文t1并记录处理结果，进而反馈处理结果t2给接入系统，最后接入系统收到t2。对于该验收案例来说，验收点可以为：接入系统能发送正确的t1到验收系统，以及接入系统能否收到正确的t2。

在本申请实施例中，在为每种验收业务建立对应的验收案例时，还要做好颗粒度控制，要做到每个验收业务的每个可选择颗粒度都要有与验收案例建立起对应关系。具体来说，因为有些业务的业务报文接入系统只可能接收(如下行的系统通知类报文)，而有的报文接入系统既可以发起也可以接收(如常规的业务往来报文)，同一业务的业务报文在发起和接收时需进行不同的检验，需要区分。例如对于转账业务来说，接入系统可以是转账业务的发起方，即业务报文的发起方，也可以是转账业务的接收方，即业务报文的接收方，因此对于转账业务来说，需要从发起维度和接收维度分别进行验收。本申请实施例在为每种业务建立对应的验收案例时，每个业务都要细化到业务报文，并区分了发起维度和接收维度，这种设计，为验收案例的选择提供了必要的前提。

在本申请的实施例中，若接入系统的某个业务需要在发起和接收两个维度都进行验收时，则会为该业务在发起和接收维度各确定出至少一个验收实例；当某个业务仅需要在发起维度或接收维度进行验收时，则只需为该维度确定出至少一个验收实例即可。

在本申请实施例中，在将验收案例按照与各业务完全对应的颗粒度细分后，每一项业务都可清晰地对应到一个或多个验收案例。因此，一旦确定出接入系统的待验收业务，验收系统可以自动为每项待验收业务匹配出对应的验收案例。

步骤s103，获取将所述接入系统作为验收对象来执行所述验收案例而产生的测试数据。在本申请实施例中，在确定出每个待验收业务对应的验收案例之后，进入案例执行环节。接入系统作为案例执行者逐条执行验收案例，并记录下执行每个验收案例产生的测试数据。在本申请实施例中，该测试数据可以包括：接入系统执行验收案例时产生的测试记录(测试日志)、以及验收系统记录的接入系统执行测试案例时产生的交互报文及处理结果。

例如支付类往账业务的验收案例，案例的执行流程为：接入系统发送报文t1给验收系统，验收系统受理该往账报文t1并记录处理结果，并反馈处理结果t2给接入系统，最后接入系统收到t2。在本验收案例执行时，可以将往账报文t1、回应报文t2及其受理结果进行记录，并保存在验收系统的数据库中。接入系统将接收t1和回应t2的日志(含报文信息)作为测试记录反馈到验收管理系统中。便于进一步根据这些测试数据来核验接入系统是否能正确的执行该验收案例。

步骤s104，根据所述测试数据以及所述测试数据对应的验收案例的核验规则，得出所述接入系统的验收结果。在本步骤中，在得到接入系统执行验收案例产生的测试数据之后，根据该测试数据以及该测试数据对应的验收案例的验收规则，可以核验出接入系统是否能正确的执行该验收案例，即核验出接入系统是否能正确的执行该验收案例对应的业务。

在本申请实施例中，在依次对接入系统的验收案例集中的所有验收案例进行核验之后，就可以得出该接入系统的验收结果，只有验收案例集中的所有验收案例都通过核验时，该接入系统才算验收通过。

从以上的描述中，可以看出，在本申请实施例中，事先根据验收经验，为每种验收业务确定好对应的验收案例，以及确定出每个验收案例的核验规则。在验收时，在确定出参与机构的接入系统需要验收的业务之后，自动为每个需要验收业务匹配出对应的验收案例，进而接入系统依次执行验收案例，通过将执行验收案例的执行结果与每个验收案例的核验规则进行对比，得出接入系统的验收结果。在本申请实施例中，在整个验收过程中，验收案例的确认、案例执行结果的获取、案例执行结果的核验以及验收结果的生成，全部自动化完成，大大的提高了验收效率。解决了现有技术依靠人工进行验收时出现的验收效率低下、自动化和标准化程度较低的技术问题。

图3是本申请第二实施例接入系统的验收方法的流程图，如图3所示，本实施例的方法包括步骤s201至步骤s204。

步骤s201，获取接入系统的待验收业务。在本申请中，在对接入系统进行验收时，需要先确定出接入系统的所有需要验收的业务，即接入系统的待验收业务。在本实施例中，该待验收业务可以为参与机构自己选择的需要验收的业务，此外验收系统方也会根据该参与机构的机构类型来确定出该接入系统必须验收通过的业务，例如对应政策性银行来说则必须验收汇款业务等。

步骤s202，确定出每个所述待验收业务对应的验收案例。在本申请实施例中，事先根据以往的验收经验为每种验收业务都准备好对应的多个验收案例，且为每个验收案例都制定好对应的验收规则，这些验收案例和每个案例对应的验收规则事先储存在验收管理系统中，由验收管理系统为每个待验收业务确定出验收案例。在本申请的可选实施例中，该验收案例中可以包括：案例执行步骤、发起报文、接收报文、验收点和预期结果。

在本申请的可选实施例中，在确定出每个所述待验收业务对应的验收案例后，还会生成该接入系统的验收案例集。在本申请实施例中，在为每种验收业务建立对应的验收案例时，还要同时考虑到业务的发起维度和接收维度，要做到业务在发起维度和接收维度都要有对应的验收案例，这种设计，为验收案例的选择提供了必要的前提。在本申请的实施例中，若接入系统的某个业务需要在发起和接收两个维度都进行验收时，则会为该业务在发起和接收维度各确定出至少一个验收实例；当某个业务仅需要在发起维度或接收维度进行验收时，则只需为该维度确定出至少一个验收实例即可。

步骤s203，获取将所述接入系统作为验收对象来执行所述验收案例而产生的测试报文。在本步骤中，在确定出每个待验收业务在发起维度以及接收维度对应的验收案例之后，进入案例执行环节。接入系统作为案例执行者逐条执行验收案例，验收系统记录下接入系统执行每个验收案例产生的测试报文。在本申请实施例中，该测试报文指的是，接入系统在执行验收案例时与验收系统之间的交互报文，该交互报文储存在验收系统的数据库中。

例如支付类往账业务的验收案例，案例的执行流程为：接入系统发送报文t1给验收系统，验收系统受理该往账报文t1并记录处理结果，进而反馈处理结果t2给接入系统，最后接入系统收到t2。在本验收案例执行时，验收系统可以将往账报文t1、回应报文t2及其受理结果进行记录，保存在自身的数据库中。便于进一步根据这些交互报文来核验接入系统是否能正确的执行该验收案例。

步骤s204，通过验证所述测试报文是否满足对应的验收案例的报文要求，得出所述接入系统的验收结果。在本步骤中，在得到接入系统执行验收案例产生的交互报文之后，根据该交互报文以及验收案例的报文要求，可以核验出接入系统是否能正确的执行该验收案例，即核验出接入系统是否能正确的执行该验收案例对应的业务。

在本申请的实施例中，通过验证报文的方式来核验接入系统是否能正确的执行该验收案例，具体可以为将测试数据中的每条报文与在验收案例中对应的报文进行对比，通过核查报文的正确性来核验接入系统是否能正确的执行该验收案例。例如上述步骤s203中的支付类来账业务的验收案例，可以将往账报文t1和回应报文t2与该验收案例中要求的报文进行对比，通过验证报文是否正确，来核验接入系统是否能正确处理该验收案例。

在本申请实施例中，每个验收案例中还包括有该验收案例对报文的格式要求，在执行验收案例时，接入系统需要按照案例要求的报文格式来返回报文，否则验收系统则无法识别或者记录处理结果为错误，只有接入系统返回的报文符合要求的格式时，验收系统才会将该报文进行保存或记录为正确。

在本申请实施例中，在依次对接入系统的验收案例集中的所有验收案例进行核验之后，就可以得出该接入系统的验收结果，只有验收案例集中的所有验收案例都通过核验时，该接入系统才算验收通过。

从以上的描述中，可以看出，在本申请实施例中，在验收时，在确定出参与机构的接入系统需要验收的业务之后，自动为每个需要验收业务匹配出对应的验收案例，进而接入系统依次执行验收案例，通过将执行验收案例的测试报文与每个验收案例的报文要求进行对比，得出接入系统的验收结果。在本申请实施例中，在整个验收过程中，验收案例的确认、案例执行结果的获取、案例执行结果的核验以及验收结果的生成，全部自动化完成，大大的提高了验收效率。解决了现有技术依靠人工进行验收时出现的验收效率低下、自动化和标准化程度较低的技术问题。

如图4所示，在本申请的实施例中，上述步骤s204，通过验证所述测试报文是否满足对应的验收案例的报文要求，得出所述接入系统的验收结果，具体可以包括步骤s301至步骤s303。

步骤s301，提取所述测试报文的报文要素。在本申请的实施例中，还为每个验收案例设置了对应的核验规则模型，通过将接入系统执行验收案例产生的测试报文的报文要素代入对应的核验规则模型进行运行，即可完成对该验收案例的核验。在本申请的实施例中，报文要素可以包括：报文发起行号、报文标识号和日期等。在本申请实施例中，储存在验收系统中的每笔交互报文都对应有特定发起行号、报文标识号和日期等要素，在确定出这些报文要素之后，就可以在验收系统的数据库中确定出唯一的一笔业务处理记录(包含测试报文以及处理结果码)，为后续核查案例提供依据。

步骤s302，将所述报文要素代入到对应的验收案例的核验规则模型中。在本申请的实施例中，该核验规则模型可以为sql语句模板，该sql语句模板包括预设变量，变量可根据测试记录中的内容替换到sql语句模板中。该sql语句模板是根据对应的验收案例的核验规则设置而成，因此通过sql语句模板就可以验证执行验收案例产生的测试数据是否满足该验收案例的核验规则。sql语句模板具体可以实现核验交互报文是否满足验收案例的报文要求，以及处理结果是否与验收案例的预期结果相对应。

在本申请的实施例中，测试报文与验收案例的报文要求的匹配是通过sql语句完成的，因为sql语句模板与验收案例是一一对应的，sql语句模板中已经将验收案例的核验规则作为固定条件，只是将报文要素作为变量，等待测试报文中提取信息后替换。在本步骤中，将测试报文的报文要素代入对应的验收案例的sql语句模板中，替换sql语句模板的变量，生成可执行的完整sql语句，该sql语句可以直接从验收系统的数据库中获取需要的核验数据(包括交互报文以及处理结果码)，通过执行该sql语句可以实现自动对该验收案例进行核验。

步骤s303，运行所述核验规则模型，得出所述接入系统的验收结果。在本申请的实施例中，通过执行验收案例对应的sql语句，可以直接得出该验收案例是否正确的执行。例如上述步骤s203中的支付类往账业务的验收案例，可以将接入系统发出的t1报文和接收的t2报文中的要素提取出来，代入到对应的sql语句模板中，根据要素代入得到可执行的sql语句，执行sql语句对验收系统中存储的t1报文和t2报文的信息进行验证，即可判断出该测试报文是否符合验收案例的报文要求。

在本申请的实施例中，在通过sql语句对接入系统的验收案例集中的所有验收案例进行核验之后，得出该接入系统的验收结果。

图5是本申请第三实施例接入系统的验收方法的流程图，如图5所示，本实施例的方法包括步骤s401至步骤s404。

步骤s401，获取接入系统的待验收业务。在本申请的实施例中，本步骤可以采用与上述步骤s101相同的方法来获取接入系统的待验收业务。

步骤s402，确定出每个所述待验收业务对应的验收案例。在本申请的实施例中，本步骤可以采用与上述步骤s102相同的方法来确定出每个所述待验收业务对应的验收案例。

步骤s403，获取将所述接入系统作为验收对象来执行所述验收案例而产生的测试报文以及测试处理结果。在本申请实施例中，在确定出每个待验收业务对应的验收案例之后，进入案例执行环节。接入系统作为案例执行者逐条执行验收案例，验收系统记录下接入系统执行每个验收案例产生的测试报文以及测试处理结果。在本申请实施例中，该测试报文指的是，接入系统在执行验收案例时与验收系统之间的交互报文，该交互报文储存在验收系统的数据库中。在本申请实施例中，该测试处理结果为验收系统根据验收案例的要求对接入系统发送的报文进行全面检查后，在报文上标记的处理结果。在本申请的实施例中，该测试处理结果可以为标记在测试报文上的处理结果码。

例如支付类往账业务的验收案例，案例的执行流程为：接入系统发送报文t1给验收系统，验收系统受理该往账报文t1并记录处理结果，反馈处理结果t2给接入系统，接入系统收到t2。在本实施例中，在执行验收案例时，当验收系统受理t1和发送t2时，会记录t1的报文内容和处理结果以及t2的报文内容，并保存在验收系统的数据库中。便于进一步根据接入系统反馈的测试报文和测设处理结果来核验接入系统是否能正确的执行该验收案例。

在本申请的实施例中，每个验收案例都对应有一个预期的案例执行结果。图15是本申请实施例验收案例的测试内容与预期结果示例表，如图15所示，每个验收案例都对应一个预期结果，例如发起普通汇兑业务，其预期的结果为接入系统能正确的处理发起普通汇兑报文报文，并能正确处理验收系统发回的汇兑业务清算回执报文。在执行该验收案例时，接入系统在发送普通汇兑报文时，对报文进行记录，在验收系统受理该报文时，会记录报文的信息和处理结果，进而根据该处理结果码来验证案例执行结果是否与验收案例的预期结果相匹配。

在本申请实施例中，每个验收案例中还包括有该验收案例对报文的格式要求，在执行验收案例时，接入系统需要按照要求的案例要求报文格式来返回报文，否则验收系统则无法识别或者记录结果错误，只有接入系统返回的报文符合要求的格式时，验收系统才会将该报文进行保存或记录为正确。

步骤s404，通过验证测试数据的测试报文是否满足对应的验收案例的报文要求以及验证测试数据的测试处理结果是否与对应的验收案例的预期结果相对应，得出所述接入系统的验收结果。在本步骤中，在得到执行验收案例产生的测试报文以及测试处理结果之后，将测试报文与验收案例要求的报文进行对比，判断测试报文是否符合验收案例的要求，此外还将测试处理结果与验收案例的预期结果进行对比，以此可以核验出接入系统是否能正确的执行该验收案例，即核验出接入系统是否能正确的执行该验收案例对应的业务。

在本申请的实施例中，验收案例的核验规则中既包括了验收案例对报文的要求(如报文类型)，又包括了对报文处理结果的要求(如清算成功)，例如上述步骤s403中的支付类往账业务的验收案例，该规则对应的报文要求可以是t1必须为100业务报文的1001业务类型、t2必须与t1匹配，进而判断出该测试报文是否符合验收案例的报文要求。同理，也需要验证t1、t2的处理结果码，来验证验收案例的执行结果是否与验收案例的预期结果相匹配，以此来核验接入系统是否能正确处理该验收案例。

在本申请的实施例中，本步骤的核验过程也可以通过上述步骤s301至步骤s303的sql语句来实现。通过执行验收案例对应的sql语句，可以直接得出该验收案例是否正确的执行。例如上述步骤s403中的支付类往账业务的验收案例，可以将接入系统发出的t1报文和接收的t2报文中的要素提取出来，代入到对应的sql语句模板中，根据要素代入得到可执行的sql语句，执行sql语句对验收系统中存储的t1报文和t2报文的信息进行验证，即可判断出该测试报文是否符合验收案例的报文要求。同理，也会对t1、t2的处理结果码进行核验，来验证案例的执行结果是否与验收案例的预期结果相匹配，以此来核验接入系统是否能正确处理该验收案例。

在本申请实施例中，在依次对接入系统的验收案例集中的所有验收案例进行核验之后，就可以得出该接入系统的验收结果，只有验收案例集中的所有验收案例都通过核验时，该接入系统才算验收通过。

从以上的描述中，可以看出，在本申请实施例中，在验收时，在确定出参与机构的接入系统需要验收的业务之后，自动为每个需要验收业务匹配出对应的验收案例，进而接入系统依次执行验收案例，通过验证测试报文是否满足对应的验收案例的报文要求以及测试处理结果是否与对应的验收案例的预期结果相对应，得出所述接入系统的验收结果。在本申请实施例中，在整个验收过程中，验收案例的确认、案例执行结果的获取、案例执行结果的核验以及验收结果的生成，全部自动化完成，大大的提高了验收效率。解决了现有技术依靠人工进行验收时出现的验收效率低下、自动化和标准化程度较低的技术问题。

图6是本申请第四实施例接入系统的验收方法的流程图，如图6所示，本实施例的方法包括步骤s501至步骤s505。

步骤s501，获取接入系统的待验收业务。在本申请的实施例中，本步骤可以采用与上述步骤s101相同的方法来获取接入系统的待验收业务。

步骤s502，确定出每个所述待验收业务对应的验收案例。在本申请的实施例中，本步骤可以采用与上述步骤s102相同的方法来确定出每个所述待验收业务对应的验收案例。

步骤s503，接收所述接入系统在执行所述验收案例时反馈的测试记录。在本步骤中，在确定出每个待验收业务对应的验收案例之后，进入案例执行环节。验收系统和接入系统作为案例执行者逐条执行验收案例。在执行验收案例时，验收系统会将向接入系统发送的报文、接入系统返回的报文储存在数据库中，便于进一步进行核验。同时在执行验收案例时，接入系统也会生成执行每个验收案例的测试记录，在本申请的可选实施例中该测试记录可以为接入系统的测试日志，该测试记录包含了执行验收案例的主要信息，用于核验人员审查。测试记录内容依据案例确定，由于每个验收案例实际上都包含报文交互，因此测试记录包含交互报文的主要信息，通常包括报文的日期、发起行号、报文标识号或交易序号等要素。根据这些要素，可以在验收系统的数据库中确定出唯一的一笔业务处理记录(包含测试报文以及处理结果码)，为后续核查案例提供依据。

在本申请的实施例中，当验收系统和接入系统作为案例执行者依次执行完所有的验收案例之后，执行每个验收案例的交互报文以及处理结果码均储存在验收系统的数据库中。在执行完所有的验收案例之后，接入系统将执行每个验收案例的测试记录发送给验收管理系统，进而验收管理系统可以根据该测试记录以及在验收系统的数据库中储存的交互报文对每个验收案例进行核验。

步骤s504，从数据库中获取所述测试记录对应的测试数据。在本步骤中，在验收系统和接入系统作为案例执行者依次执行完所有的验收案例之后，接入系统将执行每个验收案例的测试记录发送给验收管理系统，进而验收管理系统根据测试记录中的报文要素，从数据库中找到在执行该验收案例时验收系统与接入系统的交互报文以及处理结果码，进而后续根据交互报文以及处理结果码来对验收案例进行核验。

例如支付类往账业务的验收案例，案例的执行流程为：接入系统发送报文t1给验收系统，验收系统受理该往账报文t1并记录处理结果，反馈处理结果t2给接入系统，接入系统收到t2。在本验收案例执行时，验收系统会将与接入系统的交互报文及处理结果码储存在数据库中，即将往账报文t1和回应报文t2及其处理结果码储存在数据库中。同时，在执行本验收案例时，接入系统也会实时生成本验收案例的测试记录，该测试记录中包括了t1和t2两笔报文的报文要素信息，即这两笔报文的日期、发起行号、报文标识号或交易序号等要素。进而在执行完验收案例之后，接入系统将每个验收案例的测试记录发送给我验收管理系统。进而验收管理系统可以根据测试记录中的报文要素，从验收系统的数据库中找出对应的测试数据(包含测试报文及处理结果码)。

步骤s505，根据所述测试数据以及所述测试数据对应的验收案例的核验规则，得出所述接入系统的验收结果。在本步骤中，验收管理系统可以根据接入系统在执行验收案例生成的测试记录中的报文要素，从验收系统的数据库中找出对应的交互报文及处理结果码，进而根据交互报文与验收案例的报文要求进行对比，判断交互报文是否符合验收案例的要求。此外，在本步骤中还将该处理结果码与验收案例的预期结果进行对比，以此可以核验出接入系统是否能正确的执行该验收案例，即核验出接入系统是否能正确的执行该验收案例对应的业务。

在本申请实施例中，在验收管理系统依照接入系统的测试数据依次对接入系统的验收案例集中的所有验收案例进行核验之后，就可以得出该接入系统的验收结果，只有验收案例集中的所有验收案例都通过核验时，该接入系统才算验收通过。

从以上的描述中，可以看出，在本申请实施例中，通过将在执行验收案例时产生的交互报文及处理结果码储存在验收系统的数据库中，便于数据的查询和回溯，有助于提高验收的效率和准确性。此外，在本实施例中，接入系统在执行验收案例时生成的测试记录，进而根据测试记录从验收系统的数据库查询出在执行该验收案例时产生的交互报文及处理结果码，进而根据交互报文及处理结果码进行验证，有助于提高验收的准确性，此外也解决了在验收时验收系统方和接入系统方信息不对称的问题。

在本申请的可选实施例中，上述步骤s403至步骤s405还可以通过执行验收案例对应的sql语句来实现对验收案例的核验。具体为，验收管理系统可以从接入系统在执行验收案例生成的测试记录中提取出每个验收案例对应的报文要素，并将该报文要素代入到与验收案例对应的sql语句模板中，生成可执行的sql语句，在执行时，该sql语句可以从验收系统的数据库中获取该报文要素对应的测试数据(包含测试报文及处理结果码)，进而对测试报文和处理结果码进行核验，得出该验收案例的核验结果。在通过sql语句对接入系统的验收案例集中的所有验收案例进行核验之后，得出该接入系统的验收结果。

如图7所示，上述步骤，获取接入系统的待验收业务，具体可以通过步骤s601和步骤s602来实现。

步骤s601，获取所述接入系统对应的机构类型。在本实施例中，在确定接入系统的待验收业务时，验收系统会先对接入系统进行分析，确定出接入系统的参与机构的机构类型，由于对于不同种类的参与机构，其业务可能差别较大，通过确认了参与机构的机构类型，就可以初步判断出该参与机构可能需要验收的业务。

步骤s602，根据所述机构类型确定出所述接入系统的待验收业务。在本实施例中，事先会根据以往的验收经验总结出不同种机构类型的接入系统需要验收的业务，具体为，可以首先依据各接入系统的互联接口规范，对各类参与机构可以开展的支付业务进行分析，以参与机构类型为分类依据，将业务验收规范进行分类。具体地，以某一类型的参与机构为例(如银行业金融机构)，列出其可能展开的业务全集，业务分为发起和接收两种维度，并细化到可被检测的业务报文和业务类型的颗粒度。分别标识出其要求必须验收通过的业务，和允许其根据自身需要选择性验收的业务。

在本申请的可选实施例中，在根据以往的验收经验总结出不同种机构类型的接入系统需要验收的业务时，每种业务都会详细到发起维度和接收维度，即总结出不同种机构类型的接入系统需要验收的业务维度。例如，对于政策性银行来说，现金汇款业务不管是从发起维度还是接收维度都是必须验收通过的业务，而对于政策性银行来说，业务撤销应答业务则只有在接收维度上必须验收通过。

从以上的描述中，可以看出，本申请在确定接入系统的待验收业务时，会先根据接入系统的机构类型，确定出接入系统必须要进行验收的业务或业务维度，并将必须验收的业务或业务维度放入待验收业务中，避免了可能的人为失误造成的业务验收不全面的问题。

如图8所示，上述步骤，获取接入系统的待验收业务，还可以通过步骤s701至步骤s704来实现。

步骤s701，获取所述接入系统对应的机构类型。在本实施例中，在确定接入系统的待验收业务时，验收系统会先对接入系统进行分析，确定出接入系统的参与机构的机构类型，由于对于不同种类的参与机构，其业务可能差别较大，通过确认了参与机构的机构类型，就可以初步判断出该参与机构可能需要验收的业务。

步骤s702，根据所述机构类型确定出所述接入系统的必须验收业务和可选验收业务。在本实施例中，实现根据以往的验收经验并依据各接入系统的互联接口规范，对各类参与机构可以开展的支付业务进行分析，以参与机构类型为分类依据，将业务进行分类。具体地，以某一类型的参与机构为例(如银行业金融机构)，列出其可能展开的业务全集，业务分为发起和接收两种维度，并细化到可被检测的业务报文和业务类型的颗粒度。分别标识出其必须要求验收通过的业务，和允许其根据自身需要选择性验收的业务。进而将必须验收的业务放入待验收业务中，将可选验收业务提供给参与机构，以使参与机构可以根据情况选择需要的验收业务。

在本申请的可选实施例中，在根据以往的验收经验总结出不同种机构类型的接入系统必须验收的业务和可选验收业务时，每种业务都会详细到发起维度和接收维度，即总结出不同种机构类型的接入系统必须验收的业务维度和可选验收的业务维度。例如，对于政策性银行来说，现金汇款业务不管是从发起维度还是接收维度都是必须验收通过的业务，而对于政策性银行来说，通用非签名信息业务不管是从发起维度还是接收维度都是可选验收的业务。

图14是本申请实施例不同机构类型的必须验收业务和可选验收业务表，在表中“√”标识为必须验收业务，“╳”标识为不需要验收业务，“△”标识为可选选验收业务。如图14所示，对于政策性银行来说，现金汇款业务不管是从发起维度还是接收维度都是必须验收通过的业务；对于政策性银行来说，业务撤销申请业务在发起维度上为必须验收业务，而在接收维度上则为不需要验收业务；而对于港中银或澳中银来说，现金汇款业务在发起维度和接收维度上都是可选验收业务。在本申请的实施例中，可以将图14的表格中的可选选验收业务提供给参与机构，供参与机构选择需要验收的业务。

步骤s703，获取用户从所述可选验收业务中选择的自选验收业务。在本实施例中，在根据接入系统的参与机构的机构类型确定出该类型机构的可选验收业务后，将该可选验收业务提供给参与机构，进而参与机构可以根据自身情况选择需要验收的业务。在本申请的可选实施例中，上述可选验收业务也会具体到发起和接收两个维度。

在本申请的可选实施例中，供参与机构选择可选验收业务可以通过线上和线下两种渠道来实现。在线下渠道中，可以依据参与机构的机构类型对其发放相应的业务验收规范模板，例如图14，该模板将参与机构的业务类型全集进行了圈定，将必选的业务类型做了固定选择，只预留了可选的业务，供自由选择。选择完成后，该业务规范可随验收测试申请一同提交。

线上渠道的原理类似，只是通过线上系统实现，流程更为快捷。参与机构在线提交申请的同时，即可根据其类型派发相应的业务规范，供其勾选。勾选的原则同样是只能选择可选验收业务，其它固定。勾选完成后，直接通过线上系统提交。

步骤s704，根据所述必须验收业务以及所述自选验收业务确定出所述接入系统的待验收业务。在本步骤中，当确定出接入系统的必须验收业务以及参与机构选择的可选验收业务之后，接入系统的待验收业务为必须验收业务和选择的可选验收业务之总和。

从以上的描述中，可以看出，本申请实施例在确定接入系统的待验收业务时，会先根据接入系统的机构类型，确定出接入系统必须要进行验收的业务和可选验收业务，并将可选验收业务提供给参与机构，供参与机构选择，最后根据参与机构选择的可选验收业务以及必须验收业务确定出业务验收范围，实现了准确、便捷的确定待验收业务的技术效果。此外，在本申请实施例中，供参与机构选择可选验收业务可以通过线上和线下两种渠道来实现，并可以在参与机构发起验收请求时一并提交，也有助于提高验收效率。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

基于同一发明构思，本申请实施例还提供了一种接入系统的验收装置，可以用于实现上述实施例所描述的接入系统的验收方法，如下面的实施例所述。由于接入系统的验收装置解决问题的原理与接入系统的验收方法相似，因此接入系统的验收装置的实施例可以参见接入系统的验收方法的实施例，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

如图9所示，该装置包括：待验收业务获取单元1、验收案例确定单元2、测试数据获取单元3以及连接单元4。

待验收业务获取单元1，用于获取接入系统的待验收业务。在本申请中，在对接入系统进行验收时，需要先确定出接入系统的所有需要验收的业务，即接入系统的待验收业务。在本申请实施例中，该待验收业务可以为参与机构自己选择的需要验收的业务，此外验收系统方也会根据该参与机构的机构类型来确定出该接入系统必须验收通过的业务，例如对应政策性银行来说则必须验收汇款业务等。

验收案例确定单元2，用于确定出每个所述待验收业务对应的验收案例。在本申请实施例中，事先根据以往的验收经验为每种验收业务都准备好对应的多个验收案例，且为每个验收案例都制定好对应的验收规则，这些验收案例和每个案例对应的验收规则事先储存在验收系统的数据库中。在本申请的可选实施例中，该验收案例中可以包括：案例执行步骤、发起报文、接收报文、验收点和预期结果。

在本申请实施例中，在为每种验收业务建立对应的验收案例时，还要同时考虑到业务的发起维度和接收维度，要做到业务在发起维度和接收维度都要有对应的验收案例，这种设计，为验收案例的选择提供了必要的前提。

测试数据获取单元3，用于获取将所述接入系统作为验收对象来执行所述验收案例而产生的测试数据。在本申请实施例中，在确定出每个待验收业务对应的验收案例之后，进入案例执行环节。验收系统和接入系统作为案例执行者逐条执行验收案例，测试数据获取单元3记录下执行每个验收案例产生的测试数据。在本申请实施例中，该测试数据可以包括：接入系统执行验收案例时产生的测试记录(测试日志)、以及验收系统记录的接入系统执行测试案例时产生的交互报文及处理结果。

核验单元4，用于根据所述测试数据以及所述测试数据对应的验收案例的核验规则，得出所述接入系统的验收结果。在本申请实施例中，在通过测试数据获取单元3得到接入系统执行验收案例产生的测试数据之后，核验单元4根据该测试数据以及该测试数据对应的验收案例的验收规则，可以核验出接入系统是否能正确的执行该验收案例，即核验出接入系统是否能正确的执行该验收案例对应的业务。

如图10所示，上述核验单元4包括：报文要素提取模块401、核验规则模型代入模块402、以及核验规则模型运行模块403。

报文要素提取模块401，用于提取所述测试报文的报文要素。在本申请的实施例中，报文要素可以包括：报文发起行号、报文标识号和日期等。在本申请实施例中，储存在验收系统中的每笔交互报文都对应有特定发起行号、报文标识号和日期等要素，在确定出这些报文要素之后，就可以在验收系统的数据库中确定出唯一的一笔业务处理记录(包含测试报文以及处理结果码)，为后续核查案例提供依据。

核验规则模型代入模块402，用于将所述报文要素代入到对应的验收案例的核验规则模型中。在本申请的实施例中，该核验规则模型可以为sql语句模板，该sql语句模板包括预设变量，变量可根据测试记录中的内容替换到sql语句模板中。该sql语句模板是根据对应的验收案例的核验规则设置而成，因此通过sql语句模板就可以验证执行验收案例产生的测试数据是否满足该验收案例的核验规则。在本申请的实施例中，测试报文与验收案例的报文要求的匹配是通过sql语句完成的，因为sql语句模板与验收案例是一一对应的，sql语句模板中已经将验收案例的核验规则作为固定条件，只是将报文要素作为变量，等待测试报文中提取信息后替换。在本步骤中，将测试报文的报文要素代入对应的验收案例的sql语句模板中，替换sql语句模板的变量，生成可执行的完整sql语句，该sql语句可以直接从验收系统的数据库中获取需要的核验数据(包括交互报文以及处理结果码)，通过执行该sql语句可以实现自动对该验收案例进行核验。

核验规则模型运行模块403，用于运行所述核验规则模型，得出所述接入系统的验收结果。在本申请的实施例中，在通过sql语句对接入系统的验收案例集中的所有验收案例进行核验之后，得出该接入系统的验收结果。

如图11所示，上述测试数据获取单元3包括：测试记录接收模块301和数据库查询模块302。

测试记录接收模块301，用于接收所述接入系统在执行所述验收案例时反馈的测试记录。在本申请实施例中，在执行验收案例时，验收系统会将向接入系统发送的报文、接入系统返回的报文储存在数据库中，便于进一步进行核验。同时在执行验收案例时，接入系统也会生成执行每个验收案例的测试记录，在本申请的可选实施例中该测试记录可以为接入系统的测试日志(包含报文)，该测试记录包含了执行验收案例的主要信息，用于核验人员审查。测试记录内容依据案例确定，由于每个验收案例实际上都包含报文交互，因此测试记录包含交互报文的主要信息，通常包括报文的日期、发起行号、报文标识号或交易序号等要素。根据这些要素，可以在验收系统的数据库中确定出唯一的一笔报文，为后续核查案例提供依据。

数据库查询模块302，用于从数据库中获取所述测试记录对应的测试数据。在本申请实施例中，在验收系统和接入系统作为案例执行者依次执行完所有的验收案例之后，接入系统将执行每个验收案例的测试记录发送给验收系统，进而数据库查询模块302根据测试记录中的报文要素，从验收系统的数据库中找到在执行该验收案例时验收系统与接入系统的交互报文及处理结果，进而后续根据交互报文及处理结果来对验收案例进行核验。

如图12所示，上述待验收业务获取单元1包括：机构类型获取模块5和待验收业务确定模块6。

机构类型获取模块5，用于获取所述接入系统对应的机构类型。在本申请实施例中，在确定接入系统的待验收业务时，验收系统会先对接入系统进行分析，确定出接入系统的参与机构的机构类型，由于对于不同种类的参与机构，其业务可能差别较大，通过确认了参与机构的机构类型，就可以初步判断出该参与机构可能需要验收的业务。

待验收业务确定模块6，用于根据所述机构类型确定出所述接入系统的待验收业务。在本申请实施例中，事先会根据以往的验收经验总结出不同种机构类型的接入系统需要验收的业务，具体为，可以首先依据各接入系统的互联接口规范，对各类参与机构可以开展的支付业务进行分析，以参与机构类型为分类依据，将业务验收规范进行分类。具体地，以某一类型的参与机构为例(如银行业金融机构)，列出其可能展开的业务全集，业务分为发起和接收两种维度，并细化到可被检测的业务报文和业务类型的颗粒度。分别标识出其要求必须验收通过的业务，和允许其根据自身需要选择性验收的业务。

如图13所示，上述待验收业务确定模块6包括：机构业务确定子模块601、自选业务获取子模块602以及待验收业务确定子模块603。

机构业务确定子模块601，用于根据所述机构类型确定出所述接入系统的必须验收业务和可选验收业务。在本申请实施例中，实现根据以往的验收经验并依据各接入系统的互联接口规范，对各类参与机构可以开展的支付业务进行分析，以参与机构类型为分类依据，将业务进行分类。具体地，以某一类型的参与机构为例(如银行业金融机构)，列出其可能展开的业务全集，业务分为发起和接收两种维度，并细化到可被检测的业务报文和业务类型的颗粒度。分别标识出其必须要求验收通过的业务，和允许其根据自身需要选择性验收的业务。进而将必须验收的业务放入待验收业务中，将可选验收业务提供给参与机构，以使参与机构可以根据情况选择需要的验收业务。

自选业务获取子模块602，用于获取用户从所述可选验收业务中选择的自选验收业务。在本申请实施例中，在根据接入系统的参与机构的机构类型确定出该类型机构的可选验收业务后，将该可选验收业务提供给参与机构，进而参与机构可以根据自身情况选择需要验收的业务。在本申请的可选实施例中，上述可选验收业务也会具体到发起和接收两个维度。

待验收业务确定子模块603，用于根据所述必须验收业务以及所述自选验收业务确定出所述接入系统的待验收业务。在本申请实施例中，当确定出接入系统的必须验收业务以及参与机构选择的可选验收业务之后，接入系统的待验收业务为必须验收业务和选择的可选验收业务之总和。

本申请的另一方面，还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述接入系统的验收方法中的步骤。

本申请的另一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序在计算机处理器中执行时实现上述接入系统的验收方法中的步骤。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。