Test management method, system and equipment and storage medium

Abstract

The invention provides a test management method, system and device, and a storage medium. The method comprises the following steps: synchronizing incremental test data of a test platform and defect associated data of a defect management system by setting a period; dynamically filtering invalid cases by adopting a preset cleaning rule; extracting defect numbers of the failed use cases based on a regular expression, and generating a hyperlink defect use case list containing skipping to a defect system; and periodically generating a test report according to the case execution state and the number. Therefore, the test data and the defect associated data of the defect management system are increased through the periodic synchronization test platform, automatic association of cross-system data is realized, the problem that errors are easy to occur in manual matching is avoided, the delay of the test report is reduced through generation of the periodic test report, and second-level defect positioning is realized through hyperlink configuration.

Description

Technical Field

[0001] The present application relates to the field of testing technology, and in particular to a test management method, system, device and storage medium. Background Art

[0002] In enterprise test management scenarios, traditional technologies face the following urgent challenges: 1) Test data and defect data are stored separately, resulting in cross-system data integration requiring daily manual report export, which takes 2-3 hours and has a matching error rate of 15%-20%; 2) Test report updates are severely delayed, relying on batch processing, resulting in progress data delays of over 4 hours and an inability to reflect test status in real time; 3) Defect location efficiency is low, requiring manual cross-system querying of association relationships. Summary of the Invention

[0003] The present application provides a test management method, system, device and storage medium to at least solve the above technical problems existing in the prior art.

[0004] According to a first aspect of the present application, a test management method is provided, which is applied to a test management system. The method includes:

[0005] Acquire incremental test data from the test platform according to a set period, and acquire defect-related data from the defect management system, wherein the incremental test data includes multiple use cases and the use case identifier, use case description, execution status, and time field of each use case;

[0006] Cleaning invalid test cases in the incremental test data based on preset cleaning rules to obtain target incremental test data;

[0007] Filter the use cases with failed execution status from the target incremental test data as defective use cases;

[0008] Extracting a defect number from a use case description of the defect use case based on a preset regular expression and the defect-related data, and generating a defect use case list based on a use case identifier of the defect use case and the corresponding defect number, wherein each record in the defect use case list includes a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system;

[0009] A test report is generated based on the number of use cases in the incremental test data and the target incremental test data and the execution status of each use case.

[0010] In one embodiment, obtaining incremental test data from a test platform according to a set period and obtaining defect-related data from a defect management system include:

[0011] Sending a data acquisition request at a set period through the calling interface of the test platform and the defect management system, wherein the data acquisition request includes a timestamp;

[0012] receiving initial incremental test data and initial defect association data fed back by the test platform and the defect management system according to the timestamp;

[0013] A difference comparison algorithm is used to obtain incremental test data and defect-related data that have changed compared with historical data from the initial incremental test data and initial defect-related data.

[0014] In one possible implementation, before cleaning invalid use cases in the incremental test data based on preset cleaning rules, the method further includes:

[0015] Format standardization is performed on the incremental test data, wherein the format standardization includes unifying the format of the time field, execution status, and priority of each use case.

[0016] In one possible implementation, cleaning invalid use cases in the incremental test data based on preset cleaning rules includes:

[0017] Filtering use cases with illegal status codes in the incremental test data;

[0018] Eliminate use cases with abnormal time fields in the incremental test data.

[0019] In one possible implementation, the defect number is extracted from the use case description of the defect use case based on a preset regular expression and the defect-related data, and a defect use case list is generated based on the use case identifier of the defect use case and the corresponding defect number, including:

[0020] Extract the defect number from the use case description of the defect use case based on the preset regular expression, and verify whether the defect number exists in the defect-related data;

[0021] For each defect case whose defect number exists in the defect association data, establishing an association relationship between the case identifier of the defect case and the defect number;

[0022] A defect use case list is generated based on the association relationship of all defect use cases, each record including a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system.

[0023] In one embodiment, the method further comprises:

[0024] For each defect case whose defect number does not exist in the defect-related data, controlling the defect management system to create a new defect and generate a new defect number;

[0025] Establish an association between the use case identifier of the defect use case and the new defect number;

[0026] A corresponding record is generated in the defect use case list according to the association relationship, and the record includes a use case identifier and a new defect number with a defect hyperlink that jumps to the defect management system.

[0027] In one embodiment, the method further comprises:

[0028] The use case identifier associated with each defect number is transmitted to the defect management system, so that the defect management system establishes an association relationship between each defect number and its corresponding use case identifier, and deploys a use case hyperlink that jumps to the test management system at the use case identifier.

[0029] In one embodiment, the test report includes a use case execution rate, a use case pass rate, and the number of use cases in each execution status, where the execution status includes pass, fail, skip, and block.

[0030] In one embodiment, generating a test report based on the number of use cases in the target incremental test data and the execution status of each use case includes:

[0031] Calculating a use case execution rate based on the total number of use cases in the target incremental test data and the number of executed use cases;

[0032] Calculate the use case pass rate based on the total number of use cases in the target incremental test data and the number of use cases with a pass status.

[0033] Calculate the number of use cases in each execution state in the target incremental test data.

[0034] In one embodiment, the test report further includes the total number of use cases, the number of executed use cases, the number of use cases to be executed, the use case failure rate, and the use case blocking rate.

[0035] In one embodiment, the method further comprises:

[0036] Display the defect case list and test report on the target terminal.

[0037] In one embodiment, the method further comprises:

[0038] Based on a keyword extraction algorithm, test hot words are extracted from the use case description of each use case in the incremental test data, and the test hot words are displayed on the target terminal.

[0039] According to a second aspect of the present application, a test management system is provided, the system comprising:

[0040] The acquisition module is used to obtain incremental test data from the test platform according to a set period and obtain defect-related data from the defect management system. The incremental test data includes multiple use cases and the use case identification, use case description, execution status and time field of each use case;

[0041] A cleaning module, configured to clean invalid test cases in the incremental test data based on preset cleaning rules to obtain target incremental test data;

[0042] A defect analysis module is used to filter out use cases with a failed execution status from the target incremental test data as defective use cases; extract defect numbers from the use case descriptions of the defective use cases based on a preset regular expression and the defect-related data; and generate a defect use case list based on the use case identifiers and corresponding defect numbers of the defective use cases, wherein each record in the defect use case list includes a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system;

[0043] The report generation module is used to generate a test report based on the number of use cases in the incremental test data and the target incremental test data and the execution status of each use case.

[0044] In one embodiment, the acquisition module includes:

[0045] A sending submodule, configured to send a data acquisition request at a set period through a calling interface of the test platform and the defect management system, wherein the data acquisition request includes a timestamp;

[0046] A receiving submodule, configured to receive the initial incremental test data and initial defect association data fed back by the test platform and the defect management system according to the timestamp;

[0047] The acquisition submodule is used to acquire the incremental test data and defect-related data that have changed compared with the historical data from the initial incremental test data and the initial defect-related data using a difference comparison algorithm.

[0048] In one embodiment, the system further comprises:

[0049] The processing module is used to perform format standardization processing on the incremental test data, wherein the format standardization processing includes unifying the format of the time field, execution status and priority of each use case.

[0050] In one embodiment, the cleaning module includes:

[0051] A filtering submodule, configured to filter out use cases with illegal status codes in the incremental test data;

[0052] The elimination submodule is used to eliminate use cases with abnormal time fields in the incremental test data.

[0053] In one embodiment, the defect analysis module includes:

[0054] A verification submodule is used to extract the defect number from the use case description of the defect use case based on a preset regular expression, and to verify whether the defect number exists in the defect-related data;

[0055] A first establishing submodule is configured to establish, for each defect case whose defect number exists in the defect association data, an association relationship between the use case identifier of the defect case and the defect number;

[0056] The first generation submodule is used to generate a defect use case list based on the association relationship of all defect use cases, each record including a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system.

[0057] In one embodiment, the system further comprises:

[0058] A control submodule, configured to control the defect management system to create a new defect and generate a new defect number for each defect case whose defect number does not exist in the defect association data;

[0059] The second submodule is used to establish an association relationship between the use case identifier of the defect use case and the new defect number;

[0060] The second generation submodule is used to generate a corresponding record in the defect use case list according to the association relationship, where the record includes a use case identifier and a new defect number with a defect hyperlink that jumps to the defect management system.

[0061] According to a third aspect of the present application, an electronic device is provided, including:

[0062] at least one processor; and

[0063] a memory communicatively linked to the at least one processor; wherein,

[0064] The memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the method described in this application.

[0065] According to a fourth aspect of the present application, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable the computer to execute the method described in the present application.

[0066] The test management method, system, device and storage medium of the present application obtain incremental test data from the test platform according to a set period, and obtain defect-related data from the defect management system, wherein the incremental test data includes multiple use cases and the use case identification, use case description, execution status and time field of each use case; based on the preset cleaning rules, the invalid use cases in the incremental test data are cleaned to obtain the target incremental test data; the use cases with a failed execution status are filtered from the target incremental test data as defect use cases; based on the preset regular expression and the defect-related data, the defect number is extracted from the use case description of the defect use case, and based on the use case identification and corresponding defect number of the defect use case, a defect use case list is generated, each record of the defect use case list includes a use case identification and a defect number deployed with a defect hyperlink that jumps to the defect management system; a test report is generated based on the number of use cases in the incremental test data and the target incremental test data and the execution status of each use case. By replacing manual operations with data from the automated incremental synchronization test platform and the defect management system, the cross-system association problem of test data and defect data is solved, and the risk of errors in manual matching is avoided. Through periodic data processing, the test indicator update delay is shortened from more than 4 hours in the traditional solution to a set period, thereby improving data timeliness. Hyperlink configuration within the defect case list enables quick navigation from test cases to the defect details page, optimizing defect location efficiency. Test reports are generated based on cleaned, valid data, covering metrics such as case execution rate and status distribution, transcending the limitations of traditional single pass rate statistics.

[0067] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] The above and other objects, features and advantages of the exemplary embodiments of the present application will become readily understood by reading the detailed description below with reference to the accompanying drawings. In the accompanying drawings, several embodiments of the present application are shown in an illustrative and non-limiting manner, in which:

[0069] In the drawings, the same or corresponding reference numerals denote the same or corresponding parts.

[0070] Figure 1 The following is a flowchart showing an implementation of the test management method provided in an embodiment of the present application;

[0071] Figure 2 A schematic diagram illustrating the implementation flow of the data acquisition operation of the test management method provided in an embodiment of the present application is shown;

[0072] Figure 3A schematic diagram illustrating an implementation flow of a list generation operation of a test management method provided in an embodiment of the present application is shown;

[0073] Figure 4 A schematic diagram of the structure of the test management system provided in an embodiment of the present application is shown;

[0074] Figure 5 A schematic diagram of the structure of an electronic device according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0075] In order to make the purpose, features, and advantages of this application more obvious and easy to understand, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of this application.

[0076] Figure 1 The following is a flowchart showing an implementation of the test management method provided in an embodiment of the present application.

[0077] refer to Figure 1 , an embodiment of the present application provides a test management method, which is applied to a test management system, the method comprising: operation 101, obtaining incremental test data from a test platform according to a set period, and obtaining defect-related data from a defect management system, the incremental test data comprising multiple use cases and a use case identifier, a use case description, an execution status, and a time field of each use case; operation 102, cleaning invalid use cases in the incremental test data based on preset cleaning rules to obtain target incremental test data; operation 103, filtering use cases with a failed execution status from the target incremental test data as defective use cases; operation 104, extracting defect numbers from the use case descriptions of the defective use cases based on a preset regular expression and defect-related data, and generating a defective use case list based on the use case identifier and the corresponding defect number of the defective use case, wherein each record in the defective use case list comprises a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system; operation 105, generating a test report based on the number of use cases in the incremental test data and the target incremental test data and the execution status of each use case.

[0078] In operation 101, incremental test data is obtained from the test platform according to a set period, and defect-related data is obtained from the defect management system. The incremental test data includes multiple use cases and a use case identifier, use case description, execution status, and time field of each use case.

[0079] By calling the test platform's interface, incremental test data is obtained at set intervals. The incremental test data includes multiple test cases and each case's use case identifier, use case description, execution status, and time fields (such as creation time and modification time). The set interval can be configured according to actual needs, such as 1 hour, 5 minutes, etc.

[0080] During case testing, the test platform and the defect management system are interconnected through an interface, with field mappings established. For example, if a test case in the test platform displays a "failed" status, the test platform automatically calls the defect management system's interface to create a new defect, generate a defect code, and upload key evidence, such as relevant log files and screenshots, to the defect management system as attachments, allowing developers to quickly locate and analyze the issue.

[0081] To locate defects within a set period and ensure that incremental test data from the test platform and defect-related data from the defect management system can be linked in subsequent steps, when incremental test data is obtained from the test platform, defect-related data from the defect management system is also synchronized, providing a complete and accurate data foundation for subsequent test management and defect analysis. Defect-related data includes defect number, defect description, and associated test cases.

[0082] In one embodiment of the present application, the testing platform is the open source continuous testing platform MeterSphere. This open source continuous testing platform is used to manage test cases and execute test plans. It supports multiple test types, including functional testing, performance testing, and interface testing. It provides an integrated test management solution and supports complete lifecycle management from test case design to test execution. Therefore, the testing platform in this embodiment of the present application is preferably MeterSphere.

[0083] In one embodiment of the present application, the defect management system is Jira, which is a project management and defect tracking tool mainly used for defect management (recording, tracking, and repairing) in software development.

[0084] In operation 102 , invalid use cases in incremental test data are cleaned based on preset cleaning rules to obtain target incremental test data.

[0085] In the collected incremental test data, there may be invalid use cases, which will affect the subsequent test analysis and report generation, so the data needs to be cleaned.

[0086] In one embodiment of the present application, invalid use cases in incremental test data are cleaned based on preset cleaning rules, including: filtering use cases with illegal status codes in incremental test data; and eliminating use cases with abnormal time fields in incremental test data.

[0087] Specifically, after acquiring incremental test data, the data is processed based on preset cleaning rules to filter out invalid test cases to ensure data quality. These cleaning rules include, but are not limited to: filtering out test cases with illegal status codes. For example, if the preset rule stipulates that the execution status must be one of Pass, Fail, Skip, or Block, and the execution status field value of a test case is "Passed" (it should be Pass), then the test case is filtered out due to an illegal status code; and eliminating test cases with abnormal time fields, such as when the creation time shown in the time field is less than the completion time.

[0088] In operation 103 , use cases with a failed execution status are filtered from the target incremental test data as defective use cases.

[0089] During the testing process, timely defect location requires periodic acquisition of defective use cases. Specifically, use cases with a "failed" execution status are filtered from the target incremental test data and marked as defective use cases. For example, in the target incremental test data, use case TC-1050 has a "failed" execution status. This is automatically filtered as a defective use case, allowing for subsequent defect number extraction and processing.

[0090] In operation 104, the defect number is extracted from the use case description of the defect use case based on the preset regular expression and defect-related data, and a defect use case list is generated based on the use case identifier of the defect use case and the corresponding defect number. Each record in the defect use case list includes the use case identifier and the defect number with a defect hyperlink that jumps to the defect management system.

[0091] Use a preset regular expression to search for a matching defect number pattern, such as "[DEF]-[0-9]{4}," in the use case description of a defect case. In a defect management system, each defect has a unique number (such as DEF-2001). By performing text matching on the use case description of a defect case, you can find defect numbers that match the preset regular expression.

[0092] The preset regular expressions are designed based on the defect number formats of the test platform and the defect management system. Specifically, by analyzing the defect number field format in the test platform use case description and the actual defect number format in the defect management system, common patterns and rules are identified. Based on these commonalities, the preset regular expressions are generated to ensure accurate matching and extraction of defect numbers.

[0093] After extracting the defect number, a defect case list is generated. Each record in the defect case list contains the use case ID and defect number of the defect case. The defect number section includes a hyperlink that redirects you to the defect management system. Clicking the hyperlink takes you to the defect details page in the defect management system. For example, if a record in the defect case list is "TC-1050 (use case ID) DEF–2001 (defect ID)", clicking the "DEF-2001" hyperlink takes you directly to the defect details page in the defect management system to view detailed information about the defect.

[0094] In operation 105 , a test report is generated according to the number of use cases in the incremental test data and the target incremental test data and the execution status of each use case.

[0095] To provide test managers and project stakeholders with a visual representation of test progress and quality, a detailed test report needs to be generated based on the collected and processed data. Specifically, key indicators are calculated and a test report is generated based on the number of use cases in the incremental test data and the target incremental test data, as well as the execution status of each use case.

[0096] In one embodiment of the present application, the test report includes the use case execution rate, the use case pass rate and the number of use cases in each execution status, and the execution status includes pass, fail, skip, and block.

[0097] In one embodiment of the present application, a test report is generated based on the number of use cases in the target incremental test data and the execution status of each use case, including: calculating the use case execution rate based on the total number of use cases in the target incremental test data and the number of executed use cases; calculating the use case pass rate based on the total number of use cases in the target incremental test data and the number of use cases with a passed execution status; and calculating the number of use cases in each execution status in the target incremental test data.

[0098] Specifically, the test report includes the use case execution rate, the use case pass rate, and the number of use cases in each execution status. The calculation formula for the use case execution rate is: (number of executed use cases / number of valid use cases) × 100%. Since the invalid use cases in the target incremental test data have been filtered out, the total number of use cases in the target incremental data is the number of valid use cases. The total number of use cases in the target incremental test data and the number of executed use cases can be obtained to calculate the use case execution rate according to the calculation formula of the use case execution rate. The calculation formula for the use case pass rate is: (number of passed use cases / number of valid use cases) × 100%. The total number of use cases in the target incremental test data and the number of use cases with a pass execution status can be obtained to calculate the use case pass rate according to the calculation formula of the use case pass rate. For the number of use cases in each execution status, it can be directly counted from the target incremental test data.

[0099] In one embodiment of the present application, the test report also includes the total number of use cases, the number of executed use cases, the number of use cases to be executed, the use case failure rate, and the use case blocking rate.

[0100] Specifically, in addition to covering the use case execution rate, use case pass rate and the number of use cases in each execution status, the test report also covers the total number of test cases, the number of executed use cases, the number of use cases to be executed, the use case failure rate and the use case blocking rate.

[0101] In one embodiment of the present application, the defect use case list and the test report are also displayed on the target terminal.

[0102] Among them, the defective use case list and test report can be presented to the target terminal (visual interface of the test management system) in the form of intuitive tables and charts, helping relevant personnel to quickly understand the test progress and quality status. For example, a pie chart + digital dashboard is used to display the total number of use cases, the number of executed use cases, the number of use cases to be executed, and the use case execution rate. A dynamic bar chart + status tag cloud is used to display the number of passed, failed, skipped, and blocked use cases and the corresponding pass rate, failure rate, and blocking rate. The number of passed, failed, skipped, and blocked use cases can be displayed in different colors. For the pass rate, failure rate, and blocking rate, a three-color early warning signal light system can also be configured to trigger multi-level alarm prompts based on threshold rules (such as execution rate <30%).

[0103] In this way, the embodiment of the present application replaces manual operations by automating incremental synchronization of data from the test platform and the defect management system, thereby solving the problem of cross-system association between test data and defect data and avoiding the risk of errors in manual matching. Through periodic data processing, the test indicator update delay is shortened from more than 4 hours in the traditional solution to a set period, thereby improving the timeliness of the data. The hyperlink configuration of the defect use case list enables a quick jump from the test case to the defect details page, optimizing the efficiency of defect location. The test report is generated based on the valid data after cleaning, covering indicators such as use case execution rate and state distribution, breaking through the limitations of traditional single pass rate statistics.

[0104] Figure 2 A schematic diagram of the implementation flow of the data acquisition operation of the test management method provided in an embodiment of the present application is shown.

[0105] refer to Figure 2In one embodiment of the present application, the above-mentioned operation 101, obtaining incremental test data from the test platform according to a set period, and obtaining defect-related data from the defect management system, includes: operation 201, sending a data acquisition request every set period through the calling interface of the test platform and the defect management system, and the data acquisition request includes a timestamp; operation 202, receiving the initial incremental test data and initial defect-related data fed back by the test platform and the defect management system according to the timestamp; operation 203, using a difference comparison algorithm to obtain the incremental test data and defect-related data that have changed compared with the historical data from the initial incremental test data and the initial defect-related data.

[0106] In operation 201 , a data acquisition request is sent at a set period through a calling interface of a test platform and a defect management system, where the data acquisition request includes a timestamp.

[0107] By invoking the interfaces of the test platform and defect management system, data acquisition requests are sent at set intervals. The data acquisition requests contain a timestamp to identify the time of the current request, allowing the test platform and defect management system to return new or changed data since the last request based on this time point.

[0108] Specifically, after sending a data retrieval request, the test platform and defect management system will respond to the data retrieval request and retrieve the initial incremental test data and initial defect-related data that match the time range from their respective data stores based on the timestamp. For example, if the timestamp of the previous request is T1 and the timestamp of this request is T2, the test platform or defect management system will return the data that changed between T1 and T2.

[0109] In operation 202 , initial incremental test data and initial defect association data fed back by a test platform and a defect management system according to timestamps are received.

[0110] Receive initial incremental test data and initial defect-related data from the test platform and defect management system based on timestamps. Initial incremental test data includes test cases added or updated in the test platform since the last request, along with related information such as the test case ID, description, execution status, and time fields. Initial defect-related data includes test case-related defect information in the defect management system during the same time period, such as the defect number, description, and associated test cases.

[0111] In operation 203 , a difference comparison algorithm is used to obtain incremental test data and defect-related data that have changed compared with historical data from the initial incremental test data and the initial defect-related data.

[0112] During the software testing process, test data and defect data are constantly updated and changed. To efficiently identify these changes and avoid repeated processing of the full data, the present embodiment also uses a difference comparison algorithm to process the initial incremental test data and initial defect-related data, further screening out the parts that have actually changed compared to the historical data, and obtaining the actual incremental test data and defect-related data, thereby improving the efficiency and accuracy of data processing.

[0113] Specifically, after receiving the initial incremental test data and initial defect-related data, the test management system loads previously stored historical data, including previously synchronized test cases and defect information. Then, using a difference comparison algorithm, the received initial incremental test data and initial defect-related data are compared with the historical data one by one, identifying any changed data as incremental test data and defect-related data.

[0114] The difference comparison algorithm can be a preset comparison rule, such as comparing data content, structure, or hash values ​​for changes. A change in test data might mean a test case changes from "Not Executed" to "Executed" or an update to the test case description. A change in defect-related data might mean a defect status changes from "New" to "Resolved" or a change in the defect's associated test case.

[0115] In this way, the embodiment of the present application eliminates manual operation errors by automating periodic data acquisition and processing, uses timestamps and difference comparison algorithms to accurately identify incremental data, reduces data processing volume, improves efficiency, and shortens data update delays, ensuring that the test team can obtain the latest data in a timely manner, and provides accurate and timely data support for subsequent test analysis and defect management.

[0116] In one embodiment of the present application, before cleaning invalid use cases in incremental test data based on preset cleaning rules, format standardization processing is also performed on the incremental test data, and the format standardization processing includes unifying the format of the time field, execution status and priority of each use case.

[0117] During the actual test data collection process, different test cases may have inconsistent formats for information such as the time field, execution status, and priority. If the formats of these fields are not standardized, subsequent data processing and analysis may encounter difficulties, such as data matching errors and inaccurate statistical results. Therefore, before cleaning invalid test cases in the incremental test data based on preset cleaning rules, the embodiment of the present application also performs format standardization on the incremental test data.

[0118] Specifically, we first standardized the format of the time fields for each test case to ensure that the time information can be correctly identified and sorted in subsequent processing. We then standardized the execution status into four standard states: "Pass," "Fail," "Skip," and "Block," to facilitate the subsequent unified evaluation and statistics of test results. Finally, we standardized the representation of priority, for example, converting it to three levels: "High," "Medium," and "Low," so that test cases can be sorted and filtered according to the unified priority rules in subsequent processing.

[0119] Figure 3 A schematic diagram of the implementation flow of the list generation operation of the test management method provided in an embodiment of the present application is shown.

[0120] refer to Figure 3 In one embodiment of the present application, the above-mentioned operation 104 extracts the defect number from the use case description of the defect use case based on a preset regular expression and defect association data, and generates a defect use case list based on the use case identifier of the defect use case and the corresponding defect number, including: operation 301, extracting the defect number from the use case description of the defect use case based on a preset regular expression, and verifying whether the defect number exists in the defect association data; operation 302, for each defect use case whose defect number exists in the defect association data, establishing an association relationship between the use case identifier of the defect use case and the defect number; operation 303, generating a defect use case list based on the association relationship of all defect use cases, each record containing the use case identifier and the defect number with a defect hyperlink that jumps to the defect management system.

[0121] In operation 301 , a defect number is extracted from a use case description of a defect use case based on a preset regular expression, and it is verified whether the defect number exists in defect-related data.

[0122] In the test management process, accurately extracting the corresponding defect number from the use case description of the defect case is a key step in associating test cases with defects. However, because testers may use irregular formats or typos when writing use case descriptions, or the position of the defect number in the use case description is not fixed, directly extracting the defect number may lead to extraction errors or omissions. In addition, it is necessary to ensure that the extracted defect number actually exists in the defect-related data to avoid establishing incorrect associations later. Therefore, it is necessary to first extract the defect number from the use case description of the defect case based on a preset regular expression and verify its existence.

[0123] Specifically, the test management system scans the use case descriptions of each defect case and uses a pre-set regular expression to search for content that matches the defect number format. Each match is used as the defect number. These defect numbers are then compared with the defect-related data obtained from the defect management system to verify their existence.

[0124] If it exists, it indicates that the extracted defect number is valid; if it does not exist, it may be that an error occurred during the extraction process, or the defect number in the use case description has not been synchronized to the defect management system and requires further processing.

[0125] In operation 302 , for each defect use case whose defect number exists in the defect association data, an association relationship between the use case identifier of the defect use case and the defect number is established.

[0126] For all verified defective test cases with valid defect numbers, the unique identifier of each test case (use case identifier) ​​is paired with the corresponding defect number to form an association record. These association records will be stored in the system's database or data structure, allowing for quick query and location of test cases related to specific defects, or vice versa, for quick tracing back to the corresponding defect details from the test case. For example, when a tester discovers that a test case has failed and is associated with a defect, this association allows them to directly view the detailed information of the defect in the defect management system, understand the current status of the defect, the progress of the handling, etc., and thus more efficiently troubleshoot and resolve the problem.

[0127] In operation 303 , a defect use case list is generated based on the association relationship of all defect use cases, where each record includes a use case identifier and a defect number with a defect hyperlink that jumps to a defect management system.

[0128] Specifically, all associated defect cases are organized and a list record is created for each case. This record includes the test case ID to clearly identify the test case with the problem, as well as the corresponding defect number, which is configured as a hyperlink. When a user clicks the defect hyperlink, they are automatically redirected to the corresponding defect details page in the defect management system, displaying detailed information about the defect, such as the defect description, resolution status, and responsible person.

[0129] In one embodiment of the present application, for each defect use case whose defect number does not exist in the defect association data, the defect management system is controlled to create a new defect and generate a new defect number; an association relationship between the use case identifier of the defect use case and the new defect number is established; and a corresponding record is generated in the defect use case list based on the association relationship, the record containing the use case identifier and the new defect number deployed with a defect hyperlink that jumps to the defect management system.

[0130] If the defect number mentioned in the use case description of a defect case does not exist in the defect-related data, it means that the defect has not yet been formally recorded and managed. To ensure that all defects can be tracked and handled in a timely manner, it is necessary to create a new defect and generate a new defect number in the defect management system. This will establish an association between the test case and the new defect and achieve comprehensive defect management.

[0131] Specifically, for each defect use case whose defect number does not exist in the defect-related data, the interface of the defect management system is automatically called to create a new defect record in the defect management system. The defect management system follows the numbering rules corresponding to the preset regular expression to assign a unique defect number to the newly created defect, and returns the new defect number to the test management system.

[0132] After receiving the new defect number, the test management system establishes an association between the use case ID of the defect case and the newly generated defect number. Based on this association, a corresponding record is generated in the defect case list. The record contains the use case ID of the defect case and the new defect number. The new defect number is assigned a defect hyperlink to the defect management system. When testers or developers click this hyperlink, they can directly jump to the defect management system to view the newly created defect details, allowing them to quickly analyze and fix the defect.

[0133] In one embodiment of the present application, in order to achieve two-way traceability of test cases and defects, the use case identifier associated with each defect number is also transmitted to the defect management system in real time, so that the defect management system establishes an association relationship between each defect number and its corresponding use case identifier, and deploys a use case hyperlink that jumps to the test management system at the use case identifier.

[0134] During the testing process, testers record test cases and execution results in the test management system, while developers handle defects in the defect management system. If only a defect hyperlink is configured in the test management system to jump to the defect management system, only test cases can be associated with defects. This cannot meet the developer's need to quickly locate the test case from the defect, affecting collaboration efficiency. Therefore, the embodiment of the present application also configures a link in the defect management system to jump to the test management system to implement a two-way traceability mechanism between test cases and defects.

[0135] Specifically, after the defect case list is generated and the test cases are associated with defect numbers, the use case identifier associated with each defect number is transmitted to the defect management system in real time. After receiving the use case identifier, the defect management system establishes an internal association between each defect number and the corresponding use case identifier and deploys a use case hyperlink to the test management system at the location of the use case identifier. When developers or other relevant personnel view defect details in the defect management system, they can simply click on the use case hyperlink to jump directly to the test management system to view the corresponding test case details, including the use case execution status, use case description, related logs, attachments, and other information.

[0136] Therefore, the embodiment of the present application not only realizes the tracing from test cases to defects, but also realizes the reverse tracing from defects to test cases by configuring hyperlinks in the defect management system, thereby realizing the construction of a two-way tracing mechanism, thereby greatly improving the collaboration efficiency between testing and development, reducing communication costs, and speeding up the defect repair.

[0137] In one embodiment of the present application, test hot words are extracted from the use case description of each use case in the incremental test data based on a keyword extraction algorithm, and the test hot words are displayed on the target terminal.

[0138] Numerous test case descriptions contain a variety of information, including functional points, scenarios, and operational steps. By extracting keywords from these descriptions, we can quickly identify key areas and trends in testing, helping testers focus on key test points and optimize testing strategies. This also helps managers quickly understand the scope and focus of testing.

[0139] Among them, the keyword extraction algorithm can be a TF-IDF (Term Frequency-Inverse Document Frequency) algorithm. The TF-IDF algorithm is a commonly used keyword extraction method that can measure the importance of a word in a document set. By calculating the frequency of each word in the use case description and the rarity of each word in the entire data, the TF-IDF algorithm can identify the most representative keywords.

[0140] Specifically, we perform text analysis on each use case description in the incremental test data and apply the TF-IDF algorithm to extract high-frequency keywords as test hot words. For example, if multiple test cases contain keywords such as "login function" or "payment process," these keywords will be identified as test hot words.

[0141] The extracted test hot words are displayed on the target terminal (such as the visual interface of the test management system). Typically, these hot words are presented in the form of a cloud chart, with hot words with higher frequency being displayed in larger fonts or more prominent colors, thus intuitively showing the focus and trends of the current test.

[0142] In one embodiment of the present application, the defect case list, various indicators in the test report, and test hot words can be displayed on the target terminal based on the open source data visualization analysis tool DataEase.

[0143] Specifically, given DataEase's support for building real-time dashboards from multiple data sources, including a rich variety of chart types and interactive features, this application can build a progress dashboard based on DataEase's visual interface on the target terminal, namely the test management system, that includes a list of defect cases, various indicators in the test report, and test hot words. The visual interface is updated at a set interval.

[0144] In one embodiment of the present application, the personnel efficiency details of each test team or each tester are extracted from test reports, defect case lists, etc., and a personnel efficiency table is generated. The personnel efficiency table is displayed on a visual interface to facilitate personnel management. The personnel efficiency table may include data on each tester's execution, pass, and failure on the day, such as the number of test cases executed, passed, and failed.

[0145] Figure 4 A schematic diagram of the structure of the test management system provided in an embodiment of the present application is shown.

[0146] refer to Figure 4 Based on the above test management method, the present application also provides a test management system, which includes:

[0147] The acquisition module 401 is used to obtain incremental test data from the test platform according to a set period and obtain defect-related data from the defect management system. The incremental test data includes multiple use cases and the use case identifier, use case description, execution status, and time field of each use case;

[0148] A cleaning module 402 is configured to clean invalid test cases in the incremental test data based on preset cleaning rules to obtain target incremental test data;

[0149] The defect analysis module 403 is configured to filter out use cases with a failed execution status from the target incremental test data as defective use cases; extract defect numbers from the use case descriptions of the defective use cases based on a preset regular expression and defect-related data; and generate a defect use case list based on the use case identifiers and corresponding defect numbers of the defective use cases. Each record in the defect use case list includes the use case identifier and the defect number with a defect hyperlink that redirects to the defect management system.

[0150] The report generation module 404 is used to generate a test report based on the incremental test data and the number of use cases in the target incremental test data and the execution status of each use case.

[0151] In one embodiment of the present application, the acquisition module includes:

[0152] The sending submodule is used to send a data acquisition request at a set period through the calling interface of the test platform and the defect management system, and the data acquisition request includes a timestamp;

[0153] A receiving submodule is used to receive the initial incremental test data and initial defect association data fed back by the test platform and the defect management system according to the timestamp;

[0154] The acquisition submodule is used to acquire the incremental test data and defect-related data that have changed compared with the historical data from the initial incremental test data and the initial defect-related data using a difference comparison algorithm.

[0155] In one embodiment of the present application, the system further includes:

[0156] The processing module is used to perform format standardization processing on the incremental test data, and the format standardization processing includes unifying the time field, execution status and priority format of each use case.

[0157] In one embodiment of the present application, the cleaning module includes:

[0158] The filtering submodule is used to filter out cases with illegal status codes in incremental test data;

[0159] The elimination submodule is used to eliminate use cases with abnormal time fields in incremental test data.

[0160] In one embodiment of the present application, the defect analysis module includes:

[0161] A verification submodule is used to extract the defect number from the use case description of the defect use case based on a preset regular expression, and to verify whether the defect number exists in the defect-related data;

[0162] The first establishing submodule is used to establish an association relationship between the use case identifier of the defect case and the defect number for each defect case whose defect number exists in the defect association data;

[0163] The first generation submodule is used to generate a defect use case list based on the association relationship of all defect use cases, each record including a use case identifier and a defect number with a defect hyperlink that jumps to a defect management system.

[0164] In one embodiment of the present application, the system further includes:

[0165] A control submodule, configured to control the defect management system to create a new defect and generate a new defect number for each defect case whose defect number does not exist in the defect-related data;

[0166] The second submodule is used to establish an association relationship between the use case identifier of the defect use case and the new defect number;

[0167] The second generation submodule is used to generate a corresponding record in the defect use case list according to the association relationship, where the record includes a use case identifier and a new defect number with a defect hyperlink that jumps to the defect management system.

[0168] According to an embodiment of the present application, the present application also provides an electronic device and a readable storage medium.

[0169] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement an embodiment of the present application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their links and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0170] like Figure 5 As shown, the device 500 includes a computing unit 501, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. Various programs and data required for the operation of the device 500 can also be stored in the RAM 503. The computing unit 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0171] Multiple components in device 500 are connected to I / O interface 505, including: an input unit 506, such as a keyboard, mouse, etc.; an output unit 507, such as various types of displays, speakers, etc.; a storage unit 508, such as a magnetic disk, optical disk, etc.; and a communication unit 509, such as a network card, modem, wireless communication transceiver, etc. The communication unit 509 allows device 500 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0172] The computing unit 501 can be a variety of general-purpose and / or specialized processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 501 performs the various methods and processes described above, such as the test management method. For example, in some embodiments, the test management method can be implemented as a computer software program that is tangibly contained in a machine-readable medium, such as the storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on the device 500 via the ROM 502 and / or the communication unit 509. When the computer program is loaded into the RAM 503 and executed by the computing unit 501, one or more steps of the test management method described above can be performed. Alternatively, in other embodiments, the computing unit 501 can be configured to perform the test management method by any other appropriate means (e.g., by means of firmware).

[0173] Various embodiments of the systems and techniques described above can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0174] The program code for implementing the methods of the present application can be written in any combination of one or more programming languages. Such program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the program code is executed by the processor or controller, the functions / operations specified in the flow charts and / or block diagrams are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0175] In the context of the present application, a machine-readable medium can be a tangible medium that can contain or store a program for use by an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical link based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0176] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0177] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0178] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship arises through computer programs running on the respective computers and having a client-server relationship with each other. The server may be a cloud server, a server in a distributed system, or a server integrated with a blockchain.

[0179] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this application can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this application can be achieved. This is not a limitation herein.

[0180] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the description of this application, "plurality" means two or more, unless otherwise specifically defined.

[0181] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A test management method, characterized in that: Applied to a test management system, the method includes: Acquire incremental test data from the test platform according to a set period, and acquire defect-related data from the defect management system, wherein the incremental test data includes multiple use cases and the use case identifier, use case description, execution status, and time field of each use case; Cleaning invalid test cases in the incremental test data based on preset cleaning rules to obtain target incremental test data; Filter the use cases with failed execution status from the target incremental test data as defective use cases; Extracting a defect number from a use case description of the defect use case based on a preset regular expression and the defect-related data, and generating a defect use case list based on a use case identifier of the defect use case and the corresponding defect number, wherein each record in the defect use case list includes a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system; A test report is generated based on the number of use cases in the incremental test data and the target incremental test data and the execution status of each use case.

2. The method according to claim 1, characterized in that Acquire incremental test data from the test platform according to the set period, and obtain defect-related data from the defect management system, including: Sending a data acquisition request at a set period through the calling interface of the test platform and the defect management system, wherein the data acquisition request includes a timestamp; receiving initial incremental test data and initial defect association data fed back by the test platform and the defect management system according to the timestamp; A difference comparison algorithm is used to obtain incremental test data and defect-related data that have changed compared with historical data from the initial incremental test data and initial defect-related data.

3. The method according to claim 1, characterized in that Before cleaning invalid use cases in the incremental test data based on preset cleaning rules, the method further includes: Format standardization is performed on the incremental test data, wherein the format standardization includes unifying the format of the time field, execution status, and priority of each use case.

4. The method according to claim 1, wherein Cleaning invalid use cases in the incremental test data based on preset cleaning rules includes: Filtering use cases with illegal status codes in the incremental test data; Eliminate use cases with abnormal time fields in the incremental test data.

5. The method according to claim 1, wherein Extracting a defect number from the use case description of the defect use case based on a preset regular expression and the defect-related data, and generating a defect use case list based on the use case identifier of the defect use case and the corresponding defect number, including: Extract the defect number from the use case description of the defect use case based on the preset regular expression, and verify whether the defect number exists in the defect-related data; For each defect case whose defect number exists in the defect association data, establishing an association relationship between the case identifier of the defect case and the defect number; A defect use case list is generated based on the association relationship of all defect use cases, each record including a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system.

6. The method according to claim 5, characterized in that The method further comprises: For each defect case whose defect number does not exist in the defect-related data, controlling the defect management system to create a new defect and generate a new defect number; Establish an association between the use case identifier of the defect use case and the new defect number; A corresponding record is generated in the defect use case list according to the association relationship, and the record includes a use case identifier and a new defect number with a defect hyperlink that jumps to the defect management system.

7. The method according to claim 6, characterized in that The method further comprises: The use case identifier associated with each defect number is transmitted to the defect management system, so that the defect management system establishes an association relationship between each defect number and its corresponding use case identifier, and deploys a use case hyperlink that jumps to the test management system at the use case identifier.

8. The method according to claim 1, characterized in that The test report includes the use case execution rate, the use case pass rate and the number of use cases in each execution status. The execution status includes pass, fail, skip and block.

9. The method according to claim 8, characterized in that Generate a test report based on the number of use cases in the target incremental test data and the execution status of each use case, including: Calculating a use case execution rate based on the total number of use cases in the target incremental test data and the number of executed use cases; Calculate the use case pass rate based on the total number of use cases in the target incremental test data and the number of use cases with a pass status. Calculate the number of use cases in each execution state in the target incremental test data.

10. The method according to claim 9, characterized in that The test report also includes the total number of use cases, the number of executed use cases, the number of use cases to be executed, the use case failure rate and the use case blocking rate.

11. The method according to claim 1, wherein The method further comprises: Display the defect case list and test report on the target terminal.

12. The method according to claim 1, characterized in that The method further comprises: Based on a keyword extraction algorithm, test hot words are extracted from the use case description of each use case in the incremental test data, and the test hot words are displayed on the target terminal.

13. A test management system, characterized in that: The system comprises: The acquisition module is used to obtain incremental test data from the test platform according to a set period and obtain defect-related data from the defect management system. The incremental test data includes multiple use cases and the use case identification, use case description, execution status and time field of each use case; A cleaning module, configured to clean invalid test cases in the incremental test data based on preset cleaning rules to obtain target incremental test data; A defect analysis module is used to filter out use cases with a failed execution status from the target incremental test data as defective use cases; extract defect numbers from the use case descriptions of the defective use cases based on a preset regular expression and the defect-related data; and generate a defect use case list based on the use case identifiers and corresponding defect numbers of the defective use cases, wherein each record in the defect use case list includes a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system; The report generation module is used to generate a test report based on the number of use cases in the incremental test data and the target incremental test data and the execution status of each use case.

14. The system according to claim 13, wherein: The acquisition module includes: A sending submodule, configured to send a data acquisition request at a set period through a calling interface of the test platform and the defect management system, wherein the data acquisition request includes a timestamp; A receiving submodule, configured to receive the initial incremental test data and initial defect association data fed back by the test platform and the defect management system according to the timestamp; The acquisition submodule is used to acquire the incremental test data and defect-related data that have changed compared with the historical data from the initial incremental test data and the initial defect-related data using a difference comparison algorithm.

15. The system according to claim 13, wherein: The system further comprises: The processing module is used to perform format standardization processing on the incremental test data, wherein the format standardization processing includes unifying the format of the time field, execution status and priority of each use case.

16. The system according to claim 13, wherein: The cleaning module includes: A filtering submodule, configured to filter out use cases with illegal status codes in the incremental test data; The elimination submodule is used to eliminate use cases with abnormal time fields in the incremental test data.

17. The system according to claim 13, wherein: The defect analysis module includes: A verification submodule is used to extract the defect number from the use case description of the defect use case based on a preset regular expression, and to verify whether the defect number exists in the defect-related data; A first establishing submodule is configured to establish, for each defect case whose defect number exists in the defect association data, an association relationship between the use case identifier of the defect case and the defect number; The first generation submodule is used to generate a defect use case list based on the association relationship of all defect use cases, each record including a use case identifier and a defect number with a defect hyperlink that jumps to the defect management system.

18. The system according to claim 17, wherein: The system further comprises: A control submodule, configured to control the defect management system to create a new defect and generate a new defect number for each defect case whose defect number does not exist in the defect association data; The second submodule is used to establish an association relationship between the use case identifier of the defect use case and the new defect number; The second generation submodule is used to generate a corresponding record in the defect use case list according to the association relationship, where the record includes a use case identifier and a new defect number with a defect hyperlink that jumps to the defect management system.

19. An electronic device, characterized in that: include: at least one processor; as well as a memory communicatively linked to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 12.

20. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 12.

Images