Test task scheduling method and device, equipment, medium and program product

Abstract

This application provides a test task scheduling method applicable to the field of artificial intelligence, involving the application of large models in software testing scenarios. The method includes: using a large model to perform semantic parsing on the code files of the patch data to be tested, generating code module description text, and extracting entities from the modification description text of the patch data to obtain a set of key modification points; matching the code module description text with the set of key modification points through a bidirectional attention mechanism to verify the patch data to be tested; and dynamically scheduling test tasks based on historical time-consuming records and verified patch data, according to real-time acquired tester status and a knowledge graph; wherein the test tasks are obtained by splitting verified patch data based on the knowledge graph, and the knowledge graph is constructed based on historical patch data. This application also provides a test task scheduling device, equipment, storage medium, and program product.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, to the application of large models in software testing scenarios, and more specifically to a test task scheduling method, apparatus, device, medium, and program product. Background Technology

[0002] In the software development process, after testers submit defects, developers make modifications and submit patches (including modification descriptions and code files). The responsible person then breaks down the patches into several testing tasks and assigns them to different testers for testing and verification. Test task scheduling within software patches is a crucial step in the software development process, especially in the fintech sector. It connects development fixes with testing and verification, accelerates defect closure, and ensures business continuity and financial security during system iterations.

[0003] Currently, test task scheduling is typically achieved using traditional manual methods. However, this method relies on the responsible party manually breaking down test tasks within software patches based on modification instructions. This approach is time-consuming, labor-intensive, inefficient, and prone to issues such as unreasonable task allocation or omissions in test content. With the increasing adoption of agile development models, traditional manual methods can no longer meet the efficiency requirements of high-frequency iterations and cannot fully cover test tasks within software patches. Summary of the Invention

[0004] In view of the above problems, this application provides a test task scheduling method, apparatus, equipment, media and program products to improve the comprehensiveness of test task coverage.

[0005] According to a first aspect of this application, a test task scheduling method is provided, comprising: performing semantic parsing on the code file of the patch data to be tested using a large model to generate the code module description text, and extracting entities from the modification description text of the patch data to be tested to obtain the set of key modification points; matching the code module description text with the set of key modification points through a bidirectional attention mechanism to verify the patch data to be tested; and dynamically scheduling test tasks based on historical time consumption records and verified patch data to be tested, according to real-time acquired tester status and knowledge graph; wherein the test tasks are obtained by splitting the verified patch data to be tested based on the knowledge graph, and the knowledge graph is constructed based on historical patch data.

[0006] According to an embodiment of this application, the step of dynamically scheduling test tasks based on historical time-consuming records and verified patch data, and according to real-time acquired tester status and knowledge graph, includes: generating a list of patches to be scheduled based on the verified patch data; preprocessing the patches to be scheduled in the list of patches to be scheduled based on the multi-dimensional relationship edges of the knowledge graph and the historical time-consuming records, generating a test task splitting scheme, current urgency, and tester load coefficient for the patches to be scheduled, wherein the test task splitting scheme includes the test task and the tester; acquiring the tester status corresponding to the test task in real time, and scheduling the tester using a task scheduling matching strategy based on the tester status and the tester load coefficient, generating a personnel scheduling suggestion list; arranging the patches to be scheduled in the list of patches to be scheduled according to the current urgency and test deadline, and generating the test priority queue based on the arranged patches to be scheduled; and scheduling the test task based on the personnel scheduling suggestion list and the test priority queue.

[0007] According to an embodiment of this application, the historical time consumption record data includes the historical time consumption of similar tasks. The preprocessing of the pending patches in the pending patch list based on the multidimensional relationship edges of the knowledge graph and the historical time consumption record data, generating a test task splitting scheme, current urgency, and tester load coefficient for the pending patches, includes: splitting the pending patches in the pending patch list into tasks based on the multidimensional relationship edges of the knowledge graph, generating a test task splitting scheme corresponding to the pending patches; calculating the current urgency of the pending patches based on the test deadline of the pending patches and the historical time consumption of similar tasks; and real-time detection of the tester status, and calculating the tester load coefficient based on the tester status and the maximum load threshold.

[0008] According to an embodiment of this application, the personnel scheduling suggestion list includes a personnel scheduling list and / or a test personnel list. The task scheduling matching strategy includes: when the test personnel corresponding to the current test task are not on duty, matching available personnel corresponding to the current test task based on the technical testability of the current test task and the load coefficient of available personnel to generate a personnel scheduling list for the current test task; if there are no personnel in the personnel scheduling list for the current test task, updating the current urgency of the patch to be scheduled corresponding to the current test task, sorting the load coefficients of the available personnel, and filtering the available personnel corresponding to the current test task based on the sorted available personnel to generate a personnel scheduling list for the current test task; and when the test personnel corresponding to the current test task are on duty, generating a test personnel list for the current test task based on the test personnel corresponding to the current test task.

[0009] According to an embodiment of this application, the set of key modification points includes key modification points, and the code module description text includes code modules. The step of matching the code module description text with the set of key modification points using a bidirectional attention mechanism to verify the patch data under test includes: mapping the code module description text and the set of key modification points to a semantic space based on a bidirectional attention matching model, and calculating the matching degree of the key modification points in the code module description text to generate an overall matching value; marking the patch data under test as verified if the overall matching value is not lower than a preset threshold; and identifying unexpected changes to code modules and missing modification points based on the semantic space if the overall matching value is lower than the preset threshold, generating a difference report, and updating the patch data under test through a user interaction mechanism based on the difference report, iteratively verifying the updated patch data under test until the updated patch data under test is marked as verified.

[0010] According to an embodiment of this application, the step of identifying unexpectedly modified code modules and omitted modification points based on the semantic space to generate a difference report includes: identifying code modules not mapped in the set of key modification points based on the semantic space, and marking them as the unexpectedly modified code modules; locating key modification points not mapped in the code module description text based on the semantic space, and marking them as the omitted modification points; and generating the difference report based on the unexpectedly modified code modules and the omitted modification points.

[0011] According to an embodiment of this application, constructing the knowledge graph based on historical patch data includes: extracting patch task information based on the historical patch data; extracting graph nodes and multidimensional relationship edges of the patch task information through a multidimensional relationship extraction strategy; and constructing the knowledge graph based on the graph nodes and the multidimensional relationship edges.

[0012] According to an embodiment of this application, the graph nodes include patch nodes, task nodes, personnel nodes, and application nodes, and the multidimensional relationship edges include allocation relationship edges, inclusion relationship edges, task association edges, and belonging relationship edges. The step of extracting the graph nodes and multidimensional relationship edges of the patch task information using a multidimensional relationship extraction strategy includes: creating the patch node based on the patch task information, semantically analyzing the modification description information corresponding to the patch node, and generating historical test tasks; creating the task node based on the historical test tasks, and establishing inclusion relationship edges between the patch node and the task node; creating the personnel node based on a historical personnel allocation list, and establishing allocation relationship edges between the task node and the personnel node based on the historical test tasks; performing semantic clustering on the historical test task text of the task node, determining similar task nodes, and establishing task association edges between the similar task nodes; and establishing belonging relationship edges between the patch node and the application node based on application affiliation.

[0013] According to an embodiment of this application, the step of semantically clustering the historical test task text of the task node to determine the similar task nodes includes: processing the historical test task text of the task node using a pre-trained language model to generate the semantic vector of the task node; and calculating the vector similarity between the semantic vectors of each pair of task nodes, and determining the similar task nodes based on the vector similarity.

[0014] According to an embodiment of this application, the method further includes: calculating the completion rate of the patch data to be tested based on the real-time updated task completion status of the test task; statistically analyzing the task load of the testers to determine the progress delay status of the test task; identifying high-risk patches based on the completion rate of the patch data to be tested and the progress delay status of the test task, and issuing an early warning for the high-risk patches; and visualizing the multi-dimensional patch status data, wherein the multi-dimensional patch status data includes the completion rate, the task load, the progress delay status, and the high-risk patches.

[0015] A second aspect of this application provides a test task scheduling device, comprising: a large model processing unit, used to perform semantic parsing on the code file of the patch data to be tested using a large model, generate the code module description text, and extract entities from the modification description text of the patch data to be tested to obtain the set of key modification points; an attention mechanism unit, used to match the code module description text with the set of key modification points through a bidirectional attention mechanism to verify the patch data to be tested; and a dynamic scheduling unit, used to dynamically schedule test tasks based on historical time consumption records and verified patch data to be tested, according to real-time acquired tester status and knowledge graph; wherein the test tasks are obtained by splitting the verified patch data to be tested based on the knowledge graph, and the knowledge graph is constructed based on historical patch data.

[0016] According to an embodiment of this application, the apparatus further includes: a visualization unit, configured to calculate the completion rate of the patch data to be tested based on the real-time updated task completion status of the test task; to statistically analyze the task load of the testers and determine the progress delay status of the test task; to identify high-risk patches based on the completion rate of the patch data to be tested and the progress delay status of the test task, and to issue an early warning for the high-risk patches; and to visualize the multi-dimensional patch status data, wherein the multi-dimensional patch status data includes the completion rate, the task load, the progress delay status, and the high-risk patches.

[0017] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0018] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0019] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0020] In the embodiments of this application, a bidirectional attention mechanism and a large model are combined to automatically verify the patch data to be tested. Combined with historical time-consuming records and real-time tester status, test tasks are dynamically scheduled based on a knowledge graph. This improves the automation and intelligence of patch test task scheduling, reduces human error through automated processes, avoids duplication or omissions, ensures comprehensive coverage of test tasks, and improves the comprehensiveness of test task coverage. At the same time, dynamic scheduling of test tasks enables the rational allocation of resources, which improves efficiency and ultimately enhances the efficiency and quality of software testing. Attached Figure Description

[0021] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0022] Figure 1 The illustration shows an application scenario diagram of the test task scheduling method, apparatus, device, medium, and program product according to embodiments of this application;

[0023] Figure 2 A flowchart illustrating a test task scheduling method according to an embodiment of this application is shown schematically;

[0024] Figure 3 This illustration schematically shows a flowchart of the knowledge graph construction process for a test task scheduling method according to an embodiment of this application;

[0025] Figure 4 This illustration schematically shows a flowchart of a multidimensional relation extraction strategy for a test task scheduling method according to an embodiment of this application;

[0026] Figure 5 This illustration schematically shows a flowchart of the test patch verification process according to an embodiment of the test task scheduling method of this application;

[0027] Figure 6 This illustration schematically shows a flowchart of the dynamic scheduling of test tasks according to an embodiment of the present application;

[0028] Figure 7 This illustration schematically shows a patch status visualization flowchart of a test task scheduling method according to an embodiment of this application;

[0029] Figure 8 This illustration schematically shows another flowchart of a test task scheduling method according to an embodiment of the present application;

[0030] Figure 9 A schematic diagram illustrating the structure of a test task scheduling apparatus according to an embodiment of this application is shown; and

[0031] Figure 10A block diagram schematically illustrates an electronic device suitable for implementing a test task scheduling method according to an embodiment of this application. Detailed Implementation

[0032] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0033] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0034] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0035] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0036] In the fintech sector, inaccurate scheduling of software patch testing tasks can have serious consequences. If core module testing tasks are omitted, payment vulnerabilities and risk control logic failures may go undetected, directly causing financial losses. Disordered task priorities can delay the verification of emergency compliance patches, leading to penalties for violating regulatory requirements. Imbalanced resource allocation can prolong the testing cycle, slow down system repair progress, exacerbate the risk of business interruption, and even trigger a crisis of user trust, causing a chain reaction that impacts the reputation and operational stability of financial institutions.

[0037] Traditional patch test task scheduling relies on manual splitting of test tasks based on modification instructions, which has the following disadvantages: (1) Manual splitting is time-consuming and labor-intensive, especially when the number of patches is large, it is inefficient; (2) The splitting results depend on the subjective understanding of the person in charge, which may lead to unreasonable task division or omission of test content; (3) It cannot automatically verify the consistency between code files and modification instructions, which may lead to the submission of unexpected modifications and test omissions; (4) Test personnel status management relies on manual tracking, which makes it difficult to adjust the test schedule in time when personnel are on leave, affecting the progress of patch testing.

[0038] This application provides a test task scheduling method. It utilizes a large model to perform semantic parsing on the code files of the patch data to be tested, generating code module description text. It then extracts entities from the modification description text of the patch data to obtain a set of key modification points. A bidirectional attention mechanism is used to match the code module description text with the set of key modification points to verify the patch data to be tested. Based on historical time consumption records and verified patch data, test tasks are dynamically scheduled according to real-time acquired tester status and a knowledge graph. The test tasks are obtained by splitting verified patch data based on the knowledge graph, which is constructed based on historical patch data.

[0039] In the embodiments of this application, a bidirectional attention mechanism and a large model are combined to automatically verify the patch data to be tested. Combined with historical time-consuming records and real-time tester status, test tasks are dynamically scheduled based on a knowledge graph. This improves the automation and intelligence of patch test task scheduling, reduces human error through automated processes, avoids duplication or omissions, ensures comprehensive coverage of test tasks, and improves the comprehensiveness of test task coverage. At the same time, dynamic scheduling of test tasks enables the rational allocation of resources, which improves efficiency and ultimately enhances the efficiency and quality of software testing.

[0040] Figure 1 The illustration shows an application scenario diagram of the test task scheduling method, apparatus, device, medium, and program product according to embodiments of this application.

[0041] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0042] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0043] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0044] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0045] It should be noted that the test task scheduling method provided in this application embodiment can generally be executed by server 105. Correspondingly, the test task scheduling device provided in this application embodiment can generally be located in server 105. The test task scheduling method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the test task scheduling device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0046] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0047] The following will be based on Figure 1 The described scene, through Figures 2-8 The test task scheduling method according to the embodiments of this application will be described in detail.

[0048] Figure 2 A flowchart illustrating a test task scheduling method according to an embodiment of this application is shown.

[0049] like Figure 2 As shown, the test task scheduling method of this embodiment includes operations S210 to S230. This test task scheduling method does not limit the specific execution subject. The execution subject can be any electronic device, such as a terminal device or a server device, etc. The execution subject can also be any software application or client.

[0050] In the S210 operation, the large model is used to perform semantic parsing on the code file of the patch data to be tested, generate code module description text, and extract entities from the modification description text of the patch data to be tested to obtain a set of key modification points.

[0051] A large model is used to perform semantic parsing on the code files of the patch data under test, generating code module description text. The code module description text represents the functional description text of the code (a standardized description of the purpose, logic, and interface of the code module (or functional unit)). At the same time, the large model is used to extract entities from the modification description text of the patch data under test, and semantic modeling is used to form a set of key modification points.

[0052] Large models can employ pre-trained language models for programming language understanding and generation tasks. By pre-training on large-scale code corpora, they can understand code syntax, semantics, and contextual logic, and can be used for test-related tasks such as code completion, code translation, and vulnerability detection.

[0053] When operating the S220, a bidirectional attention mechanism is used to match the code module description text with the set of key modification points to verify the patch data to be tested.

[0054] By using a bidirectional attention mechanism to perform semantic matching between code and modification descriptions in patch data, consistency verification between code and modification descriptions is achieved, avoiding test omissions caused by unexpected code changes.

[0055] When operating the S230, test tasks are dynamically scheduled based on historical time-consuming records and verified patch data, according to the real-time acquired tester status and knowledge graph. The test tasks are obtained by splitting verified patch data based on the knowledge graph, which is constructed based on historical patch data.

[0056] Test tasks are obtained by splitting and verifying the patch data to be tested based on the knowledge graph, and the dynamic scheduling of test tasks is realized by combining the tester status and historical time records.

[0057] A structured patch testing knowledge graph is pre-built using historical patch data. This knowledge graph is reusable and provides a knowledge base to support automated patch data splitting. After a new patch test is completed, the knowledge graph is updated with incremental patch data. Historical patch data includes patch number information, application information, modification description records, test task splitting records, and personnel allocation records, among other historical information.

[0058] In the embodiments of this application, a bidirectional attention mechanism and a large model are combined to automatically verify the patch data to be tested. Combined with historical time-consuming records and real-time tester status, test tasks are dynamically scheduled based on a knowledge graph. This improves the automation and intelligence of patch test task scheduling, reduces human error through automated processes, avoids duplication or omissions, ensures comprehensive coverage of test tasks, and improves the comprehensiveness of test task coverage. At the same time, dynamic scheduling of test tasks enables the rational allocation of resources, which improves efficiency and ultimately enhances the efficiency and quality of software testing.

[0059] In the fintech field, software patch testing task scheduling is crucial. Accurate scheduling and allocation of testing tasks ensures precise allocation of testing resources, guaranteeing full coverage of patches for core modules such as payment and risk control, avoiding omissions of high-risk points, accelerating the verification of critical fixes through priority ranking, shortening system downtime, meeting the continuity requirements of financial services, and ensuring timely implementation of compliance patches, thus strengthening the defenses for fund security. Efficient software patch testing task scheduling ensures comprehensive testing, avoids duplication or omissions, rationally allocates resources to improve efficiency, quickly verifies the effectiveness of defect fixes, and guarantees patch quality and software stability.

[0060] Figure 3 A flowchart illustrating the knowledge graph construction process of the test task scheduling method according to an embodiment of this application is shown.

[0061] like Figure 3 As shown, the knowledge graph constructed based on historical patch data includes operations S310 to S330.

[0062] When operating S310, patch task information is extracted based on historical patch data.

[0063] Patch task information includes patch number, modification description, test task splitting records, and personnel allocation data.

[0064] When operating the S320, a multi-dimensional relationship extraction strategy is used to extract graph nodes and multi-dimensional relationship edges of patch task information.

[0065] By using a multidimensional relation extraction strategy, patch task information is abstracted into nodes and edges in a knowledge graph. For example, each patch corresponds to a node, and the task node of its test task generates child nodes through semantic segmentation. The association between the task and the tester is established based on the historical personnel allocation records.

[0066] When operating S330, a knowledge graph is constructed based on graph nodes and multidimensional relationship edges.

[0067] Based on the extracted graph nodes and multidimensional relation edges, the association relationships between each node and each edge are established to construct a knowledge graph with multidimensional relationships.

[0068] In the embodiments of this application, a knowledge graph for patch tasks is accurately constructed to enhance the correlation analysis capability and improve the accuracy of patch test task splitting.

[0069] Figure 4 A flowchart illustrating the multidimensional relation extraction strategy of the test task scheduling method according to an embodiment of this application is shown.

[0070] like Figure 4 As shown in the embodiments of this application, the graph nodes include patch nodes, task nodes, personnel nodes, and application nodes, and the multidimensional relationship edges include allocation relationship edges, inclusion relationship edges, task association edges, and belonging relationship edges. Operation S320, which extracts graph nodes and multidimensional relationship edges for patch task information using a multidimensional relationship extraction strategy, includes operations S410 to S450.

[0071] When operating S410, patch nodes are created based on patch task information, and the modification description information corresponding to the patch nodes is semantically analyzed to generate historical test tasks.

[0072] When initializing the knowledge graph G, the types of graph nodes are defined, including patch nodes, task nodes, personnel nodes, and application nodes. Each patch P in the historical patch data is traversed, and the patch number P is extracted. id Create a patch node P with the application it belongs to. node P node The attribute contains P id The modification instructions are applied and modified. Semantic segmentation and keyword extraction are performed on the modification instructions to generate n historical test tasks T1 to Tn, i∈1~n, where Ti represents the i-th historical test task.

[0073] When operating the S420, task nodes are created based on historical test tasks, and containment edges are established between patch nodes and task nodes.

[0074] For each historical test task Ti, identify the task type (technical test / business test) and create a task node Ti. nodeAnd mark the type attribute, and build P in the knowledge graph. node To Ti node The edges representing the "containment" relationship are labeled with the logical basis for splitting.

[0075] When operating S430, personnel nodes are created based on the historical personnel allocation list, and task nodes and personnel nodes are assigned to each other based on historical test tasks.

[0076] Extract the list of historically assigned testers and create a tester node Uj. node Establish Ti node To Uj node The "allocation" relationship edge.

[0077] In operation S440, the historical test task texts of the task nodes are semantically clustered to identify similar task nodes and establish task association edges between similar task nodes.

[0078] Semantic clustering is performed on the historical test task texts of all task nodes to identify similar task nodes. "Task" association edges are then established between these similar task nodes. This allows for the reuse of historical patterns when splitting new patches. Similar task nodes indicate that the nodes handle similar test tasks; establishing "task" association edges between similar task nodes establishes the relationships between similar test tasks.

[0079] According to an embodiment of this application, in operation S440, the historical test task text of the task node is semantically clustered to determine similar task nodes, including: processing the historical test task text of the task node using a pre-trained language model to generate semantic vectors of the task node; and calculating the vector similarity between the semantic vectors of each pair of task nodes, and determining similar task nodes based on the vector similarity.

[0080] A pre-trained language model is used to process historical test task text, generating semantic vectors for corresponding task nodes. Vector similarity between semantic vectors is calculated; when the vector similarity exceeds a preset similarity threshold, each pair of task nodes is considered similar. Calculated vector similarity metrics include cosine similarity and Pearson correlation coefficient. Cosine similarity calculates the cosine of the angle between two vectors, while Pearson correlation coefficient measures the degree of linear correlation between two vectors.

[0081] Preferably, the pre-trained language model can utilize the Bidirectional Encoder Representations from Transformers (BERT) model to learn deep semantic representations of text through "bidirectional pre-training." The training of the BERT model includes pre-training and fine-tuning. In pre-training, it can be trained on a large-scale unlabeled text corpus for general tasks, learning general rules and knowledge of language. In fine-tuning, for semantic vector extraction of text specific to the test task, a small amount of labeled data can be used to fine-tune the pre-trained model, quickly adapting it to the requirements of the test task. This pre-training combined with fine-tuning mode significantly reduces the dependence on the amount of labeled data and improves the model's performance in downstream tasks.

[0082] In the embodiments of this application, similar tasks are associated through semantic vectors to form a logical network between test tasks, which enhances interpretability, facilitates the rapid location of historical similar test tasks, reuses test tasks, and reduces repetitive tasks.

[0083] When operating S450, based on the application affiliation relationship, establish the affiliation edges between the patch node and the application node.

[0084] Application nodes are constructed based on the application to which the patch number belongs. Based on the application affiliation, "affiliation" edges are established between application nodes and patch nodes. The application affiliation includes the relationship between the patch number and the application to which it belongs. Application affiliation information for patches can be obtained via an API, ensuring the accuracy of the patch-application affiliation in the knowledge graph and laying the foundation for subsequent application-based management of test tasks.

[0085] In the embodiments of this application, the entire chain of application-patch-task-person in the knowledge graph is traced, similar tasks are intelligently associated, the reusability of test tasks is improved, and the intelligent management of patches is enhanced.

[0086] Figure 5 The flowchart illustrating the test patch verification process of the test task scheduling method according to an embodiment of this application is shown in the illustration.

[0087] like Figure 5 As shown, in operation S220, a bidirectional attention mechanism is used to match the code module description text with the set of key modification points to verify that the patch data to be tested includes operations S510 to S530.

[0088] When operating the S510, based on the bidirectional attention matching model, the code module description text and the set of key modification points are mapped to the semantic space, and the matching degree of the key modification points in the code module description text is calculated to generate the overall matching value.

[0089] By using a bidirectional attention matching model, the code module description text and the set of key modification points are mapped to the same semantic space. The matching degree of each key modification point in the modification description text is calculated in the code description, and an overall matching value is generated. The overall matching value represents the overall semantic matching degree index of the key modification points. The verification can be determined by whether the overall matching value is lower than a preset threshold.

[0090] When operating S520, if the overall matching value is not lower than the preset threshold, the patch data to be tested is marked as verified.

[0091] The patch data to be tested is verified based on the overall matching value. If the overall matching value is not lower than the preset threshold, it indicates that the patch data of the patch to be tested has passed the verification.

[0092] When operating S530, if the overall matching value is lower than the preset threshold, unexpected code modules and missing modification points are identified based on semantic space to generate a difference report. Based on the difference report, the patch data to be tested is updated through a user interaction mechanism. The updated patch data to be tested is iteratively verified until the updated patch data to be tested is marked as verified.

[0093] If the overall matching score is below a preset threshold, the system automatically identifies code modules not described in the modification notes (unexpected changes) and key modifications not implemented in the code (implementation omissions), and generates a difference report. Developers can resubmit patch data. The updated patch data includes code files and modification notes. The modification notes describe the changes within the patch data, and the code files represent the code content. The purpose of generating the difference report is to check for any unexpected code modules or key modifications that may have been omitted, leading to test omissions, ensuring the consistency between the patch code and the modification notes, and guaranteeing the accuracy of test tasks from the source. Based on the difference report, developers can resubmit the corresponding code files for the patch data according to the defect content, thus clarifying the modification notes.

[0094] It should be noted that the process of iteratively verifying and updating the patch data to be tested is the same as the process of verifying the patch data to be tested in operations S210 to S220, and will not be elaborated on here.

[0095] In the embodiments of this application, a bidirectional attention matching model is used to match and verify the code modules and key modification points in the patch data to be tested, ensuring the consistency between code changes and modification descriptions, avoiding test omissions caused by unexpected code, and preventing missed modification points.

[0096] According to an embodiment of this application, operation S530 identifies unexpectedly changed code modules and omitted modification points based on semantic space to generate a difference report, including: identifying code modules not mapped in the set of key modification points based on semantic space and marking them as unexpectedly changed code modules; locating key modification points not mapped in the code module description text based on semantic space and marking them as omitted modification points; and generating a difference report based on the unexpectedly changed code modules and omitted modification points.

[0097] When the overall matching value is below a preset threshold, a difference analysis is triggered. This identifies code modules not described in the code module description text but in the set of key modification points, marking them as "unexpectedly changed code modules." It also locates key modification points not reflected in the code module description text within the set of key modification points, marking them as "omitted modification points." Based on all unexpectedly changed code modules and omitted modification points, a difference report is generated. This report includes the mapping relationship between code lines in the code file and their textual descriptions in the modification description text.

[0098] In the embodiments of this application, the inconsistencies between the code and the modification instructions are automatically identified to ensure the consistency between the patch code and the modification instructions, thereby guaranteeing the accuracy of the testing task from the source and effectively reducing omissions and errors.

[0099] Figure 6 The diagram illustrates a flowchart of the dynamic scheduling of test tasks according to an embodiment of the present application.

[0100] like Figure 6 As shown, in operation S230, based on historical time-consuming data and verified patch data, and according to the real-time acquired tester status and knowledge graph, the test tasks are dynamically scheduled, including operations S610 to S650.

[0101] When operating S610, a list of patches to be scheduled is generated based on the verified patch data.

[0102] Each scheduled patch in the verified patch data is content submitted by developers based on test defects, including code files and modification descriptions. The patch number of each scheduled patch in the verified patch data is retrieved, and a scheduled patch list is generated, containing one or more scheduled patches.

[0103] When operating the S620, based on the multidimensional relationship edges and historical time-consuming records of the knowledge graph, the patches to be scheduled in the list of patches to be scheduled are preprocessed, and the test task splitting scheme, current urgency and tester load coefficient of the patches to be scheduled are generated. The test task splitting scheme includes test tasks and testers.

[0104] According to an embodiment of this application, the historical time consumption record data includes the historical time consumption of similar tasks. In operation S620, based on the multidimensional relationship edges of the knowledge graph and the historical time consumption record data, the patches to be scheduled in the list of patches to be scheduled are preprocessed to generate a test task splitting scheme, current urgency, and tester load coefficient for the patches to be scheduled. This includes the following steps:

[0105] First, based on the multidimensional relation edges of the knowledge graph, the scheduled patches in the list of scheduled patches are split into tasks to generate test task splitting schemes corresponding to the scheduled patches.

[0106] For each patch to be scheduled, the BERT model is used to semantically encode the modification description text of the patch, generating a feature vector. This feature vector is then compared with the modification description vectors of all patches belonging to the same application in the knowledge graph, and cosine similarity is calculated. K historical patches (K≥1) with similarity exceeding a preset threshold are selected to obtain historical patch nodes. These historical patch nodes are traversed using "containment" edges to extract all associated test task nodes. All test task node sets of the historical patch nodes are deduplicated and merged to generate a test task splitting scheme. Finally, using "assignment" edges, available testers corresponding to the test tasks are obtained, and these available testers are added to the test task splitting scheme.

[0107] Secondly, the current urgency of the patch to be scheduled is calculated based on the test deadline of the patch to be scheduled and the time taken for similar tasks in the past.

[0108] For each patch to be scheduled, calculate the remaining time based on the test deadline and the current date: Remaining time = Test deadline - Current date. Find the average time of similar tasks from the historical time table to obtain the historical time for similar tasks. Divide the remaining time by the historical time for similar tasks to get the current urgency. If the current urgency is less than 1, it can be marked as an urgent patch.

[0109] Finally, the tester's status is monitored in real time, and the tester's load coefficient is calculated based on the tester's status and the maximum load threshold.

[0110] Real-time monitoring of tester status allows for the creation of a personnel status table for tagging and viewing tester status. It detects testers' current work status, marking those on leave as absent or unavailable, and counts the number of incomplete tasks currently assigned to each tester. The load factor is calculated based on the number of incomplete tasks: Load Factor = Number of Incomplete Tasks / Maximum Load Threshold.

[0111] In the embodiments of this application, knowledge graph technology is used to automate the splitting of patch testing tasks, reducing the time cost of manual decomposition and improving task allocation efficiency.

[0112] When operating the S630, the status of the testers corresponding to the test tasks is obtained in real time. Based on the status of the testers and their load coefficients, the testers are scheduled using a task scheduling matching strategy, and a personnel scheduling suggestion list is generated.

[0113] According to embodiments of this application, the personnel scheduling suggestion list includes a personnel scheduling list and / or a test personnel list, and the task scheduling matching strategy in operation S630 includes the following strategies:

[0114] If the testers for the current test task are not in their current position, the available personnel for the current test task are matched based on the technical testability of the current test task and the load factor of the available personnel to generate a personnel scheduling list for the current test task.

[0115] If a tester is not currently on duty, for both technical and business testing tasks, available personnel with the corresponding qualifications and reasonable workloads will be selected. Available personnel are those currently on duty from the acquired tester status data.

[0116] If there are no personnel in the current test task's personnel scheduling list, update the current urgency of the patch to be scheduled for the current test task, sort the load coefficients of available personnel, and filter the available personnel corresponding to the current test task based on the sorted available personnel to generate the personnel scheduling list for the current test task.

[0117] If no available personnel can be matched with the technical testing and load factor, i.e. there are no personnel in the personnel scheduling list, it means that there are no available personnel for a certain type of testing task. The patch urgency will be automatically increased, and available personnel can be sorted in ascending order by load factor, and the top few suitable available personnel will be recommended.

[0118] If the testers for the current test task are in an on-duty status, generate a list of testers for the current test task based on the testers for the current test task.

[0119] For example, each test task in the test task splitting scheme will be processed as follows: When the tester status for a test task is detected as "offline," if the task is a technical test, the list of available personnel with technical qualifications and an individual workload coefficient below 0.8 will be automatically filtered; if it is a business test task, the list of available personnel with business qualifications and a workload coefficient below 0.8 will be filtered. If the list of available personnel for a test task is empty, the urgency of the patch to which the test task belongs will be increased (e.g., increased by 50%) and moved to the urgency queue; if available personnel exist, the top 3 personnel with the highest suitability will be recommended after sorting by workload coefficient in ascending order. When the tester status for a test task shows "online," the test task will be executed directly according to the established splitting scheme.

[0120] In the technical solution of this application, the information of the test personnel involved (including but not limited to personal information, image information, and equipment information such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) are all information and data authorized by the test personnel or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for personnel to choose to authorize or refuse.

[0121] In scenarios involving automated decision-making using personal information, the methods, devices, and systems provided in this application all offer testers corresponding entry points for choosing to agree to or reject the automated decision result. If the tester chooses to reject, the process proceeds to the expert decision-making stage. Here, "automated decision-making" refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests, or economic, health, and credit status through computer programs, and then making a decision. Here, "expert decision-making" refers to the activity of making decisions by personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0122] In the embodiments of this application, when testers for a certain test task are unavailable, available personnel with corresponding qualifications and reasonable workloads are selected for both technical and business test tasks. If no personnel are available for a certain test task, the urgency of the patch is automatically increased to ensure that critical test tasks are executed first and to avoid test omissions. By dynamically adjusting the urgency, resource allocation is optimized to ensure the quality and timeliness of the patch.

[0123] In operation S640, the patches to be scheduled are arranged in the list of patches to be scheduled according to their current urgency and test deadline, and a test priority queue is generated based on the arranged patches to be scheduled.

[0124] Based on the test deadline and the current date, the remaining time is determined, and a priority queue is generated according to urgency and remaining time. This ensures that urgent patches are allocated resources first, while avoiding personnel overload. When splitting patches based on a knowledge graph, the leave status of personnel can be checked simultaneously. If an urgent patch is encountered, the person in charge is notified to reschedule, ensuring test progress.

[0125] For example, patches are sorted in descending order of urgency, and those with the same urgency are sorted in ascending order of remaining time, generating an executable test priority queue.

[0126] When operating the S650, test tasks are scheduled based on the personnel scheduling suggestion list and the test priority queue.

[0127] In the embodiments of this application, a dynamic scheduling mechanism combining tester status and historical data is used to improve the testing response efficiency of emergency patches. Finally, a test priority queue is generated according to urgency and remaining time to ensure that emergency patches are allocated resources first, while avoiding personnel overload.

[0128] Figure 7 A schematic flowchart illustrating the patch status visualization of the test task scheduling method according to an embodiment of this application is shown.

[0129] like Figure 7 As shown, according to an embodiment of this application, the test task scheduling method further includes operations S710 to S740.

[0130] When operating the S710, the completion rate of the patch data to be tested is calculated based on the real-time updated task completion status of the test tasks.

[0131] In patch-level statistics, the completion status of each task is updated in real time and the completion rate is calculated based on the task list of the test task splitting scheme. Progress statistics on patch testing can be performed to obtain the corresponding test task list, calculate the completion status of each task (not started / in progress / completed), and calculate the overall completion rate of each patch test.

[0132] When operating the S720, the workload of testers is statistically analyzed to determine the progress delay status of test tasks.

[0133] In the personnel dimension statistics, the task load and progress delay of testers are statistically analyzed. For each tester, the progress of all tasks under their responsibility is statistically analyzed, and test tasks that exceed the expected time by a certain percentage are identified and marked as "progress delay".

[0134] When operating the S730, high-risk patches are identified based on the completion rate of the patch data to be tested and the progress delay status of the test task, and warnings are issued for high-risk patches.

[0135] In the priority dimension, based on the priority queue, the current processing stage of each patch is marked. High-risk patches with less than a certain threshold remaining time and a completion rate lower than a set value are triggered with an alert to help personnel quickly locate risk points.

[0136] When operating the S740, visualize multidimensional patch status data, which includes completion rate, task load, progress delay status, and high-risk patches.

[0137] The system aggregates multidimensional patch status data and presents it in a visual dashboard format, providing developers with a multidimensional view of test progress through timed data aggregation. The multidimensional patch status data includes patch dimensions (such as the application it belongs to, completion rate, remaining time, high-risk patches with warnings, etc.), personnel dimensions (such as task load, progress delay status), and priority dimensions (scheduling queue order), helping managers efficiently grasp the overall progress and adjust resource allocation.

[0138] In the embodiments of this application, the multi-dimensional test progress summary and the visualization of multi-dimensional patch status data provide managers with an intuitive management view, optimize the automation level of the software testing process as a whole, reduce human intervention errors, adapt to the high-frequency iteration requirements in the agile development environment, and provide an efficient management tool to ensure software quality.

[0139] Taking automated management systems as an example, Figure 8 This diagram schematically illustrates another flowchart of a test task scheduling method according to an embodiment of this application. The automated management system includes a patch test knowledge graph construction module, a code and modification description consistency verification module, a tester status scheduling and priority module, and a test progress dynamic summary module. Figure 8 As shown, the automated management system uses the knowledge graph of patch testing as its core hub, connecting four major modules: code consistency verification, personnel status scheduling, and test progress summary, forming an automated closed-loop management process of decomposition, verification, scheduling, and monitoring.

[0140] like Figure 8 As shown, the patch testing knowledge graph construction module aims to build a reusable knowledge graph using historical patch data, providing knowledge base support for automated patch splitting. This module abstracts patch task information from historical patch data into nodes and edges in the graph. It uses the BERT model to perform semantic clustering of task text within task nodes, establishing edges linking similar tasks. To facilitate the reuse of historical patterns when splitting new patches, this module obtains application information for each patch through an interface, ensuring the accuracy of the patch-application attribution relationship in the graph and maintaining this relationship, laying the foundation for subsequent application-based management of test tasks. Furthermore, the knowledge graph is incrementally updated after each patch test is completed.

[0141] like Figure 8As shown, the code-to-modification consistency verification module aims to achieve semantic matching between code and modification descriptions through a large model combined with a bidirectional attention mechanism, avoiding test omissions caused by unexpected code changes. For patch data, this module first uses large model technology to achieve semantic matching between code and modification descriptions, preventing test omissions due to unexpected code changes. The large model performs semantic parsing on the code file, generating functional description text, and simultaneously extracts entities from the modification descriptions, forming a set of key modification points. A bidirectional attention mechanism maps both to the same semantic space, calculates the matching degree, and determines whether the matching degree is tagged. If it meets the standard, the verification passes; if not, it automatically identifies modules in the code not described in the modification descriptions (unexpected changes) and points in the modification descriptions not implemented in the code (implementation omissions), generates a difference report, requires developers to resubmit patch data, and updates the knowledge graph based on the resubmitted patch. This module ensures the consistency between patch code and modification descriptions, guaranteeing the accuracy of testing tasks from the source.

[0142] like Figure 8 As shown, the tester status scheduling and priority module aims to dynamically schedule test tasks by combining tester status with historical data. This module generates test tasks based on a knowledge graph and a list of patches to be scheduled, calculates task urgency based on the test deadline and the historical latency of similar tasks, and simultaneously monitors tester status in real time, calculating load coefficients. If a tester is unavailable, for both technical testing and test tasks, qualified personnel with reasonable workloads are selected. If no personnel are available for a certain type of task, the patch urgency is automatically increased and added to the emergency queue. Finally, based on suitable personnel, a priority queue is generated according to urgency and remaining time, and test tasks are allocated accordingly, ensuring that urgent patches are given priority in resource allocation while avoiding personnel overload.

[0143] like Figure 8 As shown, the dynamic test progress summary module provides the responsible person with a multi-dimensional view of test progress by periodically aggregating data. After the progress summary is activated, the module statistically analyzes test progress and updates the completion status of each task in real time according to the task list in the test task breakdown plan, calculating the overall completion rate. It also tracks the task load and progress delays of testers. Based on the multi-dimensional patch status data, it determines whether an alert is needed. For patches with short remaining time and low completion rates, an alert is triggered to help the responsible person quickly locate risk points. Non-alert patches with aggregated multi-dimensional patch status data are presented in a visual dashboard format, and risk alerts are provided based on alert data, visual data, and task urgency, helping the responsible person efficiently grasp the overall progress and adjust resource allocation.

[0144] Based on the above-described test task scheduling method, this application also provides a test task scheduling apparatus. The following will be combined with... Figure 9 The device is described in detail.

[0145] Figure 9 A schematic block diagram of a test task scheduling apparatus according to an embodiment of this application is shown.

[0146] like Figure 9 As shown, the test task scheduling device 800 of this embodiment includes a large model processing unit 810, an attention mechanism unit 820, and a dynamic scheduling unit 830.

[0147] The large model processing unit 810 is used to perform semantic parsing on the code file of the patch data to be tested using a large model, generate code module description text, and extract entities from the modification description text of the patch data to obtain a set of key modification points. In one embodiment, the large model processing unit 810 can be used to perform the operation S210 described above, which will not be repeated here.

[0148] The attention mechanism unit 820 is used to match the code module description text with the set of key modification points through a bidirectional attention mechanism to verify the patch data to be tested. In one embodiment, the attention mechanism unit 820 can be used to perform the operation S220 described above, which will not be repeated here.

[0149] The dynamic scheduling unit 830 is used to dynamically schedule test tasks based on historical time-consuming records and verified patch data, according to the real-time acquired tester status and knowledge graph. The test tasks are obtained by splitting verified patch data from the knowledge graph, which is constructed based on historical patch data. In one embodiment, the dynamic scheduling unit 830 can be used to execute the operation S230 described above, which will not be repeated here.

[0150] According to an embodiment of this application, the aforementioned device 800 further includes a visualization unit, configured to calculate the completion rate of the patch data to be tested based on the real-time updated task completion status of the test task; statistically analyze the task load of the testers and determine the progress delay status of the test task; identify high-risk patches based on the completion rate of the patch data to be tested and the progress delay status of the test task, and issue an early warning for high-risk patches; and visualize multi-dimensional patch status data, wherein the multi-dimensional patch status data includes completion rate, task load, progress delay status, and high-risk patches. In one embodiment, the visualization unit may be used to perform the operations S710~S740 described above, which will not be repeated here.

[0151] According to embodiments of this application, any multiple units among the large model processing unit 810, attention mechanism unit 820, dynamic scheduling unit 830, and visualization unit can be combined into one unit, or any one of these units can be split into multiple units. Alternatively, at least some of the functionality of one or more of these units can be combined with at least some of the functionality of other units and implemented in one unit. According to embodiments of this application, at least one of the large model processing unit 810, attention mechanism unit 820, dynamic scheduling unit 830, and visualization unit can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the large model processing unit 810, attention mechanism unit 820, dynamic scheduling unit 830, and visualization unit can be at least partially implemented as a computer program unit that can perform corresponding functions when the computer program unit is run.

[0152] Figure 10 A block diagram schematically illustrates an electronic device suitable for implementing a test task scheduling method according to an embodiment of this application.

[0153] like Figure 10 As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0154] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 902 and / or RAM 903. It should be noted that programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0155] According to embodiments of this application, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0156] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0157] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0158] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the test task scheduling method provided in the embodiments of this application.

[0159] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0160] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0161] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0162] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0163] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0164] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A test task scheduling method, characterized in that, The method includes: A large model is used to perform semantic parsing on the code file of the patch data to be tested, generating the code module description text, and entity extraction is performed on the modification description text of the patch data to be tested to obtain the set of key modification points. The code module description text is matched with the set of key modification points through a bidirectional attention mechanism to verify the patch data to be tested. Based on historical time consumption records and verified patch data, test tasks are dynamically scheduled according to real-time acquired tester status and knowledge graph. The test tasks are obtained by splitting the verified patch data based on the knowledge graph, which is constructed based on historical patch data.

2. The method according to claim 1, characterized in that, The test tasks are dynamically scheduled based on historical time-consuming records and verified patch data, according to the real-time acquired tester status and knowledge graph, including: Based on the verified patch data, a list of patches to be scheduled is generated. Based on the multidimensional relation edges of the knowledge graph and the historical time consumption record data, the patches to be scheduled in the list of patches to be scheduled are preprocessed to generate a test task splitting scheme, current urgency and load coefficient of the testers for the patches to be scheduled. The test task splitting scheme includes the test tasks and the testers. The status of the testers corresponding to the test tasks is obtained in real time, and the testers are scheduled using a task scheduling matching strategy based on the status of the testers and the load coefficient of the testers, generating a personnel scheduling suggestion list. Based on the current urgency and test deadline of the patches to be scheduled, the patches in the list of patches to be scheduled are arranged in order, and the test priority queue is generated based on the arranged patches; and The test tasks are scheduled based on the personnel scheduling suggestion list and the test priority queue.

3. The method according to claim 2, characterized in that, in, The historical time consumption records include the historical time consumption of similar tasks. Based on the multidimensional relationship edges of the knowledge graph and the historical time consumption records, the system preprocesses the patches to be scheduled in the list of patches to be scheduled, generating a test task splitting scheme, current urgency, and tester load coefficient for the patches to be scheduled, including: Based on the multidimensional relation edges of the knowledge graph, the scheduled patches in the list of scheduled patches are split into tasks to generate test task splitting schemes corresponding to the scheduled patches. Calculate the current urgency of the patch to be scheduled based on its test deadline and the historical time taken for similar tasks; and The tester's status is monitored in real time, and the load coefficient of the tester is calculated based on the tester's status and the maximum load threshold.

4. The method according to claim 2, characterized in that, in, The personnel scheduling suggestion list includes a personnel scheduling list and / or a test personnel list, and the task scheduling matching strategy includes: If the testers for the current test task are not in their current position, the available personnel for the current test task are matched based on the technical testability of the current test task and the load factor of the available personnel to generate a personnel scheduling list for the current test task. If there are no personnel in the current test task's personnel scheduling list, then update the current urgency of the patch to be scheduled corresponding to the current test task, sort the load coefficients of the available personnel, and filter the available personnel corresponding to the current test task according to the sorted available personnel to generate the personnel scheduling list for the current test task; and If the tester's status for the current test task is "on duty", a list of testers for the current test task is generated based on the testers for the current test task.

5. The method according to claim 1, characterized in that, in, The set of key modification points includes key modification points, and the code module description text includes code modules; the step of matching the code module description text with the set of key modification points through a bidirectional attention mechanism to verify the patch data to be tested includes: Based on the bidirectional attention matching model, the code module description text and the set of key modification points are mapped to the semantic space, and the matching degree of the key modification points in the code module description text is calculated to generate an overall matching value. If the overall matching value is not lower than a preset threshold, the patch data to be tested is marked as verified; and If the overall matching value is lower than a preset threshold, unexpected code modules and omissions in modification are identified based on the semantic space to generate a difference report. Based on the difference report, the patch data to be tested is updated through a user interaction mechanism. The updated patch data to be tested is iteratively verified until the updated patch data to be tested is marked as verified.

6. The method according to claim 5, characterized in that, The step of identifying unexpectedly changed code modules and missed modification points based on the semantic space to generate a difference report includes: Based on the semantic space, identify code modules that are not mapped in the set of key modification points and mark them as the unexpectedly changed code modules; Based on the semantic space, key modification points not mapped in the code module description text are located and marked as the omitted modification points; and The difference report is generated based on the unexpectedly changed code modules and the omitted modification points.

7. The method according to claim 1, characterized in that, The knowledge graph constructed based on historical patch data includes: Extract patch task information based on the historical patch data; The graph nodes and multidimensional relationship edges of the patch task information are extracted using a multidimensional relationship extraction strategy; and The knowledge graph is constructed based on the graph nodes and the multidimensional relationship edges.

8. The method according to claim 7, characterized in that, in, The graph nodes include patch nodes, task nodes, personnel nodes, and application nodes, and the multidimensional relationship edges include allocation relationship edges, inclusion relationship edges, task association edges, and belonging relationship edges; The step of extracting graph nodes and multidimensional relationship edges of the patch task information using a multidimensional relationship extraction strategy includes: Based on the patch task information, the patch node is created, and the modification description information corresponding to the patch node is semantically analyzed to generate historical test tasks; The task node is created based on the historical test task, and an inclusion relationship edge is established between the patch node and the task node; The personnel node is created based on the historical personnel allocation list, and the allocation relationship edge between the task node and the personnel node is established based on the historical test tasks; Semantic clustering is performed on the historical test task texts of the task nodes to identify similar task nodes, and task association edges are established between the similar task nodes; and Based on the application affiliation relationship, establish the affiliation edge between the patch node and the application node.

9. The method according to claim 8, characterized in that, The step of semantically clustering the historical test task texts of the task nodes to determine the similar task nodes includes: The historical test task text of the task node is processed using a pre-trained language model to generate a semantic vector for the task node; and Calculate the vector similarity between the semantic vectors of each pair of task nodes, and determine the similar task nodes based on the vector similarity.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: The completion rate of the patch data under test is calculated based on the real-time updated task completion status. The task load of the testers is statistically analyzed to determine the progress delay status of the test tasks; Based on the completion rate of the patch data to be tested and the progress delay status of the test task, high-risk patches are identified, and warnings are issued for these high-risk patches; and Visualize the multidimensional patch status data, which includes the completion rate, the task load, the progress delay status, and the high-risk patches.

11. A test task scheduling device, characterized in that, The device includes: The large model processing unit is used to perform semantic parsing on the code file of the patch data to be tested using the large model, generate the code module description text, and extract entities from the modification description text of the patch data to be tested to obtain the set of key modification points. An attention mechanism unit is used to match the code module description text with the set of key modification points through a bidirectional attention mechanism to verify the patch data to be tested; and A dynamic scheduling unit is used to dynamically schedule test tasks based on historical time-consuming records and verified patch data, according to the real-time acquired tester status and knowledge graph; wherein, the test task is obtained by splitting the verified patch data based on the knowledge graph, and the knowledge graph is constructed based on historical patch data.

12. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 10.

Images