CN109857630B - 代码检测方法、系统及设备 - Google Patents
代码检测方法、系统及设备 Download PDFInfo
- Publication number
- CN109857630B CN109857630B CN201711242297.2A CN201711242297A CN109857630B CN 109857630 B CN109857630 B CN 109857630B CN 201711242297 A CN201711242297 A CN 201711242297A CN 109857630 B CN109857630 B CN 109857630B
- Authority
- CN
- China
- Prior art keywords
- file
- service
- detection
- source code
- service content
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Abstract
本申请实施例提供一种代码检测方法、系统及设备。其中，方法包括如下的步骤：获取与源代码文件所属业务类匹配的业务规则集；对所述源代码文件进行业务解析，以解析出所述源代码文件中的业务内容；根据所述业务规则集，对所述业务内容进行缺陷检测。本申请实施例提供的技术方案，通过对源代码进行业务解析以得到业务内容，然后再根据与源代码所属业务类匹配的业务规则集，对业务内容进行缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
Description
技术领域
本申请涉及计算机技术领域，尤其涉及一种代码检测方法、系统及设备。
背景技术
现有信息平台的研发质量保障流程包括：编码阶段、测试阶段、回归测试阶段及上线阶段。现有技术中，测试阶段和回归阶段已经有较完备的方案保障，可快速构建和质量反馈；而编码阶段，仍然是整个质量保障过程中投入和技术手段运用最少的环节。
众所周知，研发阶段的高质量代码的交付，对整个项目周期、项目发布质量是最至关重要。而现有技术在编码阶段还停留在低级错误的检测上，对编程人员依赖性较大。
发明内容
鉴于上述问题，提出了本申请以便解决上述问题或至少部分地解决上述问题的代码检测方法、系统及设备。
于是，在本申请的一个实施例中，提供了一种代码检测方法。该方法包括：
获取与源代码所属业务类匹配的业务规则集；
对所述源代码进行业务解析，以解析出所述源代码中的业务内容；
根据所述业务规则集，对所述业务内容进行缺陷检测。
在本申请的另一个实施例中，提供了一种代码检测方法。该方法包括：
接收客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；
对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；
根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；
将缺陷检测结果反馈至所述客户端。
在本申请的又一个实施例中，提供了一种代码检测方法。该方法包括：
响应于用户通过客户端界面触发的检测事件，向服务端发送携带至少一个源代码文件的检测请求；
接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
其中，所述检测结果是通过对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，并根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测得到。
在本申请的又一个实施例中，提供了一种代码检测系统。该系统包括：
客户端，用于响应于用户通过客户端界面触发的检测事件，向服务端发送携带有至少一个源代码文件的检测请求；接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
服务端，用于接收所述客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；将缺陷检测结果反馈至所述客户端。
在本申请的又一个实施例中，提供了一种电子设备。该电子设备包括：第一存储器和第一处理器，其中，
所述第一存储器，用于存储程序；
所述第一处理器，与所述第一存储器耦合，用于执行所述第一存储器中存储的所述程序，以用于：
获取与源代码文件所属业务类匹配的业务规则集；
对所述源代码文件进行业务解析，以解析出所述源代码文件中的业务内容；
根据所述业务规则集，对所述业务内容进行缺陷检测。
在本申请的又一个实施例中，提供了一种服务端设备。该服务端设备，包括：第二存储器和第二处理器，其中，
所述第二存储器，用于存储程序；
所述第二处理器，与所述第二存储器耦合，用于执行所述第二存储器中存储的所述程序，以用于：
接收客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；
对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；
根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；
将缺陷检测结果反馈至所述客户端。
在本申请的又一个实施例中，提供了一种客户端设备。该客户端设备包括：第三存储器和第三处理器，其中，
所述第三存储器，用于存储程序；
所述第三处理器，与所述第三存储器耦合，用于执行所述第三存储器中存储的所述程序，以用于：
响应于用户通过客户端界面触发的检测事件，向服务端发送携带至少一个源代码文件的检测请求；
接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
其中，所述检测结果是通过对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，并根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测得到。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请一实施例提供的代码检测方法的流程示意图；
图2为本申请另一实施例提供的代码检测方法的流程示意图；
图3为本申请一实施例提供的代码检测方法中获取XML文件中业务内容的流程示意图；
图4为本申请又一实施例提供的代码检测方法的流程示意图；
图5为本申请又一实施例提供的代码检测方法的流程示意图；
图6为本申请又一实施例提供的代码检测方法的流程示意图；
图7为本申请又一实施例提供的代码检测方法的流程示意图；
图8为本申请一实施例提供的代码检测装置的结构示意图；
图9为本申请另一实施例提供的代码检测装置的结构示意图；
图10为本申请又一实施例提供的代码检测装置的结构示意图；
图11为申请一实施例提供的代码检测系统的结构示意图；
图12为本申请一实施例提供的电子设备的结构示意图；
图13为本申请一实施例提供的服务端设备的结构示意图；
图14为本申请一实施例提供的客户端设备的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。
在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
现有技术的开源的代码质量管理系统SonarQube本身有规则集的概念，但其缺点在于：SonarQube作为一个通用平台，当前受限于代码规范层面的检测规则，然而代码规范层的规则集在层出不穷的业务和技术框架，以及业务实现快节奏的情况下，规范层的规则已慢慢被界定为代码文化层面上的东西，已不被重视和使用。而本申请提供的方案旨在将代码检测与业务紧密关联，以让代码检测可以更好服务于业务。
图1示出了本申请一实施例提供的代码检测方法的流程示意图。如图1所示，所述方法包括：
101、获取与源代码文件所属业务类匹配的业务规则集。
102、对所述源代码文件进行业务解析，以解析出所述源代码文件中的业务内容。
103、根据所述业务规则集，对所述业务内容进行缺陷检测。
上述101中，源代码文件可以是编程人员提交至检测平台(如持续集成平台)上代码，或是用户单个触发业务代码扫描的对象，还可以是用户批量触发业务代码扫描对象中的一个。其中，批量业务代码扫描是一种有效的批量管理业务代码的手段，当某一业务代码出现一个所有业务代码的共性问题后，可以快速检测出存在相同的问题的其他源代码。
具体实施时，业务类与业务规则集的映射关系可预先配置好，获取源代码对应的业务规则集时，可根据业务类与业务规则集的映射关系得到源代码所属业务类匹配的业务规则集。
这里需要补充的是：业务规则集可预先配置。在一种可实现的技术方案中，业务规则集的配置可具体包括：
获取业务类对应的业务数据源；
将业务数据源抽象为规则代码模式，以得到规则项；
将规则项添加到业务规则集中。
其中，所述业务数据源可包括但不限于：所述业务类对应的已有代码文件的历史故障信息、缺陷经验信息和/或日志信息。例如，该业务类的技术架构规范、线上问题、日常测试bug(错误)等等。
上述102中，对所述源代码进行业务解析得到的业务内容可包括但不限于：存储在Mapper XML文件中的SQL(Structured Query Language，结构化查询语言)语句、存储在XML(eXtensible Markup Language，可扩展标记语言)的bean(类)字义、存储在POM(ProjectObject Mode，项目对象模型)文件中项目基础信息、存储于Java中的业务代码信息及结构信息等。但本申请实施例提及的业务内容不局限在这些SQL、bean、POM文件中的项目基础信息。
这里需要补充的是：上述Mapper是MyBatis定义的一种；MyBatis是一个可以自定义SQL、存储过程和高级映射的持久层框架。
在一种可实现的技术方案中，所述源代码文件包含XML文件。相应的，业务内容的解析流程可具体包括如下步骤：
S1021、将所述XML文件转换为树状结构；
S1022、获取所述树状结构中属于业务顶级元素的主节点；
S1023、提取所述主节点的业务内容以及附属于所述主节点的所有子节点的业务内容。
上述S1021中，可将源代码中的XML文件转换为DOM(Document Object Model，文档对象模型)结构。
具体实施时，上述S1022中提及的属于业务顶级元素的主节点，可通过查询业务顶级元素列表来确定，DOM结构中的哪一个或哪一些节点为属于业务顶级元素的主节点。其中，业务顶级元素列表可预先配置。具体实施时，可遍历该DOM结构中的一个节点，查询业务顶级元素列表中是否包含有与该节点对应的元素，若有，则该节点为属于业务顶级元素的主节点，若无，则该节点非主节点，继续遍历下一节点，直至遍历完DOM结构中的所有节点。
例如：Mapper XML中的业务顶级元素包括：cache、cache-ref、resultMap、SQL、insert、update、delete、select等。
抽取存储在XML的bean定义中，业务顶级元素包括：bean或beans:bean等。
POM文件中的依赖数据抽取中，业务顶级元素包括：project、modelVersion、groupId、artifactId、version、packaging、dependencies、parent、dependencyManagement、modules、properties、build、reporting、name、description、url、inceptionYear、licenses、organization、developers、contributors、issueManagement、ciManagement、mailingLists、scm、prerequisites、repositories、pluginRepositories、distributionManagement、profiles等。
在另一种可实现的技术方案中，所述源代码文件包含Java文件。相应的，业务内容的解析流程可具体包括如下步骤：
对所述Java文件进行词法及语法解析，得到抽象语法树；
遍历所述抽象语法树，以得到所述Java文件中的业务内容。
其中，抽象语法树(Abstract Syntax Tree，AST)是源代码的抽象语法结构的树状表现形式，是从具体语法中抽象出语言结构的本质性东西，而不考虑语言的具体符号表示。抽象语法树反映了抽象的语法结构，展示了一个操作过程并同时描述了源程序的层次结构。通过遍历所述抽象语法树，即可从中提取出业务代码信息及结构信息等业务内容。
这里需要补充的是：上述对Java文件进行词法及语法解析，得到抽象语法树的过程可参见现有技术实现，本方案对此不作说明。
上述103中，缺陷检测的过程就是业务内容与业务规则集中的规则项进行模式匹配的过程。这里，规则项，即规则代码模式可以是缺陷代码模式，也可以是完善代码模式。若规则项为缺陷代码模式且业务内容与缺陷代码模式匹配，则该业务内容存在缺陷；若规则项为缺陷代码模式且业务内容与缺陷代码模式不匹配，则该业务内容不存在缺陷。若规则项为完善代码模式且业务内容与完善代码模式匹配，则该业务内容不存在缺陷；若规则项为完善代码模式且业务内容与完善代码模式不匹配，则该业务内容存在缺陷。具体实施时，规则项选择缺陷代码模式还是完善代码模式，可基于具体需要确定。例如，金额类业务中，金额字段必须定义成BigDecimal；此时可以直接选择完善代码模式来构建规则项，只有待检测源代码文件中的业务内容的金额字段的定义与完善代码模式中的BigDecimal匹配才能断定不存在缺陷。
进一步的，在上述实施例和下述实施例提供的方法中，除基于业务规则集对业务内容进行缺陷检测外，还可基于通用规则集对业务内容进行检测。其中，通用规则集中可包含有通用编码规范、常见错误检测、多种业务存在的共性等等。采用通用规则集可对业务内容进行常规检测，即，本实施例提供的所述方法还可包括：获取通用规则集。相应的，上述步骤103根据所述业务规则集，对所述业务内容进行缺陷检测，可具体为：
结合所述业务规则集及所述通过规则集，对所述业务内容进行缺陷检测。
具体实施时，上述通用规则集可采用如下方法实现：从多个业务类对应的业务规则集中抽取出相同的规则项；将相同的规则项存储至通用规则集中。
进一步的，在上述实施例和下述实施例提供的方法中，还可包括对源代码进行词法及语法缺陷检测。一种可实现的具体方案为，对源代码进行词法及语法缺陷检测，包括：
调用词语法规则库对所述源代码进行静态扫描。
本实施例中，词语法规则库可具体为：根据待检测代码的类型、待检测代码的运行环境以及对待检测代码的具体要求所设置的或者说所定义的不符合相应要求或规范的规则库。该词语法规则库中可存储有不符合要求的代码，比如典型错误代码、典型代码缺陷、不符合项目设计规范的代码、不符合产品设计规范的代码等等。对代码进行静态扫描可以理解为：在不运行上述代码的方式下，通过词法分析、语法分析、控制流分析等技术对上述代码进行扫描，从而验证扫描的所述代码是否满足针对所述代码所要求的规范性、安全性、可靠性、可维护性等指标的一种代码分析技术。上述词法分析可以理解为：将字符序列转换为单词序列的过程；上述语法分析可以理解为：在词法分析的基础上，将单词序列组合成各类语法短语、语句、表达式等。
进一步的，为了方便用户查看，上述实施例和下述实施例提供的所述方法还可包括：
检测结果为存在缺陷时，记录存在缺陷的业务内容；
根据所述存在缺陷的业务内容，生成缺陷报告。
本申请实施例提供的技术方案，通过对源代码进行业务解析以得到业务内容，然后再根据与源代码所属业务类匹配的业务规则集，对业务内容进行单文件缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
在实际实践中申请人发现，因为实际业务的复杂性，通常都具有多个源代码文件，分别对每一个源代码文件进行单独检测已经不能满足业务对于缺陷检测的诉求，所以多类型多文件的关联检测已经成为当前代码检测的必然趋势。比如，需要检测应用在POM中是否依赖了webx.extend.rpc，然后再判断是否注入了指定的bean，由于这个检测是分布在不同的文件中的，必须要依赖多文件关联检测才能做到。再比如，公司内部使用的中间工具Dts在某些特殊场景下会出现bean加载错误，导致定时任务执行失败，具体为首先检测POM文件中依赖的Dts版本信息，然后再检测DtsClient的bean在实例化的时候有没有配置newInstance属性，这个检测也是分布在不同的文件中的属性检测，必须要依赖多文件关联检测才能做到。在比如，检测Mybatis(是一个可以自定义SQL、存储过程和高级映射的持久层框架)在定义XXXmapper.java和XXXmapper.XML时，配置的属性信息是否相同，这个检测也是分布在不同的文件中的属性检测，必须要依赖多文件关联检测才能做到。因此，在实际代码检测时，需要同时对多个源代码文件进行检测。
针对上述情况本申请实施例提供的所述方法引入的多文件关联缺陷检测，可以更好的满足于复杂业务的检测诉求。
图2示出了本申请另一实施例提供的代码检测方法的流程示意图。如图2所示，所述方法包括：
201、获取与源代码文件所属业务类匹配的业务规则集，所述业务规则集包括至少一个单文件检测规则项及至少一个多文件检测规则项。
202、对所述源代码进行业务解析，以解析出所述源代码文件中的业务内容。
203、根据所述至少一个单文件检测规则项，对所述业务内容进行单文件缺陷检测。
204、根据所述至少一个多文件检测规则项，判定所述业务内容是否属于多文件关联检测类。
205、所述业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息。
206、根据所述至少一个多文件关联代码特征信息，检测所述业务内容是否存在多文件关联缺陷。
其中，有关上述201～202的内容可参见上述实施例中的相应内容，此处不再赘述。
上述单文件检测规则项及多文件检测规则项均可基于所述业务类对应的已有代码文件的历史故障信息、缺陷经验信息和/或日志信息等确定。例如，该业务类的技术架构规范、线上问题、日常测试bug(错误)等等。
上述204中，可根据源代码文件与同批次触发的其他文件的依赖关系，判断自该源代码文件解析出的业务内容是否属于多文件检测类型。其中，至少一个多文件检测规则项可理解为：至少一种符合多文件检测类型的判定模式；使用至少一个多文件检测规则项扫描源代码文件的业务内容，若业务内容与所述至少一个多文件检测规则项中的一个多文件检测规则项匹配，则该业务内容属于多文件检测类型，需进行多文件关联检测。多文件检测类型的业务内容可简单理解为在检测过程中需涉及到多个文件的综合信息才能完成检测。
其中，多文件关联代码特征信息可在源代码文件的业务内容进行多文件关联检测完成后，若该业务内容不存在多文件关联缺陷，可通过从所述源代码文件的业务内容中提取出多文件关联缺陷检测需要的至少一个业务代码信息得到。该提取到的至少一个业务代码信息即作为多文件关联代码特征信息被存储下来，为后续源代码文件进行多文件关联缺陷作准备。即本实施例提供的所述方法，还可包括如下步骤：
若所述业务内容不存在多文件关联缺陷，则从所述业务内容中提取出多文件关联缺陷检测需要的至少一个业务代码信息；
将所述至少一个业务代码信息作为多文件关联代码特征信息进行存储。
进一步的，对批量触发的多个源代码文件进行多文件关联缺陷检测，还是针对单个源代码文件来说的；实际应用中还存在一种场景需要全局考虑多个源代码文件是否存在缺陷。例如，在检测任一一个源代码文件时，发现不存在片段A，都不能立即报错，需要全局判断多个源代码文件中是否存在有片段A，若存在片段A，则不存在缺陷；反之存在缺陷。因此，本实施例提供的所述方法，还可包括如下步骤：
根据全局规则，对自所述源代码文件及与所述源代码文件同批次触发的所有文件中解析出的业务内容进行缺陷检测。
其中，全局规则可以根据日常Bug、开发代码的经验信息及线上故障等定制得到。该全局规则可预先定制，在需要进行全局缺陷检测时可直接调用即可。
这里需要说明的是：上述步骤(即根据全局规则进行缺陷检测过程)可在对同批次触发的所有源代码文件均进行多文件关联检测完成后再执行，也可独立执行，本实施例对此不作具体限定。
本申请实施例提供的技术方案，通过业务规则集将代码检测从现有的只能应用于通用编码规范和错误问题检测，升级到进行各种业务内容相关的检测，包括业务要求的技术结构、业务编码规范、业务代码bug等。其次，在现在的项目代码中，XML存储了越来越多的业务信息，通过提取XML中的业务内容，可以完成更多的业务检测诉求；最后，本方案引入的多文件关联缺陷检测，可以更好的满足于复杂业务的检测诉求。通过以上步骤，代码检测与业务进行很好的适配，使代码检测的应用范围得到本质上的提升。
进一步的，上述各实施例提供的所述方法中，还可包括如下步骤：
接收客户端提交的所述源代码文件；或者
响应于客户端单个或批量触发的检测事件，获取所述检测事件指向的至少一个欲检测文件，所述至少一个欲检测文件中包含有所述源代码文件。
具体实施时，用户可通过客户端提供的界面触发提交源代码文件，或单个或批量触发的检测事件，本实施例对此不作具体限定。
下面将结合具体示例对本申请实施例提供的代码检测方法进行进一步的说明。本申请实施例提供的代码检测方法主要包括三大部分：代码扫描触发、执行代码扫描及缺陷报告处理。
一、代码扫描触发。
具体的，触发检测有两种方式：人为触发和代码提交。例如，可结合持续集成平台，通过人机交互界面人为单个或批量触发至少一个源代码文件的检测或人为提交至少一个待检测的源代码文件。批量源代码文件是一种有效的批量管理业务代码的手段，当某一业务代码出现一个所有业务代码的共性问题后可以快速检测出存在相同的问题的其他文件。同时，通过分析批量源代码文件中存在的共性问题，可以快速根据问题抽象缺陷代码模式编写规则，并将其加入至通用规则集中，便于后续调用该通过规则集同时对多个源代码文件进行检测。
例如，某一业务系统审批流程获取下一个审批节点人时，若没有获取到则审批异常。原因是：代码中对于“workNo”的获取处理逻辑是有问题的(如果工号开头不为数字则返回工号，否则不足6位则开头用0补满6位的逻辑校验)，这类问题一旦在线上出现，影响会比较大。对于这类问题，可基于该问题人为或由系统自动制定出相应的规则项，并将该规则项存储至通用规则集中。在多个源代码文件批量检测时基于该规则项可同时发现多个源代码文件存在相同问题，进而避免了同类问题的再次发生。
又例如，一个相同的操作，大部分情况下都能正常运行，但是偶尔会出现XX找不到的报错，通过前端的RPC(Remote Procedure Call Protocol，远程过程调用协议)请求，发现前端发出的参数A，在后端拿到后就变成B(Long类型)。针对该类问题，可人为或由系统自动制定出相应的规则项，并将该规则项存储至通用规则集中。
二、执行代码检测。其中执行代码检测包括三大部分：业务规则集匹配、源码解析及缺陷检测。
2.1、业务规则集匹配。
具体实施过程为：根据源代码文件A匹配到对应的业务规则集A(RuleSetA)，然后再加载通用规则集(BaseRuleSet)。其目的是：后续能同时结合业务规则集A及通用规则集对源代码文件进行检测。
业务规则集A与源代码文件A的映射关系是预先配置好的。在配置业务规则集A时，首先要做的就是获取源代码文件A所属业务类A对应的业务数据源，如业务类A代码文件的技术架构规范、日常测试bug、线上问题等等，本申请实施例对此不作具体限定；将业务数据源抽象为具体的缺陷代码模式以得到规则项；将规则添加到业务规则集A中。
业务规则定制应用举例：假设财务类应用A以及基础服务类应用B。
财务类应用A，因为财务类应用对于金额的精度要求非常高，那么针对金额控制的业务规则：
规则1、金额字段必须定义成BigDecimal；
规则2、BigDecimal在进行比较时需要使用compareTo方法，不能使用equlas；
规则3、BigDecimal加减乘除操作后必须要赋值给具体的变量，等其他财务类规则。
制定规则1的原因在于：浮点型在存储时有丢失精确度的风险，需要使用精确度高的BigDecimal。规则2的原因在于：BigDecimal的equals方法，会同时比较数值和精度，而compareTo只比较数据；如果使用equals方法，会出现3.1和3.10不相等的情况。规则3的原因在于：BigDecimal的加减乘除并不操作自身，而是返回一个新的对象，所以只执行加减乘除操作，操作失效。
基础服务类应用B，因为基础服务类应用主要作用是对外提供服务，所以对于性能的要求较高，对于性能较低的SQL写法是不允许的；那么对基础服务类应用的业务规则有：
规则1、SQL中不能出现3表以上的关联查询；
规则2、SQL中不能使用exists及not exists关键字；
规则3、SQL查询条件不允许使用函数；等其他性能相关的规则。
财务类应用A和基础服务类应用B因其各自的功能特性不同，对于代码的写法也不同；所以上述规则在2个应用中并不能共用，所以业务代码的规则定制就显的非常重要，这使代码检测可以更好的嵌入到各种业务代码中，发挥更高的价值。另外，因为在代码写法规范上，还是存在许多共性的规则，所以本方案中还存在一个通用规则集。通过通用规则集+业务规则集的概念能更好的检测不同的业务代码。
2.2、源码解析。
源码解析的目的是：针对不同的源文件类型，解析出代码特征及业务内容，作为下一步检测时的源数据。其中，源码解析可包括：Java文件解析及XML文件解析。
其中，Java文件解析主要是通过词法解析和语法解析，得到Java文件的AST(Abstract Syntax Tree，抽象语法树)。本申请实施例提供的方案中可通过遍历抽象语法树，以得到Java文件中的业务内容，如存储于Java中的业务代码信息及结构信息等等，本实施例对此不作具体限定。
XML源文件解析，不关注XML语法上的问题，主要关注点在于XML中携带的业务数据内容。本申请实施例提供的方案中在XML中提取业务内容的处理流程如图3所示，包括：
301、将存储业务内容的XML源文件转成DOM(Document Oject Model，文件对象模型)结构。
302、遍历该DOM结构上的一个节点，并判断该节点是否为属于业务顶级元素的主节点；若不是，则继续遍历下一节点，直至遍历完所有节点；若是，则记录元素中的业务内容，执行步骤303。
303、递归处理该业务顶级元素的所有子元素，并分别记录子元素中的业务内容。
使用该方案，可记录存储在Mapper XML文件中的SQL语句、存储在XML的bean字义、存储在pom文件中项目基础信息等等，本申请实施例对此不作具体限定。
例如，记录存储在Mapper XML文件中的SQL语句。其中，mapper XML中的业务顶级元素包括：cache、cache-ref、resultMap、SQL、insert、update、delete、select。
记录存储在XML的bean定义，其中业务顶级元素包括：bean或beans:bean。
记录存储在pom文件中项目基础信息，其中业务顶级元素包括：project、modelVersion、groupId、artifactId、version、packaging、dependencies、parent、dependencyManagement、modules、properties、build、reporting、name、description、url、inceptionYear、licenses、organization、developers、contributors、issueManagement、ciManagement、mailingLists、scm、prerequisites、repositories、pluginRepositories、distributionManagement、profiles。
应用效果举例如下，现在对于SQL的错误只能在运行阶段发现，但是通过本方案的技术，可以在代码提交阶段就可以快速检出一部分缺陷或错误SQL的写法，降低代码的修复成本。
mapper XML代码片断：
从上述mapper XML代码片断中提取出的业务内容结果为：
select org_id as orgId from tax_busi_conf where is_deleted＝'n'andversion_code＝#{busiConfVersionCode}(IF<null ！＝busiNames and！busiNames.isEmpty()>){and busi_name in(FOREACH<busiNames>){(#{busiName})}andversion_code＝#{busiReclassifyVersionCode}
这里需要补充的是：在进行XML业务内容提取部分，上述实施例仅示出了SQL、bean、POM依赖等特定内容的记录，但是存储在XML中的业务内容非常多样，所以XML中的业务内容提取可以有针对其他内容的提取，本申请实施例对此不作具体限定。
2.3、缺陷检测。
该部分可分为两部分：单文件缺陷检测和多文件关联缺陷检测。
单文件缺陷检测，是将源代码解析出来的代码与对应的规则集中的规则项进行模式匹配，记录缺陷的代码。
多文件关联缺陷检测，是根据多个文件的代码特征进行综合判断是否有缺陷发生。其具体的实现方案可参见图4所示的流程图：
在使用业务规则集中的至少一个单文件缺陷规则项对源代码文件的业务内容进行扫描时，将出现在多文件关联综合判断需要使用的特征存储下来，在需要执行多类型多文件缺陷检测时取出存储的特征，完成多文件关联缺陷检测。
在一种可实现的技术方案中，所述业务规则集包括：至少一个单文件检测规则项及至少一个多文件检测规则项。代码检测方法包括：
401、以匹配好的业务规则集和待检测的多个源代码文件作为输入，根据至少一个单文件检测规则项对多个源代码文件中的第一源代码文件的业务内容进行单文件缺陷检测。
402、根据所述至少一个多文件检测规则项，判定所述第一源代码文件的业务内容是否属于多文件检测类，若是，则执行步骤403；否则执行步骤405。
403、获取至少一个多文件关联代码特征信息，并根据所述至少一个多文件关联代码特征信息，检测所述第一源代码文件的业务内容是否存在多文件关联缺陷，若存在缺陷，则记录缺陷并进入步骤405；若不存在规则，则继续执行步骤404。
其中，至少一个多文件关联代码特征信息是通过提取多个源代码文件中已检测过源代码文件中多文件关联缺陷检测需要的至少一个业务代码信息得到。
404、从所述第一源代码文件的业务内容中提取出多文件关联缺陷检测需要的至少一个业务代码信息，将所述至少一个业务代码信息作为多文件关联代码特征信息进行存储。
405、判断所有源代码文件是否均检测完，若是，继续执行步骤406；否则，返回步骤401以对多个源代码文件中的下一未检测的第二源代码文件进行单文件规则检测。
406、根据全局规则，对多个源代码的业务内容进行缺陷检测，若存在缺陷，则记录缺陷。
三、缺陷报告处理
缺陷报告处理模块是将检测出来的缺陷进行分类汇总及展示的报告内容。
本申请实施例提供的技术方案具有如下有益效果：
1、批量触发代码检测，快速实现批量应用针对特定问题的自检。
2、业务规则集定制，不同的业务定制各自业务特性的规则集，使代码检测和业务紧密关联。将代码检测从最初的只能应用于通用编码规范和错误问题检测，升级到进行各种业务内容相关的检测，包括业务要求的技术结构、业务编码规范、业务代码bug等。
3)XML业务内容提取，在现在的项目代码中，XML存储了越来越多的业务信息，通过提取XML中的业务内容，可以完成更多的业务检测诉求。尤其现在存储在Mapper XML中的SQL，原来只能在运行时检测SQL的写法，现在可以在代码提交时检测基础SQL错误，降低SQL代码维护成本。
4)多文件关联缺陷检测。通过组合多个文件的综合信息来判断是否存在缺陷。多文件关联缺陷检测，可以更好的满足于复杂业务的检测诉求，是代码缺陷检测进行业务缺陷检测必须要进行的扩展升级。
这里需要说明的是：上述内容中提供的各方法实施例的执行主体可以是服务端也可以是客户端。其中，服务端可以是通用服务器、虚拟中心或云端等等。客户端可以是台式电脑、笔记本电脑、移动设备等等。
图5示出了本申请又一实施例提供的代码检测方法的流程示意图。本实施例提供的所述方法的执行主体可以是服务端。如图5所示，所述方法包括：
501、接收客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件。
502、对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容。
503、根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测。
504、将缺陷检测结果反馈至所述客户端。
上述502中，所述至少一个源代码文件中的各源代码文件均包含有XML文件。相应的，上述对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，具体为对至少一个源代码文件中的XML文件进行业务解析，以解析出各源代码文件的XML文件中的业务内容。
在一种可实现的技术方案中，上述对每个源代码文件的XML文件进行业务解析的过程包括：
将所述XML文件转换为树状结构；
获取所述树状结构中属于业务顶级元素的主节点；
提取所述主节点的业务内容以及附属于所述主节点的所有子节点的业务内容。
进一步的，所述至少一个源代码文件中的各源代码文件还包含有Java文件。相应的，上述对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，具体为对至少一个源代码文件中的Java文件进行业务解析，以解析出各源代码文件的Java文件中的业务内容。
在一种可实现的技术方案中，上述对每个源代码文件的Java文件进行业务解析的过程包括：
对所述Java文件进行词法及语法解析，得到抽象语法树；
遍历所述抽象语法树，以得到所述Java文件中的业务内容。
上述从源代码文件中解析出的业务内容可包括：存储在Mapper XML文件中的SQL语句、存储在XML的bean字义、存储在POM文件中的项目基础信息、存储于Java中的业务代码信息及结构信息等等。
上述503步骤可简单理解为：根据业务规则集依次对至少一个源代码文件的业务内容进行缺陷扫描。
在一种可实现的技术方案中，上述业务规则集包括：至少一个单文件检测规则项及至少一个多文件检测规则项。相应的，上述步骤503中对一个源代码文件的业务内容进行缺陷检测的过程，包括如下步骤：
S5031、根据所述至少一个单文件检测规则项，对所述源代码文件的业务内容进行单文件缺陷检测。
S5032、根据所述至少一个多文件检测规则项，判定所述源代码文件的业务内容是否属于多文件关联检测类。
S5033、所述源代码文件的业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息。
S5034、根据所述至少一个多文件关联代码特征信息，检测所述源代码文件的业务内容是否存在多文件关联缺陷。
这里需要补充的是：其他源代码文件也可采用上述方法实现缺陷检测，此次不再一一赘述。有关上述各步骤的详细内容可参见上述各实施例中的相关内容，此处不再赘述。
进一步的，上述实施例提供的所述方法还可包括：
若所述源代码文件的业务内容不存在多文件关联缺陷，则从源代码文件的业务内容中提取多文件关联检测需要的至少一个业务代码信息；
将所述至少一个业务代码信息作为多文件关联代码特征信息进行存储。
进一步的，上述实施例提供的所述方法还可包括：根据全局规则，对所述至少一个源代码文件的业务内容进行缺陷检测。
进一步的，上述实施例提供的所述方法还可包括：获取通用规则集。相应的，上述步骤503、根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测，包括：
结合所述业务规则集及所述通用规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测。
进一步的，为了对源代码文件进行的检测更加全面，本实施例提供的技术方案还可包括分别对所述至少一个源代码文件进行词法及语法缺陷检测。
进一步的，本实施例提供的技术方案还可包括：
获取业务类对应的业务数据源；
将所述业务数据源抽象为规则代码模式，以得到规则项；
将所述规则项添加到业务规则集中。
其中，所述业务数据源包括：所述业务类对应的已有代码文件的历史故障信息、缺陷经验信息和/或日志信息等。
进一步的，本实施例提供的技术方案还可包括：从多个业务类对应的业务规则集中抽取出相同的规则项；
将相同的规则项存储至通用规则集中。
这里需要说明的是：本实施例中未提及的内容(如本实施例中的某一步骤或特征的具体实现方案或解释性文字)可参见上文中内容，此处不再赘述。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
图6示出了本申请又一实施例提供的代码检测方法的流程示意图。本实施例提供的方法的执行主体可以是客户端。如图6所示，所述方法包括：
601、响应于用户通过客户端界面触发的检测事件，向服务端发送携带至少一个源代码文件的检测请求。
602、接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果。
其中，所述检测结果是通过对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，并根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测得到。
其中，上述检测事件可通过如下几种方式触发，即本申请实施例还包括：
监测到用户通过所述客户端界面进行欲检测文件提交操作时，触发所述检测事件；或者
监听到用户通过所述客户端界面进行的单个或批量文件选择操作时，触发所述检测事件；或者
监听到用户通过所述客户端界面输入指定语音时，触发所述检测事件。
这里需要说明的是：上述对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，并根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测，具体实现过程可参见上文中的相关内容，此处不再赘述。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
图7示出了本申请又一实施例提供的代码检测方法的流程示意图。如图7所示，所述方法包括：
701、客户端响应于用户通过客户端界面触发的检测事件，向服务端发送携带至少一个源代码文件的检测请求。
702、服务端对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容。
703、服务端根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测。
704、服务端将缺陷检测结果反馈至所述客户端。
705、客户端接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果。
其中，有关上述701～705的内容可参见上述各实施例中的内容，此处不再赘述。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
图8示出了本申请一实施例提供的代码检测装置的结构示意图。如图8所示，所述代码检测装置包括：
第一获取模块801，用于获取与源代码文件所属业务类匹配的业务规则集；
解析模块802，用于对所述源代码文件进行业务解析，以解析出所述源代码文件中的业务内容；
检测模块803，用于根据所述业务规则集，对所述业务内容进行缺陷检测。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
进一步的，所述源代码文件包含XML文件。相应的，上述解析模块802还用于：将所述XML文件转换为树状结构；获取所述树状结构中属于业务顶级元素的主节点；提取所述主节点的业务内容以及附属于所述主节点的所有子节点的业务内容。
进一步的，所述源代码文件包含Java文件。相应的，上述解析模块802还用于：对所述Java文件进行词法及语法解析，得到抽象语法树；遍历所述抽象语法树，以得到所述Java文件中的业务内容。
进一步的，所述业务内容包括：存储在Mapper XML文件中的SQL语句、存储在XML的bean字义、存储在POM文件中的项目基础信息、存储于Java中的业务代码信息及结构信息。
进一步的，所述业务规则集包括至少一个单文件检测规则项及至少一个多文件检测规则项。相应的，所述检测模块803还用于：
根据所述至少一个单文件检测规则项，对所述业务内容进行单文件缺陷检测；
根据所述至少一个多文件检测规则项，判定所述业务内容是否属于多文件关联检测类；
所述业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息；
根据所述至少一个多文件关联代码特征信息，检测所述业务内容是否存在多文件关联缺陷。
进一步的，所述代码检测装置还包括：
提取模块，用于在所述业务内容不存在多文件关联缺陷时，从所述业务内容中提取多文件关联缺陷检测需要的至少一个业务代码信息；
存储模块，用于将所述至少一个业务代码信息作为多文件关联代码特征信息进行存储。
进一步的，所述检测模块还用于：根据全局规则，对自所述源代码文件及与所述源代码文件同批次触发的所有文件中解析出的业务内容进行缺陷检测。
进一步的，所述代码检测装置还包括：
记录模块，用于检测结果为存在缺陷时，记录存在缺陷的业务内容；
生成模块，用于根据所述存在缺陷的业务内容生成缺陷报告。
进一步的，所述第一获取模块还用于获取通用规则集；相应的，所述检测模块还用于结合所述业务规则集及所述通用规则集，对所述业务内容进行缺陷检测。
进一步的，所述检测模块还用于：对所述源代码文件进行词法及语法缺陷检测。
进一步的，所述代码检测模块还包括：规则集配置模块。该规则集配置模块用于获取业务类对应的业务数据源；将所述业务数据源抽象为缺陷代码模式，以得到规则项；将所述规则项添加至所述业务类对应的业务规则集中。
进一步的，所述业务数据源包括：所述业务类对应的已有代码文件的历史故障信息、缺陷经验信息和/或日志信息等。
再进一步的，上述规则集配置模块还用于从多个业务类对应的业务规则集中抽取出相同的规则项；将相同的规则项存储至通用规则集中。
进一步的，所述代码检测模块还包括：接收模块和/或第二获取模块。其中，接收模块用于接收客户端提交的所述源代码文件。第二获取模块用于响应于客户端单个或批量触发的检测事件，获取所述检测事件指向的至少一个欲检测文件，所述至少一个欲检测文件中包含有所述源代码文件。
这里需要说明的是：上述实施例提供的代码检测装置可实现上述图1、图2和图4所示方法实施例中描述的技术方案，上述各模块或单元具体实现的原理可参见上述方法实施例中的相应内容，此处不再赘述。
图9示出了本申请另一实施例提供的代码检测装置的结构示意图。如图9所示，所述代码检测装置包括：
接收模块901，用于接收客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；
解析模块902，用于对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；
检测模块903，用于根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；
反馈模块904，用于将缺陷检测结果反馈至所述客户端。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
进一步的，所述至少一个源代码文件中的各源代码文件均包含有XML文件。相应的，所述解析模块902还用于：将所述XML文件转换为树状结构；获取所述树状结构中属于业务顶级元素的主节点；提取所述主节点的业务内容以及附属于所述主节点的所有子节点的业务内容。
进一步的，所述至少一个源代码文件中的各源代码文件均包含有Java文件。相应的，所述解析模块902还用于：对所述Java文件进行词法及语法解析，得到抽象语法树；遍历所述抽象语法树，以得到所述Java文件中的业务内容。
进一步的，所述业务内容包括：存储在Mapper XML文件中的SQL语句、存储在XML的bean字义、存储在POM文件中的项目基础信息、存储于Java中的业务代码信息及结构信息。
进一步的，所述业务规则集包括：至少一个单文件检测规则项及至少一个多文件检测规则项。相应的，所述检测模块903还用于：根据所述至少一个单文件检测规则项，对所述源代码文件的业务内容进行单文件缺陷检测；根据所述至少一个多文件检测规则项，判定所述源代码文件的业务内容是否属于多文件关联检测类；所述源代码文件的业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息；根据所述至少一个多文件关联代码特征信息，检测所述源代码文件的业务内容是否存在多文件关联缺陷。
进一步的，所述代码检测模块903还包括：
提取模块，用于当所述源代码文件的业务内容不存在多文件关联缺陷时，从源代码文件的业务内容中提取多文件关联检测需要的至少一个业务代码信息；
存储模块，用于将所述至少一个业务代码信息作为多文件关联代码特征信息进行存储。
进一步的，所述检测模块还用于根据全局规则，对所述至少一个源代码文件的业务内容进行缺陷检测。
进一步的，所述代码检测装置还包括获取模块。该获取模块用于获取通用规则集；相应的，所述检测模块还用于：结合所述业务规则集及所述通用规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测。
进一步的，所述检测模块903还用于：分别对所述至少一个源代码文件进行词法及语法缺陷检测。
进一步的，所述代码检测装置还包括：规则配置模块。所述规则配置模块用于：
获取业务类对应的业务数据源；
将所述业务数据源抽象为规则代码模式，以得到规则项；
将所述规则项添加至所述业务类对应的业务规则集中。
其中，所述业务数据源可包括：所述业务类对应的已有代码文件的历史故障信息、缺陷经验信息和/或日志信息。
进一步的，所述规则配置模块还用于从多个业务类对应的业务规则集中抽取出相同的规则项；将相同的规则项存储至通用规则集中。
这里需要说明的是：上述实施例提供的代码检测装置可实现上述图5所示方法实施例中描述的技术方案，上述各模块或单元具体实现的原理可参见上述方法实施例中的相应内容，此处不再赘述。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
图10示出了本申请又一实施例提供的代码检测装置的结构示意图。如图10所示，所述代码检测装置包括：
发送模块1001，用于响应于用户通过客户端界面触发的检测事件，向服务端发送携带至少一个源代码文件的检测请求；
接收模块1002，用于接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
其中，所述检测结果是通过对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，并根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测得到。
进一步的，所述代码检测装置还包括检测触发模块。该检测触发模块用于：
监测到用户通过所述客户端界面进行欲检测文件提交操作时，触发所述检测事件；或者
监听到用户通过所述客户端界面进行的单个或批量文件选择操作时，触发所述检测事件；或者
监听到用户通过所述客户端界面输入指定语音时，触发所述检测事件。
这里需要说明的是：上述实施例提供的代码检测装置可实现上述图6所示方法实施例中描述的技术方案，上述各模块或单元具体实现的原理可参见上述方法实施例中的相应内容，此处不再赘述。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
图11示出了本申请一实施例提供的代码检测系统的结构示意图。如图11所示，所述代码检测系统包括：客户端1101及服务端1102。其中，
客户端1101，用于响应于用户通过客户端界面触发的检测事件，向服务端发送携带有至少一个源代码文件的检测请求；接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
服务端1102，用于接收所述客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；将缺陷检测结果反馈至所述客户端。
本申请实施例提供的技术方案，根据源代码文件所属业务类，对源代码文件进行与业务内容相关的缺陷检测，使得代码检测和业务紧密关联，将代码检测从现有技术只能应用于通用编码规范和错误问题的检测，升级到进行业务内容相关的检测，使代码检测的应用范围得到本质上的提升。
这里需要说明的是：上述实施例提供的代码检测系统中客户端可实现上述图6所示方法实施例中描述的技术方案，服务端可实现上述图1、图2和图4所示方法实施例中描述的技术方案，具体实现的原理可参见上述方法实施例中的相应内容，此处不再赘述。
图12示出了本申请一实施例提供的电子设备的结构示意图。如图12所示，所述电子设备包括：第一存储器1201和第一处理器1202。
第一存储器1201，用于存储计算机程序。除此之外，第一存储器1201，还被配置为存储其它各种数据以支持在服务端设备上的操作。这些数据的示例包括用于在服务端设备上操作的任何应用程序或方法的指令，消息，图片，视频等。
第一存储器1201可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。
第一处理器1202，与第一存储器1201耦合，用于执行所述第一存储器1201中存储的所述程序，以用于：
获取与源代码文件所属业务类匹配的业务规则集；
对所述源代码文件进行业务解析，以解析出所述源代码文件中的业务内容；
根据所述业务规则集，对所述业务内容进行缺陷检测。
其中，第一处理器1202在执行第一存储器1201中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。
进一步，如图12所示，服务端设备还可包括：第一通信组件1203、第一显示器1204、第一电源组件1205、第一音频组件1206等其它组件。图12中仅示意性给出部分组件，并不意味着电子设备只包括图12所示组件。
相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各实施例中与服务器相关的方法步骤或功能。
图13示出了本申请一实施例提供的服务端设备的结构示意图。如图13所示，所述服务端设备包括：第二存储器1301及第二处理器1302。其中，
所述第二存储器1301，用于存储程序。除此之外，第二存储器1301，还被配置为存储其它各种数据以支持在终端设备上的操作。这些数据的示例包括用于在终端设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。
第二存储器1301可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。
所述第二处理器1302，与所述第二存储器1301耦合，用于执行所述第二存储器1301中存储的所述程序，以用于：
接收客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；
对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；
根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；
将缺陷检测结果反馈至所述客户端。
其中，第一处理器1302在执行第一存储器1301中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。
进一步，如图13所示，服务端设备还可包括：第二通信组件1303、第二显示器1304、第二电源组件1305、第二音频组件1306等其它组件。图13中仅示意性给出部分组件，并不意味着服务端设备只包括图13所示组件。
相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各实施例中与服务器相关的方法步骤或功能。
图14示出了本申请一实施例提供的客户端设备的结构示意图。如图14所示，所述客户端设备包括第三存储器1401和第三处理器1402。其中，所述第三存储器1401，用于存储程序；
所述第三处理器1402，与所述第三存储器1401耦合，用于执行所述第三存储器1401中存储的所述程序，以用于：
响应于用户通过客户端界面触发的检测事件，向服务端发送携带至少一个源代码文件的检测请求；
接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
其中，所述检测结果是通过对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，并根据所述至少一个源代码文件所属业务类对应的业务规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测得到。
其中，第三处理器1402在执行第三存储器1401中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。
进一步，如图14所示，服务端设备还可包括：第三通信组件1403、第三显示器1404、第三电源组件1405、第三音频组件1406等其它组件。图14中仅示意性给出部分组件，并不意味着客户端设备只包括图14所示组件。
相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各实施例中与服务器相关的方法步骤或功能。
在图12、图13和图14中的通信组件，可被配置为便于通信组件所属设备和其他设备之间有线或无线方式的通信。通信组件所属设备可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。
在图12、图13和图14中的显示器，可以包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。
在图12、图13和图14中的电源组件，为电源组件所属设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所属设备生成、管理和分配电力相关联的组件。
在图12、图13和图14中的音频组件，被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(MIC)，当音频组件所属设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台电子设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。
Claims (30)
1.一种代码检测方法，其特征在于，包括：
获取与源代码文件所属业务类匹配的业务规则集，所述业务规则集包括至少一个单文件检测规则项及至少一个多文件检测规则项；
对所述源代码文件进行业务解析，以解析出所述源代码文件中的业务内容；
根据所述至少一个单文件检测规则项，对所述业务内容进行单文件缺陷检测；
根据所述至少一个多文件检测规则项，判定所述业务内容是否属于多文件关联检测类；
在所述业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息，并根据所述至少一个多文件关联代码特征信息，检测所述业务内容是否存在多文件关联缺陷。
2.根据权利要求1所述的方法，其特征在于，所述源代码文件包含可扩展标记语言XML文件；以及
对所述XML文件进行业务解析，以解析出所述XML文件中的业务内容，包括：
将所述XML文件转换为树状结构；
获取所述树状结构中属于业务顶级元素的主节点；
提取所述主节点的业务内容以及附属于所述主节点的所有子节点的业务内容。
3.根据权利要求1所述的方法，其特征在于，所述源代码文件包含Java文件；以及
对所述Java文件进行业务解析，以解析出所述Java文件中的业务内容，包括：
对所述Java文件进行词法及语法解析，得到抽象语法树；
遍历所述抽象语法树，以得到所述Java文件中的业务内容。
4.根据权利要求1至3中任一项所述的方法，其特征在于，所述业务内容包括：存储在Mapper XML文件中的结构化查询语言SQL语句、存储在XML文件中的bean字义、存储在项目对象模型POM文件中的项目基础信息、存储于Java中的业务代码信息及结构信息。
5.根据权利要求1所述的方法，其特征在于，还包括：
若所述业务内容不存在多文件关联缺陷，则从所述业务内容中提取多文件关联缺陷检测需要的至少一个业务代码信息；
将所述至少一个业务代码信息作为多文件关联代码特征信息进行存储。
6.根据权利要求1所述的方法，其特征在于，还包括：
根据全局规则，对自所述源代码文件及与所述源代码文件同批次触发的所有文件中解析出的业务内容进行缺陷检测。
7.根据权利要求1至3中任一项所述的方法，其特征在于，还包括：
检测结果为存在缺陷时，记录存在缺陷的业务内容；
根据所述存在缺陷的业务内容生成缺陷报告。
8.根据权利要求1至3中任一项所述的方法，其特征在于，还包括：
获取通用规则集；
结合所述业务规则集及所述通用规则集，对所述业务内容进行缺陷检测。
9.根据权利要求1至3中任一项所述的方法，其特征在于，还包括：
对所述源代码文件进行词法及语法缺陷检测。
10.根据权利要求1至3中任一项所述的方法，其特征在于，还包括：
获取业务类对应的业务数据源；
将所述业务数据源抽象为规则代码模式，以得到规则项；
将所述规则项添加至所述业务类对应的业务规则集中。
11.根据权利要求10所述的方法，其特征在于，所述业务数据源包括：所述业务类对应的已有代码文件的历史故障信息、缺陷经验信息和/或日志信息。
12.根据权利要求10所述的方法，其特征在于，还包括：
从多个业务类对应的业务规则集中抽取出相同的规则项；
将相同的规则项存储至通用规则集中。
13.根据权利要求1至3中任一项所述的方法，其特征在于，还包括：
接收客户端提交的所述源代码文件；或者
响应于客户端单个或批量触发的检测事件，获取所述检测事件指向的至少一个欲检测文件，所述至少一个欲检测文件中包含有所述源代码文件。
14.一种代码检测方法，其特征在于，包括：
接收客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；
对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；
根据所述至少一个源代码文件所属业务类对应的业务规则集所包含的至少一个单文件检测规则项及至少一个多文件检测规则项，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；
将缺陷检测结果反馈至所述客户端；
其中，根据所述至少一个单文件检测规则项及所述至少一个多文件检测规则项，对所述至少一个源代码文件中的一个源代码文件的业务内容进行缺陷检测，包括：根据所述至少一个单文件检测规则项，对所述源代码文件的业务内容进行单文件缺陷检测；根据所述至少一个多文件检测规则项，判定所述源代码文件的业务内容是否属于多文件关联检测类；在所述源代码文件的业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息，并根据所述至少一个多文件关联代码特征信息，检测所述源代码文件的业务内容是否存在多文件关联缺陷。
15.根据权利要求14所述的方法，其特征在于，所述至少一个源代码文件中的各源代码文件均包含有可扩展标记语言XML文件；以及
对所述XML文件进行业务解析，以解析出所述XML文件中的业务内容，包括：
将所述XML文件转换为树状结构；
获取所述树状结构中属于业务顶级元素的主节点；
提取所述主节点的业务内容以及附属于所述主节点的所有子节点的业务内容。
16.根据权利要求14所述的方法，其特征在于，所述至少一个源代码文件中的各源代码文件均包含有Java文件；以及
对所述Java文件进行业务解析，以解析出所述Java文件中的业务内容，包括：
对所述Java文件进行词法及语法解析，得到抽象语法树；
遍历所述抽象语法树，以得到所述Java文件中的业务内容。
17.根据权利要求14至16中任一项所述的方法，其特征在于，所述业务内容包括：存储在Mapper XML文件中的结构化查询语言SQL语句、存储在XML文件中的bean字义、存储在项目对象模型POM文件中的项目基础信息、存储于Java中的业务代码信息及结构信息。
18.根据权利要求14所述的方法，其特征在于，还包括：
若所述源代码文件的业务内容不存在多文件关联缺陷，则从源代码文件的业务内容中提取多文件关联检测需要的至少一个业务代码信息；
将所述至少一个业务代码信息作为多文件关联代码特征信息进行存储。
19.根据权利要求14至16中任一项所述的方法，其特征在于，还包括：
根据全局规则，对所述至少一个源代码文件的业务内容进行缺陷检测。
20.根据权利要求15所述的方法，其特征在于，还包括：
获取通用规则集；以及
根据所述至少一个源代码文件所属业务类对应的业务规则集所包含的至少一个单文件检测规则项及至少一个多文件检测规则项，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测，包括：
结合所述业务规则集所包含的至少一个单文件检测规则项及至少一个多文件检测规则项以及所述通用规则集，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测。
21.根据权利要求14至16中任一项所述的方法，其特征在于，还包括：
分别对所述至少一个源代码文件进行词法及语法缺陷检测。
22.根据权利要求14至16中任一项所述的方法，其特征在于，还包括：
获取业务类对应的业务数据源；
将所述业务数据源抽象为规则代码模式，以得到规则项；
将所述规则项添加至所述业务类对应的业务规则集中。
23.根据权利要求22所述的方法，其特征在于，所述业务数据源包括：所述业务类对应的已有代码文件的历史故障信息、缺陷经验信息和/或日志信息。
24.根据权利要求22所述的方法，其特征在于，还包括：
从多个业务类对应的业务规则集中抽取出相同的规则项；
将相同的规则项存储至通用规则集中。
25.一种代码检测方法，其特征在于，包括：
响应于用户通过客户端界面触发的检测事件，向服务端发送携带至少一个源代码文件的检测请求；
接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
其中，所述检测结果是通过对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，并根据所述至少一个源代码文件所属业务类对应的业务规则集所包含的至少一个单文件检测规则项及至少一个多文件检测规则项，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测得到；
根据所述至少一个单文件检测规则项及所述至少一个多文件检测规则项，对所述至少一个源代码文件中的一个源代码文件的业务内容进行缺陷检测，包括：根据所述至少一个单文件检测规则项，对所述源代码文件的业务内容进行单文件缺陷检测；根据所述至少一个多文件检测规则项，判定所述源代码文件的业务内容是否属于多文件关联检测类；在所述源代码文件的业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息，并根据所述至少一个多文件关联代码特征信息，检测所述源代码文件的业务内容是否存在多文件关联缺陷。
26.根据权利要求25所述的方法，其特征在于，还包括：
监测到用户通过所述客户端界面进行欲检测文件提交操作时，触发所述检测事件；或者
监听到用户通过所述客户端界面进行的单个或批量文件选择操作时，触发所述检测事件；或者
监听到用户通过所述客户端界面输入指定语音时，触发所述检测事件。
27.一种代码检测系统，其特征在于，包括：
客户端，用于响应于用户通过客户端界面触发的检测事件，向服务端发送携带有至少一个源代码文件的检测请求；接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
服务端，用于接收所述客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；根据所述至少一个源代码文件所属业务类对应的业务规则集所包含的至少一个单文件检测规则项及至少一个多文件检测规则项，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；将缺陷检测结果反馈至所述客户端；
其中，根据所述至少一个单文件检测规则项及所述至少一个多文件检测规则项，对所述至少一个源代码文件中的一个源代码文件的业务内容进行缺陷检测，包括：根据所述至少一个单文件检测规则项，对所述源代码文件的业务内容进行单文件缺陷检测；根据所述至少一个多文件检测规则项，判定所述源代码文件的业务内容是否属于多文件关联检测类；在所述源代码文件的业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息，并根据所述至少一个多文件关联代码特征信息，检测所述源代码文件的业务内容是否存在多文件关联缺陷。
28.一种电子设备，其特征在于，包括：第一存储器和第一处理器，其中，
所述第一存储器，用于存储程序；
所述第一处理器，与所述第一存储器耦合，用于执行所述第一存储器中存储的所述程序，以用于：
获取与源代码文件所属业务类匹配的业务规则集，所述业务规则集包括至少一个单文件检测规则项及至少一个多文件检测规则项；
对所述源代码文件进行业务解析，以解析出所述源代码文件中的业务内容；
根据所述至少一个单文件检测规则项，对所述业务内容进行单文件缺陷检测；
根据所述至少一个多文件检测规则项，判定所述业务内容是否属于多文件关联检测类；
在所述业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息，并根据所述至少一个多文件关联代码特征信息，检测所述业务内容是否存在多文件关联缺陷。
29.一种服务端设备，其特征在于，包括：第二存储器和第二处理器，其中，
所述第二存储器，用于存储程序；
所述第二处理器，与所述第二存储器耦合，用于执行所述第二存储器中存储的所述程序，以用于：
接收客户端发送的代码检测请求，所述代码检测请求中携带有至少一个源代码文件；
对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容；
根据所述至少一个源代码文件所属业务类对应的业务规则集所包含的至少一个单文件检测规则项及至少一个多文件检测规则项，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测；
将缺陷检测结果反馈至所述客户端；
其中，根据所述至少一个单文件检测规则项及所述至少一个多文件检测规则项，对所述至少一个源代码文件中的一个源代码文件的业务内容进行缺陷检测，包括：根据所述至少一个单文件检测规则项，对所述源代码文件的业务内容进行单文件缺陷检测；根据所述至少一个多文件检测规则项，判定所述源代码文件的业务内容是否属于多文件关联检测类；在所述源代码文件的业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息，并根据所述至少一个多文件关联代码特征信息，检测所述源代码文件的业务内容是否存在多文件关联缺陷。
30.一种客户端设备，其特征在于，包括：第三存储器和第三处理器，其中，
所述第三存储器，用于存储程序；
所述第三处理器，与所述第三存储器耦合，用于执行所述第三存储器中存储的所述程序，以用于：
响应于用户通过客户端界面触发的检测事件，向服务端发送携带至少一个源代码文件的检测请求；
接收所述服务端反馈的检测结果，并在所述客户端界面上显示所述检测结果；
其中，所述检测结果是通过对所述至少一个源代码文件进行业务解析，以解析出各源代码文件中的业务内容，并根据所述至少一个源代码文件所属业务类对应的业务规则集所包含的至少一个单文件检测规则项及至少一个多文件检测规则项，分别对所述至少一个源代码文件各自的业务内容进行缺陷检测得到；
根据所述至少一个单文件检测规则项及所述至少一个多文件检测规则项，对所述至少一个源代码文件中的一个源代码文件的业务内容进行缺陷检测，包括：根据所述至少一个单文件检测规则项，对所述源代码文件的业务内容进行单文件缺陷检测；根据所述至少一个多文件检测规则项，判定所述源代码文件的业务内容是否属于多文件关联检测类；在所述源代码文件的业务内容属于多文件关联检测类时，获取至少一个多文件关联代码特征信息，并根据所述至少一个多文件关联代码特征信息，检测所述源代码文件的业务内容是否存在多文件关联缺陷。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711242297.2A CN109857630B (zh) | 2017-11-30 | 2017-11-30 | 代码检测方法、系统及设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711242297.2A CN109857630B (zh) | 2017-11-30 | 2017-11-30 | 代码检测方法、系统及设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109857630A CN109857630A (zh) | 2019-06-07 |
| CN109857630B true CN109857630B (zh) | 2022-08-02 |
Family
ID=66888644
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711242297.2A Active CN109857630B (zh) | 2017-11-30 | 2017-11-30 | 代码检测方法、系统及设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109857630B (zh) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110765003B (zh) * | 2019-09-24 | 2023-06-02 | 贝壳技术有限公司 | 代码检测方法、装置以及设备、存储介质 |
| CN110928780B (zh) * | 2019-11-19 | 2023-12-15 | 深圳前海环融联易信息科技服务有限公司 | 一种代码质量控制方法、装置、计算机设备及存储介质 |
| CN111176993A (zh) * | 2019-12-24 | 2020-05-19 | 中国科学院电子学研究所苏州研究院 | 一种基于抽象语法树的代码静态检测方法 |
| CN111782737A (zh) * | 2020-08-12 | 2020-10-16 | 中国工商银行股份有限公司 | 信息处理方法、装置、设备及存储介质 |
| CN112231337A (zh) * | 2020-10-20 | 2021-01-15 | 中国建设银行股份有限公司 | Sas语句的检测装置及方法、电子设备及存储介质 |
| CN112860265B (zh) * | 2021-03-31 | 2024-02-09 | 中国工商银行股份有限公司 | 一种源代码数据库操作异常检测方法及装置 |
| CN113342687B (zh) * | 2021-07-01 | 2022-09-09 | 厦门极致互动网络技术股份有限公司 | 一种批量检测代码规范的方法 |
| CN113609004B (zh) * | 2021-07-17 | 2023-11-03 | 深圳开源互联网安全技术有限公司 | 一种静态代码检测方法和系统 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102339252A (zh) * | 2011-07-25 | 2012-02-01 | 大连理工大学 | 基于xml中间模型以及缺陷模式匹配的静态检测系统 |
| CN104023025A (zh) * | 2014-06-13 | 2014-09-03 | 中国民航信息网络股份有限公司 | 基于业务规则的网站安全漏洞检测方法及装置 |
| EP3001312A1 (en) * | 2014-09-26 | 2016-03-30 | German Research School for Simulation Sciences GmbH | Method, device and computer program product for detecting data dependencies within a program |
| CN106372511A (zh) * | 2016-08-24 | 2017-02-01 | 北京奇虎测腾安全技术有限公司 | 一种源代码检测系统及方法 |
-
2017
- 2017-11-30 CN CN201711242297.2A patent/CN109857630B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102339252A (zh) * | 2011-07-25 | 2012-02-01 | 大连理工大学 | 基于xml中间模型以及缺陷模式匹配的静态检测系统 |
| CN104023025A (zh) * | 2014-06-13 | 2014-09-03 | 中国民航信息网络股份有限公司 | 基于业务规则的网站安全漏洞检测方法及装置 |
| EP3001312A1 (en) * | 2014-09-26 | 2016-03-30 | German Research School for Simulation Sciences GmbH | Method, device and computer program product for detecting data dependencies within a program |
| CN106372511A (zh) * | 2016-08-24 | 2017-02-01 | 北京奇虎测腾安全技术有限公司 | 一种源代码检测系统及方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109857630A (zh) | 2019-06-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109857630B (zh) | 代码检测方法、系统及设备 | |
| US10353807B2 (en) | Application development management | |
| US9424115B2 (en) | Analysis engine for automatically analyzing and linking error logs | |
| US8473916B2 (en) | Method and system for providing a testing framework | |
| US20140053138A1 (en) | Quality on submit process | |
| US10671613B2 (en) | Data source binding using an OData model | |
| US20190005111A1 (en) | Relational log entry instituting system | |
| US20120204160A1 (en) | Managing Non-Common Features for Program Code Translation | |
| US20130055117A1 (en) | User interface validation assistant | |
| CN110955428A (zh) | 一种页面显示方法、装置、电子设备及介质 | |
| CN109471768B (zh) | 业务问题的监控方法、装置以及电子设备 | |
| US10628584B1 (en) | Functional language source code vulnerability scanner | |
| CN105095074B (zh) | 配置文件的升级测试方法和装置 | |
| CN111159016A (zh) | 一种规范检测方法及装置 | |
| US11816479B2 (en) | System and method for implementing a code audit tool | |
| CN106713011B (zh) | 一种获取测试数据的方法与系统 | |
| US10983782B1 (en) | User interface upgrade analyzer | |
| US9678856B2 (en) | Annotated test interfaces | |
| CN114185791A (zh) | 一种数据映射文件的测试方法、装置、设备及存储介质 | |
| US9104573B1 (en) | Providing relevant diagnostic information using ontology rules | |
| CN110321278B (zh) | 系统测试方法及装置、计算机设备、存储介质 | |
| CN110780894B (zh) | 热升级处理方法、装置及电子设备 | |
| CN110334031A (zh) | 内存分配代码检测方法、装置、计算机设备及存储介质 | |
| US11740995B2 (en) | Source quality check service | |
| US11803609B2 (en) | Method and system for navigation control to select a target page from possible target pages |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |