Code testing method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of test management, and discloses a code testing method and device, an electronic device and a storage medium, which comprise the following steps: acquiring dynamic running information and historical life cycle information of a target code unit; performing code quality evaluation on the target code unit based on the historical life cycle information to obtain historical quality information; performing code portrait construction based on the dynamic running information and the historical quality information to obtain a risk heat quantification portrait; performing risk heat category prediction on the target code unit based on the risk heat quantification portrait to obtain a code risk heat category; generating a code test coverage rate threshold of the target code unit based on the code risk heat category; and performing code test on the target code unit based on the code test coverage rate threshold to obtain target code test information. The application can be applied to the financial science and technology scene and the health care scene, and the execution efficiency of code test is improved.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence technology and test management technology, and can be applied to fintech and healthcare scenarios. In particular, it relates to a code testing method, device, electronic device, and storage medium. Background Technology

[0002] Code testing is used to verify the quality and logic of various code modules throughout the software lifecycle, ensuring highly reliable delivery from code writing to business deployment. Taking the development of a wealth management and trading system in the financial sector as an example, scientific code testing can rigorously guarantee the robustness of high-risk business code such as core fund allocation and high-frequency settlement, providing high-coverage quality support for the security of funds and high-concurrency processing in financial businesses, significantly reducing the business risks and emergency repair costs caused by production environment downtime for financial institutions. Similarly, in the development of an online consultation system in the healthcare sector, a well-planned code testing strategy can focus on strengthening testing of core modules such as electronic prescription issuance and patient medical record transfer, providing medical institutions with a stable and reliable digital healthcare service foundation, and ensuring the quality of high-frequency data transfer and patient privacy security within the medical system.

[0003] Currently, common code testing methods typically begin by setting global test metrics for the entire codebase based on preset static rules, resulting in a uniform code test coverage threshold. Subsequently, based on this uniform threshold, automated tests are performed on each code module within the entire codebase without differentiation, generating a global code test report. However, this method solidifies all modules within the codebase under the same acceptance criteria. When faced with complex code modules with varying call frequencies and historical defect profiles, this static and indiscriminate testing approach leads to insufficient testing of core, frequently used code, while meaninglessly over-testing less important and older code. This results in the testing team's resource allocation failing to effectively align with the underlying real-world business risk distribution, and fails to meet the requirements of differentiated quality assurance for heterogeneous code modules in modern software development scenarios, ultimately leading to a significant decrease in overall code testing efficiency. Therefore, improving code testing efficiency has become a pressing technical problem. Summary of the Invention

[0004] This invention provides a method, apparatus, computer equipment, and medium for testing code in artificial intelligence. It aims to solve the technical problem that existing code testing methods, which use a static and undifferentiated coverage evaluation system, cannot perform differentiated testing on code modules with different internal operating states, resulting in low overall code testing efficiency. The invention aims to improve the execution efficiency of code testing.

[0005] Firstly, a code testing method is provided for application in code testing systems, including: Obtain dynamic runtime information and historical lifecycle information of the target code unit; Based on the historical lifecycle information, code quality is evaluated on the target code unit to obtain historical quality information; Based on the dynamic operation information and the historical quality information, a code profile is constructed to obtain a quantitative profile of risk heat. Based on the aforementioned risk heat quantitative profile, the risk heat category of the target code unit is predicted to obtain the code risk heat category; Based on the code risk heat category, generate the code test coverage threshold for the target code unit; Based on the code test coverage threshold, code testing is performed on the target code unit to obtain target code test information.

[0006] Secondly, a code testing device is provided, including: The information acquisition module is used to acquire dynamic runtime information and historical lifecycle information of the target code unit; The code evaluation module is used to evaluate the code quality of the target code unit based on the historical lifecycle information to obtain historical quality information; The profile building module is used to build a code profile based on the dynamic operation information and the historical quality information to obtain a quantitative profile of risk heat. The category prediction module is used to predict the risk popularity category of the target code unit based on the risk popularity quantitative profile, so as to obtain the code risk popularity category. The threshold mapping module is used to generate the code test coverage threshold of the target code unit based on the code risk heat category. The code testing module is used to perform code testing on the target code unit based on the code test coverage threshold, and obtain target code test information.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described code testing method.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described code testing method.

[0009] In the aforementioned code testing method, apparatus, computer equipment, and storage medium, the target code unit can first be evaluated for code quality using historical lifecycle information. This yields historical quality information that comprehensively reflects the historical instability of the code, providing a historical data foundation for subsequent risk assessment. Based on this, a quantitative profile of risk heat is constructed by integrating dynamic operational information and historical quality information. This allows the business activity and quality risk of the code module to be jointly represented in a unified mathematical space, providing a calculable feature basis for the formulation of differentiated testing strategies. Subsequently, the quantitative profile is transformed into interpretable code risk heat category labels through risk heat category prediction, achieving qualitative classification of the code module in both heat and risk dimensions. Then… Based on the risk level of code, differentiated code test coverage thresholds are adaptively generated. This ensures that core code modules with high risk and high popularity receive strong test coverage, while peripheral code modules with low risk and low popularity only need to meet basic test requirements. This achieves a shift from uniform allocation of test resources to precise deployment. Finally, code testing is performed based on differentiated code test coverage thresholds, ensuring that the investment of test resources matches the actual business risks of the code modules. This avoids the resource mismatch problem of insufficient testing of core code and excessive testing of secondary code in traditional static uniform threshold methods. As a result, while ensuring the quality of core code, the computational resource consumption of overall test execution is effectively reduced, the test cycle is significantly shortened, and the execution efficiency of code testing is improved. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of an application environment for a code testing method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a code testing method in one embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of a specific implementation method for step S20; Figure 4 yes Figure 2 A schematic diagram of a specific implementation method for step S30; Figure 5 yes Figure 2 A schematic diagram of a specific implementation of step S40; Figure 6This is a schematic diagram of a code testing device in one embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 8 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] The code testing method provided in this embodiment of the invention can be applied to, for example, Figure 1 In the application environment shown, the client communicates with the server via a network. The server can receive dynamic code execution information and historical code lifecycle information generated during the software development process from the client. Based on this information, the server performs code quality assessment and profile construction, obtaining a quantitative profile of the risk heat of the target code unit. This quantitative profile includes a dual-dimensional fusion of code heat characteristics and code risk characteristics. Based on the quantitative profile, the server predicts risk heat categories to obtain code risk heat categories. Based on these categories, a code test coverage threshold is generated. Finally, based on the test coverage threshold, the server performs code testing on the target code unit to obtain target code test information. In this invention, for software testing business entities, code quality assessment and profiling are performed based on pre-acquired dynamic code execution information and historical code lifecycle information. This yields a quantitative profile of the risk heat of the target code unit. Then, by quantifying two characteristics—code heat and code risk—these are transformed into code risk heat categories. Finally, differentiated code test coverage thresholds are generated based on these risk heat categories. This ensures a high correlation between the code test coverage thresholds and the actual business risks of the code modules. This solves the technical problems of traditional code testing, which uses uniform static thresholds, leading to unreasonable allocation of test resources, insufficient investment in core high-frequency code testing, and excessive testing of secondary, outdated code. It improves the execution efficiency and rationality of test resource allocation, while reducing overall testing computational resource consumption and testing cycle. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0014] Please see Figure 2 As shown, Figure 2 This is a flowchart illustrating a code testing method provided in an embodiment of the present invention, which can be applied to a code testing system and includes the following steps: S10: Obtain dynamic runtime information and historical lifecycle information of the target code unit; S20: Based on historical lifecycle information, perform code quality assessment on the target code unit to obtain historical quality information; S30: Based on dynamic operation information and historical quality information, code profiles are constructed to obtain quantitative profiles of risk heat. S40: Based on the quantitative profile of risk heat, predict the risk heat category of the target code unit to obtain the code risk heat category; S50: Based on code risk heat category, generate code test coverage threshold for target code unit; S60: Based on the code test coverage threshold, perform code testing on the target code unit to obtain target code test information.

[0015] Steps S10 to S60 of the embodiments of this application first utilize historical lifecycle information to perform code quality assessment on the target code unit, obtaining historical quality information that comprehensively reflects the historical instability of the code, providing a historical data foundation for subsequent risk assessment. Based on this, a quantitative profile of risk heat is constructed by fusing dynamic operational information and historical quality information, enabling the business activity and quality risk of the code module to be jointly represented in a unified mathematical space, providing a calculable feature basis for the formulation of differentiated testing strategies. Subsequently, the quantitative profile is transformed into interpretable code risk heat category labels through risk heat category prediction, realizing the qualitative classification of the code module in both heat and risk dimensions. Then, based on the code... The system adaptively generates differentiated code test coverage thresholds based on risk intensity categories. This ensures that core code modules with high risk and high intensity receive robust test coverage, while peripheral code modules with low risk and low intensity only need to meet basic testing requirements. This transforms test resources from uniform allocation to precise deployment. Ultimately, code testing is performed based on these differentiated code test coverage thresholds, ensuring that test resource investment matches the actual business risks of the code modules. This avoids the resource mismatch problem of traditional static uniform threshold methods, which suffer from insufficient testing of core code and excessive testing of secondary code. As a result, while ensuring the quality of core code, the system effectively reduces the overall computational resource consumption of test execution, significantly shortens the test cycle, and improves the execution efficiency of code testing.

[0016] The code testing method provided by this invention can be applied to code testing servers in the development process of various software systems. These servers can acquire code execution data and historical evolution data throughout the software lifecycle in real time. For example, in the development of large-scale financial software, development teams often need to ensure the code quality of the core fund allocation module of a wealth management trading system. They frequently need to rely on code testing servers to determine the production environment call frequency and historical defect status of the code module, in order to allocate testing resources reasonably and ensure the delivery quality of core business code.

[0017] For example, the R&D center of a large financial institution plans to perform pre-release code testing on the core fund transfer module responsible for high-frequency settlement in its wealth management trading system. After the R&D center submits the test application for the fund transfer module and the associated historical version information to the code testing server, the code testing server immediately obtains dynamic operational information of the module in the production environment, such as the frequency of interface calls, average response time, and peak memory consumption. At the same time, it retrieves historical lifecycle information of the module in the code hosting repository, such as the frequency of historical version submissions, defect repair records, and the extent of code line changes. Subsequently, the code testing server first performs a code quality assessment of the module based on historical lifecycle information, generating historical quality information that comprehensively reflects the module's historical instability. Then, it combines dynamic runtime information with historical quality information to construct a quantitative risk profile for the module. Based on this profile, it predicts the risk level of the module and determines that it belongs to the high-level, high-risk category. Then, based on this category, it dynamically generates a strict branch test coverage threshold of over 95% for the module. Finally, based on this threshold, it filters the global test case set and executes automated tests, outputting target code test information including test pass rate and failure stack logs. At the same time, it continuously synchronizes the latest production environment call data and code change records of the module, updating its quantitative risk profile in real time to avoid test strategy lag due to code evolution.

[0018] In step S10 of some embodiments, the target code unit refers to a specific code module or set of functional functions that needs to be verified for code quality and logic by the code testing system during software development and continuous integration. For example, in the development scenario of a financial transaction system, when the developers complete a new round of business logic writing and prepare to merge the code into the main branch, the target code unit can be the code module responsible for the core fund allocation business in the financial transaction system. In the development scenario of an online consultation system, if the software engineering of a medical institution needs to undergo regular periodic version iterations, the code testing system needs to perform pre-release verification in order to ensure the stability of the digital medical service base. In this case, the target code unit can be the core code component responsible for the electronic prescription issuance business of the patient in the online consultation system.

[0019] Dynamic runtime information refers to runtime data representing the activity level and hardware resource consumption of a target code unit when it is called and executed in a real business environment or test sandbox environment. For example, in the development scenario of a financial transaction system, when the business system is in the early morning peak of transactions and the number of concurrent requests surges, the code testing system needs to obtain the real-time load of the code module to assess its business popularity. At this time, dynamic runtime information can be the frequency of interface calls and peak memory consumption data of the target code unit per unit time. In the development scenario of an online consultation system, if the online consultation system carries out a large-scale free consultation activity, in order to assess the system's carrying capacity, the code testing system needs to collect the underlying data under the state of business surge. At this time, dynamic runtime information can be the number of concurrent threads called by the video consultation business module in the online consultation system and the network bandwidth usage data.

[0020] Historical lifecycle information refers to all modification traces and historical error reports of a target code unit from its initial creation to the current version. For example, in the development scenario of a financial transaction system, when the system undergoes underlying reconstruction and needs to assess the historical quality legacy issues of the old code, the code testing system needs to trace past changes. In this case, historical lifecycle information can be the historical version submission frequency of the target code unit in the code hosting repository and the defect repair records involving fund settlement failures. In the development scenario of an online consultation system, if the system repeatedly experiences abnormal patient medical record transfers, the code testing system needs to retrieve historical development ledgers in order to investigate potential historical code vulnerabilities. In this case, historical lifecycle information can be the number of logic reconstructions of the target code unit responsible for medical record transfers in the past six months and historical vulnerability work order processing records.

[0021] In this embodiment of the application, the code testing system collects runtime data such as the number of calls, call frequency, execution path and resource consumption of the target code unit in real business scenarios in real time through the production environment monitoring agent. At the same time, it obtains all historical modification records, defect repair records and change association information of the target code unit from its initial creation to the current version through the version control system interface and the defect tracking system interface, so as to obtain the dynamic running information and historical life cycle information of the target code unit.

[0022] In step S20 of some embodiments, historical quality information refers to the evaluation result data used to comprehensively characterize the historical instability of the target code unit after the defect statistics and change record data extracted from historical lifecycle information are fused and calculated. For example, in the development scenario of a financial transaction system, after the code testing system completes the weighted calculation of the underlying data, the historical quality information can be the accounting code vulnerability score generated by combining the transaction anomaly rate and the version change rate. In the development scenario of an online consultation system, if the code testing system performs joint analysis on multi-source historical data, the code testing system will output a comprehensive evaluation result in order to guide the subsequent resource allocation. At this time, the historical quality information can be a quantitative percentage value reflecting the comprehensive probability of historical failures of the prescription issuance module.

[0023] In this embodiment, the code testing system extracts defect information from historical lifecycle information. It statistically analyzes the number, density, and severity distribution of defects in the target code unit within a preset historical time window from historical defect repair records to obtain code defect statistics. Then, the code testing system extracts change records from historical lifecycle information. It statistically analyzes the code change frequency, line change magnitude, and modifier information of the target code unit within a preset historical time window from version control system logs to obtain code change record data. Finally, the code testing system performs fusion calculations on the code defect statistics and code change record data. Through a preset weighted fusion algorithm or machine learning regression model, it integrates multi-dimensional historical quality indicators into a quantitative evaluation result to obtain historical quality information.

[0024] In detail, such as Figure 3 As shown, step S20, which involves evaluating the code quality of the target code unit based on historical lifecycle information to obtain historical quality information, includes the following steps: S21: Extract defect information from historical lifecycle information to obtain code defect statistics; S22: Extract change records from historical lifecycle information to obtain code change record data; S23: Perform data fusion on code defect statistics and code change records to obtain historical quality information.

[0025] In step S21 of some embodiments, code defect statistics refer to a set of data extracted by the code testing system from historical lifecycle information, specifically used to quantify the frequency and severity of historical failures of the target code unit. For example, in the development scenario of a financial transaction system, when the code testing system performs an in-depth analysis of the historical quality of the accounting and settlement module, the code defect statistics may be the number of production environment system crashes and memory overflow errors caused by the module in the past year. In the development scenario of an online consultation system, if the code testing system needs to evaluate the stability of the patient privacy encryption module, then in order to quantify security risks, the code testing system needs to retrieve the security ledger. In this case, the code defect statistics may be the number of high-risk vulnerabilities exposed by the privacy encryption module in various security scans.

[0026] In this embodiment, the code testing system first extracts defect information from the historical lifecycle information. It extracts all defect events that occurred in the target code unit within a preset historical time window from the defect repair records, abnormal error logs and defect tracking system ledgers in the historical lifecycle information. The system then classifies and statistically analyzes the defects according to their severity level and business impact to quantify the distribution of historical failure frequency and severity of the target code unit, thereby obtaining code defect statistics.

[0027] In step S22 of some embodiments, code change record data refers to log data extracted by the code testing system from historical lifecycle information, reflecting the addition, modification, deletion, and frequency of code lines in the target code unit during each iteration of development. For example, in the development scenario of a financial transaction system, when frequent changes in business requirements lead to repeated modifications of the core transaction routing code, the code testing system needs to grasp the extent of changes in the underlying logic. In this case, the code change record data can be the number of code lines replaced in the transaction routing code in the past month and the specific frequency of code submissions by developers. In the development scenario of an online consultation system, if adjustments to medical policies lead to major changes in the logic of the medical insurance settlement module, the code testing system needs to retrieve the code refactoring information in order to reassess its reliability. In this case, the code change record data can be the proportion of underlying functions that have been completely rewritten in the settlement module.

[0028] In this embodiment of the application, the code testing system extracts change records from historical lifecycle information. It extracts all code change events that occurred in the target code unit within a preset historical time window from the version control system commit logs, code review records, and requirement-related information in the historical lifecycle information. It also counts the number of lines added, modified, deleted, and the frequency of changes to quantify the magnitude and activity of code changes in the target code unit, thereby obtaining code change record data.

[0029] In step S23 of some embodiments, the code testing system performs data fusion on code defect statistics and code change record data. It normalizes quantitative indicators such as the number of defects, defect density, and severity level distribution in the defect statistics and quantitative indicators such as change frequency and code line change amplitude in the change record data. Then, it calculates a single quantitative evaluation result or comprehensive score that comprehensively represents the historical instability of the target code unit through a preset weighted fusion algorithm or machine learning regression model, thereby obtaining historical quality information.

[0030] Steps S21 to S23 as illustrated in this embodiment first utilize defect information extraction to mine all defect events of the target code unit within a preset historical time window from historical lifecycle information. These events are then categorized and statistically analyzed according to the severity level and business impact of the defects to obtain code defect statistics. This allows the historical failure frequency and severity of the target code unit to be presented in a structured, quantitative indicator form, providing standardized defect dimension input for subsequent historical quality assessment. Secondly, based on change records, all code change events of the target code unit are mined from historical lifecycle information. By statistically analyzing the number of added, modified, and deleted lines of code and their change frequency, code change record data is obtained. This allows the magnitude of code changes and the activity level of logical evolution of the target code unit to be quantitatively analyzed. The data is presented in a structured format, providing a structured input of change dimensions for subsequent historical quality assessments. This avoids assessment bias caused by ignoring code change history. Finally, through data fusion, code defect statistics and code change records are normalized and weighted within the same framework. This allows multiple dimensions of historical quality indicators, such as historical failure frequency, defect severity distribution, code change frequency, and code line change magnitude, to be integrated into a comprehensive historical quality information. This historical quality information simultaneously covers the combined impact of defect and change dimensions on code quality, avoiding the one-sidedness caused by single-dimensional assessments. It provides an accurate and comprehensive historical quality assessment foundation for the subsequent construction of quantitative risk profiles, thereby effectively ensuring the rationality and accuracy of code testing strategy formulation.

[0031] In step S30 of some embodiments, the risk heat quantitative profile refers to the high-dimensional mathematical expression data generated after feature extraction and fusion of dynamic operation information and historical quality information, which is used to intuitively reflect the overall positioning of the target code unit in the risk and heat space. For example, in the development scenario of a financial transaction system, when the core payment interface is both a system access hotspot and a risk point that is very likely to cause accounting errors, the risk heat quantitative profile can be a multi-dimensional feature mapping result pointing to the high-heat and high-risk feature space with specific weight allocation. In the development scenario of an online consultation system, if the static page of the user agreement text in the system backend is rarely accessed and the code logic is extremely simple, the code testing system will generate a corresponding underlying profile in order to identify its extremely low attention priority. At this time, the risk heat quantitative profile can be sparse representation data pointing to the low-heat and low-risk feature space.

[0032] In this embodiment, the code testing system extracts runtime heat features based on dynamic runtime information, transforming multi-dimensional runtime data such as call frequency, call density, and resource consumption of the target code unit into a structured code heat feature vector. Then, the code testing system extracts quality risk features based on historical quality information, transforming defect statistics and change record data of the target code unit into a structured code risk feature vector. Next, the code testing system fuses the code heat features and code risk features, using vector concatenation or attention fusion mechanisms to merge the two-dimensional features into a two-dimensional fused feature that combines business call attributes and historical quality attributes. Finally, the code testing system performs structured feature mapping on the two-dimensional fused feature, mapping it to a preset high-dimensional mathematical space through nonlinear transformation to form a structured expression, thus obtaining a quantitative profile of the risk heat of the target code unit.

[0033] In detail, such as Figure 4 As shown, step S30, which involves constructing a code profile based on dynamic operational information and historical quality information to obtain a quantitative risk heat profile, includes the following steps: S31: Based on dynamic operation information, perform operation popularity feature extraction to obtain code popularity features; S32: Based on historical quality information, extract quality risk features to obtain code risk features; S33: Feature fusion is performed on code popularity features and code risk features to obtain two-dimensional fused features; S34: Based on the dual-dimensional fusion features, perform structured feature mapping to obtain a quantitative profile of risk heat.

[0034] In step S31 of some embodiments, code popularity feature refers to a structured feature vector extracted by the code testing system based on dynamic runtime information to characterize the degree of call density of the target code unit in the business execution chain. For example, in the development scenario of a financial transaction system, when the high-frequency quantitative trading interface is in a state of continuous high load operation, the code popularity feature can be a dense feature vector characterizing the interface's extremely high transaction processing volume per second. In the development scenario of an online consultation system, if the appointment registration page of a less popular department is rarely visited by patients, the code popularity feature can be a sparse feature vector characterizing the appointment page's extremely low call frequency after the code testing system performs data transformation.

[0035] In this embodiment of the application, the code testing system extracts multi-dimensional runtime indicators such as the number of times the target code unit is called, the call frequency, the peak call volume, and the average response time within a preset time window from the dynamic runtime information. Then, after the above multi-dimensional indicators are numerically normalized, they are combined into a structured feature vector to obtain the code popularity feature.

[0036] In step S32 of some embodiments, code risk features refer to structured feature vectors extracted by the code testing system based on historical quality information to characterize potential logical defects and collapse probabilities within the target code unit. For example, in the development scenario of a financial transaction system, when a risk control interception module that has just undergone large-scale underlying reconstruction and has many historical legacy issues enters the testing phase, the code risk features can be high-risk feature vectors characterizing that the module is extremely prone to financial losses. In the development scenario of an online consultation system, if a purely static medical knowledge display page has not undergone code changes for many years and has zero customer complaints, then after the code testing system completes feature conversion, the code risk features can be low-risk feature vectors characterizing that the display page is extremely stable.

[0037] In this embodiment of the application, the code testing system extracts multi-dimensional historical quality indicators from historical quality information, such as the total number of defects, defect density, distribution of various severity levels of defects, code change frequency, and code line change amplitude of the target code unit within a preset historical time window. Then, the above multi-dimensional indicators are combined into a structured feature vector to obtain code risk characteristics.

[0038] In step S33 of some embodiments, the dual-dimensional fusion feature refers to the comprehensive feature expression that combines business call attributes and historical quality attributes obtained by the code testing system after channel splicing and normalization of code popularity features and code risk features. For example, in the development scenario of a financial transaction system, when the code testing system needs to take into account both high concurrency and fund security to prevent systemic risks, the dual-dimensional fusion feature can be a fusion tensor data that simultaneously includes the transaction system memory load parameters and historical downtime probability. In the development scenario of an online consultation system, if it is necessary to comprehensively evaluate the consultation response speed and the security of privacy data encryption, the code testing system will perform feature splicing in order to achieve comprehensive modeling of feature dimensions. At this time, the dual-dimensional fusion feature can be a multi-dimensional vector that integrates medical record reading frequency features and sensitive data leakage risk features.

[0039] In this embodiment, the code testing system concatenates the code popularity feature vector and the code risk feature vector along the feature dimension to form a fused joint feature vector. Then, the joint feature vector is normalized to eliminate the dimensional differences between different features, so that the features of each dimension are comparable in the subsequent profile construction process, thus obtaining the two-dimensional fused feature.

[0040] In step S34 of some embodiments, the code testing system inputs the dual-dimensional fusion features into a preset nonlinear mapping network. After layer-by-layer transformation of the multi-layer fully connected network and processing by the nonlinear activation function, the dual-dimensional fusion features are mapped from the original feature space to a high-dimensional mathematical space that can better distinguish different risk heat categories. In this high-dimensional space, the feature expressions of code modules with similar risk heat attributes are close to each other, while the feature expressions with different attributes are far apart, finally forming a structured high-dimensional feature expression, which can obtain a quantitative profile of risk heat.

[0041] Steps S31 to S34 as illustrated in this embodiment first utilize runtime heat feature extraction to transform multi-dimensional runtime indicators such as call frequency, call density, and resource consumption in dynamic runtime information into structured code heat feature vectors. This allows the originally scattered and varied runtime data to be uniformly expressed at the feature level, providing a standardized heat dimension input for subsequent comprehensive modeling. Secondly, relying on quality risk feature extraction, defect statistics and change record data in historical quality information are transformed into structured code risk feature vectors. This enables the unified quantification of multi-dimensional historical quality indicators such as historical defect frequency, defect severity level, and code change magnitude at the feature level, providing a standardized risk dimension input for subsequent comprehensive modeling. Finally, feature fusion is used to transform the code heat... By concatenating and normalizing the degree features and code risk features, the business activity attribute and historical quality attribute are jointly expressed in the same feature space, forming a two-dimensional fusion feature that combines information from both dimensions. This avoids feature fragmentation or information loss caused by considering popularity and risk separately. Finally, through structured feature mapping, the two-dimensional fusion feature is nonlinearly mapped from the original feature space to a high-dimensional mathematical space that can better distinguish different risk popularity categories. This allows the overall risk popularity positioning of the target code unit to form a stable and distinguishable structured expression in the high-dimensional space, providing a higher feature discrimination and clearer category boundaries for subsequent risk popularity category prediction. This effectively ensures the accuracy and robustness of code risk popularity category prediction.

[0042] In step S40 of some embodiments, the code risk heat category refers to the classification label determined after classification and prediction based on the risk heat quantitative profile, which is used to qualitatively describe the attributes of the target code unit in the two dimensions of business heat and quality risk. For example, in the development scenario of a financial transaction system, when the risk heat quantitative profile indicates that the heat quantitative index and risk quantitative index of the target code unit are both at a high level, the code risk heat category can be a high-risk, high-heat key protection category that the system determines must invest extremely high testing computing power. In the development scenario of an online consultation system, if the risk heat quantitative profile indicates that the heat quantitative index and risk quantitative index of the target code unit are both at a low level, then in order to save system resources, the code testing system will output a specific classification label. At this time, the code risk heat category can be a low-risk, low-heat secondary protection category that allows basic verification to pass.

[0043] In this embodiment, the code testing system decouples the risk heat quantification profile by using orthogonal decomposition or dimensionality separation algorithms to decompose the high-dimensional profile data into a heat quantification index representing the business busyness and a risk quantification index representing the logical fragility. Then, the code testing system maps the target code unit to a preset two-dimensional mathematical space with the heat quantification index as the horizontal axis and the risk quantification index as the vertical axis to obtain the target feature coordinate point. Finally, based on a preset four-quadrant evaluation matrix, the code testing system determines the specific landing area of ​​the target feature coordinate point in the four quadrants of high heat and high risk, high heat and low risk, low heat and high risk, or low heat and low risk, and uses the quadrant label corresponding to the landing area as the code risk heat category of the target code unit.

[0044] In detail, such as Figure 5 As shown, step S40, which is based on the quantitative profile of risk heat, predicts the risk heat category of the target code unit to obtain the code risk heat category, includes the following steps: S41: Decouple the features of the risk heat quantification profile to obtain the heat quantification index and the risk quantification index; S42: Based on the preset clustering boundary conditions, perform two-dimensional spatial mapping on the heat quantification index and the risk quantification index to obtain the target feature coordinate points; S43: Based on the preset four-quadrant evaluation matrix, perform a distribution area query on the target feature coordinate points to obtain the code risk heat category.

[0045] In step S41 of some embodiments, the heat quantification index refers to a specific value decoupled and extracted by the code testing system from the risk heat quantification profile, which is used to measure the business busyness of the target code unit. For example, in the development scenario of a financial transaction system, when the code testing system performs mathematical decomposition on the profile dimension, the heat quantification index can be a normalized floating-point number representing the daily average call volume of the financial product subscription module. In the development scenario of an online consultation system, if the code testing system needs to separately extract the business call frequency for independent analysis, the heat quantification index can be a quantitative score representing the throughput of the text and image consultation message queue.

[0046] The risk quantification index refers to a specific numerical value extracted from the risk heat quantification profile by the code testing system, specifically used to measure the logical fragility and defect tendency of the target code unit. For example, in the development scenario of a financial transaction system, when the code testing system separately decomposes the security coefficient, the risk quantification index can be a high-risk assessment value representing the probability of transaction lock contention failure. In the development scenario of an online consultation system, if the code testing system analyzes the historical potential problems of the medical image transmission module, the risk quantification index can be a normalized floating-point number representing the probability of data packet loss or memory leak in the transmission module.

[0047] In this embodiment of the application, the code testing system first decouples the risk heat quantification profile by feature decoupling, and uses orthogonal decomposition or feature dimension separation algorithm to decompose the high-dimensional risk heat quantification profile into a single quantitative index representing different independent attributes, thereby obtaining a heat quantification index for measuring the business busyness of the target code unit and a risk quantification index for measuring the logical fragility and defect tendency of the target code unit.

[0048] In step S42 of some embodiments, the preset clustering boundary conditions refer to the heat axis threshold and risk axis threshold pre-set in the code testing system for classifying the heat quantification index and risk quantification index in a two-dimensional mathematical space. For example, in the scenario of financial transaction system development, when the code testing system needs to distinguish code modules into high heat and low heat, the preset clustering boundary conditions can be the daily average call volume percentage threshold pre-set in the heat axis direction. In the scenario of online consultation system development, if the code testing system needs to distinguish medical modules into high risk and low risk, the preset clustering boundary conditions can be the historical failure probability percentage threshold pre-set in the risk axis direction.

[0049] The target feature coordinate point refers to the specific spatial positioning data generated by the code testing system in a preset two-dimensional mathematical space with the heat quantification index as the horizontal axis and the risk quantification index as the vertical axis. For example, in the development scenario of a financial transaction system, after the code testing system completes the two-dimensional spatial mapping calculation, the target feature coordinate point can be the point data with coordinate values ​​of specific high-order horizontal and vertical values ​​located in the upper right corner of the coordinate system. In the development scenario of an online consultation system, if the code testing system substitutes the edge business parameters into the mathematical space, the target feature coordinate point can be the point data located near the origin in the lower left corner of the coordinate system.

[0050] In this embodiment of the application, the code testing system performs two-dimensional spatial mapping on the heat quantification index and the risk quantification index based on preset clustering boundary conditions. With the heat quantification index as the horizontal axis and the risk quantification index as the vertical axis, the target code unit is mapped to a preset two-dimensional mathematical space, thereby generating target feature coordinate points that represent the specific spatial location of the target code unit in the two-dimensional space. For example, when the heat quantification index is a specific value and the risk quantification index is a specific value, the code testing system combines these two values ​​into two-dimensional coordinate data, i.e., target feature coordinate points.

[0051] In step S43 of some embodiments, the preset four-quadrant evaluation matrix refers to an evaluation model pre-constructed in the code testing system that divides a two-dimensional space into four quadrants: high popularity and high risk, high popularity and low risk, low popularity and high risk, and low popularity and low risk, using the popularity index and risk index as coordinate axes. For example, in the development scenario of a financial transaction system, when the code testing system needs to classify code modules into different risk level categories, the preset four-quadrant evaluation matrix can be a hierarchical evaluation matrix that divides the plane into four regions using the transaction call frequency threshold and defect probability threshold as coordinate axes. In the development scenario of an online consultation system, if the code testing system needs to classify and grade the medical module, the preset four-quadrant evaluation matrix can be a hierarchical evaluation model that divides the space into four quadrants using the consultation call volume threshold and system crash probability threshold as coordinate axes.

[0052] In this embodiment, the code testing system substitutes the target feature coordinates into a preset four-quadrant evaluation matrix, uses preset thresholds for the heat axis and the risk axis as quadrant division boundary conditions, determines the specific landing area of ​​the coordinates in the four quadrants of high heat and high risk, high heat and low risk, low heat and high risk, or low heat and low risk, and then reads the quadrant label corresponding to the landing area as the qualitative classification result of the target code unit, thereby obtaining the code risk heat category.

[0053] Steps S41 to S43 of this embodiment first utilize feature decoupling to decompose the high-dimensional risk heat quantification profile into a heat quantification index representing the level of business activity and a risk quantification index representing the level of logical fragility. This separates the heat attribute and risk attribute, which were originally coupled together in the high-dimensional space, and presents them in the form of independent quantified values, providing directly usable horizontal and vertical coordinate values ​​for subsequent two-dimensional spatial mapping. Then, relying on the two-dimensional spatial mapping, the heat quantification index and the risk quantification index are used as the horizontal and vertical coordinates, respectively, to generate specific target feature coordinate points in a preset two-dimensional mathematical space, enabling the target code unit to... The heat and risk attributes can be jointly represented in the same mathematical space and form a locatable spatial point, providing a precise spatial positioning basis for subsequent category determination. Finally, based on the preset four-quadrant evaluation matrix, the distribution area of ​​the target feature coordinate points is queried. The four quadrants in the two-dimensional space correspond to four different risk heat category labels. By determining the specific landing area of ​​the coordinate points, an intuitive and interpretable classification result can be obtained, realizing the transformation from quantitative profile to qualitative classification label. This provides category label input that can be directly matched with the rule base for subsequent differential threshold generation, effectively ensuring the relevance and rationality of threshold generation.

[0054] In step S50 of some embodiments, the code test coverage threshold refers to a quantitative acceptance baseline dynamically calculated by the code testing system based on the code risk heat category to which the target code unit belongs, used to constrain the investment of automated testing resources for the target code unit. For example, in the development scenario of a financial transaction system, when the target code unit is determined to be high-frequency accounting settlement high-risk business code, the code test coverage threshold can be set to a strict branch test coverage index of more than 95%. In the development scenario of an online consultation system, if the target code unit is determined to be an edge page display module with extremely low call frequency and no defect feedback for a long time, then in order to improve the overall execution efficiency of the system, the code test coverage threshold can be dynamically reduced to a basic test coverage index of 30%.

[0055] In this embodiment, the code testing system performs category parsing on the code risk popularity categories, converting the category tags into target category evaluation identifiers that can be matched and addressed in the rule base. Then, the code testing system uses the target category evaluation identifier as an index to perform rule matching in the preset threshold generation rule base, retrieves the threshold generation strategy corresponding to the category identifier from the rule base, and uses it as the target threshold generation strategy. Finally, the code testing system performs dynamic numerical calculation based on the numerical calculation logic defined in the target threshold generation strategy and the code size base of the target code unit to obtain the code test coverage threshold of the target code unit.

[0056] In detail, based on the code risk popularity category, code test coverage thresholds are generated for the target code unit, including: The code risk popularity categories are parsed to obtain the target category assessment label; Based on a preset threshold generation rule base and target category evaluation identifier, rule matching is performed to obtain the target threshold generation strategy; Based on the target threshold generation strategy, the threshold value is calculated for the target code unit to obtain the code test coverage threshold.

[0057] In some embodiments, the target category evaluation identifier refers to the core identifier extracted by the code testing system after semantic parsing of the code risk heat category, which is used for matching and addressing in the threshold generation rule base. For example, in the development scenario of a financial transaction system, when the code testing system needs to retrieve specific rules from the strategy database, the target category evaluation identifier can be a code number representing a specific combination of letters and numbers that represents extremely high priority. In the development scenario of an online consultation system, if a module is classified as a peripheral business that does not require special attention, the code testing system will perform dimensionality reduction labeling. At this time, the target category evaluation identifier can be a basic level sequence number used to trigger the system's automatic degradation test process.

[0058] A threshold generation rule base refers to a database of strategies pre-built and stored in a code testing system to provide mapping relationships between different category identifiers and test coverage requirements. For example, in the development scenario of a financial transaction system, when the code testing system needs to determine the level of automated testing investment for different risk levels, the threshold generation rule base can be an underlying configuration table with a series of numerical calculation logics hard-coded, such as high risk corresponding to 100% coverage and low risk corresponding to 30% coverage. In the development scenario of an online consultation system, if the code testing system plans to dynamically allocate computing resources according to the importance of medical services, then in order to achieve accurate matching, the threshold generation rule base can be a strategy form containing a graded test resource mapping dictionary stored in a relational database.

[0059] The target threshold generation strategy refers to the algorithmic rules used by the code testing system to guide the calculation of specific threshold values ​​when the target category evaluation identifier is successfully matched in the threshold generation rule base. For example, in the development scenario of a financial transaction system, when the code testing system reads an extremely high risk identifier, the target threshold generation strategy can be a mandatory execution strategy that requires the core payment code to meet extremely high branch coverage requirements and adds concurrency pressure boundary condition checks. In the development scenario of an online consultation system, if the code testing system obtains a low priority identifier, the system will call the tolerance mode rule. At this time, the target threshold generation strategy can be a lenient execution strategy that only requires the function-level coverage to meet the standard.

[0060] In this embodiment of the application, the code testing system first performs category parsing on the code risk popularity category, and converts the code risk popularity category label into a core identifier that can be matched and addressed in the threshold generation rule base, namely the target category evaluation identifier. For example, when the code risk popularity category is determined to be a high popularity and high risk category, the code testing system can parse it into a specific identifier code corresponding to the highest test priority, while when the code risk popularity category is determined to be a low popularity and low risk category, the code testing system can parse it into an identifier code corresponding to the lowest test priority.

[0061] Next, the code testing system performs rule matching based on the preset threshold generation rule base and target category evaluation identifier. Using the target category evaluation identifier as an index, it searches the threshold generation rule base to find threshold generation strategy records that match the identifier. When a matching record is found, the strategy rule in the record is extracted as the target threshold generation strategy. The threshold generation rule base pre-stores the mapping relationship between different category evaluation identifiers and different threshold generation strategies.

[0062] Finally, the code testing system calculates the threshold value for the target code unit based on the target threshold generation strategy. According to the numerical calculation logic defined in the target threshold generation strategy, it obtains the code size base of the target code unit, such as the number of lines of code or the number of executable statements. Then, it substitutes the code size base into the calculation formula in the target threshold generation strategy for dynamic calculation, thereby obtaining the code test coverage threshold applicable to the target code unit and conforming to its risk heat category.

[0063] This application first utilizes category parsing to transform the qualitative classification label of code risk popularity category into a core identifier that can be addressed and matched in the threshold generation rule base. This allows the classification result to be accurately located in the rule base as an index, providing a standardized matching basis for subsequent rule retrieval. Secondly, rule matching is performed based on the threshold generation rule base and the target category evaluation identifier. By using the identifier as an index, the corresponding threshold generation strategy is quickly retrieved in the rule base, enabling different categories to correspond to different threshold generation logics. This achieves a precise mapping from category to strategy, avoiding strategy mismatch caused by the disconnect between category judgment results and threshold generation logic. Then, based on the target threshold generation strategy, threshold values ​​are calculated for the target code unit. The general calculation logic defined in the strategy is combined with the actual code size base of the target code unit for dynamic numerical calculation. This ensures that the final generated code test coverage threshold can reflect both the overall testing requirements of the category and adapt to the specific size characteristics of the code unit. Finally, a complete transformation link from classification label to quantitative acceptance baseline is realized, ensuring a high degree of matching between the test coverage threshold and the actual risk popularity of the code module. This provides an accurate and executable quantitative standard for subsequent differentiated code testing.

[0064] In step S60 of some embodiments, the target code test information refers to the verification result data, including the test pass rate and failure stack logs, output by the automated test execution engine of the code testing system after performing tests on the target code unit under the constraint of the code test coverage threshold. For example, in the development scenario of a financial transaction system, when the automated code running job is completed, the target code test information may be a detailed test report containing a precision loss error that occurred in the deduction interface of a certain financial account under high concurrency environment. In the development scenario of an online consultation system, if the test program captures a business logic exception, the code testing system will generate a corresponding file. At this time, the target code test information may be an error list pointing out the plaintext transmission problem in the patient privacy protection desensitization process.

[0065] In this embodiment, the code testing system uses a code test coverage threshold as a constraint to select a minimal set of test cases that can meet the coverage threshold requirement from the pre-acquired global test case set as the target test case set. Then, the code testing system sends the target test case set to the automated test execution engine, which runs test cases on the target code unit and collects verification result data such as test pass rate, failure stack logs, and coverage achievement status to obtain the target code test information.

[0066] In detail, based on the code test coverage threshold, code tests are performed on the target code unit to obtain target code test information, including: Based on the code test coverage threshold, test cases are filtered from the pre-acquired global test case set to obtain the target test case set; Based on the target test example set, automated testing is performed on the target code unit to obtain target code test information.

[0067] In some embodiments, a global test case set refers to a set of test scripts and simulation verification data pre-developed and stored in a code testing system to comprehensively cover all functional branches and exception flows of the software. For example, in the development scenario of a financial transaction system, when the code testing system is preparing to verify the entire process of purchasing financial products, the global test case set may be a set of automated test scripts for financial business that includes hundreds of test conditions such as exception parameter injection verification and verification of large-amount transfers. In the development scenario of an online consultation system, if the code testing system is preparing to perform full-link regression verification, then in order to cover all medical subsystems, the global test case set may be a comprehensive medical test data set that covers the interactive logic of the text and image consultation process and the cross-network review and transfer link of electronic prescriptions.

[0068] The target test case set refers to the minimum effective execution unit set selected by the code testing system from the global test case set under the constraint of the code test coverage threshold generated above. For example, in the development scenario of an online consultation system, when the code test coverage threshold only requires 30% basic coverage, the target test case set can be a simplified test dataset that only contains the verification scripts of the main core path of the system and does not involve rare edge exception error flow running. However, in the development scenario of a financial transaction system, if the code test coverage threshold requires an extremely high standard of 100%, then in order to ensure that the funds are safe, the code testing system will extract the full amount of data. At this time, the target test case set can be a full set of high-pressure test scripts that include extreme concurrency stress testing and network disconnection and reconnection testing.

[0069] In this embodiment, the code testing system filters test cases from a pre-acquired global test case set based on a code test coverage threshold. Using the code test coverage threshold as a constraint, the system selects the minimum set of test cases that can achieve the coverage threshold requirement after execution from the global test case set, i.e., the target test case set. For example, when the code test coverage threshold requirement is low, the code testing system only filters test cases that cover the core trunk path, while when the code test coverage threshold requirement is high, the code testing system filters test cases that cover the trunk path and all branch paths.

[0070] Furthermore, the code testing system performs automated testing on the target code unit based on the target test case set. The target test case set is distributed to the automated test execution engine of the code testing system, and the execution engine runs test cases on the target code unit one by one in the preset test environment. The execution results of each test case are collected, including the test pass status, failure assertions that fail, code coverage achievement status, and stack logs when exceptions are thrown. Thus, the verification result data containing the test pass rate and failure stack logs are output, and the target code test information can be obtained.

[0071] This application first utilizes test case filtering to select a minimal set of test cases matching a code test coverage threshold from the global test case set. This ensures that the final size of the test case set is adapted to the test coverage requirements of the target code unit, avoiding the waste of computational resources caused by executing all test cases regardless of the threshold. This achieves precise allocation of test resources from the source. Secondly, automated testing is performed based on the selected target test case set. The streamlined test case set is run in the automated test execution engine, and verification result data such as test pass rate and failure stack logs are collected. This allows the test execution process to not only verify the correctness of the code but also provide structured test result data input for subsequent defect localization and risk scoring updates. Thus, while ensuring test sufficiency, unnecessary test execution overhead is effectively reduced, comprehensively improving test execution efficiency and making rational use of test resources.

[0072] It should be noted that, after obtaining the target code test information, in order to feed back newly discovered quality issues during the test execution to the code test system so as to achieve continuous optimization and adaptive evolution of the test strategy, the threshold generation rule base can also be dynamically updated based on the target code test information, so that the generation logic of the code test coverage threshold can continuously self-correct as the quality status of the code module evolves.

[0073] In detail, after performing code testing on the target code unit based on the code test coverage threshold and obtaining the target code test information, the process also includes: Defect information is extracted from the test information of the target code to obtain code test defect information; Based on code test defect information, the root cause of code defects is located and the characteristic parameters of the defect root cause are obtained; Based on the defect root cause feature parameters, the risk score of the target code unit is recalculated to obtain a dynamically updated risk score. Based on dynamically updated risk scores, the threshold generation rule base is optimized to obtain an optimized rule base, which is used to generate the code test coverage threshold for the next code unit.

[0074] In some embodiments, code test defect information refers to data extracted by the code testing system from the target code test information, specifically recording the underlying logic vulnerabilities and error details exposed by the target code unit during automated test runs. For example, in the development scenario of a financial transaction system, when the account transfer module fails the verification during test case runs, the code testing system will solidify the error. In this case, the code test defect information may be an exception tracking text that records a database deadlock timeout in a specific line of code. In the development scenario of an online consultation system, when the code testing system discovers that the medical subsystem has crashed unexpectedly, the code test defect information may be an error log pointing to a null pointer exception in the electronic prescription signature digital certificate verification function.

[0075] Root cause feature parameters refer to the deep feature data extracted by the code testing system after performing reverse analysis and localization of the abnormal source of code test defect information, which is used to characterize the fundamental physical cause of the defect. For example, in the development scenario of a financial transaction system, when the code testing system finds out the underlying source of the fund calculation error, the root cause feature parameters can be the root cause quantitative parameters that characterize floating-point overflow or concurrent lock contention failure. In the development scenario of an online consultation system, if the code testing system traces the program problem of video stuttering during consultation, then in order to guide strategy feedback, the root cause feature parameters can be the fault source value that characterizes the deadlock blocking of the audio and video encoding and decoding thread.

[0076] Dynamically updated risk scores refer to the latest quantitative risk values ​​obtained by the code testing system after recalculating and penalizing the original quality assessment results of the target code unit based on newly extracted defect root cause feature parameters. For example, in the development scenario of a financial transaction system, if a module successfully passes a full and rigorous test without finding any remaining root cause parameters, the code testing system will lower its alert level. In this case, the dynamically updated risk score can be the corresponding decrease in security level score after adjusting the reward coefficient. In the development scenario of an online consultation system, when a module that was originally considered low-risk exposes a serious privacy leakage underlying logic vulnerability in automated testing, the dynamically updated risk score can be a high-risk warning score for the module that has increased significantly after the system penalty factor is superimposed.

[0077] An optimized rule base refers to a database of new strategies created by a code testing system after dynamically updating risk scores and modifying the parameters and weights of the original threshold generation logic to guide the next code testing task. For example, in the development scenario of a financial trading system, when the code testing system finds that the defect frequency of a certain type of trading middleware is seriously underestimated, the optimized rule base can be an adaptive update rule configuration table that significantly reduces the system fault tolerance of that type of code module and permanently increases the corresponding code test coverage requirements. In the development scenario of an online consultation system, if the system determines that a certain old module has been completely stabilized, then in order to free up system testing computing power, the optimized rule base can be an intelligent iterative strategy library that lowers the default threshold baseline of that module.

[0078] In this embodiment of the application, the code testing system first extracts defect information from the target code test information. It extracts the underlying logic vulnerabilities and error details exposed by the target code unit during this automated test run from the test failure case records, exception stack logs and assertion failure details in the target code test information, thereby obtaining code test defect information.

[0079] Next, the code testing system locates the root cause of code defects based on the code test defect information. It analyzes the exception stack information in the code test defect information to locate the source code file path, function name and specific line number where the defect is located. It also traces the most recent modifier and modification time of the code line by combining the code change records in the version control system to determine the root cause of the defect and obtain the defect root cause characteristic parameters.

[0080] Subsequently, the code testing system recalculates the risk score of the target code unit based on the defect root cause feature parameters. It determines the weight value of the penalty factor or reward factor according to the defect severity level and business impact scope indicated by the defect root cause feature parameters. Then, it adds the weight value to the original risk score of the target code unit to update its risk score, or recalculates the risk score of the target code unit based on the latest defect data to replace the original risk score, thereby obtaining a dynamically updated risk score.

[0081] Finally, the code testing system optimizes the threshold generation rule base based on dynamically updated risk scores. It determines the parameter types and adjustment ranges that need to be adjusted for the threshold generation logic of the corresponding category of code in the threshold generation rule base according to the change range of the dynamically updated risk scores. Then, it corrects the relevant parameters in the risk weight coefficient or threshold calculation formula of the corresponding category of code in the threshold generation rule base according to the preset weight adjustment strategy, and stores the corrected rules in the threshold generation rule base to replace the original rules, thereby obtaining an optimized rule base for the next code test coverage threshold generation.

[0082] This application first utilizes defect information extraction to mine the underlying logic vulnerabilities and error details exposed in the automated test from the target code test information, obtaining code test defect information. This provides structured defect data input for subsequent defect localization and risk updates. Secondly, based on the root cause localization of code defects, reverse analysis of the defect information is performed to determine the source of the anomaly. Through stack analysis and code change tracing, the code location and root cause of the defect are determined, obtaining defect root cause characteristic parameters. This allows subsequent risk score updates to accurately pinpoint specific code modules rather than broadly affecting the overall score, avoiding erroneous risk score updates due to unclear defect attribution. Then, risk scoring... The risk score of the target code unit is dynamically corrected by recalculating the original risk score based on the defect root cause feature parameters. This allows newly exposed quality issues in the current test to be reflected in the risk assessment of the code module in real time, realizing the dynamic evolution of the risk score with the test process. Finally, the threshold generation rule base is optimized based on the dynamically updated risk score, and the changes in the risk score are transformed into adaptive adjustments of the corresponding parameters in the threshold generation logic. This allows the generation of the code test coverage threshold in the next test to fully refer to the new knowledge accumulated in this test, thus forming a complete adaptive closed loop from test execution to threshold optimization. This achieves a virtuous cycle of continuous optimization of the test strategy as the software evolves.

[0083] As can be seen, in the above scheme, historical lifecycle information can be used to first assess the code quality of the target code unit, obtaining historical quality information that comprehensively reflects the historical instability of the code, providing a historical data foundation for subsequent risk assessment. Based on this, a quantitative profile of risk heat is constructed by integrating dynamic operational information and historical quality information, enabling the business activity and quality risk of the code module to be jointly represented in a unified mathematical space, providing a calculable feature basis for the formulation of differentiated testing strategies. Subsequently, the quantitative profile is transformed into interpretable code risk heat category labels through risk heat category prediction, realizing the qualitative classification of the code module in terms of both heat and risk dimensions. Then, based on the code risk heat category... By adaptively generating differentiated code test coverage thresholds, high-frequency and high-risk core code modules receive robust test coverage, while low-frequency and low-risk peripheral code modules only need to meet basic testing requirements. This transforms test resources from uniform allocation to precise deployment. Ultimately, code testing is executed based on differentiated code test coverage thresholds, ensuring that test resource investment matches the actual business risks of the code modules. This avoids the resource mismatch problem of insufficient testing of core code and excessive testing of secondary code in traditional static uniform threshold methods. As a result, while ensuring the quality of core code, it effectively reduces the overall computational resource consumption of test execution, significantly shortens the test cycle, and improves the execution efficiency of code testing.

[0084] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0085] In one embodiment, a code testing apparatus is provided, which corresponds one-to-one with the code testing methods described in the above embodiments. For example... Figure 6 As shown, this code testing device includes an information acquisition module, a code evaluation module, a profile construction module, a category prediction module, a threshold mapping module, and a code testing module. Detailed descriptions of each functional module are as follows: The information acquisition module is used to acquire dynamic runtime information and historical lifecycle information of the target code unit; The code evaluation module is used to evaluate the code quality of target code units based on historical lifecycle information and obtain historical quality information. The profile building module is used to build code profiles based on dynamic runtime information and historical quality information to obtain quantitative profiles of risk heat. The category prediction module is used to predict the risk popularity category of the target code unit based on the quantitative profile of risk popularity, and obtain the code risk popularity category. The threshold mapping module is used to generate code test coverage thresholds for target code units based on code risk heat categories. The code testing module is used to perform code testing on target code units based on code test coverage thresholds and obtain target code test information.

[0086] This invention provides a code testing device. First, it uses historical lifecycle information to assess the code quality of target code units, obtaining historical quality information that comprehensively reflects the historical instability of the code. This provides a historical data foundation for subsequent risk assessment. Based on this, it constructs a quantitative profile of risk heat by integrating dynamic operational information and historical quality information. This allows the business activity and quality risk of code modules to be jointly represented in a unified mathematical space, providing a calculable feature basis for the formulation of differentiated testing strategies. Subsequently, through risk heat category prediction, the quantitative profile is transformed into interpretable code risk heat category labels, achieving qualitative classification of code modules in both heat and risk dimensions. Finally, based on the code risk heat... The system adaptively generates differentiated code test coverage thresholds by category, ensuring high-intensity test coverage for core code modules with high popularity and high risk, while peripheral code modules with low popularity and low risk only need to meet basic test requirements. This achieves a shift in test resource allocation from uniform distribution to precise deployment. Ultimately, code testing is performed based on differentiated code test coverage thresholds, ensuring that the investment of test resources matches the actual business risks of the code modules. This avoids the resource mismatch problem of insufficient testing of core code and excessive testing of secondary code in traditional static uniform threshold methods. As a result, while ensuring the quality of core code, the system effectively reduces the computational resource consumption of overall test execution, significantly shortens the test cycle, and improves the execution efficiency of code testing.

[0087] For specific limitations regarding the code testing device, please refer to the limitations on the code testing method above, which will not be repeated here. Each module in the aforementioned code testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0088] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a code testing method on the server side.

[0089] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a code testing method on the client side. In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain dynamic runtime information and historical lifecycle information of the target code unit; Based on historical lifecycle information, code quality is evaluated on target code units to obtain historical quality information; Code profiles are constructed based on dynamic operational information and historical quality information to obtain quantitative profiles of risk heat. Based on the quantitative profile of risk heat, the risk heat category of the target code unit is predicted to obtain the code risk heat category; Based on the code risk heat category, generate the code test coverage threshold for the target code unit; Based on the code test coverage threshold, code tests are performed on the target code unit to obtain target code test information.

[0090] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Obtain dynamic runtime information and historical lifecycle information of the target code unit; Based on historical lifecycle information, code quality is evaluated on target code units to obtain historical quality information; Code profiles are constructed based on dynamic operational information and historical quality information to obtain quantitative profiles of risk heat. Based on the quantitative profile of risk heat, the risk heat category of the target code unit is predicted to obtain the code risk heat category; Based on the code risk heat category, generate the code test coverage threshold for the target code unit; Based on the code test coverage threshold, code tests are performed on the target code unit to obtain target code test information.

[0091] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0092] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0093] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0094] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0095] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A code testing method, characterized in that, The method includes: Obtain dynamic runtime information and historical lifecycle information of the target code unit; Based on the historical lifecycle information, code quality is evaluated on the target code unit to obtain historical quality information; Based on the dynamic operation information and the historical quality information, a code profile is constructed to obtain a quantitative profile of risk heat. Based on the aforementioned risk heat quantitative profile, the risk heat category of the target code unit is predicted to obtain the code risk heat category; Based on the code risk heat category, generate the code test coverage threshold for the target code unit; Based on the code test coverage threshold, code testing is performed on the target code unit to obtain target code test information.

2. The code testing method as described in claim 1, characterized in that, The process of constructing a code profile based on the dynamic operational information and the historical quality information to obtain a quantitative risk heat profile includes: Based on the dynamic operation information, operation popularity features are extracted to obtain code popularity features; Based on the historical quality information, quality risk features are extracted to obtain code risk features; The code popularity feature and the code risk feature are fused to obtain a two-dimensional fused feature. Based on the dual-dimensional fusion features, structured feature mapping is performed to obtain the quantitative profile of risk heat.

3. The code testing method as described in claim 1, characterized in that, The step of evaluating the code quality of the target code unit based on the historical lifecycle information to obtain historical quality information includes: Defect information is extracted from the historical lifecycle information to obtain code defect statistics. The historical lifecycle information is used to extract change records to obtain code change record data; The historical quality information is obtained by fusing the statistical data on code defects and the data on code changes.

4. The code testing method as described in claim 1, characterized in that, The step of predicting the risk popularity category of the target code unit based on the risk popularity quantitative profile to obtain the code risk popularity category includes: The risk heat quantification profile is decoupled by features to obtain the heat quantification index and the risk quantification index. Based on preset clustering boundary conditions, the heat quantification index and the risk quantification index are mapped in two-dimensional space to obtain target feature coordinate points. Based on the preset four-quadrant evaluation matrix, the distribution area of ​​the target feature coordinate points is queried to obtain the code risk heat category.

5. The code testing method as described in claim 1, characterized in that, The step of generating the code test coverage threshold for the target code unit based on the code risk heat category includes: The risk popularity categories of the code are parsed to obtain the target category assessment identifier; Based on the preset threshold generation rule base and the target category evaluation identifier, rule matching is performed to obtain the target threshold generation strategy; Based on the target threshold generation strategy, the threshold value is calculated for the target code unit to obtain the code test coverage threshold.

6. The code testing method as described in claim 5, characterized in that, The step of performing code testing on the target code unit based on the code test coverage threshold to obtain target code test information includes: Based on the code test coverage threshold, test cases are filtered from the pre-acquired global test case set to obtain the target test case set; Based on the target test example set, the target code unit is subjected to automated testing to obtain the target code test information.

7. The code testing method as described in claim 6, characterized in that, After performing code testing on the target code unit based on the code test coverage threshold to obtain target code test information, the method further includes: Defect information is extracted from the target code test information to obtain code test defect information; Based on the code test defect information, the root cause of the code defect is located, and the defect root cause feature parameters are obtained; Based on the defect root cause feature parameters, the risk score of the target code unit is recalculated to obtain a dynamically updated risk score; Based on the dynamically updated risk score, the threshold generation rule base is optimized to obtain an optimized rule base, wherein the optimized rule base is used to generate the code test coverage threshold for the next code unit.

8. A code testing device, characterized in that, include: The information acquisition module is used to acquire dynamic runtime information and historical lifecycle information of the target code unit; The code evaluation module is used to evaluate the code quality of the target code unit based on the historical lifecycle information to obtain historical quality information; The profile building module is used to build a code profile based on the dynamic operation information and the historical quality information to obtain a quantitative profile of risk heat. The category prediction module is used to predict the risk popularity category of the target code unit based on the risk popularity quantitative profile, so as to obtain the code risk popularity category. The threshold mapping module is used to generate the code test coverage threshold of the target code unit based on the code risk heat category. The code testing module is used to perform code testing on the target code unit based on the code test coverage threshold, and obtain target code test information.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the code testing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the code testing method as described in any one of claims 1 to 7.

Images