CN117435502A - 软件质量检测方法、系统和存储介质 - Google Patents

软件质量检测方法、系统和存储介质 Download PDF

Info

Publication number
CN117435502A
CN117435502A CN202311575155.3A CN202311575155A CN117435502A CN 117435502 A CN117435502 A CN 117435502A CN 202311575155 A CN202311575155 A CN 202311575155A CN 117435502 A CN117435502 A CN 117435502A
Authority
CN
China
Prior art keywords
function
software
index
obtaining
quality detection
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.)
Pending
Application number
CN202311575155.3A
Other languages
English (en)
Inventor
王斌
刘建
李寒霜
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jiangsu XCMG Guozhong Laboratory Technology Co Ltd
Original Assignee
Jiangsu XCMG Guozhong Laboratory Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Jiangsu XCMG Guozhong Laboratory Technology Co Ltd filed Critical Jiangsu XCMG Guozhong Laboratory Technology Co Ltd
Priority to CN202311575155.3A priority Critical patent/CN117435502A/zh
Publication of CN117435502A publication Critical patent/CN117435502A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

本公开提供了一种软件质量检测方法、系统和存储介质，涉及软件设计领域。该方法包括：对软件程序源码进行分析，构建控制流图、过程级调用图和文件级调用图；根据软件程序源码、控制流图、过程级调用图和文件级调用图，提取多个度量元；根据多个度量元，利用多个测量函数，得到与软件质量检测相关的内在指标和外在指标；以及根据内在指标和外在指标，对软件质量进行检测。本公开提高了软件质量检测的通用性、准确性以及全面评估性。

Description

软件质量检测方法、系统和存储介质
技术领域
本公开涉及软件设计领域，尤其涉及一种软件质量检测方法、系统和存储介质。
背景技术
软件设计质量评估技术研究，一直是软件工程发展的核心关注点，也是软件开发的关键步骤，还是软件需求和软件实现的桥梁。软件设计质量的好坏，直接影响最终开发出来的软件产品质量的好坏。高质量的软件设计一方面能很好地满足用户的功能需求和非功能需求，另一方面使得后续的软件实现更加高效高质。反之，低质量的软件设计可能导致的直接后果是最终开发出来的软件产品不满足用户的需求，甚至还会带来一些严重的质量问题，例如功能错误、性能差、存在安全风险、难以维护和扩展等。通过软件设计质量评估，开发团队可以更好地理解、评估和改进他们的软件设计，保证最终产品的质量。
软件设计质量评估领域是软件工程领域中的一个重要分支，随着软件技术的发展和应用的普及，软件设计质量评估技术也在不断演化和进步。软件设计质量评估始于软件工程的早期阶段。在20世纪70年代和80年代，软件工程的先驱们开始关注如何设计出更好质量的软件。早期的方法主要集中在软件结构、模块化和设计原则，如结构化设计和面向对象设计。在20世纪80年代末和90年代初，引入了质量模型，如ISO 9126，用于定义和度量软件质量的不同方面，如功能性、可维护性、性能等。这些模型为软件设计质量评估提供了一种系统的方法。随着计算机技术的进步，出现了许多自动化工具和静态分析工具，用于分析和评估软件设计的质量。这些工具可以检测代码质量问题、潜在的错误和性能瓶颈，帮助开发人员更早地发现和修复问题。
敏捷开发方法的兴起改变了软件设计质量评估的方式。敏捷方法强调快速迭代和反馈，使得质量评估成为开发过程的一部分，而不是后期的活动。持续集成和持续交付(CI/CD)实践也促使了质量评估的自动化和集成。随着人工智能技术的发展，机器学习和人工智能被用于软件设计质量评估，例如通过自动化代码审查、缺陷检测和性能分析。这些技术可以加速和改进质量评估过程。总的来说，软件设计质量评估领域随着软件工程的发展和新技术的出现不断演进。它从最初的结构化设计和质量模型发展到了自动化工具、敏捷开发、DevOps(Development+Operations，开发+运维)、机器学习等现代技术的整合。这个领域的目标是确保开发出高质量、可维护和安全的软件，以满足不断变化的用户需求和市场要求。
发明内容
本公开要解决的一个技术问题是，提供一种软件质量检测方法、系统和存储介质，能够提高软件质量检测的通用性和全面性。
根据本公开一方面，提出一种软件质量检测方法，包括：对软件程序源码进行分析，构建控制流图、过程级调用图和文件级调用图；根据软件程序源码、控制流图、过程级调用图和文件级调用图，提取多个度量元；根据多个度量元，利用多个测量函数，得到与软件质量检测相关的内在指标和外在指标；以及根据内在指标和外在指标，对软件质量进行检测。
在一些实施例中，构建控制流图包括：根据软件程序源码，生成中间控制流图；以及利用软件程序源码，对中间控制流图中的节点内容进行替换，并在中间控制流图中的边上增加转换控制条件，以生成控制流图。
在一些实施例中，构建过程级调用图包括：根据软件程序源码，构建抽象语法树；在抽象语法树中，查找函数声明节点以获取每个函数的函数声明信息，以及查找函数调用节点以获取每个函数的函数调用信息；根据每个函数的函数声明信息，构建每个函数的唯一标识；根据每个函数的唯一标识，构建每个函数节点；以及根据每个函数节点以及每个函数的函数调用信息，构建过程级调用图。
在一些实施例中，构建文件级调用图包括：根据过程级调用图中的属于同一文件的函数节点，得到文件节点；根据文件节点中每个函数的函数调用信息，得到文件调用信息；以及根据文件调用信息，构建文件级调用图。
在一些实施例中，多个度量元包括软件中的第一函数数量、包含注释的第二函数数量、每个函数的出度和入度、接口数量、存在坏味道的第三函数数量以及文件数量中的一种或多种。
在一些实施例中，内在指标包括可修改性指标、可扩展性指标、易测试性指标、可替换性指标、易理解性指标中的至少一项；以及外在指标包括坏味率指标和缺陷率中的至少一项。
在一些实施例中，得到可修改性指标包括：根据每个函数的出度和入度之和，得到每个函数关联其他函数的数量；以及根据每个函数关联其他函数的数量之和，与第一函数数量，得到可修改性指标。
在一些实施例中，得到可扩展性指标包括：根据接口数量与第一函数数量的比值，得到可扩展性指标。
在一些实施例中，得到易测试性指标包括：将每个函数的出度进行加和，得到测试所有函数需要调用其他函数的个数；以及根据测试所有函数需要调用其他函数的个数，与第一函数数量，得到易测试性指标。
在一些实施例中，得到可替换性指标包括：根据每个函数的入度，得到每个函数的可替换性；以及根据每个函数的可替换性之和，与第一函数数据，得到可替换性指标。
在一些实施例中，得到易理解性指标包括：根据第二函数数量与第一函数数量的比值，得到易理解性指标。
在一些实施例中，得到坏味率指标包括：根据第三函数数量与第一函数数量的比值，得到坏味率指标。
在一些实施例中，缺陷率包括千行代码缺陷率、缺陷密度、文件通过率以及函数通过率中的至少一项。
在一些实施例中，获取缺陷检测结果，其中，得到缺陷率包括以下至少一项：根据缺陷检测结果中的缺陷数量，得到千行代码缺陷率；根据缺陷检测结果中的每种类型的缺陷数量以及每种类型的权重，得到缺陷密度；根据缺陷检测结果中的含有缺陷的文件数量，与文件数量的比值，得到文件缺陷率；以及根据缺陷检测结果中的含有缺陷的函数数量，与第一函数数量的比值，得到函数缺陷率。
在一些实施例中，提取多个度量元包括：根据软件程序源码，获取第一函数数量和第二函数数量；根据过程级调用图，获取每个函数的出度和入度；根据文件级调用图，获取接口数量以及文件数量；以及根据软件程序源码、控制流图、过程级调用图和文件级调用图，获取第三函数数量。
在一些实施例中，根据软件程序源码，提取多个度量元包括：基于AST-Matcher规则，对软件程序源码进行信息提取，得到多个度量元。
根据本公开的另一方面，还提出一种软件质量检测系统，包括：设计恢复模块，被配置为对软件程序源码进行分析，构建控制流图、过程级调用图和文件级调用图；信息提取模块，被配置为根据软件程序源码、控制流图、过程级调用图和文件级调用图，提取多个度量元；指标获取模块，被配置为根据多个度量元，利用多个测量函数，得到与软件质量检测相关的内在指标和外在指标；以及质量检测模块，被配置为根据内在指标和外在指标，对软件质量进行检测。
根据本公开的另一方面，还提出一种软件质量检测系统，包括：存储器；以及耦接至存储器的处理器，处理器被配置为基于存储在存储器的指令执行如上述的软件质量检测方法。
根据本公开的另一方面，还提出一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现如上述的软件质量检测方法。
本公开实施例中，无需利用特定的SRE工具，即可实现软件设计结构的识别，然后通过源码以及软件设计结构提取软件质量检测相关的内在指标和外在指标，通过内外两个指标对软件质量进行全面评估，提高了软件质量检测的通用性和全面评估性。
通过以下参照附图对本公开的示例性实施例的详细描述，本公开的其它特征及其优点将会变得清楚。
附图说明
构成说明书的一部分的附图描述了本公开的实施例，并且连同说明书一起用于解释本公开的原理。
参照附图，根据下面的详细描述，可以更加清楚地理解本公开，其中：
图1为本公开的软件质量检测方法的一些实施例的流程示意图；
图2为本公开的软件质量检测方法的另一些实施例的流程示意图；
图3为本公开的软件质量检测方法的另一些实施例的流程示意图；
图4为本公开的软件质量检测方法的另一些实施例的流程示意图；
图5为本公开的软件质量检测系统的一些实施例的结构示意图；
图6为本公开的软件质量检测系统的另一些实施例的结构示意图。
具体实施方式
现在将参照附图来详细描述本公开的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。
同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本公开及其应用或使用的任何限制。
对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。
在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。
应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。
相关技术中，根据类表示(例如UML类图)生成的源代码的预期质量评估方法的使用前提是，完整正确的类表示，但对于实际情况下，完整、正确的UML图等几乎难以获得，因此该方法实用性存疑。而从调用关系出发分析评估软件质量存在一定的片面性，无法充分利用源码信息进行全方位的评估。通过特定SRE(Software Reverse Engineering，软件逆向工程)工具的进行软件质量评估方法，如果这些特定SRE工具不可用或不适用于特定的软件系统，则无法有效地收集静态内聚数据，另外，关注于内聚性的评估，可能会在其他软件质量属性上有所忽视，适用范围较小。
下面将对质量模型、静态代码分析和软件逆向工程进行相应解释。
软件设计质量评估中的质量模型是一种系统性方法，用于定义、度量和评估软件的各个质量方面。这些模型帮助开发团队和利益相关者明确软件应具备的质量属性，以便确保软件在设计和实现阶段满足这些要求。一个广泛使用的质量模型是ISO 25010，它定义了软件质量的多个方面。ISO 25010质量模型将软件质量分为两个主要类别：内部质量和外部质量。其中内部质量指软件内部特征的质量，通常只在软件开发和测试过程中可见。而外部质量是用户能够观察和体验的软件特征的质量。这些内部质量和外部质量子特性可以进一步细分为更具体的特征和标准，以帮助开发团队更精细地评估和改进软件设计的质量。质量模型提供了一个通用的框架，可以根据项目和组织的需求来制定具体的质量目标和指标，并在开发过程中持续监测和评估软件的质量。这有助于确保软件在满足用户需求、性能、可维护性和安全性等方面达到预期的水平。
静态代码分析是软件设计质量评估中的一项重要技术，它通过分析源代码的文本而不需要运行程序来识别潜在问题、错误和缺陷。这种分析可以帮助开发团队在代码执行之前发现问题，以提高软件的质量、可维护性和可靠性。静态代码分析有助于确保代码符合编码标准和合规性要求，并且分析工具可以自动运行，提高了效率，尤其是对于大型代码库。静态代码分析也存在一定的限制，静态代码分析不能完全替代人工代码审查和测试，因为它无法捕捉所有类型的问题。静态代码分析工具可能会产生误报(虚警)，需要人工验证和修复。
软件逆向工程是指将已有的软件系统、程序或者组件进行解析和分析，以获取其内部结构、算法、设计原理等信息的过程。逆向工程通常用于理解、审查、改进或者重新设计软件，也可以用于发现和修复软件中的缺陷或安全漏洞。
图1为本公开的软件质量检测方法的一些实施例的流程示意图。
在步骤110，对软件程序源码进行分析，构建控制流图、过程级调用图和文件级调用图。
在一些实施例中，该软件程序源码为C语言、C++语言及C和C++混源软件源码。
在一些实施例中，对软件程序源码进行分析，识别程序设计结构，例如，包括顺序结构、各种选择结构、各种循环结构等，进而构建出控制流图(Control Flow Graph，CFG)以及调用图(Call Graph，CG)，该调用图包括过程级调用图(Procedure-Level Call Graph，PLCG)和文件级调用图(File-Level Call Graph，FLCG)。
在一些实施例中，控制流图是一个有向图G＝(V，E)，其中V是顶点的集合，E是有向边的集合。在控制流图中，每个顶点代表一个基本块，该基本块是具有一个入口点(执行的第一条指令)和一个出口点(执行最后一条指令)的程序指令的线性序列，有向边显示控制流路径。
在一些实施例中，调用图是表示一个软件系统中子程序之间的调用关系。每个节点表示一个过程，每条边(f,g)表示过程f调用过程g。在过程级调用图中，每个节点表示C程序中的一个函数，边表示函数之间的调用关系。在文件级调用图中，每个节点表示C语言项目中的一个文件，边表示两个文件之间存在的调用关系。
在步骤120，根据软件程序源码、控制流图、过程级调用图和文件级调用图，提取多个度量元。
在一些实施例中，基于AST-Matcher规则，对软件程序源码进行信息提取，得到多个度量元。基于AST-Matcher规则实现源码信息提取，其核心是对软件程序源码的不同信息编写通的查询规则，提高了模型实例化的准确性以及逆向工程的准确性，进而提高了后续评估结果的可靠性，减少了可能的误差和误差率。
在一些实施例中，基于源码恢复的控制流图、过程级调用图和文件级调用图，提取设计图信息。
在一些实施例中，多个度量元包括软件中的第一函数数量、包含注释的第二函数数量、每个函数的出度和入度、接口数量、存在坏味道的第三函数数量以及文件数量等。
例如，根据软件程序源码，获取第一函数数量和第二函数数量；根据过程级调用图，获取每个函数的出度和入度；根据文件级调用图，获取接口数量以及文件数量；以及根据软件程序源码、控制流图、过程级调用图和文件级调用图，获取第三函数数量。
在步骤130，根据多个度量元，利用多个测量函数，得到与软件质量检测相关的内在指标和外在指标。
在一些实施例中，从内外两个方面来评估软件设计质量，内在指标是指设计结构层面(Structural Level)的指标，包括设计与代码的协同能力和设计适应演进活动的能力；外在指标是指设计行为表现层面(Behavioral Level)的指标，是对设计的表现的度量。
例如，内在指标包括可修改性指标、可扩展性指标、易测试性指标、可替换性指标、易理解性指标等，外在指标包括坏味率指标和缺陷率等。
在步骤140，根据内在指标和外在指标，对软件质量进行检测。
该步骤中，通过内外两个方面全面评估软件设计质量。在评估的基础上，判断软件设计是否符合预期的质量标准，如果不符合则进行软件设计重构。
针对不同的项目，可以选择不同的指标，来判断软件质量是否合格。例如，若可修改性指标、可扩展性指标、易测试性指标、可替换性指标、易理解性指标、坏味率指标和缺陷率中至少一项不满足项目要求，则说明该软件质量不合格，此时，可以对软件设计进行重构，这样，不仅能够帮助了解和分析现有项目的设计，还为改进和优化软件设计提供了有力的指导。
在上述实施例中，无需利用特定的SRE工具，即可实现软件设计结构的识别，然后通过源码以及软件设计结构提取软件质量检测相关的内在指标和外在指标，通过内外两个指标对软件质量进行全面评估，提高了软件质量检测的通用性和全面评估性。
图2为本公开的软件质量检测方法的另一些实施例的流程示意图。
在步骤210，根据软件程序源码，生成中间控制流图。
在一些实施例中，使用Clang的CFG生成工具对软件程序源码进行分析，生成中间控制流图，该中间控制流图为编译器的符号标识，需要经过处理变成源码级别的控制流图。
在步骤220，利用软件程序源码，对中间控制流图中的节点内容进行替换，并在中间控制流图中的边上增加转换控制条件，以生成控制流图。
该步骤中，对中间控制流图的节点中的信息进行处理，使用源码替换节点的内容，最后在中间控制流图中添加分支条件，从而实现了控制流图的恢复，该实现过程不受特定SRE工具的限制，通用性更强，无需关注软件使用的开发工具和环境，能够适用于更广泛的软件系统。
图3为本公开的软件质量检测方法的另一些实施例的流程示意图。
在步骤310，根据软件程序源码，构建抽象语法树。
在一些实施例中，通过Clang构建抽象语法树。
在步骤320，在抽象语法树中，查找函数声明节点以获取每个函数的函数声明信息，以及查找函数调用节点以获取每个函数的函数调用信息。
在一些实施例中，使用ASTMatcher在抽象语法树中，查找函数声明节点和函数调用节点。该步骤中，对软件程序源码的不同信息编写不同的查询规则，进而能够获取函数声明信息以及函数调用信息，能够提高模型实例化的准确性，提高后续评估结果的可靠性，减少了可能的误差和误差率。
在步骤330，根据每个函数的函数声明信息，构建每个函数的唯一标识。
在一些实施例中，唯一标识例如为文件名+函数名。
在步骤340，根据每个函数的唯一标识，构建每个函数节点。
在步骤350，根据每个函数节点以及每个函数的函数调用信息，构建过程级调用图。
在该实施例中，无需利用特定的SRE工具，即可实现过程级调用图的构建。
图4为本公开的软件质量检测方法的另一些实施例的流程示意图。
在步骤410，根据过程级调用图中的属于同一文件的函数节点，得到文件节点。
过程级调用图为细粒度调用图，文件级调用图为粗粒度调用图，过程级调用图中包含多个函数节点，按照文件粒度进行分析，得到文件节点。
在步骤420，根据文件节点中每个函数的函数调用信息，得到文件调用信息。
在步骤430，根据文件调用信息，构建文件级调用图。
在该实施例中，无需利用特定的SRE工具，即可实现文件级调用图的构建。
上述实施例中，不需要项目提供相关的设计图信息，而是利用软件程序源码，构建控制流图、过程级调用图和文件级调用图，提高了恢复出的软件设计的完整性与正确性，并且便于全方位评估软件设计质量。
本公开一些实施例中，不仅可以评估设计结构层面的质量，还可以评估设计行为表现层面的质量。在软件质量评估的计算中，将所有指标的粒度设定在函数级别。全面地审查软件设计，从而提供了更全面、更全面的评估。
在一些实施例中，根据每个函数的出度和入度之和，得到每个函数关联其他函数的数量；根据每个函数关联其他函数的数量之和，与第一函数数量，得到可修改性指标。
例如，利用函数得到可修改性指标X1，其中，ODi为函数i的出度，i为自然数，IDi为函数i的入度，N为软件中函数的数量，即第一函数数量。ODi+IDi计算的是一个函数在调用图中关联的函数之和，如果该函数关联的其他函数越多，修改需要考虑的对其他函数影响越大，认为修改越困难。/>考虑的是整个系统所有函数的平均值，该值越小说明系统函数可修改性越好，1-/>的值越大系统函数的可修改性越好。
该实施例中，可修改性指标度量对该软件设计进行修改的难度，特指对软件改正和改进活动实施的难度，指标值越高，实施难度越低。
在一些实施例中，根据接口数量与第一函数数量的比值，得到可扩展性指标。
例如，利用函数得到可扩展性指标X2，其中，NAPI为软件中API(Application Programming Interface，应用程序编程接口)的数量，N为软件中函数的数量。该实施例中，API数量占比越大，系统对外的可扩展性越好。
该实施例中，可扩展性指标度量对该软件设计进行扩展的难度，指标值越高，扩展难度越低。
在一些实施例中，将每个函数的出度进行加和，得到测试所有函数需要调用其他函数的个数；以及根据测试所有函数需要调用其他函数的个数，与第一函数数量，得到易测试性指标。
例如，利用函数得到易测试性指标X3，其中，ODi为函数i的出度，N为软件中函数的数量。函数出度ODi越大，测试该函数所需调用的其他函数越多，测试难度相对较大。
该实施例中，易测试性指标度量对该软件设计进行测试的难度，指标值越高，测试难度越小。
在一些实施例中，根据每个函数的入度，得到每个函数的可替换性；以及根据每个函数的可替换性之和，与第一函数数据，得到可替换性指标。
例如，利用函数得到可替换性指标X4，其中，/> Di为函数i的出度，N为软件中函数的数量，Ri为函数i的可替换性。函数的入度越小说明，其它函数调用该函数越小，Ri值越高，该函数可替换性越好。
该实施例中，可替换性指标度量软件中的函数被具有相似功能的函数替换的难度，以及删除特定功能函数的难度，指标值越高，替换/删除难度越小。
在一些实施例中，根据第二函数数量与第一函数数量的比值，得到易理解性指标。
例如，利用函数到易理解性指标X5，其中，Ncomment为包含注释的函数的数量，N为软件中函数的数量，注释的函数越多，相对来说更易理解。
该实施例中，易理解性指标度量的是开发人员对于软件和现有工程文件理解的难易程度，值越高，软件和工程文件越易于理解，越利于开发人员开展演进活动。
在一些实施例中，根据第三函数数量与第一函数数量的比值，得到坏味率指标。
例如，利用函数得到坏味率指标X6，其中，Nbad为存在坏味道的函数数量，N为软件中函数的数量。
该实施例中，坏味率指标度量的是软件中缺陷出现的频率。指标值越高，软件中缺陷出现的频率越高。
在一些实施例中，缺陷率指的是软件缺陷出现的频率，软件缺陷的具体检测依赖于其他工具的检测结果，因此，该实施例中获取缺陷检测结果，根据缺陷检测结果，计算缺陷率。缺陷率包括千行代码缺陷率、缺陷密度、文件通过率以及函数通过率等。
例如，根据缺陷检测结果中的缺陷数量，得到千行代码缺陷率。如，其中，KLOC为千行代码，千行代码缺陷数是指每千行代码中出现的缺陷个数。
再例如，根据缺陷检测结果中的每种类型的缺陷数量以及每种类型的权重，得到缺陷密度。如，其中，该缺陷类型例如包括代码冗余、界面缺陷、功能缺陷、健壮性缺陷等。缺陷密度是指对各个类型的缺陷进行加权计算后得出的缺陷个数。
再例如，根据缺陷检测结果中的含有缺陷的文件数量，与文件数量的比值，得到文件缺陷率。如，文件缺陷率是指含有缺陷的文件数量在总文件数中的比例。
再例如，根据缺陷检测结果中的含有缺陷的函数数量，与第一函数数量的比值，得到函数缺陷率。如， 函数缺陷率是指含有缺陷的函数数量在总函数数中的比例。
上述四种缺陷率的计算结果，侧重点不同，可针对不同的方面对软件进行更系统全面的评估。
上述实施例中，从内外两个方面来评估软件质量，提高了软件评估的全面性和准确性。
本公开的实施例中，从C/C++源码中进行软件设计恢复，首先，恢复出控制流图以及多层次调用图，这些图形化的结构使得对软件设计的理解变得直观和深入。接着，在基于这些恢复出的软件设计的基础上，进行信息提取，精准地获取了各种关键信息，如函数调用关系等。随后，通过对提取到的信息进行深入分析，对软件设计的质量进行全方位评估。这个评估过程不仅关注内在指标，还关注外在指标，即对软件设计行为表现的度量。这使得对软件设计的评价更加全面准确。
图5为本公开的软件质量检测系统的一些实施例的结构示意图，该软件质量检测系统包括设计恢复模块510、信息提取模块520、指标获取模块530和质量检测模块540。
设计恢复模块510被配置为对软件程序源码进行分析，构建控制流图、过程级调用图和文件级调用图。
在一些实施例中，根据软件程序源码，生成中间控制流图；以及利用软件程序源码，对中间控制流图中的节点内容进行替换，并在中间控制流图中的边上增加转换控制条件，以生成控制流图。
在一些实施例中，根据软件程序源码，构建抽象语法树；在抽象语法树中，查找函数声明节点以获取每个函数的函数声明信息，以及查找函数调用节点以获取每个函数的函数调用信息；根据每个函数的函数声明信息，构建每个函数的唯一标识；根据每个函数的唯一标识，构建每个函数节点；以及根据每个函数节点以及每个函数的函数调用信息，构建过程级调用图。
在一些实施例中，根据过程级调用图中的属于同一文件的函数节点，得到文件节点；根据文件节点中每个函数的函数调用信息，得到文件调用信息；以及根据文件调用信息，构建文件级调用图。
信息提取模块520被配置为根据软件程序源码、控制流图、过程级调用图和文件级调用图，提取多个度量元。
在一些实施例中，多个度量元包括软件中的第一函数数量、包含注释的第二函数数量、每个函数的出度和入度、接口数量、存在坏味道的第三函数数量以及文件数量中的一种或多种。
例如，根据软件程序源码，获取第一函数数量和第二函数数量；根据过程级调用图，获取每个函数的出度和入度；根据文件级调用图，获取接口数量以及文件数量；以及根据软件程序源码、控制流图、过程级调用图和文件级调用图，获取第三函数数量。
在一些实施例中，基于AST-Matcher规则，对软件程序源码进行信息提取，得到多个度量元。
指标获取模块530被配置为根据多个度量元，利用多个测量函数，得到与软件质量检测相关的内在指标和外在指标。
在一些实施例中，内在指标包括可修改性指标、可扩展性指标、易测试性指标、可替换性指标、易理解性指标中的至少一项；以及外在指标包括坏味率指标和缺陷率中的至少一项。
例如，根据每个函数的出度和入度之和，得到每个函数关联其他函数的数量；根据每个函数关联其他函数的数量之和，与第一函数数量，得到可修改性指标。
根据接口数量与第一函数数量的比值，得到可扩展性指标。
将每个函数的出度进行加和，得到测试所有函数需要调用其他函数的个数；以及根据测试所有函数需要调用其他函数的个数，与第一函数数量，得到易测试性指标。
根据每个函数的入度，得到每个函数的可替换性；以及根据每个函数的可替换性之和，与第一函数数据，得到可替换性指标。
根据第二函数数量与第一函数数量的比值，得到易理解性指标。
根据第三函数数量与第一函数数量的比值，得到坏味率指标。
该缺陷率包括千行代码缺陷率、缺陷密度、文件通过率以及函数通过率中的至少一项。
例如，根据缺陷检测结果中的缺陷数量，得到千行代码缺陷率；根据缺陷检测结果中的每种类型的缺陷数量以及每种类型的权重，得到缺陷密度；根据缺陷检测结果中的含有缺陷的文件数量，与文件数量的比值，得到文件缺陷率；以及根据缺陷检测结果中的含有缺陷的函数数量，与第一函数数量的比值，得到函数缺陷率。
质量检测模块540被配置为根据内在指标和外在指标，对软件质量进行检测。
在一些实施例中，判断软件质量是否符合预期的质量标准，如果不符合则进行软件设计重构。
在上述实施例中，无需利用特定的SRE工具，即可实现软件设计结构的识别，然后通过源码以及设计结构提取软件质量检测相关的内在指标和外在指标，通过内外两个指标对软件质量进行全面评估，提高了软件质量检测的通用性、准确性以及全面评估性。
图6为本公开的软件质量检测系统的另一些实施例的结构示意图。该软件质量检测系统600包括存储器610和处理器620。其中：存储器610可以是磁盘、闪存或其它任何非易失性存储介质。存储器610用于存储上述实施例中的指令。处理器620耦接至存储器610，可以作为一个或多个集成电路来实施，例如微处理器或微控制器。该处理器620用于执行存储器中存储的指令。
在一些实施例中，处理器620通过BUS总线630耦合至存储器610。该软件质量检测系统600还可以通过存储接口640连接至外部存储装置650以便调用外部数据，还可以通过网络接口660连接至网络或者另外一台计算机系统(未标出)，此处不再进行详细介绍。
在该实施例中，通过存储器存储数据指令，再通过处理器处理上述指令，减少了对特定工具的依赖，提高了模型的准确性，以及提高了软件设计质量评估的全面性。
本公开实施例中，通过从C/C++项目中进行软件设计恢复，然后从源代码、真实设计以及文档中提取信息，最终构建一个综合的C语言、C++语言及C和C++混源软件设计质量指标体系，以进行全面的软件设计质量评估。本公开不仅能够帮助了解和分析现有项目的设计，还为改进和优化软件设计提供了有力的指导。
在另一些实施例中，一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现上述实施例中的方法的步骤。本领域内的技术人员应明白，本公开的实施例可提供为方法、装置、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本公开是参照根据本公开实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
至此，已经详细描述了本公开。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。
虽然已经通过示例对本公开的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上示例仅是为了进行说明，而不是为了限制本公开的范围。本领域的技术人员应该理解，可在不脱离本公开的范围和精神的情况下，对以上实施例进行修改。本公开的范围由所附权利要求来限定。

Claims (19)

1.一种软件质量检测方法，包括：
对软件程序源码进行分析，构建控制流图、过程级调用图和文件级调用图；
根据所述软件程序源码、所述控制流图、所述过程级调用图和所述文件级调用图，提取多个度量元；
根据所述多个度量元，利用多个测量函数，得到与软件质量检测相关的内在指标和外在指标；以及
根据所述内在指标和所述外在指标，对软件质量进行检测。
2.根据权利要求1所述的软件质量检测方法，其中，所述构建控制流图包括：
根据所述软件程序源码，生成中间控制流图；以及
利用所述软件程序源码，对所述中间控制流图中的节点内容进行替换，并在所述中间控制流图中的边上增加转换控制条件，以生成所述控制流图。
3.根据权利要求1所述的软件质量检测方法，其中，构建所述过程级调用图包括：
根据所述软件程序源码，构建抽象语法树；
在所述抽象语法树中，查找函数声明节点以获取每个函数的函数声明信息，以及查找函数调用节点以获取所述每个函数的函数调用信息；
根据所述每个函数的函数声明信息，构建所述每个函数的唯一标识；
根据所述每个函数的唯一标识，构建每个函数节点；以及
根据所述每个函数节点以及所述每个函数的函数调用信息，构建所述过程级调用图。
4.根据权利要求3所述的软件质量检测方法，其中，构建所述文件级调用图包括：
根据所述过程级调用图中的属于同一文件的函数节点，得到文件节点；
根据所述文件节点中所述每个函数的函数调用信息，得到文件调用信息；以及
根据所述文件调用信息，构建所述文件级调用图。
5.根据权利要求1至4任一所述的软件质量检测方法，其中，所述多个度量元包括软件中的第一函数数量、包含注释的第二函数数量、每个函数的出度和入度、接口数量、存在坏味道的第三函数数量以及文件数量中的一种或多种。
6.根据权利要求5所述的软件质量检测方法，其中，
所述内在指标包括可修改性指标、可扩展性指标、易测试性指标、可替换性指标、易理解性指标中的至少一项；以及
所述外在指标包括坏味率指标和缺陷率中的至少一项。
7.根据权利要求6所述的软件质量检测方法，其中，得到所述可修改性指标包括：
根据所述每个函数的出度和入度之和，得到所述每个函数关联其他函数的数量；以及
根据所述每个函数关联其他函数的数量之和，与所述第一函数数量，得到所述可修改性指标。
8.根据权利要求6所述的软件质量检测方法，其中，得到所述可扩展性指标包括：
根据所述接口数量与所述第一函数数量的比值，得到所述可扩展性指标。
9.根据权利要求6所述的软件质量检测方法，其中，得到所述易测试性指标包括：
将所述每个函数的出度进行加和，得到测试所有函数需要调用其他函数的个数；以及
根据测试所有函数需要调用其他函数的个数，与所述第一函数数量，得到所述易测试性指标。
10.根据权利要求6所述的软件质量检测方法，其中，得到所述可替换性指标包括：
根据所述每个函数的入度，得到所述每个函数的可替换性；以及
根据所述每个函数的可替换性之和，与所述第一函数数据，得到所述可替换性指标。
11.根据权利要求6所述的软件质量检测方法，其中，得到所述易理解性指标包括：
根据所述第二函数数量与所述第一函数数量的比值，得到所述易理解性指标。
12.据权利要求6所述的软件质量检测方法，其中，得到所述坏味率指标包括：
根据所述第三函数数量与所述第一函数数量的比值，得到所述坏味率指标。
13.根据权利要求6所述的软件质量检测方法，其中，所述缺陷率包括千行代码缺陷率、缺陷密度、文件通过率以及函数通过率中的至少一项。
14.根据权利要求13所述的软件质量检测方法，还包括：
获取缺陷检测结果，其中，得到所述缺陷率包括以下至少一项：
根据所述缺陷检测结果中的缺陷数量，得到所述千行代码缺陷率；
根据所述缺陷检测结果中的每种类型的缺陷数量以及所述每种类型的权重，得到所述缺陷密度；
根据所述缺陷检测结果中的含有缺陷的文件数量，与所述文件数量的比值，得到所述文件缺陷率；以及
根据所述缺陷检测结果中的含有缺陷的函数数量，与所述第一函数数量的比值，得到所述函数缺陷率。
15.根据权利要求5所述的软件质量检测方法，其中，所述提取多个度量元包括：
根据所述软件程序源码，获取所述第一函数数量和所述第二函数数量；
根据所述过程级调用图，获取所述每个函数的出度和入度；
根据所述文件级调用图，获取所述接口数量以及所述文件数量；以及
根据所述软件程序源码、所述控制流图、所述过程级调用图和所述文件级调用图，获取所述第三函数数量。
16.根据权利要求1至4任一所述的软件质量检测方法，其中，根据所述软件程序源码，提取多个度量元包括：
基于AST-Matcher规则，对所述软件程序源码进行信息提取，得到多个度量元。
17.一种软件质量检测系统，包括：
设计恢复模块，被配置为对软件程序源码进行分析，构建控制流图、过程级调用图和文件级调用图；
信息提取模块，被配置为根据所述软件程序源码、所述控制流图、所述过程级调用图和所述文件级调用图，提取多个度量元；
指标获取模块，被配置为根据所述多个度量元，利用多个测量函数，得到与软件质量检测相关的内在指标和外在指标；以及
质量检测模块，被配置为根据所述内在指标和所述外在指标，对软件质量进行检测。
18.一种软件质量检测系统，包括：
存储器；以及
耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器的指令执行如权利要求1至16任一项所述的软件质量检测方法。
19.一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现如权利要求1至16任一项所述的软件质量检测方法。
CN202311575155.3A 2023-11-23 2023-11-23 软件质量检测方法、系统和存储介质 Pending CN117435502A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311575155.3A CN117435502A (zh) 2023-11-23 2023-11-23 软件质量检测方法、系统和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311575155.3A CN117435502A (zh) 2023-11-23 2023-11-23 软件质量检测方法、系统和存储介质

Publications (1)

Publication Number Publication Date
CN117435502A true CN117435502A (zh) 2024-01-23

Family

ID=89553454

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311575155.3A Pending CN117435502A (zh) 2023-11-23 2023-11-23 软件质量检测方法、系统和存储介质

Country Status (1)

Country Link
CN (1) CN117435502A (zh)

Similar Documents

Publication Publication Date Title
Ampatzoglou et al. The effect of GoF design patterns on stability: a case study
Taba et al. Predicting bugs using antipatterns
Le Goues et al. Specification mining with few false positives
Wang et al. Lightweight global and local contexts guided method name recommendation with prior knowledge
Mijatov et al. A Framework for Testing UML Activities Based on fUML.
CN115080448B (zh) 一种软件代码不可达路径自动检测的方法和装置
Abilio et al. Metrics for feature-oriented programming
Abbad-Andaloussi On the relationship between source-code metrics and cognitive load: A systematic tertiary review
Marinescu How good is genetic programming at predicting changes and defects?
Rustambekovich et al. Challenging the ways to determine the faults in software: Technique based on associative interconnections
Burgstaller et al. FMTESTING: A FEATUREIDE Plug-in for Automated Feature Model Analysis and Diagnosis
Rapos et al. SimPact: Impact analysis for simulink models
Priya et al. Test Case Generation from UML models-A survey
Faragó Connection between version control operations and quality change of the source code
Babkin et al. Analysis of the consistency of enterprise architecture models using formal verification methods
Ryser et al. On the State of the Art in Requirements-based Validation and Test of Software
Feichtinger et al. Supporting feature model evolution by suggesting constraints from code-level dependency analyses
CN117435502A (zh) 软件质量检测方法、系统和存储介质
Ben Charrada et al. An automated hint generation approach for supporting the evolution of requirements specifications
Kemmann et al. Extensible and automated model-evaluations with INProVE
Weber et al. Detecting inconsistencies in multi-view uml models
Nguyen et al. TC4MT: A Specification-Driven Testing Framework for Model Transformations
Oosterman et al. Evojava: A tool for measuring evolving software
Zapalowski et al. The WGB method to recover implemented architectural rules
Gómez-Abajo et al. Gotten: A Model-Driven Solution to Engineer Domain-specific Metamorphic Testing Environments

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