Implementation method and device of testing process, computer equipment, readable storage medium and program product

Abstract

The invention relates to an implementation method and device of a test submission process, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: defining a data unit, and generating a structured test case; establishing an association index among the function demand unit or the task execution unit, the test case and the defect recording unit; configuring a state node sequence for the function demand unit, the task execution unit and the defect recording unit through a state circulation rule engine; creating a test submission management data set, associating the test submission data units meeting the test submission conditions to the test submission management data set, and transferring the state nodes of the test submission data units from the development to the to-be-submitted test; and obtaining and verifying the structured test submission information of the test submission data unit in the to-be-tested state, transferring the state node of the test submission data unit to the test from the to-be-tested state after the verification is passed, and pushing a test task notification to the test end. By adopting the method, the normativity and the testing efficiency of the testing process can be improved.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for implementing a testing process. Background Technology

[0002] With the continuous development of agile software, short-cycle iterative methods are typically used for product development and delivery. Common iterations include development, testing, testing and deployment phases. Testing, as a key link between the development and testing phases, directly affects the delivery quality and speed of the software product due to the standardization and efficiency of its process.

[0003] In traditional technologies, on the one hand, we try to manage the testing process by formulating testing specifications, including requiring developers to complete code development, pass P0 test cases, and fill in the scope of change impact before testing; on the other hand, we establish a two-way feedback mechanism between development and testing by introducing test point reviews and daily stand-up meetings.

[0004] However, the current testing specifications rely heavily on manual supervision, making them difficult to implement effectively and track continuously. Furthermore, the established two-way feedback mechanisms often lack system-level support, resulting in limited collaboration between development and testing. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can systematically manage the testing process and achieve efficient collaboration and quality control between the development and testing phases, in order to address the above-mentioned technical problems.

[0006] Firstly, this application provides a method for implementing a testing process, including:

[0007] Define data units, which include functional requirement units that describe the required functions, task execution units that carry out the minimum development tasks, and defect record units that record software defects.

[0008] Based on the acceptance criteria fields of functional requirement units or task execution units, generate structured test cases containing operation steps and expected results; establish an association index between functional requirement units, test cases and defect record units, or between task execution units, test cases and defect record units through a unique identifier mapping mechanism;

[0009] The state transition rule engine, built on a directed acyclic graph, configures a sequence of state nodes consisting of pending, under development, pending testing, under testing, and completed for functional requirement units and task execution units, and a sequence of state nodes consisting of new, open, under repair, pending verification, closed, and rejected for defect recording units. Each state node is assigned a unique state identifier. The state transition rule engine verifies the preconditions for state transition through pre-verification logic and executes the automated operation after the state transition through post-trigger logic.

[0010] Create a test management dataset for each agile iteration cycle and assign a unique test set identifier; define a single functional requirement unit or task execution unit as the smallest test data unit; monitor the attribute status of the test data unit in real time, and when the test conditions are met, associate the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and trigger the state transition rule engine to transition the state node of the corresponding test data unit from development to pending test.

[0011] For test data units in the pending test status, structured test information is obtained from the attributes of associated functional requirement units or task execution units through a data synchronization interface. Based on the pre-verification logic of the state transition rule engine, test admission verification is completed for the integrity verification of test information, code branch compliance verification, and unit test coverage verification. After the verification is passed, based on the post-trigger logic, the state node of the test data unit is transitioned from pending test to test, and a test task notification is pushed to the test end. The structured test information includes test environment configuration and the scope of impact of changes.

[0012] In one embodiment, the process of the test terminal performing the test includes:

[0013] Tests are executed based on associated structured test cases. If a test case fails, a defect record unit is automatically generated through the associated index and assigned to the responsible development user. The state transition of the defect record unit is managed by the state transition rule engine and the role and permission control model.

[0014] When the status of the defect recording unit changes, relevant messages are pushed to the relevant responsible users based on the post-trigger logic.

[0015] In one embodiment, the method further includes:

[0016] Through the state transition rule engine, the number of data units, the severity level of defect record units, and the execution results of structured test cases of each state node are collected in real time and synchronized to the test management dataset.

[0017] Based on the data from the test submission management dataset, a visual monitoring view containing the distribution of data unit status and defect level is generated, and defect density, defect repair cycle, and first-time test pass rate are calculated to generate a structured test report.

[0018] In one embodiment, a unique identifier mapping mechanism is used to establish an association index between functional requirement units, test cases, and defect record units, or between task execution units, test cases, and defect record units, including:

[0019] Assign a unique unit identifier to the functional requirement unit and the task execution unit; assign a unique test case identifier to the test case; assign a unique defect identifier to the defect record unit.

[0020] Establish a mapping table between unit identifiers and test case identifiers to store the association between functional requirement units and test cases, or the association between task execution units and test cases. The fields of the mapping table include unit identifier, test case identifier, and acceptance criterion identifier.

[0021] When a defect record unit is generated, the test case identifier of the failed test case is read, the corresponding unit identifier is matched through the mapping table, and the unit identifier, test case identifier, and failure step sequence number are written into the associated information field of the defect record unit to form a complete traceability link.

[0022] In one embodiment, when the testing conditions are met, the corresponding testing data unit is associated with the testing management dataset of the current iteration through a unique unit identifier, including:

[0023] During the initialization phase of the agile iteration cycle, a test management dataset is created, and the test set identifier, iteration cycle, associated unit list, and unit status distribution are configured.

[0024] Real-time monitoring of the status of functional requirement units or task execution units; when the status changes to completed, P0 test cases pass self-testing and code review passes, it is determined that the conditions for submitting for testing are met.

[0025] Query the list of associated units in the test management dataset. If the unique identifier of the corresponding test data unit is not included, add the corresponding unique identifier to the list of associated units. Based on the pre-verification logic of the state transition rule engine, update the state of the corresponding test data unit to "pending test" and synchronously update the number of units in the "pending test" state in the unit state distribution.

[0026] In one embodiment, the method further includes:

[0027] For test data units that fail verification, they are modified and re-verified. If the number of failures reaches a preset number, the corresponding test data units are removed from the test management dataset and their status is marked as pending optimization.

[0028] For defect record units with a status of "rejected", trigger the dispute coordination process;

[0029] If a structured test case is blocked due to an environmental anomaly, the status of the corresponding test data unit will be updated to "Test Blocked" and a notification will be sent to the operations and maintenance team. After the operations and maintenance team repairs the environment, the status of the corresponding test data unit will be updated to "Testing" and the blocking duration will be recorded.

[0030] Secondly, this application also provides an apparatus for implementing the testing process, comprising:

[0031] The definition module is used to define data units, which include functional requirement units that describe the required functions, task execution units that carry out the minimum development tasks, and defect record units that record software defects.

[0032] The generation module is used to generate structured test cases containing operation steps and expected results based on the acceptance criterion fields of functional requirement units or task execution units; and to establish association indexes between functional requirement units, test cases and defect record units, or between task execution units, test cases and defect record units, through a unique identifier mapping mechanism.

[0033] The configuration module is used to configure a state transition rule engine based on a directed acyclic graph to configure a sequence of state nodes consisting of pending, under development, pending testing, under testing, and completed for functional requirement units and task execution units, and a sequence of state nodes consisting of new, open, under repair, pending verification, closed, and rejected for defect recording units. Each state node is assigned a unique state identifier. The state transition rule engine verifies the preconditions for state transition through pre-verification logic and executes the automated operation after the state transition through post-trigger logic.

[0034] Create a module to create a test management dataset for each agile iteration cycle and assign a unique test set identifier; define a single functional requirement unit or task execution unit as the smallest test data unit; monitor the attribute status of the test data unit in real time, and when the test conditions are met, associate the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and trigger the state transition rule engine to transition the state node of the corresponding test data unit from development to pending test.

[0035] The acquisition module is used to obtain structured test information from the attributes of associated functional requirement units or task execution units through a data synchronization interface for test data units in the pending test status. Based on the pre-verification logic of the state transition rule engine, it completes the test admission verification of test information integrity, code branch compliance, and unit test coverage. After the verification is passed, based on the post-trigger logic, the state node of the test data unit is transferred from pending test to test, and a test task notification is pushed to the test end. The structured test information includes test environment configuration and the scope of impact of changes.

[0036] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method in any of the above embodiments.

[0037] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the methods in any of the above embodiments.

[0038] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods in any of the above embodiments.

[0039] The above-described testing process implementation method, apparatus, computer equipment, computer-readable storage medium, and computer program product define data units, including functional requirement units describing the required functions, task execution units carrying the minimum development tasks, and defect record units recording software defects; based on the acceptance criterion fields of the functional requirement units or task execution units, structured test cases containing operation steps and expected results are generated; through a unique identifier mapping mechanism, an association index is established between functional requirement units, test cases, and defect record units, or between task execution units, test cases, and defect record units; through a state transition rule engine based on a directed acyclic graph, a sequence of state nodes consisting of pending, developing, pending testing, testing, and completed is configured for functional requirement units and task execution units, and a sequence of state nodes consisting of newly created, open, repairing, pending verification, closed, and rejected is configured for defect record units; each state node is assigned a unique state identifier, and the state transition rule engine verifies the preconditions for state transition through pre-verification logic and through post-triggering... The system implements automated operations after the logical execution state transition; creates a test management dataset for each agile iteration cycle and assigns a unique test set identifier; defines a single functional requirement unit or task execution unit as the smallest test data unit; monitors the attribute status of test data units in real time, and when the test conditions are met, associates the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and triggers the state transition rule engine to transfer the state node of the corresponding test data unit from "under development" to "pending test"; for test data units in the "pending test" state, it obtains structured test information from the attributes of the associated functional requirement unit or task execution unit through the data synchronization interface; based on the pre-verification logic of the state transition rule engine, it completes the test admission verification of test information integrity, code branch compliance, and unit test coverage; after the verification passes, based on the post-trigger logic, it transfers the state node of the test data unit from "pending test" to "under test" and pushes test task notifications to the test end; the structured test information includes test environment configuration and the scope of impact of changes. By establishing an association index between functional requirement units or task execution units, test cases, and defect record units, defect record units can be directly created and associated with the failed steps of test cases, thus ensuring rapid and accurate location of problem sources. A state transition rule engine based on a directed acyclic graph (DAG) ensures the standardization and authenticity of the process by managing the state transitions of each unit. Furthermore, by creating a test submission management dataset and defining the minimum test submission data unit for each agile iteration cycle, refined and orderly management of test submissions is achieved, thereby enabling efficient collaboration and quality control between the development and testing phases. Attached Figure Description

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

[0041] Figure 1 This is an application environment diagram of the implementation method of the testing process in one embodiment;

[0042] Figure 2 This is a flowchart illustrating the implementation method of the testing process in one embodiment;

[0043] Figure 3 This is a flowchart illustrating the implementation method of the testing process in another embodiment;

[0044] Figure 4 This is a structural block diagram of the apparatus for implementing the testing process in one embodiment;

[0045] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0047] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0048] The implementation method of the testing process provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on a cloud or other network server. Specifically, terminal 102 or server 104 implements a method for a testing process, which includes:

[0049] Define data units, which include functional requirement units that describe the required functions, task execution units that carry out the minimum development tasks, and defect record units that record software defects.

[0050] Based on the acceptance criteria fields of functional requirement units or task execution units, generate structured test cases containing operation steps and expected results; establish an association index between functional requirement units, test cases and defect record units, or between task execution units, test cases and defect record units through a unique identifier mapping mechanism;

[0051] The state transition rule engine, built on a directed acyclic graph, configures a sequence of state nodes consisting of pending, under development, pending testing, under testing, and completed for functional requirement units and task execution units, and a sequence of state nodes consisting of new, open, under repair, pending verification, closed, and rejected for defect recording units. Each state node is assigned a unique state identifier. The state transition rule engine verifies the preconditions for state transition through pre-verification logic and executes the automated operation after the state transition through post-trigger logic.

[0052] Create a test management dataset for each agile iteration cycle and assign a unique test set identifier; define a single functional requirement unit or task execution unit as the smallest test data unit; monitor the attribute status of the test data unit in real time, and when the test conditions are met, associate the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and trigger the state transition rule engine to transition the state node of the corresponding test data unit from development to pending test.

[0053] For test data units in the pending test status, structured test information is obtained from the attributes of associated functional requirement units or task execution units through a data synchronization interface. Based on the pre-verification logic of the state transition rule engine, test admission verification is completed for the integrity verification of test information, code branch compliance verification, and unit test coverage verification. After the verification is passed, based on the post-trigger logic, the state node of the test data unit is transitioned from pending test to test, and a test task notification is pushed to the test end. The structured test information includes test environment configuration and the scope of impact of changes.

[0054] Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, and projection equipment. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. Server 104 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0055] In one exemplary embodiment, such as Figure 2 As shown, a method for implementing the testing process is provided, which is then applied to... Figure 1 Taking the terminal in the example, the explanation includes the following steps 202 to 210. Wherein:

[0056] Step 202: Define data units. Data units include functional requirement units that describe the required functions, task execution units that carry out the minimum development tasks, and defect record units that record software defects.

[0057] The functional requirements unit describes the various functional requirements of the software; the task execution unit is the minimum development task that the functional requirements unit must carry out. The task execution unit is the minimum specific, operable, and assignable work item that is necessary for the functional requirements unit; and the defect recording unit is used to record various defects that occur during the software testing process.

[0058] For example, three types of data units are defined on the deployment platform, including functional requirement units that describe the required functions, task execution units that carry out the minimum development tasks, and defect recording units that record software defects.

[0059] Step 204: Based on the acceptance criteria fields of the functional requirement unit or task execution unit, generate structured test cases containing operation steps and expected results; establish an association index between the functional requirement unit, test cases and defect record unit, or between the task execution unit, test cases and defect record unit, through a unique identifier mapping mechanism.

[0060] Among them, the unique identifier mapping mechanism is used to assign globally unique identifiers to each functional requirement unit, task execution unit, and defect.

[0061] For example, testers write structured test cases based on the acceptance criteria fields of functional requirement units or task execution units. Each structured test case consists of multiple operation steps and expected results. A globally unique identifier is assigned to each functional requirement unit, task execution unit, defect record unit, and test case based on a unique identifier mapping mechanism. An association index is established between functional requirement units, test cases, and defect record units through the identifier, or an association index is established between task execution units, test cases, and defect record units through the identifier.

[0062] Step 206: Using a state transition rule engine built on a directed acyclic graph, configure a sequence of state nodes consisting of pending, under development, pending testing, under testing, and completed for the functional requirement unit and task execution unit, and configure a sequence of state nodes consisting of new, open, under repair, pending verification, closed, and rejected for the defect record unit. Each state node is assigned a unique state identifier. The state transition rule engine verifies the preconditions for state transition through pre-verification logic and executes the automated operation after state transition through post-trigger logic.

[0063] A directed acyclic graph (DAG) is a graph data structure consisting of tasks and their dependencies, where there are no circular dependencies—meaning each task will not return to its original state based on dependencies. State transition rules ensure that each work item, including functional requirement units, task execution units, and defect recording units, can proceed in an orderly and controlled manner according to a predetermined state cycle, thereby enabling state transitions for each work item. Furthermore, state transition rules include the current state of the work item, the target state, the preconditions for state transition, the user roles allowed to perform state transitions, verification checks before and after state transitions, automated operations after successful state transitions, and the operation execution interface.

[0064] The pre-verification logic includes merging the code into the system integration test environment and initiating a test submission with specific information. The automated operations after the state transition include notifying testers and activating test cases.

[0065] For example, the state transition rule engine based on the directed acyclic graph defines a complete state cycle for the functional requirement unit and the task execution unit. This state cycle is a sequence of state nodes consisting of pending, under development, pending testing, under testing, and completed. The state transition rule engine based on the directed acyclic graph defines a complete state cycle for the defect recording unit. This state cycle includes a sequence of state nodes consisting of new, open, under repair, pending verification, closed, and rejected.

[0066] For example, a unique state identifier is assigned to each state node, and the transition between states is controlled by combining predefined state transition rules. The state transition rules are implemented based on pre-verification logic and post-trigger logic. The pre-verification logic verifies whether the preconditions for state transition are met, and the post-trigger logic executes the automated operation after the state transition is successful.

[0067] Step 208: Create a test management dataset for each agile iteration cycle and assign a unique test set identifier; define a single functional requirement unit or task execution unit as the smallest test data unit; monitor the attribute status of the test data unit in real time, and when the test conditions are met, associate the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and trigger the state transition rule engine to transition the state node of the corresponding test data unit from development to pending test.

[0068] The attribute status of the data unit submitted for testing includes: under development, awaiting technical review, awaiting product pre-acceptance, ready for testing, test transferred to you, test passed, test failed, accepted, merged and launched, rolled back, and blocked. Testing conditions include P0-level test case certification.

[0069] For example, a test submission management dataset is created for each agile iteration cycle and assigned a unique submission set identifier to manage all test submission activities within that agile iteration cycle. A single functional requirement unit or task execution unit is defined as the smallest test submission data unit. The attribute status of the test submission data unit is monitored in real time. When a developer completes the development of a test submission data unit and meets the test submission conditions, the corresponding test submission data unit is associated with the test submission management dataset of the current iteration through a unique unit identifier. The test submission process for that test submission data unit is automatically triggered through a state transition rule engine, so that the state node of the corresponding test submission data unit transitions from "under development" to "awaiting test submission."

[0070] For example, when initiating testing for a test data unit, developers are guided to fill in structured test information, including test environment configuration, scope of impact of changes, description of core functional points, and links to relevant interface documents. This test information can be associated with the corresponding functional requirement unit or task execution unit and automatically synchronized from the corresponding functional requirement unit or task execution unit.

[0071] Step 210: For the test data unit in the pending test status, obtain structured test information from the attributes of the associated functional requirement unit or task execution unit through the data synchronization interface; based on the pre-verification logic of the state transition rule engine, complete the test admission verification of test information integrity verification, code branch compliance verification, and unit test coverage verification; after the verification is passed, based on the post-trigger logic, the state node of the test data unit is transferred from pending test to test, and a test task notification is pushed to the test end; the structured test information includes test environment configuration and the scope of impact of changes.

[0072] For example, when the test data unit is in the state of pending test, the structured test information filled in by the developers is obtained from the attributes of the associated functional requirement unit or task execution unit through the data synchronization interface, including the test environment configuration and the impact of changes; and based on the pre-verification logic of the state transition engine, the test admission verification is completed to verify the integrity of the test information, the compliance of the code branch, and the unit test coverage.

[0073] For example, after the test submission admission verification is passed, the state node of the test submission data unit is transferred from the test pending stage to the test stage based on the post-trigger logic of the state transition rule engine, and the test task is automatically pushed to the test end to notify the testers, so that the testers can perform tests based on the test cases written by the developers.

[0074] In the above-described method for implementing the testing process, by establishing an association index between functional requirement units or task execution units, test cases, and defect record units, it is possible to directly create and associate defect record units from the failed steps of test cases with the initial working unit, thereby ensuring rapid and accurate location of the problem source. By using a state transition rule engine based on a directed acyclic graph to perform state transitions for each unit, the standardization and authenticity of the process can be ensured. By creating a testing management dataset for each agile iteration cycle and defining the minimum testing data unit, refined and orderly management of testing is achieved, thereby realizing efficient collaboration and quality control between the development and testing phases.

[0075] In one embodiment, the process of the tester executing tests includes: executing tests based on associated structured test cases; if a test case failure is detected, automatically generating a defect record unit through the associated index and assigning it to the responsible development user; wherein, the state transition of the defect record unit is managed by the state transition rule engine and the role-based access control model; and when the state of the defect record unit changes, pushing relevant messages to the relevant responsible user based on the post-triggered logic.

[0076] For example, when performing tests based on structured test cases written by testers and associated with functional requirement units or task execution units corresponding to test data units, if the actual result is found to be inconsistent with the expected result, a defect record unit is automatically generated on the failed test step through the association index, and the defect record unit is automatically bound to the corresponding test case and the initial functional requirement unit or task execution unit associated with the test case, and assigned to the development responsible user.

[0077] For example, the status of a defect recording unit includes New, Open, Under Repair, Pending Verification, Closed, and Rejected. Its status transitions are managed by a status transition rule engine with clearly defined rules. Furthermore, critical status transitions are subject to strict role-based access control constraints. For instance, only testers have the authority to change the status of a defect marked as "Completed" to "Closed." When the status of a defect recording unit changes, relevant messages are pushed to the responsible users in real time based on post-triggered logic.

[0078] In this embodiment, defect record units are automatically generated by association index and assigned to responsible development users, which can ensure that each defect can be accurately traced back to the work item that generated it and the relevant responsible user, thereby improving the efficiency of problem solving. By managing the state flow of defect record units through the state transition engine and role permission control module, the objectivity of defect repair verification and the independence of final quality control can be ensured, and an efficient closed-loop feedback loop can be formed by pushing relevant messages to relevant responsible users.

[0079] In one embodiment, the method further includes: using a state transition rule engine to collect in real time the number of data units, the severity level of defect record units, and the execution results of structured test cases for each state node, and synchronizing them to the test submission management dataset; based on the data in the test submission management dataset, generating a visual monitoring view containing the distribution of data unit states and the distribution of defect levels, and calculating the defect density, defect repair cycle, and first-time test pass rate to generate a structured test report.

[0080] The execution results of structured test cases include the pass rate, failure rate, and blocking rate. Defect density refers to the number of defects per story point; defect repair cycle time refers to the average time from defect creation to closure; and the first-time pass rate is used to characterize the quality of the test submission.

[0081] For example, for each state in an agile iteration, including development, testing, and completion, the state transition rule engine collects data in real time on each state node, including the number of functional requirement units, the number of task execution units, the cumulative number of defects discovered, the severity level of defect record units, the pass rate, failure rate, and blocking rate of structured test cases, as well as the task load of the responsible user. This collected data is then synchronized to the test management dataset. Through in-depth data mining and analysis of the test management dataset, a visual monitoring view containing the state distribution of each data unit and the defect level distribution is generated. Defect density, defect repair cycle, test quality, and test coverage are calculated, thereby generating a structured test report.

[0082] In this embodiment, the state transition engine collects data from each state node in real time and synchronizes it to the test management dataset, enabling responsible users to monitor the progress and quality risks of each data unit in agile iterations in real time. The real-time collected data generates a visual monitoring view and a structured test report, which helps to provide objective evidence for evaluating development quality, test effectiveness, and iteration success rate, thereby enabling responsible users to make continuous improvements and thus improve development efficiency.

[0083] In one embodiment, a unique identifier mapping mechanism is used to establish an association index between functional requirement units, test cases, and defect record units, or between task execution units, test cases, and defect record units. This includes: assigning unique unit identifiers to functional requirement units and task execution units, assigning unique test case identifiers to test cases, and assigning unique defect identifiers to defect record units; establishing a mapping table between unit identifiers and test case identifiers to store the association relationship between functional requirement units and test cases, or between task execution units and test cases, with fields including unit identifier, test case identifier, and acceptance criterion identifier; and, in the case of generating a defect record unit, reading the test case identifier of a failed test case, matching the corresponding unit identifier through the mapping table, and writing the unit identifier, test case identifier, and failure step sequence number into the association information field of the defect record unit to form a complete traceability chain.

[0084] For example, functional requirement units, task execution units, and defect test case recording units are defined on the deployment platform. A unique unit identifier is assigned to each functional requirement unit and task execution unit in agile development, and a unique defect identifier is assigned to each defect recording unit in agile development. Testers write test cases based on acceptance criteria and assign unique test case identifiers to the test cases.

[0085] For example, the association between functional requirement units and test cases is established according to the acceptance criteria of each functional requirement unit or task execution unit, or the association between task execution units and test cases is established, thereby establishing a mapping table between unit identifiers and test case identifiers. The fields of the mapping table include unit identifier, test case identifier, and acceptance criterion identifier.

[0086] For example, when generating a defect record unit, based on the test case identifier of the failed test case corresponding to the defect, the corresponding unit identifier is matched through a mapping table, thereby writing the unit identifier, test case identifier, and failure step sequence number into the association information field of the defect record unit to form a complete traceability chain. When the unit identifier is the identifier of a functional requirement unit, an association is established between the functional requirement unit, test case, and defect record unit; when the unit identifier is the identifier of a task execution unit, an association is established between the task execution unit, test case, and defect record unit.

[0087] In this embodiment, a unique identifier mapping mechanism is used to establish the association between development work items, test cases, and defect work items, thereby improving the transparency of testing and the standardization of the test submission process.

[0088] In one embodiment, when the testing conditions are met, the corresponding test data unit is associated with the test management dataset of the current iteration through a unique unit identifier. This includes: creating a test management dataset and configuring the test set identifier, iteration cycle, associated unit list, and unit status distribution during the initialization phase of the agile iteration cycle; monitoring the status of functional requirement units or task execution units in real time, and determining that the testing conditions are met when the status changes to "completed," the P0 test case self-test passes, and the code review passes; querying the associated unit list of the test management dataset, and adding the corresponding unique identifier to the associated unit list if it is not found; and updating the status of the corresponding test data unit to "pending testing" based on the pre-verification logic of the state transition rule engine, and synchronously updating the number of units in the "pending testing" state in the unit status distribution.

[0089] The associated unit list includes the functional requirement unit or task execution unit corresponding to the test data unit, as well as the unique unit identifier corresponding to the test data unit. P0 test case self-testing refers to testing the completed functional requirement unit and task execution unit based on test cases written by testers before the developers submit the test data. Code review refers to the review of the code by developers other than the code developer before merging the code.

[0090] For example, during the initialization phase of an agile iteration cycle, a test submission management dataset is created. This dataset is configured with a test submission set identifier, iteration cycle, associated unit list, and the status distribution of each unit. The status of each functional requirement unit or task execution unit is monitored in real time. The pre-validation logic of the state transition rule engine detects whether the test submission data unit meets the test submission conditions. If the status of the corresponding functional requirement unit or task execution unit changes to "completed," and the unit passes P0 test case self-testing and code review, the unit is deemed to meet the test submission conditions. When a test submission data unit meets the test submission conditions, the state transition rule engine automatically triggers the test submission of that data unit. It queries the associated unit list of the test submission management dataset for the unique identifier of the corresponding test submission data unit. If no unique identifier is found, the unique identifier is added to the associated unit list, and the status of the corresponding test submission data unit is updated to "pending test submission." The number of units in the "pending test submission" state in the unit status distribution is also updated synchronously.

[0091] In this embodiment, by monitoring the status of functional requirement units or task execution units in real time and updating the status of corresponding test data units that meet the test conditions to be put into test, the test personnel can be notified based on the post-trigger logic of the status flow rule engine. This ensures that test personnel can continuously and incrementally receive testable content, which is conducive to discovering and fixing defects earlier and improving unit testing efficiency.

[0092] In one embodiment, the method further includes: for test data units that fail verification, re-verify them after modification; if the number of failed verifications reaches a preset number, remove the corresponding test data unit from the test management dataset and mark its status as pending optimization; for defect record units with a status of rejected, trigger a dispute coordination process; if a structured test case is blocked due to environmental anomalies, update the status of the corresponding test data unit to test blocked and send a notification to the operations and maintenance end; after the operations and maintenance end repairs the environment, update the status of the corresponding test data unit to test in progress and record the blocking duration.

[0093] For example, for test data units that fail verification, i.e., when the test data unit does not meet the test conditions, the corresponding developers modify them and re-verify them; if the re-verification passes, the corresponding test data unit continues to be submitted for testing; if the re-verification fails and the number of failures reaches a preset number, the corresponding test data unit is removed from the corresponding test management dataset, and the status of the test data unit is marked as pending optimization.

[0094] For example, after submitting a test request for a data unit, testers execute tests based on test cases and create defect record units based on the test results during the testing process. These defect record units are then associated with the initial functional requirement unit or task execution unit and the corresponding test cases, and sent to the relevant developers for analysis, confirmation, and repair. If a developer refuses to repair, i.e., the status of the defect record unit changes to "rejected," a dispute coordination process is triggered. This process includes: the developer submits a statement online explaining their refusal to repair, which the testers review; if the review is successful, the status of the defect record unit is changed to "cancelled," and the statement is included in the reporting metrics; if the review fails, i.e., the testers disagree with the statement, dispute communication is triggered, the developers perform defect repair based on the communication results, and the testers then conduct a retest based on the repaired test data unit.

[0095] For example, when a test block occurs during the testing of a test data unit, the status of the test data unit is updated to "test blocked" and a notification is sent to the operations and maintenance department. After the operations and maintenance department repairs the environment, the test data unit is tested again, and the status of the corresponding test data unit is updated to "testing in progress," and the blocking duration is recorded.

[0096] In this embodiment, based on the various defects and problems that occur during the unit testing of the test data, corresponding status changes are made and relevant responsible users are notified. This can form an efficient closed-loop feedback loop, thereby ensuring the test progress, avoiding waste of test resources, and effectively improving test efficiency.

[0097] like Figure 3 As shown, a specific embodiment illustrates the implementation method of the testing process, including steps 302 to 314. Wherein,

[0098] Step 302: Define data units, including functional requirement units, task execution units, and defect recording units.

[0099] Specifically, the functional requirements unit describes the various functional requirements of the software; the task execution unit carries the minimum development task, which is the minimum specific, operable, and assignable work item necessary for the functional requirements unit; and the defect recording unit records various defects that occur during the software testing process.

[0100] Step 304: Write test cases and establish an association index between functional requirement units or task execution units, test cases, and defect record units.

[0101] Specifically, based on the acceptance criteria fields of functional requirement units or task execution units, testers write structured test cases, each consisting of multiple operation steps and expected results.

[0102] A globally unique identifier is assigned to each functional requirement unit, task execution unit, defect record unit, and test case based on a unique identifier mapping mechanism. An association index is established between functional requirement units, test cases, and defect record units through the identifier, or an association index is established between task execution units, test cases, and defect record units through the identifier.

[0103] Step 306: Based on the state transition rule engine built by the directed acyclic graph, configure the state node sequence for the functional requirement unit, task execution unit and defect recording unit respectively, and drive the automatic transition of state.

[0104] Specifically, the state transition rule engine based on directed acyclic graphs defines a complete state cycle for functional requirement units and task execution units. This state cycle consists of a sequence of state nodes: pending, under development, pending testing, under testing, and completed. The state transition rule engine based on directed acyclic graphs also defines a complete state cycle for defect recording units. This state cycle includes a sequence of state nodes: new, open, under repair, pending verification, closed, and rejected.

[0105] The state transition rule engine drives the state of each unit to flow according to predefined workflow rules, which are implemented through pre-validation logic and post-trigger logic. Specifically, the pre-validation logic verifies whether all the preconditions for state transition are met; the post-trigger logic executes automated operations after a successful state transition.

[0106] Step 308: Create a test management dataset for each agile iteration cycle, include the smallest test data unit that meets the test conditions into the test management dataset, and transfer its status node from development to pending test.

[0107] Specifically, a test submission management dataset is created for each agile iteration cycle and assigned a unique submission set identifier to manage all test submission activities within that agile iteration cycle. A single functional requirement unit or task execution unit is defined as the smallest test submission data unit. The attribute status of the test submission data unit is monitored in real time. When a developer completes the development of a test submission data unit and meets the test submission conditions, the test submission data unit is associated with the test submission management dataset of the current iteration through a unique unit identifier. The test submission process for that test submission data unit is automatically triggered through the state transition rule engine, so that the corresponding test submission data unit's state node transitions from "under development" to "awaiting test submission."

[0108] Meanwhile, when initiating testing for a data unit, developers are guided to fill in structured testing information, including test environment configuration, scope of impact of changes, description of core functional points, and links to relevant interface documents. This testing information can be associated with the corresponding functional requirement unit or task execution unit and automatically synchronized from the corresponding functional requirement unit or task execution unit.

[0109] Step 310: Obtain the structured test information of the test data unit in the test-to-be-tested state and perform integrity verification. After the verification is passed, transfer the state node of the test data unit from the test-to-be-tested state to the test state.

[0110] Specifically, when a data unit is in a "pending test" state, the structured test information filled in by developers is obtained from the attributes of the associated functional requirement unit or task execution unit through the data synchronization interface. This includes test environment configuration and the impact of changes. Based on the pre-verification logic of the state transition engine, test admission verification is completed to verify the completeness of test information, the compliance of code branches, and the unit test coverage. After the test admission verification is passed, based on the post-trigger logic of the state transition rule engine, the state node of the data unit is transitioned from "pending test" to "testing," and the test task is automatically pushed to the test end to notify the testers, enabling them to perform tests based on the test cases written by the developers.

[0111] Specifically, for test data units that fail verification (i.e., those that do not meet the testing conditions), the corresponding developers modify them and re-verify them. If the re-verification passes, the corresponding test data unit is submitted for testing again. If the re-verification fails and the number of failures reaches a preset number, the corresponding test data unit is removed from the corresponding test management dataset, and its status is marked as pending optimization.

[0112] Step 312: Testers execute tests based on test cases and create defect record units based on test results.

[0113] After submitting a test request for a data unit, testers execute tests based on test cases. During the testing process, they create defect record units based on the test results, associate these defect record units with the initial functional requirement unit or task execution unit and the corresponding test cases, and send them to the relevant developers for analysis, confirmation, and repair. If a developer refuses to repair, i.e., the status of the defect record unit changes to "rejected," a dispute coordination process is triggered. This process includes: the developer submits an explanation for refusing to repair online, and the testers review this explanation; if the review is successful, the status of the defect record unit is changed to "cancelled," and the explanation is included in the report metrics; if the review fails, i.e., the testers disagree with the explanation, dispute communication is triggered, the developers perform defect repair based on the communication results, and the testers then conduct a retest based on the repaired test data unit.

[0114] Specifically, when a test block occurs during the testing of a test data unit, the status of the test data unit is updated to "Test Blocked" and a notification is sent to the operations and maintenance team. After the operations and maintenance team repairs the environment, the test data unit is tested again, and the status of the corresponding test data unit is updated to "Testing" and the duration of the block is recorded.

[0115] Step 314: Based on the data in the test management dataset, generate a visual monitoring view and a structured test report.

[0116] Specifically, for each state in the agile iteration process, including development, testing, and completion, the state transition rule engine collects data in real time on each state node, including the number of functional requirement units, the number of task execution units, the cumulative number of defects discovered, the severity level of defect record units, the pass rate, failure rate, and blocking rate of structured test cases, as well as the task load of the responsible user. This collected data is then synchronized to the test management dataset. Through in-depth data mining and analysis of the test management dataset, a visual monitoring view is generated, containing the state distribution of each data unit and the defect level distribution. Defect density, defect repair cycle, test quality, and test coverage are calculated, thereby generating a structured test report.

[0117] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0118] Based on the same inventive concept, this application also provides an apparatus for implementing the above-described method for implementing the testing process. The solution provided by this apparatus is similar to the implementation scheme described in the above method. Therefore, the specific limitations in one or more embodiments of the testing process implementation apparatus provided below can be found in the limitations of the testing process implementation method described above, and will not be repeated here.

[0119] In one exemplary embodiment, such as Figure 4 As shown, a testing process implementation device 400 is provided, including: a definition module 402, a generation module 404, a configuration module 406, a creation module 408, and an acquisition module 410, wherein:

[0120] Module 402 is defined to define data units, which include functional requirement units that describe the required functions, task execution units that carry out the minimum development tasks, and defect record units that record software defects.

[0121] The generation module 404 is used to generate structured test cases containing operation steps and expected results based on the acceptance criterion fields of functional requirement units or task execution units; and to establish an association index between functional requirement units, test cases and defect record units, or between task execution units, test cases and defect record units, through a unique identifier mapping mechanism.

[0122] Configuration module 406 is used to configure a state node sequence consisting of pending, under development, pending testing, under testing, and completed for functional requirement units and task execution units, and a state node sequence consisting of new, open, under repair, pending verification, closed, and rejected for defect recording units, through a state transition rule engine built on a directed acyclic graph. Each state node is assigned a unique state identifier. The state transition rule engine verifies the preconditions for state transition through pre-verification logic and executes the automated operation after the state transition through post-trigger logic.

[0123] Create module 408 to create a test management dataset for each agile iteration cycle and assign a unique test set identifier; define a single functional requirement unit or task execution unit as the smallest test data unit; monitor the attribute status of the test data unit in real time, and when the test conditions are met, associate the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and trigger the state transition rule engine to transition the state node of the corresponding test data unit from development to pending test.

[0124] The acquisition module 410 is used to obtain structured test information from the attributes of the associated functional requirement unit or task execution unit through the data synchronization interface for the test data unit in the pending test status. Based on the pre-verification logic of the state transition rule engine, it completes the test admission verification of test information integrity, code branch compliance, and unit test coverage. After the verification is passed, based on the post-trigger logic, the state node of the test data unit is transferred from pending test to test, and a test task notification is pushed to the test end. The structured test information includes test environment configuration and the scope of impact of changes.

[0125] In one embodiment, the acquisition module is also used for the process of the test terminal to execute the test, including: executing the test based on the associated structured test cases; if the test case fails, automatically generating a defect record unit through the associated index and assigning it to the development responsible user; wherein, the state transition of the defect record unit is controlled by the state transition rule engine and the role permission control model; when the state of the defect record unit changes, relevant messages are pushed to the relevant responsible user based on the post-trigger logic.

[0126] In one embodiment, the configuration module is also used to collect the number of data units, the severity level of defect record units, and the execution results of structured test cases of each state node in real time through the state transition rule engine, and synchronize them to the test management dataset; based on the data in the test management dataset, generate a visual monitoring view containing the distribution of data unit states and defect levels, and calculate defect density, defect repair cycle, and first-time test pass rate to generate a structured test report.

[0127] In one embodiment, the generation module is further configured to establish an association index between functional requirement units, test cases, and defect record units, or between task execution units, test cases, and defect record units, through a unique identifier mapping mechanism. This includes: assigning unique unit identifiers to functional requirement units and task execution units, assigning unique test case identifiers to test cases, and assigning unique defect identifiers to defect record units; establishing a mapping table between unit identifiers and test case identifiers to store the association relationship between functional requirement units and test cases, or between task execution units and test cases, wherein the fields of the mapping table include unit identifier, test case identifier, and acceptance criterion identifier; and, in the case of generating defect record units, reading the test case identifier of failed test cases, matching the corresponding unit identifier through the mapping table, and writing the unit identifier, test case identifier, and failure step sequence number into the association information field of the defect record unit to form a complete traceability chain.

[0128] In one embodiment, the creation module is further configured to associate the corresponding test data unit with the test management dataset of the current iteration through a unique unit identifier when the test conditions are met. This includes: creating a test management dataset during the initialization phase of the agile iteration cycle and configuring the test set identifier, iteration cycle, associated unit list, and unit status distribution; monitoring the status of functional requirement units or task execution units in real time, and determining that the test conditions are met when the status changes to "completed," the P0 test case self-test passes, and the code review passes; querying the associated unit list of the test management dataset, and adding the corresponding unique identifier to the associated unit list if it does not contain the unique identifier of the corresponding test data unit; and updating the status of the corresponding test data unit to "pending test" based on the pre-verification logic of the state transition rule engine, and synchronously updating the number of units in the "pending test" state in the unit status distribution.

[0129] In one embodiment, the acquisition module is further configured to modify and re-verify test data units that fail verification; if the number of failed verifications reaches a preset number, the corresponding test data unit is removed from the test management dataset and its status is marked as pending optimization; for defect record units with a status of rejected, a dispute coordination process is triggered; if a structured test case is blocked due to environmental anomalies, the status of the corresponding test data unit is updated to test blocked and a notification is sent to the operations and maintenance end; after the operations and maintenance end repairs the environment, the status of the corresponding test data unit is updated to test in progress and the blocking duration is recorded.

[0130] Each module in the above-described testing process implementation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0131] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a testing process.

[0132] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0133] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0134] Define data units, which include functional requirement units that describe the required functions, task execution units that carry out the minimum development tasks, and defect record units that record software defects.

[0135] Based on the acceptance criteria fields of functional requirement units or task execution units, generate structured test cases containing operation steps and expected results; establish an association index between functional requirement units, test cases and defect record units, or between task execution units, test cases and defect record units through a unique identifier mapping mechanism;

[0136] The state transition rule engine, built on a directed acyclic graph, configures a sequence of state nodes consisting of pending, under development, pending testing, under testing, and completed for functional requirement units and task execution units, and a sequence of state nodes consisting of new, open, under repair, pending verification, closed, and rejected for defect recording units. Each state node is assigned a unique state identifier. The state transition rule engine verifies the preconditions for state transition through pre-verification logic and executes the automated operation after the state transition through post-trigger logic.

[0137] Create a test management dataset for each agile iteration cycle and assign a unique test set identifier; define a single functional requirement unit or task execution unit as the smallest test data unit; monitor the attribute status of the test data unit in real time, and when the test conditions are met, associate the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and trigger the state transition rule engine to transition the state node of the corresponding test data unit from development to pending test.

[0138] For test data units in the pending test status, structured test information is obtained from the attributes of associated functional requirement units or task execution units through a data synchronization interface. Based on the pre-verification logic of the state transition rule engine, test admission verification is completed for the integrity verification of test information, code branch compliance verification, and unit test coverage verification. After the verification is passed, based on the post-trigger logic, the state node of the test data unit is transitioned from pending test to test, and a test task notification is pushed to the test end. The structured test information includes test environment configuration and the scope of impact of changes.

[0139] In one embodiment, when the processor executes the computer program, it also implements the following steps: the process of the test terminal executing the test includes: executing the test based on the associated structured test cases; if the test case failure is detected, automatically generating a defect record unit through the associated index and assigning it to the development responsible user; wherein, the state transition of the defect record unit is controlled by the state transition rule engine and the role and permission control model; when the state of the defect record unit changes, relevant messages are pushed to the relevant responsible user based on the post-trigger logic.

[0140] In one embodiment, when the processor executes the computer program, it also performs the following steps: by using a state transition rule engine, it collects in real time the number of data units, the severity level of defect record units, and the execution results of structured test cases for each state node, and synchronizes them to the test submission management dataset; based on the data in the test submission management dataset, it generates a visual monitoring view containing the distribution of data unit states and the distribution of defect levels, and calculates the defect density, defect repair cycle, and first-time test pass rate to generate a structured test report.

[0141] In one embodiment, when the processor executes the computer program, it further implements the following steps: establishing an association index between functional requirement units, test cases, and defect record units, or between task execution units, test cases, and defect record units, through a unique identifier mapping mechanism. This includes: assigning unique unit identifiers to functional requirement units and task execution units, assigning unique test case identifiers to test cases, and assigning unique defect identifiers to defect record units; establishing a mapping table between unit identifiers and test case identifiers to store the association relationship between functional requirement units and test cases, or between task execution units and test cases, wherein the fields of the mapping table include unit identifiers, test case identifiers, and acceptance criterion identifiers; and, in the case of generating a defect record unit, reading the test case identifier of a failed test case, matching the corresponding unit identifier through the mapping table, and writing the unit identifier, test case identifier, and failure step sequence number into the association information field of the defect record unit to form a complete traceability chain.

[0142] In one embodiment, when the processor executes the computer program, it further implements the following steps: when the testing conditions are met, the corresponding test data unit is associated with the test management dataset of the current iteration through a unique unit identifier, including: during the initialization phase of the agile iteration cycle, creating a test management dataset and configuring the test set identifier, iteration cycle, associated unit list, and unit status distribution; monitoring the status of functional requirement units or task execution units in real time, and determining that the testing conditions are met when the status changes to completed, the P0 test case self-test passes, and the code review passes; querying the associated unit list of the test management dataset, and if the unique identifier of the corresponding test data unit is not included, adding the corresponding unique identifier to the associated unit list; and updating the status of the corresponding test data unit to pending testing based on the pre-verification logic of the state transition rule engine, and synchronously updating the number of units in the pending testing state in the unit status distribution.

[0143] In one embodiment, when the processor executes the computer program, it further implements the following steps: for test data units that fail verification, after modification, they are re-verified; if the number of failed verifications reaches a preset number, the corresponding test data unit is removed from the test management dataset and its status is marked as pending optimization; for defect record units with a status of rejected, a dispute coordination process is triggered; if a structured test case is blocked due to environmental anomalies, the status of the corresponding test data unit is updated to test blocked and a notification is sent to the operations and maintenance end; after the operations and maintenance end repairs the environment, the status of the corresponding test data unit is updated to test in progress and the blocking duration is recorded.

[0144] The implementation principle and technical effects of the above embodiments are similar to those of the above method embodiments, and will not be repeated here.

[0145] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0146] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0147] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0148] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0149] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0150] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for implementing a testing process, characterized in that, The method includes: Define a data unit, which includes a functional requirement unit that describes the required functions, a task execution unit that carries the minimum development task, and a defect record unit that records software defects; Based on the acceptance criteria fields of functional requirement units or task execution units, generate structured test cases containing operation steps and expected results; establish an association index between functional requirement units, test cases and defect record units, or between task execution units, test cases and defect record units through a unique identifier mapping mechanism; A state transition rule engine based on a directed acyclic graph is used to configure a sequence of state nodes consisting of pending, under development, pending testing, under testing, and completed for functional requirement units and task execution units, and a sequence of state nodes consisting of new, open, under repair, pending verification, closed, and rejected for defect recording units. Each state node is assigned a unique state identifier. The state transition rule engine verifies the preconditions for state transition through pre-verification logic and executes the automated operation after the state transition through post-trigger logic. Create a test management dataset for each agile iteration cycle and assign a unique test set identifier; define a single functional requirement unit or task execution unit as the smallest test data unit; monitor the attribute status of the test data unit in real time, and when the test conditions are met, associate the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and trigger the state transition rule engine to transition the state node of the corresponding test data unit from development to pending test. For test data units in the pending test status, structured test information is obtained from the attributes of associated functional requirement units or task execution units through a data synchronization interface. Based on the pre-verification logic of the state transition rule engine, test admission verification is completed for test information integrity verification, code branch compliance verification, and unit test coverage verification. After the verification is passed, based on the post-trigger logic, the state node of the test data unit is transitioned from pending test to test, and a test task notification is pushed to the test end. The structured test information includes test environment configuration and the scope of impact of changes.

2. The method according to claim 1, characterized in that, The process of the test terminal executing the test includes: Tests are executed based on associated structured test cases. If a test case fails, a defect record unit is automatically generated through the associated index and assigned to the responsible development user. The state transition of the defect record unit is managed by the state transition rule engine and the role and permission control model. When the status of the defect recording unit changes, relevant messages are pushed to the relevant responsible users based on the post-trigger logic.

3. The method according to claim 1, characterized in that, The method further includes: Through the state transition rule engine, the number of data units, the severity level of defect record units, and the execution results of structured test cases of each state node are collected in real time and synchronized to the test management dataset. Based on the data from the test submission management dataset, a visual monitoring view containing the distribution of data unit status and defect level is generated, and defect density, defect repair cycle, and first-time test pass rate are calculated to generate a structured test report.

4. The method according to claim 1, characterized in that, The establishment of an association index between functional requirement units, test cases, and defect record units, or between task execution units, test cases, and defect record units, through a unique identifier mapping mechanism, includes: Assign a unique unit identifier to the functional requirement unit and the task execution unit; assign a unique test case identifier to the test case; assign a unique defect identifier to the defect record unit. Establish a mapping table between unit identifiers and test case identifiers to store the association between functional requirement units and test cases, or the association between task execution units and test cases. The fields of the mapping table include unit identifier, test case identifier, and acceptance criterion identifier. When a defect record unit is generated, the test case identifier of the failed test case is read, the corresponding unit identifier is matched through the mapping table, and the unit identifier, test case identifier, and failure step sequence number are written into the associated information field of the defect record unit to form a complete traceability link.

5. The method according to claim 1, characterized in that, The step of associating the corresponding test data unit with the test management dataset of the current iteration through a unique unit identifier when the test conditions are met includes: During the initialization phase of the agile iteration cycle, a test management dataset is created, and the test set identifier, iteration cycle, associated unit list, and unit status distribution are configured. Real-time monitoring of the status of functional requirement units or task execution units; when the status changes to completed, P0 test cases pass self-testing and code review passes, it is determined that the conditions for submitting for testing are met. Query the list of associated units in the test management dataset. If the unique identifier of the corresponding test data unit is not included, add the corresponding unique identifier to the list of associated units. Based on the pre-verification logic of the state transition rule engine, update the state of the corresponding test data unit to "pending test" and synchronously update the number of units in the "pending test" state in the unit state distribution.

6. The method according to claim 2, characterized in that, The method further includes: For test data units that fail verification, they are modified and re-verified. If the number of failures reaches a preset number, the corresponding test data units are removed from the test management dataset and their status is marked as pending optimization. For defect record units with a status of "rejected", trigger the dispute coordination process; If a structured test case is blocked due to an environmental anomaly, the status of the corresponding test data unit will be updated to "Test Blocked" and a notification will be sent to the operations and maintenance team. After the operations and maintenance team repairs the environment, the status of the corresponding test data unit will be updated to "Testing" and the blocking duration will be recorded.

7. An apparatus for implementing a testing process, characterized in that, The device includes: The definition module is used to define data units, which include functional requirement units that describe the required functions, task execution units that carry out the minimum development tasks, and defect recording units that record software defects. The generation module is used to generate structured test cases containing operation steps and expected results based on the acceptance criterion fields of functional requirement units or task execution units; and to establish association indexes between functional requirement units, test cases and defect record units, or between task execution units, test cases and defect record units, through a unique identifier mapping mechanism. The configuration module is used to configure a state transition rule engine based on a directed acyclic graph to configure a sequence of state nodes consisting of pending, under development, pending testing, under testing, and completed for functional requirement units and task execution units, and a sequence of state nodes consisting of new, open, under repair, pending verification, closed, and rejected for defect recording units. Each state node is assigned a unique state identifier. The state transition rule engine verifies the preconditions for state transition through pre-verification logic and executes the automated operation after the state transition through post-trigger logic. Create a module to create a test management dataset for each agile iteration cycle and assign a unique test set identifier; define a single functional requirement unit or task execution unit as the smallest test data unit; monitor the attribute status of the test data unit in real time, and when the test conditions are met, associate the corresponding test data unit with the test management dataset of the current iteration through the unique unit identifier, and trigger the state transition rule engine to transition the state node of the corresponding test data unit from development to pending test. The acquisition module is used to obtain structured test information from the attributes of associated functional requirement units or task execution units through a data synchronization interface for test data units in the pending test status. Based on the pre-verification logic of the state transition rule engine, it completes the test admission verification of test information integrity, code branch compliance, and unit test coverage. After the verification is passed, based on the post-trigger logic, the state node of the test data unit is transitioned from pending test to test, and a test task notification is pushed to the test end. The structured test information includes test environment configuration and the scope of impact of changes.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images