CN118069517A - 一种业务测试方法和装置 - Google Patents

Abstract

本发明公开了一种业务测试方法和装置，涉及信息安全技术领域。该方法的一具体实施方式包括：识别增量代码中的实体，接收对每个实体打标的标签，对每个标签配置的营业日期；获取测试数据，确定对测试数据打标的标签，将测试数据中营业字段的属性值，设置为相应营业日期；达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标目标标签的目标实体，从目标实体所处表的字段中选择测试字段；对于与目标标签和目标营业日期对应的测试数据，检测是否包括测试字段，每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息。该实施方式通过标签间的强关联关系，对未覆盖测试字段的测试数据进行遗漏提示，提升测试效率，降低成本。

Description

一种业务测试方法和装置

技术领域

本发明涉及信息安全技术领域，尤其涉及一种业务测试方法和装置。

背景技术

一套信贷批量代码中包含多层代码分支，对于某些产品、客户甚至是特定的租户银行而言，每一次的测试验证点可能仅包含其中多个代码分支的排列组合，测试人员往往只希望看到自己的测试案例埋数是否在测试日志验证中绿灯通过，而不是研究开发人员的代码去拉长测试沟通，而开发人员也希望测试人员只需要关注批量线中的某几个批量节点，去验证对应的案例埋数是否能够在批量线中满足。

多重测试日志验证往往会使代码混杂，验证观测点交错不易进行具体的测试验证，依然需要开发全程接入分析案例中的问题，可能是代码缺陷亦或者是案例缺陷。且容易导致测试案例无法覆盖全批量代码分支或业务实体观测未覆盖全等问题。

测试场景为实际业务案例的模拟测试。而代码观测往往是全局观测，因此现有批量处理所得结果是全局代码的执行情况，而非业务人员自己想观测的部分代码的执行情况，由此出现代码混杂问题，业务人员需要手动从测试记录中查询覆盖哪些字段、代码，以及确定未被测试的代码分支。

发明内容

有鉴于此，本发明实施例提供一种业务测试方法和装置，至少能够解决现有技术中代码测试覆盖情况不透明，需要手动从测试执行情况中查询覆盖哪些字段、代码，以及确定未被测试的代码分支的现象。

为实现上述目的，根据本发明实施例的一个方面，提供了一种业务测试方法，包括：

响应于监听到对增量代码的测试操作，识别增量代码中的实体，接收对每个实体打标的标签，以及接收对每个标签配置的营业日期；

获取测试数据，确定对每个测试数据打标的标签，将每个测试数据中营业字段的属性值，设置为相应标签的营业日期；

响应于达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段；

对于与目标标签和目标营业日期对应的每个测试数据，检测是否包括测试字段，以及每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息。

可选地，所述响应于监听到对增量代码的测试操作，包括：响应于监听到位于增量代码位置之前的其他代码测试完毕，触发对增量代码的测试操作；

所述获取测试数据，确定对每个测试数据打标的标签，包括：

获取所述其他代码的测试数据的标识，接收对每个标识打标的标签，将每个测试数据的标识和标签、配置的业务标识存入临时表中；其中，标识由表名、主键生成；

确定增量代码所属业务需求，根据业务需求的业务标识确定相应临时表，从临时表中获取每个测试数据的标识和标签，以根据标识获取测试数据。

可选地，实体包括业务实体和计算实体，所述方法还包括：

确定每个标签对应的实体，获取每个实体的字段，接收对其中一个或多个字段的选择操作，对选择的字段打标相应实体的标签；

所述确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段，包括：

确定打标相应标签的业务实体，根据业务实体与计算实体之间的关联关系，确定业务实体关联的计算实体；

获取计算实体的编号，依据编号确定计算实体所处表，从表中打标目标标签的字段中，选择一个或多个字段作为测试字段。

可选地，所述方法还包括：根据标签和相应营业日期生成日志表，以将打标标签和相应营业日期的测试数据存储至相应日志表中。

可选地，所述方法还包括：

接收对增量代码中代码分支的定义操作，获取每个代码分支的文件路径地址，接收对其中一个或多个文件路径地址打标的标签，将打标的文件路径地址和标签存入临时表中；

响应于达到目标营业日期，从临时表中确定目标标签对应的文件路径地址，根据每个文件路径地址获取代码分支，判断每个代码分支的字段是否包括测试字段，对不符合要求的代码分支弹出提示信息。

为实现上述目的，根据本发明实施例的另一方面，提供了一种业务测试装置，包括：

打标模块，用于响应于监听到对增量代码的测试操作，识别增量代码中的实体，接收对每个实体打标的标签，以及接收对每个标签配置的营业日期；

刷新模块，用于获取测试数据，确定对每个测试数据打标的标签，将每个测试数据中营业字段的属性值，设置为相应标签的营业日期；

选择模块，用于响应于达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段；

覆盖检测模块，用于对于与目标标签和目标营业日期对应的每个测试数据，检测是否包括测试字段，以及每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息。

可选地，所述打标模块，用于：响应于监听到位于增量代码位置之前的其他代码测试完毕，触发对增量代码的测试操作；

所述刷新模块，用于：

获取所述其他代码的测试数据的标识，接收对每个标识打标的标签，将每个测试数据的标识和标签、配置的业务标识存入临时表中；其中，标识由表名、主键生成；

确定增量代码所属业务需求，根据业务需求的业务标识确定相应临时表，从临时表中获取每个测试数据的标识和标签，以根据标识获取测试数据。

可选地，实体包括业务实体和计算实体，所述打标模块，还用于：

确定每个标签对应的实体，获取每个实体的字段，接收对其中一个或多个字段的选择操作，对选择的字段打标相应实体的标签；

所述选择模块，用于：

确定打标相应标签的业务实体，根据业务实体与计算实体之间的关联关系，确定业务实体关联的计算实体；

获取计算实体的编号，依据编号确定计算实体所处表，从表中打标目标标签的字段中，选择一个或多个字段作为测试字段。

可选地，根据标签和相应营业日期生成日志表，以将打标标签和相应营业日期的测试数据存储至相应日志表中。

可选地，所述装置还包括代码分支模块，用于：

接收对增量代码中代码分支的定义操作，获取每个代码分支的文件路径地址，接收对其中一个或多个文件路径地址打标的标签，将打标的文件路径地址和标签存入临时表中；

响应于达到目标营业日期，从临时表中确定目标标签对应的文件路径地址，根据每个文件路径地址获取代码分支，判断每个代码分支的字段是否包括测试字段，对不符合要求的代码分支弹出提示信息。

为实现上述目的，根据本发明实施例的再一方面，提供了一种业务测试电子设备。

本发明实施例的电子设备包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一所述的业务测试方法。

为实现上述目的，根据本发明实施例的再一方面，提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一所述的业务测试方法。

为实现上述目的，根据本发明实施例的又一个方面，提供了一种计算程序产品。本发明实施例的一种计算程序产品，包括计算机程序，所述程序被处理器执行时实现本发明实施例提供的业务测试方法。

根据本发明所述提供的方案，上述发明中的一个实施例具有如下优点或有益效果：构建业务测试标签关系库，通过标签之间的强关联关系，实现代码批量测试过程中，对未覆盖到测试字段的测试数据以及代码分支进行遗漏提示，提升覆盖测试效率，降低人工成本，且可以仅对增量代码进行测试，无需测试全部代码。

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

附图说明

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

图1是根据本发明实施例的一种业务测试方法的主要流程示意图；

图2是根据本发明实施例的一种可选的业务测试方法的流程示意图；

图3是计算构建数据示意图；

图4根据本发明实施例的一具体地业务测试方法的流程示意图；

图5是另一种计算构建数据示意图；

图6是根据本发明实施例的一种业务测试装置的主要模块示意图；

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

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

具体实施方式

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

需要指出的是，在不冲突的情况下，本发明中的实施例以及实施例中的特征可以互相组合。本发明的技术方案中，所涉及的用户个人信息的采集、分析、使用、传输、存储等方面，均符合相关法律法规的规定，被用于合法且合理的用途，不在这些合法使用等方面之外共享、泄露或出售，并且接受监管部门的监督管理。应当对用户个人信息采取必要措施，以防止对此类个人信息数据的非法访问，确保有权访问个人信息数据的人员遵守相关法律法规的规定，确保用户个人信息安全。

一旦不再需要这些用户个人信息数据，应当通过限制甚至禁止数据收集和/或删除数据的方式将风险降至最低。当适用时，包括在某些相关应用程序中，通过对数据去标识来保护用户隐私，例如在适用时通过移除特定标识符(例如，出生日期等)、控制所存储数据的量或特异性(例如，在城市级别而不是在具体地址级别收集位置数据)、控制数据如何被存储、和/或其他方法去标识。

此处对本方案涉及的词语做解释如下：

案例埋数：指在产品设计中，通过在产品中加入一些隐藏的元素，引导用户进行特定的操作，从而达到提升用户体验的目的。案例埋数可以分为两种类型：1)积极案例埋数：指在产品中加入一些积极的元素，引导用户进行积极的操作。2)消极案例埋数：消指在产品中加入一些消极的元素，引导用户进行消极的操作。

多重测试日志验证：指在测试过程中，对多个测试日志进行验证，以确保测试结果的准确性。

此处对现有技术及缺点进行详细描述：

现有技术一：多个代码版本分支，每个分支一套日志业务测试点：1)通过git、svn等版本工具维护测试版本代码；2)每一个代码分支验证测试独立的业务案例；3)分支日志独立部署观测案例通过情况；4)分支日志测案例通过情况。

这种方式存在的缺陷和不足：1)无法全局把控代码分支(非版本分支)的批量逻辑全部验证，只能验证营业日的数据的批量逻辑符合，但营业日的数据往往只能符合数据分布中的大多数，特殊客户、特殊授信品种等业务场景可能会有遗漏测试；2)无法链接测试点与业务实际需求点之间的测试点监控，容易导致测试与开发点对于业务理解观测的不同引发的测试性遗漏；3)不利于快速迭代验证的流水测试部署。

现有技术二：在线热部署的方式，开发人员完全把控需求与测试，通过批量测试在线热部署的方式逐一验证代码分支和业务验证观测点。1)代码在线部署；2)依据即时案例独立在代码切面注入观测点；3)观测单独的测试点通过情况。其中，在线热部署是指在线上环境下，在不影响用户使用的情况下，对应用程序进行更新和部署。

这种方式存在的缺陷和不足：1)不符合开发与测试剥离原则，容易导致理解性测试遗漏；2)无法链接开发点与测试点之间的桥梁，依然处于批处理代码的业务性单元测试；3)无法链接测试点与业务实际需求点之间的测试点监控；4)需要测试人员满足开发人员完全对代码熟悉的级别，且开发人员满足测试案例熟悉级别并无法控制日志版本。

本方案可适用于多种测试代码场景，比如信贷业务场景，主要以信贷业务场景为例进行说明。信贷业务场景中，同一个信贷批量代码包含多个代码分支，对于不同客户、产品而言存有差异化。

测试是为了满足实际业务各种情况的可用性，例如新增的授信品种银行承兑汇票转贴现，对于原先代码已有规模为小企业的客户场景是否适用，原先代码已有的信用风险第一还款人逻辑是否适配。在不同客户、不同授信品种、不同监管需求下，需要对代码分支进行不同排列组合。比如小企业执行小企业的判断逻辑，大中型企业执行大中型企业的判断逻辑。

测试场景为实际业务案例的模拟测试。而代码观测往往是全局观测，因此现有批量处理，所得结果是全局代码的执行情况，而非业务人员自己想观测的部分代码的执行情况，由此出现代码混杂问题，业务人员需要手动从测试记录中查询覆盖哪些字段、代码，以及确定未被测试的代码分支。本方案针对这一问题，仅针对模拟案例进行分析观测，而非对所有场景全局日志进行分析。

另外，实际操作中会出现测试案例覆盖不全的问题，比如信贷测试案例难以覆盖全批量计算代码所考虑的场景，这是因为各租户银行对应不同的业务需求，无法涉及到全部业务场景。例如某银行在贷后检查报告中暂未接入RAD(Rapid ApplicationDevelopment，快速应用程序开发)业务场景，但同套批处理计算代码中存在RAD对应的逻辑，随着监管要求的不断变化，后续该银行可能会在贷后检查与报告中接入RAD(贷后检查与报告是信贷的一个环节)。

参见图1，示出的是本发明实施例提供的一种业务测试方法的主要流程图，包括如下步骤：

S101：响应于监听到对增量代码的测试操作，识别增量代码中的实体，接收对每个实体打标的标签，以及接收对每个标签配置的营业日期；

S102：获取测试数据，确定对每个测试数据打标的标签，将每个测试数据中营业字段的属性值，设置为相应标签的营业日期；

S103：响应于达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段；

S104：对于与目标标签和目标营业日期对应的每个测试数据，检测是否包括测试字段，以及每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息。

上述实施方式中，对于步骤S101，本方案主要针对增量代码情况，比如信贷分为贷前、贷中和贷后三个场景，新增贷后代码，则对新增贷后代码进行处理。贷后代码执行需要在贷前、贷中代码执行完毕的情况下进行，因而对新增贷后代码的测试操作，可以是在监听到贷前代码、贷中代码测试完毕的情况下触发。此处的触发可以是人工触发，也可以是自动触发，优选自动触发。除了上述触发操作外，还可以设置预设时间点，比如每天一个固定时间点，或者并非每天，而是特定一个时间点。

在测试增量代码之前，需要做一系列配置操作，首先人工定义关键字，如customer_number、contract_number，依据关键字识别方式，从增量代码中识别实体，并接收对每个实体打标的标签。不同实体配置的标签可以不同，每个实体也可以配置多个标签，此处不做限制，依据测试人员设置，优选设置一个标签。

虽设置多个标签，比如YD001、YD002、YD003，但可能部分标签对应的实体后续使用不到，因而此处打标之后，还可以根据标签对实体分类，进而通过选择标签的方式确定后续需测试的实体。比如选择了YD001、YD002，则表示YD003对应的实体本次测试并不涉及。根据选择的标签构建标签库，如上述YD001、YD002，构成信贷批量测试标签库。

通常测试均为模拟测试，而模拟测试的时间点通常未到达，为提高测试效率，设置营业日期，以在营业日期进行模拟测试，因而营业日期为模拟测试日期。营业日期多样，如年终、月初等具体某个时间点，还可以是一个时间范围，本方案优选设置为具体某日，如当日为20231223，设置营业日期为20231224。

对于步骤S102，测试均为模拟测试，一般未达到实际时间点，通过营业日期实现在当前日期的模拟测试。但每个标签对应的场景可能不同，因而测试时间点可能也不同，本方案优选针对每个标签配置不同的营业日期，比如YD001配置营业日期为20231224，YD002配置营业日期为20231225。实际也可以将多个标签设置同一营业日期，以此实现对多个标签对应实体同步测试，此处不做限制，具体依据业务需求而定。

获取测试数据，在增量代码为贷后代码的情况下，此处的测试数据需要通过贷前代码和贷中代码获得。此处同样需要对测试数据打标，打标可以是预先配置的。比如预先对测试数据打标，打标的标签需要落入前述选择的标签范围内，如有些测试数据打标YD001，有些则打标YD002。

在确定测试数据的标签后，触发刷新操作，可以是自动触发，也可以是人为手动触发，不做限制。通过刷新操作，将测试数据中营业字段的属性值设置为相应标签的营业日期，如数据X打标YD001，则将其营业字段属性值设置为20231224，数据Y打标YD002，则将其营业字段的属性值设置为20231225。

本方案还可以基于标签和配置的营业日期生成日志表并命名，如标签.营业日期.log，以将打标标签的测试数据分别存入相应日志表中，如打标YD001的数据X存入YD001.20231224.log，打标YD002的数据Y存入YD002.20231225.log。

进一步的，测试数据通常位于不同表的不同位置，位置通过主键区分，因而测试数据的标识为表名+主键，且考虑不同测试数据用于不同的业务场景，由此可以设置业务ID，如信贷业务ID。打标可以仅对测试数据的标识打标，标识对应唯一测试数据，后续可以将标识、业务ID和标签存入临时表中。因而此处获取测试数据，实际是根据增量代码所属业务需求的业务ID确定临时表，从临时表中获取每个测试数据的标识和标签，进而依据标识从相应表中相应位置获取测试数据。

对于步骤S103，通过上述标签，实现以标注的方式约定了业务、测试、开发之间的数据沟通标准。上述YD001、YD002仅为示例，实际可以是其他标识，如0、1、N、Y，此处不做限制。以标签1为例，1-合同编号、1-contract_num、1-合同页面录入时生成的合同编号，分别对应业务、开发、测试对应的观测点。此处的1即为沟通方式，上述合同编号、contract_num、合同业务录入时生成的合同编号即为需求观测点之一。

因而本方案设置的标签是全局标签，后续可以在全局日志中涉及标签1的观测点激活日志。因而本方案可以通过多种激活标签的排列组合方式，组成需要观测的日志节点，如果测试案例没有覆盖到日志节点的所有逻辑，即可发现日志节点实例化后，可能不会有实际对应业务观测点的结果。假设有一个日志节点，它负责将用户的行为日志记录到数据库中。如果测试案例没有覆盖到日志节点的所有逻辑，那么在日志节点实例化后，可能不会有用户行为日志记录到数据库中。

因而在监听达到营业日期，比如20231224时，确定与之对应的标签，如上述YD001，确定打标YD001的实体，从实体所处表的字段中，选择一个或多个字段作为测试字段。实际操作中，在步骤S101对实体打标标签后，可以获取每个实体的字段，测试人员可以从中选择一个或多个字段，对这些字段打标相应实体的标签，如实体打标YD001，则对选择的字段也打标YD001。此处选择测试字段，需要从打标YD001的字段中再筛选。假设原先打标YD001的字段有ABCD，此处可以选择其中的部分，如ABC，也可以全部，具体依据业务需求而定。

对于步骤S104，从与标签和营业日期对应的日志表中，获取测试数据。假设测试字段为ABC，则判断YD001.20231224.log的每个测试数据，其字段是否包含ABC，以筛选出不包含其中一个或多个字段的测试数据，对于包含ABC字段的测试数据，判断ABC每个字段下的属性值是否为空，以此筛选出不符合要求的测试数据。本方案主要应用于后端测试场景，因而此处对于不符合要求的测试数据，可以显示该数据是否需要再处理，以进行删除、人工处理等操作。

上述实施例所提供的方法，构建业务测试标签关系库，通过标签之间的强关联关系，实现代码批量测试过程中，对未覆盖到测试字段的测试数据进行遗漏提示，提升覆盖测试效率，降低人工成本，且可以仅对增量代码进行测试，无需测试全部代码。

参见图2，示出了根据本发明实施例的一种可选的业务测试方法流程示意图，包括如下步骤：

S201：响应于监听到对增量代码的测试操作，识别增量代码中的实体，接收对每个实体打标的标签；

S202：确定每个标签对应的实体，获取每个实体的字段，接收对其中一个或多个字段的选择操作，对选择的字段打标相应实体的标签；

S203：接收对每个标签配置的营业日期；

S204：获取测试数据，确定对每个测试数据打标的标签，将每个测试数据中营业字段的属性值，设置为相应标签的营业日期；

S205：响应于达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标相应标签的业务实体，根据业务实体与计算实体之间的关联关系，确定业务实体关联的计算实体；

S206：获取计算实体的编号，依据编号确定计算实体所处表，从表中打标目标标签的字段中，选择一个或多个字段作为测试字段；

S207：对于与目标标签和目标营业日期对应的每个测试数据，检测是否包括测试字段，以及每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息。

上述实施方式中，对于步骤S201、S203、S204、S207可参见图1所示描述。

对于步骤S202，从增量代码中确定业务实体和计算实体，并接收对每个业务实体和每个计算实体打标的标签。业务实体如合同、授信品种、客户四部委规模，其中，客户四部委规模，是指客户的销售部门、市场部门、财务部门和人力资源部门四个主要部门的规模。客户四部委规模越大，客户的规模和复杂性就越大。

标签分为一般标签和专属标签，以信贷业务场景为例：1)一般标签用于常用的信贷业务，包括常用测试业务实体：授信品种-标签、合同-标签、客户标签；常用计算实体标签：授信品种编号-标签、合同编号-标签、客户编号-标签。2)专属标签，例如监管新规发布，业务实体：第一还款人-标签，计算实体：第一还款人编号-标签。

对于步骤S205和S206，业务实体和计算实体具有关联关系，参见如3所示，计算实体包括实体ID、业务ID、实体描述、模型ID、代码分支ID，业务实体包括实体ID、业务ID、实体描述和模型ID，业务实体和计算实体通过模型ID关联，模型ID唯一。

模型ID通过标准模型配置，因而业务实体通过标准模型与计算实体间接绑定，与测试案例的绑定通过需求选择绑定。标准模型包括模型ID、模型描述和数据项，业务ID通过业务需求而定，业务需求包括需求ID、需求名称和需求描述。

测试案例包括案例ID、案例实体、案例简述、业务ID和业务实体ID，案例ID关联营业日。其中，测试案例是业务表述，代码做一个业务场景，做完后的生成对应的测试数据。

因而在达到营业日期时，根据案例ID确定测试案例，根据测试案例中的业务实体ID确定业务实体。进而依据业务实体和计算实体之间通过标准模型构建的关联关系，确定与该业务实体关联的计算实体。

在确定计算实体后，获取计算实体的编号，依据编号确定计算实体所处表，从表中打标目标标签的字段中，选择一个或多个字段作为测试字段。如从打标YD001的ABCD四个字段中，选择ABC作为测试字段。实际操作中，还可以从表中获取ABC三个字段的属性值，将ABC三个字段以及相应属性值，输出到与YD001对应的日志表中。

上述实施例所提供的方法，在达到营业日时首先确定测试案例，然后根据标签之间的关联关系，确定所需测试的计算实体，以供选择测试字段，提升测试效率。

参见图4，示出了根据本发明实施例的一具体地业务测试方法流程示意图，包括如下步骤：

S401：响应于监听到对增量代码的测试操作，识别增量代码中的实体，接收对每个实体打标的标签，以及接收对每个标签配置的营业日期；

S402：接收对增量代码中代码分支的定义操作，获取每个代码分支的文件路径地址，接收对其中一个或多个文件路径地址打标的标签，将打标的文件路径地址和标签存入临时表中；

S403：获取测试数据，确定对每个测试数据打标的标签，将每个测试数据中营业字段的属性值，设置为相应标签的营业日期；

S404：响应于达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段；

S405：对于与目标标签和目标营业日期对应的每个测试数据，检测是否包括测试字段，以及每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息；

S406：响应于达到目标营业日期，从临时表中确定目标标签对应的文件路径地址，根据每个文件路径地址获取代码分支，判断每个代码分支的字段是否包括测试字段，对不符合要求的代码分支弹出提示信息。

上述实施方式中，对于步骤S401、S403～S405可参见图1所示描述，在此不再赘述。

对于步骤S402，计算实体和代码分支是计算中的基本组件，它们可以用来构建复杂的计算模型。计算实体以具体的方法栈入口参数或者为脚本代码的临时表，这样设计的目的是便于切面观测，如果不是入口参数难以在热部署时进行实时观测。而临时表也符合信贷批量计算节点的常用设计。

代码分支绑定计算实体：每个代码分支以代码切面可观测的方法绑定可观测点，对于以脚本语言实现的信贷批量方式，以观测代码分支涉及的代码分支作为观测实点。

增量代码中的代码分支需要人为定义，定义之后获取每个代码分支的文件路径地址，之后从中选择全部或部分文件路径地址进行打标，比如有些打标YD001，有些则打标YD002。将打标的文件路径地址的标签，存入临时表中。

对于步骤S406，标签绑定为具体测试实例化的过程，也是以测试、业务、开发三个信贷实施参与方维度进行的绑定。通过上述步骤，将测试数据、实体、字段、代码分支进行绑定。

标签观测验证，需要通过具体营业日期跑批得到观测日志结果，观测日志以标签实例化生成观测版本注入静态代码。代码编译实例化跑批进行业务观测。观测以计算实体为入口，以业务实体为验收点。通过验收缺口和入口缺口提示测试缺陷

营业日与测试数据绑定，用于判断哪些测试数据不符合要求。此外，由于标签与代码分支绑定，因而代码分支与营业日期之间也可以绑定，参见图5所示，营业日中的分支ID与代码分支的分支ID相同。具体地，从临时表中确定YD001对应的文件路径地址，根据该地址获取代码分支，判断每个代码分支是否包含ABC三个字段。通过这些步骤，实现对测试数据缺陷、代码分支测试遗漏缺陷的验证。

上述实施例所提供的方法，构建业务测试标签关系库，通过标签之间的强关联关系，实现代码批量测试过程中，对未覆盖到测试字段的测试数据以及代码分支进行遗漏提示，提升覆盖测试效率，降低人工成本，且可以仅对增量代码进行测试，无需测试全部代码。

在图5中，关系的详细描述如下：

1.代码分支-计算实体-标签：这个关系描述了大批量信贷业务处理流计算过程中的阶段和业务观测点之间的关系。每个阶段都有自己的业务观测点，但没有直接与最终批量结果体验相关联。为了解决在信贷批量线应用测试中可能出现的没有执行全部批量流分支的问题，本方案引入了批量分支流标签。

2.代码分支-业务实体-标签：这个关系描述了代码分支与信贷批量计算过程中涉及的业务实体之间的关系。业务实体可以是授信品种、客户、合同、支用、押品等粗粒度的一级实体标签，也可以是更高层次的业务实体标签，比如客户相关的客户评级、客户类型、客户四部委规模等。通过将代码分支与业务实体分支绑定，可以方便地构建测试案例与业务实体的关联关系。

3.测试案例-业务实体-标签：这个关系描述了信贷批量测试案例数据与信贷业务流程中的业务实体之间的关系。信贷批量测试案例数据需要执行某一段信贷业务流程，通常以合同放款为基本出发点。在执行过程中，会产生多层次的业务数据，这些数据对应着某个批量计算或批量计算线，但只有某些数据是有效的，即符合业务需求的测试数据。通过将测试案例与业务实体绑定，可以激活这些案例测试数据，并将其注入到相应的代码分支中。

4.测试案例-营业日-标签：这个关系描述了批量跑批入口的必要参数，即营业日，与测试案例之间的桥梁关系。营业日是批量案例执行的必要参数，它可以用来确定测试案例的执行时间和顺序。

5.业务实体-标准模型-标签：一级业务实体、二级业务实体甚至是更细粒度的业务实体，需要能够在统一的标准模型中，进行实际数据项的注册和绑定操作。通过其他标签到业务实体的关联关系找到标准数据项，并通过标准数据项沟通业务实体与计算实体之间的关系。

6.计算实体-标准模型-标签：计算实体可以是批量计算过程中的临时表，也可以是具体应用代码的方法入口。临时表可以通过代码检核验证SQL代码的方式，验证计算实体中标准数据项是否对应存在。方法入口可以通过切面，观测数据项在切面观测点是否被观测、观测结果比对的方式进行验证。

7.业务实体-业务需求-标签：每一个具体的业务需求所关注或者重点关注的业务实体不同。一般在测试案例评审中，业务计算参与评审测试案例，会关注测试案例中涉及的计算实体与业务实体，是否均在测试案例中有体现。

关联解释：标签的实例化方式可以是以切面的方式注册在工程中，或是通过静态文件的配置方式，注册批量计算中涉及的批量临时表、检核脚本、计算实体等关联关系配置。

通过构建业务测试标签关系库，来实现信贷批量测试案例观测与代码解耦、测试可控式热部署，并通过标签之间的强关联关系，实现未观测计算实体与未观测业务实体检查遗漏提示，来实现测试用例与测试评审的辅助手段。

通过上述ID-标签-标签的形式构建标签与标签之间的关系，使得在进行具体的业务验证时，通过测试案例绑定验证业务实体，进而确定观测的计算实体，摆脱冗余观测点。通过测试案例观测点与实际代码解耦，在代码编译阶段写入日志观测的方式，即可使得可控式热部署得以实现，无需开发人员手动硬编码参与，也无需维护多套用于批量测试的代码分支。

代码分支m维与业务实体n维绑定后，可以实现m*n维度的观测点。而测试案例覆盖的观测点，既可以在绑定时提示，也可以在跑批观测时发现遗漏的观测点。通过遗漏观测点在标签绑定中的关系，可获得遗漏维度提示。

参见图6，示出了本发明实施例提供的一种业务测试装置600的主要模块示意图，包括：

打标模块601，用于响应于监听到对增量代码的测试操作，识别增量代码中的实体，接收对每个实体打标的标签，以及接收对每个标签配置的营业日期；

刷新模块602，用于获取测试数据，确定对每个测试数据打标的标签，将每个测试数据中营业字段的属性值，设置为相应标签的营业日期；

选择模块603，用于响应于达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段；

覆盖检测模块604，用于对于与目标标签和目标营业日期对应的每个测试数据，检测是否包括测试字段，以及每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息。

本发明实施装置中，所述打标模块601，用于：响应于监听到位于增量代码位置之前的其他代码测试完毕，触发对增量代码的测试操作；

所述刷新模块602，用于：

获取所述其他代码的测试数据的标识，接收对每个标识打标的标签，将每个测试数据的标识和标签、配置的业务标识存入临时表中；其中，标识由表名、主键生成；

确定增量代码所属业务需求，根据业务需求的业务标识确定相应临时表，从临时表中获取每个测试数据的标识和标签，以根据标识获取测试数据。

本发明实施装置中，实体包括业务实体和计算实体，所述打标模块601，还用于：

确定每个标签对应的实体，获取每个实体的字段，接收对其中一个或多个字段的选择操作，对选择的字段打标相应实体的标签；

所述选择模块603，用于：

确定打标相应标签的业务实体，根据业务实体与计算实体之间的关联关系，确定业务实体关联的计算实体；

获取计算实体的编号，依据编号确定计算实体所处表，从表中打标目标标签的字段中，选择一个或多个字段作为测试字段。

本发明实施装置中，所述装置还包括：根据标签和相应营业日期生成日志表，以将打标标签和相应营业日期的测试数据存储至相应日志表中。

本发明实施装置中，所述装置还包括代码分支模块，用于：

接收对增量代码中代码分支的定义操作，获取每个代码分支的文件路径地址，接收对其中一个或多个文件路径地址打标的标签，将打标的文件路径地址和标签存入临时表中；

响应于达到目标营业日期，从临时表中确定目标标签对应的文件路径地址，根据每个文件路径地址获取代码分支，判断每个代码分支的字段是否包括测试字段，对不符合要求的代码分支弹出提示信息。

另外，在本发明实施例中所述装置的具体实施内容，在上面所述方法中已经详细说明了，故在此重复内容不再说明。

图7示出了可以应用本发明实施例的示例性系统架构700，包括终端设备701、702、703，网络704和服务器705(仅仅是示例)。

终端设备701、702、703可以是具有显示屏并且支持网页浏览的各种电子设备，安装有各种通讯客户端应用，用户可以使用终端设备701、702、703通过网络704与服务器705交互，以接收或发送消息等。

网络704用以在终端设备701、702、703和服务器705之间提供通信链路的介质。网络704可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

服务器705可以是提供各种服务的服务器，需要说明的是，本发明实施例所提供的方法一般由服务器705执行，相应地，装置一般设置于服务器705中。

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

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

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

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

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

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

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

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括打标模块、刷新模块、选择模块、覆盖检测模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，选择模块还可以被描述为“选择测试字段模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备执行上述任一所述的业务测试方法。

本发明的计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现本发明实施例中的业务测试方法。

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

Claims (12)

1.一种业务测试方法，其特征在于，包括：

响应于监听到对增量代码的测试操作，识别增量代码中的实体，接收对每个实体打标的标签，以及接收对每个标签配置的营业日期；

获取测试数据，确定对每个测试数据打标的标签，将每个测试数据中营业字段的属性值，设置为相应标签的营业日期；

响应于达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段；

对于与目标标签和目标营业日期对应的每个测试数据，检测是否包括测试字段，以及每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息。

2.根据权利要求1所述的方法，其特征在于，所述响应于监听到对增量代码的测试操作，包括：响应于监听到位于增量代码位置之前的其他代码测试完毕，触发对增量代码的测试操作；

所述获取测试数据，确定对每个测试数据打标的标签，包括：

获取所述其他代码的测试数据的标识，接收对每个标识打标的标签，将每个测试数据的标识和标签、配置的业务标识存入临时表中；其中，标识由表名、主键生成；

确定增量代码所属业务需求，根据业务需求的业务标识确定相应临时表，从临时表中获取每个测试数据的标识和标签，以根据标识获取测试数据。

3.根据权利要求1所述的方法，其特征在于，实体包括业务实体和计算实体，所述方法还包括：

确定每个标签对应的实体，获取每个实体的字段，接收对其中一个或多个字段的选择操作，对选择的字段打标相应实体的标签；

所述确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段，包括：

确定打标相应标签的业务实体，根据业务实体与计算实体之间的关联关系，确定业务实体关联的计算实体；

获取计算实体的编号，依据编号确定计算实体所处表，从表中打标目标标签的字段中，选择一个或多个字段作为测试字段。

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

根据标签和相应营业日期生成日志表，以将打标标签和相应营业日期的测试数据存储至相应日志表中。

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

接收对增量代码中代码分支的定义操作，获取每个代码分支的文件路径地址，接收对其中一个或多个文件路径地址打标的标签，将打标的文件路径地址和标签存入临时表中；

响应于达到目标营业日期，从临时表中确定目标标签对应的文件路径地址，根据每个文件路径地址获取代码分支，判断每个代码分支的字段是否包括测试字段，对不符合要求的代码分支弹出提示信息。

6.一种业务测试装置，其特征在于，包括：

打标模块，用于响应于监听到对增量代码的测试操作，识别增量代码中的实体，接收对每个实体打标的标签，以及接收对每个标签配置的营业日期；

刷新模块，用于获取测试数据，确定对每个测试数据打标的标签，将每个测试数据中营业字段的属性值，设置为相应标签的营业日期；

选择模块，用于响应于达到目标营业日期，确定与目标营业日期对应的目标标签，确定打标目标标签的目标实体，从目标实体所处表的字段中，选择一个或多个字段作为测试字段；

覆盖检测模块，用于对于与目标标签和目标营业日期对应的每个测试数据，检测是否包括测试字段，以及每个测试字段下的属性值是否为空，对不符合要求的测试数据弹出提示信息。

7.根据权利要求6所述的装置，其特征在于，所述打标模块，用于：响应于监听到位于增量代码位置之前的其他代码测试完毕，触发对增量代码的测试操作；

所述刷新模块，用于：

获取所述其他代码的测试数据的标识，接收对每个标识打标的标签，将每个测试数据的标识和标签、配置的业务标识存入临时表中；其中，标识由表名、主键生成；

确定增量代码所属业务需求，根据业务需求的业务标识确定相应临时表，从临时表中获取每个测试数据的标识和标签，以根据标识获取测试数据。

8.根据权利要求6所述的装置，其特征在于，实体包括业务实体和计算实体，所述打标模块，还用于：

确定每个标签对应的实体，获取每个实体的字段，接收对其中一个或多个字段的选择操作，对选择的字段打标相应实体的标签；

所述选择模块，用于：

确定打标相应标签的业务实体，根据业务实体与计算实体之间的关联关系，确定业务实体关联的计算实体；

获取计算实体的编号，依据编号确定计算实体所处表，从表中打标目标标签的字段中，选择一个或多个字段作为测试字段。

9.根据权利要求6所述的装置，其特征在于，所述装置还包括代码分支模块，用于：

接收对增量代码中代码分支的定义操作，获取每个代码分支的文件路径地址，接收对其中一个或多个文件路径地址打标的标签，将打标的文件路径地址和标签存入临时表中；

响应于达到目标营业日期，从临时表中确定目标标签对应的文件路径地址，根据每个文件路径地址获取代码分支，判断每个代码分支的字段是否包括测试字段，对不符合要求的代码分支弹出提示信息。

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

一个或多个处理器；

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

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

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

12.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-5中任一项所述的方法。