CN106557859A - 一种验证方法和设备 - Google Patents

Abstract

本发明公开了一种验证方法和设备，该方法包括：确定项目中的代码变更点；基于所述代码变更点确定所述代码变更点对应的影响链路；基于所述影响链路中的代码结点的数量对所述项目进行验证；以此在代码层面对项目风险进行验证，并通过验证来控制风险的大小，从而提高日常技术改造的精确度，以及对代码潜在风险进行预判，实现了综合判断代码的风险程度以及影响面的大小。

Description

一种验证方法和设备

技术领域

本公开涉及计算机技术领域，特别涉及一种验证方法。本公开同时还涉及一种验证设备。

背景技术

在技术改造项目之中,业务没有发生过任何变更与修改,因此从业务角度来看无法判定需求/项目的业务风险程度，但是实际上,技术改造的风险是存在的,各种实现业务需求的方式可能会引发多种故障。

而目前的风险评估方式都是基于从业务层面对项目与需求进行风险评估的,但是这种策略也是片面的,在技术改造项目之中,没有发生任何业务变更,通过业务判定风险的方式就会完全失效,且在实际的项目需求中，涉及到的类是众多的，而一个应用的完整运行是动态的，各个类与类之间是相关的；在平时的工作之中所发现一个类本身并没有问题，但是一旦和其他类进行连接工作，就可能会引入一些超出预期的情况，而连接的类越多，发生问题的概率就越大。

可见现有技术中并无法实现对项目的风险进行准确有效地验证。

发明内容

针对现有技术中无法准确评估风险的缺陷，本公开提出了一种验证方法，用于验证修改后的项目，以控制风险，该包括：

确定项目中的代码变更点；

基于所述代码变更点确定所述代码变更点对应的影响链路；

基于所述影响链路中的代码结点的数量对所述项目进行验证。

可选的，所述确定项目中的代码变更点，具体包括：

获取在所述项目所修改后生成的变更代码和所述项目所对应业务的主干代码；

通过比较变更代码和主干代码，确定代码变更点。

可选的，所述基于所述代码变更点确定所述代码变更点对应的影响链路，具体包括：

基于所述代码变更点，确定所述代码变更点直接影响到的上游的影响结点；

基于所述影响结点进行迭代处理，以确定影响结点所影响到的更上游的影响结点，直至没有更上游的影响结点；

基于确定的所有影响结点确定影响链路。

可选的，所述基于所述影响链路中的代码结点的数量对所述项目进行验证，具体包括：

当存在多个项目时，基于所述影响链路中的代码结点的数量来确定对应的多个项目的风险值；或基于所述影响链路中的代码结点的数量与分配给每一个所述代码节点的权重，计算出加权总和，并基于所述加权总和来确定对应的多个项目的风险值；

选取风险值最小的项目作为验证通过的项目。

可选的，所述选取风险值最小的项目作为验证通过的项目，之后还包括：

对代码变更点影响的所有代码结点进行检测，以判断影响的各代码结点是否存在风险；

若判断结果为是，则对存在风险的代码结点进行修改以排除风险。

本公开还提出了一种验证设备，包括：

第一确定模块，用于确定项目中的代码变更点；

第二确定模块，用于基于所述代码变更点确定所述代码变更点对应的影响链路；

验证模块，用于基于所述影响链路中的代码结点的数量对所述项目进行验证。

可选的，所述第一确定模块，具体用于：

获取所述项目所修改后生成的变更代码和所述项目所对应业务的主干代码；

通过比较变更代码和主干代码，确定代码变更点。

可选的，所述第二确定模块，具体用于：

基于所述代码变更点，确定所述代码变更点直接影响到的上游的影响结点；

基于所述影响结点进行迭代处理，以确定影响结点所影响到的更上游的影响结点，直至没有更上游的影响结点；

基于确定的所有影响结点确定影响链路。

可选的，所述验证模块，具体用于：

当存在多个项目时，基于所述影响链路中的代码结点的数量来确定对应的多个项目的风险值；或基于所述影响链路中的代码结点的数量与分配给每一个所述代码节点的权重，计算出加权总和，并基于所述加权总和来确定对应的多个项目的风险值；

选取风险值最小的项目作为验证通过的项目。

可选的，该设备还包括：

修正模块，用于对代码变更点影响的所有代码结点进行检测，以判断影响的各代码结点是否存在风险；

若判断结果为是，则对存在风险的代码结点进行修改以排除风险。

与现有技术相比，本公开的技术方案有助于提高日常技术改造的精确度，以及对代码潜在风险进行预判，实现了综合判断代码的风险程度以及影响面的大小。

附图说明

图1为本公开实施例公开的一种验证方法的流程示意图；

图2为本公开实施例公开的一种验证方法中项目的影响范围的示意图；

图3为本公开实施例公开的一种代码变更点以及影响链路的示意图；

图4为本公开实施例公开的一种验证设备的结构示意图。

具体实施方式

如背景技术所述的，技术改造涉及对代码的修改，而对代码进行的修改会对其他的代码部分产生影响，进而这些影响会产生潜在的风险。例如，应用a与应用b之间的通信需要中间件1或其他系统的支持，而当需要对中间件1或者其他用于支持的系统进行改造时，需要判别这是否会影响到应用a与应用b。原因之一是：业务的不同代码之间是具有关联性的，变更其中一点，有可能会对其他代码产生预料不到的影响。

再例如，当需要对现有业务进行技术改造时，例如对用户购物下单的业务进行部分的变更或修改。对用户而言，在业务的使用上并不会有任何变化，但在后台对支撑下单的代码实现方式会进行部分的改变。为此，也需要从代码角度来确认变更某个或某些业务子类型会不会有系统性风险。例如，修改物流业务中的某一些部分，会不会产生不可预见的影响。

很多情况下，代码的变更点是与业务完全隔离的,无法从业务层面进行验证或判断。为此，本公开提出了一种验证方法，用以从代码的角度来验证修改后的项目，以控制风险。

根据本公开的一个实施例的对项目的验证方法如图1所示，包括以下步骤：

步骤101：确定代码变更点；

步骤102：基于代码变更点，确定代码变更点对应的影响链路；

步骤103：基于影响链路中的代码结点的数量，对项目进行验证。

具体的，在步骤101中确定代码变更点具体包括：

获取项目所修改后生成的变更代码和项目所对应业务的主干代码；

通过比较变更代码和主干代码，确定代码变更点。

具体的，根据一个实施例，进行的项目会对部分的业务进行修改，例如变更中间件。而在具体的变更中间件的过程中，涉及到对代码进行的补充或者修改，也即，会产生如图2所示的对应项目需求的一个或多个代码变更点。而各代码变更点也会影响其上一级的代码结点(即，存在代码调用关系的上级结点)，迭代地，受到影响的其上级的代码结点进而会影响再上级的代码结点(例如，由于再上级的结点调用了受到影响的上级结点)。由此可以认为，由于技术改造而改动的代码变更点会产生一系列的影响范围，称为影响链路。而在影响链路中存在有一个或多个代码结点。

因此，为了确定影响链路，首先需要确定准确的代码变更点。根据一个实施例，可以使用基于svn(Subversion，版本管理工具)以及git(分布式版本控制系统)的工具来进行比对，以确定代码变更点。具体的过程是：将本次的技术改造后生成的代码和主干代码进行对比，能具体获得发生代码变更的位置(例如，可以是变更所在的行号)，之后在从class文件中根据该位置获取到所对应的具体变更点。

接下来，在步骤102中，基于代码变更点，可以逐级确定代码变更点所对应的影响链路。

具体的，基于代码变更点，确定代码变更点直接影响到的上游的影响结点；基于影响结点进行迭代处理，以确定影响结点所影响到的更上游的影响结点，直至没有更上游的影响结点；基于确定的所有影响结点确定影响链路。也即是通过回溯的方法来确定结点。可以认识到，可能受到影响的代码结点是本方案所要考虑的结点，在此被称为影响结点。

如图3所示，在确定了进行代码修改的代码变更点(在本图中示例性地是修改结点0)之后，通过对class文件的分析，可以找到上游调用该修改结点0的所有上级结点。可以认为这些上级结点也被影响到了，因此将这些上级结点标记为影响结点1、2。然后进行迭代，依次找到调用该影响结点1、2的所有上级结点，标记为影响结点11、21、22。并继续进行迭代回溯，依次找到影响结点12以及再上游影响结点13，以及影响结点21、22的共同上游影响结点23以及再上游影响结点24。直到没有发现更上游的结点为止，也即到如图3中影响结点13、24为止，最终导出影响链路。在本示例中，修改结点0的影响链路为：(1)修改结点0->影响结点1->影响结点11->影响结点12->影响结点13，(2)修改结点0->影响结点21、22->影响结点23->影响结点24。

接下来，在步骤103中，基于影响链路中的代码结点的数量对项目进行验证。

基于上文的教导，本领域技术人员可以认识到，受到变更影响的结点越多，那么越容易出现不可预测的风险情况。因此，在一个实施例中，影响链路和影响结点的数量多少可以被用于后续验证是否存在风险。

由于一个技术改造项目中可能产生多个变更点，那么，将对所有变更点所确定得到的所有影响结点的数量进行加总，就可以得到对于该技术改造项目的总影响结点数量，记为该技术改造项目的总风险值，用于后续的验证。

由于在实际情况中，有可能对应于同一个技术改造的目标，存在多个不同的项目实施方式(即，不同的代码改造方式，显然，每种代码改造方式所产生的代码变更点可能会有所不同，则进而影响链路和影响结点也不同)，也可能只有一种项目实施方式，因此进行验证可以有以下两种情况：

情况1、当存在多个项目实施方式时，对每个项目实施方式进行上述的步骤101-102的分析，基于每个项目实施方式所得出的所述影响链路中的代码结点的数量，确定与每个项目实施方式相对应的风险值；选取风险值最小(总影响结点数量最少)的项目实施方式作为优选方式，也即验证通过的项目。

而在选取风险值最小的项目作为验证通过的项目，之后还包括：

对代码变更点影响的所有代码结点进行检测，以判断影响的各代码结点是否存在风险；

若判断结果为是，则对存在风险的代码结点进行修改以排除风险。

情况2、当确定了优选的项目实施方式后，或者只有一个项目实施方式时，即在选取风险值最小的项目作为验证通过的项目之后，还可以对代码变更点影响的所有代码结点进行检测，以判断影响的各代码结点是否存在风险；若判断结果为是，则对存在风险的代码结点进行修改以排除风险。具体的，对上述所确定的所有的影响结点一一进行检查，判定其是否存在潜在风险，对于实际存在风险的结点进行修改以排除风险。由于此时是针对总影响结点数量最少的项目实施方式进行的检查，因此可以更为有效快速地确定风险点，提高整个验证过程的效率。

在另一个替换实施例中，在得到了技术改造项目的总影响结点数量后，可以按照不同的情况需求，对每个影响结点进行加权，将加权后的总数量记为该技术改造项目的总风险值。具体的，当存在多个项目时，基于所述影响链路中的代码结点的数量来确定对应的多个项目的风险值；或基于所述影响链路中的代码结点的数量与分配给每一个所述代码节点的权重，计算出加权总和，并基于所述加权总和来确定对应的多个项目的风险值；选取风险值最小的项目作为验证通过的项目。换言之，本公开适用于对所有的代码结点给予一致的权重(例如都为1)，还可以为各代码结点给予不同的权重，并基于分配给每一个所述代码节点的权重，计算得到加权总和，作为项目的风险值。

具体而言，在一个实施例中，可以包括如下一个或多个步骤：如上所述地，针对每一个代码变更点，获取每一个代码变更点对应的影响链路的影响结点的数量。

基于加权条件来确定每一个影响结点的权重。在一个情况，加权条件可以是如下一个或多个：影响结点的影响范围，影响结点的代码复杂度，等等。在多个实施例中，具体来说，影响结点所影响范围越大(例如可以以调用该影响结点的处于上游的影响结点的数量来进行确定)，对该影响结点加权所确定的权重越大；和/或，影响结点的代码复杂度越高，对该影响结点加权所确定的权重越大。

在此情况下，加权后的影响结点的总数量具体表现为：各影响结点的加权总和，在此以一个具体的实施例来进行说明，例如项目1共有20个影响结点，其中有11个影响结点的权重都为0.8，剩余的9个影响结点的权重都为0.2，在此情况下，加权后的总数量，也即项目1的总风险值为10.6＝0.8×11+0.2×9。

为了对本公开进行进一步的说明，本公开实施例还提出了一种验证设备，如图4所示，包括：

第一确定模块401，用于确定项目中的代码变更点；

第二确定模块402，用于基于所述代码变更点确定所述代码变更点对应的影响链路；

验证模块403，用于基于所述影响链路中的代码结点的数量对所述项目进行验证。

具体的，所述第一确定模块401，具体用于：

获取所述项目所修改后生成的变更代码和项目所对应业务的主干代码；

通过比较变更代码和主干代码，确定代码变更点。

具体的，所述第二确定模块402，具体用于：

基于所述代码变更点，确定所述代码变更点直接影响到的上游的影响结点；

基于所述影响结点进行迭代处理，以确定影响结点所影响到的更上游的影响结点，直至没有更上游的影响结点；

基于确定的所有影响结点确定影响链路。

所述验证模块403，具体用于：

当存在多个项目时，基于所述影响链路中的代码结点的数量来确定对应的多个项目的风险值；或基于所述影响链路中的代码结点的数量与分配给每一个所述代码节点的权重，计算出加权总和，并基于所述加权总和来确定对应的多个项目的风险值；

选取风险值最小的项目作为验证通过的项目。

具体的，该设备，还包括：

修正模块，用于对代码变更点影响的所有代码结点进行检测，以判断影响的各代码结点是否存在风险；

若判断结果为是，则对存在风险的代码结点进行修改以排除风险。

与现有技术相比，本公开公开了确定项目中的代码变更点；基于所述代码变更点确定所述代码变更点对应的影响链路；基于所述影响链路中的代码结点的数量对所述项目进行验证；以此在代码层面对项目风险进行进行验证，并通过验证来控制风险的大小，从而提高日常技术改造之中需求接手的精确度，以及对代码潜在风险进行预判，实现了综合判断代码的风险程度以及影响面的大小。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本公开可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本公开的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本公开所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本公开序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本公开的几个具体实施场景，但是，本公开并非局限于此，任何本领域的技术人员能思之的变化都应落入本公开的保护范围。

Claims (10)

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

确定项目中的代码变更点；

基于所述代码变更点确定所述代码变更点对应的影响链路；

基于所述影响链路中的代码结点的数量对所述项目进行验证。

2.如权利要求1所述的方法，其特征在于，所述确定项目中的代码变更点，具体包括：

获取在所述项目所修改后生成的变更代码和所述项目所对应业务的主干代码；

通过比较变更代码和主干代码，确定代码变更点。

3.如权利要求1所述的方法，其特征在于，所述基于所述代码变更点确定所述代码变更点对应的影响链路，具体包括：

基于所述代码变更点，确定所述代码变更点直接影响到的上游的影响结点；

基于所述影响结点进行迭代处理，以确定影响结点所影响到的更上游的影响结点，直至没有更上游的影响结点；

基于确定的所有影响结点确定影响链路。

4.如权利要求1所述的方法，其特征在于，所述基于所述影响链路中的代码结点的数量对所述项目进行验证，具体包括：

当存在多个项目时，基于所述影响链路中的代码结点的数量来确定对应的多个项目的风险值；或基于所述影响链路中的代码结点的数量与分配给每一个所述代码节点的权重，计算出加权总和，并基于所述加权总和来确定对应的多个项目的风险值；

选取风险值最小的项目作为验证通过的项目。

5.如权利要求1或4所述的方法，其特征在于，所述选取风险值最小的项目作为验证通过的项目，之后还包括：

对代码变更点影响的所有代码结点进行检测，以判断影响的各代码结点是否存在风险；

若判断结果为是，则对存在风险的代码结点进行修改以排除风险。

6.一种验证设备，其特征在于，包括：

第一确定模块，用于确定项目中的代码变更点；

第二确定模块，用于基于所述代码变更点确定所述代码变更点对应的影响链路；

验证模块，用于基于所述影响链路中的代码结点的数量对所述项目进行验证。

7.如权利要求6所述的设备，其特征在于，所述第一确定模块，具体用于：

获取所述项目所修改后生成的变更代码和所述项目所对应业务的主干代码；

通过比较变更代码和主干代码，确定代码变更点。

8.如权利要求6所述的设备，其特征在于，所述第二确定模块，具体用于：

基于所述代码变更点，确定所述代码变更点直接影响到的上游的影响结点；

基于所述影响结点进行迭代处理，以确定影响结点所影响到的更上游的影响结点，直至没有更上游的影响结点；

基于确定的所有影响结点确定影响链路。

9.如权利要求6所述的设备，其特征在于，所述验证模块，具体用于：

当存在多个项目时，基于所述影响链路中的代码结点的数量来确定对应的多个项目的风险值；或基于所述影响链路中的代码结点的数量与分配给每一个所述代码节点的权重，计算出加权总和，并基于所述加权总和来确定对应的多个项目的风险值；

选取风险值最小的项目作为验证通过的项目。

10.如权利要求9所述的方法，其特征在于，还包括：

修正模块，用于对代码变更点影响的所有代码结点进行检测，以判断影响的各代码结点是否存在风险；

若判断结果为是，则对存在风险的代码结点进行修改以排除风险。