Test record automatic verification method and device and storage medium

Abstract

The invention relates to a test record automatic verification method and device and a storage medium, and the method comprises the steps: obtaining a to-be-verified test record, carrying out the mutual verification of the test record, and verifying a system-level test case result in a test case preliminary result list after the mutual verification is completed; wherein the mutual verification comprises the following steps: whether item points of the use cases needing to be modified in the product problem record list are correctly associated to the use case modification list or not; whether item points needing to submit defects are correctly associated to a test case preliminary result list or not is judged; whether all defects listed in the system-level test influence analysis file are correct or not is verified, a result is obtained, and whether the defects are circulated according to the correct result or not is judged; and updating the mutual verification result into the current test form of the system-level test report. Compared with the prior art, the verification process and system provided by the invention perform cross verification by taking the result as the guide, so that the correctness of the result is ensured, and the communication cost caused by human negligence can be saved.

Description

Technical Field

[0001] The invention relates to the technical field of rail transit control system testing and verification, and in particular to an automatic verification method for test records. Background Art

[0002] With the development of intelligence, urban rail transit has increasingly higher requirements for the flexibility and reliability of subway signal systems. The Train Autonomous Control System (TACS) has emerged as a new generation of urban rail transit products. It has a streamlined architecture and extremely high performance. It is a more reliable, efficient and flexible choice for urban rail transit. System-level testing is an important part of product quality assurance, and the accuracy and reliability of its test results are crucial.

[0003] During the system-level test of the train autonomous operation system TACS, after completing the test work of this round of test items, a series of test records will be obtained, such as the verification results of defects in the impact analysis, the verification results of test cases, the test problems and the confirmation results of R&D analysis, etc. We need to quickly and accurately verify these complex records and extract the test results we need in the end. And as continuous integration becomes more and more in-depth, the test cycle will become faster and faster. The method of manually checking and obtaining the final test results for each version is very time-consuming and inefficient. And in the case of a larger version or a large baseline upgrade, the version test will contain at least dozens of defects, hundreds of test cases, and hundreds of test problems involved. The method of manually reviewing and confirming all these test records and finally obtaining the test conclusion is not only inefficient, but also more prone to misjudgment and omissions, affecting the test pass rate and subsequent documentation work. Summary of the invention

[0004] The purpose of the present invention is to overcome the defects of the above-mentioned prior art and provide a method, device and storage medium for automatically verifying test records and automatically obtaining test results.

[0005] The purpose of the present invention can be achieved by the following technical solutions:

[0006] As a first aspect of the present invention, a method for automatic verification of test records is provided, the steps comprising:

[0007] Obtain the test records to be verified, including the test case modification list, product problem record list, test case preliminary result list, and system-level test impact analysis file;

[0008] The test records are mutually verified, and after the mutual verification is completed, the system-level test case results in the test case preliminary result list are checked; wherein the mutual verification includes: whether the items in the product problem record list that need to modify the test case are correctly associated with the test case modification list; whether the items that need to submit defects are correctly associated with the test case preliminary result list; whether all defects listed in the system-level test impact analysis file are correctly verified and the results are obtained, and whether the defects have been transferred according to the correct results;

[0009] The mutual verification results are updated in the current test round form of the system-level test report.

[0010] As a preferred technical solution, it is verified whether the item points of the use case that needs to be modified in the product problem record list are correctly associated with the use case modification list, specifically: verify whether the items of the use case that need to be modified in the final judgment result of the product problem record list have been included in the use case modification list, and verify the content format included in the use case modification list, the steps are as follows:

[0011] Record the test case name in the test case modification list, record the specific modification content, and mark from issuelist XXX; the recorded test case name should be consistent with the test case name in the product issue record list;

[0012] After filtering the baseline of this version in the product problem record list, check whether the content in the final judgment result of the problem final status column in the product problem record list contains use cases that need to be modified;

[0013] When a test case needs to be modified, search for the corresponding test case in the test case modification list;

[0014] If there is a corresponding need to modify the use case, it is passed;

[0015] If there is no corresponding use case that needs to be modified, list the ID number of the product problem record list that needs to be modified and the corresponding name of the relevant test responsible person.

[0016] As a preferred technical solution, the retrieval basis for searching the test case modification list for the case that needs to be modified includes: whether there is the case number; whether there is the words "from issue list" and whether the ID number corresponds to the ID number in the product problem record list;

[0017] As a preferred technical solution, after verification of whether the items of the use case that need to be modified have been included in the use case modification list is completed, a first result file is obtained that lists the final judgment results of the product problem record list, which lists the use cases that need to be modified but have not been added to the use case modification list. The first result file includes: the id number of the product problem record list, the corresponding use case number, the submitter, and the reason for the error.

[0018] As a preferred technical solution, verify whether the item points that need to submit defects are correctly associated with the preliminary result list of the test case, specifically:

[0019] The final judgment result of the product problem record list contains items that need to submit defects, that is, the status in the final judgment result contains open, which is a problem and needs to submit a CR;

[0020] After filtering the baseline of this version in the product problem record list, check whether the final judgment result of the product problem record list contains open, and whether the listed defect numbers contain incorrect defect numbers and defect numbers that are not filled in;

[0021] Verify whether the defects of the open items in the product problem record list have been associated with the test case preliminary result list, that is, the defect numbers in the product problem record list are associated with the test case preliminary result list.

[0022] As a preferred technical solution, the items that need to submit defects have been correctly associated with the preliminary result list of the test case. After verification, a second result file is obtained, which includes:

[0023] The final judgment result of the product problem record list shows that the status is open, but there is no defect number tracking; the ID number and submitter of the product problem record list and the reason for the error are listed;

[0024] The status of the final judgment result of the product problem record list is open, but the defect number filled in is not associated with the corresponding use case in the test case preliminary result list according to the use case number; list the id number of the product problem record list, the corresponding use case number and the submitter, as well as the cause of the error.

[0025] As a preferred technical solution, it is verified whether all defects listed in the impact analysis file are correct and the results are obtained, specifically:

[0026] Record the verification results of the impact analysis related defects in the Impact Analysis CR sheet of the test case preliminary results list, and check the pass / fail results of the defect verification in the impact analysis;

[0027] According to the test case number, find the corresponding test case in the preliminary test case result list, and update the result according to the format for the found test case.

[0028] As a preferred technical solution, after the verification is completed, a third result file is obtained, the content of which includes:

[0029] Check the results of the CR in the K2_CR_Analysis sheet in the Impact AnalysisCR sheet of the test case preliminary results list, and verify whether all the use cases of the CR in the impact analysis are associated with the system-level confirmation test case RTD / system-level integration test case ITD in the test case preliminary results list;

[0030] If there is no association or the association is incorrect, list the CR number, use case number and the reason for the error: the two do not match and the person responsible.

[0031] As a preferred technical solution, when checking whether all use cases of the CR in the impact analysis are associated in the system-level confirmation test case RTD / system-level integration test case ITD in the test case preliminary result list, non-compliant text descriptions are also judged as errors.

[0032] As a preferred technical solution, column B in the third result file is the use case not associated with the CR, column C is the use case with incorrect CR results, column D is the CR results filled in the use case, and column E is the CR results in the Impact Analysis CR sheet.

[0033] As a preferred technical solution, verify whether the defect has been transferred on the CQ library according to the correct result, specifically:

[0034] After defect transfer, check the following based on the verification results of defects related to this round of impact analysis: whether the final status of defects in the CQ library is consistent with the results of the preliminary result list of test cases;

[0035] Verify the results of defect flow: crawl the results of all defects in the impact analysis, that is, the status includes: Submitted / Recorded / Analysed / Safety_Analysed / Assigned / Realised / Validate_Failed / Validated / Closed / Rejected;

[0036] Correctly verified defect results, that is, the results found in the Impact Analysis CR sheet of the test case preliminary results list, with a status of Closed / Validate_Failed;

[0037] For defects with incorrect status, list the Submitter field to find the responsible person.

[0038] As a preferred technical solution, after the defect has been correctly transferred and verified, a fourth result file is obtained, including:

[0039] If all defect results in the impact analysis are inconsistent with the defect status in the CQ library, list the defect number, status in the CQ library, results of the impact analysis, and submitter.

[0040] As a preferred technical solution, the system-level test case results in the preliminary result list of the verification test cases are specifically:

[0041] The principles for checking whether the results of the preliminary results list of test cases need to be changed include:

[0042] KO: If there is no bracket after the defect in the preliminary result list of the inspection trial case, or there is a verification failure in the bracket after the defect, it is KO;

[0043] OK: Check the preliminary result list of the trial case. If there is no defect in column R / the results in brackets after the defect are all verified passed / the word "closed" is after the defect / the word "rejected" is after the defect, it is OK;

[0044] NA: Due to R&D restrictions, the conclusion remains unchanged, ensuring that the limitations and defects in the preliminary results list of the trial cases are open; because the product is not compatible, the conclusion remains unchanged;

[0045] NT: The conclusion of NT remains unchanged. Check the CR in the R column of the preliminary result list of the trial case. There should be no defects or defects followed by verification.

[0046] 14. A test record automatic verification method according to claim 13, characterized in that after the verification is completed, a fifth result file is obtained, which lists the use case number, current result, judgment result, defect result summary (result of column R in the preliminary result list of the trial case), submitter and remarks of the test case preliminary result list with incorrect conclusion.

[0047] As a second aspect of the present invention, there is provided a test record automatic verification device, comprising a memory, a processor, and a program stored in the memory, wherein the processor implements the test record automatic verification method as described above when executing the program.

[0048] As a third aspect of the present invention, there is provided a storage medium having a program stored thereon, wherein the program, when executed, implements the test record automatic verification method as described above.

[0049] Compared with the prior art, the present invention has the following beneficial effects:

[0050] 1) The present invention can verify the results of all files generated during the test process to ensure that each link of the test, such as impact analysis defect testing, system-level test case testing, case modification, defect submission and other links are verified with each other, avoiding errors in the Test Record file ultimately used as input for the system-level test report due to errors in the intermediate links, greatly reducing errors caused by human negligence, thereby reducing the rework rate and saving labor costs.

[0051] 2) The verification process and system proposed by the present invention are more conducive to collaborative testing work among multiple people. The test documents filled out by multiple people can be cross-checked based on the results, ensuring the correctness of the results and saving the communication costs caused by human negligence.

[0052] 3) The present invention is universal and can be used to verify the results of all baseline system-level testing work using the TACS platform;

[0053] 4) For less mature and stable product lines, the logic design of this verification method is more comprehensive. It not only takes into account the test results of the test cases, but also takes into account the possible design errors of the test cases. Therefore, based on multi-party verification, the correct test results can be obtained to avoid misjudgment and omission of test results, which will affect the test pass rate and subsequent documentation work. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 A schematic diagram of the process flow of the automatic verification method of test records of the present invention;

[0055] Figure 2 The figure is a schematic diagram of the process of performing verification and checking specifically for the present invention. DETAILED DESCRIPTION

[0056] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. This embodiment is implemented based on the technical solution of the present invention, and provides a detailed implementation method and specific operation process, but the protection scope of the present invention is not limited to the following embodiments.

[0057] Example 1

[0058] The present invention aims at the need to perform multi-faceted verification on the test records generated by the test after the test work is completed and before the test report is written, so as to obtain the correct results of the test cases required by the test report.

[0059] First, you need to prepare the files that need to be verified, which are: test case modification list, product problem record list (issue list), test case preliminary result list (KPI list), system-level test impact analysis file. By verifying these files as materials, you can get the correct test case results of the system-level test. These results can eventually be directly updated to the current test form (Test Record) of the system-level test report, thus becoming the input source for the test report to draw the correct conclusions of this round of testing.

[0060] A method for automatically verifying test records and automatically obtaining test results, the method comprising the following steps:

[0061] Step S1, input the files to be verified, including: test case modification list, product problem record list (issuelist), test case preliminary result list (KPI list), system-level test impact analysis file;

[0062] The meaning of each column in the product problem record list issue list used in this embodiment is specifically as follows:

[0063] Column A: Issue number; Column B: Issue title; Column C: Issue creation date; Column D: Test platform number where the issue was discovered; Column E: Baseline number where the issue was discovered; Column F: Issue priority; Column G: Issue-related test case number; Column H: Specific description of the issue; Column I: Issue storage log path; Column J: Issue severity level, specifically divided into 5 states: Critical (very serious) / Major (serious) / Average (average) / Minor (minor) / Enhancement (improvement and enhancement); Column K: Issue final status, specifically divided into closed (issue closed) / not issue (not an issue in itself) / open (issue, need to submit CR) / test case (test case issue) / pending to open (final result has not yet been determined) and multiple options can be selected if multiple situations occur; Column M: Associated CR number (CR, change request, that is, the defect change record submitted for the issue); Column P: Name of the person responsible for the relevant test;

[0064] Step S2: For the verification files prepared in the above steps, we need to set the verification target, that is, after verifying the test case modification list, issue list, KPI list, and system-level test impact analysis file, we ensure that the items in the issue list that need to modify the test case are correctly associated with the test case modification list, the items that need to submit defects are correctly associated with the KPI list, all defects listed in the system-level test impact analysis file are verified and the results are obtained, and these defects have been circulated on the CQ library according to the correct results, and based on the above verification results, further verify the system-level test case results in the KPI list and obtain the final results, so that they can be directly updated into the Test Record.

[0065] Step S3: Design verification rules and formulate verification strategies according to the above verification objectives. The verification strategies can be divided into the following five specific verification items:

[0066] Step 301: Check whether the items of the test case that need to be modified have been included in the test case modification list:

[0067] The final determination result of the final status of the issue in column K of the issue list includes items that need to modify the test case. It is necessary to verify whether these test case items have been included in the test case modification list, and to check the format of the content included in the test case modification list, including: writing the test case name in column A of the test case modification list: egQiji-SyRTD-834 (needs to be consistent with the test case name in column G of the issue list); and writing the specific modification content in column B, and marking column E with from issuelist XXX.

[0068] After filtering the baseline of this version from the baseline numbers found in the problem in column E of the issue list, check if there is any test case in the final judgment result of the final status of the problem in column K, and search in the use case modification list: first, whether there is the use case number in column A; second, whether there is the words from issue list in column E, and the id must match (match the id of the problem number in column A of the issue list); if there is, it is passed; if not, it is necessary to list the id numbers of the issue list (in a new sheet, and also list the corresponding names of the relevant test responsible persons in column P of the issue list), that is, these ids have not been added to the use case modification list.

[0069] After the verification is completed, you can get an EXCEL file with the first sheet [Issue list and use case modification tracking], which lists the issues in column K on the issue list whose final status is test case but not added to the use case modification list. It records the issue list id number, the corresponding use case number and the submitter, as well as the reason for the error. If the list is empty, it means everything has been completed and there is no problem.

[0070] Step 302: Check whether the defect of the Open item has been associated with the KPI list:

[0071] The final judgment results in column K of the issue list contain items that need to submit defects (that is, the final judgment results in column K contain open items). It is necessary to verify whether the defects of the open items in the issue list have been associated with the KPI, that is, the defect numbers in column M of the issue list are associated with the defect limits in column R of the KPI list.

[0072] After filtering the baseline of this version from the baseline number found in the problem in column E of the issue list, check whether the content in the final status of the problem in column K contains open (not pending to open), the defect number listed in the CR number associated with column M (including the case where the defect number is incorrect or not filled in), and search in the test case number related to the problem in column G to see whether the defect number has been associated with column R on the KPI list.

[0073] After the verification is completed, you can get an EXCEL file of the results. The second sheet [Defect-related KPI] contains two types of content:

[0074] The first is the list of issues whose status is open in column K but no defect number is tracked in column M. List the issuelist id number, submitter, and error reason.

[0075] The second is that the status of column K on the issue list is open, but the defect number filled in column M is not associated with the corresponding use case in the KPI according to the use case number in column G (including under-filling and incorrect filling). List the id number of the issue list, the corresponding use case number and the submitter, as well as the reason for the error.

[0076] If the list is empty, it means everything is completed and there is no problem.

[0077] Step 303: Check whether the impact analysis defect verification result has been updated:

[0078] In the Impact Analysis CR sheet in the KPI table, the verification results of defects related to the impact analysis are recorded. The pass / fail results of the defect verification in the impact analysis need to be verified: whether these test cases have been found in the KPI list according to the test case numbers listed in the E column of the sheet, and the results in the R column of these test cases have been updated according to the format. Taking the impact analysis as the source, check whether the defects in the K2_CR_Analysis sheet appear in the test cases included in the G / H / I columns of the Impact Analysis CR sheet. The results refer to the G / H / I columns of the Impact Analysis CR sheet on the KPI list; and the text description should be: TACS100000525 (111B2 verification passed / failed).

[0079] Format example: TACS100000277 (111B2 verification failed) / TACS100000414 (111B2 verification passed).

[0080] After verification, you can get a result EXCEL file. On the third sheet [Impact Analysis Verification Defects], check the results of the CR in column A of K2_CR_Analysis sheet in column G of Impact Analysis CR sheet on KPI; and whether all the use cases of the CR in columns G / H / I of the impact analysis are associated with column R of RTD (system-level confirmation test case) / ITD (system-level integration test case) of KPI. If there is no association or the association is wrong (non-compliant text description will also be judged as an error), list the CR number, use case number (column B is the use case that is not associated with the CR, column C is the use case with wrong CR result) and the reason for the error: the two do not match (column D is the CR result filled in the use case, column E is the CR result in Impact Analysis) and the person in charge. If the list is empty, it means everything has been completed and there is no problem.

[0081] Step 304: Whether the defect has been correctly transferred:

[0082] According to the verification results of the defects related to this round of impact analysis: verification passed or verification failed; after the defect flow, it is necessary to verify whether the final status of the defect in the CQ library is consistent with the result filled in the R column of the KPI list.

[0083] Check the defect flow results: crawl the defect results of all defects in the impact analysis, that is, "State:", the states are: eg; Submitted / Recorded / Analysed / Safety_Analysed / Assigned / Realised / Validate_Failed / Validated / Closed / Rejected; and the defect result of correct verification (see the G column of the Impact Analysis CR sheet of the KPI list to find the result) must be Closed / Validate_Failed, the other states are incorrect, list the defects with incorrect states in the Submitter field, that is, find the responsible person. For example: TACS100000814 (rejected) / TACS100000553 (closed).

[0084] After the tool is verified, you can get an EXCEL file of the results. In the fourth sheet [Defect Flow], check whether all the defect results in the impact analysis are consistent with the defect status in the CQ library. If they are inconsistent, list the defect number, status in the CQ library, impact analysis results, and submitter. If the list is empty, it means everything has been completed and there is no problem.

[0085] Step 305: Check the system-level test case results in the KPI list:

[0086] After completing the above steps, you need to check the results in the Result column (column I) in the KPI list to see if they need to be changed, because the defect status in column R may have changed.

[0087] Inspection principles:

[0088] KO (failed): Check if there is no bracket after the defect in the R column or there is a verification failure in the bracket after the defect, which means KO;

[0089] OK (passed): Check if there are no defects in column R / the results in brackets after defects are all verified to have passed / there is a word (closed) after the defect / there is a word (rejected) after the defect, which means OK;

[0090] NA (not available for this product): There are two types of NA. One is NA due to R&D restrictions. The conclusion remains unchanged, and the restriction defects in column R are still open. The other is NA due to not applicable for Qiji, which means it is not suitable for the current product, and the conclusion remains unchanged.

[0091] NT (untestable): The conclusion of NT remains unchanged because the defect in column R leads to the result NT, so as long as the CR in column R is checked, there must be no defect or the defect is followed by verification.

[0092] After the verification is completed, you can get an EXCEL file of the results. The fifth sheet [KPI Use Case Results] lists the use case number, current result, judgment result, defect result summary (KPI R column result), submitter, and remarks of the incorrect conclusion of KPIlist. If the list is empty, it means that everything has been completed and there is no problem.

[0093] Step S4: Run the tool, automatically read the input file, and determine the correct result according to the verification rules set by the algorithm. The result can be directly used for test record update.

[0094] The method of automatically verifying test records and automatically obtaining test results based on the above algorithm can significantly improve the efficiency of test report writing, effectively collect all evidence of system-level and subsystem-level requirement testing and classify and summarize it, flexibly determine the requirement conclusions through the algorithm, and innovatively adopt the regression judgment method. The judgment logic design is more comprehensive, further improving the accuracy, and is faster than manual collection and judgment, which is of great help to the writing of test reports.

[0095] It can quickly verify all test record files generated during the testing process, ensuring the correctness and uniformity of each link of the test, such as impact analysis defect testing, system-level test case testing, case modification, defect submission, etc. It greatly reduces incorrect test results due to human negligence and greatly reduces the rework rate. In addition, through verification, the way of filling in test record files is also standardized. This design is more suitable for test products that require multi-person collaboration and ensures accuracy and traceability.

[0096] Example 2

[0097] As a second aspect of the present invention, the present application also provides an electronic device, comprising: one or more processors; a memory for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the above-mentioned test record automatic verification method. In addition to the above-mentioned processor, memory and interface, any device with data processing capability in which the device in the embodiment is located may also include other hardware according to the actual function of the device with data processing capability, which will not be described in detail.

[0098] The processor may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of processors include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The processor performs the various methods and processes described above, such as methods of image processing and / or methods of model training. For example, in some embodiments, the methods of image processing and / or methods of model training may be implemented as computer software programs, which are tangibly contained in machine-readable media, such as storage units. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via a ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the processor, one or more steps of the methods of image processing and / or methods of model training described above may be performed. Alternatively, in other embodiments, the processor may be configured to perform methods of image processing and / or methods of model training by any other appropriate means (e.g., by means of firmware).

[0099] Example 3

[0100] As a third aspect of the present invention, the present application also provides a computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by the processor, the automatic verification method of the test record as described above is implemented. The machine-readable medium can be a tangible medium, which 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. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the above. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above.

[0101] The preferred specific embodiments of the present invention are described in detail above. It should be understood that a person skilled in the art can make many modifications and changes based on the concept of the present invention without creative work. Therefore, any technical solution that can be obtained by a person skilled in the art through logical analysis, reasoning or limited experiments based on the concept of the present invention on the basis of the prior art should be within the scope of protection determined by the claims.

Claims

1. A method for automatic verification of test records, characterized in that: The steps include: Obtain the test records to be verified, including the test case modification list, product problem record list, test case preliminary result list, and system-level test impact analysis file; The test records are mutually verified, and after the mutual verification is completed, the system-level test case results in the test case preliminary result list are checked; wherein the mutual verification includes: whether the items in the product problem record list that need to modify the test case are correctly associated with the test case modification list; whether the items that need to submit defects are correctly associated with the test case preliminary result list; whether all defects listed in the system-level test impact analysis file are correctly verified and the results are obtained, and whether the defects have been transferred according to the correct results; The mutual verification results are updated in the current test round form of the system-level test report.

2. A test record automatic verification method according to claim 1, characterized in that: Verify whether the item points of the use case that needs to be modified in the product problem record list are correctly associated with the use case modification list, specifically: verify whether the items of the use case that needs to be modified in the final judgment result of the product problem record list have been included in the use case modification list, and check the content format included in the use case modification list, the steps are as follows: Record the test case name in the test case modification list, record the specific modification content, and mark it as from issue listXXX; the recorded test case name should be consistent with the test case name in the product issue record list; After filtering the baseline of this version in the product problem record list, check whether the content in the final judgment result of the problem final status column in the product problem record list contains use cases that need to be modified; When a test case needs to be modified, search for the corresponding test case in the test case modification list; If there is a corresponding need to modify the use case, it is passed; If there is no corresponding use case that needs to be modified, list the ID number of the product problem record list that needs to be modified and the corresponding name of the relevant test responsible person.

3. A test record automatic verification method according to claim 2, characterized in that: The retrieval basis for searching the test case modification list for the corresponding test case to be modified includes: whether there is the test case number; whether there is the words "from issuelist" and whether the ID number corresponds to the ID number of the product problem record list.

4. A test record automatic verification method according to claim 2, characterized in that: After verification of whether the items of the use case that need to be modified have been included in the use case modification list is completed, a first result file is obtained that lists the final judgment results of the product problem record list, which lists the use cases that need to be modified but have not been added to the use case modification list. The first result file includes: the ID number of the product problem record list, the corresponding use case number, the submitter, and the reason for the error.

5. A test record automatic verification method according to claim 1, characterized in that: Verify whether the items for which defects need to be submitted are correctly associated with the preliminary result list of the test case, specifically: The final judgment result of the product problem record list contains items that need to submit defects, that is, the status in the final judgment result contains open, which is a problem and needs to submit a CR; After filtering the baseline of this version in the product problem record list, check whether the final judgment result of the product problem record list contains open, and whether the listed defect numbers contain incorrect defect numbers and defect numbers that are not filled in; Verify whether the defects of the open items in the product problem record list have been associated with the test case preliminary result list, that is, the defect numbers in the product problem record list are associated with the test case preliminary result list.

6. A test record automatic verification method according to claim 5, characterized in that: After the items that need to submit defects have been correctly associated with the preliminary result list of the test case, the second result file is obtained, which includes: The final judgment result of the product problem record list shows that the status is open, but there is no defect number tracking; the ID number and submitter of the product problem record list and the reason for the error are listed; The status of the final judgment result of the product problem record list is open, but the defect number filled in is not associated with the corresponding use case in the test case preliminary result list according to the use case number; list the id number of the product problem record list, the corresponding use case number and the submitter, as well as the cause of the error.

7. A test record automatic verification method according to claim 1, characterized in that: Verify that all defects listed in the impact analysis file are correct and obtain the results, specifically: Record the verification results of the impact analysis related defects in the Impact Analysis CR sheet of the test case preliminary results list, and check the pass / fail results of the defect verification in the impact analysis; According to the test case number, find the corresponding test case in the preliminary test case result list, and update the result according to the format for the found test case.

8. A test record automatic verification method according to claim 7, characterized in that: After the verification is completed, a third result file is obtained, the content of which includes: Check the results of CR in K2_CR_Analysis sheet in Impact Analysis CRsheet of Test Case Preliminary Results List, and verify whether all the cases of the CR in Impact Analysis are associated in System Level Confirmation Test Case RTD / System Level Integration Test Case ITD of Test Case Preliminary Results List; If there is no association or the association is incorrect, list the CR number, use case number and the reason for the error: the two do not match and the person responsible.

9. A test record automatic verification method according to claim 8, characterized in that: When checking whether all the use cases of the CR in the impact analysis are associated in the system-level confirmation test case RTD / system-level integration test case ITD in the preliminary result list of the test case, non-compliance of the text description is also determined as an error.

10. A test record automatic verification method according to claim 8, characterized in that: In the third result file, column B is the use case that is not associated with the CR, column C is the use case with incorrect CR results, column D is the CR results filled in the use case, and column E is the CR results in the Impact Analysis CR sheet.

11. A test record automatic verification method according to claim 1, characterized in that: Verify whether the defect has been transferred on the CQ library according to the correct result, specifically: After defect transfer, check the following based on the verification results of defects related to this round of impact analysis: whether the final status of defects in the CQ library is consistent with the results of the preliminary result list of test cases; Verify the results of defect flow: crawl the results of all defects in the impact analysis, that is, the status includes: Submitted / Recorded / Analysed / Safety_Analysed / Assigned / Realised / Validate_Failed / Validated / Closed / Rejected; Correctly verified defect results, that is, the results found in the Impact Analysis CR sheet of the test case preliminary results list, with a status of Closed / Validate_Failed; For defects with incorrect status, list the Submitter field to find the responsible person.

12. A test record automatic verification method according to claim 11, characterized in that: After the defect has been correctly transferred and verified, the fourth result file is obtained, including: If all defect results in the impact analysis are inconsistent with the defect status in the CQ library, list the defect number, status in the CQ library, results of the impact analysis, and submitter.

13. A test record automatic verification method according to claim 1, characterized in that: The system-level test case results in the preliminary result list of the verification test cases are specifically: The principles for checking whether the results of the preliminary results list of test cases need to be changed include: KO: If there is no bracket after the defect in the preliminary result list of the inspection trial case, or there is a verification failure in the bracket after the defect, it is KO; OK: Check the preliminary result list of the trial case. If there is no defect in column R / the results in brackets after the defect are all verified passed / the word "closed" is after the defect / the word "rejected" is after the defect, it is OK; NA: Due to R&D restrictions, the conclusion remains unchanged, ensuring that the limitations and defects in the preliminary results list of the trial cases are open; because the product is not compatible, the conclusion remains unchanged; NT: The conclusion of NT remains unchanged. Check the CR in the R column of the preliminary result list of the trial case. There should be no defects or defects followed by verification.

14. A test record automatic verification method according to claim 13, characterized in that: After the verification is completed, the fifth result file is obtained, which lists the case number, current result, judgment result, defect result summary (result of column R in the preliminary result list of the test case), submitter and remarks of the case with incorrect conclusion in the preliminary result list of the test case.

15. A test record automatic verification device, comprising a memory, a processor, and a program stored in the memory, characterized in that: When the processor executes the program, the test record automatic verification method as described in any one of claims 1-14 is implemented.

16. A storage medium having a program stored thereon, characterized in that: When the program is executed, the test record automatic verification method as described in any one of claims 1-14 is implemented.

Images