Software quality detection method and system, and storage medium

Abstract

The present disclosure relates to the field of software design, and provides a software quality detection method and system, and a storage medium. The method comprises: analyzing a software program source code to construct a control-flow graph, a procedure-level call graph, and a file-level call graph; on the basis of the software program source code, the control-flow graph, the procedure-level call graph, and the file-level call graph, extracting a plurality of metric elements; and on the basis of the plurality of metric elements, using a plurality of measurement functions to obtain an internal index and an external index which are related to software quality detection; and performing software quality detection on the basis of the internal index and the external index.

Description

Software quality detection method, system and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on the application with CN application number 202311575155.3 and application date November 23, 2023, and claims its priority. The disclosed content of the CN application is hereby introduced as a whole into this application. Technical Field

[0003] The present disclosure relates to the field of software design, and in particular to a software quality detection method, system, and storage medium. Background Art

[0004] Research on software design quality assessment technology has always been a core focus of software engineering development. It is a key step in software development and serves as a bridge between software requirements and implementation. The quality of software design directly impacts the quality of the final software product. High-quality software design can effectively meet users' functional and non-functional requirements while also enabling more efficient and high-quality subsequent software implementation. Conversely, low-quality software design can directly result in a final software product that fails to meet user needs and may even lead to serious quality issues such as functional errors, poor performance, security risks, and difficulty in maintenance and expansion. Through software design quality assessment, development teams can better understand, evaluate, and improve their software designs, ensuring the quality of the final product.

[0005] Software design quality assessment is a key branch of software engineering. With the development of software technology and the widespread adoption of its applications, software design quality assessment techniques have also been evolving and advancing. Software design quality assessment dates back to the early days of software engineering. In the 1970s and 1980s, pioneers in software engineering began focusing on how to design higher-quality software. Early approaches focused on software structure, modularity, and design principles such as structured design and object-oriented design. In the late 1980s and early 1990s, quality models such as ISO 9126 were introduced to define and measure various aspects of software quality, such as functionality, maintainability, and performance. These models provide a systematic approach to software design quality assessment. Advances in computer technology have led to the emergence of numerous automated tools and static analysis tools for analyzing and assessing software design quality. These tools can detect code quality issues, potential bugs, and performance bottlenecks, helping developers identify and fix problems earlier.

[0006] The rise of agile development methodologies has transformed the way software design quality assessment is conducted. Agile methods emphasize rapid iteration and feedback, making quality assessment an integral part of the development process rather than a post-process activity. Continuous integration and continuous delivery (CI / CD) practices have also driven the automation and integration of quality assessment. With the development of artificial intelligence (AI), machine learning and AI are being applied to software design quality assessment, for example, through automated code reviews, defect detection, and performance analysis. These technologies can accelerate and improve the quality assessment process. Overall, the field of software design quality assessment has continuously evolved with the advancement of software engineering and the emergence of new technologies. It has evolved from initial structured design and quality models to the integration of modern technologies such as automated tools, agile development, DevOps (Development + Operations), and machine learning. The goal of this field is to ensure the development of high-quality, maintainable, and secure software that meets ever-changing user needs and market requirements.

[0007] Summary of the Invention

[0008] According to one aspect of the present disclosure, a software quality detection method is proposed, comprising: analyzing software program source code to construct a control flow graph, a procedure-level call graph, and a file-level call graph; extracting multiple metrics based on the software program source code, the control flow graph, the procedure-level call graph, and the file-level call graph; obtaining intrinsic and extrinsic indicators related to software quality detection based on the multiple metrics using multiple measurement functions; and detecting software quality based on the intrinsic and extrinsic indicators.

[0009] In some embodiments, constructing a control flow graph includes: generating an intermediate control flow graph based on the software program source code; and using the software program source code to replace the node content in the intermediate control flow graph, and adding conversion control conditions to the edges in the intermediate control flow graph to generate a control flow graph.

[0010] In some embodiments, constructing a process-level call graph includes: constructing an abstract syntax tree based on the software program source code; in the abstract syntax tree, searching for function declaration nodes to obtain function declaration information of each function, and searching for function call nodes to obtain function call information of each function; constructing a unique identifier for each function based on the function declaration information of each function; constructing each function node based on the unique identifier of each function; and constructing a process-level call graph based on each function node and the function call information of each function.

[0011] In some embodiments, constructing a file-level call graph includes: obtaining a file node based on function nodes belonging to the same file in a process-level call graph; obtaining file call information based on function call information of each function in the file node; and constructing a file-level call graph based on the file call information.

[0012] In some embodiments, the plurality of metrics include one or more of the number of first functions in the software, the number of second functions containing annotations, the out-degree and in-degree of each function, the number of interfaces, the number of third functions with bad smells, and the number of files.

[0013] In some embodiments, the intrinsic indicator includes at least one of a modifiability indicator, an extensibility indicator, a testability indicator, a replaceability indicator, and an understandability indicator; and the extrinsic indicator includes at least one of a smell rate indicator and a defect rate.

[0014] In some embodiments, obtaining the modifiability index includes: obtaining the number of other functions associated with each function based on the sum of the out-degree and in-degree of each function; and obtaining the modifiability index based on the sum of the number of other functions associated with each function and the number of first functions.

[0015] In some embodiments, obtaining the scalability indicator includes: obtaining the scalability indicator according to a ratio of the number of interfaces to the number of first functions.

[0016] In some embodiments, obtaining the testability index includes: summing the out-degree of each function to obtain the number of other functions that need to be called to test all functions; and obtaining the testability index based on the number of other functions that need to be called to test all functions and the number of first functions.

[0017] In some embodiments, obtaining the replaceability index includes: obtaining the replaceability of each function according to the in-degree of each function; and obtaining the replaceability index according to the sum of the replaceability of each function and the first function data.

[0018] In some embodiments, obtaining the comprehensibility index includes: obtaining the comprehensibility index according to a ratio of the number of the second functions to the number of the first functions.

[0019] In some embodiments, obtaining the bad smell ratio indicator includes: obtaining the bad smell ratio indicator according to a ratio of the number of third functions to the number of first functions.

[0020] In some embodiments, the defect rate includes at least one of a thousand lines of code defect rate, a defect density, a file pass rate, and a function pass rate.

[0021] In some embodiments, defect detection results are obtained, wherein obtaining the defect rate includes at least one of the following: obtaining a defect rate per thousand lines of code based on the number of defects in the defect detection results; obtaining a defect density based on the number of defects of each type in the defect detection results and the weight of each type; obtaining a file defect rate based on the ratio of the number of files containing defects to the number of files in the defect detection results; and obtaining a function defect rate based on the ratio of the number of functions containing defects in the defect detection results to the number of first functions.

[0022] In some embodiments, extracting multiple metric elements includes: obtaining a first number of functions and a second number of functions based on the software program source code; obtaining the out-degree and in-degree of each function based on the process-level call graph; obtaining the number of interfaces and the number of files based on the file-level call graph; and obtaining a third number of functions based on the software program source code, the control flow graph, the process-level call graph, and the file-level call graph.

[0023] In some embodiments, extracting multiple metrics based on the software program source code includes: extracting information from the software program source code based on AST-Matcher rules to obtain multiple metrics.

[0024] According to another aspect of the present disclosure, a software quality detection system is also proposed, including: a design recovery module, configured to analyze the software program source code and construct a control flow graph, a process-level call graph and a file-level call graph; an information extraction module, configured to extract multiple metrics based on the software program source code, the control flow graph, the process-level call graph and the file-level call graph; an indicator acquisition module, configured to obtain intrinsic indicators and extrinsic indicators related to software quality detection based on the multiple metrics and using multiple measurement functions; and a quality detection module, configured to detect software quality based on the intrinsic indicators and extrinsic indicators.

[0025] According to another aspect of the present disclosure, a software quality detection system is provided, including: a memory; and a processor coupled to the memory, wherein the processor is configured to execute the above-mentioned software quality detection method based on instructions stored in the memory.

[0026] According to another aspect of the present disclosure, a computer-readable storage medium is provided, on which computer program instructions are stored. When the instructions are executed by a processor, the software quality detection method as described above is implemented.

[0027] Other features and advantages of the present disclosure will become apparent from the following detailed description of exemplary embodiments of the present disclosure with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0029] The present disclosure can be more clearly understood from the following detailed description with reference to the accompanying drawings, in which:

[0030] FIG1 is a flowchart of some embodiments of the software quality detection method disclosed herein;

[0031] FIG2 is a flowchart of other embodiments of the software quality detection method disclosed herein;

[0032] FIG3 is a flowchart of other embodiments of the software quality detection method disclosed herein;

[0033] FIG4 is a flowchart of other embodiments of the software quality detection method disclosed herein;

[0034] FIG5 is a schematic structural diagram of some embodiments of the software quality detection system disclosed herein;

[0035] FIG6 is a schematic structural diagram of other embodiments of the software quality detection system disclosed herein. DETAILED DESCRIPTION

[0036] Various exemplary embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings. It should be noted that unless otherwise specifically stated, the relative arrangement of components and steps, numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present disclosure.

[0037] At the same time, it should be understood that for the convenience of description, the sizes of the various parts shown in the drawings are not drawn according to the actual proportional relationship.

[0038] The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the present disclosure, its application, or uses.

[0039] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered part of the specification.

[0040] In all examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not limiting. Therefore, other examples of the exemplary embodiments may have different values.

[0041] It should be noted that like reference numerals and letters refer to like items in the following figures, and therefore, once an item is defined in one figure, it need not be further discussed in subsequent figures.

[0042] In order to make the objectives, technical solutions and advantages of the present disclosure more clearly understood, the present disclosure is further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

[0043] In related technologies, the use of the expected quality assessment method for source code generated based on class representation (such as UML class diagrams) is based on the premise of a complete and correct class representation. However, in actual situations, complete and correct UML diagrams are almost impossible to obtain, so the practicality of this method is questionable. Analyzing and evaluating software quality based on call relationships is somewhat one-sided and cannot fully utilize source code information for a comprehensive assessment. Software quality assessment methods using specific SRE (Software Reverse Engineering) tools cannot effectively collect static cohesion data if these specific SRE tools are unavailable or not applicable to a specific software system. In addition, focusing on the assessment of cohesion may neglect other software quality attributes, resulting in a smaller scope of application.

[0044] The quality model, static code analysis and software reverse engineering will be explained accordingly below.

[0045] Quality models in software design quality assessment are systematic approaches for defining, measuring, and evaluating various aspects of software quality. These models help development teams and stakeholders clearly define the quality attributes that software should possess, ensuring that these requirements are met during the design and implementation phases. A widely used quality model is ISO 25010, which defines multiple aspects of software quality. The ISO 25010 quality model divides software quality into two main categories: internal quality and external quality. Internal quality refers to the quality of internal characteristics of the software, typically only visible during the software development and testing process. External quality, on the other hand, refers to the quality of software characteristics that users can observe and experience. These internal and external quality sub-characteristics can be further broken down into more specific characteristics and criteria to help development teams more granularly assess and improve the quality of software designs. Quality models provide a general framework for establishing specific quality goals and metrics based on project and organizational needs, and for continuously monitoring and evaluating software quality throughout the development process. This helps ensure that the software meets expected levels of user needs, performance, maintainability, and security.

[0046] Static code analysis is a key technique in software design quality assessment. It identifies potential issues, errors, and defects by analyzing the text of source code without running the program. This analysis helps development teams identify problems before code is executed, thereby improving software quality, maintainability, and reliability. Static code analysis helps ensure that code adheres to coding standards and compliance requirements, and analysis tools can run automatically, improving efficiency, especially for large code bases. However, static code analysis also has certain limitations. Static code analysis cannot completely replace manual code review and testing because it cannot catch all types of problems. Static code analysis tools may generate false positives (false alarms), which require manual verification and remediation.

[0047] Software reverse engineering is the process of parsing and analyzing existing software systems, programs, or components to obtain information about their internal structure, algorithms, design principles, and other aspects. Reverse engineering is often used to understand, review, improve, or redesign software, and can also be used to discover and fix defects or security vulnerabilities in software.

[0048] FIG1 is a flowchart of some embodiments of the software quality detection method disclosed herein.

[0049] In step 110, the software program source code is analyzed to construct a control flow graph, a procedure-level call graph, and a file-level call graph.

[0050] In some embodiments, the software program source code is C language, C++ language, or mixed source software source code of C and C++.

[0051] In some embodiments, the software program source code is analyzed to identify program design structures, such as sequential structures, various selection structures, various loop structures, etc., and then a control flow graph (CFG) and a call graph (CG) are constructed. The call graph includes a procedure-level call graph (PLCG) and a file-level call graph (FLCG).

[0052] In some embodiments, the control flow graph is a directed graph G = (V, E), where V is a set of vertices and E is a set of directed edges. In the control flow graph, each vertex represents a basic block, which is a linear sequence of program instructions with an entry point (the first instruction executed) and an exit point (the last instruction executed), and the directed edges represent the control flow path.

[0053] In some embodiments, a call graph represents the call relationships between subroutines in a software system. Each node represents a procedure, and each edge (f, g) represents a call from procedure f to procedure g. In a procedure-level call graph, each node represents a function in a C program, and edges represent the call relationships between functions. In a file-level call graph, each node represents a file in a C language project, and edges represent the call relationships between two files.

[0054] In step 120 , a plurality of metrics are extracted based on the software program source code, the control flow graph, the procedure-level call graph, and the file-level call graph.

[0055] In some embodiments, information extraction is performed on the software program source code based on AST-Matcher rules to obtain multiple metrics. The core of source code information extraction based on AST-Matcher rules is to compile consistent query rules for different information in the software program source code. This improves the accuracy of model instantiation and reverse engineering, thereby improving the reliability of subsequent evaluation results and reducing potential errors and error rates.

[0056] In some embodiments, design diagram information is extracted based on the control flow graph, procedure-level call graph, and file-level call graph recovered from the source code.

[0057] In some embodiments, the multiple metrics include the number of first functions in the software, the number of second functions containing annotations, the out-degree and in-degree of each function, the number of interfaces, the number of third functions with bad smells, the number of files, etc.

[0058] For example, based on the software program source code, the first number of functions and the second number of functions are obtained; based on the process-level call graph, the out-degree and in-degree of each function are obtained; based on the file-level call graph, the number of interfaces and the number of files are obtained; and based on the software program source code, the control flow graph, the process-level call graph and the file-level call graph, the third number of functions is obtained.

[0059] In step 130, intrinsic indicators and extrinsic indicators related to software quality detection are obtained based on multiple metrics and using multiple measurement functions.

[0060] In some embodiments, software design quality is evaluated from both internal and external aspects. Internal indicators refer to indicators at the structural level, including the ability of design to collaborate with code and the ability of design to adapt to evolutionary activities; external indicators refer to indicators at the behavioral level, which are a measure of the performance of the design.

[0061] For example, intrinsic indicators include modifiability indicators, scalability indicators, testability indicators, replaceability indicators, understandability indicators, etc., and extrinsic indicators include bad smell rate indicators and defect rate, etc.

[0062] In step 140, the software quality is tested based on the intrinsic and extrinsic indicators.

[0063] In this step, the software design quality is comprehensively evaluated from both internal and external aspects. Based on the evaluation, it is determined whether the software design meets the expected quality standards. If not, the software design is refactored.

[0064] Different indicators can be selected for different projects to determine software quality. For example, if at least one of the modifiability, scalability, testability, replaceability, understandability, smell rate, and defect rate does not meet the project requirements, the software quality is considered unsatisfactory. In this case, the software design can be refactored. This not only helps understand and analyze the existing project design, but also provides powerful guidance for improving and optimizing the software design.

[0065] In the above embodiment, the software design structure can be identified without using a specific SRE tool. Then, the intrinsic and extrinsic indicators related to software quality detection are extracted through the source code and the software design structure. The software quality is comprehensively evaluated by the internal and external indicators, thereby improving the versatility and comprehensive evaluation of software quality detection.

[0066] FIG2 is a flowchart of other embodiments of the software quality detection method disclosed herein.

[0067] In step 210, an intermediate control flow graph is generated based on the software program source code.

[0068] In some embodiments, the software program source code is analyzed using Clang's CFG generation tool to generate an intermediate control flow graph, which is a symbolic identifier of the compiler and needs to be processed into a source code level control flow graph.

[0069] In step 220, the node contents in the intermediate control flow graph are replaced using the software program source code, and conversion control conditions are added to the edges in the intermediate control flow graph to generate a control flow graph.

[0070] In this step, the information in the nodes of the intermediate control flow graph is processed, the node contents are replaced with source code, and finally branch conditions are added to the intermediate control flow graph to achieve the recovery of the control flow graph. This implementation process is not limited by specific SRE tools and is more versatile. It does not need to focus on the development tools and environment used by the software and can be applied to a wider range of software systems.

[0071] FIG3 is a flowchart of other embodiments of the software quality detection method disclosed herein.

[0072] In step 310, an abstract syntax tree is constructed based on the software program source code.

[0073] In some embodiments, the abstract syntax tree is constructed by Clang.

[0074] In step 320 , in the abstract syntax tree, a function declaration node is searched to obtain function declaration information of each function, and a function call node is searched to obtain function call information of each function.

[0075] In some embodiments, ASTMatcher is used to search for function declaration nodes and function call nodes in an abstract syntax tree. In this step, different query rules are written for different information in the software program source code, thereby obtaining function declaration information and function call information. This can improve the accuracy of model instantiation, increase the reliability of subsequent evaluation results, and reduce potential errors and error rates.

[0076] In step 330 , a unique identifier of each function is constructed based on the function declaration information of each function.

[0077] In some embodiments, the unique identifier is, for example, a file name + a function name.

[0078] In step 340 , each function node is constructed according to the unique identifier of each function.

[0079] In step 350 , a procedure-level call graph is constructed based on each function node and the function call information of each function.

[0080] In this embodiment, the construction of the process-level call graph can be achieved without using a specific SRE tool.

[0081] FIG4 is a flowchart of other embodiments of the software quality detection method disclosed herein.

[0082] In step 410, a file node is obtained based on the function nodes belonging to the same file in the procedure-level call graph.

[0083] The process-level call graph is a fine-grained call graph, and the file-level call graph is a coarse-grained call graph. The process-level call graph contains multiple function nodes, which are analyzed according to the file granularity to obtain the file nodes.

[0084] In step 420, file call information is obtained based on the function call information of each function in the file node.

[0085] In step 430, a file-level call graph is constructed based on the file call information.

[0086] In this embodiment, the file-level call graph can be constructed without using specific SRE tools.

[0087] In the above embodiment, the project is not required to provide relevant design drawing information. Instead, the software program source code is used to construct a control flow graph, a process-level call graph, and a file-level call graph, thereby improving the integrity and correctness of the recovered software design and facilitating an all-round evaluation of the software design quality.

[0088] In some embodiments of the present disclosure, the quality of a design can be evaluated not only at the structural level but also at the behavioral level. In the calculation of software quality assessment, the granularity of all indicators is set at the function level. This allows for a comprehensive review of the software design, thus providing a more comprehensive and comprehensive assessment.

[0089] In some embodiments, the number of other functions associated with each function is obtained based on the sum of the out-degree and in-degree of each function; and the modifiability index is obtained based on the sum of the number of other functions associated with each function and the number of first functions.

[0090] For example, using the function Get the modifiability index X1, where OD i is the out-degree of function i, i is a natural number, ID i is the in-degree of function i, N is the number of functions in the software, that is, the number of first functions. i +ID i The calculation is the sum of the functions associated with a function in the call graph. The more other functions a function is associated with, the greater the impact of the modification on other functions needs to be considered, and the more difficult it is to modify. The average value of all functions in the entire system is considered. The smaller the value, the better the modifiability of the system function. The larger the value, the better the modifiability of the system function.

[0091] In this embodiment, the modifiability index measures the difficulty of modifying the software design, specifically the difficulty of implementing software correction and improvement activities. The higher the index value, the lower the implementation difficulty.

[0092] In some embodiments, the scalability index is obtained based on the ratio of the number of interfaces to the number of first functions.

[0093] For example, using the function Get the scalability index X2, where N API is the number of APIs (Application Programming Interfaces) in the software, and N is the number of functions in the software. In this embodiment, the larger the proportion of APIs, the better the external scalability of the system.

[0094] In this embodiment, the scalability index measures the difficulty of expanding the software design. The higher the index value, the lower the expansion difficulty.

[0095] In some embodiments, the out-degree of each function is summed to obtain the number of other functions that need to be called to test all functions; and the testability index is obtained based on the number of other functions that need to be called to test all functions and the number of first functions.

[0096] For example, using the function Get the testability index X3, where OD i is the out-degree of function i, and N is the number of functions in the software. Function out-degree OD i The larger the value, the more other functions need to be called to test the function, and the more difficult the test is.

[0097] In this embodiment, the testability index measures the difficulty of testing the software design. The higher the index value, the lower the testing difficulty.

[0098] In some embodiments, the substitutability of each function is obtained according to the in-degree of each function; and the substitutability index is obtained according to the sum of the substitutabilities of each function and the first function data.

[0099] For example, using the function Get the replaceability index X4, where D i is the out-degree of function i, N is the number of functions in the software, R i is the substitutability of function i. The smaller the in-degree of a function, the smaller the number of other functions that call it. i The higher the value, the more replaceable the function.

[0100] In this embodiment, the replaceability index measures the difficulty of replacing a function in the software with a function having similar functionality, as well as the difficulty of deleting a function with a specific functionality. The higher the index value, the lower the difficulty of replacement / deletion.

[0101] In some embodiments, the comprehensibility index is obtained based on the ratio of the number of second functions to the number of first functions.

[0102] For example, using the function To understandability index X5, where N comment is the number of functions containing comments, N is the number of functions in the software. The more functions with comments, the easier it is to understand.

[0103] In this embodiment, the understandability index measures the difficulty for developers to understand the software and existing project files. The higher the value, the easier the software and project files are to understand, and the more conducive it is for developers to carry out evolution activities.

[0104] In some embodiments, a bad smell rate indicator is obtained according to the ratio of the number of the third functions to the number of the first functions.

[0105] For example, using the function Get the bad taste rate index X6, where N bad is the number of functions with bad smells, and N is the number of functions in the software.

[0106] In this embodiment, the bad smell rate index measures the frequency of defects in the software. The higher the index value, the higher the frequency of defects in the software.

[0107] In some embodiments, the defect rate refers to the frequency of software defects. Specific software defect detection relies on the detection results of other tools. Therefore, in this embodiment, defect detection results are obtained and used to calculate the defect rate. Defect rates include defect rate per thousand lines of code, defect density, file pass rate, and function pass rate.

[0108] For example, the defect rate per thousand lines of code can be obtained based on the number of defects in the defect detection results. KLOC stands for thousand lines of code, and defects per thousand lines of code refers to the number of defects that occur in every thousand lines of code.

[0109] For another example, the defect density is obtained based on the number of defects of each type in the defect detection results and the weight of each type. For example, The defect types include, for example, code redundancy, interface defects, functional defects, robustness defects, etc. Defect density refers to the number of defects obtained by weighted calculation of defects of various types.

[0110] For another example, the file defect rate can be obtained based on the ratio of the number of files containing defects in the defect detection results to the number of files. The file defect rate refers to the ratio of the number of files containing defects to the total number of files.

[0111] For another example, the function defect rate is obtained based on the ratio of the number of functions containing defects in the defect detection result to the number of first functions. The function defect rate refers to the ratio of the number of functions containing defects to the total number of functions.

[0112] The calculation results of the above four defect rates have different focuses and can provide a more systematic and comprehensive evaluation of the software in different aspects.

[0113] In the above embodiment, software quality is evaluated from both internal and external aspects, which improves the comprehensiveness and accuracy of software evaluation.

[0114] In the embodiments of the present disclosure, software design recovery is performed from C / C++ source code. First, the control flow graph and multi-level call graph are recovered. These graphical structures make the understanding of software design intuitive and in-depth. Then, based on these recovered software designs, information extraction is performed to accurately obtain various key information, such as function call relationships. Subsequently, through in-depth analysis of the extracted information, the quality of the software design is comprehensively evaluated. This evaluation process focuses not only on internal indicators, but also on external indicators, that is, the measurement of the behavioral performance of the software design. This makes the evaluation of software design more comprehensive and accurate.

[0115] FIG5 is a schematic structural diagram of some embodiments of the software quality detection system of the present disclosure. The software quality detection system includes a design recovery module 510 , an information extraction module 520 , an indicator acquisition module 530 and a quality detection module 540 .

[0116] The design recovery module 510 is configured to analyze the software program source code and construct a control flow graph, a procedure-level call graph, and a file-level call graph.

[0117] In some embodiments, an intermediate control flow graph is generated based on the software program source code; and the software program source code is used to replace the node content in the intermediate control flow graph, and conversion control conditions are added to the edges in the intermediate control flow graph to generate a control flow graph.

[0118] In some embodiments, an abstract syntax tree is constructed based on the software program source code; in the abstract syntax tree, function declaration nodes are searched to obtain function declaration information of each function, and function call nodes are searched to obtain function call information of each function; based on the function declaration information of each function, a unique identifier of each function is constructed; based on the unique identifier of each function, each function node is constructed; and based on each function node and the function call information of each function, a process-level call graph is constructed.

[0119] In some embodiments, a file node is obtained based on function nodes belonging to the same file in a process-level call graph; file call information is obtained based on function call information of each function in the file node; and a file-level call graph is constructed based on the file call information.

[0120] The information extraction module 520 is configured to extract a plurality of metrics based on the software program source code, the control flow graph, the procedure-level call graph, and the file-level call graph.

[0121] In some embodiments, the plurality of metrics include one or more of the number of first functions in the software, the number of second functions containing annotations, the out-degree and in-degree of each function, the number of interfaces, the number of third functions with bad smells, and the number of files.

[0122] For example, based on the software program source code, the first number of functions and the second number of functions are obtained; based on the process-level call graph, the out-degree and in-degree of each function are obtained; based on the file-level call graph, the number of interfaces and the number of files are obtained; and based on the software program source code, the control flow graph, the process-level call graph and the file-level call graph, the third number of functions is obtained.

[0123] In some embodiments, information is extracted from the software program source code based on AST-Matcher rules to obtain multiple metrics.

[0124] The indicator acquisition module 530 is configured to obtain intrinsic indicators and extrinsic indicators related to software quality detection based on multiple metrics and using multiple measurement functions.

[0125] In some embodiments, the intrinsic indicator includes at least one of a modifiability indicator, an extensibility indicator, a testability indicator, a replaceability indicator, and an understandability indicator; and the extrinsic indicator includes at least one of a smell rate indicator and a defect rate.

[0126] For example, the number of other functions associated with each function is obtained based on the sum of the out-degree and in-degree of each function; the modifiability index is obtained based on the sum of the number of other functions associated with each function and the number of the first function.

[0127] The scalability index is obtained according to the ratio of the number of interfaces to the number of first functions.

[0128] The out-degree of each function is summed up to get the number of other functions that need to be called to test all functions; and the testability index is obtained based on the number of other functions that need to be called to test all functions and the number of first functions.

[0129] According to the in-degree of each function, the substitutability of each function is obtained; and according to the sum of the substitutability of each function and the first function data, the substitutability index is obtained.

[0130] According to the ratio of the number of the second functions to the number of the first functions, the understandability index is obtained.

[0131] The bad taste ratio index is obtained according to the ratio of the number of the third function to the number of the first function.

[0132] The defect rate includes at least one of a thousand-line-of-code defect rate, a defect density, a file pass rate, and a function pass rate.

[0133] For example, the defect rate per thousand lines of code is obtained based on the number of defects in the defect detection results; the defect density is obtained based on the number of defects of each type in the defect detection results and the weight of each type; the file defect rate is obtained based on the ratio of the number of files containing defects in the defect detection results to the number of files; and the function defect rate is obtained based on the ratio of the number of functions containing defects in the defect detection results to the number of first functions.

[0134] The quality detection module 540 is configured to detect the software quality based on intrinsic indicators and extrinsic indicators.

[0135] In some embodiments, it is determined whether the software quality meets the expected quality standards, and if not, the software design is refactored.

[0136] In the above embodiment, the software design structure can be identified without using a specific SRE tool. Then, the intrinsic and extrinsic indicators related to software quality detection are extracted through the source code and design structure. The software quality is comprehensively evaluated through the internal and external indicators, thereby improving the versatility, accuracy and comprehensive evaluation of software quality detection.

[0137] FIG6 is a schematic diagram of the structure of other embodiments of the software quality detection system disclosed herein. The software quality detection system 600 includes a memory 610 and a processor 620. The memory 610 may be a disk, flash memory, or any other non-volatile storage medium. The memory 610 is used to store the instructions described in the above embodiments. The processor 620 is coupled to the memory 610 and may be implemented as one or more integrated circuits, such as a microprocessor or microcontroller. The processor 620 is used to execute the instructions stored in the memory.

[0138] In some embodiments, the processor 620 is coupled to the memory 610 via a BUS 630. The software quality detection system 600 can also be connected to an external storage device 650 via a storage interface 640 to access external data, and can also be connected to a network or another computer system (not shown) via a network interface 660, which will not be described in detail here.

[0139] In this embodiment, data instructions are stored in a memory and then processed by a processor, thereby reducing dependence on specific tools, improving the accuracy of the model, and enhancing the comprehensiveness of software design quality assessment.

[0140] In this disclosure, software design recovery is performed from C / C++ projects. Information is then extracted from source code, actual designs, and documentation. Ultimately, a comprehensive C, C++, and mixed-source C and C++ software design quality indicator system is constructed for comprehensive software design quality assessment. This disclosure not only helps understand and analyze existing project designs but also provides powerful guidance for improving and optimizing software designs.

[0141] In other embodiments, a computer-readable storage medium stores computer program instructions thereon, which, when executed by a processor, implement the steps of the method in the above-described embodiment. Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, devices, or computer program products. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable non-transient storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0142] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present disclosure. It should be understood that each process and / or box in the flowchart and / or block diagram and the combination of the processes and / or boxes in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0143] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0144] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0145] In some embodiments of the present disclosure, a computer program is further provided, comprising: instructions, which, when executed by a processor, cause the processor to perform the software quality detection method as described above.

[0146] The present disclosure has been described in detail so far. To avoid obscuring the concept of the present disclosure, some details known in the art have not been described. Based on the above description, those skilled in the art can fully understand how to implement the technical solutions disclosed herein.

[0147] Although some specific embodiments of the present disclosure have been described in detail by way of examples, those skilled in the art will appreciate that the above examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Those skilled in the art will appreciate that modifications may be made to the above embodiments without departing from the scope and spirit of the present disclosure. The scope of the present disclosure is defined by the appended claims.

Claims

1. A software quality detection method, comprising: Analyze the software program source code and construct control flow graphs, process-level call graphs, and file-level call graphs; Extracting a plurality of metrics according to the software program source code, the control flow graph, the process-level call graph, and the file-level call graph; According to the multiple metrics, using multiple measurement functions, obtaining intrinsic indicators and extrinsic indicators related to software quality detection; as well as The software quality is detected according to the intrinsic index and the extrinsic index.

2. The software quality detection method according to claim 1, wherein: The construction of the control flow graph includes: generating an intermediate control flow graph according to the software program source code; and The software program source code is used to replace the node content in the intermediate control flow graph, and conversion control conditions are added to the edges in the intermediate control flow graph to generate the control flow graph.

3. The software quality detection method according to claim 1 or 2, wherein: Constructing the process-level call graph includes: Constructing an abstract syntax tree according to the software program source code; In the abstract syntax tree, searching for a function declaration node to obtain function declaration information of each function, and searching for a function call node to obtain function call information of each function; Constructing a unique identifier for each function according to the function declaration information of each function; Constructing each function node according to the unique identifier of each function; and The process-level call graph is constructed according to each function node and the function call information of each function.

4. The software quality detection method according to claim 3, wherein: Building the file-level call graph includes: Obtaining a file node according to function nodes belonging to the same file in the process-level call graph; Obtaining file call information according to the function call information of each function in the file node; and The file-level call graph is constructed according to the file call information.

5. The software quality detection method according to any one of claims 1 to 4, wherein: The multiple metrics include one or more of the number of first functions in the software, the number of second functions containing annotations, the out-degree and in-degree of each function, the number of interfaces, the number of third functions with bad smells, and the number of files.

6. The software quality detection method according to claim 5, wherein: The intrinsic index includes at least one of a modifiability index, an extensibility index, a testability index, a replaceability index, and an understandability index; and The external index includes at least one of a bad taste rate index and a defect rate.

7. The software quality detection method according to claim 6, wherein: Obtaining the modifiability index includes: According to the sum of the out-degree and the in-degree of each function, the number of other functions associated with each function is obtained; and The modifiability index is obtained according to the sum of the number of other functions associated with each function and the number of the first functions.

8. The software quality detection method according to claim 6 or 7, wherein: Obtaining the scalability index includes: The scalability index is obtained according to the ratio of the number of interfaces to the number of the first functions.

9. The software quality detection method according to any one of claims 6 to 8, wherein: The testability index includes: Add up the out-degree of each function to obtain the number of other functions that need to be called to test all functions; and The testability index is obtained according to the number of other functions that need to be called when testing all functions and the number of the first functions.

10. The software quality detection method according to any one of claims 6 to 9, wherein: Obtaining the replaceability index includes: According to the in-degree of each function, obtain the interchangeability of each function; and The interchangeability index is obtained according to the sum of the interchangeability of each function and the first function data.

11. The software quality detection method according to any one of claims 6 to 10, wherein: The comprehensibility index includes: The comprehensibility index is obtained according to the ratio of the number of the second functions to the number of the first functions.

12. The software quality detection method according to any one of claims 6 to 11, wherein: Obtaining the bad taste rate index includes: The bad taste rate index is obtained according to the ratio of the number of the third functions to the number of the first functions.

13. The software quality detection method according to any one of claims 6 to 12, wherein: The defect rate includes at least one of a thousand lines of code defect rate, a defect density, a file pass rate, and a function pass rate.

14. The software quality detection method according to claim 13, further comprising: Obtaining defect detection results, wherein obtaining the defect rate includes at least one of the following: Obtaining the thousand-line-of-code defect rate according to the number of defects in the defect detection result; Obtaining the defect density according to the number of defects of each type in the defect detection result and the weight of each type; Obtaining the file defect rate according to the ratio of the number of files containing defects in the defect detection result to the number of files; and The function defect rate is obtained according to the ratio of the number of functions containing defects in the defect detection result to the number of the first functions.

15. The software quality detection method according to any one of claims 5 to 14, wherein: The extracting of multiple metrics comprises: According to the software program source code, obtaining the first function quantity and the second function quantity; According to the procedure-level call graph, obtaining the out-degree and in-degree of each function; According to the file-level call graph, obtaining the number of interfaces and the number of files; and The third function quantity is obtained according to the software program source code, the control flow graph, the process-level call graph and the file-level call graph.

16. The software quality detection method according to any one of claims 1 to 15, wherein: According to the software program source code, extracting multiple metric elements includes: Based on AST-Matcher rules, information is extracted from the software program source code to obtain multiple metrics.

17. A software quality detection system, comprising: A design recovery module is configured to analyze the source code of the software program and construct a control flow graph, a procedure-level call graph, and a file-level call graph; An information extraction module is configured to extract a plurality of metrics based on the software program source code, the control flow graph, the process level call graph, and the file level call graph; An indicator acquisition module is configured to obtain intrinsic indicators and extrinsic indicators related to software quality detection based on the multiple metrics and using multiple measurement functions; as well as The quality detection module is configured to detect the software quality according to the intrinsic index and the extrinsic index.

18. A software quality detection system, comprising: Memory; as well as A processor coupled to the memory, wherein the processor is configured to execute the software quality detection method according to any one of claims 1 to 16 based on instructions stored in the memory.

19. A computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the software quality detection method according to any one of claims 1 to 16.

20. A computer program comprising: Instructions, when executed by a processor, cause the processor to perform the software quality detection method according to any one of claims 1 to 16.

Images