Software quality detection method and device, electronic equipment and medium

Abstract

The embodiment of the invention discloses a software quality detection method and device, electronic equipment and a medium, and relates to the technical field of computers.The specific implementation mode of the method comprises the steps that code data, operation data, historical test defect data and historical operation alarm data of software to be detected are obtained; based on the code data, the operation data, the historical test defect data and the historical operation alarm data, constructing a software knowledge graph reflecting an association relationship between internal entities of the to-be-tested software; and based on the software knowledge graph, performing quality analysis on the to-be-tested software to obtain a quality analysis result, and generating a quality analysis report according to the quality analysis result. The method can effectively reduce the human input and the detection period, improves the accuracy and efficiency of software quality detection by means of the deep correlation analysis capability of the knowledge graph, and meets the application scene requirements of large-scale centralized production and high-frequency iteration in the financial industry.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a software quality testing method, apparatus, electronic device, and medium. Background Technology

[0002] As the digital transformation of the financial industry deepens, application systems are iterating more frequently, and the scale of application software deployments continues to expand. The introduction of new technologies such as cloud-native, big data, and artificial intelligence, as well as the demand for upgrading domestically produced software and hardware, has further accelerated the pace of system updates. Against this backdrop, ensuring the quality and stability of large-scale, high-frequency application software deployments has become a key challenge for the fintech sector.

[0003] Currently, the relevant technologies mainly use human experience and standardized testing processes to identify risks and defects in the production version of the application. The testing methods mainly include code review, unit testing, functional testing, and non-functional testing, and rely on human review to confirm the results and identify incomplete test content and defects in test results.

[0004] However, the related technologies rely too heavily on expert experience, resulting in insufficient test coverage, high manpower investment, long testing cycles, and rules and standards that rely on manual writing and maintenance, leading to delayed updates and high management costs, making them unsuitable for high-frequency iteration needs. Summary of the Invention

[0005] This application provides a software quality inspection method, apparatus, electronic device, and medium to solve the problems in related technologies that rely too much on human experience, resulting in insufficient test coverage, low inspection efficiency, high maintenance costs of quality inspection rules, and inability to adapt to large-scale, high-frequency software iteration and production scenarios.

[0006] In a first aspect, embodiments of this application provide a software quality testing method, which includes: acquiring code data, runtime data, historical test defect data, and historical runtime alarm data of the software under test; constructing a software knowledge graph reflecting the relationships between internal entities of the software under test based on the code data, runtime data, historical test defect data, and historical runtime alarm data; performing quality analysis on the software under test based on the software knowledge graph to obtain quality analysis results, and generating a quality analysis report based on the quality analysis results.

[0007] In some embodiments, constructing a software knowledge graph reflecting the relationships between internal entities of the software under test based on code data, runtime data, historical test defect data, and historical runtime alarm data includes: extracting code elements, business objects, runtime components, and performance metrics from code data, runtime data, historical test defect data, and historical runtime alarm data; identifying code elements, business objects, runtime components, and performance metrics as graph nodes; constructing directed edges connecting graph nodes based on call chains, data flows, resource dependencies, and logical mapping relationships; and constructing the software knowledge graph based on the graph nodes and the directed edges connecting them.

[0008] In some embodiments, quality analysis of the software under test is performed based on a software knowledge graph to obtain quality analysis results, including: static analysis of the software under test based on code element nodes and their associated edges in the software knowledge graph to obtain static analysis results; dynamic analysis of the software under test based on business object nodes, runtime component nodes, and performance indicator nodes in the software knowledge graph to obtain dynamic analysis results; and fusion processing of the static and dynamic analysis results, combined with risk level determination rules, to obtain the final quality analysis result.

[0009] In some embodiments, static analysis is performed on the software under test based on code element nodes and their associated edges in the software knowledge graph. The static analysis results include: parsing and generating a code syntax tree of the software under test based on code element nodes and their associated edges in the software knowledge graph; and performing risk identification and semantic analysis on the code syntax tree based on preset risk pattern rules to obtain static analysis results. The preset risk pattern rules are generated based on historical test defect data.

[0010] In some embodiments, dynamic analysis is performed on the software under test based on business object nodes, runtime component nodes, and performance indicator nodes in the software knowledge graph. The dynamic analysis results include: determining model input data based on business object nodes, runtime component nodes, and performance indicator nodes in the software knowledge graph; inputting the model input data into a traffic generation model to generate traffic simulation data; reconstructing the business transaction chain of the software under test using traffic replay technology; and performing performance testing and anomaly detection on the software under test based on the business transaction chain and traffic simulation data to obtain dynamic analysis results.

[0011] In some embodiments, after performing quality analysis on the software under test based on the software knowledge graph and obtaining the quality analysis results, the method further includes: updating the graph node attributes and the association relationships between graph nodes in the software knowledge graph based on the effective defect information, risk correlations and adjustment suggestions in the quality analysis results.

[0012] Secondly, embodiments of this application provide a software quality testing device, the device comprising: The acquisition unit is used to acquire code data, runtime data, historical test defect data, and historical runtime alarm data of the software under test. The building unit is used to construct a software knowledge graph that reflects the relationships between internal entities of the software under test, based on code data, runtime data, historical test defect data, and historical runtime alarm data. The analysis unit is used to perform quality analysis on the software under test based on the software knowledge graph, obtain quality analysis results, and generate a quality analysis report based on the quality analysis results.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory for storing a computer program capable of running on the processor, wherein, when the processor runs the computer program, it performs the method described in any embodiment of the first aspect.

[0014] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described in any embodiment of the first aspect.

[0015] Fifthly, embodiments of this application provide a computer program product including a computer program that, when executed by a processor, performs the method described in any embodiment of the first aspect.

[0016] This application provides a software quality testing method that acquires code data, runtime data, historical test defect data, and historical runtime alarm data of the software under test. Based on the code data, runtime data, historical test defect data, and historical runtime alarm data, a software knowledge graph reflecting the relationships between internal entities of the software under test is constructed. Based on the software knowledge graph, quality analysis is performed on the software under test to obtain quality analysis results, and a quality analysis report is generated based on the quality analysis results. This method effectively solves the defects of related technologies, such as excessive reliance on human experience, insufficient test coverage, high costs, and lagging rules and standards. It significantly reduces manpower input and testing cycle, achieves comprehensive coverage of code logic, business scenarios, and abnormal branches, and improves the accuracy and efficiency of quality testing through the association analysis of the knowledge graph. It is suitable for the application scenarios of large-scale centralized production and high-frequency iteration in the financial industry, providing reliable assurance for the quality of application production versions.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are merely embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort, and this application can be applied to other similar scenarios based on the provided drawings.

[0019] Figure 1 A flowchart illustrating the first software quality detection method provided in this application embodiment; Figure 2 A flowchart illustrating the second software quality detection method provided in this application embodiment; Figure 3 A flowchart illustrating the third software quality detection method provided in this application embodiment; Figure 4 A schematic diagram of a software quality inspection model architecture provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a software quality testing device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. The described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that the terms "system," "device," "unit," and / or "module" used in this application are methods of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they can be replaced by other expressions.

[0022] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0023] As the digital transformation of the financial industry deepens, application systems are iterating more frequently, and the scale of application software deployments continues to expand. The introduction of new technologies such as cloud-native, big data, and artificial intelligence, as well as the demand for upgrading domestically produced software and hardware, has further accelerated the pace of system updates. Against this backdrop, ensuring the quality and stability of large-scale, high-frequency application software deployments has become a key challenge for the fintech sector.

[0024] Currently, the relevant technologies mainly employ a combination of human experience and standardized testing processes to identify risks and defects in production versions of application software. Specific testing methods encompass multiple stages, including code review, unit testing, functional testing, and non-functional testing. Each stage relies on manual review to confirm the results, verifying the completeness of test content and identifying potential defects in the test results.

[0025] However, the relevant technologies have obvious drawbacks: on the one hand, over-reliance on expert experience not only leads to insufficient test coverage, making it difficult to fully cover complex code logic and abnormal scenarios, but also affects the consistency of test results due to differences in personnel capabilities; on the other hand, high human involvement results in huge human resource costs and testing cycles that can last for several weeks, severely compressing the space for R&D iteration; at the same time, the rules and standards for quality testing need to be manually written and maintained, which not only increases management costs as the system becomes more complex, but also causes update delays, making it difficult to adapt to changes brought about by new technologies and new businesses in a timely manner, and failing to meet the actual needs of high-frequency iteration.

[0026] To address the aforementioned issues, this application proposes a software quality testing method. By integrating the code data, runtime data, and historical quality-related data of the software under test to construct a software knowledge graph, quality analysis is conducted based on this graph, generating reports. This method effectively solves core shortcomings such as excessive reliance on human experience, incomplete test coverage, high manpower and time costs, and lagging rule and standard updates. It not only significantly reduces manpower input and shortens the testing cycle but also achieves full coverage of code logic, business scenarios, and abnormal branches. Furthermore, leveraging the deep association analysis capabilities of the knowledge graph further improves the accuracy and efficiency of software quality testing, adapting to the application scenarios of large-scale centralized production and high-frequency iteration in the financial industry, providing a solid and reliable guarantee for the quality of production versions of application software.

[0027] The following section provides a detailed description of a software quality testing method provided in this application, with reference to the accompanying drawings.

[0028] Figure 1 A flowchart of a software quality inspection method provided in an embodiment of this application is shown. Figure 1 As shown, the software quality inspection method includes steps 101-103.

[0029] Step 101: Obtain the code data, runtime data, historical test defect data, and historical runtime alarm data of the software under test.

[0030] In the embodiments of this application, the software under test specifically refers to the application version in the financial industry that is yet to be put into production and launched. The core is a software system or module related to financial business, such as a bank's transfer transaction system, an insurance policy management system, etc., which directly carries the core financial business; or a software sub-version that provides support for the core business, such as a user identity authentication module, payment and settlement component, data report generation plugin, etc.

[0031] Code data refers to the complete source code and related configuration files of the software under test, including business logic code (such as Java / Python source code), configuration files, dependency package list, database scripts, etc.

[0032] Runtime data refers to real-time data generated when software is running in a test or pre-production environment, such as CPU (Central Processing Unit) utilization, memory usage, response time, and API call frequency.

[0033] Historical test defect data: Details of defects recorded in previous version tests, including defect type (such as logical error, syntax error), occurrence scenario, fix, and associated code module.

[0034] Historical alarm data: Records of abnormal alarms triggered during the software's historical operation, such as timeout alarms, resource exhaustion alarms, and interface call failure alarms.

[0035] Specifically, lightweight probes (Agents) are deployed in application servers and networks to non-intrusively collect runtime performance metrics and business logs. Data is obtained through API calls or direct access to code repositories, defect management systems (such as Jira), and operation and maintenance monitoring platforms (such as Zabbix and Prometheus). The acquired data is then uniformly stored in a distributed database, indexed, and supports rapid querying by module, time, issue type, and other dimensions.

[0036] Step 102: Based on code data, runtime data, historical test defect data, and historical runtime alarm data, construct a software knowledge graph that reflects the relationships between internal entities of the software under test.

[0037] In the embodiments of this application, a software knowledge graph refers to a structured semantic network with "entities, relationships, and attributes" as its core, serving as a fusion carrier for multi-dimensional software data. Here, "entities" correspond to the core elements of the software (code, business, operation, defects, etc.), "relationships" correspond to the logical connections between entities (such as code calls, data dependencies, defect triggers), and "attributes" correspond to the characteristic information of entities (such as the number of parameters in a method, the response time threshold of an interface).

[0038] Internal entities encompass the core elements of the entire software lifecycle, including independent units at the code, business, runtime, and quality levels. Relationships refer to the logical mappings between entities, including code-level call relationships (e.g., method A calling method B), data-level flow relationships (e.g., interface A writing data to database B), business-level process relationships (transaction A depending on the result of transaction B), quality-level causal relationships (e.g., defect A causing alarm B), and resource-level dependencies (e.g., application A depending on cache B).

[0039] Specifically, technologies such as natural language processing, code analysis, and pattern recognition are used to automatically identify and extract key entity objects from multi-source data. For example, classes and methods are parsed from code; business keywords and operational objects are identified from logs and documents. By analyzing the inherent relationships between data, association edges are established between entities. For example, call relationships are established by analyzing the function call stack of code; relationships that introduce defects are established by associating historical defects with code submissions. The identified entities (as nodes) and relationships (as edges), along with their rich attribute information, are used to construct a dynamic and visualized software knowledge graph.

[0040] Step 103: Based on the software knowledge graph, perform quality analysis on the software under test to obtain the quality analysis results, and generate a quality analysis report based on the quality analysis results.

[0041] In the embodiments of this application, the quality analysis types include two categories: static analysis and dynamic analysis. Static analysis refers to detecting potential risks at the code level (such as syntax errors, logical vulnerabilities, and security risks) based solely on code structure, syntax rules, and historical defect patterns without running the software. Dynamic analysis refers to discovering software quality problems by actually running the software program and monitoring its performance and behavior under specific inputs and environments (such as stress and anomalies).

[0042] Specifically, based on code entities (such as classes, methods, and interfaces), code relationships (calls and dependencies), historical defect entities, and related relationships in the software knowledge graph, combined with a risk rule base trained on historical defect data, static analysis is performed on the software under test to identify code errors, business logic contradictions, etc., and output a list of code defects, including defect location (related graph code nodes), defect type, risk level, and remediation plan. Based on business process entities in the software knowledge graph, core business links are selected, and key interfaces, dependent components, and performance benchmark thresholds in these links are determined. High-concurrency, highly realistic simulated traffic is generated and injected into the software under test, combining historical operational data and business ratios. Performance monitoring tools are used to collect metrics such as interface response time and error rate, and link tracing tools are used to locate performance bottlenecks (e.g., slow interface response due to excessively long database query times). Simultaneously, component failures are simulated (e.g., database crashes, cache timeouts) to test the software's fault tolerance and degradation mechanisms, and the impact range of failures is analyzed by relating them to resource dependencies in the knowledge graph. Based on this dynamic analysis process, a performance bottleneck list and a stability issue list are finally output, including the issue location (nodes of running components in the knowledge graph), triggering conditions, impact range, and optimization suggestions.

[0043] Utilize large language models (such as GPT-4) to understand structured analysis results and automatically generate detailed reports that include a defect list (with code location), risk level, impact scope, remediation recommendations, and overall quality score.

[0044] In summary, the software quality inspection method proposed in this application involves acquiring the code data, runtime data, historical test defect data, and historical runtime alarm data of the software under test. Based on these data, a software knowledge graph reflecting the relationships between internal entities within the software under test is constructed. Based on this knowledge graph, quality analysis is performed on the software under test to obtain the analysis results, which are then used to generate a quality analysis report. This method effectively reduces manpower and testing cycles, achieving comprehensive coverage of code logic, business scenarios, and abnormal branches. Furthermore, the association analysis of the knowledge graph enhances the accuracy and efficiency of quality inspection, adapting to the application scenarios of large-scale centralized production and high-frequency iteration in the financial industry, and providing reliable assurance for the quality of production versions of applications.

[0045] As one possible implementation method, Figure 2 A flowchart of a second software quality inspection method provided in an embodiment of this application is shown. Based on the above embodiments, a software knowledge graph reflecting the relationships between internal entities of the software under test is constructed based on code data, runtime data, historical test defect data, and historical runtime alarm data, including the following steps: Step 201: Extract code elements, business objects, running components, and performance metrics from code data, runtime data, historical test defect data, and historical runtime alarm data.

[0046] In the embodiments of this application, code elements are the core constituent units at the software code level and are the basic carriers for implementing functional logic, including applications, classes, methods, functions, variables, interfaces, code branches, etc.

[0047] The business objects are the core entities directly related to the business scenarios carried by the software, including transaction types (such as transfers and payments), account types (such as savings accounts and credit card accounts), and business processes (such as account opening processes and repayment processes).

[0048] Runtime components are the underlying infrastructure and middleware that support software operation, including servers, databases, middleware (such as Redis and Kafka), storage devices, operating systems, etc.

[0049] Performance metrics are quantitative data that reflect the operating status and efficiency of software. They are the core basis for evaluating the non-functional quality of software and include CPU utilization, memory usage, interface response time, transaction success rate, and error rate.

[0050] Specifically, code analysis tools scan source code files to identify and extract information such as class names, method names, variable names, interface definitions, and code branch structures, forming a list of code elements. Deployed data collection probes capture real-time infrastructure information (such as server address, database instance name, and middleware type) as runtime components; simultaneously, they collect quantitative data such as CPU usage, memory consumption, and response time at the second / minute level as raw data for performance metrics. Combining code comments, business descriptions in runtime logs (such as "transfer transaction initiated" and "account balance verification"), and business scenario annotations in historical test defect data, entities strongly related to actual business operations are extracted, clarifying the names and core attributes of business objects (such as the amount of the transfer transaction, the payer, and the payee).

[0051] Step 202: Identify code elements, business objects, running components, and performance metrics as graph nodes.

[0052] In the embodiments of this application, the graph node is the core building block of the software knowledge graph, used to carry a specific type of information. Each node corresponds to a specific entity and is the connecting carrier of the association relationship.

[0053] The four types of entities extracted in step 201 are divided into four node types of the knowledge graph: "code element node", "business object node", "running component node" and "performance indicator node", and the node type identifier is clearly defined.

[0054] Step 203: Based on the call chain, data flow, resource dependencies and logical mapping relationships, construct directed edges connecting the nodes of the graph.

[0055] In the embodiments of this application, the call chain refers to the call relationship path between code elements or business processes, such as "method A calls method B". Data flow refers to the path of business data transmission between different nodes. Resource dependency refers to the dependency relationship between the underlying running components during software operation, such as "code method A depends on database B". Logical mapping relationship refers to the business logic association between different types of nodes, such as "historical defect A is associated with code method B", "performance indicator M corresponds to running component N", etc. A directed edge refers to a line segment connecting two graph nodes, used to represent the association relationship between nodes.

[0056] Specifically, the system constructs association edges between code elements based on the call chain; it constructs association edges between business objects and code elements, and between code elements and running components based on the data flow; it constructs association edges between running components based on resource dependencies; and it constructs association edges between historical defects and code elements, and between alarm data and running components based on logical mappings.

[0057] Step 204: Construct a software knowledge graph based on the graph nodes and the directed edges connecting the graph nodes.

[0058] In the embodiments of this application, a graph database (such as Neo4j) is used to store graph nodes and directed edges. The storage structure of the association relationship is optimized by graph computing algorithms (such as shortest path analysis) to form a complete software knowledge graph that supports multi-dimensional query and association analysis.

[0059] In summary, this application automates the extraction and definition of code, business, operational, and performance entities as graph nodes from multi-source heterogeneous data, and constructs directed edges based on their inherent technical and logical connections, thereby automatically building a comprehensive, accurate, and queryable software knowledge graph. This process integrates previously isolated code, operational, and maintenance data into a unified knowledge network rich in semantic relationships, providing a core data foundation and reasoning framework for achieving intelligent quality inspection based on deep contextual understanding.

[0060] As one possible implementation method, Figure 3 A flowchart of a third software quality inspection method provided in this application is shown. Based on the above embodiments, a quality analysis is performed on the software under test using a software knowledge graph to obtain the quality analysis results, including the following steps: Step 301: Based on the code element nodes and their associated edges in the software knowledge graph, perform static analysis on the software under test to obtain the static analysis results.

[0061] In the embodiments of this application, static analysis refers to quality inspection conducted solely based on the static structure, syntax logic, and relationships of the code without running the software under test. The core objective is to identify potential defects at the code level (such as logical errors, syntax vulnerabilities, and compliance issues). For static testing, all code is tested based on testing rules.

[0062] Based on the code element nodes and their associated edges in the software knowledge graph, the specific process for static analysis of the software under test in this application is as follows: 1) Based on the code element nodes and their associated edges in the software knowledge graph, the code syntax tree of the software under test is generated by parsing. Among them, the code syntax tree refers to breaking down the syntactic structure of the source code into structured tree nodes (such as expressions, loop statements, and conditional statements), which intuitively presents the logical hierarchy and syntactic relationships of the code.

[0063] Specifically, all code element nodes (such as "user recharge method" and "order calculation function") and the connecting edges between nodes (such as "recharge method -> call balance update method") are extracted from the software knowledge graph to clarify the calling logic and structural relationships of the code. Using code parsing tools (such as Java's ASTParser and Python's AST module), the source code is converted into a code syntax tree based on the code element nodes and connecting edges, thus breaking down the code's syntactic hierarchy.

[0064] 2) Based on the preset risk pattern rules, risk identification and semantic analysis are performed on the code syntax tree to obtain static analysis results. The preset risk pattern rules are generated based on historical test defect data.

[0065] Specifically, it calls preset risk pattern rules from a rule base, which is automatically generated and continuously updated based on historical test defect data, covering scenarios such as code syntax errors, logic vulnerabilities, security risks, and compliance issues. It traverses each node of the code syntax tree, matching the node logic with the preset risk pattern rules; simultaneously, it performs semantic analysis based on the related edges of code element nodes (such as parameter passing paths and method call relationships) to determine whether variable scope is reasonable, whether there are unprocessed return values, and whether permission checks are complete.

[0066] Mark code snippets that match the risk pattern, associate them with the corresponding code element node identifiers, clarify the defect type (such as "loop condition exception" or "uninitialized variable call") and severity (high / medium / low), and form a structured static analysis result.

[0067] The preset risk pattern rules are standardized detection rules mined and refined from historical test defect data, used to match risk scenarios in the code (such as "null pointer not checked" or "missing permission verification"). An example of the preset risk pattern rule generation process is as follows: First, using 230,000 historical defect cases as the core data source, common features of defects are extracted through data mining algorithms (such as association rule mining and cluster analysis), including the syntax structure, logical association, and business scenario association at the code level. These common features are then transformed into structured initial rule expressions, clarifying the matching conditions, risk type labels, and initial severity of each rule, and constructing the basic version of the preset risk pattern rule base. Simultaneously, a weekly rule self-generation process is initiated, automatically analyzing newly added defect cases and missed / false alarm records in detection results to uncover new risk patterns not covered by existing rules. New rules are automatically generated and added to the rule base at a frequency of 12-15 per week. At the same time, based on the real-time statistical false alarm rate, the detection sensitivity of existing rules is dynamically adjusted by ±15% (e.g., lowering the matching threshold for high false alarm rules and increasing the trigger priority for high missed detection rules).

[0068] Step 302: Based on the business object nodes, running component nodes, and performance indicator nodes in the software knowledge graph, perform dynamic analysis on the software under test to obtain dynamic analysis results.

[0069] In the embodiments of this application, dynamic analysis refers to quality testing conducted based on the real-time operating status of the software by running the software under test to simulate real business scenarios and operating environments. The core objective is to verify performance, business adaptability, and anomaly handling capabilities. For dynamic testing, real-time acquired software-related data is used as input, and simulation data is generated using a traffic generation model to perform traffic replay testing.

[0070] Based on the business object nodes, runtime component nodes, and performance indicator nodes in the software knowledge graph, the specific process for dynamic analysis of the software under test in this application is as follows: 1) Determine the model input data based on the business object nodes, runtime component nodes, and performance indicator nodes in the software knowledge graph; Specifically, business object nodes (such as "high-frequency transfer transactions" and "large-amount payment transactions"), runtime component nodes (such as "application server clusters" and "database instances"), and performance indicator nodes (such as "target response time <300ms" and "concurrency capacity ≥1000TPS") are extracted from the software knowledge graph. Business scenario requirements, runtime environment configurations, and performance threshold requirements are then integrated into the model input data for the traffic generation model.

[0071] 2) Input the model input data into the traffic generation model to generate traffic simulation data; Specifically, the traffic generation model can be a simulation data generation model trained based on generative adversarial networks (GANs), which can simulate the characteristics of real business traffic (such as request frequency, parameter distribution, and peak pressure).

[0072] Specifically, the model input data is fed into the traffic generation model to generate traffic data that is highly similar to real business, including normal traffic (such as regular transfer requests) and abnormal traffic (such as parameter errors, high concurrency peaks, and network latency simulations), covering core business scenarios and edge scenarios.

[0073] 3) Reconstruct the business transaction chain of the software under test using traffic replay technology, and perform performance testing and anomaly detection on the software under test based on the business transaction chain and traffic simulation data to obtain dynamic analysis results.

[0074] Specifically, using traffic replay tools (such as a customized version of JMeter or Gatling), the complete business transaction chain is reconstructed based on the association edges between business object nodes and code elements and running component nodes in the knowledge graph (such as "user initiates transfer -> calls identity verification interface -> queries account balance -> deducts amount -> updates database -> returns result"). Simulated traffic data is injected into the software under test to conduct performance testing (concurrency stress testing, long-term stability testing) and anomaly detection (simulating server crash, database connection failure, network interruption).

[0075] Real-time monitoring of the status and performance metrics of running component nodes, including actual node data (such as actual response time, CPU utilization, and error rate), records whether performance meets standards, whether abnormal scenarios trigger expected processing logic (such as timeout prompts and failure retries), and bottleneck locations (such as "database query takes too long"), generating dynamic analysis results.

[0076] Step 303: The static analysis results and dynamic analysis results are fused and processed, and combined with the risk level determination rules, to obtain the quality analysis results.

[0077] In the embodiments of this application, code defects discovered through static analysis and runtime issues discovered through dynamic analysis are aggregated and attributed within the framework of a software knowledge graph. For example, a timeout alarm in a dynamic test is associated with a specific code method and server resource bottlenecks linked to the graph to pinpoint the root cause.

[0078] Based on the preset risk level determination rules (such as comprehensively considering the severity of the defect, the scope of business impact, the difficulty of repair, and the frequency of historical occurrence), a comprehensive risk assessment and level classification (such as "severe", "high", "medium", "low") is carried out for each discovered problem, forming the final quality analysis result.

[0079] In some embodiments, after performing quality analysis on the software under test based on the software knowledge graph and obtaining the quality analysis results, the method further includes: updating the graph node attributes and the relationships between graph nodes in the software knowledge graph based on the effective defect information, risk correlations and adjustment suggestions in the quality analysis results.

[0080] Among them, valid defect information refers to genuine defect records that have been manually confirmed or automatically verified (excluding false positives), including defect details, remediation plans, and verification results. Risk correlation refers to the potential association between defects and other graph nodes (such as "performance defects -> associated server resource insufficiency" or "code defects -> associated specific business scenarios"). Adjustment suggestions refer to rectification plans and optimization suggestions for defects (such as "optimize SQL query statements" or "add a caching layer to reduce database pressure").

[0081] Specifically, valid defect information, risk correlations, and adjustment suggestions are screened from the quality analysis results, while false positives and invalid data are eliminated. Supplementary attributes are added to the associated graph nodes, such as adding tags like "Historical Defect: Null Pointer Risk" and "Remediation Status: Rectified" to code element nodes; and adding tags like "Performance Bottleneck: High CPU Usage" and "Optimization Suggestion: Upgrade to 8 Cores 16GB" to runtime component nodes. Based on risk correlations, the association edges between nodes are supplemented or strengthened; if the original association edge descriptions are inaccurate, the labels and attributes of the association edges are corrected.

[0082] The updated software knowledge graph will serve as the foundational data for the next round of quality inspection, enabling subsequent inspections to accurately cover historical defect scenarios and adapt to the optimized operating environment.

[0083] In summary, this application constructs an intelligent, closed-loop software quality testing system through the logic of accurately identifying code defects via static analysis, comprehensively verifying operational quality via dynamic analysis, achieving multi-dimensional evaluation through result fusion, and continuously optimizing via knowledge graph self-updating. This system not only solves the problems of incomplete coverage in traditional static testing and the limited scope of dynamic testing scenarios, but also continuously improves the accuracy and adaptability of testing through the association analysis and self-updating capabilities of the knowledge graph, perfectly meeting the needs of large-scale production and high-frequency iteration scenarios in the financial industry.

[0084] In one example, to help better understand the software quality inspection scheme provided in this application, such as Figure 4 As shown, Figure 4 This is a schematic diagram of a software quality inspection model architecture provided in an embodiment of this application. The software quality inspection method provided in this application is implemented through the software quality inspection model.

[0085] Reference Figure 4 The software quality inspection model comprises three core layers from top to bottom: a data acquisition layer, an intelligent processing layer, and an application output layer. The data acquisition layer is used to uniformly complete the collection of runtime data, code acquisition, and historical data of the software under test by deploying multiple types of probe agents, thereby achieving centralized and standardized collection of multi-source data; The intelligent processing layer is used to perform intelligent feature extraction (to construct a software knowledge graph) and multimodal analysis engine processing (static analysis and dynamic analysis) on the data collected by the data acquisition layer. It also completes the self-generation of rules (i.e., preset risk mode rules), threshold adjustment and self-evolution of the software knowledge graph through an adaptive decision system, thereby achieving autonomous optimization of detection capabilities. The application output layer is used to automatically generate quality inspection reports and visual monitoring dashboards based on the analysis results of the intelligent processing layer, providing direct support for production decisions.

[0086] The specific implementation process is as follows: First, the data acquisition layer uses probe agents with different functions to synchronously collect the running data (such as CPU utilization and interface response time), code data, historical test defect data and historical running alarm data of the software under test, and aggregate the scattered multi-source data into the data pool. Secondly, the intelligent processing layer retrieves all data from the data pool. First, through the intelligent feature extraction module, it transforms core information such as code elements, business objects, and running components into nodes and edges of the knowledge graph, thus constructing the software knowledge graph. Then, the knowledge graph data is input into the multimodal analysis engine to perform static analysis (parsing the code syntax tree and matching risk pattern rules) and dynamic analysis (generating simulated traffic and conducting traffic replay tests), obtaining two types of analysis results. Finally, the adaptive decision-making system automatically generates new detection rules and dynamically adjusts the detection sensitivity based on the analysis results, and feeds back defect handling information to the software knowledge graph to optimize the detection strategy. Finally, based on the quality analysis results from the intelligent processing layer, the application output layer automatically generates a quality inspection report containing defect details, risk levels, and rectification suggestions. At the same time, it generates a real-time visual monitoring dashboard (displaying core information such as performance indicators and defect distribution), directly supporting the production decision of the software under test.

[0087] To implement the above embodiments, this application also provides a software quality testing device. Figure 5 This is a schematic diagram of the structure of a software quality inspection device 500 provided in an embodiment of this application. Figure 5 As shown, the device includes: The acquisition unit 501 is used to acquire the code data, runtime data, historical test defect data, and historical runtime alarm data of the software under test. Construction unit 502 is used to construct a software knowledge graph that reflects the relationships between internal entities of the software under test based on code data, runtime data, historical test defect data, and historical runtime alarm data. Analysis unit 503 is used to perform quality analysis on the software under test based on software knowledge graph, obtain quality analysis results, and generate a quality analysis report based on the quality analysis results.

[0088] In some embodiments of this application, the construction unit 502 is used to: extract code elements, business objects, running components, and performance indicators from code data, runtime data, historical test defect data, and historical runtime alarm data; determine the code elements, business objects, running components, and performance indicators as graph nodes; construct directed edges connecting graph nodes based on call chains, data flow, resource dependencies, and logical mapping relationships; and construct a software knowledge graph based on the graph nodes and the directed edges connecting the graph nodes.

[0089] In some embodiments of this application, the analysis unit 503 is used to: perform static analysis on the software under test based on the code element nodes and their associated edges in the software knowledge graph to obtain static analysis results; perform dynamic analysis on the software under test based on the business object nodes, running component nodes, and performance indicator nodes in the software knowledge graph to obtain dynamic analysis results; and fuse the static analysis results and dynamic analysis results, and combine them with risk level determination rules to obtain quality analysis results.

[0090] In some embodiments of this application, the analysis unit 503 is used to: parse and generate a code syntax tree of the software under test based on the code element nodes and the associated edges of the code element nodes in the software knowledge graph; and perform risk identification and semantic analysis on the code syntax tree based on preset risk pattern rules to obtain static analysis results. The preset risk pattern rules are generated based on historical test defect data.

[0091] In some embodiments of this application, the analysis unit 503 is used to: determine model input data based on business object nodes, running component nodes, and performance indicator nodes in the software knowledge graph; input the model input data into the traffic generation model to generate traffic simulation data; reconstruct the business transaction link of the software under test through traffic replay technology, and perform performance testing and anomaly detection on the software under test based on the business transaction link and traffic simulation data to obtain dynamic analysis results.

[0092] In some embodiments of this application, the apparatus further includes: an updating unit, used to update the graph node attributes and the relationships between graph nodes in the software knowledge graph based on the valid defect information, risk correlations and adjustment suggestions in the quality analysis results.

[0093] The methods and apparatus provided in the embodiments of this application have been described above. To implement the functions of the methods provided in the embodiments of this application, the electronic device may include a hardware structure and software modules, and may implement the above functions in the form of a hardware structure, software modules, or a hardware structure plus software modules. One of the above functions may be executed in the form of a hardware structure, software modules, or a hardware structure plus software modules.

[0094] Figure 6 This is a block diagram illustrating an electronic device 600 for implementing the above-described software quality inspection method, according to an exemplary embodiment. For example, the electronic device 600 may be a mobile phone, computer, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0095] Reference Figure 6 The electronic device 600 may include a communication interface 601, capable of interacting with other devices; a processor 602, connected to the communication interface 601 to interact with other devices, used to execute the methods provided by one or more of the above-described technical solutions when running a computer program; and a memory 603, on which the computer program is stored. Specifically, the specific processing procedure of the processor 602 can refer to the software quality detection method described in the above embodiments of this application.

[0096] Of course, in practical applications, the various components in electronic device 600 are coupled together through bus system 604. It can be understood that bus system 604 is used to realize the connection and communication between these components. In addition to a data bus, bus system 604 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in... Figure 6 The general designated all buses as Bus System 604.

[0097] The memory 603 in this embodiment is used to store various types of data to support the operation of the electronic device 600. Examples of such data include any computer program used to operate on the electronic device 600.

[0098] The methods disclosed in the embodiments of this application can be applied to processor 602, or implemented by processor 602. Processor 602 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 602 or by instructions in the form of software. The processor 602 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 602 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 603. Processor 602 reads the information in memory 603 and combines it with its hardware to complete the steps of the aforementioned method.

[0099] In an exemplary embodiment, the electronic device 600 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0100] Embodiments of this application also propose a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the software quality detection method described in the above embodiments of this application.

[0101] Embodiments of this application also propose a computer program product, including a computer program, which is executed by a processor using the software quality detection method described in the above embodiments of this application.

[0102] Embodiments of this application also propose a chip including one or more interface circuits and one or more processors; the interface circuits are used to receive signals from the memory of an electronic device and send signals to the processors, the signals including computer instructions stored in the memory, and when the processor executes the computer instructions, it causes the electronic device to perform the software quality detection method described in the above embodiments of this application.

[0103] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0104] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0105] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0106] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0107] It should be understood that various parts of the embodiments of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0108] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0109] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc.

[0110] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A software quality inspection method, characterized in that, include: Acquire code data, runtime data, historical test defect data, and historical runtime alarm data of the software under test; Based on the code data, the runtime data, the historical test defect data, and the historical runtime alarm data, a software knowledge graph reflecting the relationships between internal entities of the software under test is constructed. Based on the software knowledge graph, a quality analysis is performed on the software under test to obtain the quality analysis results, and a quality analysis report is generated based on the quality analysis results.

2. The method according to claim 1, characterized in that, The construction of a software knowledge graph reflecting the relationships between internal entities of the software under test, based on the code data, the runtime data, the historical test defect data, and the historical runtime alarm data, includes: Code elements, business objects, runtime components, and performance metrics are extracted from the code data, runtime data, historical test defect data, and historical runtime alarm data. The code elements, the business objects, the running components, and the performance metrics are identified as graph nodes; Based on the call chain, data flow, resource dependencies, and logical mapping relationships, directed edges connecting the nodes of the graph are constructed; The software knowledge graph is constructed based on the graph nodes and the directed edges connecting the graph nodes.

3. The method according to claim 1, characterized in that, The quality analysis of the software under test based on the software knowledge graph, and the resulting quality analysis results include: Based on the code element nodes and their associated edges in the software knowledge graph, static analysis is performed on the software under test to obtain static analysis results. Based on the business object nodes, running component nodes, and performance indicator nodes in the software knowledge graph, the software under test is dynamically analyzed to obtain dynamic analysis results. The static analysis results and the dynamic analysis results are fused together and combined with the risk level determination rules to obtain the quality analysis results.

4. The method according to claim 3, characterized in that, The static analysis of the software under test, based on the code element nodes and their associated edges in the software knowledge graph, yields the following results: Based on the code element nodes and their associated edges in the software knowledge graph, the code syntax tree of the software under test is generated. Based on preset risk pattern rules, risk identification and semantic analysis are performed on the code syntax tree to obtain the static analysis results. The preset risk pattern rules are generated based on the historical test defect data.

5. The method according to claim 3, characterized in that, The dynamic analysis of the software under test, based on the business object nodes, runtime component nodes, and performance indicator nodes in the software knowledge graph, yields the following results: Based on the business object nodes, running component nodes, and performance indicator nodes in the software knowledge graph, the model input data is determined. The model input data is input into the traffic generation model to generate traffic simulation data; The business transaction chain of the software under test is reconstructed using traffic replay technology. Based on the business transaction chain and the traffic simulation data, performance testing and anomaly detection are performed on the software under test to obtain the dynamic analysis results.

6. The method according to claim 1, characterized in that, After performing quality analysis on the software under test based on the software knowledge graph and obtaining the quality analysis results, the method further includes: Based on the effective defect information, risk correlations, and adjustment suggestions in the quality analysis results, update the graph node attributes and the correlations between graph nodes in the software knowledge graph.

7. A software quality inspection device, characterized in that, The device includes: The acquisition unit is used to acquire code data, runtime data, historical test defect data, and historical runtime alarm data of the software under test. The construction unit is used to construct a software knowledge graph that reflects the relationships between internal entities of the software under test based on the code data, the runtime data, the historical test defect data, and the historical runtime alarm data. The analysis unit is used to perform quality analysis on the software under test based on the software knowledge graph, obtain quality analysis results, and generate a quality analysis report based on the quality analysis results.

8. An electronic device, characterized in that, include: The processor and the memory used to store computer programs that can run on the processor. When the processor is used to run the computer program, it performs the method according to any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 6.

Images