An Automatic Generation Method for Interlocking System Test Cases
By automatically generating interlock system test cases, the problems of low testing efficiency and insufficient coverage under traditional manual compilation methods are solved, and efficient and automated interlock system testing is realized, which is suitable for various station-type scenarios.
Patent Information
- Application Number
- CN202211715868.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-28
- Publication Date
- 2025-08-01
- Estimated Expiration
- 2042-12-28
AI Technical Summary
The traditional manual interlocking system test cases face the problems of complex testing scenarios, easy omissions and huge workloads, and it is difficult to achieve effective interlocking system software testing in complex operation scenarios.
The automatic generation method of interlocking system test cases is adopted. By obtaining input path configuration files, site data files, query files and general test case files, test cases are automatically generated, test objects and parameters are instantiated, and test cases are checked for specific sites are generated.
It improves the efficiency of test preparation, enhances the accuracy and coverage of test cases, shortens the test time, and supports preliminary verification of interlocking data, realizing automated testing of interlocking systems.
Smart Images

Figure CN116302934B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of interlocking software testing, and in particular to a method for automatically generating test cases for an interlocking system. Background Art
[0002] For the track signal system, the interlocking system is an important guarantee for ensuring the safe operation of trains. With the rapid development of China's track industry, in the signal system designs of various systems in railways, urban rails, and intercity railways, more and more trackside devices are incorporated into the management scope of the interlocking system. Correspondingly, the actual operation scenarios become more complex. The correctness of the data logic design of the interlocking system is the basis for whether the interlocking system can correctly implement the safety function under complex operation scenarios. For the logic design of the interlocking system software, accurate and efficient interlocking tests are required to control the effectiveness of the interlocking system software logic design.
[0003] To correctly and comprehensively test the interlocking system software, it is necessary to cover the requirements and functions of the corresponding interlocking system according to the test cases and in combination with the corresponding scenarios one by one. Therefore, for interlocking systems with different systems and different function selections, a complete and effective test case file is an inevitable requirement for testing the interlocking system software. The complex functions of the interlocking system mean that the traditional manual method of preparing test cases faces problems such as complex test scenarios being prone to omission and a huge workload of a large number of repetitive tasks. Summary of the Invention
[0004] The present invention proposes a method for automatically generating test cases for an interlocking system, which can replace the traditional manual preparation of test cases, standardize and program the generation of test cases, thereby greatly improving the efficiency of test preparation work, improving the correctness of test cases, shortening the test time, and at the same time being able to preliminarily verify the interlocking data during the process of generating test cases.
[0005] To achieve the above object, the present invention proposes a method for automatically generating test cases for an interlocking system, including the following steps:
[0006] S_{1}, obtaining all input files according to the input path configuration file;
[0007] S_{2}, obtaining the general test cases in the input files, and instantiating all the test objects under each step in each general test case respectively;
[0008] S_{3}, after instantiating all the test objects, instantiating each general test case in combination with the data instantiated by the test cases to generate test cases for each specific station yard.
[0009] Further, S1 includes the following steps: The input path configuration file includes the file paths of each input file and the type identifier of the input file. By reading a specific type of the input path configuration file, the content of all input files required for generating test cases can be obtained.
[0010] Further, the input files are divided into three categories: station data files, query files, and general test case files;
[0011] The station data files are used to describe the interlocking relationship and interface information of the corresponding test station, including: interlocking tables, communication files, and function list files, which are used to describe the interlocking relationship and interface information of the corresponding test station;
[0012] The query files are used to define the corresponding search methods to find the specified device name in the station data files, including: name comparison files, keyword definition files, and test query mapping files;
[0013] The general test case files define all general test cases used for interlocking system testing. Each test case defines the test steps, the detailed operations under each step of the test case, whether the test step has a loop attribute, and the expected parameter changes in each cycle under the operations of the corresponding steps.
[0014] Further, the step S2 includes the following steps:
[0015] When generating test cases, the test cases defined in the general test case files are extracted one by one. After obtaining the test cases, each test object of the current test case is traversed, and an instantiated test case will be generated for each test object;
[0016] During the generation of each instantiated test case, it is necessary to instantiate each step operation of the test case and the parameter tracking after each step operation based on the current test object.
[0017] Further, the step S2 specifically includes the following steps:
[0018] S2.1. Obtain all general test cases according to the input files;
[0019] S2.2. Traverse the general test cases;
[0020] S2.3. Obtain all test objects included in the current general test case;
[0021] S2.4. Determine whether the device names of all operation objects and tracking parameters under the first step in the currently common test cases are already the instantiated parameter names. If so, directly output them as they are, and then execute step S2.6; otherwise, execute step S2.5;
[0022] S2.5. Replace the device names of the operation objects and tracking parameters with the string "parameter mapping", and further process according to the application scenario;
[0023] S2.6. Repeatedly execute steps S2.4 - S2.5 to instantiate the device names of all operation objects and tracking parameters under each step in the currently common test cases;
[0024] S2.7. Repeatedly execute steps S2.2 - S2.6 to instantiate the device names in each common test case in turn.
[0025] Furthermore, the method for further processing according to the application scenario in step S2.5 includes the following steps:
[0026] Search for all instantiated parameter names that appear in the abstract form of "parameter mapping" in the "parameter mapping name" column of the test query mapping file one by one;
[0027] For the "parameter mapping" found, special processing is required in special scenarios:
[0028] (1) Take a specific one or several consecutive parameters of the found "parameter mapping", modify them with parentheses "()", and fill in the number n or the number combination n - m to take a specific one or several consecutive parameters of the found parameter mapping; if the value of n is less than m, sequentially obtain the nth to the mth parameters; if the value of n is greater than m, obtain the nth to the mth parameters in reverse order;
[0029] (2) For turnout devices, generally in the industry, turnouts in the normal position are not specially modified, turnouts in the reverse position are modified with parentheses "()", actuated turnouts are modified with curly braces "{}", and protective turnouts are modified with square brackets "[]"; in some test scenarios where only the name of the turnout is required and no specific position information of the turnout is needed, in cooperation with <wwz>" string, indicating that only the switch name is retained; for some test scenarios, if the position of a specific switch or the opposite position of the switch needs to be obtained, then for the name of the parameter, use " <dfw>” or " <dfwf>"Modify it and instantiate the turnout combination position to generate;
[0030] 3) For parameters containing directions, the industry generally distinguishes between up and down directions for the running direction. For parameters that need to distinguish between up and down directions, add " <tfx>"or" <ffx>"Modify to determine whether the direction of the parameter is upward or downward, and instantiate the parameter in combination with the direction to generate;
[0031] 4) First, perform a conditional judgment on the parameter generation. After the judgment condition is met, determine the generation of the corresponding parameter. The query format for adding a conditional judgment is: "base parameter_column where the parameter is located_target parameter column_column for conditional judgment" query condition". Compared with the ordinary parameter search, it adds a specified condition search in the column for conditional judgment; when searching with the base parameter, first judge whether the search condition is met in the column for conditional judgment, that is, whether the content in the column for conditional judgment is consistent with the string defined in the "query condition". When the query condition is met, perform the search according to the method defined above, otherwise do not extract any elements;
[0032] 5) For multiple found "parameter mappings", corresponding logical operations can be performed, including: union operation, difference operation, intersection operation, conditional judgment, conditional negation judgment, and operations on the front and rear devices.
[0033] Furthermore, the method for finding all instantiated parameter names in the abstract form of "parameter mapping" includes the following steps:
[0034] The search method for each "parameter mapping" is defined in the "mapping query" in the test query mapping file, and the query format is: "base parameter_column where the parameter is located_target parameter column"; the base parameter is the current test object or the device found previously, the "column where the parameter is located" and the "target parameter column" called during the search are both defined in the "keyword" column in the "keyword definition file". By using the column names called by the "column where the parameter is located" and the "target parameter column", the specific column of the specified input file can be accurately located;
[0035] When the current base parameter is found row by row in the "column where the parameter is located", all the parameters in the "target parameter column" are extracted, which is the content of the current "parameter mapping";
[0036] The content of the currently found "parameter mapping" is used as the "base parameter" for the search of other "parameter mappings" to continue the next search.
[0037] Furthermore, the step S3 includes the following steps:
[0038] S3.1. Read the general test case file, obtain all general test cases, and traverse each general test case one by one;
[0039] S3.2. Read the test object of the currently traversed test case, and traverse each test object one by one;
[0040] S3.3. For each current test object, obtain the steps of the current test case and the corresponding trace parameters for each step, and instantiate the operation object found for the current step;
[0041] S3.4. When the current step is instantiated, perform a legality check;
[0042] S3.5. Continue to generate each step of the current general test case. If the next step exists, jump to step S3.3 and repeat the operations of S3.3 - S3.4; if the next step does not exist, it means that the current test case has ended. Output the currently generated instantiated test case and execute step S3.6;
[0043] S3.6. Continue to generate test cases for each test object. If the next test object exists, jump to step S3.2 and repeat the operations of steps S3.2 - S3.5 to continue generating the instantiation for the next test object; if the next test object does not exist, all the instantiated cases for the current general test case have been generated. The use case generation for the next general test case can be performed, and jump to step S3.7;
[0044] S3.7. Continue to traverse the next general test case. If the next general test case exists, jump to step S3.1 and repeat the operations of steps S3.1 - S3.6 to continue searching for test objects and generating instantiated cases for the next general test case one by one; if the next general test case does not exist, the current general use case is already the last use case defined in the general use case file, and all the use cases defined in the general test case file have been executed, ending the entire test case generation.
[0045] Further, in step S3.2, if the test object is empty, that is, the object of the current test case does not exist, skip the generation of the current use case and jump to S3.1; if the test object is not empty, traverse each test object of the current test case one by one;
[0046] Further, when instantiating the operation object found for the current step in step S3.3, determine whether the current step is in a loop according to the "test loop" column of the general test case;
[0047] If the current step is not in a loop and the current step instantiates multiple operation objects, all the operation objects are generated in the cell of the current step simultaneously, indicating that the operations of this step need to be performed simultaneously; if the current step is in a loop, the multiple operation objects instantiated in the current step are respectively instantiated and corresponding tracking parameters are generated based on each operation object. That is, if a total of N operation objects are instantiated in the current step, the current step will be instantiated into N steps.
[0048] Further, the method for legality check in step S3.4 includes the following steps:
[0049] For a test step, if no special identifier is added to the test step, it indicates that the current test step is a key step and must be generated. If the current step fails to correctly instantiate any operation object, it means that the current test data may be incorrect, the legality check fails, the entire test case is not generated, and an error is reported and processed in the generated record file.
[0050] If the end of the test step is modified with ":Y", it indicates that the current test step and the steps after the current loop are non-key steps. If the current step fails to correctly instantiate any operation object, within the range from the current step to the end of this loop, nothing will be instantiated from the current step to the end of this loop, and the steps before the current step within the scope of this loop can be instantiated normally.
[0051] If the end of the test step is modified with ":N", it indicates that the entire loop where the current test step is located is a non-key step. If the current step fails to correctly instantiate any operation object, nothing will be instantiated within the entire loop range where the current step is located.
[0052] Further, the method for legality check in step S3.4 also includes the following steps:
[0053] For the tracking parameters under a test step, if no special identifier is added to the tracking parameter, it indicates that the current tracking parameter is a key tracking parameter and must be generated. If the key tracking parameter fails to be correctly instantiated, it means that the current test data may be incorrect, the legality check fails, the entire test case is not generated, and an error is reported and processed in the generated record file.
[0054] If the end of the tracking parameter is modified with ":N", it indicates that the current tracking parameter is a non-key tracking parameter. If the current tracking parameter fails to be correctly instantiated, it is still considered legal, and the generation of the current tracking parameter can be directly skipped.
[0055] If the end of a tracking parameter is modified with ":Y", it indicates that the current tracking parameter is a non-critical tracking parameter. If the current tracking parameter fails to be correctly instantiated, it is still considered legal, and the entire step where the current tracking parameter is located is skipped.
[0056] The present invention has the following advantages:
[0057] The present invention provides a method for automatically generating test cases based on a general test case file, a query class file, and a station yard data class file, which overcomes the huge workload of manually writing test cases one by one in combination with the station yard in the traditional method. Moreover, it can be well compatible with various station types involved in the interlocking system, has good universality, and can generate test cases for specific applications corresponding to various station types. The test cases for specific applications generated by the present invention can have very fine-grained control of the test granularity, can achieve parameter jump control at the cycle level, have good completeness of the test cases, and can be well used as the test basis for the interlocking engineering project. In addition, the test cases for specific applications generated by the present invention have very wide applicability and can be combined with the automatic test method to realize the automation of the full-process interlocking system test. BRIEF DESCRIPTION OF THE DRAWINGS
[0058] Figure 1 It is a schematic flow chart of the method for automatically generating test cases for the interlocking system provided by an embodiment of the present invention;
[0059] Figure 2 It is a schematic flow chart of instantiating all test objects in each general test case provided by an embodiment of the present invention;
[0060] Figure 3 It is a schematic flow chart of generating test cases for each specific station yard provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0061] The following further describes the present invention in detail with reference to the accompanying drawings and specific embodiments. According to the following description and the claims, the advantages and features of the present invention will be more clearly understood. It should be noted that the accompanying drawings are all in a very simplified form and use non-precise ratios, only for the purpose of facilitating and clearly assisting in explaining the objectives of the embodiments of the present invention.
[0062] The present invention provides a method for automatically generating test cases for an interlocking system, which can replace the traditional manual preparation of test cases, standardize and program the generation of test cases, thereby greatly improving the efficiency of test preparation work, improving the correctness of test cases, shortening the test time, and at the same time being able to preliminarily verify the interlocking data during the process of generating test cases.
[0063] Such as Figure 1 As shown in the figure, the method for automatically generating test cases for the interlocking system includes the following steps:
[0064] S1. Obtain all input files according to the input path configuration file.
[0065] Specifically, the input path configuration file includes the file paths of each input file and the type identifiers of the input files. By reading the specific types of the input path configuration file, the contents of all input files required for generating test cases can be obtained. The input files are divided into three categories: station field data files, query files, and general test case files.
[0066] The station field data files are used to describe the interlocking relationships and interface information of the corresponding test station fields. The station field data files include: interlocking tables, communication files, and function lists, etc., which are used to describe the interlocking relationships and interface information of the corresponding test station fields. The interlocking table defines the interlocking relationships of the test station field, and each interlocking sub-table is distinguished by equipment type: for example, switch tables, route tables, section tables, continued protection route tables, etc. In each interlocking sub-table, based on the equipment to be described, the interlocking relationships are described in detail with columns as the distinction. For example, in each column of the route table sub-table, information such as route name, inner section of the route, route direction, positions of inner / protective / driven switches in the route, intrusion sections, opposing routes, opposing protection, route inspection conditions, and start signal opening inspection conditions are described. The communication file is a communication file between the interlocking system and other subsystems, which defines the communication header, version number, input / output identifiers, names of all input communication parameters are defined under the input identifier, and names of all output communication parameters are defined under the output identifier. The function list refers to that the urban rail transit interlocking system can select various different function combinations according to the needs of specific applications. The function list is a table that defines the function items selected for the project. The corresponding function numbers are recorded for each function in the function list table. If the test station has the corresponding function, the corresponding function is marked as 1, otherwise it is 0.
[0067] The query class file is used to define the corresponding search method to find the specified device name in the yard data class file. The query class file includes: a name comparison file, a keyword definition file, and a test query mapping file. The name comparison file is used to define each sub-table storing valid data in the input file and each column name. In the name comparison file, four columns of "file name", "full table name", "abbreviated table name", and "abbreviated column name" are defined. The "file name" corresponds to the short name of the file name of the test station specific input information table, corresponding to the attributes of each input file in the input path configuration file, to determine the corresponding input file and its type; the "full table name" defines the complete name of each valid input sub-table under the corresponding input file; the "abbreviated table name" defines the short name of each valid input sub-table page under the corresponding input file, corresponding one by one to the "full table name"; the "abbreviated column name" column defines the abbreviations of all valid column names under the sub-table corresponding to the "full table name", filled in sequentially according to the column order, and the naming of the "abbreviated column name" of each sub-table of each input file is unique. The keyword definition file is used to define the keyword names of the specified logic and at the same time abstract each column defined in the name comparison file. The keyword definition file includes three columns of "keyword", "sub-table abbreviation", and "sub-table list identifier"; the "sub-table abbreviation" column corresponds one by one to the "abbreviated table name" column defined in the name comparison file; the "sub-table list identifier" column corresponds one by one to the "abbreviated column name" column defined in the name comparison file; the "keyword" column represents the abstract definition of each column under each sub-table of each yard data class file. Through the above "sub-table abbreviation" and "sub-table list identifier", the columns under each sub-table of all yard data class files of the test station can be located, and through the "keyword" column, a specified column in the yard data class file can be directly located through a single variable name. The test query mapping file finds the corresponding test yard equipment name through each column name defined in the keyword table and the specified logic keyword, in cooperation with a specific search logic. The test query mapping file includes two columns of "parameter mapping name" and "parameter query", where the "parameter mapping name" column defines the abstract device name; the "parameter query" column defines the search method for the device corresponding to the "parameter mapping name" column.
[0068] The general test case file defines all general test cases used for interlocking system testing. Each test case defines test steps, detailed operations under each step of the test case, whether the test step has a loop attribute, and the expected parameter changes in each cycle under the corresponding step operations. In the interlocking system, the parameter name consists of two parts: the device name and the variable name. Among them, the device name generally corresponds to the name of the signal equipment in the station yard (such as turnouts, signal machines, sections, platforms, throat areas, etc.), and the variable name is general and used to express the logical state inside the interlocking. Through the combination of the device name and the code bit name, it is the parameter name for each specific station yard operation. For example, for the train signal relay parameter of an outbound signal machine S01, indicating whether the signal machine can be opened, it is named S01-LXJ, where S01 is the name of the signal machine device and LXJ is the code bit name. In the tracking of the operation of specific parameters in each step of the general use case and the parameter state changes under the corresponding operations, the code bit name of the parameter is fixed, while the device name is not fixed. It is named with an abstract device name, and this abstract device name is called "parameter mapping" and is modified with square brackets "[]".
[0069] S2. Obtain the general test cases in the input file, and instantiate all test objects under each step of each general test case respectively;
[0070] Specifically, when generating the test cases, extract the test cases defined in the general test case file one by one. After obtaining the use cases, traverse the test objects of the current use case one by one, and each test object will generate an instantiated use case separately. During the generation of each instantiated use case, it is necessary to take the current test object as the benchmark to instantiate the operation of each step of the test case and the parameter tracking after each operation.
[0071] In the general test case, the operation objects of the test steps and the device names of the tracked parameters are all reflected in the "parameter mapping" column in the test query mapping file in the form of abstract device names. The query method is defined in the "parameter query" column in the test query mapping file. Taking the current test object as the benchmark, find and instantiate the device names of the operation objects and tracked parameters in each step of the test case.
[0072] Furthermore, as Figure 2 shown, step S2 includes the following steps:
[0073] S2.1. According to the input file, obtain all general test cases;
[0074] S2.2. Traverse the general test cases;
[0075] S2.3. Obtain all test objects included in the currently common test cases;
[0076] Specifically, the test objects are the parameter names under each step in the common test cases;
[0077] S2.4. Determine whether the names of all operation objects and the devices for tracking parameters under the first step in the currently common test cases are already instantiated parameter names. If so, directly output them as they are, and then execute step S2.6; otherwise, execute step S2.5;
[0078] S2.5. Replace the names of operation objects and the devices for tracking parameters with the string "parameter mapping", and further process them for the application scenario;
[0079] Specifically, based on the test objects of the currently generated test cases, search one by one for the instantiated parameter names that appear in the "parameter mapping name" column of the test query mapping file in the abstract form of "parameter mapping". The search method for each "parameter mapping" is defined in the "mapping query" in the test query mapping file, and the query format is: "benchmark parameter_column where parameter is located_target parameter column". The benchmark parameter can be the current test object or the device found previously. The "column where parameter is located" and the "target parameter column" called during the search are both defined in the "keyword" column of the "keyword definition file". Since the definitions in the "keyword" column are unique, the column names called through the "column where parameter is located" and the "target parameter column" can accurately locate specific columns of the specified input file. In the data extraction module, when the current benchmark parameter is found row by row in the "column where parameter is located", all the parameters in the "target parameter column" are extracted, which is the content of the current "parameter mapping". The content of the currently found "parameter mapping" can be used as the "benchmark parameter" for the search of other "parameter mappings", and the parameter search can be iterated infinitely in the above format, that is, the result found each time is used as the benchmark parameter for the next search.
[0080] For the found "parameter mapping", special processing is required in special scenarios. For the obtained "parameter mapping", the special processing includes the following several types to adapt to the special scenarios of the interlocking system:
[0081] 1) Take a specific parameter or several consecutive parameters from the searched parameter mapping, modify them with parentheses "()", and fill in the number n or the number combination n-m to take a specific parameter or several consecutive parameters from the searched parameter mapping. If the value of n is less than m, sequentially obtain the nth to the mth parameters; if the value of n is greater than m, obtain the nth to the mth parameters in reverse order;
[0082] 2) For switch equipment, in the industry, generally, switches in the normal position are not specially modified, switches in the reverse position are modified with small parentheses "()", driven switches are modified with curly braces "{}", and protective switches are modified with square brackets "[]". In some test scenarios where only the name of the switch is required and specific position information of the switch is not needed, in coordination with " <wwz>"String, indicating to only retain the switch name; for some test scenarios, if it is necessary to obtain the position of a specific switch or the opposite position of the switch, then for the name of the parameter, use " <dfw>"or" <dfwf>”Modify it and instantiate the turnout combination position to generate;
[0083] 3) For parameters containing directions, the industry generally distinguishes between up and down directions for the running direction. For parameters that need to distinguish between up and down directions, add " <tfx>"or" <ffx>"Modify to determine whether the direction of the parameter is upward or downward, and instantiate the parameter in combination with the direction to generate;
[0084] 4) First, perform a conditional judgment on the parameter generation. After meeting the judgment conditions, decide the generation of the corresponding parameter. Column "query condition", compared with ordinary parameter search, adds a specified condition search in the conditional judgment column. When searching with the reference parameter, first judge whether the search condition is met in the conditional judgment column, that is, whether the content in the conditional judgment column is consistent with the string defined in the "query condition". When the query condition is met, perform the search according to the method defined above, otherwise do not extract any elements;
[0085] 5) For multiple found "parameter mappings", corresponding logical operations can be performed, including: union operation, difference operation, intersection operation, conditional judgment, conditional negation judgment, operation on the front and rear devices. Specifically, as shown in Table 1:
[0086]
[0087]
[0088] S2.6. Repeatedly execute steps S2.4-S2.5 to instantiate all the operation objects and the device names of the tracking parameters under each step in the current general test case;
[0089] S2.7. Repeatedly execute steps S2.2-S2.6 to instantiate the test objects in each general test case in turn.
[0090] S3. After all the test objects are instantiated, in combination with the test case, instantiate the corresponding data for each general test case to generate a test case for each specific station yard.
[0091] Specifically, perform logical processing on the query class file and the station yard data class file in the input file, extract the application data required for testing, and use it to cooperate with the generation of the instantiation of the general test case file. When generating the test case, first extract each general test case one by one, obtain the test object of the current test case, traverse each test object of the current case one by one, and generate an instantiation case for each test object according to the steps and the tracking parameters under the steps described in the general test case.
[0092] Furthermore, as Figure 3 shown, step S3 includes the following steps:
[0093] S3.1. Read the general test case file, obtain all the general test cases, and traverse each general test case one by one;
[0094] S3.2. Read the test objects of the currently traversed test case and traverse each test object one by one; if the test object is empty, that is, the object of the current test case does not exist, skip the generation of the current use case and jump to S3.1; if the test object is not empty, traverse each test object of the current test case one by one;
[0095] S3.3. According to the current test object, obtain the steps of the current test case and the corresponding trace parameters under each step one by one, and instantiate the operation objects found for the current step;
[0096] Furthermore, when instantiating the current step, determine whether the current step is in a loop according to the "Test Loop" column of the general test case;
[0097] If the current step is not in a loop and multiple operation objects are instantiated for the current step, then generate all the operation objects in this cell of the current step at the same time, which means that the current step needs to perform operations simultaneously; if the current step is in a loop, instantiate the multiple operation objects instantiated for the current step separately and generate the corresponding trace parameters based on each operation object, that is, if a total of N operation objects are instantiated for the current step, the current step will be instantiated into N steps.
[0098] In particular, the loop range can include multiple steps. For example, steps 1 and 2 of a general use case are included in the same loop range. At this time, the instantiation method for step 1 follows the above generation method and is instantiated one by one. In step 2, the operation objects and trace parameters in step 2 are searched and generated based on the results of each instantiation of step 1 at present; at the same time, the loop range can be nested multiple times. For example, steps 1 and 2 of a general use case are included in the same loop range, and step 2 performs another loop on the basis of this loop. At this time, the instantiation method for step 1 follows the above generation method and is instantiated one by one. In step 2, based on the results of each instantiation of step 1 at present, the multiple operation objects instantiated in step 2 are generated in a loop respectively.
[0099] S3.4. When the current step is instantiated and generated, perform a legality check;
[0100] The legality check is divided into two categories: (1) For test steps, if no special identifier is added to a test step, it means the current test step is a critical step and must be generated. If any operation object cannot be correctly instantiated in the current step, it indicates that the current test data may be incorrect, the legality check fails, the entire test case is not generated, and an error is reported in the generated record file. If the end of a test step is modified with ":Y", it means the current test step and the steps after the current loop are non-critical steps. If any operation object cannot be correctly instantiated in the current step, within the range from the current step to the end of the current loop, nothing will be instantiated from the current step to the end of this loop, and the parts before the current step within the current loop range can be normally instantiated. If the end of a test step is modified with ":N", it means all loops where the current test step is located are non-critical steps. If any operation object cannot be correctly instantiated in the current step, nothing will be instantiated within the entire loop range where the current step is located. (2) For trace parameters under a test step, if no special identifier is added to a trace parameter, it means the current trace parameter is a critical trace parameter and must be generated. If this critical trace parameter cannot be correctly instantiated, it indicates that the current test data may be incorrect, the legality check fails, the entire test case is not generated, and an error is reported in the generated record file. If the end of a trace parameter is modified with ":N", it means the current trace parameter is a non-critical trace parameter. If the current trace parameter cannot be correctly instantiated, it is still considered legal, and the generation of the current trace parameter can be directly skipped. If the end of a trace parameter is modified with ":Y", it means the current trace parameter is a non-critical trace parameter. If the current trace parameter cannot be correctly instantiated, it is still considered legal, and the entire step where the current trace parameter is located will be skipped. During the process of instantiating test case generation, detailed generation records should be recorded in the log file.
[0101] Furthermore, if the steps after instantiating the current test case pass the legality check, the steps after instantiating the current test case and the log will be output at the specified path. If the generated instantiation fails the legality check, an error will be reported and the log will be output, but the entire current test case file will not be output.
[0102] S3.5. Continue to generate each step of the current general test case one by one. If the next step exists, jump to step S3.3 and repeat the operations of S3.3 - S3.4. If the next step does not exist, it means the current test case has ended. Output the instantiated test case that has been generated and execute step S3.6.
[0103] S3.6. Continue to generate test cases for each test object one by one. If the next test object exists, jump to step S3.2 and repeat the operations in steps S3.2 - S3.5 to continue generating instantiations for the next test object; if the next test object does not exist, all instantiation cases of the current general test case have been generated, and the generation of the next general test case can be carried out. Jump to step S3.7;
[0104] S3.7. Continue to traverse the next general test case. If the next general test case exists, jump to step S3.1 and repeat the operations in steps S3.1 - S3.6 to continue searching for test objects and generating instantiation cases for the next general test case one by one; if the next general test case does not exist, the current general test case is already the last test case defined in the general test case file, and all test cases defined in the general test case file have been executed, ending the entire test case generation process.
[0105] Embodiment
[0106] A typical general test case table is shown in Table 2; the data class input file is selected and read according to needs in actual applications. In this example, only the interlocking table is used as an example. The route table sub - table of the typical interlocking table is shown in Table 3. Those skilled in the art can easily understand the meaning of the information in the interlocking table; the query class files all need to participate in the instantiation generation of test cases in actual applications. A typical name mapping file is shown in Table 4; a typical keyword definition file is shown in Table 5; a typical test query mapping file is shown in Table 6. Combining the above input files, the method for instantiating the general test cases described in the general test case table in Table 2 is described, including the following steps:
[0107] Step 100, read the input path configuration file, and obtain all input files according to the file path of the input file and the type identifier of the input file.
[0108] Step 101, obtain the general test cases defined in the test case file one by one, that is, read the general test cases shown in Table 2. According to the test object obtained under the test case file number, the test object in Table 2 is: "JL". According to the keyword definition file shown in Table 5, it is obtained that "JL" is the Route column of the Route sub - table of the interlocking table; according to the name mapping file shown in Table 4, it can be known that the "JL" column is the first column "Route Name" column in the Route_List route table of the interlocking table. That is, the test objects of the current test case are all the obtained route names: S22D - S32D, S21D - S17D, S20D - S28D. Traverse the test objects one by one, and first obtain the first test object S22D - S32D.
[0109] Step 102: Taking the test object S22D - S32D as a reference, instantiate all parameter names under each step of the current use case one by one:
[0110] (1) For the "Execution Operation" column MMISET(SDJS) in step step1, where "MMISET" is an operation command (the explanation of the operation command can be found in detail in Chinese Patent Document CN113268415A), it is directly output as it is. "SDJS" is a device name without being modified by "[]", that is, "SDJS" is an instantiated parameter name and is directly output as it is; similarly, for the "Tracking Parameter" column and the parameters in the "Tracking Parameter Start Benchmark" column corresponding to step step1, they are all instantiated parameters and are directly output: Tracking parameter SDJS - BS, Tracking parameter start benchmark SDJS = 1. For other columns, such as the "Parameter Status Waiting Period" column and the "Expected Parameter Status" column, they are not modified during the instantiation process and are directly output as they are.
[0111] (2) In step step2, similar to step1 described above, the "Execution Operation" column, the "Tracking Parameter" column, and the "Tracking Parameter Start Benchmark" column are all instantiated parameters and are directly output.
[0112] (3) Before step step3, there is a loop start flag "START" in the "Loop Processing" column, that is: after instantiating the loop object [DSW - JLNFYDC] in the "Execution Operation" column, traverse it one by one. In the "Parameter Mapping Name" column and the "Mapping Query" column of Table 6 for testing the query mapping file, the abstract device name DSW - JLNFYDC and its search method can be found: [JL - NFYDC_JL_DSW - JL_QOKH]. Among them, the device name JL - NFYDC is also defined in the "Parameter Mapping Name" column. First, its content needs to be searched, and its search method is: [SW - JL]**[JL]. Among them, both "SW - JL" and "JL" are defined in the keyword definition file shown in Table 5, that is, both "SW - JL" and "JL" represent columns in the route table sub - table of the interlocking table file. According to the search method described above, "SW - JL" corresponds to the content of the "Switch Normal Position" and "Switch Reverse Position" columns in the route sub - table, and "JL" corresponds to the content of the "Route Name" column in the route sub - table. The current test object is the route name S22D - S32D. According to the usage of the "**" operator described in Table 1, when the first parameter mapping "SW - JL" has a result, the result of the second parameter mapping "JL" is taken. The "Switch Normal Position" column of the test object S22D - S32D has content, that is, the route name corresponding to the search of "JL - NFYDC" is taken out: "S22D - S32D".
[0113] (4) After obtaining the content "JL-NFYDC", search for the device name "DSW-JLNFYDC": Using "JL-NFYDC" as the basis to find the content "S22D-S32D", after finding the same route name in the "JL" column (the route name column of the route table in the interlocking table file), obtain the content of the "DSW-JL" column (the positioning switch column of the route table in the interlocking table file): P06D, P12D-P14D. For the obtained device name, according to the usage of the "QOKH" operator described in Table 1, delete other parentheses outside the small parentheses. Since the currently retrieved switch does not contain parentheses, no processing is performed, and the device name "DSW-JLNFYDC" finally obtains P06D, P12D-P14D. Since under the current test object, the device name "DSW-JLNFYDC" obtains two device names, it should loop separately with P06D, P12D-P14D for the loop range, and the device name within each loop range is instantiated with the current device name.
[0114] (5) In the subsequent steps step3, step4, and step6, in the "Execution Operation" column, "Tracking Parameter" column, and "Tracking Parameter Start Benchmark" column of the test case, only the device name "DSW-JLNFYDC" exists. Then, in the first loop, it is instantiated as P06D; in the second loop, it is instantiated as P12D-P14D.
[0115] (6) In step5, for the device name "JL-JLNFYDWDC" in the "Execution Operation" column of the test case, the method of searching in the test query mapping file is: [DSW-JLNFYDC]**[JL-NFYDC]. The search method is the same as before. Since the current "DSW-JLNFYDC" is not empty, the content of "JL-NFYDC" is obtained, and the previous "JL-NFYDC" found the content "S22D-S32D". That is, step5 is instantiated as ROUTE(S22D-S32D), which means to handle the route of S22D-S32D. At the same time, in step5, there is also a new device name in the "Tracking Parameter" column of the test case: LXH-JLNFYDWDC, and the corresponding search method is [JL-JLNFYDWDC_JL_LXH-JL]. Using "JL-JLNFYDWDC" as the basis to find the content "S22D-S32D", after finding the same route name in the "JL" column (the route name column of the route table in the interlocking table file), obtain the content of the "LXH-JL" column (the start signal column of the route table in the interlocking table file): S22D.
[0116] (7) In the "Loop Processing" column corresponding to step step6, there is a loop end flag OVER. That is, the loop for the loop object [DSW-JLNFYDC] ends here.
[0117] (8) After the loop instantiation for steps step3-step6, in step step7, there is a new device name in the "Trace Parameter" column of the test case: FXZH-JLNFYDWDC, and the corresponding search methods are [QD-JLNFYDWDC] & [FX-JLNFYDWDC]. Among them, the search method for QD-JLNFYDWDC is [JL-JLNFYDWDC_JL_QD-LJLNF]. Based on finding the content "S22D-S32D" with "JL-JLNFYDWDC", after finding the same route name in the "JL" column (the route name column of the route table in the interlocking table file), obtain the content "T11D, T13D, T15D" in the "QD-LJLNF" column (the section column inside the route). Among them, the search method for FX-JLNFYDWDC is [JL-JLNFYDWDC_JL_FX]. Based on finding the content "S22D-S32D" with "JL-JLNFYDWDC", after finding the same route name in the "JL" column (the route name column of the route table in the interlocking table file), obtain the content "S" in the "FX" column (the route direction column). According to the usage of the "&" operator described in Table 1, the content of FXZH-JLNFYDWDC is the found QD-JLNFYDWDC name with the -S modifier added: "T11D-S, T13D-S, T15D-S". During the instantiation process, the trace parameter to be generated is [FXZH-JLNFYDWDC]- <tfx>TDJ, in combination with Section 3, for <tfx>The processing description, the instantiated parameter names are: "T11D-STDJ, T13D-STDJ, T15D-STDJ"
[0118] Step 103, after performing the instantiation operation on all parameter names, gradually generate the instantiated test cases. For the first test object S22D-S32D obtained from the current general test case, replace the test object "JL" in the general test case.
[0119] (1) In step step1, the current step is not in a loop. According to step 102, it can be known that the columns of "Execution Operation", "Tracking Parameter", and "Tracking Parameter Start Benchmark" are all instantiated parameters, and there is no special identifier for the corresponding instantiated parameters. All columns are directly output as they are. When the instantiated case outputs the current step, check whether the instantiated parameters are defined in the application data. If they are not defined in the application parameters, the current case is incorrect and an error is directly reported in the log and the output of the case is prohibited;
[0120] (2) In step step2, similar to step 1, the current step is not in a loop, and the columns of "Execution Operation", "Tracking Parameter", and "Tracking Parameter Start Benchmark" are all instantiated parameters. However, the operation in the "Execution Operation" column corresponding to step step2 is modified with ":N". Since the current step is not in a loop, if the parameter name YHX-YZSA-CAN of the operation object in the "Execution Operation" column does not exist in the application data, the entire current step is not generated and is directly skipped. If the parameter name YHX-YZSA-CAN of the operation object in the "Execution Operation" column exists in the application data, all columns are directly output as they are.
[0121] (3) Before step step3, there is a loop start flag "START" in the "Loop Processing" column, and generate the object for each current loop. According to step 102, it can be known that the object name for the first loop is: P06D.
[0122] (4) In steps step3 and step4, since the operation object and the tracking parameter are the objects of the current loop, only the name P06D of the current loop object is reflected during the instantiation process to replace the device name [DSW-JLNFYDC]. And there is no special identifier for the parameters corresponding to the columns of "Execution Operation", "Tracking Parameter", and "Tracking Parameter Start Benchmark". Then all operation object tracking parameters must exist in the application data, otherwise the legality check fails. Other columns are output as they are.
[0123] (5) In step step5, the operation object [JL-JLNFYDWDC] instantiates only one device: "S22D-S32D". The tracking parameter [DSW-JLNFYDC] is the object of the current loop. If the tracking parameter [LXH-JLNFYDWDC] finds "S22D" through the current test object "S22D-S32D", then during the instantiation process, only the name P06D of the current loop object is reflected to replace the device name [DSW-JLNFYDC], and the device name S22D is used to replace the device name [LXH-JLNFYDWDC], and other columns are output as they are. In particular, in the "Execute Operation" column, the operation object is modified with ":N". Therefore, if the operation object [JL-JLNFYDWDC] does not instantiate any device, the entire current loop, including the previously generated steps step3 and step4, will not be instantiated, and the current loop will be directly skipped and the next loop will be entered. Additionally, in the "Tracking Parameter" column, the tracked parameter [LXH-JLNFYDWDC]-LXJ is modified with ":N", so the current tracking parameter is a non-critical parameter. If it is not generated, it can be directly skipped without reporting an error, and it will not affect the generation result of the entire test case or the current step.
[0124] (6) In step step6, there is a loop end flag "OVER" in the "Loop Processing" column, so the loop of the loop object P06D ends at the current step. The generation method of step step6 is the same as before.
[0125] (7) After the instantiation of step step6 is completed. Before returning to step step3 at the beginning of the loop, start looping P12D-P14D, and replace the device name [DSW-JLNFYDC] with P12D-P14D, and repeat the previous steps (3)-(6) to regenerate steps step3-step6.
[0126] (8) In step step7, the operation object [JL-JLNFYDWDC] instantiates only one device: "S22D-S32D". Among the tracking parameters, [LXH-JLNFYDWDC] is based on the current operation object and can only generate one tracking parameter "S22D"; according to the description in step 102, [FXZH-JLNFYDWDC]- <tfx>TDJ instantiates three objects "T11D-STDJ, T13D-STDJ, T15D-STDJ", and these three tracking parameters are generated in sequence.
[0127] At this point, the entire use case generated for the instantiation of the first test object S22D-S32D is completed. The results are shown in Table 7.
[0128] Step 104: Get the next test object: S21D-S17D. Repeat steps 102-103 to generate corresponding test cases for test objects S21D-S17D. See Table 8 for the results.
[0129] Step 105: Get the next test object: S20D-S28D. Repeat steps 102-103 to generate corresponding test cases for test objects S20D-S28D. See Table 9 for the results.
[0130] Step 106: After all current general test cases have been generated, the generation of the next general test case begins. Since there is only one general test case in the general test case file in the current embodiment, the entire process ends.
[0131] Table 2. Typical general test case table
[0132]
[0133]
[0134] Table 3. Typical interlocking table entry table sub-table
[0135]
[0136] Table 4. Typical name reference files
[0137]
[0138] Table 5. Typical keyword definition files
[0139]
[0140]
[0141] Table 6. Typical test query mapping files
[0142]
[0143] Table 7. The entire use case generated by instantiating the first test object S22D-S32D
[0144]
[0145]
[0146]
[0147] Table 8, the entire use case generated by instantiating the second test object S21D - S17D
[0148]
[0149]
[0150] Table 9, the entire use case generated by instantiating the third test object S20D - S28D
[0151]
[0152]
[0153]
[0154]
[0155] The present invention provides a method for automatically generating test cases based on a general test case file, a query class file, and a station yard data class file, which overcomes the huge workload of manually writing test cases one by one for each station yard in the traditional method. Moreover, it can be well compatible with various station types involved in the interlocking system, has good universality, and can generate corresponding test cases for specific applications for various station types. The test cases for specific applications generated by the present invention can have very fine-grained control of the test granularity, can achieve parameter jump control at the cycle level, and the completion degree of the test cases is good, which can be well used as the test basis for the interlocking engineering project. In addition, the test cases for specific applications generated by the present invention have very wide applicability and can be combined with the automatic test method to realize the automation of the full-process interlocking system test.
[0156] Although the content of the present invention has been introduced in detail through the above preferred embodiments, it should be recognized that the above description should not be considered as a limitation of the present invention. After those skilled in the art have read the above content, various modifications and substitutions to the present invention will be obvious. Therefore, the protection scope of the present invention should be defined by the appended claims.< / tfx> < / tfx> < / tfx> < / ffx> < / tfx> < / dfwf> < / dfw> < / wwz> < / ffx> < / tfx> < / dfwf> < / dfw> < / wwz>
Claims
1. An automatic generation method for test cases of an interlocking system, characterized in that, It includes the following steps: S1. Obtain all input files according to the input path configuration file; S2. Obtain the common test cases in the input files, and instantiate all test objects under each step in each common test case respectively; S3. After instantiating all test objects, instantiate each common test case by combining the instantiated corresponding data of the test cases to generate test cases for each specific station yard; S3.
1. Read the common test case file, obtain all common test cases, and traverse each common test case one by one; S3.
2. Read the test objects of the currently traversed test case, and traverse each test object one by one; S3.
3. According to the current test object, obtain the steps of the current test case and the tracking parameters under the corresponding steps one by one, and instantiate the operation objects found in the current step; S3.
4. When instantiating and generating the current step, perform a legality check; S3.
5. Continue to generate each step of the current common test case one by one. If the next step exists, jump to step S3.3 and repeat the operations of S3.3 - S3.4; If the next step does not exist, it means that the current test case has ended. Output the instantiated test case generated currently, and execute step S3.6; S3.
6. Continue to generate test cases for each test object one by one. If the next test object exists, jump to step S3.2 and repeat the operations of steps S3.2 - S3.5 to continue generating the instantiation of the next test object; If the next test object does not exist, all instantiated cases of the current common test case have been generated, and the use case generation of the next common test case can be performed. Jump to step S3.7; S3.
7. Continue to traverse the next common test case. If the next common test case exists, jump to step S3.1 and repeat the operations of steps S3.1 - S3.6 to continue searching for test objects and generating instantiated use cases for the next common test case one by one; If the next common test case does not exist, the current common use case is already the last use case defined in the common use case file, and all use cases defined in the common test case file have been executed, and the entire test case generation ends.
2. The method for automatically generating test cases for an interlocking system according to claim 1, wherein The S1 includes the following steps: The input path configuration file includes the file paths of each input file and the type identifier of the input file. By reading the specific type of the input path configuration file, the content of all input files required for generating use cases can be obtained.
3. The automatic generation method of the interlock system test case according to claim 1, characterized in that The input files are divided into three categories: station yard data files, query files, and common test case files; The station yard data files are used to describe the interlocking relationship and interface information of the corresponding test station yard, including: interlocking tables, communication files, and function list files, which are used to describe the interlocking relationship and interface information of the corresponding test station yard; The query class file is used to define the corresponding search method to find the specified device name in the yard data class file, including: the name comparison file, the keyword definition file, and the test query mapping file; The general test case file defines all general test cases used for the interlocking system test. Each test case defines the test steps, the detailed operations under each step of the test case, whether the test step has a loop attribute, and the expected parameter changes in each cycle under the operations of the corresponding steps.
4. The method for automatically generating test cases for an interlocking system according to claim 1, wherein, Step S2 includes the following steps: When generating test cases, extract each test case defined in the general test case file one by one. After obtaining the test case, traverse each test object of the current test case one by one, and each test object will generate an instantiated test case separately; During the generation of each instantiated test case, it is necessary to instantiate each step operation of the test case and the parameter tracking after each step operation based on the current test object.
5. The method for automatically generating test cases for an interlocking system according to claim 4, wherein Step S2 specifically includes the following steps: S2.
1. Obtain all general test cases according to the input file; S2.
2. Traverse the general test cases; S2.
3. Obtain all test objects included in the current general test case; S2.
4. Determine whether the device names of all operation objects and tracking parameters under the first step of the current general test case are already instantiated parameter names. If so, directly output them as they are, and then execute step S2.6; otherwise, execute step S2.5; S2.
5. Replace the device names of the operation objects and tracking parameters with the string of "parameter mapping", and further process them according to the application scenario; S2.
6. Repeat steps S2.4 - S2.5 to instantiate the device names of all operation objects and tracking parameters under each step of the current general test case; S2.
7. Repeat steps S2.2 - S2.6 to instantiate the device names in each general test case in turn.
6. The method for automatically generating test cases for an interlocking system according to claim 5, wherein, The method for further processing according to the application scenario in step S2.5 includes the following steps: Search for all instantiated parameter names that appear in the abstract form of "parameter mapping" in the "parameter mapping name" column of the test query mapping file one by one; For the found "parameter mapping", corresponding processing is required in the specific scenario: 1) Take one parameter or several consecutive parameters of the found "parameter mapping", modify them with parentheses "()", and fill in the number n or the number combination n - m to take one parameter or several consecutive parameters of the found "parameter mapping"; if the value of n is less than m, obtain the nth to the mth parameters in sequence; if the value of n is greater than m, obtain the nth to the mth parameters in reverse order; 2) For switch equipment, in the industry, switches in the normal position are not specially modified, switches in the reverse position are modified with small parentheses "()", driven switches are modified with curly braces "{}", and protective switches are modified with square brackets "[]"; in some test scenarios where only the name of the switch is required and no specific position information of the switch is needed, in coordination with " <wwz>" string, indicating that only the switch name is retained; for some test scenarios, if the position of a specific switch or the opposite position of the switch needs to be obtained, then for the name of the parameter, use " <dfw>"or" <dfwf>Modify with "", and generate the instantiation of the turnout combination position; < / dfwf> < / dfw> < / wwz> 3) For parameters containing directions, in the industry, the up and down directions are distinguished for the operating direction. For parameters that require distinguishing the up and down directions, add " <tfx>"or" <ffx>Modify with "", determine whether the direction of the parameter is up or down, and generate the instantiation of the parameter in combination with the direction;< / ffx> < / tfx> 4) First, perform a conditional judgment on parameter generation. After meeting the judgment conditions, decide the generation of the corresponding parameters. The query format for adding conditional judgment is: "base parameter_column where the parameter is located_target parameter column_column for conditional judgment" query condition". Compared with ordinary parameter search, it adds a specified condition search in the column for conditional judgment. When searching with the base parameter, first judge whether the search condition is met in the column for conditional judgment, that is, whether the content in the column for conditional judgment is the same as the string defined in the "query condition". When the query condition is met, perform the search according to the method defined above; otherwise, do not extract any elements. 5) Perform corresponding logical operations among multiple found "parameter mappings", including: union operation, difference operation, intersection operation, conditional judgment, conditional negation judgment, operations on front and rear devices.
7. The method for automatically generating test cases for an interlocking system according to claim 6, characterized in that The method for finding all instantiated parameter names that appear in the abstract form of "parameter mapping" includes the following steps: The search method for each "parameter mapping" is defined in the "mapping query" in the test query mapping file. The query format is: "base parameter_column where the parameter is located_target parameter column". The base parameter is the current test object or the device found previously. The "column where the parameter is located" and "target parameter column" called during parameter search are both defined in the "keyword" column in the "keyword definition file". The column names called through the "column where the parameter is located" and "target parameter column" are used to accurately locate specific columns in the specified input file. Search for the base parameter row by row in the "column where the parameter is located" with the current base parameter, and extract all parameters in the "target parameter column", which is the content of the current "parameter mapping". The content of the currently found "parameter mapping" is used as the "base parameter" for the search of other "parameter mappings" to continue the next search.
8. The automatic generation method of the interlock system test case according to claim 1, wherein, In step S3.2, if the test object is empty, that is, the object of the current test case does not exist, skip the generation of the current case and jump to S3.
1. If the test object is not empty, traverse each test object of the current test case one by one.
9. The method for automatically generating test cases for an interlocking system according to claim 1, characterized in that, When instantiating the operation object found in the current step in step S3.3, judge whether the current step is in a loop according to the "test loop" column of the general test case. If the current step is not in a loop and the current step instantiates multiple operation objects, generate all operation objects in the cell of the current step at the same time, which means that this step needs to perform operations simultaneously. If the current step is in a loop, instantiate the multiple operation objects instantiated in the current step separately and generate corresponding tracking parameters based on each operation object. That is, if the current step instantiates N operation objects in total, the current step will be instantiated into N steps.
10. The method for automatically generating test cases for an interlocking system according to claim 1, characterized in that, The method for legality check in step S3.4 includes the following steps: Regarding the test steps, if no special identifier is added to a test step, it means that the current test step is a critical step and must be generated. If any operation object cannot be correctly instantiated in the current step, it indicates that there may be an error in the current test data, the legality check fails, the entire test case is not generated, and an error is reported and processed in the generated record file; If the end of a test step is modified with ":Y", it means that the current test step and the steps after the current loop are non-critical steps. If any operation object cannot be correctly instantiated in the current step, within the range from the current step to the end of this loop, nothing will be instantiated from the current step to the end of this loop, and normal instantiation will be performed for the steps before the current step within the scope of this loop; If the end of a test step is modified with ":N", it means that all loops where the current test step is located are non-critical steps. If any operation object cannot be correctly instantiated in the current step, nothing will be instantiated within the entire loop range where the current step is located.
11. The method for automatically generating test cases for an interlock system according to claim 10, wherein, The method for legality check in step S3.4 also includes the following steps: Regarding the trace parameters under a test step, if no special identifier is added to a trace parameter, it means that the current trace parameter is a critical trace parameter and must be generated. If this critical trace parameter cannot be correctly instantiated, it indicates that there may be an error in the current test data, the legality check fails, the entire test case is not generated, and an error is reported and processed in the generated record file; If the end of a trace parameter is modified with ":N", it means that the current trace parameter is a non-critical trace parameter. If the current trace parameter cannot be correctly instantiated, it is still considered legal, and the generation of the current trace parameter can be directly skipped; If the end of a trace parameter is modified with ":Y", it means that the current trace parameter is a non-critical trace parameter. If the current trace parameter cannot be correctly instantiated, it is still considered legal, and the entire step where the current trace parameter is located will be skipped.
12. The method for automatically generating test cases for an interlocking system according to claim 1, wherein, If the steps after the current test case is instantiated pass the legality check, the steps and logs after the current test case is instantiated will be output at the specified path; if the generated instantiation fails the legality check, an error will be reported and the logs will be output, and the entire current test case file will not be output.
Citation Information
Patent Citations
Interlocking rule automatic test system and method based on test case
CN113268415A
Method for generating test cases for computer interlocking system automatically
CN103838675A
Automated testing system for railway signal computer interlocking system
CN103885439A