Task processing method and electronic device

Abstract

The application discloses a task processing method and an electronic device, and relates to the technical field of computers, which comprises the following steps: extracting a plurality of target dimension features from a node test task, and converting each target dimension feature in the plurality of target dimension features into a target feature vector; acquiring a matching degree between the plurality of target feature vectors of the node test task and a plurality of feature vectors of each historical node test task in a composite feature library, so as to screen an optimal node test strategy from a node test strategy library; comparing the plurality of target feature vectors with a plurality of feature vectors of a target historical node test task associated with the optimal node test strategy, determining a difference index between the node test task and the target historical node test task, adjusting the optimal node test strategy, generating a target node test strategy, and processing the node test task. The technical effect of improving the test efficiency and the test quality is achieved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to task processing methods and electronic devices. Background Technology

[0002] Node testing is a core component in ensuring system performance, stability, security, and service capacity. Currently, related technologies involve manually designing corresponding node testing strategies for different tasks. However, processing node testing tasks based on these manually designed strategies results in low testing efficiency and quality. Summary of the Invention

[0003] This application provides a task processing method and electronic equipment to at least solve the problems of low testing efficiency and testing quality in related technologies.

[0004] This application provides a task processing method, including: Receive node test tasks; Extract multiple target dimension features from the node test task, and convert each target dimension feature into a target feature vector. Obtain the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of each historical node test task in the composite feature library; Based on the matching degree, the optimal node testing strategy is selected from the node testing strategy library; By comparing multiple target feature vectors with multiple feature vectors of the target historical node test task associated with the optimal node test strategy, the difference index between the node test task and the target historical node test task is determined. Based on the difference indicators, the optimal node testing strategy is adjusted to generate the target node testing strategy; Based on the target node testing strategy, node testing tasks are processed.

[0005] This application also provides a task processing apparatus, including: The receiving module is used to receive node test tasks; The extraction module is used to extract multiple target dimension features from the node test task and convert each target dimension feature into a target feature vector. The acquisition module is used to obtain the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of each historical node test task in the composite feature library; The filtering module is used to select the optimal node testing strategy from the node testing strategy library based on the matching degree. The determination module is used to compare multiple target feature vectors with multiple feature vectors of the target historical node test task associated with the optimal node test strategy, and determine the difference index between the node test task and the target historical node test task. The adjustment module is used to adjust the optimal node testing strategy based on the difference indicators and generate the target node testing strategy. The processing module is used to process node test tasks based on the target node test strategy.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described task processing methods.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described task processing methods.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described task processing methods.

[0009] This application extracts multiple target dimension features from a node testing task and converts each target dimension feature into a target feature vector. It then obtains the matching degree between these target feature vectors and multiple feature vectors from each historical node testing task in a composite feature library. Based on the matching degree, it selects the optimal node testing strategy from the node testing strategy library, ensuring that the selected optimal node testing strategy best matches the node testing task, thus achieving automatic selection of the optimal node testing strategy. The application compares the multiple target feature vectors with the multiple feature vectors of the target historical node testing tasks associated with the optimal node testing strategy to determine the difference index between the node testing task and the target historical node testing tasks. Based on the difference index, it adjusts the optimal node testing strategy to generate a target node testing strategy. Finally, it processes the node testing task based on the target node testing strategy. By using the difference index, it achieves adaptive adjustment of the optimal node testing strategy, ensuring that the generated target node testing strategy is the most suitable node testing strategy for the node testing task. Therefore, it can solve the technical problems of low testing efficiency and low testing quality in related technologies for processing node testing tasks, achieving the technical effect of improving testing efficiency and testing quality. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of the structure of a task processing system provided in an embodiment of this application; Figure 2 A flowchart illustrating a task processing method provided in an embodiment of this application; Figure 3 A flowchart illustrating yet another task processing method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a task processing device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0013] It should be noted that, in the description of this application, 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 a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] Throughout the entire lifecycle of node development, production deployment, and operation and maintenance iterations, node testing is a core component ensuring hardware performance, software compatibility, system stability, and business carrying capacity. With the development of cloud computing, big data, and artificial intelligence, the types of nodes and their application scenarios are becoming increasingly diverse, placing higher demands on the refinement, efficiency, and targeting of node testing. In related technologies, there are two main approaches to node testing tasks: First, testers design corresponding node testing strategies from scratch based on node type, application scenario, and testing requirements, combined with their professional experience. This includes test scope, test case design, environment setup, and execution strategies. Second, a simple test case library is built, where testers reuse some test cases through key searches and then manually integrate them into a complete testing strategy.

[0016] It is evident that the first approach in related technologies heavily relies on the testers' professional experience and familiarity with node architecture and industry scenarios. Novice testers are prone to issues such as incomplete test point coverage and unreasonable threshold settings, making it difficult to guarantee test quality. For new types and scenarios of node testing tasks, node testing strategies must be designed from scratch. Strategies for similar nodes and scenarios are repeatedly designed, resulting in long design cycles and low testing efficiency. Historical assets such as accumulated test cases and node testing strategies lack standardized management, are not associated with node testing tasks, and cannot be quickly retrieved and reused, leading to a waste of knowledge assets. Node testing strategy designs are often based on theoretical metrics and general application scenarios, failing to incorporate online operational data from node deployment scenarios. This mismatch between testing focus and real-world risks leads to a high rate of missed tests.

[0017] The second processing method in related technologies still requires significant manual intervention for integration, resulting in low testing efficiency. It focuses on a single testing dimension and cannot meet the testing needs of multiple dimensions.

[0018] To address the aforementioned technical problems, embodiments of this application provide a task processing method. Figure 1 This is a schematic diagram of the structure of the task processing system on which the task processing method provided in the embodiments of this application is based, such as... Figure 1As shown, the task processing system includes a client and a server. The client sends node test tasks to the server. The server receives node test tasks; extracts multiple target dimension features from the node test tasks and converts each target dimension feature into a target feature vector; obtains the matching degree between the multiple target feature vectors of the node test task and the multiple feature vectors of each historical node test task in the composite feature library; based on the matching degree, selects the optimal node test strategy from the node test strategy library; compares the multiple target feature vectors with the multiple feature vectors of the target historical node test tasks associated with the optimal node test strategy to determine the difference index between the node test task and the target historical node test tasks; adjusts the optimal node test strategy based on the difference index to generate the target node test strategy; and processes the node test tasks based on the target node test strategy.

[0019] An embodiment of this application provides a task processing method applied to the aforementioned server. Figure 2 This is a flowchart illustrating the task processing method provided in the embodiments of this application, as shown below. Figure 2 As shown, the task processing method includes the following steps: Step S201: Receive node test task.

[0020] Among them, nodes include, but are not limited to, computing nodes (servers), switching nodes (switches), and storage nodes (storage devices).

[0021] Node testing tasks include full testing tasks before the node goes live and full testing tasks after the node goes live and is upgraded, which means a complete test of the node.

[0022] Step S202: Extract multiple target dimension features from the node test task, and convert each target dimension feature into a target feature vector.

[0023] These target dimensions include: hardware dimensions, application scenario dimensions, online operation dimensions, test target dimensions, and change dimensions. It's understandable that online operation dimensions are not included when a node test task is not processed; that is, the online operation dimensions are empty.

[0024] Specifically, each target dimension feature in the multiple target dimension features is standardized to generate multiple composite feature vectors in a unified format, that is, to generate multiple target feature vectors.

[0025] Step S203: Obtain the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of each historical node test task in the composite feature library.

[0026] Specifically, based on the historical test asset library and the online operation data of test tasks at various historical nodes, the five target dimensions of each historical node test task are extracted. For any historical node test task, the five target dimensions of the historical node test task are standardized to generate multiple composite feature vectors in a unified format, that is, to generate multiple feature vectors for that historical node test task.

[0027] The five target dimensions and multiple feature vectors of the test tasks at each historical node are stored in a composite feature library, and feature dimension indexes and keyword indexes are established to support fast retrieval of feature vectors, real-time updates of feature information, and flexible expansion of new dimension features.

[0028] The historical node testing tasks include full-scale testing tasks that pass the test after being processed by the corresponding node testing strategy before the node goes live; and full-scale testing tasks that pass the test after the node goes live and is upgraded, after being processed by the corresponding node testing strategy.

[0029] The online operation data of the historical node test task refers to the online operation data after the node in the historical node test task is launched or upgraded.

[0030] Step S204: Based on the matching degree, select the optimal node testing strategy from the node testing strategy library.

[0031] This process involves extracting node testing strategies from the historical test asset repository and storing them in a node testing strategy library. The node testing strategy library includes node testing strategies adopted for multiple historical node testing tasks, with one historical node testing task corresponding to one node testing strategy. The node testing strategies in the node testing strategy library are then associated with the corresponding historical node testing tasks in the composite feature library. Initially, the node testing strategies in the library are generated by domain experts based on the associated historical node testing tasks, and are subsequently expanded based on automatically generated node testing strategies corresponding to newly added node testing tasks.

[0032] It should be noted that after extracting the node test strategies from the historical test asset library, the node test strategies are standardized and organized, and then the node test strategies are structured and stored in the node test strategy library.

[0033] Step S205: Compare multiple target feature vectors with multiple feature vectors of the target historical node test task associated with the optimal node test strategy to determine the difference index between the node test task and the target historical node test task.

[0034] Each target dimension includes multiple metrics. For example, hardware dimension features include metrics such as node type, node architecture, processor architecture, memory capacity, storage type, network configuration, and cluster type. Application scenario dimension features include metrics such as business scenario and deployment mode. Online operation dimension features include targets such as fault type, fault escape rate, fault occurrence frequency, and failover time. Testing target dimension metrics include metrics such as target failover time and target cluster type. Change dimension features include metrics such as storage architecture changes, storage type changes, and network configuration changes.

[0035] Step S206: Based on the difference index, adjust the optimal node testing strategy to generate the target node testing strategy.

[0036] Step S207: Process node test tasks based on the target node test strategy.

[0037] The task processing method provided in this application extracts multiple target dimension features from a node testing task and converts each target dimension feature into a target feature vector; obtains the matching degree between the multiple target feature vectors of the node testing task and the multiple feature vectors of each historical node testing task in a composite feature library; based on the matching degree, selects the optimal node testing strategy from the node testing strategy library; ensures that the selected optimal node testing strategy is most suitable for the node testing task, and realizes automatic selection of the optimal node testing strategy; compares the multiple target feature vectors with the multiple feature vectors of the target historical node testing tasks associated with the optimal node testing strategy to determine the difference index between the node testing task and the target historical node testing tasks; adjusts the optimal node testing strategy based on the difference index to generate a target node testing strategy; and processes the node testing task based on the target node testing strategy. By using the difference index, the optimal node testing strategy is adaptively adjusted, ensuring that the generated target node testing strategy is the most suitable node testing strategy for the node testing task. Therefore, it can solve the technical problems of low testing efficiency and low testing quality in related technologies for processing node testing tasks, achieving the technical effect of improving testing efficiency and testing quality.

[0038] In some optional implementations, step S203 above includes: Step S2031: For any historical node test task in the composite feature library, obtain the similarity between each target feature vector in the multiple target feature vectors of the node test task and the corresponding feature vector of the historical node test task.

[0039] Step S2032: Based on similarity, determine the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task.

[0040] The task processing method provided in this application calculates the similarity of multiple target feature vectors of the same historical node test task and then determines the matching degree, making the selected optimal node test strategy more accurate.

[0041] In some optional implementations, step S2031 above includes: Step a1: For any historical node test task in the composite feature library, based on the first formula, determine the similarity between the j-th target feature vector among multiple target feature vectors of the node test task and the corresponding feature vector of the historical node test task. The first formula is:

[0042] in, Let be the similarity between the j-th target feature vector among multiple target feature vectors of the node testing task and the corresponding feature vector of the historical node testing task, where n is the number of indicator vectors included in the j-th target feature vector. Let i be the index vector in the j-th target feature vector. This refers to the indicator vector corresponding to the i-th indicator vector among the feature vectors corresponding to the j-th target feature vector in the test task at this historical node. The similarity value ranges from [0, 1] and is used to measure the angle between two feature vectors. The smaller the angle, the higher the similarity between the two feature vectors.

[0043] In some optional implementations, step S2032 above includes: Step b1: Based on similarity, determine the total similarity between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task.

[0044] Step b2: Obtain the matching weight of the node test strategy associated with the historical node test task.

[0045] Step b3: Based on the total similarity and matching weight, determine the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task.

[0046] The task processing method provided in this application determines the matching degree between node test tasks and historical node test tasks based on the total similarity and matching weight, effectively suppressing false matching with high similarity and low reliability, and ensuring the quality of the selected optimal node test strategy.

[0047] In some alternative implementations, step b1 above includes: Step b11: Based on the second formula, determine the total similarity between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task. The second formula is: Sim=α×Cos(Fm)+β×Cos(Fs)+γ×Cos(Fo)+δ×Cos(Ft)+ε×Cos(Fc) Where Sim is the total similarity, Cos(Fm) is the similarity between the target feature vector corresponding to the hardware dimension feature and the corresponding feature vector of the test task at the historical node, Cos(Fs) is the similarity between the target feature vector corresponding to the application scenario dimension feature and the corresponding feature vector of the test task at the historical node, Cos(Fo) is the similarity between the target feature vector corresponding to the online operation dimension feature and the corresponding feature vector of the test task at the historical node, Cos(Ft) is the similarity between the target feature vector corresponding to the test target dimension feature and the corresponding feature vector of the test task at the historical node, Cos(Fc) is the similarity between the target feature vector corresponding to the changed dimension feature and the corresponding feature vector of the test task at the historical node, α, β, γ, δ and ε are the weight coefficients of the similarity between the target feature vector corresponding to different target dimension features and the corresponding feature vector of the test task at the historical node, and α+β+γ+δ+ε=1.

[0048] It is understandable that the similarity between the target feature vector corresponding to the hardware dimension feature and the corresponding feature vector of the test task at that historical node is the same as the similarity between the target feature vector corresponding to the hardware dimension feature and the feature vector corresponding to the hardware dimension feature of the test task at that historical node; the similarity between the target feature vector corresponding to the application scenario dimension feature and the corresponding feature vector of the test task at that historical node is the same as the similarity between the target feature vector corresponding to the application scenario dimension feature and the feature vector corresponding to the application scenario dimension feature of the test task at that historical node; and so on.

[0049] The value of Sim ranges from [0, 1]. The closer the value is to 1, the more similar the node test task is to the historical test task.

[0050] The weighting coefficients can be dynamically adjusted based on the business focus and scenario requirements of node testing to improve the accuracy of similarity calculation. The core adjustment rules are as follows: Based on the initial weighting coefficients corresponding to each dimension feature, reduce the weighting coefficients corresponding to the least important dimension feature. For example, reduce the initial weighting coefficients by 0.1, so the initial weighting coefficients for each dimension feature can be 0.2; determine the sum of the weighting coefficients corresponding to the other dimension features besides the least important dimension feature; determine the initial weighting coefficients corresponding to the intermediate important dimension features; based on the sum of the weighting coefficients corresponding to the remaining dimension features and the sum of the weighting coefficients corresponding to the intermediate important dimension features, determine the sum of the weighting coefficients corresponding to the most important dimension feature; based on the sum of the weighting coefficients corresponding to the most important dimension feature, determine the weighting coefficient corresponding to each most important dimension feature.

[0051] For example: In a performance testing scenario, the most important features are the online operation features and the test target features; the intermediately important features are the hardware features; and the least important features are the application scenario features and the change features. The weighting coefficients for each feature could be: α=0.2, β=0.1, γ=0.3, δ=0.3, ε=0.1. In a hardware upgrade testing scenario, the most important features are the hardware features; the least important features are the application scenario features and the online operation features; and the intermediately important features are... The features are change dimension features and test target dimension features. The weight coefficients for each dimension feature can be: α=0.4, β=0.1, γ=0.1, δ=0.2, ε=0.2. For high availability test scenarios: the most important dimension features are application scenario dimension features, the intermediate important dimension features are online operation dimension features, and the least important dimension features are change dimension features, test target dimension features, and hardware dimension features. The weight coefficients for each dimension feature can be: α=0.1, β=0.5, γ=0.2, δ=0.1, ε=0.1.

[0052] In some alternative implementations, step b2 above includes: Step b21: Obtain multiple target dimension features of the test task of the historical node from the composite feature library. The multiple target dimension features include online operation dimension features, which include fault escape rate, fault occurrence frequency and fault transfer time.

[0053] Step b22: Based on the fault escape rate, fault occurrence frequency, and fault transfer time of the historical node test task, determine the online credit score of the node test strategy associated with the historical node test task.

[0054] Step b23: Based on the online credit score of the node testing strategy associated with the historical node testing task, determine the matching weight of the node testing strategy associated with the historical node testing task.

[0055] Understandably, the higher the online credit score, the higher the matching weight.

[0056] The task processing method provided in this application extracts the fault escape rate, fault occurrence frequency and fault transfer time from historical node test tasks, aggregates them to obtain the online credit score of the associated strategy, and maps it to the matching weight according to the monotonic relationship, so that the strategy-level matching weight has an interpretable source driven by production environment data.

[0057] In some alternative implementations, step b22 above includes: Step b221: Based on the correspondence table between different fault escape rates and the first fault score, and the fault escape rate of the historical node test task, determine the target first fault score of the node test strategy associated with the historical node test task, wherein the higher the fault escape rate, the higher the first fault score.

[0058] Step b222: Based on the correspondence table between different failure frequencies and the second failure score, and the failure frequency of the historical node test task, determine the target second failure score of the node test strategy associated with the historical node test task, wherein the higher the failure frequency, the higher the second failure score.

[0059] Step b223: Based on the correspondence table between different failover times and third fault scores, and the failover time of the historical node test task, determine the target third fault score of the node test strategy associated with the historical node test task. The longer the failover time, the higher the third fault score.

[0060] Step b224: Based on the target first fault score, target second fault score, and target third fault score, determine the online credit score of the node testing strategy associated with the historical node testing task.

[0061] It is understandable that the higher the target first failure score, target second failure score, and target third failure score, the lower the online credit score of the node testing strategy associated with that historical node testing task.

[0062] The task processing method provided in this application embodiment obtains the target first / second / third fault scores by looking up the fault escape rate, fault occurrence frequency and fault transfer time in a preset correspondence table, and obtains the inverse online credit score based on the aggregation of the three scores, thereby stably suppressing the recommendation probability of high similarity and low reliability strategies in the matching stage.

[0063] In some alternative implementations, step b3 above includes: Step b31: Based on the third formula, determine the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task. The third formula is: M = Sim × W Where M represents the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task, Sim represents the total similarity, and W represents the matching weight.

[0064] In some optional implementations, step S204 above includes: Step S2041: Sort the test tasks of multiple historical nodes in descending order of matching degree to obtain the sorting results.

[0065] Step S2042: Based on the sorting results, determine the node testing strategy associated with the historical node test task that ranks first as the optimal node testing strategy.

[0066] In some optional implementations, step S206 above includes: Step S2061: Based on the difference index, match the adjustment strategy from the rule base corresponding to the target dimension feature to which the difference index belongs.

[0067] Specifically, adjustment dimensions are determined based on the target dimension characteristics of the difference indicators, and adjustment strategies are matched from the corresponding rule base based on these adjustment dimensions. Adjustment dimensions include device model adaptation, scenario adaptation, target adaptation, and risk adaptation. For example, the matching of adjustment strategies from the corresponding rule base based on the adjustment dimensions can be shown in Table 1.

[0068] Table 1

[0069] Step S2062: Based on the adjustment strategy, adjust the optimal node testing strategy to generate the target node testing strategy.

[0070] The task processing method provided in this application obtains the adjustment strategy by looking up the corresponding rule base based on the target dimension features of the difference index, and generates the target node test strategy by adding, deleting and modifying based on the optimal node test strategy. This achieves differential customization of the historical strategy template: it retains the main structure of the historical strategy that has been verified to be effective in the production environment, and makes interpretable, auditable and dimension-isolated local adjustments based on the differences between the new task and the historical task in the specified dimension, avoiding the high cost and low reusability of designing from scratch.

[0071] In some optional implementations, step S2061 above includes: Step c1: If the difference indicator belongs to the hardware dimension feature and the difference indicator is at least one of node type, node form architecture, processor architecture, memory capacity, storage type and network configuration, determine the adjustment strategy as follows: add hardware compatibility test cases of the difference indicator of the node test task in the optimal node test strategy, and delete hardware compatibility test cases of the difference indicator of the target historical node test task.

[0072] Step c2: If the difference indicator belongs to the hardware dimension feature and the difference indicator is of the cluster type, determine the adjustment strategy as follows: add cluster failure simulation strategy test cases of the difference indicator of the node test task to the optimal node test strategy, and delete the cluster failure simulation test cases of the difference indicator of the target historical node test task.

[0073] Among these, the difference indicators belong to the hardware dimension, meaning the adjustment dimension is model compatibility. Hardware-level test case adjustments are performed based on the difference indicators: when the difference indicator is at least one of node type, node form factor architecture, processor architecture, memory capacity, storage type, and network configuration, corresponding hardware compatibility test cases are added or removed, such as adding specific network card driver tests or storage array adaptation tests. When the difference indicator is cluster type, cluster failure simulation test cases are adjusted according to the cluster type differences, such as adding test cases for blade node failures and fiber optic storage link interruptions.

[0074] In some optional implementations, step S2061 above includes: Step d1: When the difference indicator belongs to the application scenario dimension feature and the difference indicator is a business scenario, the adjustment strategy is determined as follows: based on the scenario type and business load characteristics of the difference indicator of the node test task, determine the test cases to be added, add the test cases to be added in the optimal node test strategy, and delete the test cases corresponding to the difference indicator of the target historical node test task.

[0075] Step d2: If the difference indicator belongs to the application scenario dimension feature and the difference indicator is the deployment mode, the adjustment strategy is determined as follows: add environment setup test cases and network configuration test cases for the difference indicators of the node test task in the optimal node test strategy, and delete the environment setup test cases and network configuration test cases corresponding to the difference indicators of the target historical node test task.

[0076] Among these, the difference indicators belong to the application scenario dimension, meaning the adjustment dimension is scenario adaptation. Application scenario-level test case adjustments are performed based on the difference indicators: When the difference indicators pertain to a business scenario, test cases for specific business scenarios are added based on the business scenario type (e.g., financial transactions, e-commerce, government cloud, etc.) and business load characteristics. For example, peak transaction failover test cases are added for financial transaction scenarios, and peak load test cases are added for e-commerce scenarios. When the difference indicators pertain to deployment modes, environment setup test cases and network configuration test cases are adjusted based on the deployment mode differences (e.g., private cloud, public cloud, hybrid cloud, physical machine).

[0077] In some optional implementations, step S2061 above includes: Step e1: When the difference metric belongs to the test target dimension feature, determine the adjustment strategy as follows: When the difference type of the difference metric is a performance threshold difference, update the test decision threshold and assertion condition of the corresponding test case in the optimal node test strategy based on the difference metric; when the difference type of the difference metric is that the node test task does not include the difference metric, delete the test cases corresponding to the difference metric of the target historical node test task in the optimal node test strategy; when the difference type of the difference metric is that the target historical node test task does not include the difference metric, add the test cases corresponding to the difference metric of the node test task in the optimal node test strategy; adjust the execution order and coverage depth of the test cases in the optimal node test strategy based on the priority of each metric in the test target dimension feature.

[0078] Among these, the difference metrics belong to the test target dimension features, meaning the adjusted dimension is adapted to the target. Test target-level test cases are adjusted based on the difference metrics: Test decision thresholds and assertion conditions are automatically updated according to test target requirements (e.g., failover time ≤ 3 seconds). The execution order and coverage depth of test cases in the optimal node test strategy are adjusted based on the priority of each metric in the test target dimension features. For example, test cases for corresponding metrics are executed in descending order of priority; for high-priority metrics, concurrency test cases and long-term stability test cases are added.

[0079] It is understandable that node test tasks do not include difference metrics, meaning that the values ​​of difference metrics in node test tasks are empty.

[0080] In some optional implementations, step S2061 above includes: Step f1: When the difference index belongs to the online operation dimension characteristics, the adjustment strategy is determined as follows: identify multiple historical node test tasks to be screened that are the same as the node types in the node test tasks; based on the online operation dimension characteristics of the multiple historical node test tasks to be screened, identify the target fault type whose failure frequency is higher than the preset frequency threshold; add test cases corresponding to the target fault type to the optimal node test strategy; and adjust the stress test cases in the optimal node test strategy based on the online resource utilization and peak load data in the online operation dimension characteristics of the multiple historical node test tasks to be screened.

[0081] Among them, the difference indicators belong to the online operation dimension characteristics, that is, the adjustment dimension is risk adaptation. Based on the difference indicators, risk-oriented test case adjustments are performed: according to the high-frequency failure types (such as network card failure, disk I / O bottleneck) in the online operation data of similar nodes, corresponding failure test cases are added to the optimal node test strategy to strengthen risk coverage; according to the online resource utilization and peak load data of similar nodes, stress test cases are adjusted, specifically, the concurrency parameters in the stress test cases are adjusted to ensure that the test intensity is close to the real operating environment.

[0082] It should be noted that after determining the optimal node testing strategy, the strategy can be adaptively adjusted according to the following process to generate the target node testing strategy: 1. Analyze feature differences: Compare multiple target feature vectors of the new node test task with multiple feature vectors of the target historical node test task associated with the optimal node test strategy in a dimension-by-dimensional manner to generate a list of difference indicators. For example, there are differences in the processor architecture indicators of multiple target feature vectors of the new node test task and multiple feature vectors of the target historical node test task. The processor architecture indicator of the new node test task is ARM architecture, while the processor architecture indicator of the target historical node test task is x86 architecture.

[0083] 2. Rule Base Matching and Calculation: Based on the list of difference indicators, the corresponding rule base is queried. For example, based on the processor architecture indicator, the hardware configuration mapping table is queried. The mapping table will return the adjustment strategy based on the processor architecture indicators of the new node test task and the processor architecture indicators of the target historical node test task.

[0084] 3. Execute test case operations: Based on the adjustment strategy, perform add, delete, and modify operations on the test case set in the optimal node testing strategy: 1) Add: Insert new use cases returned by the rule base.

[0085] 2) Delete: Remove old test cases from the optimal node test strategy that are not applicable to the new node test task.

[0086] 3) Modify: Update the specific parameter values ​​in the test case (such as assertion conditions, decision thresholds, etc.).

[0087] 4. Solution Integration and Output: The adjusted test case set is recombined to generate a complete and directly executable customized test solution.

[0088] In some optional implementations, the above task processing method further includes: Step g1: After the target node passes the test and goes online or is upgraded, obtain the target online running dimension characteristics of the target node.

[0089] Step g2: Based on the target node test task corresponding to the target node, the node test strategy corresponding to the target node test task, and the target online running dimension features, update the node test strategy library and the composite feature library.

[0090] It is understandable that the target node test task is a full test task that passes the test after being processed by the corresponding node test strategy before the target node goes online or after the upgrade.

[0091] The task processing method provided in this application obtains the actual online operation dimension characteristics of the target node after it has passed the test and been launched or upgraded, and updates the composite feature library and the node test strategy library synchronously based on the task, the strategy used and the online characteristics, so as to realize the continuous self-improvement of the composite feature library and the node test strategy library with production operation.

[0092] In some optional implementations, the above task processing method further includes: Step h1: Based on the matching degree, select multiple candidate node test strategies from the node test strategy library and push the multiple candidate node test strategies to the client.

[0093] Understandably, multiple historical node test tasks are sorted according to their matching degree from high to low to obtain the sorting results.

[0094] Based on the sorting results, the node testing strategies associated with the historical node test tasks ranked in the first preset position are determined as candidate node testing strategies.

[0095] Step h2, in response to the client's selection operation, determines the optimal node testing strategy.

[0096] The task processing method provided in this application sorts historical node test tasks based on matching degree and extracts the previously preset associated strategies as candidate push clients. Then, it determines the optimal node test strategy in response to the client's selection operation. This achieves human-machine collaborative decision-making, where "the system performs a rough screening based on similarity and online credit, and testers select the best strategy based on business context." While ensuring the quality and interpretability of the candidate set, it retains the human's right to decide the final strategy, balancing automation efficiency and controllability of key scenarios.

[0097] This application also provides a task processing method applied to a server. Figure 3 This is a flowchart illustrating the task processing method provided in the embodiments of this application, as shown below. Figure 3 As shown, the task processing method includes the following steps: Preliminary preparations: Integrate the historical test asset library and online running data of test tasks at various historical nodes, build a Python FastAPI backend service, deploy a MySQL database and a vector database, configure the initial weight coefficients of the similarity between the target feature vectors corresponding to different target dimensions and the corresponding feature vectors of historical node test tasks, and prepare data, environment and algorithms for the construction of the composite feature library and node test strategy library.

[0098] The online operational data for each historical node test task is collected by the node online data acquisition component. The core function of the node online data acquisition component is the real-time, full-volume collection and preliminary processing of node online operational data: by connecting to the node's operation and maintenance monitoring system, it collects online operational data such as node online resource utilization (CPU / memory / disk / network), peak load data, fault types and frequency of occurrence, performance bottlenecks, and business response time distribution, providing real and effective online data support for composite feature extraction and strategy adaptation.

[0099] The historical test asset repository is used to store a full range of historical test assets accumulated during long-term node testing, including node test tasks, test cases, node test strategies, test reports, test execution results, and defect analysis reports. This provides historical data support for the construction of the composite feature library and the node test strategy library.

[0100] Composite Feature Library Construction: Five dimensions of features for each node test task are defined. A composite feature extraction component extracts these five dimensions from the historical test asset library and online execution data of each historical node test task, performs standardization processing, and generates a unified format composite feature vector. The five dimensions of features and composite feature vectors for each historical node test task are stored in the composite feature library, and a feature index is established. The composite feature library is essentially a vector database.

[0101] The core functions of the composite feature extraction component are feature extraction, standardization processing, and composite feature vector generation. This component incorporates standardized feature extraction rules and quantization algorithms, supporting the automatic extraction of five dimensions of features from structured and unstructured data: hardware, application scenario, online operation, test objectives, and changes for node test tasks. It converts feature indicators of different formats and calibers into composite feature vectors with a unified format and quantization standard, providing a standardized data foundation for calculating matching degrees.

[0102] The core functions of the composite feature library are the storage, management, and rapid retrieval of five-dimensional features and composite feature vectors. It is used to store standardized composite feature vectors and detailed indicator information of each dimension feature, establish feature dimension indexes and keyword indexes, support rapid retrieval of composite feature vectors, real-time updates of feature information, and flexible expansion of new feature dimensions. It is the core data warehouse for calculating matching degree.

[0103] Node test strategy library construction: Each node test strategy is associated with a corresponding historical node test task. The content of the node test strategies is standardized and organized, and then stored in the node test strategy library. The node test strategy library is a MySQL database.

[0104] New task feature extraction: When a new node test task is input, the composite feature extraction component extracts five dimensions of features from the new node test task and performs standardization processing to generate a composite feature vector of the new node test task.

[0105] Optimal node test strategy matching: The matching engine retrieves the online running dimension features and composite feature vectors of historical node test tasks from the composite feature library. Based on the online running dimension features and composite feature vectors of historical node test tasks and the composite feature vectors of new node test tasks, the matching degree between historical node test tasks and new node test tasks is calculated. Based on the matching degree, the optimal node test strategy is selected from the node test strategy library.

[0106] The matching engine has a built-in weighted cosine similarity algorithm that supports dynamically adjusting the weight coefficients of each feature dimension based on the business focus and scenario requirements of the node test.

[0107] Adaptive Strategy Adjustment: The adaptive strategy adjustment component analyzes the differences between the new node test task and the target historical node test task in five dimensions, and performs differentiated customization and adjustment of the optimal node test strategy from four dimensions: device adaptation, scenario adaptation, target adaptation, and risk adaptation, generating a customized test plan that meets the requirements of the new node test task.

[0108] The strategy adaptive adjustment component has built-in adjustment rules in four dimensions: device model adaptation, scenario adaptation, target adaptation, and risk adaptation. By comparing and analyzing the composite characteristics of the new node test task and the target historical node test task, it automatically performs operations such as adding or deleting test cases, adjusting test parameters, optimizing execution strategies, and strengthening risk testing for the optimal node test strategy, generating customized test solutions that meet the personalized needs of the new node test task, greatly reducing the workload of manual adjustment.

[0109] Closed-loop feedback optimization: After a target node is launched or upgraded, based on the target node's corresponding test task, the node test strategy corresponding to the target node's test task, and the target online operational dimensional characteristics, the closed-loop feedback optimization component synchronizes these to the composite feature library and the node test strategy library, updating the matching weights of the node test strategies corresponding to the target node's test tasks. The weight coefficients are periodically retrained based on the full feedback data to achieve continuous iterative optimization of the entire testing system.

[0110] Furthermore, based on the fault escape rate, fault occurrence frequency, and fault type in the target online operation dimension features, the test coverage and missed test rate of the node test strategy corresponding to the target node test task can be calculated, and the test coverage and missed test rate can also be synchronized to the composite feature library as target online operation dimension features.

[0111] The task processing method provided in this application, by constructing a standardized composite feature library and an iterative node testing strategy library, achieves intelligent feature matching, strategy recommendation and adaptive adjustment for new testing tasks, solves the pain points of traditional testing strategy design, improves the quality and efficiency of node testing, and realizes the effective accumulation of testing knowledge and assets.

[0112] Through intelligent strategy matching and adaptive adjustment, testers do not need to design test plans from scratch. Customized test plans can be generated with only a small amount of manual confirmation. Actual verification has shown that the design time for node test plans can be shortened by more than 65%, which greatly shortens the test cycle and reduces labor costs.

[0113] By integrating historical successful testing experience and online risk data of similar nodes, the reliance on the experience of senior testers has been broken, and even novices can design test plans with high coverage and high targeting. The defect omission rate of node testing has been reduced by more than 40%, effectively reducing online fault escape.

[0114] By building a composite feature library and a node testing strategy library based on the historical test asset library, the system enables rapid retrieval, matching, and reuse of historical assets, solving the problem of knowledge asset waste. At the same time, it transforms the implicit experience of testers into explicit knowledge assets, avoiding knowledge loss caused by personnel turnover.

[0115] By incorporating the online operational characteristics of nodes into the core dimensions of composite characteristics, the design of testing strategies closely matches real-world scenarios such as business load, resource consumption, and failure risks after actual node deployment. This shifts the focus from "general testing" to "scenario-specific customized testing," significantly enhancing the reference value of test results for actual node operation.

[0116] Through a closed-loop feedback optimization mechanism, online operational data is continuously fed back into the composite feature library and node testing strategy library, enabling data updates, matching weight adjustments, and algorithm parameter retraining. As data accumulates, the accuracy of strategy matching and the scientific nature of the testing scheme will continuously improve, demonstrating a strong self-evolution capability.

[0117] By designing a five-dimensional composite feature system, we can achieve linked analysis of hardware, application scenarios, online operation, test objectives, and changes, avoiding the one-sidedness of single-dimensional testing, ensuring the integrity of testing across all dimensions such as node functionality, performance, and high availability, and adapting to the testing needs of multiple node types and scenarios.

[0118] The composite feature library and node testing strategy library support flexible expansion. New feature indicators and testing strategies can be added based on node technology iterations (such as new hardware architectures and new deployment modes) and industry scenario upgrades (such as new business loads), adapting to industry development trends such as cloud computing and big data, and applicable to the entire lifecycle of node R&D, testing, and operation and maintenance.

[0119] To make the task processing method of this application clearer, it is described in conjunction with a specific embodiment.

[0120] I. Scene Description A bank plans to upgrade its core business system's physical server cluster by building a dual-machine hot standby cluster using blade-based x86 servers. This cluster will be deployed on a private cloud and applied to the bank's core transaction scenarios (transfer / payment / clearing). The core objective of this test is to verify the cluster's high availability and disaster recovery capabilities. Specific test requirements are: cluster failover time ≤ 3 seconds, 100% disaster recovery data consistency, and a Service Level Agreement (SLA) availability of 99.999%. The core configuration of the cluster under test is 32 CPU cores / 128GB memory / fiber optic storage. Upgrading from a traditional rack-mount server cluster to a blade-based server cluster with the addition of fiber optic storage, the failover time requirement is to be reduced by 25% compared to the original cluster.

[0121] II. Implementation Process 1. Preliminary preparations Integrate test strategies, test cases, execution results, and other data from the historical high availability test asset library of the financial industry servers; collect online operation data (fault type, fault frequency, failover time, etc.) of the bank's core transaction server cluster; build a Python FastAPI backend service, deploy the database, and configure the initial weight parameters of the weighted cosine similarity algorithm according to the needs of the high availability test scenario: α=0.2, β=0.3, γ=0.2, δ=0.1, ε=0.2.

[0122] Build a composite feature library and a node testing strategy library.

[0123] 2. Composite Feature Extraction for New Test Tasks The five dimensions of features of the new test task were extracted and a composite feature vector was generated. The five dimensions of features include: blade physical server, x86 architecture, dual-machine hot standby cluster, core transaction scenario of financial industry, private cloud deployment, failover time ≤ 3 seconds, rack-mount to blade cluster upgrade, and new fiber optic storage architecture.

[0124] 3. Strategy Matching The matching engine calculates the matching degree between new test tasks and historical node test tasks based on the weight parameters of the high availability test scenario, and selects the optimal node test strategy based on the matching degree.

[0125] 4. Strategy Adaptive Adjustment and Solution Generation Based on the optimal node testing strategy, adaptive adjustments are made across four dimensions to address the characteristic differences between the new testing task and the target historical node testing task: (1) Model adaptation: In view of the hardware characteristics of blade clusters and fiber storage architecture, add fault simulation test cases such as blade server node failure, fiber storage link interruption, and cluster management node failure to adapt to the hardware architecture of the new cluster. (2) Scenario adaptation: Combine the application scenarios of core bank transactions, add fault transfer tests under peak transaction scenarios such as salary payment and holiday consumption, and fit the actual business scenarios of banks; (3) Target adaptation: According to the test index requirements, the test judgment threshold for cluster failover time was adjusted from the original 4 seconds to 3 seconds, and disaster recovery speed test and data consistency verification test points were added to match the index requirements of the new test task; (4) Risk adaptation: Based on the online operation data of core servers of similar banks, and in response to the high frequency of network failures, strengthen the high availability test of the cluster under network interruption, network latency and network jitter scenarios, and increase the simulation of network failures in multiple frequency and multiple scenarios.

[0126] Based on the above adjustments, the system automatically generates a customized high availability test plan for the blade server cluster, adds 10 fault simulation test cases unique to blade clusters, and improves the test content for peak transaction scenarios.

[0127] 5. Closed-loop feedback optimization After the test task was completed, an optimization point was found in the cluster failover script. After adjustment, the cluster failover time was shortened to 2.5 seconds, meeting the test requirements. The online operation data of the server cluster after going live (after experiencing one network card hardware failure, the cluster achieved seamless failover, core transactions were not interrupted, and there was no data loss) was fed back to the composite feature library, and the matching weight of the corresponding node test strategy was adjusted.

[0128] III. Effect Verification 1. Test design efficiency: Quickly complete the design of high availability test solutions without requiring testers to design from scratch, significantly reducing manual workload; 2. Test design quality: The customized test solution adds fault simulation test cases unique to blade clusters, which provides more comprehensive test scenario coverage, accurately identifies optimization points in the cluster failover script, and ensures test quality; 3. Online Application Results: After the blade server cluster went online, it successfully handled hardware failures, achieved seamless failover, ensured that core transaction services were not interrupted and no data was lost, met the SLA requirement of 99.999% availability, and guaranteed the continuity of the bank's core business.

[0129] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0130] Embodiments of this application also provide a task processing apparatus, such as... Figure 4 As shown, the task processing device includes: The receiving module 401 is used to receive node test tasks.

[0131] Extraction module 402 is used to extract multiple target dimension features from the node test task and convert each target dimension feature in the multiple target dimension features into a target feature vector.

[0132] The acquisition module 403 is used to acquire the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of each historical node test task in the composite feature library.

[0133] The filtering module 404 is used to filter the optimal node testing strategy from the node testing strategy library based on the matching degree.

[0134] The determination module 405 is used to compare multiple target feature vectors with multiple feature vectors of the target historical node test task associated with the optimal node test strategy, and determine the difference index between the node test task and the target historical node test task.

[0135] The adjustment module 406 is used to adjust the optimal node testing strategy based on the difference index and generate the target node testing strategy.

[0136] Processing module 407 is used to process node test tasks based on the target node test strategy.

[0137] In some alternative implementations, the acquisition module 403 includes: The first acquisition unit is used to acquire the similarity between each target feature vector in the multiple target feature vectors of any historical node test task in the composite feature library and the corresponding feature vector of the historical node test task.

[0138] The first determining unit is used to determine the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task based on similarity.

[0139] In some optional implementations, the first acquisition unit includes: The second determining unit is used to determine, for any historical node test task in the composite feature library, the similarity between the j-th target feature vector among multiple target feature vectors of the node test task and the corresponding feature vector of the historical node test task, based on the first formula:

[0140] in, Let be the similarity between the j-th target feature vector among multiple target feature vectors of the node testing task and the corresponding feature vector of the historical node testing task, where n is the number of indicator vectors included in the j-th target feature vector. Let i be the index vector in the j-th target feature vector. The indicator vector corresponding to the i-th indicator vector is the feature vector corresponding to the j-th target feature vector in the test task of this historical node.

[0141] In some optional implementations, the first determining unit includes: The third determining unit is used to determine the total similarity between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task based on similarity.

[0142] The second acquisition unit is used to acquire the matching weight of the node test strategy associated with the historical node test task.

[0143] The fourth determining unit is used to determine the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task based on the total similarity and matching weight.

[0144] In some optional implementations, the third determining unit includes: The fifth determining unit is used to determine the total similarity between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task, based on the second formula: Sim=α×Cos(Fm)+β×Cos(Fs)+γ×Cos(Fo)+δ×Cos(Ft)+ε×Cos(Fc) Where Sim is the total similarity, Cos(Fm) is the similarity between the target feature vector corresponding to the hardware dimension feature and the corresponding feature vector of the test task at the historical node, Cos(Fs) is the similarity between the target feature vector corresponding to the application scenario dimension feature and the corresponding feature vector of the test task at the historical node, Cos(Fo) is the similarity between the target feature vector corresponding to the online operation dimension feature and the corresponding feature vector of the test task at the historical node, Cos(Ft) is the similarity between the target feature vector corresponding to the test target dimension feature and the corresponding feature vector of the test task at the historical node, Cos(Fc) is the similarity between the target feature vector corresponding to the changed dimension feature and the corresponding feature vector of the test task at the historical node, α, β, γ, δ and ε are the weight coefficients of the similarity between the target feature vector corresponding to different target dimension features and the corresponding feature vector of the test task at the historical node, and α+β+γ+δ+ε=1.

[0145] In some optional implementations, the second acquisition unit includes: The third acquisition unit is used to acquire multiple target dimension features of the test task of the historical node from the composite feature library. The multiple target dimension features include online operation dimension features, which include fault escape rate, fault occurrence frequency and fault transfer time.

[0146] The sixth determining unit is used to determine the online credit score of the node testing strategy associated with the historical node testing task based on the fault escape rate, fault occurrence frequency and fault transfer time of the historical node testing task.

[0147] The seventh determining unit is used to determine the matching weight of the node testing strategy associated with the historical node testing task based on the online credit score of the node testing strategy associated with the historical node testing task.

[0148] In some optional implementations, the sixth determining unit includes: The eighth determining unit is used to determine the target first fault score of the node test strategy associated with the historical node test task based on the correspondence table between different fault escape rates and the first fault score and the fault escape rate of the historical node test task. The higher the fault escape rate, the higher the first fault score.

[0149] The ninth determining unit is used to determine the target second fault score of the node test strategy associated with the historical node test task based on the correspondence table between different fault occurrence frequencies and the second fault score and the fault occurrence frequency of the historical node test task, wherein the higher the fault occurrence frequency, the higher the second fault score.

[0150] The tenth determining unit is used to determine the target third fault score of the node test strategy associated with the historical node test task based on the correspondence table between different fault transfer times and the third fault score and the fault transfer time of the historical node test task. The longer the fault transfer time, the higher the third fault score.

[0151] The eleventh determining unit is used to determine the online credit score of the node testing strategy associated with the historical node testing task based on the target first fault score, the target second fault score, and the target third fault score.

[0152] In some optional implementations, the fourth determining unit includes: The twelfth determining unit is used to determine the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task based on the third formula, which is: M = Sim × W Where M represents the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task, Sim represents the total similarity, and W represents the matching weight.

[0153] In some alternative implementations, the filtering module 404 includes: The fourth acquisition unit is used to sort multiple historical node test tasks in descending order of matching degree to obtain the sorting results.

[0154] The thirteenth determining unit is used to determine the node testing strategy associated with the highest-ranked historical node test task as the optimal node testing strategy based on the ranking results.

[0155] In some alternative implementations, the adjustment module 406 includes: The matching unit is used to match adjustment strategies from the rule base corresponding to the target dimension features to which the difference index belongs, based on the difference index.

[0156] The generation unit is used to adjust the optimal node testing strategy based on the adjustment strategy and generate the target node testing strategy.

[0157] In some alternative implementations, the matching unit includes: The fourteenth determining unit is used to determine the adjustment strategy as follows when the difference indicator belongs to the hardware dimension feature and the difference indicator is at least one of node type, node form architecture, processor architecture, memory capacity, storage type and network configuration: add hardware compatibility test cases of the difference indicator of the node test task in the optimal node test strategy, and delete hardware compatibility test cases of the difference indicator of the target historical node test task.

[0158] The fifteenth determining unit is used to determine, when the difference index belongs to the hardware dimension feature and the difference index is a cluster type, the adjustment strategy is to add cluster failure simulation strategy test cases of the difference index of the node test task to the optimal node test strategy, and delete cluster failure simulation test cases of the difference index of the target historical node test task.

[0159] In some alternative implementations, the matching unit includes: The sixteenth determining unit is used to determine the adjustment strategy when the difference indicator belongs to the application scenario dimension feature and the difference indicator is a business scenario. The strategy is as follows: based on the scenario type and business load characteristics of the difference indicator of the node test task, determine the test cases to be added, add the test cases to be added in the optimal node test strategy, and delete the test cases corresponding to the difference indicator of the target historical node test task.

[0160] The seventeenth determining unit is used to determine the adjustment strategy when the difference indicator belongs to the application scenario dimension feature and the difference indicator is the deployment mode: add environment setup test cases and network configuration test cases for the difference indicators of the node test task in the optimal node test strategy, and delete the environment setup test cases and network configuration test cases corresponding to the difference indicators of the target historical node test task.

[0161] In some alternative implementations, the matching unit includes: The eighteenth determining unit is used to determine the adjustment strategy when the difference indicator belongs to the test target dimension feature: when the difference type of the difference indicator is a performance threshold difference, update the test judgment threshold and assertion condition of the corresponding test case in the optimal node test strategy based on the difference indicator; when the difference type of the difference indicator is that the node test task does not include the difference indicator, delete the test cases corresponding to the difference indicator of the target historical node test task in the optimal node test strategy; when the difference type of the difference indicator is that the target historical node test task does not include the difference indicator, add the test cases corresponding to the difference indicator of the node test task in the optimal node test strategy; and adjust the execution order and coverage depth of the test cases in the optimal node test strategy based on the priority of each indicator in the test target dimension feature.

[0162] In some alternative implementations, the matching unit includes: The nineteenth determining unit is used to determine the adjustment strategy when the difference index belongs to the online operation dimension characteristics. The strategy is as follows: determine multiple historical node test tasks to be screened that are the same as the node types in the node test tasks; determine the target fault type with a fault occurrence frequency higher than a preset frequency threshold based on the online operation dimension characteristics of the multiple historical node test tasks to be screened; add test cases corresponding to the target fault type to the optimal node test strategy; and adjust the stress test cases in the optimal node test strategy based on the online resource utilization and peak load data in the online operation dimension characteristics of the multiple historical node test tasks to be screened.

[0163] For a description of the features in the embodiment corresponding to the task processing device, please refer to the relevant description in the embodiment corresponding to the task processing method, which will not be repeated here.

[0164] Embodiments of this application also provide an electronic device, such as... Figure 5 As shown, it includes a processor 501 and a memory 502, in which a computer program is stored. The processor 501 is configured to run the computer program to perform the steps in any of the above-described task processing method embodiments.

[0165] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described task processing method embodiments at runtime.

[0166] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0167] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described task processing method embodiments.

[0168] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described task processing method embodiments.

[0169] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0170] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0171] The foregoing has provided a detailed description of a task processing method and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A task processing method, characterized in that, include: Receive node test tasks; Multiple target dimension features are extracted from the node test task, and each of the multiple target dimension features is converted into a target feature vector; the multiple target dimension features include: hardware dimension features, application scenario dimension features, online operation dimension features, test target dimension features, and change dimension features; Obtain the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of each historical node test task in the composite feature library; Based on the matching degree, the optimal node testing strategy is selected from the node testing strategy library; The multiple target feature vectors are compared with the multiple feature vectors of the target historical node test task associated with the optimal node test strategy to determine the difference index between the node test task and the target historical node test task. Based on the aforementioned difference indicators, the optimal node testing strategy is adjusted to generate the target node testing strategy. Based on the target node testing strategy, process the node testing task; The step of adjusting the optimal node testing strategy based on the difference index to generate the target node testing strategy includes: Based on the difference index, an adjustment strategy is matched from the rule base corresponding to the target dimension feature to which the difference index belongs; Based on the aforementioned adjustment strategy, the optimal node testing strategy is adjusted to generate the target node testing strategy.

2. The method according to claim 1, characterized in that, The step of obtaining the matching degree between the multiple target feature vectors of the node test task and the multiple feature vectors of each historical node test task in the composite feature library includes: For any historical node test task in the composite feature library, obtain the similarity between each target feature vector in the multiple target feature vectors of the node test task and the corresponding feature vector of the historical node test task; Based on the similarity, the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task is determined.

3. The method according to claim 2, characterized in that, Each of the target dimension features includes multiple indicators, and the target feature vector includes multiple indicator vectors; for any historical node test task in the composite feature library, obtaining the similarity between each target feature vector of the node test task and the corresponding feature vector of the historical node test task includes: For any historical node test task in the composite feature library, based on the first formula, the similarity between the j-th target feature vector among the multiple target feature vectors of the node test task and the corresponding feature vector of the historical node test task is determined. The first formula is: in, The similarity between the j-th target feature vector among the multiple target feature vectors of the node test task and the corresponding feature vector of the historical node test task, where n is the number of index vectors included in the j-th target feature vector. Let i be the index vector in the j-th target feature vector. The indicator vector corresponding to the i-th indicator vector is the feature vector corresponding to the j-th target feature vector in the test task of this historical node.

4. The method according to claim 2, characterized in that, The step of determining the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task based on the similarity includes: Based on the similarity, the total similarity between the multiple target feature vectors of the node test task and the multiple feature vectors of the historical node test task is determined. Obtain the matching weight of the node test strategy associated with the historical node test task; Based on the total similarity and the matching weight, the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task is determined.

5. The method according to claim 4, characterized in that, The step of determining the total similarity between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task based on the similarity includes: Based on the second formula, the total similarity between the multiple target feature vectors of the node test task and the multiple feature vectors of the historical node test task is determined. The second formula is: Sim=α×Cos(Fm)+β×Cos(Fs)+γ×Cos(Fo)+δ×Cos(Ft)+ε×Cos(Fc) Wherein, Sim is the total similarity, Cos(Fm) is the similarity between the target feature vector corresponding to the hardware dimension feature and the corresponding feature vector of the historical node test task, Cos(Fs) is the similarity between the target feature vector corresponding to the application scenario dimension feature and the corresponding feature vector of the historical node test task, Cos(Fo) is the similarity between the target feature vector corresponding to the online operation dimension feature and the corresponding feature vector of the historical node test task, Cos(Ft) is the similarity between the target feature vector corresponding to the test target dimension feature and the corresponding feature vector of the historical node test task, Cos(Fc) is the similarity between the target feature vector corresponding to the change dimension feature and the corresponding feature vector of the historical node test task, α, β, γ, δ and ε are the weighting coefficients of the similarity between the target feature vectors corresponding to different target dimension features and the corresponding feature vectors of the historical node test task, and α+β+γ+δ+ε=1.

6. The method according to claim 4, characterized in that, The step of obtaining the matching weight of the node testing strategy associated with the historical node testing task includes: Multiple target dimension features of the historical node test task are obtained from the composite feature library. The multiple target dimension features include online operation dimension features, which include fault escape rate, fault occurrence frequency and fault transfer time. Based on the fault escape rate, fault occurrence frequency, and fault transfer time of the historical node test task, determine the online credit score of the node test strategy associated with the historical node test task. Based on the online credit score of the node testing strategy associated with the historical node testing task, the matching weight of the node testing strategy associated with the historical node testing task is determined.

7. The method according to claim 6, characterized in that, The online credit score of the node testing strategy associated with the historical node testing task is determined based on the fault escape rate, fault occurrence frequency, and fault transition time of the historical node testing task, including: Based on the correspondence table between different fault escape rates and the first fault score, and the fault escape rate of the historical node test task, the target first fault score of the node test strategy associated with the historical node test task is determined, wherein the higher the fault escape rate, the higher the first fault score. Based on the correspondence table between different failure frequencies and second failure scores, and the failure frequency of the historical node test task, the target second failure score of the node test strategy associated with the historical node test task is determined, wherein the higher the failure frequency, the higher the second failure score. Based on the correspondence table between different failover times and third fault scores, and the failover time of the historical node test task, the target third fault score of the node test strategy associated with the historical node test task is determined. The longer the failover time, the higher the third fault score. Based on the target first fault score, target second fault score, and target third fault score, the online credit score of the node testing strategy associated with the historical node testing task is determined.

8. The method according to claim 4, characterized in that, The step of determining the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task based on the total similarity and the matching weight includes: Based on the third formula, the matching degree between multiple target feature vectors of the node test task and multiple feature vectors of the historical node test task is determined. The third formula is: M=Sim×W Where M is the matching degree between the multiple target feature vectors of the node test task and the multiple feature vectors of the historical node test task, Sim is the total similarity, and W is the matching weight.

9. The method according to claim 1, characterized in that, The step of selecting the optimal node testing strategy from the node testing strategy library based on the matching degree includes: The test tasks of the historical nodes are sorted in descending order of matching degree to obtain the sorting results; Based on the sorting results, the node testing strategy associated with the historical node test task that ranks first is determined as the optimal node testing strategy.

10. The method according to claim 1, characterized in that, The step of matching and adjusting strategies from the rule base corresponding to the target dimension feature to which the difference index belongs, based on the difference index, includes: If the difference indicator belongs to the hardware dimension feature, and the difference indicator is at least one of node type, node form factor architecture, processor architecture, memory capacity, storage type and network configuration, the adjustment strategy is to add hardware compatibility test cases of the difference indicator of the node test task to the optimal node test strategy, and delete hardware compatibility test cases of the difference indicator of the target historical node test task. If the difference indicator belongs to the hardware dimension feature and the difference indicator is a cluster type, the adjustment strategy is determined to be to add the cluster failure simulation strategy test case of the difference indicator of the node test task to the optimal node test strategy, and to delete the cluster failure simulation test case of the difference indicator of the target historical node test task.

11. The method according to claim 1, characterized in that, The step of matching and adjusting strategies from the rule base corresponding to the target dimension feature to which the difference index belongs, based on the difference index, includes: When the difference indicator belongs to the application scenario dimension feature and the difference indicator is a business scenario, the adjustment strategy is determined as follows: based on the scenario type and business load characteristics of the difference indicator of the node test task, determine the test cases to be added, add the test cases to be added to the optimal node test strategy, and delete the test cases corresponding to the difference indicator of the target historical node test task. When the difference indicator belongs to the application scenario dimension feature and the difference indicator is the deployment mode, the adjustment strategy is determined as follows: add environment setup test cases and network configuration test cases of the difference indicator of the node test task to the optimal node test strategy, and delete the environment setup test cases and network configuration test cases corresponding to the difference indicator of the target historical node test task.

12. The method according to claim 1, characterized in that, The step of matching and adjusting strategies from the rule base corresponding to the target dimension feature to which the difference index belongs, based on the difference index, includes: When the difference metric belongs to the test target dimension feature, the adjustment strategy is determined as follows: when the difference type of the difference metric is a performance threshold difference, based on the difference metric, update the test decision threshold and assertion condition of the corresponding test case in the optimal node test strategy; when the difference type of the difference metric is that the node test task does not include the difference metric, delete the test case corresponding to the difference metric of the target historical node test task in the optimal node test strategy; when the difference type of the difference metric is that the target historical node test task does not include the difference metric, add the test case corresponding to the difference metric of the node test task in the optimal node test strategy; based on the priority of each metric in the test target dimension feature, adjust the execution order and coverage depth of the test cases in the optimal node test strategy.

13. The method according to claim 1, characterized in that, The step of matching and adjusting strategies from the rule base corresponding to the target dimension feature to which the difference index belongs, based on the difference index, includes: When the difference indicator belongs to the online operation dimension feature, the adjustment strategy is determined as follows: identify multiple historical node test tasks to be screened that are the same as the node type in the node test task; based on the online operation dimension features of the multiple historical node test tasks to be screened, determine the target fault type whose fault occurrence frequency is higher than a preset frequency threshold; add test cases corresponding to the target fault type to the optimal node test strategy; and adjust the stress test cases in the optimal node test strategy based on the online resource utilization and peak load data in the online operation dimension features of the multiple historical node test tasks to be screened.

14. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the task processing method as described in any one of claims 1 to 13.

Images