一种代码风险检查方法、装置及设备

技术领域

本申请涉及软件测试领域，特别涉及一种代码风险检查方法、装置及设备。需要说明的是，本申请公开的代码风险检查方法、装置及设备可用于金融领域，也可用于除金融领域之外的任意领域，本申请公开的代码风险检查方法、装置及设备的应用领域不做限定。

背景技术

在软件系统的日常开发、测试过程中，保证代码不存在潜在或明显的风险，对提升代码质量和测试进度变得越来越重要。

目前，在开发测试中，提交过程控制主要通过代码静态扫描工具进行规范性检查，然后利用单元测试驱动开发(Unit Test Driven Development，UTDD)思想中的单元测试工具对通过规范性检查的代码进行测试。然而，代码静态扫描工具，如SONAR等只能基于业界或公司技术部门制定的规则库去静态扫描代码中可能引发的问题，对于一些需要运行才能暴露的问题无法进行捕捉；基于UTDD的单元测试工具存在人为原因，会导致很多时候单元测试只是为了实现代码级覆盖率而编写，不仅质量参差不齐，难以起到守护产品质量的作用，而且也难以验证其是否真正从业务角度对分支实现了覆盖，从而无法保证产品代码质量。

因此，业内亟需一种可以解决上述技术问题的技术方案。

发明内容

本说明书实施例提供了一种代码风险检查方法、装置及设备，可以提高代码风险检测效率的同时，保证产品代码质量。

本说明书提供的一种代码风险检查方法、装置及设备是包括以下方式实现的。

一种代码风险检查方法，包括：获取目标代码；基于错误信息集对所述目标代码进行检测，获得检测数据；所述检测数据表示所述目标代码是否存在风险；在所述检测数据不存在风险的情况下，基于过程控制模型确定是否对所述目标代码执行破坏测试；其中，所述过程控制模型基于资源信息与破坏测试案例生成时间、破坏测试案例运行判断时间、代码错误率建立；在确定对所述目标代码执行破坏测试的情况下，基于所述目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例；执行所述破坏测试案例，获得与所述目标代码对应的执行结果；基于所述执行结果确定所述目标代码是否存在风险。

一种代码风险检查装置，包括：获取模块，用于获取目标代码；检测模块，用于基于错误信息集对所述目标代码进行检测，获得检测数据；所述检测数据表示所述目标代码是否存在风险；第一确定模块，用于在所述检测数据不存在风险的情况下，基于过程控制模型确定是否对所述目标代码执行破坏测试；其中，所述过程控制模型基于资源信息与破坏测试案例生成时间、破坏测试案例运行判断时间、代码错误率建立；生成模块，用于在确定对所述目标代码执行破坏测试的情况下，基于所述目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例；执行模块，用于执行所述破坏测试案例，获得与所述目标代码对应的执行结果；第二确定模块，用于基于所述执行结果确定所述目标代码是否存在风险。

一种代码风险检查设备，包括至少一个处理器以及存储计算机可执行指令的存储器，所述处理器执行所述指令时实现本说明书实施例中任意一个方法实施例的步骤。

一种计算机可读存储介质，其上存储有计算机指令，所述指令被执行时实现本说明书实施例中任意一个方法实施例的步骤。

本说明书提供的一种代码风险检查方法、装置及设备。一些实施例中可以获取目标代码，基于错误信息集对目标代码进行检测，获得检测数据，其中，检测数据表示目标代码是否存在风险。进一步，可以在检测数据不存在风险的情况下，基于过程控制模型确定是否对目标代码执行破坏测试，确定要对目标代码执行破坏测试时，可以基于目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例，进而执行破坏测试案例，获得与目标代码对应的执行结果，基于执行结果确定目标代码是否存在风险；其中，过程控制模型基于资源信息与破坏测试案例生成时间、破坏测试案例运行判断时间、代码错误率建立。采用本说明书提供的实施方案，可以提高代码风险检测效率的同时，保证产品代码质量。

附图说明

此处所说明的附图用来提供对本说明书的进一步理解，构成本说明书的一部分，并不构成对本说明书的限定。在附图中：

图1是本说明书提供的一种代码风险检查方法的一个实施例的流程示意图；

图2是本说明书提供的一种业务代码对应的有向图；

图3是本说明书提供的一种代码风险检查装置的一个实施例的模块结构示意图；

图4是本说明书提供的一种代码风险检查服务器的一个实施例的硬件结构框图。

具体实施方式

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

下面以一个具体的应用场景为例对本说明书实施方案进行说明。具体的，图1是本说明书提供的一种代码风险检查方法的一个实施例的流程示意图。虽然本说明书提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者部分合并后更少的操作步骤或模块单元。

本说明书提供的一种实施方案可以应用到客户端、服务器等中。所述客户端可以包括终端设备，如智能手机、平板电脑等。所述服务器可以包括单台计算机设备，也可以包括多个服务器组成的服务器集群，或者分布式系统的服务器结构等。

需要说明的是，下述实施例描述并不对基于本说明书的其他可扩展到的应用场景中的技术方案构成限制。具体的一种实施例如图1所示，本说明书提供的一种代码风险检查方法的一种实施例中，所述方法可以包括以下步骤。

S0：获取目标代码。

本说明书实施例中，目标代码可以是被测代码。被测代码可以是需要检查是否存在风险的代码，如代码在提交Git并出发Commit操作后，会进入代码的review阶段，在这个阶段中一般会进行一系列代码的检查，因此，可以将该阶段的代码认为是目标代码。其中，Git是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。Commit操作可以用于把事务所做的修改保存到数据库。Review可以减少代码的错误率。

一些实施例中，可以从数据库或其他存储器中获取目标代码，本说明书对此不作限定。

S2：基于错误信息集对所述目标代码进行检测，获得检测数据；所述检测数据表示所述目标代码是否存在风险。

本说明书实施例中，获取目标代码后，可以基于错误信息集对目标代码进行检测，获得检测数据。其中，检测数据可以表示目标代码是否存在风险。

一些实施例中，所述错误信息集可以通过下述方式获得：获取应用代码库中包括的业务代码；对所述业务代码进行结构化转化，获得所述业务代码对应的有向图；其中，所述有向图中包括所述业务代码的运行节点信息；所述运行节点信息包括参数信息、代码结构信息；利用广度优先算法遍历所述有向图，获得所述业务代码对应的执行路径信息；基于所述运行节点信息和所述执行路径信息，生成破坏测试案例；执行所述破坏测试案例，获取错误信息；所述错误信息包括执行所述破坏测试案例过程中出现错误时对应的执行路径信息、代码结构信息、参数信息；对所述错误信息进行预处理，获得错误信息集。其中，应用代码库中可以预先存储有大量业务代码。业务代码可以包括已经应用到业务中的代码，还可以包括源代码等。

一些实施场景中，结构化转化也可以称为节点化抽取，节点化抽取可以理解为是对代码本身结构的分解与抽离，其可以将代码转化成有向图。需要说明的是，一些实施场景中，业务代码中可以包括一个或多个程序方法(简称“方法”)，一个方法可以包含输入、输出、内部逻辑等信息。一般来说，方法内部逻辑可以包括一定的分支判断条件。其中，分支判断条件一般是根据自己的实际业务需求出发，基于编程语言的特性，基于不同判断条件给出不同的代码执行路径以及输出结果，以此来满足业务逻辑的实现。java编程语言的分支判断条件可以包括：1)try...catch，该表达式一般可以用于防止可能出现的程序异常，一般try模块中放入正常的业务代码，catch分支一般可以用于处理可能出现的程序异常；2)if...else if...else，该表达式作为最常见的分支判断条件，if可以用于碰撞第一个条件，一到多个else if可以用于碰撞之后一到多个条件，当所有前述条件都不满足时，就执行else的语句块；3)switch...case...default，switch语句一般有一个统一的被判断对象，根据一到多个case的值进行匹配，当匹配到后就执行对应的逻辑，当全部case都无法匹配时，就触发default语句块；4)三元表达式，该表达式可以看作是简易版的if...else，一般形式为：Var＝Boolean Equation？A:B，其表示三元表达式基于一个布尔表达式作为判断，当表达式为true时返回A，否则返回B。

基于以上介绍的java编程语言的分支判断条件可知，一个方法的内部逻辑通常由顺序执行、分支判断、循环执行三类组成。本说明书一些实施场景中，在将业务代码转化成有向图时，可以将顺序执行与循环执行作合并，这样，业务代码中一个方法的顺序执行链路的长度可以决定业务代码的深度，而分支判断可以增加业务代码的广度。

一些实施场景中，可以基于以下抽取规则将代码转化成有向图：

Step1：将方法的入口设置为有向图的start(开始)节点，初始代码深度记为d＝1；

Step2：判断下一行语句的形式；

其中，如果是顺序流语句，则跳过；如果是分支判断标识符，则转Step3；如果是结束标识符，则转Step4；如果是最后一行代码，转Step5。

Step3：深度d＝d+1，找到对应的结尾，按照分支在有向图中的分支，深度一致。进一步，继续在同级别向下寻找是否有同深度级别的分支判断结构，直到同级代码块结束，转Step2。

Step4：深度记为d

其中，d

Step5：记录最大深度

本说明书实施例中，利用抽取规则将业务代码从编程语言转换为有向图，可以方便结构化描述代码，为后续进行代码分析时提供更多便利，从而提高分析效率。

一些实施场景中，在将对业务代码进行结构化转化后，可以获得业务代码对应的有向图。其中，有向图以代码入口、结束表示有向图的开始节点与结束节点，有向图中的其它各个节点可以由分支结构组成。有向图中可以包括代码的运行节点信息，运行节点信息可以包括参数信息、代码结构信息。参数信息可以包括输入参数、输出参数、条件参数等。代码结构信息可以包括输入、输出、外部依赖、分支判断等。

一些实施场景中，获得业务代码对应的有向图后，可以利用广度优先算法遍历有向图，获得业务代码对应的执行路径信息。一些实施场景中，在获得业务代码对应的执行路径信息的同时，还可以获得对应的路径执行矩阵。

一些实施场景中，假设业务代码的一个方法中包括K条执行路径，d表示深度，

Step1：从start节点开始，记录当前深度d

Step2：基于分支判断条件，找到第i个深度级别的在第k条执行路径对应的数值，记录深度为d

Step3：记录先到达end节点的线路，记录结束节点的深度，此时对于某一条执行路径k来说，其执行路径信息为N

Step4：重复Step2和Step3，直到遍历过所有节点。

如图2所示，图2是本说明书提供的一种业务代码对应的有向图。其中，d表示深度，圆圈中数字表示节点编号，共有节点10个，圆圈中start表示开始节点(记为节点1)，圆圈中end表示结束节点(记为节点10)，有执行路径5条，方法在节点1、2、4、5进行了分支条件判断形成分支。利用广度优先算法遍历有向图，可以获得执行矩阵R为：

执行路径集合N

一些实施场景中，在业务代码对应的执行路径信息后，可以基于运行节点信息和执行路径信息设计破坏测试组件，对被测方法执行破坏测试，从而验证当前代码编写逻辑是否存在潜在的风险，为后续的智能识别提供数据基础。其中，破换测试组件可以理解为破坏测试案例。

一些实施场景中，基于目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例时，首先可以利用PowerMockito模拟业务代码中对外依赖信息，然后基于运行节点信息，设计破坏测试输入，最后基于执行路径信息和破坏测试输入，利用反射工具及代码模板生成工具生成测试案例。其中，PowerMockito是一个开源mock框架，可以用于隔断代码方法中的对外依赖，保证代码执行的单元级以及独立性。例如，一个方法内部连接了数据库来执行一些操作，那么在执行破坏测试时为了保证代码的单元性质，就需要隔断掉对外部的依赖，即并不能真正的去连接数据库，而PowerMockito的存在就可以模拟外部依赖的行为，进而实现“模拟”的效果。代码模板生成工具可以是Velocity。Velocity可以认为是一个模板引擎，可以用来生成测试案例。例如，设计好一封邮件的模板，只将部分核心内容(如时间、收件人等动态信息)传输给模板，利用Velocity就可以拼装出一个成品的邮件。反射工具可以包括javaassit、cglib等。javaassit是在Java中编辑字节码的类库，其可以在运行时查找对象属性、方法，修改作用域，通过方法名称调用方法等。cglib是一个强大的、高性能的代码生成库，其被广泛应用于AOP框架中，用以提供方法拦截操作。破坏测试输入可以理解为破坏测试案例的入参，其数值可以基于分支来推断获得，例如。比如入参有一个数组，而在分支里检查了这个数组的元素数目，并根据是否为空分支处理，么在这里对于数组的入参可以是空数组或者是有数据的数组。

一些实施场景中，设计破坏测试组件可以包括：(1)读取代码，获取到代码的输入信息、输出信息、对外依赖信息、分支判断条件信息；(2)设计破坏测试输入；(3)基于javaassit、cglib等反射工具包以及Velocity代码模板生成工具，自动生成破坏测试案例。

上述实施场景中，代码的输入信息一般可以分为三种，一种是无输入，一种是基本类型，包括常见数值、字符串、布尔、集合、Map等，另一种是较为复杂的类。对于这较为复杂的类一方面可以基于mock来进行模拟，对于一些难以mock但方法里也未用到的可以给null(空)，对于一些难以mock的则要通过人工编写破坏测试案例，但这种情况极少。

上述实施场景中，对于输入来说，可以基于对象扫描的方法检索其使用了哪些属性、方法，涉及到了哪些赋值和判断过程，通过结合类型和输入，可以得到具体的不同组合输入信息。

上述实施场景中，对于输出来说，一般可以包括三类，一种是无输出，即Void方法，一种是基本类型输出，另外就是类型输出。但一些实施场景中，在破坏测试中，还会存在一组特殊的输出，即Exception类，其是代码在抛出异常且代码本身未捕获的情况下产生的一个结果。

上述实施场景中，对于外部依赖，在软件开发中，一般指在一个方法中调用了数据库、发起了对外部的网络请求、或者调用了其他非系统类的方法。按照单元测试的隔离原则，对于这种情况，可以使用mock来隔断掉依赖，保证测试运行不因外部环境变化而出现不稳定的情况。本说明书实施例中，通过PowerMockito工具来隔断外部依赖，PowerMockito工具具备对实例方法、静态方法、final方法、private方法等的模拟。

上述实施场景中，对于分支判断，可以结合输入和外部依赖一起看，一般来说，方法内会依据数据的输入和中间变量进行判断，对于中间变量一般是通过外部方法来实现获取的，因此可以通过分析分支的判断条件可溯源至判断条件的产生位置，进而对不同分支设置不同的mock实现行为。

一些实施场景中，在生成破坏测试案例后，可以基于Junit执行破坏测试案例，获取错误信息。其中，错误信息可以包括执行破坏测试案例过程中出现错误时对应的执行路径信息、代码结构信息、参数信息、深度、错误类型、错误堆栈信息等。Junit是基于java的单元测试框架，可以用于运行对方法级别的单元级测试，驱动测试案例的执行。

本说明书实施例中，通过设计基于PowerMockito+Junit的破坏测试组件，通过对方法的输入、输出、外部依赖、分支条件判断，通过Velocity代码模板生成工具自动生成全路径覆盖的破坏性单元测试案例，通过运行生成的破坏性单元测试案例获取到大量错误信息，可以为后续错误分类提供数据基础，为后续代码风险检测提供保证。

一些实施例中，在获取错误信息后，可以对错误信息进行预处理，获得错误信息集。一些实施场景中，可以先将执行路径信息相同的错误信息合并，然后从合并后的错误信息集中剔除继发性错误信息，获得错误信息集。

一些实施场景中，在将执行路径信息相同的错误信息合并前，可以基于错误堆栈信息溯源到代码出错的位置，进而将其定位在两个执行节点内。由于发生错误的节点不一定是真正发生错误的位置，所以可以根据抛出的错误类型进一步来追溯到代码的错误真正发生位置。本说明书实施例中，将造成本次测试失败的根本原因(如数组越界、读写异常、网络连接异常等)称为原发性错误，将因原发性错误产生及代码运行产生的传播效应，进而导致后续代码执行出错称为继发性错误。

一些实施场景中，在将错误信息定位在两个执行节点内后，可以将因不同条件导致的相同执行路径对应的错误信息进行合并，然后从中剔除继发性错误信息，保留原发性错误信息径，从而获得错误信息集。例如一些实施场景中，针对单个方法的所有破坏测试成功案例进行分析，获取到该方法的所有错误信息后，由于考虑到可能的重复错误，可以根据原发性错误发生位置为中心实施去重与合并，最后得到方法m的错误信息集合

一些实施场景中，在获取错误信息后，还可以根据错误信息对应的执行路径信息从执行矩阵中抽取对应的子矩阵。例如一些实施场景中，可以基于错误执行路径，从执行矩阵中抽出对应的数值信息组成新的错误执行矩阵R

本说明书实施例中，在获得错误信息集后，还可以对错误信息集中错误信息进行分类。

一些实施场景中，可以将错误信息集中每条错误信息表示为向量，进而可以通过对向量进行分类实现对错误信息的分类。例如一些实施场景中，可以将某个方法对应的执行路径信息记为错误执行向量v

一些实施场景中，在将错误信息集中的错误信息通过向量组v＝(v

本实施场景中，对于一个有V个错误信息集组成的向量组集合，可以构造为有向图G＝(V,E,w)。其中，V表示有向图的节点，E表示错误信息集之间的弧，有E＝{ee＝(v

本实施场景中，对于有向图G

其中，上述a

本实施场景中，可以定义度矩阵D

其余元素均为0。其中，上述d

本实施场景中，L

本实施场景中，连接路径集合E

本实施场景中，可以使用多路规范割集准则作为实施方式，相比于其他准则，其具备较高的执行效率。多路规范割集准则的识别模型为：

本实施场景中，在识别模型建立后存在两个待优化参数，一个是高斯核函数σ，另一个是分隔簇数目K。为确定参数的最优取值，可以基于模拟退火的优化算法来优化两个参数的取值。其中，模拟退火算法以一定的概率来接受一个比当前解要差的解，因此有可能会跳出这个局部的最优解，达到全局的最优解。

因此，约束条件为：

其中，K为分隔簇数目，S

本实施场景中，通过迭代求解上述识别模型可以获取到最佳的错误信息分类，其可以用于检验新的代码是否存在已知错误。

本实施场景中，通过基于谱聚类+模拟退火算法实现了对错误信息的分类，此时，对于某一类错误信息Ε，有Ε＝{v

本说明书实施例中，在对错误信息集中的错误信息进行分类后，可以基于错误信息集对目标代码进行检测，从而确定目标代码中是否存在风险。

一些实施例中，在基于错误信息集对目标代码进行检测前，可以先基于业界或公司技术部门制定的规则库去静态扫描目标代码中是否存在可能引发的问题，确认不存在时，再基于错误信息集检测目标代码中是否存在风险。当然，上述只是进行示例性说明，静态扫描目标代码的方式不限于上述举例，所属领域技术人员在本申请技术精髓的启示下，还可能做出其它变更，但只要其实现的功能和效果与本申请相同或相似，均应涵盖于本申请保护范围内。

一些实施例中，所述基于错误信息集对所述目标代码进行检测前，可以包括：对所述目标代码进行结构化转化，获得所述目标代码对应的有向图；其中，所述有向图中包括所述目标代码的运行节点信息；利用广度优先算法遍历所述有向图，获得所述目标代码对应的执行路径信息。

需要说明的，上述对目标代码进行结构化转化、获得目标代码对应的执行路径信息的具体实现方式可以参照前述相关方法实施例的描述，在此不作一一赘述。

一些实施例中，所述基于错误信息集对所述目标代码进行检测，可以包括：检测所述错误信息集中是否存在与所述目标代码的代码结构信息相匹配的第一错误信息集；确定存在时，检测所述第一错误信息集中是否存在与所述目标代码对应的执行路径信息相匹配的第二错误信息集；确定存在时，检测所述第二错误信息集中是否存在与所述目标代码对应的参数信息相匹配的第三错误信息集。

一些实施场景中，基于错误信息集对目标代码进行检测时，可以将目标代码先进行节点化抽取，然后在错误信息集中进行匹配。具体匹配顺序是：先与错误信息集中每条错误信息对应的向量组中的代码结构向量v

上述将既有的错误信息集进行了分类，可以说此时有了用于衡量被检验代码是否存在既有错误的尺子。但此时存在的问题在于被检验代码与错误信息集的某个向量组匹配到何种程度才可以判定其属于该类错误。一些实施场景中，为了判定匹配到何种程度算匹配成功，为每个向量匹配时设定一个相似度阈值，进而可以通过该相似度阈值来判断每组向量是否匹配成功。

一些实施场景中，可以使用已知错误的代码训练三个相似度阈值(代码结构向量、错误执行向量、参数向量匹配时分别对应的相似度阈值)，然后基于错误信息集检测目标代码中是否存在风险时，基于三次匹配的相似度阈值，当每次匹配的结果超过相应的阈值，才进行下一组匹配，否则直接判定目标代码中不存在错误信息集中错误信息对应的风险，其是新的代码类型，进而可以考虑是否需要执行破坏性测试来发现问题。

一些实施场景中，可以通过下述方式确定上述三个相似度阈值：设初始相似度阈值，目标为预测为正且结果为正的参数个数占总数的百分比数TPR大于预设值θ，可以利用无约束优化算法迭代训练得到目标相似度阈值，具体的可以采用L-BFGS算法(Limitedmemory-BFGS，Limited memory拟牛顿算法)。其中，L-BFGS是一种省内存的BFGS，可以用于求解最优化问题。具体迭代过程如下所示：

S21：输入初始相似度阈值δ

S22：当TPR≤θ，执行步骤S23-步骤S27，否则执行S28；

S23：计算相似度阈值δ梯度：

S24：计算Hessian矩阵；

S25：计算Hessian矩阵的逆矩阵H

S26：计算更新：Δδ←-H

S27：应用更新：δ←δ+Δδ。

S28：当迭代得到的相似度阈值基本不发生变化时输出结果：目标相似度阈值δ。

一些实施场景中，当获得最佳相似度阈值δ

本说明书实施例中，通过将代码结构向量、错误执行向量、参数向量组成向量组，可以提高对错误信息的分类效率，划分出错误大类。通过利用已知错误代码确定在匹配代码结构向量、错误执行向量以及参数向量时对应的相似度阈值，可以有效提高代码风险检查的准确度。

一些实施例中，基于错误信息集检测到目标代码中存在风险时，可以从规则库抽取应对措施或修改建议，反馈给代码编写人员或其他管理人员。其中，规则库中可以预先存储有不同错误信息对应的修改建议或措施，代码审核人员和技术人员会分析错误信息，给出从代码设计层面的建议，为开发人员避免下次开发出同类代码给出建议，比如，为防止定时任务出现并发控制问题，应该为任务加锁以保证任务在同一时间节点只有一台服务器在执行。

S4：在所述检测数据不存在风险的情况下，基于过程控制模型确定是否对所述目标代码执行破坏测试；其中，所述过程控制模型基于资源信息与破坏测试案例生成时间、破坏测试案例运行判断时间、代码错误率建立。

本说明书实施例中，在检测数据不存在风险的情况下，可以基于过程控制模型确定是否对目标代码执行破坏测试，进而判断目标代码中是否存在风险。其中，过程控制模型也可以称为过程控制决策模型，其可以基于资源信息与破坏测试案例生成时间、破坏测试案例运行判断时间、代码错误率建立。过程控制模型以类中的方法是否执行破坏测试为决策变量，以费用作为输出值。资源信息可以是指费用、成本等信息。

由于对于日常开发来说，在敏捷开发的影响下代码提交速度与数目与日俱增，如果对于每一份代码都执行匹配、破坏测试、结果输出可能会造成代码的检查过程非常繁琐，从而影响研发效率。为此，本说明书实施例中，在基于错误信息集确定目标代码中不存在风险时，可以基于过程控制模型确定是否对目标代码执行破坏测试。过程控制模型可以在质量与效率间寻求一个平衡点，或者偏向于某种策略。其中，平衡点可以理解为为了实现总费用最小，在质量最优和效率最优间寻求的一点，在该平衡点下可以实现最小总费用的情况下尽可能实现部分质量最优和效率最优。本实施例中，将为了实现效率最优所付出的代价与为了实现质量最优所付出的代价之和可以称为总费用。对于注重质量轻视效率的研发过程，可以称为质量最优(Quality Optimize)，对于注重效率轻视质量的研发过程，可以称为效率最优(Efficiency Optimize)。总费用可以以符号Z代表，平衡点系数可以以符号α表示。

一些实施例中，建立过程控制模型时，首先要对质量和效率进行度量。

本实施例中，对于质量的度量，以方法的错误率作为衡量指标；对于效率的度量，以方法的分支的破坏测试案例生成时间与破坏测试案例运行判断时间作为度量。

本实施例中，对于效率的度量，可以假定一个类C有方法U个，表示为C＝{f

对于质量的度量，可以假定一个类中C方法f

对于整个目标代码来说，总费用模型可以表示为Z＝αZ

代入上式，总费用模型可以表示为：

其中，α表示平衡点系数，ω

对应约束为：

0≤α≤1

C＝{f

R

ω

0≤μ≤1

上述实施例中，通过量化质量和效率的量度，可以建立起是否执行破坏测试与总费用的关系(过程控制模型)。通过求解该模型，可以实现在特定平衡点系数即策略的情况下，实现整个流程的最小成本。

一些实施例中，可以基于遗传算法，对上述建立的模型进行求解。其中，遗传算法是基于备选解进行交叉、变异、选择、遗传来实现逐步优化的。具体的，交叉过程中，可以假设每次迭代的交叉概率为p

本实施例中，基于遗传算法对上述建立的模型进行求解时，求解对象(即决策变量)为类C中每个方法是否执行破坏测试，若执行则值为1，否则为0。定义变量Ψ

Step1：初始化相关参数，基于随机数任意生成动态测试集合，即种群；

Step2：基于不同的策略调用检查模块，运行跑出相关的数据，得到计算适应度的相关数据；

Step3：基于数据结果计算个体、群体的适应度；

Step4：对种群内个体实施变异、交叉、选择操作，生成新的种群合集；

Step5：对迭代次数进行判断，若超过则转Step6，否则转Step2；

Step6：输出最优运行策略。

本说明书实施例中，通过基于遗传算法对上述建立的模型进行求解，用户可以在自定义平衡点的情况下对不同方法类进行智能化评估，从而在质量和效率中寻求平衡，以实现运行成本最低的需求。

本说明书实施例中，通过建立基于效率与质量的过程控制模型，可针对当前研发需求来动态调整平衡点策略，得到相对最优的破坏测试执行策略，从而可以保证在代码质量与流水线效率的局部最优的同时，保证综合成本的全局最优。

S6：在确定对所述目标代码执行破坏测试的情况下，基于所述目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例。

本说明书实施例中，在确定对目标代码执行破坏测试时，可以基于目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例。

一些实施例中，所述基于所述目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例，可以包括：利用PowerMockito模拟所述目标代码中对外依赖信息；基于所述运行节点信息，设计破坏测试输入；基于所述执行路径信息和所述破坏测试输入，利用反射工具及代码模板生成工具生成测试案例。

需要说明的，上述生成破坏测试案例的具体实现方式可以参照前述相关方法实施例的描述，在此不作一一赘述。

一些实施例中，确定对目标代码执行破坏测试时，可以在预定时间内执行。其中预定时间可以根据实际场景进行设定，例如，可以是在夜间执行，也可以在其他空闲时间执行等，本说明书对此不作限定。

一些实施例中，在确定不对目标代码执行破坏测试时，可以输出利用错误信息集检测的结果。

S8：执行所述破坏测试案例，获得与所述目标代码对应的执行结果。

本说明书实施例中，在生成破坏测试案例后，可以执行破坏测试案例，获得与目标代码对应的执行结果。其中，执行结果中可以包括错误信息，也可以不包括错误信息。其中，错误信息可以包括执行破坏测试案例过程中出现错误时对应的执行路径信息、代码结构信息、参数信息、深度、错误类型、错误堆栈信息等。

一些实施例中，在生成破坏测试案例后，可以基于Junit执行破坏测试案例，获得与目标代码对应的执行结果。

S10：基于所述执行结果确定所述目标代码是否存在风险。

本说明书实施例中，在获得与目标代码对应的执行结果后，可以基于执行结果确定目标代码是否存在风险。

一些实施例中，所述基于所述执行结果确定所述目标代码是否存在风险，可以包括：判断所述执行结果中是否存在错误信息；确定存在时，基于所述错误信息更新所述错误信息集。其中，当执行结果中是否存在错误信息时，可以说明目标代码存在风险。

一些实施场景中，在确定执行结果中存在错误信息时，可以将其自动收集入库，实现错误库的自学习、自补充机制，为后续更新错误信息集提供数据基础，也为技术人员扩充规则库提供数据。

本说明书实施例所述方法可以以插件形式引入，实现构建流水线无侵入式触发，根据开发人员所提交代码进行动态风险检查，并将检查结果反馈给流水线(如Jenkins流水线)。其中，Jenkins流水线是一套插件，可以实现持续交付信息的落地和实施。

本说明书实施例中，可以应用到包括存储模块、逻辑运算模块以及交互模块的软件架构中。其中，存储模块主要可以存储所需要的相关基础数据、优化部分的计算结果以及所有的需要的相关参数，目前该模块可以通过ORACLE数据库以及mangoDB开发。逻辑运算模块主要可以包括三个作用：(1)和存储模块交互，存储运算结果信息、读取各类基本信息，其可以基于JAVA开发，与存储模块交互可以采用JPA(Java Persistence API，Java持久层API)作为ORM(Object Relational Mapping)框架；(2)实施逻辑计算：该部分主要进行数值计算与算法的流程控制；(3)为交互模块提供数据中转：作为展示层和存储层之间的层级，逻辑运算层可以接受交互层发起的API(Application Programming Interface，应用程序接口)请求，并返回对应数据。交互模块主要包括三个功能：(1)代码动态风险检查：基于当前用户提交的代码信息，抽取其运行节点信息、执行路径信息、进行既有错误信息集匹配与动态破坏测试；(2)信息推送：基于(1)的输出，组装可能的错误信息，并从规则库抽取应对措施或修改建议，返回构建的流水线；(3)规则库更新：后台以批量形式分析未知错误，并执行相应算法并提供给技术管理员进行进一步分析。目前，前端技术使用开源框架Vue.js开发。

本说明书实施例中，通过对代码库中业务代码进行分析，基于开源工具组件生成破坏型测试案例，对被测代码进行破坏测试，当破坏测试成功时可以获取相关信息，找到潜在存在的运行时问题，可以提升潜在问题的发现能力，进而可以为问题归类、有效建议的提出奠定基础。

本说明书实施例中，通过对被测代码进行破坏测试，可以获取到大量错误集合，通过对这些错误进行分类，可以确定错误类别，为后续规则库的更新提供数据基础，为技术人员进行错误规避指明方向，也为技术部门在更新代码开发规范提供一定的支持。

本说明书实施例中，在扫描新用户代码时通过扫描其代码结构与动态破坏测试来判断其错误类别，可以在有效避免重复破坏的同时，将错误信息提供给技术部门，为增加代码开发规范提供数据及指引。

本说明书实施例中，通过建立基于效率与质量的过程控制模型，可针对当前研发需求来动态调整平衡点策略，得到相对最优的破坏测试执行策略，从而可以保证在代码质量与流水线效率的局部最优的同时，保证综合成本的全局最优。

本说明书实施例中，基于Git提交操作所触发的Jenkins流水线，可以实现在无侵入的同时，有效检查代码风险，为提升代码质量及规避低级问题导致的测试进度缓慢提供新的思路。

当然，上述只是进行示例性说明，本说明书实施例不限于上述举例，所属领域技术人员在本申请技术精髓的启示下，还可能做出其它变更，但只要其实现的功能和效果与本申请相同或相似，均应涵盖于本申请保护范围内。

从以上的描述中，可以看出，本申请实施例可以获取目标代码，基于错误信息集对目标代码进行检测，获得检测数据，其中，检测数据表示目标代码是否存在风险。进一步，可以在检测数据不存在风险的情况下，基于过程控制模型确定是否对目标代码执行破坏测试，确定要对目标代码执行破坏测试时，可以基于目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例，进而执行破坏测试案例，获得与目标代码对应的执行结果，基于执行结果确定目标代码是否存在风险；其中，过程控制模型基于资源信息与破坏测试案例生成时间、破坏测试案例运行判断时间、代码错误率建立。由于本申请可以基于过程控制模型对目标代码选择性执行破坏测试，从而可以提高代码风险检测效率的同时，保证产品代码质量。

本说明书中上述方法的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参加即可，每个实施例重点说明的都是与其他实施例的不同之处。相关之处参见方法实施例的部分说明即可。

基于上述所述一种代码风险检查方法，本说明书一个或多个实施例还提供一种代码风险检查装置。所述的装置可以包括使用了本说明书实施例所述方法的系统(包括分布式系统)、软件(应用)、模块、组件、服务器、客户端等并结合必要的实施硬件的装置。基于同一创新构思，本说明书实施例提供的一个或多个实施例中的装置如下面的实施例所述。由于装置解决问题的实现方案与方法相似，因此本说明书实施例具体的装置的实施可以参见前述方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

具体地，图3是本说明书提供的一种代码风险检查装置的一个实施例的模块结构示意图，如图3所示，本说明书提供的一种代码风险检查装置可以包括：获取模块120，检测模块122，第一确定模块124，生成模块126，执行模块128，第二确定模块130。

获取模块120，可以用于获取目标代码；

检测模块122，可以用于基于错误信息集对所述目标代码进行检测，获得检测数据；所述检测数据表示所述目标代码是否存在风险；

第一确定模块124，可以用于在所述检测数据不存在风险的情况下，基于过程控制模型确定是否对所述目标代码执行破坏测试；其中，所述过程控制模型基于资源信息与破坏测试案例生成时间、破坏测试案例运行判断时间、代码错误率建立；

生成模块126，可以用于在确定对所述目标代码执行破坏测试的情况下，基于所述目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例；

执行模块128，可以用于执行所述破坏测试案例，获得与所述目标代码对应的执行结果；

第二确定模块130，可以用于基于所述执行结果确定所述目标代码是否存在风险。

需要说明的，上述所述的装置根据方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

本说明书还提供一种代码风险检查设备的实施例，包括处理器及用于存储处理器可执行指令的存储器，所述指令被所述处理器执行时实现包括以下步骤：获取目标代码；基于错误信息集对所述目标代码进行检测，获得检测数据；所述检测数据表示所述目标代码是否存在风险；在所述检测数据不存在风险的情况下，基于过程控制模型确定是否对所述目标代码执行破坏测试；其中，所述过程控制模型基于资源信息与破坏测试案例生成时间、破坏测试案例运行判断时间、代码错误率建立；在确定对所述目标代码执行破坏测试的情况下，基于所述目标代码对应的运行节点信息和执行路径信息，生成破坏测试案例；执行所述破坏测试案例，获得与所述目标代码对应的执行结果；基于所述执行结果确定所述目标代码是否存在风险。

需要说明的，上述所述的设备根据方法或装置实施例的描述还可以包括其他的实施方式。具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。

本说明书所提供的方法实施例可以在移动终端、计算机终端、服务器或者类似的运算装置中执行。以运行在服务器上为例，图4是本说明书提供的一种代码风险检查服务器的一个实施例的硬件结构框图，该服务器可以是上述实施例中的代码风险检查装置或代码风险检查设备。如图4所示，服务器10可以包括一个或多个(图中仅示出一个)处理器100(处理器100可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器200、以及用于通信功能的传输模块300。本领域普通技术人员可以理解，图4所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，服务器10还可包括比图4中所示更多或者更少的组件，例如还可以包括其他的处理硬件，如数据库或多级缓存、GPU，或者具有与图4所示不同的配置。

存储器200可用于存储应用软件的软件程序以及模块，如本说明书实施例中的代码风险检查方法对应的程序指令/模块，处理器100通过运行存储在存储器200内的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器200可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器200可进一步包括相对于处理器100远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输模块300用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输模块300包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块300可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书提供的上述实施例所述的方法或装置可以通过计算机程序实现业务逻辑并记录在存储介质上，所述的存储介质可以计算机读取并执行，实现本说明书实施例所描述方案的效果。所述存储介质可以包括用于存储信息的物理装置，通常是将信息数字化后再以利用电、磁或者光学等方式的媒体加以存储。所述存储介质可以包括：利用电能方式存储信息的装置如，各式存储器，如RAM、ROM等；利用磁能方式存储信息的装置如，硬盘、软盘、磁带、磁芯存储器、磁泡存储器、U盘；利用光学方式存储信息的装置如，CD或DVD。当然，还有其他方式的可读存储介质，例如量子存储器、石墨烯存储器等等。

本说明书提供的上述代码风险检查方法或装置实施例可以在计算机中由处理器执行相应的程序指令来实现，如使用windows操作系统的c++语言在PC端实现、linux系统实现，或其他例如使用android、iOS系统程序设计语言在智能终端实现，以及基于量子计算机的处理逻辑实现等。

需要说明的是说明书上述所述的装置、设备、系统根据相关方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照对应方法实施例的描述，在此不作一一赘述。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把部分模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。

本发明是参照根据本发明实施例的方法、装置、设备、系统的流程图和/或方框图来描述的。应理解可由计算机程序指令实现，可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。

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