Software defect testing method based on large model

Abstract

The invention provides a software defect test method based on a large model, and belongs to the technical field of software defect test.The method comprises the steps that the software test running condition is extracted, and defect feature vectors are obtained through the large model; constructing a characterization matrix through potential characterization analysis, and obtaining a defect combination through gain analysis; comparing the difference with the source code after the test to obtain a defect scene set, constructing a scene matrix, mapping the scene matrix with a representation matrix, and fusing defect combinations to obtain a defect representation vector; defects are positioned accordingly, and repair suggestions are generated in combination with a historical repair scheme of large model mining. According to the invention, accurate defect analysis and positioning are realized, the test efficiency is improved, and the missing detection rate and the false detection rate of defects are reduced.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a software defect testing method based on a large model. Background Technology

[0002] In software development and maintenance, software defect testing is a core component for ensuring software quality and improving operational stability. With the increasing complexity of software systems and the diversification of business scenarios, traditional software defect testing methods often rely on manual test case design and defect feature analysis. This is not only inefficient but also fails to cover complex business scenarios and potential defect types. In recent years, large-scale modeling technology has been gradually applied in software testing. However, existing large-scale model-based software defect testing solutions lack a systematic test process design, leading to issues such as missed or false positives in defect detection, and failing to meet the defect testing needs of complex software systems.

[0003] Therefore, this invention proposes a software defect testing method based on a large model. Summary of the Invention

[0004] This invention provides a software defect testing method based on a large model to solve the aforementioned technical problems.

[0005] This invention provides a software defect testing method based on a large model, comprising:

[0006] Step 1: Extract the test run status of the software under test in different test instances and input it into the large running model to obtain the defect feature vector of the software under test based on the corresponding test instance;

[0007] Step 2: Perform potential characterization analysis on the corresponding defect feature vectors to obtain the potential defect types and the potential impact range level and allowable expansion impact threshold of the corresponding potential defect types. Then, classify all defect feature vectors according to the test type of the test instance to obtain the characterization matrix of the same type of defect feature vectors. In this matrix, the potential defect type, potential impact range level and allowable expansion impact threshold of each defect feature vector are used as a triple array and added to the corresponding defect feature vector.

[0008] Step 3: Perform gain analysis on the characterization matrix to obtain several defect combinations corresponding to the characterization matrix;

[0009] Step 4: Capture the post-test code of the source code of the software under test in different test instances, and determine the corresponding defect scenario set of the source code based on the code differences between the post-test code and the source code;

[0010] Step 5: Construct a scenario matrix based on the defect scenario set corresponding to all test instances involved under the same representation matrix, and map the scenario matrix to the corresponding representation matrix. Combine all defect combinations under the corresponding representation matrix to obtain the defect performance vector of the software under test.

[0011] Step 6: Locate defects in the software under test according to all defect manifestation vectors and provide defect repair suggestions. The defect repair suggestions are generated based on historical defect repair schemes mined by running a large model, combined with the specific features of the defect manifestation vectors.

[0012] Preferably, before extracting the test run data of the software under test in different test instances, the process includes:

[0013] Based on the service business of the software under test, business scenario data, type scenario data, and tool scenario data are retrieved from the business database. The business scenario data refers to the data in the business database associated with the service business and the execution logic of the execution code layer that the service business depends on, and the execution code layer contains several individual business execution code segments. The type scenario data refers to the execution type data corresponding to the individual business execution code segments that generate abnormal factors in the layer logs generated by the execution code layer. The tool scenario data refers to the working status data of the log capture tool associated with each log generation time in relation to the layer logs.

[0014] Information is extracted from the business scenario data to obtain several individual business execution code segments and logical extension code segments for each individual business. The individual business execution code segments and logical extension code segments are encoded to obtain corresponding first codes and second codes. The first codes and second codes under the same individual business execution code segment are combined and retained.

[0015] Each first code is combined with each remaining second code except for the one that matches it. Ambiguity processing is performed on each code combination. If the ambiguity coefficient is greater than a preset coefficient, the corresponding code combination is removed; otherwise, the corresponding code combination is retained.

[0016] Retrieve the instance to be analyzed that matches each coding combination from the combination-instance database;

[0017] Each coding combination of individual business execution code segments involved at adjacent log generation times is determined. Combined with the tool dependency relationship of adjacent log generation times determined by the tool working tree constructed based on the tool scenario data and the radiation relationship of the log capture tool at adjacent log generation times to the individual business execution code segments involved at adjacent log generation times, an instance correction template for the corresponding coding combination is obtained.

[0018] Several instance filling templates related to the type of scenario data are determined, and a first template is obtained by uniquely retrieving from the several instance filling templates according to the execution type corresponding to each encoding combination;

[0019] The test instance is obtained by modifying and filling the corresponding instance to be analyzed according to the example correction template and the first template.

[0020] Preferably, the corresponding instance to be analyzed is modified and filled according to the example modification template and the first template to obtain a test instance, including:

[0021] According to the example correction template and the first template, the corresponding instance to be analyzed is initially corrected and filled to obtain the initial instance;

[0022] Real-time collection of business traffic data, code execution frequency data, and abnormal alarm data of the software under test within the current business cycle, to construct a real-time business status feature set;

[0023] The real-time business status feature set is input into a preset template optimization model to obtain the first adjustment parameter of the instance correction template and the second adjustment parameter of the first template. The template optimization model is a neural network model trained by running a large model to adjust the template parameters according to the real-time business status.

[0024] Based on the first adjustment parameter, the correction rules of the instance correction template are updated in layers. At the same time, based on the second adjustment parameter, the filling rules of the first template are updated precisely.

[0025] The corresponding initial instance is optimized based on the updated instance correction template and the updated first template to obtain the test instance.

[0026] Preferably, the potential defect types and the potential impact range level and allowable expansion impact threshold based on each potential defect type are obtained, including:

[0027] The defect feature vectors are quantified by their feature importance, global contribution, and historical correlation, and each defect feature vector is converted into a corresponding potential representation vector.

[0028] Calculate the cosine similarity between any two potential representation vectors. If the similarity is greater than the preset clustering threshold, the two vectors are grouped into the same cluster. Each cluster corresponds to a potential defect type, and all potential representation vectors within the cluster form the defect representation set for that potential defect type.

[0029] Extract the impact keywords from the business impact information corresponding to each potential defect type, wherein the impact keywords are related to the business module identifier, function failure description, data anomaly type and user impact scope description;

[0030] The maximum coverage matching strategy is used to match the influencing keywords with the preset influence range rule base, wherein each rule in the preset influence range rule base corresponds to an influence level and a corresponding allowable extended influence threshold.

[0031] If the affected keyword only hits one rule, the impact level of the corresponding rule will be determined as the potential impact range level of the corresponding potential defect type;

[0032] If at least two rules affect the keyword hit, the highest impact level among the hit rules will be determined as the potential impact range level of the corresponding potential defect type.

[0033] Obtain the impact time series corresponding to the corresponding potential defect type, and take the mean of the impact time series and the corresponding standard impact time series to obtain the actual impact mean and the standard impact mean;

[0034] Based on the influence weight of the corresponding potential defect type in the business system, and multiplied by the actual influence mean and the standard influence mean respectively, we obtain the weighted actual influence mean and the weighted standard influence mean.

[0035] Calculate the absolute value of the difference between the weighted actual impact mean and the weighted standard impact mean;

[0036] If the absolute value of the difference is greater than the preset impact threshold, then the allowable expansion impact threshold of the corresponding potential defect type is determined as the maximum allowable expansion threshold of the corresponding impact level in the impact range rule base;

[0037] Otherwise, the allowed expansion threshold will be determined as the minimum allowed expansion threshold for the corresponding impact level.

[0038] Preferably, gain analysis is performed on the characterization matrix to obtain the defect combination corresponding to the characterization matrix, including:

[0039] For each row of the characterization matrix consisting of a defect feature vector and a triple array, a row analysis model of the corresponding characterization matrix is ​​constructed. The coupling mapping relationship between each row vector in the characterization matrix in the dimensions of potential defect type, potential impact range level, and allowable extended impact threshold is quantified to construct a coupling matrix, and the coupling matrix is ​​applied to the row analysis model.

[0040] Based on the statistical regularity of historical defect characterization data under the same test type, the prior knowledge of the corresponding characterization matrix is ​​determined, and the coupling matrix is ​​dimensionality reduced to obtain a new matrix. The prior knowledge includes mean, variance and covariance constraints based on three dimensions: potential defect type, potential impact range level and allowable extended impact threshold.

[0041] Obtain the new eigenvector of the new matrix and the coupling eigenvector of the coupling matrix, and based on the new eigenvector and the coupling eigenvector, obtain the constraint weight of each dimension in the ternary array;

[0042] Determine the association relationship of each row vector in the representation matrix based on the remaining row vectors in each dimension of the ternary array to obtain a relation array, wherein the association relationship includes: linear association, non-linear association and no association;

[0043] When the associated array meets the standard analysis criteria, the corresponding row vector is retained; otherwise, the corresponding row vector is removed.

[0044] The retained row vectors are enhanced according to the constraint weights to obtain enhanced row vectors, and the row gain of the enhanced row vectors on the defect features is determined.

[0045] Cluster analysis is performed on all retained row vectors. Row vectors with row gain similarity higher than a preset threshold and potential defect type associations are grouped into the same cluster, and each cluster corresponds to a set of defect combinations.

[0046] Preferably, the defect combination includes the defect tendency, tendency type, and tendency generation conditions determined by the potential impact range level and the allowable extended impact threshold corresponding to the row vectors within the cluster.

[0047] Preferably, the scene matrix is ​​mapped to the corresponding representation matrix, and the defect performance vector of the software under test is obtained by combining all defect combinations under the corresponding representation matrix, including:

[0048] Based on all defect combinations under the corresponding representation matrix, the row vector cluster center features and core constraint factors of each defect combination are extracted, wherein the core constraint factors are determined based on the row vector cluster center features.

[0049] Add association features that match the dimensions of the defect scene and the triplet of the representation matrix to each defect scene vector in the scene matrix to obtain a dimension-aligned scene matrix;

[0050] The core constraint factor of each defect combination is used as a weight factor, and combined with the mapping priority of each row vector in the corresponding representation matrix, the current weight is assigned to the corresponding defect combination. Among them, the mapping weight of the row vector corresponding to the defect combination with direct tendency type is higher than the mapping weight of the row vector corresponding to the defect combination with potential tendency type. The mapping weight of the row vector corresponding to the defect combination with high tendency generation condition threshold satisfaction is higher than the mapping weight of the row vector corresponding to the defect combination with low tendency generation condition threshold satisfaction. The mapping priority of the corresponding row vector is determined according to the mapping weight of tendency type and tendency generation condition threshold.

[0051] The scene features of the dimension-aligned scene matrix are mapped to the row vectors of the representation matrix to obtain the scene-representation association matrix. The scene-representation association matrix is ​​then fused and mapped with the current weight of the defect combination to obtain the intermediate defect performance matrix.

[0052] The intermediate defect representation matrix is ​​aggregated by row dimension according to the defect scenario dimension to obtain the defect representation vector of the software under test under the corresponding representation matrix.

[0053] Preferably, the associated features are the historical probability of the defect scenario triggering the corresponding potential defect type and the matching degree between the impact range of the defect scenario and the potential impact range level of the representation matrix.

[0054] Compared with the prior art, the beneficial effects of this application are as follows:

[0055] 1. A systematic technical solution for the entire process from test instance generation, defect feature extraction, potential characterization analysis to defect location and repair has been constructed, which solves the problems of low fit between test instances and business scenarios, single defect feature analysis, inaccurate defect combination classification, and lack of comprehensive basis for defect location in existing technologies.

[0056] 2. In the test instance generation phase, through multi-dimensional scenario data retrieval, coding ambiguity handling, and template optimization driven by real-time business status, the generated test instances possess high relevance and effectiveness. In the defect feature analysis phase, latent representation analysis enables refined mining of defect features, constructs a representation matrix, and obtains accurate defect combinations through scientific gain analysis, achieving centralized and correlated analysis of defect features. In the defect performance vector generation phase, through dimensional alignment and weighted mapping of the scenario matrix and representation matrix, combined with multi-dimensional information of defect combinations, a defect performance vector that comprehensively reflects the characteristics of software defects is generated. Finally, based on the large model mining of historical repair schemes and combined with the defect performance vector, accurate positioning of software defects and generation of targeted repair suggestions are achieved.

[0057] 3. The entire method fully leverages the feature extraction and data analysis capabilities of large models, achieving intelligent, standardized, and precise software defect testing. It effectively reduces the rate of missed and false detections of defects, improves the efficiency and quality of software defect testing, and is suitable for defect testing of various complex software systems.

[0058] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings.

[0059] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0060] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings:

[0061] Figure 1 This is a flowchart of a software defect testing method based on a large model, as described in an embodiment of the present invention. Detailed Implementation

[0062] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0063] The large-scale models used in this invention are all built on the Transformer-Base architecture and are fine-tuned for the software defect testing domain. The fine-tuning dataset contains 100,000+ software defect test cases, defect feature annotation data, and code defect repair samples. The fine-tuning adopts the mini-batch gradient descent method with a batch size of 32 and an initial learning rate of 5e-5. The model converges after 20 rounds of iterative training. The input of the large-scale model is standardized software running / code data, and the output is normalized digital feature vectors / matching results (numerical range 0-1). All sub-models derived from the large-scale model (template optimization model, defect localization model, constraint factor calculation model, etc.) are all lightweight modifications based on this basic large-scale model.

[0064] In this invention, the values ​​of all preset parameters are set based on industry-standard parameters in the field of software defect testing and the statistical regularities of the fine-tuning dataset of this invention. They can be adjusted by ±10% depending on the business complexity of the software to be tested.

[0065] This invention provides a software defect testing method based on a large model, such as... Figure 1 As shown, it includes:

[0066] Step 1: Extract the test run status of the software under test in different test instances and input it into the large running model to obtain the defect feature vector of the software under test based on the corresponding test instance;

[0067] Step 2: Perform potential characterization analysis on the corresponding defect feature vectors to obtain the potential defect types and the potential impact range level and allowable expansion impact threshold of the corresponding potential defect types. Then, classify all defect feature vectors according to the test type of the test instance to obtain the characterization matrix of the same type of defect feature vectors. In this matrix, the potential defect type, potential impact range level and allowable expansion impact threshold of each defect feature vector are used as a triple array and added to the corresponding defect feature vector.

[0068] Step 3: Perform gain analysis on the characterization matrix to obtain several defect combinations corresponding to the characterization matrix;

[0069] Step 4: Capture the post-test code of the source code of the software under test in different test instances, and determine the corresponding defect scenario set of the source code based on the code differences between the post-test code and the source code;

[0070] Step 5: Construct a scenario matrix based on the defect scenario set corresponding to all test instances involved under the same representation matrix, and map the scenario matrix to the corresponding representation matrix. Combine all defect combinations under the corresponding representation matrix to obtain the defect performance vector of the software under test.

[0071] Step 6: Locate defects in the software under test according to all defect manifestation vectors and provide defect repair suggestions. The defect repair suggestions are generated based on historical defect repair schemes mined by running a large model, combined with the specific features of the defect manifestation vectors.

[0072] In this embodiment, the characterization matrix consists of all defect feature vectors involved in the same test type and three elements of each defect feature vector (potential defect type, potential impact range level, and allowable extended impact threshold). The three elements are added to the corresponding defect feature vectors, and the added vectors are combined and arranged in sequence to obtain the characterization matrix.

[0073] In this embodiment, the test run status refers to various running data and status information generated during the operation of the software under test in the test instance, including software execution logs, interface call data, code execution error information, resource utilization data, etc.

[0074] A defect feature vector is a digital vector extracted from the test run of the software under test after processing by a large model. It can represent the potential defects of the software. Each dimension of the vector corresponds to a defect feature dimension, and the dimension value is the quantitative representation result of the feature. For example, the defect feature vector of an e-commerce transaction system is: {interface response timeout feature, database write anomaly feature, permission verification missing feature, data format error feature}.

[0075] Potential characterization analysis refers to the process of performing multi-dimensional quantitative analysis and mining of defect feature vectors to extract characterization information such as potential defect attributes and scope of influence of software from the defect feature vectors.

[0076] Potential defect types refer to the categories of defects that may exist in the software under test, which are mined from the defect feature vector through potential characterization analysis. These include, but are not limited to, interface defects, database defects, permission defects, logic defects, and performance defects.

[0077] The potential impact level refers to the classification of the extent to which a potential defect will affect the business modules, operational functions, and user experience of a software system. The potential impact level is divided into four levels: L1-L4. L1 affects only a single functional point, L2 affects a single business module, L3 affects multiple related business modules, and L4 affects the entire software system.

[0078] The permissible expanded impact threshold refers to the preset threshold at which the scope of impact of a potential defect can be expanded. This threshold corresponds to the potential impact range level. For example, for potential impact range levels L1-L4, the preset permissible expanded impact thresholds are 1, 3, 6, and 10 respectively. The threshold value represents the number of function points affected. That is, the maximum number of function points that can be expanded to be affected by a defect at level L1 is 1.

[0079] In this embodiment, the ternary array is: {potential defect type, potential impact range level, and allowable extended impact threshold corresponding to the defect feature vector}.

[0080] A representation matrix is ​​a matrix formed by combining and arranging all the supplemented defect feature vectors under the same test type in a preset order, with each row of the matrix corresponding to a supplemented defect feature vector.

[0081] Gain analysis refers to the quantitative analysis of the row and column dimensions of a representation matrix, and the calculation of the gain value of each row vector in the matrix.

[0082] A defect combination refers to a set of defects formed by combining defect feature vectors that have correlations and similar gain characteristics through gain analysis of the representation matrix. Defects in the same defect combination have correlation characteristics that induce and influence each other. For example, in the order payment test type of an e-commerce transaction system, database defects and interface defects are related. Interface response timeouts will induce database write exceptions. After gain analysis, the two form a defect combination.

[0083] In this embodiment, post-test code refers to the code file generated after the source code of the software under test has changed its code content after the test instance is executed, including code modifications, temporary variable generation, error code lines, etc. caused by the test execution in the source code.

[0084] A defect scenario set refers to a collection of specific business scenarios in which defects exist in the software under test, discovered by comparing the code differences between the post-test code and the source code. Each defect scenario corresponds to a defect situation that occurs in the software during a specific business execution process. For example, by comparing the source code of an e-commerce transaction system with the post-test code of an order payment test instance, it was found that the code difference occurred in the parameter passing process of the WeChat payment interface. Thus, the corresponding defect scenario was determined to be an anomaly in the parameter passing of the WeChat payment interface. Defect scenarios corresponding to multiple test instances are combined to form a defect scenario set.

[0085] A scenario matrix refers to a matrix formed by digitizing the features of each defect scenario in the defect scenario set corresponding to all test instances under the same representation matrix, and arranging them in a preset order. For example, in the representation matrix of the order payment test type of an e-commerce transaction system, the defect scenario set includes: abnormal parameter transmission of WeChat payment interface and delay in writing to Alipay payment database. The feature encoding of the two defect scenarios yields vector 1: [1,0,0.9,0.1] and vector 2: [0,1,0.2,0.8], which are then arranged to form a scenario matrix of 2 rows and 4 columns.

[0086] The defect representation vector refers to a digital vector generated by mapping the scene matrix to the corresponding representation matrix and integrating the information of all defect combinations under the corresponding representation matrix. This vector can comprehensively represent the multi-dimensional information of the software under test, such as defect scenes, defect features, and defect combinations.

[0087] In this embodiment, a defect localization model is constructed. The defect manifestation vector is input into the model, which performs feature matching based on the code architecture diagram and business process tree of the software under test. The model outputs the specific file, specific line of code, and corresponding business process of the defect in the source code, thus achieving defect localization. Subsequently, a historical defect repair solution library is built. This library is constructed by crawling and organizing publicly available defect repair cases in the software testing field and the company's historical defect repair records through a large model. The large model performs semantic analysis on the specific features of the defect manifestation vector and performs similarity matching in the historical defect repair solution library to discover repair solutions for similar defects. Finally, the historical repair solutions are adapted based on the technical architecture and business requirements of the software under test to generate targeted defect repair suggestions. Here, defect localization refers to the process of determining the specific location and specific business process of the software defect in the source code based on the feature information of the defect manifestation vector, combined with the code architecture and business process of the software under test. For example, based on the feature information of the defect manifestation vector of an e-commerce transaction system, combined with the code architecture of the payment module, the specific location of the defect is determined to be the parameter passing line of the pay_wechat() function of the WeChat payment interface. Defect remediation suggestions refer to targeted remediation plans generated for identified software defects based on historical defect remediation solutions discovered through large-scale model mining, combined with the specific characteristics of the defect manifestation vector of the software under test. These plans include code modification suggestions, business logic optimization suggestions, and technical solution adjustment suggestions. For example, regarding the defect of abnormal parameter transmission in the WeChat Pay interface, the remediation plan discovered by the large-scale model for similar historical defects is to optimize the interface parameter validation rules and transmission format. Based on the characteristic of incorrect parameter format in the current defect manifestation vector, the generated remediation suggestion is: add parameter format validation code to the pay_wechat() function and change the parameter transmission format from JSON string to key-value pair format.

[0088] In this embodiment, the defect localization model is a classification + regression model based on a large-scale model. The model structure and training data are as follows:

[0089] Model structure: The input layer is a defect representation vector (dimension 256), the hidden layer consists of 3 fully connected layers (512, 256, and 128 neurons respectively), and the output layer is divided into two parts: classification output (the code file / business module where the defect is located, using softmax activation) and regression output (the line number of the code where the defect is located, using linear activation).

[0090] Training data: Includes defect manifestation vectors and corresponding defect location annotation data (80,000+ samples in total). The annotation data comes from the company's historical defect repair records and publicly available software defect cases.

[0091] The beneficial effects of the above technical solution are as follows: It constructs a systematic software defect testing method based on a large model, which covers the entire process from test operation status extraction and defect feature vector generation to defect location and repair. It achieves refined mining of defect features through potential characterization analysis, constructs a characterization matrix to achieve centralized management of defect features under the same test type, obtains defect combinations by combining gain analysis and integrates multi-dimensional information from the scenario matrix and characterization matrix to generate defect performance vectors, and finally achieves accurate defect location and targeted repair suggestions based on the large model. Overall, it improves the intelligence, accuracy and efficiency of software defect testing, effectively reduces the defect missed detection rate and false detection rate, and provides a standardized technical solution for defect testing of complex software systems.

[0092] This invention provides a software defect testing method based on a large model, which extracts the test run status of the software under test before different test instances, including:

[0093] Based on the service business of the software under test, business scenario data, type scenario data, and tool scenario data are retrieved from the business database. The business scenario data refers to the data in the business database associated with the service business and the execution logic of the execution code layer that the service business depends on, and the execution code layer contains several individual business execution code segments. The type scenario data refers to the execution type data corresponding to the individual business execution code segments that generate abnormal factors in the layer logs generated by the execution code layer. The tool scenario data refers to the working status data of the log capture tool associated with each log generation time in relation to the layer logs.

[0094] Information is extracted from the business scenario data to obtain several individual business execution code segments and logical extension code segments for each individual business. The individual business execution code segments and logical extension code segments are encoded to obtain corresponding first codes and second codes. The first codes and second codes under the same individual business execution code segment are combined and retained.

[0095] Each first code is combined with each remaining second code except for the one that matches it. Ambiguity processing is performed on each code combination. If the ambiguity coefficient is greater than a preset coefficient, the corresponding code combination is removed; otherwise, the corresponding code combination is retained.

[0096] Retrieve the instance to be analyzed that matches each coding combination from the combination-instance database;

[0097] Each coding combination of individual business execution code segments involved at adjacent log generation times is determined. Combined with the tool dependency relationship of adjacent log generation times determined by the tool working tree constructed based on the tool scenario data and the radiation relationship of the log capture tool at adjacent log generation times to the individual business execution code segments involved at adjacent log generation times, an instance correction template for the corresponding coding combination is obtained.

[0098] Several instance filling templates related to the type of scenario data are determined, and a first template is obtained by uniquely retrieving from the several instance filling templates according to the execution type corresponding to each encoding combination;

[0099] The test instance is obtained by modifying and filling the corresponding instance to be analyzed according to the example correction template and the first template.

[0100] In this embodiment, the instance correction template applies to all log generation times except for the last log generation time.

[0101] In this embodiment, business scenario data refers to all data in the business database that is associated with the service business of the software under test and the execution logic of the execution code layer on which the service business depends. It is the basic data that reflects the actual business operation status and execution logic of the software, including business execution logs, business parameter configuration data, function call records, etc.

[0102] The execution code layer refers to the code layer in the software under test that implements specific service business. This layer consists of several separate business execution code segments that implement different business functions. For example, the execution code layer corresponding to the order payment business of an e-commerce transaction system is the payment module code layer, which includes the code implementation of functions such as WeChat Pay, Alipay, and UnionPay.

[0103] A standalone business execution code segment refers to a code fragment in the execution code layer that implements a single specific business function. It is the basic unit that constitutes the execution code layer. For example, the WeChat payment function implementation code and the Alipay payment function implementation code in the payment module code layer of an e-commerce transaction system are standalone business execution code segments.

[0104] Type scenario data refers to the execution type data corresponding to the individual business execution code segment that caused the anomaly in the layer logs generated by the execution code layer. Layer logs refer to the log files generated by the execution code layer during runtime. Anomalies refer to various factors that cause code execution errors. Execution type data refers to the code execution type of the individual business execution code segment, including synchronous execution, asynchronous execution, and loop execution. For example, in the layer logs of the payment module of an e-commerce transaction system, if the individual business execution code segment for WeChat Pay experiences a callback timeout exception due to asynchronous execution, the corresponding type scenario data is the asynchronous execution type-related data for that code segment, including the asynchronous execution timeout and callback address configuration.

[0105] Tool scenario data refers to the working status data of the log capture tool associated with each log generation time related to the layer logs. Log capture tools are tools used to collect execution logs at the code execution layer, such as ELK and Fluentd. Working status data includes the tool's running status, collection frequency, data transfer rate, and service resource consumption. For example, if the log generation time is 10:00 AM on [Date], 2025, and the log capture tool involved at that time is ELK, the corresponding tool scenario data would be: ELK running normally at that time, collection frequency of 1 time / second, data transfer rate of 10MB / s, and CPU utilization of 20%.

[0106] In this embodiment, the logic extension code segment refers to a code fragment formed by logically extending and branching the business logic based on the separate business execution code segment. For example, the core logic of the separate business execution code segment of WeChat Pay is the payment interface call, and its logic extension code segment is the code implementation of the retry logic and exception prompt logic after payment failure.

[0107] The first code refers to the encoding information obtained after standardizing the individual business execution code segment. The encoding rule adopts a combination of numbers and letters. The code must uniquely identify the corresponding individual business execution code segment. For example, the first code corresponding to the individual business execution code segment of WeChat Pay is PAY-WX-001, and that of Alipay is PAY-ZFB-002.

[0108] The second encoding refers to the encoding information obtained after standardizing the encoding of the logic extension code segment. The encoding rules are consistent with the first encoding, and there is an association identifier with the first encoding of the corresponding individual business execution code segment. For example, the second encoding corresponding to the logic extension code segment of the payment failure retry logic of WeChat Pay is PAY-WX-001-01, and the second encoding corresponding to the exception prompt logic is PAY-WX-001-02.

[0109] In this embodiment, the ambiguity coefficient ,in, The semantic similarity between the core logic H1 of the first encoding corresponding to the separate business execution code segment and the extended logic H2 of the second encoding corresponding to the extended logic code segment is calculated using the cosine similarity algorithm, and the logical feature vector is output based on the text embedding layer of the running large model. The runtime dependency of the code segment corresponding to the first encoding. 1. Runtime dependencies of the code segment corresponding to the second encoding The Pearson correlation coefficient, with a value ranging from 0 to 1, depends on the code call records taken from the business database. It should be noted that in this embodiment, the preset coefficient value is 0.7.

[0110] In this embodiment, the combination-instance database refers to a pre-built database that maps code combinations to instances to be analyzed. The database stores various valid code combinations and their corresponding software test instances. The instances to be analyzed refer to the original test instances that match the code combinations without modification or filling. For example, in the combination-instance database, the instance to be analyzed corresponding to the code combination [PAY-WX-001, PAY-WX-001-01] is the original test case of the WeChat Pay function, which includes the basic payment interface call steps.

[0111] In this embodiment, the tool working tree is a directed tree structure, and the construction process consists of four steps, as follows:

[0112] Node initialization: All log capture tools are treated as nodes in a tree. The root node is the core log analysis tool (such as ELK), and the child nodes are log collection / transmission tools (such as Fluentd and Filebeat). The node attributes include the tool's unique identifier and working status threshold (such as CPU utilization ≤80% is normal).

[0113] Construct tool dependency edges: Based on tool scenario data, add directed edges to tool nodes with dependency relationships. The weight of the edge is the dependency strength Wd (value 0-1), where Wd = number of times the dependent tool is called / total number of times the core tool is called;

[0114] Construct radiation relationship edges: Add a directed edge to each tool node pointing to the individual business execution code segment that it can collect. The weight of the edge is the radiation coverage Wc (value 0-1), Wc = the number of logs collected by the tool for that code segment / the total number of logs for that code segment.

[0115] Tree structure optimization: Invalid edges with dependency strength Wd < 0.1 and radiation coverage Wc < 0.05 are removed, and multiple radiation nodes in the same code segment are merged to obtain a simplified tool working tree with a depth of no more than 3 levels to ensure analysis efficiency.

[0116] Tool dependencies refer to the runtime dependencies between different log scraping tools, including master-slave dependencies and call dependencies. For example, the ELK tool needs to call the data collection interface of the Fluentd tool to perform log analysis, which is a call dependency between the two.

[0117] Radiation relationship refers to the log collection coverage relationship of a log capture tool on individual business execution code segments in the execution code layer. That is, which individual business execution code segments can the tool collect the runtime logs of. For example, the Fluentd tool can collect the logs of the individual business execution code segments of WeChat Pay and Alipay Pay in the payment module, and the two have a radiation relationship.

[0118] An instance correction template refers to a standardized template developed for each valid coding combination to correct the instance to be analyzed, based on the tool dependencies and radiation relationships determined by the tool working tree. The template includes rules for correcting test steps and test environment configurations for the instance to be analyzed. For example, for the instance correction template of coding combination [PAY-WX-001, PAY-WX-001-01], the correction rules based on the tool dependencies and radiation relationships are: add state detection steps for the ELK and Fluentd tools to the test steps, and set the log collection frequency of the test environment to 1 time / second.

[0119] Instance population templates refer to a set of templates related to type scenario data used to populate data for unanalyzed instances. The templates contain test data population rules, test parameter configuration rules, etc., corresponding to individual business execution code segments of different execution types.

[0120] The first template refers to the standardized template used to fill the instance to be analyzed, which is uniquely retrieved from several instance filling templates according to the execution type corresponding to each valid coding combination. For example, the execution type corresponding to the coding combination [PAY-WX-001, PAY-WX-001-01] is asynchronous execution. The filling template corresponding to asynchronous execution is retrieved from the instance filling templates as the first template. The template contains filling rules for test parameters such as the timeout time and callback address of asynchronous execution.

[0121] The beneficial effects of the above technical solution are as follows: By retrieving multi-dimensional scenario data from the business database, deep binding between test instance generation and the actual business scenario, code execution status, and tool working status of the software under test is achieved. Through coding and ambiguity handling, an effective coding combination is obtained, ensuring the correlation between the business logic and code logic corresponding to the test instance. By combining the tool working tree to construct an instance correction template and retrieving the first template according to the execution type, the standardized correction and filling of the instance to be analyzed is achieved. The generated test instances are highly targeted and effective, providing a high-quality test foundation for the subsequent extraction of defect feature vectors and effectively improving the accuracy of subsequent defect testing.

[0122] This invention provides a software defect testing method based on a large model. The method involves modifying and filling in the corresponding instances to be analyzed according to the instance modification template and the first template to obtain test instances, including:

[0123] According to the example correction template and the first template, the corresponding instance to be analyzed is initially corrected and filled to obtain the initial instance;

[0124] Real-time collection of business traffic data, code execution frequency data, and abnormal alarm data of the software under test within the current business cycle, to construct a real-time business status feature set;

[0125] The real-time business status feature set is input into a preset template optimization model to obtain the first adjustment parameter of the instance correction template and the second adjustment parameter of the first template. The template optimization model is a neural network model trained by running a large model to adjust the template parameters according to the real-time business status.

[0126] Based on the first adjustment parameter, the correction rules of the instance correction template are updated in layers. At the same time, based on the second adjustment parameter, the filling rules of the first template are updated precisely.

[0127] The corresponding initial instance is optimized based on the updated instance correction template and the updated first template to obtain the test instance.

[0128] In this embodiment, the hierarchical update includes:

[0129] The code execution frequency data is mapped to the code segment dependency weight correction factor, the weight configuration of the code segment dependency correction is updated, and the priority of the dependency constraint of the high execution frequency code segment is increased. The weight correction factor is calculated as: original dependency weight × actual execution frequency of the corresponding code segment / average execution frequency of all code segments.

[0130] Based on the type and frequency of abnormal alarm data, adjust the location and intensity of abnormal injection points, and prioritize the code segments corresponding to high-frequency alarms as injection points and increase their injection intensity. The abnormal injection point intensity = 1 + abnormal alarm frequency of the code segment / average alarm intensity of all code segments, with a value range of 0.1 to 1.

[0131] By combining the request timing characteristics of business traffic data, Markov chains are used to calculate the execution transition probability of code segments, and the execution order is reconstructed from high to low based on the transition probability.

[0132] In this embodiment, precise updates include:

[0133] The template optimization model fits the business traffic data to a normal distribution and updates the filling rules for the input parameter value range to make the parameter value distribution consistent with the actual business traffic.

[0134] Based on the function call percentage data, adjust the filling rules for the logical branch trigger probability so that the trigger probability of each branch in the test instance matches the actual business percentage. The adjusted logical branch trigger probability = the probability before adjustment × the actual function call percentage of the corresponding branch / the average call percentage of all branches.

[0135] Real-time data relationships from the business database are introduced to update the business data population rules, ensuring that the population data meets the relationship constraints of real business operations. Specifically, based on real-time data from the business database, the relationship support between data fields is calculated, and only the relationship between fields with a support greater than 0.8 is retained as the population constraint.

[0136] In this embodiment, according to the preset test steps and test environment correction rules in the instance correction template, the original test steps of the instance to be analyzed are added, deleted, or modified, and the test environment configuration is adjusted; according to the preset test data and test parameter filling rules in the first template, the corresponding test data and parameters are filled into the instance to be analyzed, and after the basic correction and filling are completed, the initial instance is output.

[0137] Real-time business status feature set refers to the feature set formed after real-time collection of various business operation status data of the software under test during the current business cycle, and after feature extraction and standardization processing. It includes multi-dimensional features such as business traffic, code execution, and abnormal alarms. For example, if the current business cycle of an e-commerce transaction system is the morning peak from 8:00 to 10:00, the corresponding real-time business status feature set includes features such as a payment business traffic of 1000 transactions / minute, a WeChat payment code execution frequency of 500 times / minute, and a payment interface abnormal alarm frequency of 5 times / minute during this period.

[0138] The template optimization model refers to a neural network model trained on a large model to adjust the parameters of the instance correction template and the first template based on real-time business conditions. The model's input is a set of real-time business state features, and its output is the adjustment parameters of the instance correction template and the first template. With over 10,000 samples, this model is pre-trained using the Transformer architecture and fine-tuned using a large amount of business state data and historical template parameter adjustment data, enabling it to accurately output adjustment parameters based on real-time business conditions.

[0139] The first adjustment parameter refers to the digital parameters output by the template optimization model used to adjust the parameters of the instance correction template. The parameter values ​​correspond one-to-one with the correction rules of the instance correction template. For example, if the first adjustment parameter is [0.8, 1.2, 0.9], it corresponds to the adjustment coefficients of code segment dependency weight, exception injection point strength, and execution order priority in the instance correction template, respectively. ,in, Correct the template rule parameters for the updated instance; These are the original rule parameters; This is the first parameter to adjust.

[0140] The second adjustment parameter refers to the digital parameters output by the template optimization model used to adjust the parameters of the first template. The parameter values ​​correspond one-to-one with the filling rules of the first template. For example, if the second adjustment parameter is [1.5, 0.8, 1.0], it corresponds to the adjustment coefficients of the input parameter value range, the probability of triggering logical branches, and the correlation of business data in the first template, respectively. ,in, Populate the rule parameters for the updated first template; These are the original fill rule parameters; This is the second adjustment parameter;

[0141] It should be noted that the adjustment parameter range is 0.5-2.0. When the parameter is >1, the rule is amplified; when it is <1, the rule is reduced; and when it is =1, the rule remains unchanged.

[0142] In this embodiment, the updates are performed in layers. For example, for the code segment dependency level, the dependency weight of the WeChat Pay code segment with high execution frequency is updated from 1.0 to 0.8 according to the adjustment coefficient of 0.8 of the first adjustment parameter; for the exception injection point strength level, the strength of the payment interface exception injection point is updated from 0.5 to 0.6 according to the adjustment coefficient of 1.2.

[0143] For precise updates, such as for the input parameter value range dimension, based on the adjustment coefficient of 1.5 of the second adjustment parameter, the value range of the payment amount is updated from 0-1000 yuan to 0-1500 yuan; for the logical branch trigger probability dimension, based on the adjustment coefficient of 0.8, the trigger probability of the payment failure branch is updated from 30% to 24%.

[0144] The beneficial effects of the above technical solution are as follows: Based on the initial correction and filling, a feature set is constructed in combination with the real-time business status of the software under test. The template adjustment parameters are accurately output through the template optimization model, realizing the layered and precise update of the instance correction template and the first template. This completes the secondary optimization of the initial instance, enabling the generated test instance to dynamically adapt to the real-time business operation status of the software. This solves the problem of the disconnect between traditional test instances and real-time business status, further improving the effectiveness and relevance of the test instances, and providing a more realistic test foundation for the accurate extraction of subsequent defect features.

[0145] This invention provides a software defect testing method based on a large model, which obtains potential defect types and, for each potential defect type, a potential impact range level and an allowable extended impact threshold, including:

[0146] The defect feature vectors are quantified by their feature importance, global contribution, and historical correlation, and each defect feature vector is converted into a corresponding potential representation vector.

[0147] Calculate the cosine similarity between any two potential representation vectors. If the similarity is greater than the preset clustering threshold, the two vectors are grouped into the same cluster. Each cluster corresponds to a potential defect type, and all potential representation vectors within the cluster form the defect representation set for that potential defect type.

[0148] Extract the impact keywords from the business impact information corresponding to each potential defect type, wherein the impact keywords are related to the business module identifier, function failure description, data anomaly type and user impact scope description;

[0149] The maximum coverage matching strategy is used to match the influencing keywords with the preset influence range rule base, wherein each rule in the preset influence range rule base corresponds to an influence level and a corresponding allowable extended influence threshold.

[0150] If the affected keyword only hits one rule, the impact level of the corresponding rule will be determined as the potential impact range level of the corresponding potential defect type;

[0151] If at least two rules affect the keyword hit, the highest impact level among the hit rules will be determined as the potential impact range level of the corresponding potential defect type.

[0152] Obtain the impact time series corresponding to the corresponding potential defect type, and take the mean of the impact time series and the corresponding standard impact time series to obtain the actual impact mean and the standard impact mean;

[0153] Based on the influence weight of the corresponding potential defect type in the business system, and multiplied by the actual influence mean and the standard influence mean respectively, we obtain the weighted actual influence mean and the weighted standard influence mean.

[0154] Calculate the absolute value of the difference between the weighted actual impact mean and the weighted standard impact mean;

[0155] If the absolute value of the difference is greater than the preset impact threshold, then the allowable expansion impact threshold of the corresponding potential defect type is determined as the maximum allowable expansion threshold of the corresponding impact level in the impact range rule base;

[0156] Otherwise, the allowed expansion threshold will be determined as the minimum allowed expansion threshold for the corresponding impact level.

[0157] In this embodiment, the potential representation vector is: {the feature importance, global contribution, and historical correlation of the corresponding defect feature vector};

[0158] Feature importance Tz ;

[0159] Global contribution ,in, The information entropy of the defect dataset; The conditional entropy of the dataset given feature A;

[0160] Historical correlation ,in, Let i be the i-th dimension of the current defect feature vector; The corresponding dimension of the historical defect feature vector is used, and the historical data is taken from defect test samples from the past 6 months.

[0161] It should be noted that the values ​​of the above three indicators are all normalized to 0-1, the dimension of the potential representation vector is consistent with the defect feature vector, and each defect feature dimension corresponds to a triple-weighted potential representation sub-vector.

[0162] The clustering threshold refers to the preset cosine similarity threshold used to determine whether two potential representation vectors belong to the same cluster. The threshold is preset according to the complexity of the defect type of the software under test, and the preset clustering threshold is 0.9.

[0163] The K-means clustering algorithm is used to perform cluster analysis on all potential representation vectors. Vectors with cosine similarity higher than the preset clustering threshold are grouped into the same cluster, while those with cosine similarity lower than the clustering threshold are divided into separate clusters. Then, all potential representation vectors within the cluster are aggregated to form a defect representation set for that potential defect type.

[0164] Business impact information refers to information related to the impact of potential defects on the software's business operations, functional implementation, and user experience. This includes the impact on business modules, functional failures, and abnormal data states. For example, the business impact information corresponding to an interface defect in an e-commerce transaction system is that the WeChat Pay interface response times out, causing the WeChat Pay function to malfunction and user payment requests to fail. In this case, the extracted impact keywords are: WeChat Pay interface, response timeout, functional failure, and payment request failure.

[0165] In this embodiment, the maximum coverage matching strategy is used to match influencing keywords with the influence scope rule base, including:

[0166] Iterate through all rules Rg={r1,r2,...,rn} in the preset influence range rule base, and calculate the matching rate of each rule with the keyword set K. ,in, The number of keywords in the intersection of rules rj and K;

[0167] Elimination of matching rate Invalid rules with a value < 0.5 are used to obtain the candidate rule set R11;

[0168] Calculate the number of keywords covered by each rule in the candidate rule set R11, and select the rule with the highest coverage as the optimal matching rule; if multiple rules have the same coverage, select the rule with the highest matching rate.

[0169] The impact level of the potential defect type is determined according to the impact level corresponding to the optimal matching rule. If the candidate rule set R11 is empty, the impact level is set to L1, which is the lowest level, by default.

[0170] The scope of influence rule base refers to a pre-built database that stores scope of influence levels and corresponding keyword rules. Each rule in the database corresponds to a scope of influence level and contains keywords related to the business module, function failure, data anomaly, etc., for that level. For example, in the scope of influence rule base, the rule keywords for level L1 are: single function point, single interface, local data, and for level L2 they are: single business module, multiple interfaces, data within a module.

[0171] The impact time series refers to the numerical sequence of the degree of impact of potential defects on the software at various points in time within a preset time window. The time window is set according to the business type of the software under test; the time window is 1 hour for real-time transaction software and 24 hours for non-real-time management software. The sampling interval within the time window is 5 minutes / 1 hour, corresponding to high-frequency / low-frequency sampling, respectively, and the degree of impact is also specified. ,in, The percentage of functional failures. The percentage of data anomalies; The proportion of users affected.

[0172] The standard impact time series is set by industry standards and software requirements specifications. Different impact levels correspond to fixed standard series. For example, the standard series for L1 level is 0.2 for all sampling points, and the standard series for L4 level is 0.8 for all sampling points.

[0173] The actual impact mean and the standard impact mean are both calculated arithmetic mean.

[0174] In this embodiment, the weighting of the impact factors is determined based on the degree of influence of the defect type on the core business of the software, using the Analytic Hierarchy Process (AHP). Defects related to core business (such as payment and login) are assigned a weight of 0.8-0.9, while defects related to non-core business (such as logs and statistics) are assigned a weight of 0.3-0.7. Specific weight values ​​are shown in Table 1 below.

[0175] Table 1. List of Influence Weights

[0176]

[0177] The preset impact threshold refers to the threshold set in advance to determine whether the potential defect's extended impact threshold is the maximum or minimum value. This threshold is preset based on the software's fault tolerance, and the preset impact threshold is 0.2.

[0178] The beneficial effects of the above technical solution are as follows: by weighting feature importance, global contribution, and historical correlation, the defect feature vector is accurately converted into a potential representation vector; by combining the cosine similarity clustering algorithm, the potential defect types are accurately classified; by extracting influencing keywords and using the maximum coverage matching strategy to determine the potential influence range level, the accuracy of qualitative analysis of defect influence range is improved; by constructing influence time series and standard influence time series and combining weighted mean analysis to determine the allowable expansion influence threshold, the quantitative assessment of defect influence expansion boundary is realized, and the overall refinement and standardization level of potential representation analysis is improved.

[0179] This invention provides a software defect testing method based on a large model, which performs gain analysis on the representation matrix to obtain defect combinations corresponding to the representation matrix, including:

[0180] For each row of the characterization matrix consisting of a defect feature vector and a triple array, a row analysis model of the corresponding characterization matrix is ​​constructed. The coupling mapping relationship between each row vector in the characterization matrix in the dimensions of potential defect type, potential impact range level, and allowable extended impact threshold is quantified to construct a coupling matrix, and the coupling matrix is ​​applied to the row analysis model.

[0181] Based on the statistical regularity of historical defect characterization data under the same test type, the prior knowledge of the corresponding characterization matrix is ​​determined, and the coupling matrix is ​​dimensionality reduced to obtain a new matrix. The prior knowledge includes mean, variance and covariance constraints based on three dimensions: potential defect type, potential impact range level and allowable extended impact threshold.

[0182] Obtain the new eigenvector of the new matrix and the coupling eigenvector of the coupling matrix, and based on the new eigenvector and the coupling eigenvector, obtain the constraint weight of each dimension in the ternary array;

[0183] Determine the association relationship of each row vector in the representation matrix based on the remaining row vectors in each dimension of the ternary array to obtain a relation array, wherein the association relationship includes: linear association, non-linear association and no association;

[0184] When the associated array meets the standard analysis criteria, the corresponding row vector is retained; otherwise, the corresponding row vector is removed.

[0185] The retained row vectors are enhanced according to the constraint weights to obtain enhanced row vectors, and the row gain of the enhanced row vectors on the defect features is determined.

[0186] Cluster analysis is performed on all retained row vectors. Row vectors with row gain similarity higher than a preset threshold and potential defect type associations are grouped into the same cluster, and each cluster corresponds to a set of defect combinations.

[0187] Preferably, the defect combination includes the defect tendency, tendency type, and tendency generation conditions determined by the potential impact range level and the allowable extended impact threshold corresponding to the row vectors within the cluster.

[0188] In this embodiment, the row analysis model refers to a mathematical model constructed for the row vectors of the representation matrix to analyze the characteristics of the row vectors and the relationships between the vectors. The core of the model is the coupling matrix, which is the basic model for realizing the gain analysis of the representation matrix.

[0189] The coupling mapping relationship refers to the mapping relationship between the row vectors of the characterization matrix and the three dimensions of potential defect type, potential impact range level, and allowable extended impact threshold. For example, the potential defect type of interface defect has a strong coupling mapping relationship with the potential impact range level of L1 and the allowable extended impact threshold of 1. That is, interface defect is likely to correspond to L1 level and threshold of 1.

[0190] The coupling matrix is ​​a constructed 3×3 coupling matrix, with rows and columns corresponding to the three dimensions of potential defect type, potential impact range level, and allowable extended impact threshold, respectively. The elements of the matrix are coupling coefficients, represented by values ​​from 0 to 1. ,in, Let i be the covariance of the eigenvalues ​​of dimension i and dimension j; , , i and j respectively, are the variances of the eigenvalues ​​in dimensions i and j. The eigenvalues ​​are the quantized values ​​of all row vectors in the characterization matrix in the corresponding dimension (potential defect types are encoded as numbers according to preset rules, such as interface class = 1, database class = 2; the impact range level L1-L4 corresponds to 1-4; the allowed extended impact threshold is the original value), and the diagonal elements are 1.

[0191] Prior knowledge refers to the prior information used to constrain the analysis of the representation matrix, which is determined based on the statistical regularities of historical defect representation data under the same test type. It includes the mean, variance, and covariance constraints of three dimensions: potential defect type, potential impact range level, and allowable extended impact threshold. For example, in the historical defect representation data of the order payment test type of e-commerce transaction system, the mean of the potential impact range level is L1.2, the variance is 0.3, and the covariance between the potential defect type and the allowable extended impact threshold is 0.2.

[0192] Dimensionality reduction refers to the use of data dimensionality reduction algorithms to simplify the dimensions of a coupling matrix, removing redundant dimensions and invalid information. Commonly used dimensionality reduction algorithms include PCA principal component analysis and LDA linear discriminant analysis. During the dimensionality reduction process, it is ensured that the retention rate of the core coupling relationship is not less than 90%.

[0193] The new matrix refers to the simplified matrix obtained after dimensionality reduction of the coupling matrix.

[0194] The new eigenvector refers to the eigenvector obtained after performing eigenvalue decomposition on the new matrix; the coupled eigenvector refers to the eigenvector obtained after performing eigenvalue decomposition on the coupled matrix, and its dimension is consistent with the eigendimensional dimension of the coupled matrix. For example, after eigenvalue decomposition, a 3×3 coupled matrix yields a 3-dimensional coupled eigenvector [0.92, 0.85, 0.78], which corresponds to the coupled features of potential defect type, potential influence range level, and allowable extended influence threshold dimensions, respectively.

[0195] Constraint weights refer to the quantized weights used to constrain the features of each dimension in the ternary array, calculated based on the new eigenvector of the new matrix and the coupled eigenvector of the coupled matrix. The weight values ​​are 0-1. For example, by combining the new eigenvector [0.88, 0.82] and the coupled eigenvector [0.92, 0.85, 0.78], the constraint weights of the potential defect type, potential influence range level, and allowable extended influence threshold dimensions in the ternary array are calculated to be [0.90, 0.84, 0.75].

[0196] In this embodiment, ,in, Let k be the constraint weights for the k-th dimension, where k = 1, 2, 3; The k-th component of the new eigenvector of the new matrix; The contribution rate to the new feature vector; The contribution rate of the coupled feature vector, and ; It is the k-th component of the coupling eigenvector of the coupling matrix.

[0197] In this embodiment, the relation array corresponding to the row vector is: {relationship type in different dimensions of the triple array}, such as {linear relationship, non-linear relationship, linear relationship}, which means that the vector is linearly related to the remaining row vectors in the dimensions of potential defect type and allowable expansion impact threshold, and non-linearly related in the dimension of potential impact range level.

[0198] In this embodiment, the standard analysis criterion is a quantitative decision rule for retaining / removing row vectors, specifically:

[0199] Core judgment criterion: The relationship between the row vector and the remaining row vectors in the potential defect type dimension (1st dimension) must be linear or non-linear, and must not be unrelated;

[0200] Auxiliary judgment condition: The number of unrelated dimensions of a row vector is ≤2, that is, a maximum of 2 dimensions are allowed to be unrelated, but if the core dimension is unrelated, the row vector is removed regardless of the other dimensions.

[0201] Methods for determining association: Pearson correlation coefficient is used to determine linear association (|r|≥0.6 is linear association), mutual information is used to determine nonlinear association (mutual information≥0.3 is nonlinear association), and the rest are no association.

[0202] Enhanced row vectors refer to row vectors obtained by combining the retained row vectors with the constraint weights of each dimension of the triple array for feature weighting enhancement. For example, if the original row vector is [0.9,0.1,0.2,0.0,interface class defect,L1,1], after combining the constraint weights [0.90,0.84,0.75] to weight the dimensions of the triple array, the enhanced row vector is [0.9,0.1,0.2,0.0,interface class defect(0.90),L1(0.84),1(0.75)].

[0203] In this embodiment, the line gain ,in, To enhance row vectors, This is the original row vector; is the mean vector representing all original row vectors in the matrix; Dist is the Euclidean distance, normalized to 0-1.

[0204] Row gain similarity refers to the degree of similarity in row gain features between any two enhanced row vectors. It is calculated using the cosine similarity algorithm, with a preset threshold of 0.85. The K-means clustering algorithm is used to cluster the retained row vectors, and the number of clusters is determined by the elbow rule (the inflection point is the optimal number of clusters). The criteria for determining the association of defect types are: the potential defect types of the two row vectors belong to the same defect category (such as interface type, database type), or there is a direct causal relationship (such as interface type defects inducing database type defects, which is obtained from historical defect data statistics).

[0205] In this embodiment, defect tendency refers to the development trend and manifestation characteristics of defects that are likely to occur in the software corresponding to the row vector within the cluster during operation. For example, in a certain defect combination of the payment module of an e-commerce transaction system, the row vectors all correspond to interface class and database class defects. The defect tendency of this defect combination is that abnormal payment interface calls can easily induce database write delays, and the two have a cascading trend.

[0206] In this embodiment, direct tendency type refers to defect tendency that can be directly manifested in software operation and can be directly detected through testing; latent tendency type refers to defect tendency that is difficult to manifest in conventional testing and will only appear in specific business scenarios and specific operating conditions.

[0207] The tendency generation condition refers to the specific conditions under which a defect tendency can occur, determined by the potential impact range level and the allowed extended impact threshold in the ternary array. For example, if the potential impact range level of a defect combination is L2 and the allowed extended impact threshold is 3, its tendency generation condition is: when the impact range of the defect covers the entire business module of the payment module and the number of extended impact function points reaches 3 or more, interface defects are likely to induce database defects.

[0208] The beneficial effects of the above technical solution are as follows: By constructing a row analysis model and coupling matrix, the precise quantification of the coupling mapping relationship of the row vectors of the characterization matrix in the three dimensions of the ternary array is achieved. By combining historical defect data to determine prior knowledge and reduce the dimensionality of the coupling matrix, the computational complexity is reduced while retaining the core features. The constraint weights are obtained through new feature vectors and coupled feature vectors. The row vectors are accurately screened by combining the relation array. Then, enhanced row vectors are obtained through feature enhancement and row gain is calculated. Finally, clustering is achieved through row gain similarity and defect type association analysis. The resulting defect combinations can accurately reflect the inherent correlation and coupling characteristics between defects, thus improving the scientificity and accuracy of gain analysis.

[0209] This invention provides a software defect testing method based on a large model, which maps the scenario matrix to the corresponding representation matrix and combines all defect combinations under the corresponding representation matrix to obtain the defect manifestation vector of the software under test, including:

[0210] Based on all defect combinations under the corresponding representation matrix, the row vector cluster center features and core constraint factors of each defect combination are extracted, wherein the core constraint factors are determined based on the row vector cluster center features.

[0211] Add association features that match the dimensions of the defect scene and the triplet of the representation matrix to each defect scene vector in the scene matrix to obtain a dimension-aligned scene matrix;

[0212] The core constraint factor of each defect combination is used as a weight factor, and combined with the mapping priority of each row vector in the corresponding representation matrix, the current weight is assigned to the corresponding defect combination. Among them, the mapping weight of the row vector corresponding to the defect combination with direct tendency type is higher than the mapping weight of the row vector corresponding to the defect combination with potential tendency type. The mapping weight of the row vector corresponding to the defect combination with high tendency generation condition threshold satisfaction is higher than the mapping weight of the row vector corresponding to the defect combination with low tendency generation condition threshold satisfaction. The mapping priority of the corresponding row vector is determined according to the mapping weight of tendency type and tendency generation condition threshold.

[0213] The scene features of the dimension-aligned scene matrix are mapped to the row vectors of the representation matrix to obtain the scene-representation association matrix. The scene-representation association matrix is ​​then fused and mapped with the current weight of the defect combination to obtain the intermediate defect performance matrix.

[0214] The intermediate defect representation matrix is ​​aggregated by row dimension according to the defect scenario dimension to obtain the defect representation vector of the software under test under the corresponding representation matrix.

[0215] Preferably, the associated features are the historical probability of the defect scenario triggering the corresponding potential defect type and the matching degree between the impact range of the defect scenario and the potential impact range level of the representation matrix.

[0216] In this embodiment, the row vector cluster center feature refers to the core features possessed by the cluster center of the row vectors within the cluster corresponding to each defect combination, including defect features, triple array dimension features, etc. For example, if the cluster center of the row vectors within the cluster corresponding to a certain defect combination is [0.85, 0.12, 0.21, 0.0, interface type defect, L2, 3], the core features of this cluster center are: prominent interface type defect features, potential influence range level is L2, and the allowable extended influence threshold is 3.

[0217] Core constraint factors ,in, , These are the maximum and minimum values ​​of all row vectors within the cluster in the i1-th dimension, respectively. This represents the value of the i1th dimension corresponding to the cluster center feature of the row vector. Before calculation, all feature values ​​need to be normalized to 0 to 1.

[0218] The dimension-aligned scene matrix refers to the scene matrix obtained by supplementing each defect scene vector of the original scene matrix with associated features. For example, if the original defect scene vector is [1,0,0.9,0.1], after supplementing with associated features [0.95,0.88], a new vector [1,0,0.9,0.1,0.95,0.88] is obtained. All new vectors are combined to form the dimension-aligned scene matrix.

[0219] Mapping priority refers to the priority level of each row vector in the characterization matrix when it is mapped to the scene matrix. The priority is determined by the tendency type of the defect combination and the satisfaction of the threshold of the tendency generation condition. The higher the priority of the row vector, the higher its proportion in the mapping.

[0220] In this embodiment, a basic priority weight is set according to the tendency type of the defect combination, with a direct tendency type set to 1.2 and a potential tendency type set to 0.8; the threshold satisfaction of the tendency generation condition for each defect combination is calculated, and the satisfaction is converted into a threshold weight of 0.9-1.1, with a higher satisfaction and a larger threshold weight; the basic priority weight is multiplied by the threshold weight to obtain the mapping priority weight of the row vector; the core constraint factor of each defect combination is multiplied by the corresponding mapping priority weight to obtain the current weight of the defect combination.

[0221] In this embodiment, the scene-representation correlation matrix refers to the matrix obtained by calculating the correlation degree between the scene features of the dimension-aligned scene matrix and the row vectors of the representation matrix. The elements of the matrix are the correlation degree values ​​between the scene features and the row vectors, quantifying the degree of correlation between the defective scene and the defective representation. For example, an element of 0.92 in the scene-representation correlation matrix indicates that the correlation degree between the corresponding defective scene and the defective representation is 92%.

[0222] In this embodiment, a cosine similarity algorithm is used to calculate the element correlation between the dimension-aligned scene matrix and the representation matrix to construct a scene-representation correlation matrix. The scene-representation correlation matrix is ​​then weighted and fused with the current weights of the defect combinations, i.e., each element of the correlation matrix is ​​multiplied by the current weight of the corresponding defect combination to obtain an intermediate defect representation matrix. A feature aggregation algorithm is then used to aggregate the intermediate defect representation matrix by row dimension according to the defect scene dimension. The feature information of the same defect scene is then normalized and fused to obtain a single feature vector corresponding to the defect scene, which is regarded as the defect representation vector.

[0223] In this embodiment, the historical probability of a defect scenario triggering a corresponding potential defect type refers to the proportion of the number of times a certain defect scenario actually triggers a corresponding potential defect type in historical test and operation data to the total number of times the defect scenario occurs.

[0224] The degree of matching between the impact range of the defect scenario and the potential impact range level in the characterization matrix = 1 - the absolute value of the difference between the quantified value of the actual impact range of the defect scenario and the quantified value of the potential impact range level in the characterization matrix / the quantified value of the potential impact range level in the characterization matrix.

[0225] The beneficial effects of the above technical solution are as follows: by extracting the cluster center features and core constraint factors of the row vectors of defect combinations, the precise quantification of defect combination features is achieved; the dimensional alignment processing of the scene matrix solves the problem that the scene matrix and the representation matrix cannot be directly mapped due to dimensional mismatch; the mapping priority is determined by combining the tendency type and the threshold satisfaction of the tendency generation condition, and the current weight is calculated, making the weight allocation of the mapping process more scientific; by obtaining the intermediate defect performance matrix through two mappings and generating the defect performance vector through row dimension aggregation, the deep integration of multi-dimensional information of defect scene, representation matrix, and defect combination is achieved, and the generated defect performance vector can comprehensively reflect the defect features of the software.

[0226] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A software defect testing method based on a large model, characterized in that, include: Step 1: Extract the test run status of the software under test in different test instances and input it into the large running model to obtain the defect feature vector of the software under test based on the corresponding test instance; Step 2: Perform potential characterization analysis on the corresponding defect feature vectors to obtain the potential defect types and the potential impact range level and allowable expansion impact threshold of the corresponding potential defect types. Then, classify all defect feature vectors according to the test type of the test instance to obtain the characterization matrix of the same type of defect feature vectors. In this matrix, the potential defect type, potential impact range level and allowable expansion impact threshold of each defect feature vector are used as a triple array and added to the corresponding defect feature vector. Step 3: Perform gain analysis on the characterization matrix to obtain several defect combinations corresponding to the characterization matrix; Step 4: Capture the post-test code of the source code of the software under test in different test instances, and determine the corresponding defect scenario set of the source code based on the code differences between the post-test code and the source code; Step 5: Construct a scenario matrix based on the defect scenario set corresponding to all test instances involved under the same representation matrix, and map the scenario matrix to the corresponding representation matrix. Combine all defect combinations under the corresponding representation matrix to obtain the defect performance vector of the software under test. Step 6: Locate defects in the software under test according to all defect manifestation vectors and provide defect repair suggestions. The defect repair suggestions are generated based on historical defect repair schemes mined by running a large model, combined with the specific features of the defect manifestation vectors.

2. The software defect testing method based on a large model according to claim 1, characterized in that, Before extracting the test run data of the software under test from different test instances, the following should be included: Based on the service business of the software under test, business scenario data, type scenario data, and tool scenario data are retrieved from the business database. The business scenario data refers to the data in the business database associated with the service business and the execution logic of the execution code layer that the service business depends on, and the execution code layer contains several individual business execution code segments. The type scenario data refers to the execution type data corresponding to the individual business execution code segments that generate abnormal factors in the layer logs generated by the execution code layer. The tool scenario data refers to the working status data of the log capture tool associated with each log generation time in relation to the layer logs. Information is extracted from the business scenario data to obtain several individual business execution code segments and logical extension code segments for each individual business. The individual business execution code segments and logical extension code segments are encoded to obtain corresponding first codes and second codes. The first codes and second codes under the same individual business execution code segment are combined and retained. Each first code is combined with each remaining second code except for the one that matches it. Ambiguity processing is performed on each code combination. If the ambiguity coefficient is greater than a preset coefficient, the corresponding code combination is removed; otherwise, the corresponding code combination is retained. Retrieve the instance to be analyzed that matches each coding combination from the combination-instance database; Each coding combination of individual business execution code segments involved at adjacent log generation times is determined. Combined with the tool dependency relationship of adjacent log generation times determined by the tool working tree constructed based on the tool scenario data and the radiation relationship of the log capture tool at adjacent log generation times to the individual business execution code segments involved at adjacent log generation times, an instance correction template for the corresponding coding combination is obtained. Several instance filling templates related to the type of scenario data are determined, and a first template is obtained by uniquely retrieving from the several instance filling templates according to the execution type corresponding to each encoding combination; The test instance is obtained by modifying and filling the corresponding instance to be analyzed according to the example correction template and the first template.

3. The software defect testing method based on a large model according to claim 2, characterized in that, According to the example correction template and the first template, the corresponding example to be analyzed is corrected and filled to obtain the test example, including: According to the example correction template and the first template, the corresponding instance to be analyzed is initially corrected and filled to obtain the initial instance; Real-time collection of business traffic data, code execution frequency data, and abnormal alarm data of the software under test within the current business cycle, to construct a real-time business status feature set; The real-time business status feature set is input into a preset template optimization model to obtain the first adjustment parameter of the instance correction template and the second adjustment parameter of the first template. The template optimization model is a neural network model trained by running a large model to adjust the template parameters according to the real-time business status. Based on the first adjustment parameter, the correction rules of the instance correction template are updated in layers. At the same time, based on the second adjustment parameter, the filling rules of the first template are updated precisely. The corresponding initial instance is optimized based on the updated instance correction template and the updated first template to obtain the test instance.

4. The software defect testing method based on a large model according to claim 1, characterized in that, Obtain the potential defect types and, based on each potential defect type, the potential impact range level and the allowable expanded impact threshold, including: The defect feature vectors are quantified by their feature importance, global contribution, and historical correlation, and each defect feature vector is converted into a corresponding potential representation vector. Calculate the cosine similarity between any two potential representation vectors. If the similarity is greater than the preset clustering threshold, the two vectors are grouped into the same cluster. Each cluster corresponds to a potential defect type, and all potential representation vectors within the cluster form the defect representation set for that potential defect type. Extract the impact keywords from the business impact information corresponding to each potential defect type, wherein the impact keywords are related to the business module identifier, function failure description, data anomaly type and user impact scope description; The maximum coverage matching strategy is used to match the influencing keywords with the preset influence range rule base, wherein each rule in the preset influence range rule base corresponds to an influence level and a corresponding allowable extended influence threshold. If the affected keyword only hits one rule, the impact level of the corresponding rule will be determined as the potential impact range level of the corresponding potential defect type; If at least two rules affect the keyword hit, the highest impact level among the hit rules will be determined as the potential impact range level of the corresponding potential defect type. Obtain the impact time series corresponding to the corresponding potential defect type, and take the mean of the impact time series and the corresponding standard impact time series to obtain the actual impact mean and the standard impact mean; Based on the influence weight of the corresponding potential defect type in the business system, and multiplied by the actual influence mean and the standard influence mean respectively, we obtain the weighted actual influence mean and the weighted standard influence mean. Calculate the absolute value of the difference between the weighted actual impact mean and the weighted standard impact mean; If the absolute value of the difference is greater than the preset impact threshold, then the allowable expansion impact threshold of the corresponding potential defect type is determined as the maximum allowable expansion threshold of the corresponding impact level in the impact range rule base; Otherwise, the allowed expansion threshold will be determined as the minimum allowed expansion threshold for the corresponding impact level.

5. The software defect testing method based on a large model according to claim 1, characterized in that, Gain analysis is performed on the characterization matrix to obtain the defect combination corresponding to the characterization matrix, including: For each row of the characterization matrix consisting of a defect feature vector and a triple array, a row analysis model of the corresponding characterization matrix is ​​constructed. The coupling mapping relationship between each row vector in the characterization matrix in the dimensions of potential defect type, potential impact range level, and allowable extended impact threshold is quantified to construct a coupling matrix, and the coupling matrix is ​​applied to the row analysis model. Based on the statistical regularity of historical defect characterization data under the same test type, the prior knowledge of the corresponding characterization matrix is ​​determined, and the coupling matrix is ​​dimensionality reduced to obtain a new matrix. The prior knowledge includes mean, variance and covariance constraints based on three dimensions: potential defect type, potential impact range level and allowable extended impact threshold. Obtain the new eigenvector of the new matrix and the coupling eigenvector of the coupling matrix, and based on the new eigenvector and the coupling eigenvector, obtain the constraint weight of each dimension in the ternary array; Determine the association relationship of each row vector in the representation matrix based on the remaining row vectors in each dimension of the ternary array to obtain a relation array, wherein the association relationship includes: linear association, non-linear association and no association; When the associated array meets the standard analysis criteria, the corresponding row vector is retained; otherwise, the corresponding row vector is removed. The retained row vectors are enhanced according to the constraint weights to obtain enhanced row vectors, and the row gain of the enhanced row vectors on the defect features is determined. Cluster analysis is performed on all retained row vectors. Row vectors with row gain similarity higher than a preset threshold and potential defect type correlation are grouped into the same cluster, and each cluster corresponds to a set of defect combinations.

6. The software defect testing method based on a large model according to claim 5, characterized in that, The defect combination includes the defect tendency, tendency type, and tendency generation conditions determined by the potential impact range level and the allowable extended impact threshold corresponding to the row vectors within the cluster.

7. The software defect testing method based on a large model according to claim 1, characterized in that, The scene matrix is ​​mapped to the corresponding representation matrix, and all defect combinations under the corresponding representation matrix are combined to obtain the defect performance vector of the software under test, including: Based on all defect combinations under the corresponding representation matrix, the row vector cluster center features and core constraint factors of each defect combination are extracted, wherein the core constraint factors are determined based on the row vector cluster center features. Add association features that match the dimensions of the defect scene and the triplet of the representation matrix to each defect scene vector in the scene matrix to obtain a dimension-aligned scene matrix; The core constraint factor of each defect combination is used as a weight factor, and combined with the mapping priority of each row vector in the corresponding representation matrix, the current weight is assigned to the corresponding defect combination. Among them, the mapping weight of the row vector corresponding to the defect combination with direct tendency type is higher than the mapping weight of the row vector corresponding to the defect combination with potential tendency type. The mapping weight of the row vector corresponding to the defect combination with high tendency generation condition threshold satisfaction is higher than the mapping weight of the row vector corresponding to the defect combination with low tendency generation condition threshold satisfaction. The mapping priority of the corresponding row vector is determined according to the mapping weight of tendency type and tendency generation condition threshold. The scene features of the dimension-aligned scene matrix are mapped to the row vectors of the representation matrix to obtain the scene-representation association matrix. The scene-representation association matrix is ​​then fused and mapped with the current weight of the defect combination to obtain the intermediate defect performance matrix. The intermediate defect representation matrix is ​​aggregated by row dimension according to the defect scenario dimension to obtain the defect representation vector of the software under test under the corresponding representation matrix.

8. The software defect testing method based on a large model according to claim 7, characterized in that, The associated features are the historical probability of a defect scenario triggering a corresponding potential defect type, and the degree of matching between the impact range of the defect scenario and the potential impact range level of the representation matrix.

Images