Software efficient testing method and system based on artificial intelligence

Abstract

The invention discloses an efficient software testing method and system based on artificial intelligence. The method comprises the steps that multi-modal feature data such as static codes and dynamic running tracks of to-be-tested software in multiple running scenes are collected and structurally packaged; constructing a multi-modal feature fusion model, and mining association between modals to generate a fusion feature vector; generating an initial test case set in combination with the fusion feature vector based on a model-Based test framework; a multi-objective decision algorithm is introduced, and test cases are optimized and screened according to parameters such as test coverage; executing the optimized test case, collecting data and identifying exceptions and defects; and positioning defect positions and influence ranges in combination with the fusion feature vectors. The system comprises six units such as a multi-modal feature data acquisition and packaging unit and a multi-modal feature fusion processing unit which are connected in sequence. According to the method and the system, the test efficiency and accuracy are improved through multi-modal feature deep fusion, test case optimization and step refinement.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software testing, in particular to a software efficient testing method and system based on artificial intelligence. BACKGROUND

[0002] With the continuous rise of software system complexity, multi-modal feature interaction becomes more frequent, and traditional testing methods are difficult to achieve efficient fusion and accurate analysis when dealing with static code, dynamic running track, user interaction behavior and system resource occupation and other multi-dimensional features. Although the model-based testing framework has certain advantages in test case generation, it has limitations in multi-modal feature correlation mining and dynamic optimization of the testing process, making it difficult to balance test coverage and execution efficiency. Therefore, it is necessary to combine artificial intelligence technology to build a new testing method and system to adapt to the testing needs of complex software.

[0003] The prior art has obvious deficiencies in multi-modal feature processing. The feature fusion process does not fully consider the potential correlation between different modal features, and only integrates the features through simple splicing or weighting, which cannot effectively capture the deep interaction between features, making it difficult for the fused feature vector to accurately reflect the real running state of the software. At the same time, in the test case optimization and screening link, the existing technology relies on a single evaluation index and does not comprehensively consider parameters such as test coverage, execution cost and defect discovery ability, making the optimized test case set either redundant or insufficient in coverage, which cannot guarantee the integrity of the test while improving the test efficiency. SUMMARY

[0004] In order to overcome the shortcomings and deficiencies of the prior art, the present application provides a software efficient testing method and system based on artificial intelligence.

[0005] The technical solution adopted by the present application is a software efficient testing method based on artificial intelligence, comprising the following steps:

[0006] S1: Collecting multi-modal feature data generated by the software to be tested under multiple running scenarios, the multi-modal feature data including static code features, dynamic running track features, user interaction behavior features and system resource occupation features, and structuring and packaging various types of feature data to form a feature data set;

[0007] S2: Building a multi-modal feature fusion model, inputting the feature data set formed in S1 into the model, converting different modal feature data to a unified feature space through a feature mapping mechanism, using an inter-modal correlation analysis algorithm to mine the potential correlation between different modal feature data, and generating a fused feature vector;

[0008] S3: Based on the model-based test framework, the fusion feature vector generated in S2 is input to construct a test case generation model. The model generates an initial test case set according to the logical constraint relationship contained in the software requirement specification, combined with the software running state information carried in the fusion feature vector;

[0009] S4: The initial test case set generated in S3 is optimized and screened. The test coverage evaluation index and the test case execution cost parameter are introduced. The priority of each test case in the initial test case set is sorted by a multi-objective decision algorithm. Redundant test cases are removed to obtain an optimized test case set.

[0010]

[0011] S6: According to the abnormal behavior and potential defects identified in S5, defect feature information is extracted, combined with the fusion feature vector output by the multi-modal feature fusion model, and a defect positioning model is constructed to determine the specific location and impact range of the defect in the software code.

[0012] Further, in S2, the multi-modal feature fusion model realizes feature fusion in the following way: a weighted fusion mechanism is used to fuse different modal feature data. A modal weight coefficient is introduced in the fusion process. The coefficient is determined by a modal feature contribution degree evaluation algorithm based on the discriminant ability and stability parameters of the feature data. The feature fusion formula is constructed as follows:

[0013]

[0014] where F represents the fusion feature vector, w i represents the weight coefficient of the i-th modal feature, f i represents the feature vector after mapping of the i-th modal feature, represents the reliability parameter of the i-th modal feature, and n represents the number of modal features.

[0015] In S3, when the test case generation model generates the initial test case set, the calling relationship of the software function module and the state information in the fusion feature vector are combined to generate test cases that meet the requirements of the requirements through logical reasoning rules. The triggering condition of the logical reasoning rule is associated with the threshold range of the feature value in the fusion feature vector.

[0016] ​Further, in S4, when the initial test case set is optimized and screened, the execution path complexity parameter and the potential defect discovery probability parameter of the test case are introduced, and the optimized screening is realized by constructing a test case optimization model; the calculation formula of the test case optimization model is as follows:

[0017] C j = α·P j + β·Q j / R j

[0018] Wherein, C j represents the comprehensive evaluation value of the jth test case, P j represents the test coverage of the jth test case, Q j represents the probability of the jth test case discovering potential defects, R j represents the execution cost of the jth test case, and α and β represent weight coefficients, and α+β=1;

[0019] In the optimization and screening process, the test cases are sorted according to the comprehensive evaluation value, and the test cases with higher comprehensive evaluation value are selected to form the optimized test case set, while the representative test cases under different execution paths are retained.

[0020] Further, in S5, the anomaly detection algorithm realizes the identification of the abnormal behavior of the software by constructing an anomaly degree evaluation model, which takes the response data and internal state parameters collected during the test process as input to calculate the anomaly degree value of the software running state; the calculation formula of the anomaly degree evaluation model is as follows:

[0021]

[0022] Wherein, A represents the anomaly degree value, s k represents the actual value of the internal state parameter of the software at the kth collection time, represents the predicted value of the internal state parameter of the software at the kth collection time, and m represents the number of collection times. δ k represents the deviation coefficient of the software output response data at the kth collection time, and γ represents the weight parameter.

[0023] By comparing the calculated anomaly degree value with the preset anomaly threshold value, when the anomaly degree value exceeds the threshold value, it is determined that the software has abnormal behavior.

[0024] Further, in S6, in the defect positioning model construction process, the calling frequency parameter and the defect propagation probability parameter of the code module are introduced by combining the defect feature information and the fusion feature vector, and the probability of each code module having defects is calculated by the Bayesian network algorithm; the defect probability calculation model is constructed as follows:

[0025]

[0026] wherein, P(d m |f) represents the posterior probability of the mth code module having defects under the fusion feature vector f, P(f m |d m ) represents the likelihood probability of generating the fusion feature vector f when the mth code module has defects, P(d m ) represents the prior probability of the mth code module having defects, and M represents the total number of software code modules.

[0027] Further, in S2, the multi-modal feature fusion model adopts a nonlinear mapping function to convert each modal feature data when performing feature mapping, and the nonlinear mapping function is determined based on the distribution characteristics of the feature data and the software test target parameters; the feature mapping function is constructed as follows:

[0028] f′ i = tanh(a i ·f i +b i )·c i

[0029] wherein, f′ i represents the mapped feature value of the ith modal feature, f i represents the original feature value of the ith modal feature, a i and b i represent the coefficient parameters of the mapping function, c i represents the scaling factor of the ith modal feature, and tanh represents the hyperbolic tangent function.

[0030] In S3, the test case generation model generates the initial test case set, introduces the precondition dependency parameters and the post-result constraint parameters of the test case, describes the state change process of the software under different test case executions through a state transition graph, and generates test cases including various state transition paths of the software.

[0031] Further, in S3, the test case generation model includes the following steps:

[0032] S31: Analyzing the software requirement specification document, extracting the functional requirement items and non-functional requirement items included therein, converting the functional requirement items into quantifiable logical expressions, converting the non-functional requirement items into corresponding constraint parameters, and forming a requirement analysis result;

[0033] S32: Based on the demand analysis result formed in S31, the input parameter range and output result determination standard of the test case generation are determined in combination with the fusion feature vector generated in S2, the input parameter range is determined according to the distribution interval of the feature value in the fusion feature vector, and the output result determination standard is set according to the constraint parameter in the demand analysis result;

[0034] S33: The input parameter range and output result determination standard determined in S32 are integrated into the state transition rule of the state machine in the model-based test framework, and the test cases capable of triggering the state transition of each state are generated by traversing all the reachable states of the state machine, thereby forming an initial test case set.

[0035] Further, in S4, the optimization and screening of the initial test case set includes the following steps:

[0036] S41: The test coverage of each test case in the initial test case set is calculated, the test coverage is determined by calculating the ratio of the included number to the total number of software code statements, branches and conditions, and the execution cost of each test case is calculated, including execution time, system resource occupation amount and data processing amount parameters;

[0037] S42: The similarity parameter between test cases is introduced, the feature vector similarity of any two test cases is calculated through the feature hash algorithm, and when the similarity exceeds the preset threshold, it is marked as a similar test case group, which provides a basis for subsequent redundant test case elimination;

[0038] S43: Based on the test coverage, execution cost calculated in S41 and the similar test case group marked in S42, a multi-objective optimization algorithm is used to optimize the initial test case set, and under the premise of ensuring that the test coverage is not lower than the preset standard, the test cases with low execution cost and representative in the similar test case group are preferentially retained;

[0039] S44: The test case set processed by S43 is subjected to secondary verification, the test coverage and execution cost are recalculated, the optimized test case set meets the efficiency and effect requirements of software testing, and the final optimized test case set is formed.

[0040] Further, in S5, the abnormal behavior and potential defects occurring in the software running process include the following steps:

[0041] S51: In the test case execution process, the response data output by the software is collected in real time through the sensor and data collection interface, the response data includes function output result, error prompt information and state return code, and the software internal state parameters are collected, including memory occupation rate, CPU usage, inter-process communication data and variable value change trajectory;

[0042] S52: The response data collected in S51 and the internal state parameters are time-aligned, the same time generated data of various types are associated and integrated according to the time stamp, forming a time sequence data sequence, and the data has consistency in the time dimension;

[0043] S53: The time sequence data sequence formed in S52 is input to an anomaly detection algorithm, which compares the time sequence data sequence with the baseline data sequence under the normal operation state, calculates the deviation degree between the two, and when the deviation degree exceeds the set threshold, marks the software operation state in the corresponding time period as abnormal;

[0044] S54: The response data corresponding to the marked abnormal operation state and the internal state parameters are analyzed in depth, the abnormal feature information is extracted, the logical structure of the software code is combined, and the manifestation of the abnormal behavior and the potential defect type that may be caused are determined.

[0045] An efficient software testing system based on artificial intelligence, comprising:

[0046] A multi-modal feature data acquisition and packaging unit is used to acquire multi-modal feature data of the software to be tested under multiple running scenarios and to structure and package the data. The output end of the unit is connected to the input end of the multi-modal feature fusion processing unit.

[0047] A multi-modal feature fusion processing unit is used to receive the feature data set output by the multi-modal feature data acquisition and packaging unit, and generate a fusion feature vector through a multi-modal feature fusion model. The output end of the unit is connected to the input end of the test case generation unit.

[0048] A test case generation unit based on a model-Based testing framework receives the fusion feature vector output by the multi-modal feature fusion processing unit, generates an initial test case set, and the output end of the unit is connected to the input end of the test case optimization and screening unit.

[0049] A test case optimization and screening unit receives the initial test case set output by the test case generation unit, optimizes and screens it through a multi-objective decision algorithm, and obtains an optimized test case set. The output end of the unit is connected to the input end of the test execution and data acquisition unit.

[0050] A test execution and data acquisition unit receives the optimized test case set output by the test case optimization and screening unit, executes it on the software to be tested and collects related data. The output end of the unit is connected to the input end of the abnormal behavior and defect identification unit.

[0051] A defect positioning and analyzing unit receives data output by the test execution and data collecting unit, combines the fusion feature vector output by the multi-modal feature fusion processing unit, and determines the defect position and influence range, and the unit is the final output unit of the system.

[0052] Beneficial effects: the present application proposes a software efficient test method and system based on artificial intelligence, through constructing a multi-modal feature fusion model, deeply fusing multi-modal feature data such as static code and dynamic running track, mining potential correlation between modes, and generating a fusion feature vector that can accurately reflect the running state of software, overcoming the problem of loss of associated information caused by simple splicing of multi-modal features in the prior art. Combined with the model-Based test framework to generate an initial test case set, and introducing a multi-objective decision algorithm, the test case is optimized and screened by comprehensively considering parameters such as test coverage and execution cost, solving the defects of test case redundancy or insufficient coverage caused by single evaluation index. Through the step-by-step refinement of the test case generation, optimization and abnormal identification process, the system formed by the orderly connection of each unit realizes the balance of test coverage and efficiency, improves the accuracy of defect positioning and the systematicness of the test process, and effectively adapts to the test requirements of complex software. BRIEF DESCRIPTION OF DRAWINGS

[0053] Figure 1 The method flowchart of the present application is shown in the figure.

[0054] Figure 2 The system unit composition diagram of the present application is shown in the figure. DETAILED DESCRIPTION

[0055] It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict, and the present application will be further described in detail below in combination with the drawings and specific embodiments.

[0056] As shown in the figure, a software efficient test method based on artificial intelligence comprises the following steps: Figure 1

[0057] S1: collect multi-modal feature data generated by the software to be tested under multiple running scenarios, the multi-modal feature data includes static code features, dynamic running track features, user interaction behavior features and system resource occupation features, structure and package various types of feature data to form a feature data set;

[0058] ​Specifically, the static code features collected by S1 include code line number, function nesting depth (range generally 1-8 layers), number of loop statements and other parameters, which are directly related to the modularization degree and maintainability of the software; the dynamic running track features include process response delay (unit: milliseconds, generally in the range of 10-500 ms), data cache hit rate (percentage, generally in the range of 60%-95%) and other parameters, which reflect the real-time performance of the software during running; the user interaction behavior features involve operation interval length (unit: seconds, common range 0.5-30 s), input field filling completeness (percentage) and other parameters, which embody the matching degree of user operation and software response; the system resource occupation features include memory leakage amount (unit: bytes, generally controlled in the range of 0-10240 bytes), network bandwidth occupation (unit: Mbps, range 1-100 Mbps) and other parameters, which measure the consumption intensity of system resources by the software. This step provides comprehensive raw data for subsequent feature fusion and is the basis for ensuring test accuracy.

[0059] In implementation, the running scenarios of the software to be tested are first defined, including single-user low-load scenario, 50-200 concurrent user medium-load scenario and more than 200 concurrent user high-load scenario. In each scenario, the code static analysis tool is used to scan the code and extract the module features with function nesting depth of 3 layers or more; the running log is used to record the dynamic track of process response delay in the range of 50-200 ms; the user behavior tracking tool is used to collect the interactive data with operation interval length of 1-10 s; and the resource monitoring software is used to obtain the resource occupation data with memory leakage amount in the range of 512-2048 bytes. The collected data is encapsulated in a structured format with field length of 256 bytes, and metadata such as scenario number (1-3), collection timestamp (accurate to seconds), feature type code (1-4) is added to form a feature data set, wherein each data entry contains 16 feature fields.

[0060] S2: Construct a multi-modal feature fusion model, input the feature data set formed in S1 into the model, convert different modal feature data to a unified feature space through a feature mapping mechanism, mine the potential correlation between different modal feature data using an inter-modal correlation analysis algorithm, and generate a fusion feature vector;

[0061] Specifically, the multi-modal feature fusion model of S2 involves parameters such as feature mapping dimension (value range 200-1000 dimensions), modal correlation strength threshold (value 0.3-0.8), fusion weight coefficient (sum is 1, and the weight of each modal is in the range of 0.1-0.4) and other parameters. Through these parameter settings, the effective integration of different modal features is realized, the problem of one-sidedness of single modal feature information is solved, and the fusion feature vector can more comprehensively reflect the software state, providing a high-dimensional and high-correlation feature basis for subsequent test case generation, which directly affects the pertinence and coverage range of test cases.

[0062] In the implementation process, the feature data set of S1 is input into the fusion model, the model first classifies the data by modal, and identifies four types of features such as static code and dynamic trajectory. The feature mapping dimension is set to 500 dimensions, and each type of feature is mapped to this dimension space through linear transformation. The correlation strength between modes is calculated, and when the correlation strength between static code features and dynamic running trajectory features reaches 0.5 or above, the collaborative fusion mechanism is started. Assign fusion weights, static code feature weight 0.25, dynamic running trajectory feature 0.3, user interaction behavior feature 0.2, system resource occupation feature 0.25, complete feature fusion by weighted sum, generate a fusion vector containing 500 feature values, and control the value range of each feature value to 0-1000.

[0063] S3: Based on the model-Based test framework, the fusion feature vector generated by S2 is input, and a test case generation model is constructed. The model generates an initial test case set according to the logical constraint relationship contained in the software requirement specification, combined with the software running state information carried in the fusion feature vector;

[0064] Specifically, the test case generation model of S3 involves requirement coverage threshold (usually set to 80%-100%), state transition trigger probability (percentage, range 30%-70%), input parameter dispersion (value 0-1, the larger the value, the more scattered the distribution) and other parameters. These parameters ensure that the generated test cases can cover core functional requirements and touch edge scenarios, and through the logical reasoning mechanism of the model-Based framework, the test case generation process has traceability, avoiding the problem of repeated or missing test cases in traditional methods, and directly improving the integrity of the test.

[0065] In the implementation, the 500-dimensional fusion feature vector generated by S2 is input into the model, the model analyzes the requirement document, and converts the function points into a quantitative index with a coverage threshold of 90%. According to the feature value distribution in the fusion vector, set the state transition trigger condition, when the feature value corresponding to the dynamic running trajectory feature is in the interval of 600-800, the state transition probability is 60%. Determine the input parameter value range, such as setting the user operation frequency parameter to 1-5 times / minute, and setting the system resource occupation parameter to 20%-70%. According to the conversion rule of the state machine model, an initial set containing 100-300 test cases is generated, each case contains 5-8 input parameters, the parameter value interval is 5% gradient, and the execution step number is controlled in 3-8 steps.

[0066] S4: Optimize and screen the initial test case set generated by S3, introduce test coverage evaluation index and test case execution cost parameters, prioritize each test case in the initial test case set through multi-objective decision algorithm, eliminate redundant test cases, and get the optimized test case set;

[0067] Specifically, the test coverage evaluation parameters of S4 include the statement coverage ratio (target value ≥ 90%), branch coverage ratio (target value ≥ 85%), condition coverage ratio (target value ≥ 80%), etc.; the execution cost parameters involve single use case execution time (range 10-300 seconds), memory peak (range 512-4096 MB), data transmission volume (range 1-100 MB), etc. The step realizes accurate selection of test cases through multi-parameter comprehensive evaluation, compresses the total execution time by 30%-50% on the premise of ensuring that the coverage meets the standard, significantly improves the test efficiency, and reduces resource consumption.

[0068] In implementation, the coverage of each test case is calculated first, the ratio of the number of statement coverage to the total number of statements is counted, and it is required to reach more than 92%; the branch coverage ratio needs to exceed 86%; the condition coverage ratio is not less than 81%. At the same time, the execution time is recorded, and the use cases in the interval of 10-150 seconds are selected; the memory peak is controlled in the range of 1024-2048 MB; the data transmission volume is limited to 5-50 MB. A multi-objective decision algorithm is used, the weights of statement coverage, branch coverage, execution time, memory occupation and data transmission volume are set to 0.3, 0.25, 0.2, 0.15 and 0.1 respectively, the use cases are scored (full score 100 points), the use cases with scores above 70 points are retained, the use cases with scores below 50 points are eliminated, and the optimized test case set is formed, the number of which is controlled in the range of 40%-60% of the initial set.

[0069] S5: The optimized test case set obtained in S4 is executed on the software to be tested, the response data and internal state parameters output by the software during the test process are collected in real time, and the collected data are analyzed by an abnormality detection algorithm to identify abnormal behaviors and potential defects in the software running process;

[0070] Specifically, the abnormality detection of S5 involves parameters such as abnormal fluctuation threshold (value 5%-20%), feature extraction resolution (time granularity 1-10 seconds), state parameter sampling frequency (1-10 times / second). These parameters determine the sensitivity and timeliness of abnormality identification. Through high-frequency sampling and accurate threshold setting, small abnormal fluctuations (such as CPU utilization increasing by more than 10%) can be captured, ensuring that potential defects are found in the test phase, avoiding large-scale failures after the software goes online, and directly improving the software release quality.

[0071] In the implementation process, the optimized test case set is executed in order, the state parameter sampling frequency is set to 5 times per second, and the feature extraction time granularity is 2 seconds. During execution, response data is collected in real time, including function output check code (32-bit characters), error code (4-digit numbers), etc.; internal state parameters are collected synchronously, such as CPU utilization (sampling value retains 1 digit after the decimal point), memory fragmentation rate (percentage, accurate to 0.1%). The data is input into the anomaly detection algorithm, and the CPU utilization abnormal fluctuation threshold is set to 15%, and the memory fragmentation rate abnormal threshold is set to 8%. When the CPU utilization fluctuation of 3 consecutive sampling points exceeds 15% or the memory fragmentation rate reaches 8% or more, it is marked as abnormal behavior, and the 32-bit check code, 4-bit error code and corresponding state parameter values at the time of abnormal occurrence are extracted.

[0072] S6: According to the abnormal behavior and potential defects identified in S5, defect feature information is extracted, combined with the fusion feature vector output by the multi-modal feature fusion model, a defect positioning model is constructed, and the specific location and impact range of the defect in the software code are determined through the model.

[0073] Specifically, the defect positioning model of S6 involves module correlation coefficient (value 0-1, the larger the value, the closer the correlation), defect propagation distance (unit: code lines, range 10-500 lines), feature matching error (value 0-0.2) and other parameters. These parameters determine the accuracy and range of defect positioning. Through high correlation module screening and short distance propagation analysis, the defect positioning error can be controlled within 50 lines of code, significantly reducing the time for developers to troubleshoot defects, improving repair efficiency, and clearly defining the impact range of defects to provide a basis for priority sorting.

[0074] In implementation, the defect feature information identified by S5 and the fusion feature vector of S2 are input into the positioning model, the model first calculates the correlation coefficient of each code module (retaining 2 digits after the decimal point), and filters out the module group with a correlation coefficient of 0.6 or more. According to the matching result of defect features and fusion vectors (matching error controlled within 0.1), the initial suspicious module is locked. Analyze the code logic of the module, combined with the state parameters at the time of abnormal occurrence (such as memory address 0x00000000-0xFFFFFFFF), to locate the specific code line (error not more than 30 lines). According to the module correlation coefficient and the defect type, the defect propagation distance (value 100-300 lines) is calculated to determine the affected code range, including directly related modules (3-5) and indirectly related modules (2-4), forming a defect positioning report.

[0075] Preferably, in S2, the multi-modal feature fusion model realizes feature fusion in the following way: different modal feature data are fused by using a weighted fusion mechanism, a modal weight coefficient is introduced in the fusion process, the coefficient is determined by a modal feature contribution degree evaluation algorithm, the modal feature contribution degree evaluation algorithm is calculated based on the discriminative ability and stability parameters of the feature data; a feature fusion formula is constructed as follows:

[0076]

[0077] Wherein, F represents a fusion feature vector, w i represents the weight coefficient of the i-th modal feature, f i represents the feature vector after mapping of the i-th modal feature, represents the reliability parameter of the i-th modal feature, and n represents the number of modal feature types.

[0078] In S3, when the test case generation model generates an initial test case set, the calling relationship of the software function module and the state information in the fusion feature vector are combined to generate test cases that meet the requirements, including requirements, through logical reasoning rules, wherein the trigger condition of the logical reasoning rule is associated with the threshold range of the feature value in the fusion feature vector.

[0079] Specifically, in S2, the modal weight coefficient is determined by the modal feature contribution degree evaluation algorithm, which calculates the discriminative ability (value 0-1, the larger the value, the stronger the discriminative ability) and the stability parameter (fluctuation range 1%-10%) of the feature data, and the reliability parameter reflects the consistency (value 0.5-1.0) of the feature data in different scenarios. When implementing, first evaluate the contribution degree of each modal feature, assign weights according to the evaluation results, and then generate a fusion feature vector through weighted fusion to make the fusion result more suitable for software testing requirements. In S3, the trigger condition of the logical reasoning rule is associated with the threshold range of the feature value in the fusion feature vector, when the feature value is in a certain interval, the rule is activated, and the corresponding test case is generated. In this way, the test case generation is closely combined with the actual state of the feature data, the matching degree of the test case and the actual running scenario of the software is improved, and it is ensured that the generated test case can effectively cover the performance of the software under different feature states.

[0080] Preferably, in S4, when the initial test case set is optimized and screened, the execution path complexity parameter and the potential defect discovery probability parameter of the test case are introduced, and the optimization and screening are realized by constructing a test case optimization model; the calculation formula of the test case optimization model is as follows:

[0081] C j = α·P j + β·Q j / R j

[0082] wherein C j represents the comprehensive evaluation value of the jth test case, P j represents the test coverage of the jth test case, Q j represents the probability of the jth test case discovering potential defects, R j represents the execution cost of the jth test case, and a and b represent weight coefficients, and a+b=1.

[0083] In the optimization screening process, the test cases are sorted according to the comprehensive evaluation value, and the test cases with higher comprehensive evaluation value are selected to form the optimized test case set, while the representative test cases under different execution paths are retained.

[0084] Specifically, the execution path complexity parameter (with a value of 1-10, the larger the value, the more complex the path) and the potential defect discovery probability parameter (with a value of 0-1) of the test case are introduced to construct a test case optimization model. Among them, the test coverage reflects the coverage degree (percentage) of the test case to the software function, the execution cost includes time, resource and other cost parameters (time unit is second, resource unit is MB), and the weight coefficient is adjusted according to the test target (a value is 0.4-0.6, b value is 0.4-0.6). When implemented, first calculate each parameter of each test case, substitute it into the model to calculate the comprehensive evaluation value, sort according to the evaluation value, retain the high evaluation value cases, and consider the representativeness of different execution paths. The test cases with high execution path complexity are preferentially retained, and the test cases with high potential defect discovery probability are given more weight. Through this multi-parameter comprehensive optimization, while reducing redundancy, it ensures that the optimized test case set can cover complex paths and high-risk areas, and improves the effectiveness of the test.

[0085] Preferably, in S5, the anomaly detection algorithm realizes the identification of the abnormal behavior of the software by constructing an anomaly degree evaluation model, which takes the response data and internal state parameters collected during the test process as input to calculate the anomaly degree value of the software running state. The calculation formula of the anomaly degree evaluation model is as follows:

[0086]

[0087] wherein A represents the anomaly degree value, s k represents the actual value of the internal state parameter of the software at the kth collection time, represents the predicted value of the internal state parameter of the software at the kth collection time, and m represents the number of collection times, and d k represents the deviation coefficient of the output response data of the software at the kth collection time, and g represents the weight parameter.

[0088] By comparing the calculated abnormality value with a preset abnormal threshold, when the abnormality value exceeds the threshold, it is determined that the software has abnormal behavior.

[0089] Specifically, an abnormality evaluation model is constructed to quantify the abnormality degree of the software running state. The deviation of the actual value of the internal state parameter from the predicted value (unit according to parameter type) reflects the degree of deviation of the state from the normal range, the deviation coefficient reflects the difference between the response data and the expected result (value 0-2), and the weight parameter is adjusted according to the abnormal type (γ value 0.3-0.7). In implementation, the actual state parameters and response data in the test process are first collected, the deviation from the predicted value and the deviation coefficient are calculated, and the abnormality value is obtained by substituting the model, and then compared with the preset threshold (value 0.5-1.5) to determine whether there is an abnormality. The sampling frequency is set to 5-10 times / s to ensure that abnormal changes can be captured in time. Through this quantitative evaluation method, the abnormality identification is more objective and accurate, which can effectively distinguish between normal fluctuations and real abnormal behavior, and improve the accuracy of defect identification.

[0090] Preferably, in S6, during the construction of the defect positioning model, the calling frequency parameter of the code module and the defect propagation probability parameter are introduced in combination with the defect feature information and the fusion feature vector, and the probability of each code module having a defect is calculated through a Bayesian network algorithm; The defect probability calculation model is constructed as follows:

[0091]

[0092] Wherein, P(d m |f) represents the posterior probability of the mth code module having a defect under the fusion feature vector f, P(f|d m ) represents the likelihood probability of generating the fusion feature vector f when the mth code module has a defect, P(d m ) represents the prior probability of the mth code module having a defect, and M represents the total number of software code modules.

[0093] Specifically, the calling frequency parameter (unit: times / minute) and the defect propagation probability parameter (value: 0-1) of the code module are introduced by combining the defect feature information with the fusion feature vector, and the probability of the existence of defects in each code module is calculated by the Bayesian network algorithm. Among them, the posterior probability reflects the possibility of the existence of defects in the module under a certain feature, the likelihood probability represents the probability of generating the corresponding feature when the module exists defects, the prior probability is determined based on historical defect data (value: 0-0.5), and the number of modules is determined according to the software size (usually 10-50). When implemented, the prior probability is first determined by collecting historical defect data, then the likelihood probability is calculated according to the current fusion feature vector, the posterior probability is obtained by substituting the model, and the suspicious module is determined according to the posterior probability sorting. At the same time, combined with the module calling frequency and the defect propagation probability, the range of the possible impact of the defect is determined, so that the defect positioning is more targeted, the module with high probability of existing defects can be quickly locked, and the troubleshooting time is reduced.

[0094] Preferably, in S2, when performing feature mapping, the multi-modal feature fusion model adopts a nonlinear mapping function to convert each modal feature data, and the nonlinear mapping function is determined based on the distribution characteristics of the feature data and the software test target parameter; the feature mapping function is constructed as follows:

[0095] f′ i =tanh(a i ·f i +b i )·c i

[0096] Wherein, f′ i represents the feature value of the i-th modal feature after mapping, f i represents the original feature value of the i-th modal feature, a i , b i represent the coefficient parameters of the mapping function, c i represents the scaling factor of the i-th modal feature, and tanh represents the hyperbolic tangent function.

[0097] In S3, when the test case generation model generates the initial test case set, the pre-condition dependency parameter and the post-result constraint parameter of the test case are introduced, the state transition graph is used to describe the state change process of the software under different test case executions, and the generated test case includes various state transition paths of the software.

[0098] Specifically, in S2, the nonlinear mapping function is determined based on the distribution characteristics (normal distribution, skew distribution, etc.) of the feature data and the software testing target parameters (coverage requirement, precision requirement, etc.), the coefficient parameters are adjusted according to the feature type (a_i takes the value of 0.1-1.0, b_i takes the value of -5-5), and the scaling factor is used to adjust the feature value range (c_i takes the value of 0.5-2.0). When implemented, first analyze the feature distribution characteristics, determine the mapping function parameters, and convert the features to the appropriate space through nonlinear mapping, so that the features can better reflect the focus of software testing. In S3, the precondition dependency parameter (value 0-1, the larger the value, the stronger the dependency) and the post-result constraint parameter (value range according to the result type) are introduced, the state transition graph is used to describe the software state change, and the test case is ensured to cover all types of state transition paths. The state transition graph contains nodes (representing states) and edges (representing transitions), and the number of nodes is set according to the software complexity (20-50). In this way, the test case can fully cover the state transition of the software, and the completeness of the test is improved.

[0099] Preferably, in S3, the test case generation model is constructed by the following steps:

[0100] S31: Analyze the software requirement specification document, extract the functional requirement items and non-functional requirement items included therein, convert the functional requirement items into quantifiable logical expressions, and convert the non-functional requirement items into corresponding constraint parameters to form a requirement analysis result;

[0101] S32: Based on the requirement analysis result formed in S31, combine the fusion feature vector generated in S2 to determine the input parameter range and output result determination standard of the test case generation, the input parameter range is determined according to the distribution interval of the feature value in the fusion feature vector, and the output result determination standard is set according to the constraint parameter in the requirement analysis result;

[0102] S33: Adopt the state machine model in the model-Based test framework, integrate the input parameter range and output result determination standard determined in S32 into the state transition rules of the state machine, generate test cases that can trigger state transitions by traversing all reachable states of the state machine, and form an initial test case set.

[0103] Preferably, in S4, the initial test case set is optimized and screened by the following steps:

[0104] S41: Calculate the test coverage of each test case in the initial test case set, the test coverage is determined by calculating the ratio of the number of test cases to the total number of software code statements, branches and conditions, and calculating the execution cost of each test case, which includes execution time, system resource occupation and data processing amount parameters;

[0105] S42: Introduce the similarity parameter between test cases, calculate the similarity of the feature vectors of any two test cases through the feature hashing algorithm, and when the similarity exceeds the preset threshold, mark as a similar test case group, which provides the basis for subsequent redundant test case elimination;

[0106] S43: Based on the test coverage calculated in S41, the execution cost and the similar test case group marked in S42, a multi-objective optimization algorithm is used to optimize the initial test case set. Under the premise of ensuring that the test coverage is not lower than the preset standard, the test cases with low execution cost and representative in the similar test case group are preferentially retained;

[0107] S44: The test case set processed by S43 is subjected to secondary verification, and the test coverage and execution cost are recalculated. The optimized test case set meets the efficiency and effectiveness requirements of software testing, forming the final optimized test case set.

[0108] Preferably, in S5, identifying abnormal behaviors and potential defects occurring during software running includes the following steps:

[0109] S51: During the execution of the test case, the response data output by the software is collected in real time through the sensor and the data acquisition interface. The response data includes functional output results, error prompt information, and state return codes. At the same time, internal state parameters of the software are collected, including memory occupancy, CPU usage, inter-process communication data, and variable value change trajectory;

[0110] S52: The response data and internal state parameters collected in S51 are subjected to time sequence alignment processing. According to the time stamp, the various data generated at the same time are associated and integrated to form a time sequence data sequence. The data has consistency in the time dimension;

[0111] S53: The time sequence data sequence formed in S52 is input into the abnormality detection algorithm. The algorithm compares the time sequence data sequence with the baseline data sequence under normal running state, calculates the deviation degree between the two, and when the deviation degree exceeds the set threshold, marks the software running state in the corresponding time period as abnormal;

[0112] S54: In-depth analysis is performed on the response data and internal state parameters corresponding to the abnormal running state marked, and abnormal feature information is extracted. Combined with the logical structure of the software code, the manifestation of the abnormal behavior and the possible types of potential defects caused are determined.

[0113] As shown in Figure 2 A software efficient testing system based on artificial intelligence, comprising:

[0114] A multi-modal feature data acquisition and packaging unit is configured to acquire multi-modal feature data of a software to be tested under multiple running scenarios and to perform structured packaging. An output end of the unit is connected to an input end of a multi-modal feature fusion processing unit.

[0115] The multi-modal feature fusion processing unit is configured to receive a feature data set output by the multi-modal feature data acquisition and packaging unit, generate a fusion feature vector through a multi-modal feature fusion model, and an output end of the unit is connected to an input end of a test case generation unit.

[0116] The test case generation unit is based on a model-based test framework, receives a fusion feature vector output by the multi-modal feature fusion processing unit, generates an initial test case set, and an output end of the unit is connected to an input end of a test case optimization and screening unit.

[0117] The test case optimization and screening unit receives an initial test case set output by the test case generation unit, performs optimization and screening through a multi-objective decision algorithm, and obtains an optimized test case set. An output end of the unit is connected to an input end of a test execution and data acquisition unit.

[0118] The test execution and data acquisition unit receives an optimized test case set output by the test case optimization and screening unit, executes and acquires relevant data on the software to be tested, and an output end of the unit is connected to an input end of an abnormal behavior and defect identification unit.

[0119] The defect positioning and analysis unit receives data output by the test execution and data acquisition unit, combines a fusion feature vector output by the multi-modal feature fusion processing unit, determines a defect position and an impact range, and the unit is the final output unit of the system.

[0120] An efficient software testing method and system based on artificial intelligence, by constructing a multi-modal feature fusion model, processing multi-modal feature data such as static code features and dynamic running trajectory features, and converting different modal features to a unified feature space through a feature mapping mechanism, the method and system mine potential correlation between modalities to generate a fusion feature vector. This process changes the simple splicing method of multi-modal features in the prior art, avoids the loss of correlation information, and makes the fusion feature more accurately reflect the software running state, thereby overcoming the shortcomings of insufficient multi-modal feature processing in the background technology.

[0121] In the test case generation and optimization aspect, in combination with the model-based test framework, the initial test case set is generated by taking the fusion feature vector as the input, and the test coverage, execution cost and other parameters are introduced, and the initial test case set is optimized and screened through the multi-objective decision algorithm. This method breaks the limitation of relying on a single evaluation index in the prior art, reduces the redundancy of test cases, ensures the coverage range, solves the problem of poor test case optimization in the background art, and improves the pertinence and effectiveness of the test.

[0122] At the same time, by refining the steps S3, S4 and S5 into multiple sub-steps, the test case generation, optimization screening and abnormality identification process are more organized and operable. The system formed by the orderly connection of the six complex units cooperates to realize the complete process connection from feature collection to defect positioning. This structured step design and system architecture enhance the systematicness and continuity of the test process, and further make up for the deficiencies of the prior art in the completeness and cooperativeness of the test process.

[0123] In the description of the present application, it should be noted that unless otherwise explicitly specified and limited, the terms "arrangement", "installation", "connection", "link", "fixation" should be understood broadly, for example, it can be fixed connection, or detachable connection, or integrally connected, it can be mechanical connection, or electrical connection, it can be directly connected, or indirectly connected through intermediate medium, it can be the communication inside two elements. For ordinary skilled in the art, the specific meaning of the above terms in the present application can be understood through specific circumstances.

[0124] Although the embodiments of the present application have been shown and described, it can be understood by those skilled in the art that various equivalent changes, modifications, replacements and variations of the embodiments can be made without departing from the principles and spirits of the present application, and the scope of the present application is defined by the appended claims and their equivalent scope.

Claims

1. A software efficient testing method based on artificial intelligence, characterized in that, The method comprises the following steps: S1: Collecting multi-modal feature data generated by the software to be tested under multiple running scenarios, the multi-modal feature data comprising static code features, dynamic running track features, user interaction behavior features and system resource occupation features, and structurally packaging various types of feature data to form a feature data set; S2: Constructing a multi-modal feature fusion model, inputting the feature data set formed in S1 into the model, converting different modal feature data to a unified feature space through a feature mapping mechanism, mining potential correlation between different modal feature data using an inter-modal correlation analysis algorithm, and generating a fusion feature vector; S3: Based on a model-based test framework, taking the fusion feature vector generated in S2 as input, constructing a test case generation model, and generating an initial test case set according to logical constraint relationships contained in the software requirement specification and combining software running state information carried in the fusion feature vector; S4: Optimizing and screening the initial test case set generated in S3, introducing a test coverage evaluation index and a test case execution cost parameter, prioritizing each test case in the initial test case set through a multi-objective decision algorithm, eliminating redundant test cases, and obtaining an optimized test case set; S5: Executing the optimized test case set obtained in S4 on the software to be tested, collecting response data and internal state parameters output by the software during the test in real time, analyzing the collected data through an anomaly detection algorithm, and identifying abnormal behaviors and potential defects occurring during software running; S6: Extracting defect feature information according to the abnormal behaviors and potential defects identified in S5, combining the fusion feature vector output by the multi-modal feature fusion model, constructing a defect positioning model, and determining the specific location and impact range of the defect in the software code through the model.

2. The method of claim 1, wherein, In S2, the multi-modal feature fusion model realizes feature fusion in the following way: a weighted fusion mechanism is used to fuse different modal feature data, a modal weight coefficient is introduced in the fusion process, the coefficient is determined through a modal feature contribution degree evaluation algorithm, and the modal feature contribution degree evaluation algorithm is calculated based on the discriminability and stability parameters of the feature data; the feature fusion formula is constructed as follows: wherein F represents a fusion feature vector, w i represents a weight coefficient of the i-th modality feature, f i represents a feature vector after mapping of the i-th modality feature, represents a reliability parameter of the i-th modality feature, and n represents a number of types of modality features. In S3, when the test case generation model generates the initial test case set, the calling relationship of the software function module and the state information in the fusion feature vector are combined, and the test case satisfying the requirement is generated through a logical reasoning rule, wherein the trigger condition of the logical reasoning rule is associated with the threshold range of the feature value in the fusion feature vector.

3. The method of claim 1, wherein, In S4, when the initial test case set is optimized and screened, the execution path complexity parameter and the potential defect discovery probability parameter of the test case are introduced, and optimization and screening are realized through the construction of a test case optimization model; the calculation formula of the test case optimization model is as follows: C j = a · P j + β · Q j / R j wherein C j represents the comprehensive evaluation value of the jth test case, P j represents the test coverage of the jth test case, Q j represents the probability of the jth test case discovering potential defects, R j represents the execution cost of the jth test case, and α and β represent weight coefficients, and α + β = 1. In the optimization and screening process, the test cases are sorted according to the comprehensive evaluation value, the test cases with higher comprehensive evaluation values are selected to form the optimized test case set, and representative test cases under different execution paths are retained.

4. The method of claim 1, wherein, In S5, the anomaly detection algorithm realizes the identification of the abnormal behavior of the software by constructing an anomaly degree evaluation model, which takes the response data and internal state parameters collected during the test as input to calculate the anomaly degree value of the software running state. The calculation formula of the anomaly degree evaluation model is as follows: wherein A represents the abnormality value, s k represents the actual value of the software internal state parameter at the kth collection time, represents the predicted value of the software internal state parameter at the kth collection time, m represents the number of collection times, and k represents the deviation coefficient of the software output response data at the kth collection time, and γ represents the weight parameter. By comparing the calculated anomaly degree value with the preset anomaly threshold, when the anomaly degree value exceeds the threshold, it is determined that the software has abnormal behavior.

5. The method of claim 1, wherein, In S6, in the defect positioning model construction process, the calling frequency parameter and the defect propagation probability parameter of the code module are introduced by combining the defect feature information and the fusion feature vector, and the probability of each code module having a defect is calculated by the Bayesian network algorithm. The defect probability calculation model is constructed as follows: where P(d m ) represents the posterior probability of the mth code module having a defect given the fusion feature vector f, P(f m ) represents the likelihood probability of the fusion feature vector f being generated given the mth code module has a defect, P(d m ) represents the prior probability of the mth code module having a defect, and M represents the total number of software code modules.

6. The method of claim 1, wherein, In S2, when the multi-modal feature fusion model performs feature mapping, a nonlinear mapping function is used to convert each modal feature data, and the nonlinear mapping function is determined based on the distribution characteristics of the feature data and the software test target parameters. The feature mapping function is constructed as follows: f′ i = tanh(a i · f i + b i ) · c i wherein f′ i represents the mapped feature value of the i-th modality feature, f i represents the original feature value of the i-th modality feature, a i , b i represents the coefficient parameter of the mapping function, c i represents the scaling factor of the i-th modality feature, and tanh represents the hyperbolic tangent function. In S3, when the test case generation model generates the initial test case set, the pre-condition dependency parameter and the post-result constraint parameter of the test case are introduced, the state transition graph is used to describe the state change process of the software under different test case executions, and the generated test case includes various state transition paths of the software.

7. The method of claim 1, wherein, In S3, the test case generation model is constructed in the following steps: S31: Analyze the software requirement specification document to extract the functional requirement items and non-functional requirement items, convert the functional requirement items into quantifiable logical expressions, and convert the non-functional requirement items into corresponding constraint parameters to form the requirement analysis result; S32: Based on the requirement analysis result formed in S31, combine the fusion feature vector generated in S2 to determine the input parameter range and output result determination standard of the test case generation, the input parameter range is determined according to the distribution interval of the feature value in the fusion feature vector, and the output result determination standard is set according to the constraint parameter in the requirement analysis result; S33: Use the state machine model in the model-based test framework to integrate the input parameter range and output result determination standard determined in S32 into the state transition rules of the state machine, generate test cases that can trigger state transitions by traversing all reachable states of the state machine, and form an initial test case set.

8. The method of claim 1, wherein, In S4, the optimization and selection of the initial test case set includes the following steps: S41: Calculate the test coverage of each test case in the initial test case set, which is determined by calculating the ratio of the number of included software code statements, branches, and conditions to the total number, and calculating the execution cost of each test case, which includes execution time, system resource occupation, and data processing amount parameters; S42: Introduce the similarity parameter between test cases, calculate the feature vector similarity of any two test cases by the feature hashing algorithm, and when the similarity exceeds the preset threshold, mark it as a similar test case group to provide a basis for subsequent redundant test case elimination; S43: Based on the test coverage calculated in S41, the execution cost and the similar test case group marked in S42, a multi-objective optimization algorithm is used to optimize the initial test case set. Under the premise of ensuring that the test coverage is not lower than the preset standard, the test cases with low execution cost and representative in the similar test case group are preferentially retained; S44: The test case set processed in S43 is subjected to secondary verification, and the test coverage and execution cost are recalculated. The optimized test case set meets the efficiency and effectiveness requirements of software testing, and forms the final optimized test case set.

9. The method of claim 1, wherein, In S5, identifying abnormal behaviors and potential defects occurring in the software running process includes the following steps: S51: During the execution of the test case, the response data output by the software is collected in real time through the sensor and the data acquisition interface. The response data includes functional output results, error prompt information and state return code. At the same time, the internal state parameters of the software are collected, including memory occupancy, CPU usage, inter-process communication data and variable value change trajectory; S52: The response data and internal state parameters collected in S51 are subjected to time sequence alignment processing. According to the time stamp, the various data generated at the same time are associated and integrated to form a time sequence data sequence. The data has consistency in the time dimension; S53: The time sequence data sequence formed in S52 is input into the abnormality detection algorithm. The algorithm compares the time sequence data sequence with the baseline data sequence under the normal running state, calculates the deviation degree between the two, and marks the software running state in the corresponding time period as abnormal when the deviation degree exceeds the set threshold; S54: The response data and internal state parameters corresponding to the abnormal running state are subjected to in-depth analysis, and the abnormal feature information is extracted. Combined with the logical structure of the software code, the manifestation of the abnormal behavior and the possible types of potential defects are determined.

10. An artificial intelligence based software efficient testing system, characterized in that, It includes: A multi-modal feature data acquisition and packaging unit for acquiring multi-modal feature data of the software to be tested under multiple running scenarios and structurally packaging the data. The output end of the unit is connected to the input end of the multi-modal feature fusion processing unit; A multi-modal feature fusion processing unit for receiving the feature data set output by the multi-modal feature data acquisition and packaging unit, generating a fusion feature vector through a multi-modal feature fusion model, and connecting the output end of the unit to the input end of the test case generation unit; A test case generation unit based on a model-Based test framework, receiving the fusion feature vector output by the multi-modal feature fusion processing unit, and generating an initial test case set. The output end of the unit is connected to the input end of the test case optimization and screening unit; A test case optimization and screening unit for receiving the initial test case set output by the test case generation unit, optimizing and screening through a multi-objective decision algorithm, and obtaining an optimized test case set. The output end of the unit is connected to the input end of the test execution and data acquisition unit; The test execution and data collection unit receives the optimized test case set output by the test case optimization and screening unit, executes on the software to be tested and collects relevant data, and the output end of the test execution and data collection unit is connected with the input end of the abnormal behavior and defect identification unit. The defect positioning and analysis unit receives the data output by the test execution and data collection unit, combines the fusion feature vector output by the multi-modal feature fusion processing unit, determines the defect position and influence range, and the defect positioning and analysis unit is the final output unit of the system.

Images