Software testing intelligent optimization method based on multi-dimensional time series analysis

CN122884843APending Publication Date: 2026-10-09CHINA UNICOM DIGITAL TECNOLOGY CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611076516.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-20
Publication Date
2026-10-09

AI Technical Summary

Technical Problem

[0007]本发明的目的在于提供基于多维时间序列分析的软件测试智能优化方法,以解决现有技术中测试优化决策视野受限、无法充分利用多维时序演化信息、缺乏闭环自适应能力以及生成与排序分离的技术问题

Benefits of technology

[0016]与现有技术相比,本发明所达到的有益效果是:通过采集测试执行、代码变更和系统运行时三类时序数据并构建多维时间序列矩阵,将多维动态信息深度融入测试优化决策,解决了传统方法决策视野受限的问题。采用面向长序列的时序预测网络对故障概率、执行时长和系统性能进行联合预测,为决策提供前瞻性指导。将测试用例生成、优先级排序和停止决策统一建模为深度强化学习驱动的闭环协同优化问题,实现了测试资源的全局最优配置。提出基于剩余故障期望值的动态停止判据,为自动化测试停止提供了量化依据,避免了固定轮次导致的资源浪费。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122884843A_ABST
    Figure CN122884843A_ABST
Patent Text Reader

Abstract

The application discloses a software testing intelligent optimization method based on multi-dimensional time sequence analysis and belongs to the technical field of software testing. The method comprises the following steps: S1, collecting three types of time sequence data of test execution, code change and system runtime to construct a multi-dimensional time sequence matrix; S2, inputting the matrix into a multi-layer time sequence prediction network to predict the module fault probability, test case execution time length distribution and system performance index of the next period; S3-S4, constructing a state space of a deep reinforcement learning decision network and outputting a mixed action; S5-S6, executing a test case, generating a new test case or stopping the test according to the action, and introducing a dynamic stopping criterion based on a residual fault expectation value. The application solves the problems in the prior art that the test optimization decision view is limited, multi-dimensional time sequence evolution information cannot be fully utilized and there is a lack of closed-loop adaptive capability, and realizes closed-loop collaborative optimization of generation, sequencing and stopping.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and more specifically to an intelligent optimization method for software testing based on multidimensional time series analysis. Background Technology

[0002] With the continuous expansion of software system scale and the popularization of agile development models, the frequency of regression testing in continuous integration environments has increased significantly. In a typical continuous integration pipeline, each code commit needs to trigger test execution, but running all test cases in their entirety is often impractical due to the excessive time required. Test case prioritization techniques are widely used to maximize fault detection efficiency within a limited timeframe.

[0003] However, existing methods have the following obvious shortcomings. Most methods only use the historical execution results of test cases as the basis for ranking, failing to effectively integrate multi-dimensional data such as code change information and system runtime performance indicators, resulting in a narrow perspective for ranking decisions.

[0004] Existing methods typically treat each dimension of features as static attributes, ignoring the dynamic characteristics of features evolving with the test cycle, such as the continuous upward trend of execution time and the periodic fluctuation of fault detection rate. This time-series pattern information is directly discarded.

[0005] Existing methods mostly employ an open-loop structure of "sorting first, then executing," lacking the ability to dynamically adjust based on online execution feedback. Test case generation and priority sorting are often processed separately, and historical timing information is not fully utilized when generating new test cases, making it difficult to achieve globally optimal configuration of test resources.

[0006] Therefore, the present invention aims to provide an intelligent optimization method for software testing based on multidimensional time series analysis to address the deficiencies in the existing technology. Summary of the Invention

[0007] The purpose of this invention is to provide a software testing intelligent optimization method based on multidimensional time series analysis, so as to solve the technical problems in the prior art, such as limited decision-making perspective, inability to fully utilize multidimensional time series evolution information, lack of closed-loop adaptive capability, and separation of generation and sorting.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution, specifically including: The intelligent optimization method for software testing based on multidimensional time series analysis includes the following steps: Step S1: Multidimensional Time Series Data Acquisition and Matrix Construction. In each test cycle t (t=1,2,…,M, where M is the number of historical test cycles), three types of multidimensional time series data are collected, including the test execution sequence: the execution duration T of each test case tc. tc (t), Fault detection result Ftc (t)∈{0,1} and code coverage Cov tc (t); Code change sequence: Commit frequency for each module (mod). mod (t) Lines of code modification mod (t) and cyclomatic complexity Cyc mod (t); System runtime sequence: CPU utilization (CPU(t), memory utilization (Mem(t), disk I / O latency (Disk(t)), and network latency (Latency(t)) of the tested system. All the above sequences are aligned according to the test period to construct a multidimensional time series matrix X∈R. M×D , where D is the total dimension of all sequences.

[0009] Step S2: Multidimensional Temporal Joint Prediction. The multidimensional time series matrix X constructed in Step S1 is input into a multilayer temporal prediction network. This network adopts an encoder-decoder architecture. The encoder uses a probabilistic sparse self-attention mechanism to extract features from the input sequence, and the decoder uses generative inference to output multiple prediction steps at once. The network outputs three joint prediction results: the predicted failure probability p of each code module in the next test cycle (M+1). mod (M+1); Predicted execution time distribution of each test case in the next test cycle, including expected execution time. and its 95% confidence interval Time-series predictions of system runtime performance metrics for the next testing cycle, including .

[0010] Step S3: State Space Construction and Decision Network Initialization. At the beginning of each test cycle, the state space S of the deep reinforcement learning decision network is constructed, including: the three joint prediction results output in step S2; the embedding representation of the current set of test cases to be executed, with each test case converted into a fixed-dimensional embedding vector through a pre-trained encoder; and the current remaining test time budget. and remaining computing resource budget The decision network employs the SAC algorithm, and its policy network is a Gaussian distribution with reparameterization trick.

[0011] Step S4: Hybrid Action Decision Output. The deep reinforcement learning decision network outputs a hybrid action A based on the current state S. The action space includes discrete actions and continuous actions: discrete actions include selecting the next test case to be executed from the candidate set, triggering the generation of a new test case, and triggering early termination of the test; continuous actions include the mutation intensity coefficient σ∈[0,1] and the priority threshold θ∈[0,1] when generating a new test case. The network adopts the maximum entropy reinforcement learning objective function: , Where H is the strategy entropy and α is the temperature parameter.

[0012] Step S5: Execute test case decision processing. If the discrete action output in step S4 is "Select test case to execute", then the test execution engine is invoked to run the selected test case and the actual execution time is recorded. Actual fault detection label The actual coverage increment Δcov is calculated, and the single-step reward is calculated based on the actual execution results, updating the remaining time budget. If the discrete action output in step S4 is "trigger new test case generation", the test case generation process is invoked; using the test case associated with the module with the highest predicted failure probability in the current candidate set as the seed, parameter value mutation, execution order mutation, and conditional branch mutation are performed according to the mutation intensity coefficient σ to generate one or more new test cases, which are then added to the set of test cases to be executed. The larger σ is, the greater the mutation amplitude and the stronger the exploratory nature.

[0013] Step S6: Stop decision-making and dynamic criterion calculation. After each decision-making step, calculate the expected value of the remaining fault: , Ind tc,mod This is an indicator variable, representing whether test case tc covers module mod. If ENRF is lower than a preset threshold ENRF... min And no faults are detected in K consecutive actions, or the remaining time budget If the condition is met, the "Trigger Stop Test" action will be output, terminating the current test round.

[0014] Step S7: Calculation of Total Periodic Reward and Trajectory Storage. At the end of a test cycle, the total periodic reward R is calculated based on all execution results within that cycle, using a multi-objective weighted approach: , in As a reward for fault detection, r coverage p is the ratio of the cumulative coverage gain to the target gain over the period. time As a penalty for exceeding the time limit, p redundancy The redundancy execution ratio is represented by α, β, γ, and δ, which are weighting coefficients. The complete trajectory S, A, R, S' of this cycle is stored in the experience pool, and then the next test cycle begins, returning to step S1, until the termination condition is met. The termination condition includes: reaching the preset maximum number of test cycles, receiving an external stop command, or all module failure probability prediction values ​​being lower than a preset threshold.

[0015] Step S8: Prioritize experience replay and network parameter update. Sample training data from the experience pool, prioritizing the sampling process. , where R norm For the normalized total periodic reward, Let be a small bias constant, and κ be a sampling bias hyperparameter. The policy and value networks of the deep reinforcement learning decision network are updated using gradient descent with the sampled mini-batch data. The update formula is as follows: , where η is the learning rate and L(θ) is the loss function.

[0016] Compared with existing technologies, the beneficial effects achieved by this invention are as follows: By collecting three types of time-series data—test execution, code change, and system runtime—and constructing a multi-dimensional time-series matrix, multi-dimensional dynamic information is deeply integrated into test optimization decisions, solving the problem of limited decision-making perspective in traditional methods. A time-series prediction network oriented towards long sequences is employed to jointly predict fault probability, execution duration, and system performance, providing forward-looking guidance for decision-making. Test case generation, priority ranking, and stopping decisions are uniformly modeled as a closed-loop collaborative optimization problem driven by deep reinforcement learning, achieving globally optimal allocation of test resources. A dynamic stopping criterion based on the expected value of remaining faults is proposed, providing a quantitative basis for automated test stopping and avoiding resource waste caused by fixed rounds. Attached Figure Description

[0017] 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: Figure 1 This is a flowchart illustrating the steps of the intelligent optimization method for software testing based on multidimensional time series analysis, as described in this invention. Detailed Implementation

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

[0019] Please see Figure 1 The present invention provides the following technical solution: like Figure 1 As shown, this embodiment uses a medium-sized e-commerce backend system as the test object. This system contains 50 core modules, numbered mod=1,2,…,50, and 200 regression test cases, numbered tc=1,2,…,200. The test cycle corresponds to each build of the continuous integration system, and complete data for M=20 historical test cycles are available.

[0020] Step S1: In each historical period t=1,2,…,20, data is collected in the following manner.

[0021] By using the hook functions of the pytest testing framework, the execution time, fault detection results, and code coverage of each test case are recorded. Define T. tc (t) represents the execution duration of test case tc in cycle t, in milliseconds (ms); F tc (t) represents the fault detection result, F tc (t)=1 indicates that at least one fault was detected in this test case during the period, F tc (t)=0 indicates that no fault was detected; Cov tc (t) represents code coverage, expressed as a percentage, and is defined as the ratio of the number of lines of code covered during test case execution to the total number of lines of code in the target module multiplied by 100%.

[0022] Taking test case tc=100 as an example, its execution time sequence from cycle 16 to 20 is as follows: T 100 (16) = 1250 ms, T 100 (17) = 1280 ms, T 100 (18) = 1310 ms, T 100 (19) = 1340 ms, T 100 (20) = 1380ms. Fault detection result sequence: F 100 (16)=0, F 100 (17)=0, F 100 (18)=1, F 100 (19)=1, F 100 (20) = 0. Code coverage: Cov 100 (20) = 78.5%.

[0023] Git hook scripts are used to record the modules involved and the number of lines modified at each code commit, and the cyclomatic complexity is calculated using the static analysis tool Lizard. A commit definition is then established. mod (t) represents the number of code commits made by module mod during period t; Lines mod (t) represents the total number of lines of code added and deleted by module mod during cycle t; Cyc mod (t) represents the average cyclomatic complexity of all functions of module mod during period t. The formula for calculating cyclomatic complexity Cyc is Cyc = E - N + 2P, where E is the number of edges in the control flow graph, N is the number of nodes, and P is the number of connected components.

[0024] Taking module mod=15 as an example, its cyclomatic complexity sequence in cycles 16 to 20 is: Cyc 15 (16) = 12.3, Cyc 15 (17) = 13.1, Cyc 15 (18) = 14.5, Cyc15 (19) = 16.2, Cyc 15 (20) = 18.4. Commit frequency sequence: Commit 15 (16)=3, Commit 15 (17) = 4, Commit 15 (18) = 5, Commit 15 (19) = 6, Commit 15 (20) = 5. Code modification: Lines 15 (16) = 120, Lines 15 (17) = 156, Lines 15 (18) = 202, Lines 15 (19) = 278, Lines 15 (20) = 245.

[0025] The CPU utilization, memory utilization, disk I / O latency, and network latency of the tested server were collected at 1-minute sampling intervals during the test period using Prometheus Node Exporter, and the data was aggregated into an average value for each period. CPU(t) is defined as the average CPU utilization of the tested system in period t, in percentage; Mem(t) is the average memory utilization, in percentage; Disk(t) is the average disk I / O latency, in milliseconds; and Latency(t) is the average network latency, in milliseconds. The data for period 20 are: CPU(20) = 67.3%, Mem(20) = 54.1%, Disk(20) = 8.7ms, and Latency(20) = 125.3ms.

[0026] Construct a multidimensional time series matrix, aligning all the sequences according to periods t=1,…,20. The total dimension D is calculated as follows: each test case contributes 3 sequences, totaling 200 test cases → 600 dimensions; each module contributes 3 sequences, totaling 50 modules; and the system runtime contributes 4 sequences. The total D = 600 + 150 + 4 = 754. Therefore, X∈R 20×754 That is, 20 rows and 754 columns.

[0027] Step S2: Input X into a pre-trained Informer network. The network parameters are set as follows: 3 encoder layers, 8 attention heads, 512 hidden layer dimensions, and a learning rate of 0.0001. The input sequence length Lin = 20, and the prediction stride L... out =1. The three-term joint prediction results output by the network are as follows.

[0028] Define p mod(M+1) represents the predicted probability that module mod will fail at least once in the next test cycle, taking values ​​[0,1]. For module mod=15, the predicted output p 15 (21) = 0.73. This predicted value is relatively high, mainly driven by the continuous upward trend of the module's cyclomatic complexity and the frequency of historical failures. For module mod = 8, p8(21) = 0.12. For module mod = 2, p2(21) = 0.64.

[0029] Predicting the distribution of test case execution time. Definition Predict the expected execution time of test case tc in the next cycle, in milliseconds; Use its 95% confidence interval. For example, with tc=100, predict the expected value. Calculation method: The model captures the execution time sequence of this use case over the past 5 cycles [1250, 1280, 1310, 1340, 1380], showing a linear growth trend of approximately +30ms per cycle. Extrapolation yields 1380 + 30 = 1410ms, which is then smoothed by the model and output as 1420ms. A 95% confidence interval is also output. .

[0030] Predicting system runtime performance metrics. Definition , These are the predicted values ​​for the system performance indicators for the next cycle. This example outputs: The 95% confidence interval is [64.5%, 77.9%]; The 95% confidence interval is [52.1%, 61.5%]; The 95% confidence interval is [7.8, 10.6] ms; The 95% confidence interval is [118.5, 144.9] ms.

[0031] Step S3: The deep reinforcement learning decision network adopts the SAC algorithm, and its policy network is a Gaussian distribution with reparameterization trick. The state space S consists of the following three parts.

[0032] The three joint prediction results output in step S2, i.e., each module p mod (21) Each use case It includes confidence intervals and system performance predictions, totaling approximately 650 values.

[0033] The embedded representation of the test case set to be executed. Define the pre-trained test case encoder as Encoder. tc Based on the GraphCodeBERT model, it was pre-trained on data from 12 open-source projects and then fine-tuned on the data from this project. Each test case tc is encoded with a fixed dimension d. eEmbedded vector e = 128 tc =Encoder tc (tc)∈R 128 Taking tc=100 as an example, its embedding vector e 100 The 128 values ​​are not listed one by one in this embodiment, but they are used as part of the state space in subsequent calculations.

[0034] Remaining time and resource budget. Definition B t For the time budget of a single test cycle, this embodiment takes B. t =7200 seconds; B r To calculate the resource budget, it is represented by the maximum CPU utilization rate. In this embodiment, B is taken as the maximum utilization rate. r =75%. The initial time elapsed was 0, therefore the remaining time budget... Seconds, remaining computing resource budget .

[0035] Step S4: The decision network outputs a hybrid action A based on the current state S. The policy network calculates a priority score for each candidate use case. The calculation of the priority score comprehensively considers the weighted failure probability of the modules covered by the use case; and the matching degree between the predicted execution time and the remaining time budget.

[0036] The priority comparison process is illustrated using two candidate test cases as an example. The priority score calculation process for the candidate test case tc=100 is as follows: This test case covers modules mod=2 and mod=8. Module 2 has 245 lines of code, and module 8 has 85 lines of code, for a total of L lines of code. 100 =245+85=330 rows. The predicted failure probability of module 2 is p2(21)=0.64, and the predicted failure probability of module 8 is p8(21)=0.12. Weighted failure probability .

[0037] Predicted execution time The second is a very small percentage of the remaining time budget of 7196 seconds, resulting in a high matching score.

[0038] Historical fault detection rate: Over the past 20 periods, F 100 The number of times (t) = 1 is 8, therefore the historical failure rate h 100 =8 / 20=0.40.

[0039] Coverage increment potential estimation: Estimated by the model based on the coverage change trend over the most recent 3 periods, it is approximately 6 lines of new coverage code. Based on the above characteristics, the policy network assigns a priority score of tc=100. 100 =0.85.

[0040] The priority score calculation process for candidate use case tc=45 is as follows: This use case covers modules mod=15 and mod=10. Module 15 predicts the failure probability p. 15 (21) = 0.73, Module 10 predicts the failure probability p 10 (21) = 0.58. The number of lines of code covered are 320 lines for module 15 and 210 lines for module 10, for a total of 530 lines. Weighted failure probability. ≈0.671. Predicted execution time Seconds. Historical fault detection rate: 5 faults were detected in the past 20 cycles, h 45 =0.25. Estimated potential for increased coverage: approximately 15 lines of new covered code. Overall Score 45 =0.92, higher than Score 100 Therefore, the policy network selects to execute tc=45. Simultaneously, the continuous action output variation intensity coefficient σ=0.5 and the priority threshold θ=0.6.

[0041] Step S5: After executing tc=45, the test execution engine returns the actual execution result: actual execution time. Actual fault detection indicator Actual coverage increase Okay. Update remaining time budget: Second.

[0042] Suppose that in a certain round of decision-making, there is ample remaining time budget, but the remaining unexecuted test cases are mostly marginal test cases with low coverage and low historical failure rates. The policy network determines that new test cases need to be generated to cover modules with a high predicted failure probability, and thus outputs the discrete action "trigger new test case generation," while simultaneously outputting the continuous action variation strength coefficient σ = 0.7. The variation strength coefficient σ ∈ [0,1] is defined; a larger value indicates a greater difference between the generated new test case and the seed test case, and a stronger exploratory nature.

[0043] From the historical test case set, the test case with the highest correlation to module 15, which has the highest predicted failure probability, was retrieved. Correlation was defined as the proportion of lines of code covering module 15 out of the total lines of code (tc=45). The 320 lines of code covering module 15, out of a total of 530 lines, represented approximately 60% and were therefore selected as the seed test case. Gaussian noise was added to the input parameters of the seed test case to mutate the parameter values. Let the input parameters of the seed test case be a vector `param`. seed The parameters after mutation: , Where `range` represents the basic value range of each parameter. For example, in the seed use case, there is a parameter "order amount" with a basic value range of [0, 1000] yuan. When σ = 0.7, the noise standard deviation δnoise =0.7 × 1000 = 700 yuan, therefore the modified order amount may fluctuate significantly around the original value. The original parameter "order amount = 100 yuan" may become after modification. For example, it can generate "Order amount = 143 yuan".

[0044] Execution order mutation randomly rearranges the sequence of operation steps in the seed use case. Let the length of the original step sequence be L. steps The variation intensity σ controls the proportion of steps requiring rearrangement. When σ = 0.7, approximately 0.7 × L is randomly selected. steps The positions are swapped in one step.

[0045] Conditional branch mutation inserts additional branch conditions or modifies existing conditional expressions at critical decision points in seed test cases. For example, the original condition "if (status == SUCCESS)" might become "if (status== SUCCESS&&random()<0.5)" after mutation. The generated new test case tc=201 is added to the candidate set for execution, for subsequent decision loops to select for execution.

[0046] Step S6: After each decision step, the Expected Remaining Fault Value (ENRF) must be calculated, and a decision must be made as to whether to stop the test. The formula for calculating ENRF is: , Ind tc,mod This is an indicator variable; it is set to 1 when the test case tc covers the module mod, and 0 otherwise. This represents the probability that module mod is not covered by any of the executed test cases in the set of executed test cases. Therefore, 1 minus this product is the probability that module mod is covered by at least one executed test case.

[0047] After the first round of execution, the executed test case set only contains tc=45. tc=45 covers modules 15 and 10, therefore for module 15, Ind 45,15 =1, Similarly, for module 10, Ind = 1; for other modules, Ind = 0. .therefore , Preset threshold ENRF min =2.0, current ENRF=1.31<2.0, but the number of consecutive fault-free actions has not yet reached K=5, therefore stop is not triggered, and the next round of decision-making continues. After executing approximately 120 test cases, a total of 22 faults were detected, and the remaining time budget... Seconds. At this point, ENRF is recalculated.

[0048] Taking Module 15 as an example, this module contains 50 coverable function nodes. Of the 120 executed test cases, 48 ​​covered different functions in Module 15, achieving a coverage rate of 96%. Accurate calculation using product terms... This represents the probability that none of the executed test cases cover module 15. Since 48 test cases cover module 15, and the coverage indicator for these test cases is 1, therefore 1-Ind tc,15 =0 For these use cases, the product is 0, so 1-0=1. However, more generally, if it's not complete coverage, the product needs to be calculated. In this embodiment, since there is already coverage, the actual probability of being covered is close to 1, so for simplicity, we take: , Therefore, the expected residual fault contribution of module 15 is 0.73 × 0.98 = 0.715. For module 2, 40 executed test cases covered this module, with a coverage rate of 40 / 50 = 80%, a coverage probability of approximately 0.98, and a contribution of 0.64 × 0.98 = 0.627.

[0049] Module 8 has 35 test cases covering it, a coverage rate of 70%, with a coverage probability of approximately 0.95, contributing 0.12 × 0.95 = 0.114. The combined contribution of other modules is approximately 0.2. Therefore, ENRF ≈ 0.715 + 0.627 + 0.114 + 0.2 = 1.656. Since the current ENRF = 1.656 < 2.0, and no faults were detected in K = 5 consecutive actions, the policy network outputs the "Trigger Stop Test" action, terminating this round of testing.

[0050] Step S7: After the 21st cycle ends, calculate the total execution result for this cycle. Let N be the total number of faults actually detected in this cycle. detected =22; Fault detection budget N budget =25; Coverage Cov at the start of the cycle start =65%, coverage Cov at the end end =82%, Expected coverage gain target Cov target =20 percentage points; Actual test execution time t actual =7200 seconds, time budget B t =7200 seconds; Number of redundant test cases N executed in this cycle redundant =15, Total number of executed test cases N executed =120.

[0051] Fault detection reward ; Coverage gain bonus ; Timeout penalty p time If t actual >B tThen take 1, otherwise take 0. Since 7200 ≤ 7200, therefore p time =0; Redundancy execution penalty ; Let the weighting coefficients be α=1.0, β=0.3, γ=0.5, and δ=0.2.

[0052] The total periodic reward R is calculated as follows: Substituting the values: R = 1.0 × 0.88 + 0.3 × 0.85 - 0.5 × 0 - 0.2 × 0.125 = 0.88 + 0.255 - 0.025 = 1.11. Store the complete trajectory (S, A, R, S') for this period into the experience pool.

[0053] Step S8: The experience pool already contains 5000 historical tracks. Let R be the minimum reward in the experience pool. min ≈-1.0, maximum reward R max ≈2.0. Normalize the current reward R=1.11: .

[0054] The formula for calculating the sampling priority w is as follows: ,Pick =0.01, k=0.6. Substitute into the calculation: Calculate 0.713 0.6 ln(0.713)≈-0.338, multiplying by 0.6 gives -0.2028, e -0.2028 Since w ≈ 0.816, we use Priority Experience Replay (PER) to non-uniformly sample 32 trajectories from the experience pool according to priority w, forming a mini-batch of training data. For each trajectory, we calculate the loss function L(θ) and use the Adam optimizer to update the policy network parameters θ using gradient descent. The learning rate η = 0.0003. This update enables the decision network to output better action decisions when facing similar states in the future. After the current cycle ends, the next test cycle begins and returns to step S1 to continue execution. The entire test process terminates when the preset maximum number of test cycles is reached, an external stop command is received, or the predicted failure probability values ​​of all modules are lower than the preset threshold.

[0055] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0056] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A software testing intelligent optimization method based on multidimensional time series analysis, characterized in that, Includes the following steps: Step S1: Collect test execution sequence, code change sequence, and system runtime sequence in each test cycle, and align them by cycle to construct a multi-dimensional time series matrix; Step S2: Input the multidimensional time series matrix into the multilayer time series prediction network to output the failure probability prediction of each module, the execution time distribution prediction of each test case, and the system performance index prediction in the next test cycle. Step S3: Construct the state space of the deep reinforcement learning decision network, including the three prediction results, the embedding of the test case set to be executed, and the remaining time and resource budget; Step S4: The decision network outputs a hybrid action based on the current state. The hybrid action includes three discrete actions: selecting test case execution, triggering new test case generation, and triggering test stop; as well as two continuous actions: mutation intensity coefficient and priority threshold. Step S5: When the action is to execute a test case, run the selected test case and record the execution result; when the action is to generate a test case, generate a new test case according to the mutation intensity coefficient and add it to the candidate set. Step S6: Terminate the current test when the action is to stop the test or the dynamic stopping criterion is met; Step S7: Calculate the total reward for the period and store the trajectory in the experience pool; Step S8: Sample and update the decision network parameters from the experience pool using priority experience replay, then proceed to the next test cycle and return to step S1 until the termination condition is met.

2. The intelligent optimization method for software testing based on multidimensional time series analysis according to claim 1, characterized in that, The test execution sequence mentioned in step S1 includes the execution time sequence T of each test case. tc (t), Fault detection result sequence F tc (t)∈{0,1} and code coverage sequence Cov tc (t); The code change sequence includes the commit frequency sequence of each module. mod (t) Lines of code modification sequence mod (t) and the cyclomatic complexity sequence Cyc mod (t); the system runtime sequence includes CPU utilization (CPU(t), memory utilization (Mem(t), disk I / O latency (Disk(t)), and network latency (Latency(t)); the multidimensional time series matrix X∈R M×D , where M is the number of historical test periods and D is the total dimension of all sequences.

3. The intelligent optimization method for software testing based on multidimensional time series analysis according to claim 1, characterized in that, The multi-layer temporal prediction network in step S2 adopts an encoder-decoder architecture. The encoder uses a probabilistic sparse self-attention mechanism, and the decoder uses generative inference to output the prediction step size at one time. The execution duration distribution prediction includes the expected value. and its 95% confidence interval Where tc is the test case number and M is the number of historical test cycles. Predict the expected execution time of test case tc in the next cycle. and These are the lower and upper limits of the confidence interval, respectively.

4. The intelligent optimization method for software testing based on multidimensional time series analysis according to claim 1, characterized in that, The test case set embedding described in step S3 is generated by a pre-trained encoder, with each test case mapped to a fixed-dimensional embedding vector; the decision network in step S4 uses the SAC algorithm, with the objective function being: , Where π is the policy function, s t Let a be the state at time t. t Let r(s) be the action at time t. t ,a t ) is the reward function, α is the temperature parameter, and H is the policy entropy.

5. The intelligent optimization method for software testing based on multidimensional time series analysis according to claim 1, characterized in that, The total periodic reward mentioned in step S7: , in N detected N represents the total number of faults actually detected in this period. budget Budget for fault detection; r coverage p is the ratio of cumulative coverage gain to target gain over the period. time As a timeout penalty, a value of 1 is applied if the actual execution time exceeds the time budget, otherwise a value of 0 is applied; p redundancy α represents the redundancy execution ratio, which is the ratio of the number of redundant test cases to the total number of executed test cases; α, β, γ, and δ are weighting coefficients.

6. The intelligent optimization method for software testing based on multidimensional time series analysis according to claim 1, characterized in that, The dynamic stopping criterion in step S6 is: calculating the expected value of remaining faults. , Where mod is the micromodule number, p mod Here, tc represents the predicted failure probability value for module mod, and Ind represents the test case number. tc,mod This is an indicator variable; when ENRF is below a preset threshold ENRF min If no faults are detected for K consecutive actions, or if the remaining time budget is insufficient, the test will be stopped.

7. The intelligent optimization method for software testing based on multidimensional time series analysis according to claim 1, characterized in that, When generating new test cases in step S5, the seed test case associated with the module with the highest predicted failure probability is used as the basis, and parameter value mutation, execution order mutation and conditional branch mutation are performed according to the mutation intensity coefficient σ, where σ∈[0,1].

8. The intelligent optimization method for software testing based on multidimensional time series analysis according to claim 1, characterized in that, The sampling priority of the priority experience playback mentioned in step S8 , where R norm For the normalized total periodic reward, η is a small bias constant, κ is a sampling bias hyperparameter, the network parameters are updated using mini-batch gradient descent, and the learning rate is η.

9. The intelligent optimization method for software testing based on multidimensional time series analysis according to claim 1, characterized in that, In step S4, the mutation intensity coefficient σ and the priority threshold θ are dynamically output by the decision network based on the current state, where σ controls the exploration degree of newly generated use cases and θ is used to filter low-priority use cases.