A static checking method based on XML test script code

Abstract

The present invention discloses a static inspection method based on XML test script code, comprising the following steps: S1, building an inspection rule base; S2, loading a script code file to be inspected and performing preprocessing to obtain a plurality of script code subfiles; S3, sequentially matching an inspection specification list of the script code subfiles; S4, sequentially testing the script code subfiles according to the detection logic of the inspection specification table; S5, if a test failure occurs, executing S6; if the test does not fail, executing S9; S6, performing a fault analysis and correction on the fault section information, and then performing a regression static inspection; S7, repeatedly executing S5-S6 according to a set execution number threshold, and if the number of repetitions exceeds the threshold, executing S8; S8, associating the label of the script code subfile with the test failure to a fault shared container; S9, weaving the plurality of script code subfiles to obtain a target script code file. The scheme significantly improves the efficiency of test script code detection and avoids the problem of missed detection.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to a static checking method based on XML test script code. Background Art

[0002] Software testing methods primarily include manual testing and automated testing. With the continued increase in testing workload and rising labor costs, automated testing is becoming increasingly important. As test script code continues to grow and be modified, the amount of test script review required to ensure automated testing quality also increases. When test scripts reach hundreds of thousands or even millions of lines of code, relying entirely on manual review becomes unrealistic. Summary of the Invention

[0003] The purpose of the present invention is to solve the problems of low efficiency and easy omission of test script code detection in the prior art, and proposes an XML-based test script language for writing automated test scripts. The script language used is the same as the script code to be checked, which has good scalability and is reusable. It can replace a large amount of manual inspection workload and significantly improve the efficiency of test script code detection. At the same time, it can record inspection rules that fail static inspection, support regression inspection after the test script problem is repaired, and avoid the problem of omission.

[0004] A technical solution provided in an embodiment of the present invention is a static inspection method based on XML test script code, comprising the following steps:

[0005] S1. Build a detection rule base, and establish a mapping between the detection rule base and the script parsing executor;

[0006] S2. The script parsing executor loads the script code file to be detected and preprocesses the script code file to obtain several script code sub-files;

[0007] S3. The script parsing executor sequentially matches the inspection specification list of the script code sub-file, wherein the inspection specification list sequentially associates the inspection entry instructions in the inspection rule library;

[0008] S4. Testing the script code sub-files in sequence according to the detection logic of the detection specification table, and equipping a fault detection table;

[0009] S5. If a failure occurs during the test, execute S6 and obtain the label of the corresponding script code sub-file from the fault column in the fault detection table; if no failure occurs during the test, execute S9;

[0010] S6. After analyzing and correcting the fault section information corresponding to the number, perform a regression static check;

[0011] S7, repeat S5-S6 according to the set execution number threshold. If the number of repetitions exceeds the threshold, execute S8;

[0012] S8. Associating the label of the script code sub-file where the test failure occurs with a fault sharing container, wherein the fault sharing container is associated with an expert library;

[0013] S9. When all script code sub-files have passed the test, several script code sub-files are knitted to obtain a target script code file.

[0014] Preferably, constructing the detection rule base in S1 includes the following steps:

[0015] Determine the inspection rules according to the language specifications and usage requirements of the XML test script language;

[0016] Use regular expressions to write static checking rule codes based on XML test script language.

[0017] Preferably, in S2, preprocessing the script code file to obtain a plurality of script code sub-files includes: dividing the script code file into a plurality of script code sub-files according to the test item attributes of the script code file;

[0018] Record the starting code line, ending code line and code line difference of each script code sub-file;

[0019] The separation slots in the test container are allocated according to the code line difference, and several script code sub-files are stored in the separation slots of the container to be tested and labeled; the labels are extracted as test sequences, and the sequence bits of the test sequences are mapped to the separation slots.

[0020] Preferably, S3 includes the following steps:

[0021] The test sequence is mapped to the inspection specification list, and the script parsing executor sequentially obtains the script code sub-files in the container to be tested according to the inspection logic of the test sequence, and calls the corresponding inspection entry instructions to test the script code sub-files.

[0022] Preferably, S5 includes the following steps:

[0023] If a fault occurs during testing, the fault column in the fault detection table automatically obtains the label information of the corresponding script code sub-file;

[0024] The fault column is mapped to the corresponding test sequence bit.

[0025] Preferably, in S8, associating the label of the script code sub-file where the test failure occurs with the fault sharing container, wherein the fault sharing container is associated with the expert library, comprises the following steps:

[0026] Establish a mapping between the fault sharing container and the test sequence bit of the test fault, and obtain the script code sub-file corresponding to the test sequence bit;

[0027] Obtain the fault section information of the corresponding script code sub-file according to the script parsing executor;

[0028] According to the attribute characteristics of the fault section information, an expert database is associated, wherein a daily task pop-up window is set in the expert database;

[0029] The fault section information is converted into an Excel format file and filled into the task pop-up window of the expert library. The experts process the corresponding fault section information according to the task pop-up window.

[0030] Preferably, in S9, when all script code sub-files pass the test, several script code sub-files are knitted to obtain a target script code file, including:

[0031] Retrieve the script code sub-files corresponding to the test sequence bits in sequence, and copy the script code sub-files to the compilation environment according to the sequential logic of the test sequence;

[0032] Compare the starting code line, ending code line and code line difference of each script code sub-file with the recorded value; if the starting code line, ending code line and code line difference match the historical record value, generate the target script code file; if not, perform proofreading.

[0033] Beneficial effects of the present invention: The present invention proposes a method for writing automated test scripts based on an XML test script language, which replaces manual inspection by writing static inspection rules, greatly reducing the workload of manual code inspection. At the same time, the written inspection rules can be reused, saving a lot of labor costs; the static inspection rules are written using the same script language as the inspected test script code, and test developers can quickly get started writing or modifying inspection rules; at the same time, because the inspection rules are keyword-driven, different inspection rules can be freely expanded using different parameters; the language specifications and usage requirements of the inspected test script code are diverse, and the present invention supports the use of regular expressions to write static rules, which greatly improves the flexibility of inspection rule writing and reduces the workload and difficulty of inspection rule writing; after executing the static inspection, the rules that fail the static inspection of the test script code will be recorded and reported as errors. After the development test personnel modify the test script according to the problem list found in the inspection, they can separately execute the inspection rules that failed the last inspection for regression inspection, which greatly improves the overall inspection efficiency; for fault events that are difficult to handle, the fault information is automatically fed back to the expert database, and the experts handle them according to daily affairs reminder notifications, further improving the efficiency of fault handling.

[0034] The above content of the invention is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Other features, objects, and advantages of the present invention will become more apparent upon reading the detailed description of the non-limiting embodiments made with reference to the following drawings. The drawings are for the purpose of illustrating preferred embodiments only and are not to be construed as limiting the present invention. Like reference characters are used throughout the drawings to designate like parts.

[0036] Figure 1 This is a flow chart of a static inspection method based on XML test script code of the present invention.

[0037] Figure 2 This is an example diagram of the static inspection code of the test script of the present invention. DETAILED DESCRIPTION

[0038] In order to make the objectives, technical solutions and advantages of the present invention more clear, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific implementation method described herein is only an optimal embodiment of the present invention, which is only used to explain the present invention and does not limit the scope of protection of the present invention. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0039] Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow charts describe the operations (or steps) as sequential processes, many of the operations (or steps) therein can be performed in parallel, concurrently, or simultaneously. In addition, the order of the operations can be rearranged. The process can be terminated when its operations are completed, but can also have additional steps not included in the figures; the process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0040] Example: Figure 1 As shown, a static checking method based on XML test script code includes the following steps:

[0041] S1. Build a detection rule base, and establish a mapping between the detection rule base and the script parsing executor;

[0042] S2. The script parsing executor loads the script code file to be detected and preprocesses the script code file to obtain several script code sub-files;

[0043] S3. The script parsing executor sequentially matches the inspection specification list of the script code sub-file, wherein the inspection specification list sequentially associates the inspection entry instructions in the inspection rule library;

[0044] S4. Testing the script code sub-files in sequence according to the detection logic of the detection specification table, and equipping a fault detection table;

[0045] S5. If a failure occurs during the test, execute S6 and obtain the label of the corresponding script code sub-file from the fault column in the fault detection table; if no failure occurs during the test, execute S9;

[0046] S6. After analyzing and correcting the fault section information corresponding to the number, perform a regression static check;

[0047] S7, repeat S5-S6 according to the set execution number threshold. If the number of repetitions exceeds the threshold, execute S8;

[0048] S8. Associating the label of the script code sub-file where the test failure occurs with a fault sharing container, wherein the fault sharing container is associated with an expert library;

[0049] S9. When all script code sub-files have passed the test, several script code sub-files are knitted to obtain a target script code file.

[0050] In this embodiment, the detection rule library is provided with inspection rules for matching script code sub-files. The inspection rules are written using the same script language as the script code sub-file being inspected. Test developers can quickly get started writing or modifying inspection rules. It has good scalability and is reusable. It can replace a large amount of manual inspection workload, significantly improving the efficiency of test script code detection. At the same time, it can record inspection rules that fail static inspections, support regression inspections after test script problems are fixed, and avoid missed inspections. Synchronously, for fault events that are difficult to handle, the fault information is automatically fed back to the expert library, and experts handle them based on daily affairs reminder notifications, further improving the efficiency of fault handling.

[0051] Building a detection rule base in S1 includes the following steps:

[0052] Determine the inspection rules according to the language specifications and usage requirements of the XML test script language;

[0053] Use regular expressions to write static checking rule codes based on XML test script language.

[0054] In this solution, the inspection rules are driven by keywords, and different inspection rules can be freely extended by using different keywords; specifically, Figure 2As shown, each set of check specifications includes one or more check items, which can be driven by the following keywords: CheckXMLNodeName (check whether the test case script node name is correct), CheckXMLNodePropName (check whether the test case script node property name is correct), RegexCheckExecStepMatch (check the matching of the test case script execution steps using regular expressions), RegexCheckExecStepPostConditionMatch (check the matching of the test case script execution steps and postconditions using regular expressions) and CheckExecStepRuleExist (check whether the keywords used in the test case script exist).

[0055] Furthermore, a new check rule keyword function is added to the test script parsing executor using the C++ development language. Different keywords can freely extend different check rules. Typical keywords can be:

[0056] CheckXMLNodeName (check whether the test case script node name is correct)

[0057] CheckXMLNodePropName (checks whether the test case script node property name is correct)

[0058] CheckXMLNodePropValueExist (checks whether the test case script node property value exists)

[0059] RegexCheckXMLNodePropValueOrMatch (regular expression method to check whether the test case script node property value is correct)

[0060] RegexCheckExecStepMatch (regular expression method to check the matching of test case script execution steps)

[0061] RegexCheckExecStepPostConditionMatch (regular expression method to check the matching of test case script execution steps and post-conditions)

[0062] RegexCheckExecPostConditionMatch (regular expression method to check the matching of test case script post-conditions)

[0063] RegexCheckRevExecStepMatch (regular expression method to reverse check the matching of test case script execution steps)

[0064] RegexCheckRevExecStepPostConditionMatch (regular expression method to reverse check the matching of test case script execution steps and post-conditions)

[0065] RegexCheckRevExecPostConditionMatch (regular expression method to reverse check the matching of the post-condition of the test case script)

[0066] RegexCheckExecStepTitleMatch (regular expression method to check the matching of test case title and execution step of test case script)

[0067] RegexCheckSameExecStepMatch (regular expression method to check the content matching of the same composite execution step in the test case script)

[0068] RegexCheckSameExecPostConditionMatch (regular expression method to check the content matching of the same composite post-condition in the test case script)

[0069] CheckExecStepRuleExist (checks whether the keywords used in the test case script exist)

[0070] CheckExecStepExist (checks whether the test case script execution step exists)

[0071] CheckExcelTestCase2ScriptXMLNode (checks whether a corresponding test script exists for an automated test case)

[0072] CheckScriptXMLNode2ExcelTestCase (checks whether the test script has a corresponding test case)

[0073] CheckScriptXMLNodeTitle (checks whether the test case title attribute in the test script is correct)

[0074] RegexCheckScriptXMLNodeMatchExcelExecStepExist (checks whether the corresponding execution step of the test script exists based on the test case keyword).

[0075] In S2, the script code file is preprocessed to obtain several script code sub-files, including:

[0076] Divide the script code file into several script code sub-files according to the test item attributes;

[0077] Record the starting code line, ending code line and code line difference of each script code sub-file;

[0078] The separation slots in the test container are allocated according to the code line difference, and several script code sub-files are stored in the separation slots of the container to be tested and labeled; the labels are extracted as test sequences, and the sequence bits of the test sequences are mapped to the separation slots.

[0079] In S3, the following steps are included:

[0080] The test sequence is mapped to the inspection specification list, and the script parsing executor sequentially obtains the script code sub-files in the container to be tested according to the inspection logic of the test sequence, and calls the corresponding inspection entry instructions to test the script code sub-files.

[0081] S5 includes the following steps:

[0082] If a fault occurs during testing, the fault column in the fault detection table automatically obtains the label information of the corresponding script code sub-file;

[0083] The fault column is mapped to the corresponding test sequence bit.

[0084] In S8, the label of the script code sub-file having the test fault is associated with the fault sharing container, and the fault sharing container is associated with the expert library, including the following steps:

[0085] Establish a mapping between the fault sharing container and the test sequence bit of the test fault, and obtain the script code sub-file corresponding to the test sequence bit;

[0086] Obtain the fault section information of the corresponding script code sub-file according to the script parsing executor;

[0087] According to the attribute characteristics of the fault section information, an expert database is associated, wherein a daily task pop-up window is set in the expert database;

[0088] The fault section information is converted into an Excel format file and filled into the task pop-up window of the expert library. The experts process the corresponding fault section information according to the task pop-up window.

[0089] In S9, when all script code sub-files have passed the test, several script code sub-files are knitted to obtain a target script code file, including:

[0090] Retrieve the script code sub-files corresponding to the test sequence bits in sequence, and copy the script code sub-files to the compilation environment according to the sequential logic of the test sequence;

[0091] Compare the starting code line, ending code line and code line difference of each script code sub-file with the recorded value; if the starting code line, ending code line and code line difference match the historical record value, generate the target script code file; if not, perform proofreading.

[0092] The specific implementation described above is a preferred implementation of a static inspection method based on XML test script code of the present invention, and is not intended to limit the specific implementation scope of the present invention. The scope of the present invention includes but is not limited to this specific implementation. Any equivalent changes made in accordance with the shape and structure of the present invention are within the protection scope of the present invention.

Claims

1. A static inspection method based on XML test script code, characterized by: The steps include: S1. Build a detection rule library, and establish a mapping between the detection rule library and the script parsing executor; S2. The script parsing executor loads the script code file to be detected and preprocesses the script code file to obtain several script code sub-files; S3. The script parsing executor sequentially matches the detection specification table of the script code sub-file, wherein the detection specification table sequentially associates the detection entry instructions in the detection rule library; S4. Testing the script code sub-files in sequence according to the detection logic of the detection specification table, and equipping a fault detection table; S5. If a failure occurs during the test, execute S6 and obtain the label of the corresponding script code sub-file from the fault column in the fault detection table; if no failure occurs during the test, execute S9; S6. After analyzing and correcting the fault section information corresponding to the number, perform a regression static check; S7, repeat S5-S6 according to the set execution number threshold. If the number of repetitions exceeds the threshold, execute S8; S8. Associating the label of the script code sub-file where the test failure occurs with a fault sharing container, wherein the fault sharing container is associated with an expert library; S9. When all script code sub-files have passed the test, several script code sub-files are knitted to obtain a target script code file.

2. A static inspection method based on XML test script code according to claim 1, characterized in that: Building a detection rule base in S1 includes the following steps: Determine the inspection rules according to the language specifications and usage requirements of the XML test script language; Use regular expressions to write static checking rule codes based on XML test script language.

3. The static inspection method based on XML test script code according to claim 1, characterized in that: In S2, the script code file is preprocessed to obtain several script code sub-files, including: Divide the script code file into several script code sub-files according to the test item attributes; Record the starting code line, ending code line and code line difference of each script code sub-file; The separation slots in the test container are allocated according to the code line difference, and several script code sub-files are stored in the separation slots of the container to be tested and labeled; the labels are extracted as test sequences, and the sequence bits of the test sequences are mapped to the separation slots.

4. The static inspection method based on XML test script code according to claim 3, characterized in that: In S3, the following steps are included: The test sequence is mapped to the test specification table, and the script parsing executor sequentially obtains the script code sub-files in the container to be tested according to the test logic of the test sequence, and calls the corresponding test entry instructions to test the script code sub-files.

5. A static inspection method based on XML test script code according to claim 3 or 4, characterized in that: S5 includes the following steps: If a fault occurs during testing, the fault column in the fault detection table automatically obtains the label information of the corresponding script code sub-file; The fault column is mapped to the corresponding test sequence bit.

6. The static checking method based on XML test script code according to claim 3, characterized in that: In S8, the label of the script code sub-file having the test fault is associated with the fault sharing container, and the fault sharing container is associated with the expert library, including the following steps: Establish a mapping between the fault sharing container and the test sequence bit of the test fault, and obtain the script code sub-file corresponding to the test sequence bit; Obtain the fault section information of the corresponding script code sub-file according to the script parsing executor; According to the attribute characteristics of the fault section information, an expert database is associated, wherein a daily task pop-up window is set in the expert database; The fault section information is converted into an Excel format file and filled into the task pop-up window of the expert library. The experts process the corresponding fault section information according to the task pop-up window.

7. The static inspection method based on XML test script code according to claim 3, characterized in that: In S9, when all script code sub-files have passed the test, several script code sub-files are knitted to obtain a target script code file, including: Retrieve the script code sub-files corresponding to the test sequence bits in sequence, and copy the script code sub-files to the compilation environment according to the sequential logic of the test sequence; Compare the starting code line, ending code line and code line difference of each script code sub-file with the recorded value; if the starting code line, ending code line and code line difference match the historical record value, generate the target script code file; if not, perform proofreading.

Images