CN116431470A - ATS automatic test method, equipment and medium based on scripting language - Google Patents

Abstract

The invention relates to an ATS automatic test method, equipment and medium based on a scripting language, wherein the method comprises the following steps: s1, generating a script file of an automatic test by combining a Lua script with static data of a specific line; step S2, merging and putting the generated script file under an ATS system workstation software appointed directory according to the need; and S3, the workstation interface enters an automatic test interface through a button or a menu, and a test command is loaded to automatically complete the test. Compared with the prior art, the invention has the advantages of effectively avoiding input errors and output inspection errors caused by human factors, and the like.

Description

ATS automatic test method, equipment and medium based on scripting language

Technical Field

The invention relates to a train signal control system, in particular to an ATS automatic test method, equipment and medium based on a scripting language.

Background

Along with the rapid development of urban rail transit, the requirements of people on the operation safety and stability of subway lines are continuously improved. The automatic train monitoring system (ATS for short, full name Automatic Train Supervision) is taken as a component of the urban rail transit signal system and is directly applied to a dispatching command center, and the accuracy of functions and the stability of software become more and more important.

Lua is a kind of script language, is small and easy to call by C/C++ code, and can also call functions of C/C++ in reverse, so that Lua is widely applied to application programs. Lua can be used as an extension script, can also be used as a common configuration file, replaces file formats such as XML, ini and the like, and is easy to understand and maintain. Almost all operating systems and platforms can compile and run the Lua script, and meanwhile, the running speed of the Lua script is the fastest, so that the interference on the performance of an application program can be greatly reduced.

ATS as a large-scale complex monitoring system, there are a large number of application data configurations to describe different circuit layouts, signal device arrangements; and simultaneously, the requirements of various operation scenes and the requirements of specific users are met. With the increase of new lines, the extension of existing lines, the transformation of old lines and the like, the system functions are continuously increased, and continuous update and iterative release are required. In each project implementation, application data requires manual programming, auditing, verification, testing, and reporting. Repeated tests such as point-to-point test, minimum regression set and the like can not increase the release period of the product, and the quality is difficult to control.

Therefore, how to automatically complete the test work of the ATS part, thereby avoiding the input error and the output inspection error caused by human factors, and becoming the technical problem to be solved.

Disclosure of Invention

The invention aims to overcome the defects of the prior art and provide an ATS automatic test method, equipment and medium based on a scripting language.

The aim of the invention can be achieved by the following technical scheme:

according to a first aspect of the present invention, there is provided an ATS automation test method based on a scripting language, the method comprising the steps of:

s1, generating a script file of an automatic test by combining a Lua script with static data of a specific line;

step S2, merging and putting the generated script file under an ATS system workstation software appointed directory according to the need;

and S3, the workstation interface enters an automatic test interface through a button or a menu, and a test command is loaded to automatically complete the test.

As a preferable technical solution, the step S1 specifically includes the following steps:

step S11, running different scripts and reading line static data configuration;

step S12, checking the correctness of the read data;

and step S13, generating a corresponding automatic test script file according to the executed script and the selected different parameters.

As a preferred technical solution, the line static data configuration includes TLE data and planning data.

As a preferable technical solution, the script file name generated in the step S1 is named as a test function.

As a preferable technical scheme, each record in the script file is used as an independent execution unit, and all fields are combined into a complete manual operation message to be sent to an ATS system for simulating manual operation.

As an optimal technical scheme, the execution unit capable of being identified by the ATS system comprises a platform truck, an automatic truck adding device, a head truck setting device, a train information checking device, a truck canceling device, an automatic truck deleting device, a jump stop device, a stop time setting device, a route canceling device and a lead truck.

As a preferred technical scheme, the execution unit formats are different according to the requirements of the message formats.

As an optimal technical scheme, generating batches of script files is independently operated, and a tester is used for offline production; or the batch tasks are directly called by C++ codes in the workstation software and used for generating batch tasks on line in real time and driving the execution.

As a preferred technical solution, the step S2 specifically includes:

step S21, combining a plurality of stations into a file according to the test quantity and the different test scripts generated by each station to serve as one-time automatic test content;

s22, putting the script command file combined according to the actual situation under a workstation software directory;

and S23, copying the script file for generating the test command file to a designated directory of the workstation for generating the script command on line in real time and synchronously executing the script command.

As a preferred technical solution, the step S3 specifically includes:

step S31, clicking a batch command and a script command on a workstation interface menu, and popping up an automatic test operation dialog box;

step S32, clicking a loading script, reading a script command file stored under the specified directory in the step S2, and displaying the script command file in an operation dialog box according to the display name configured in the command;

step S33, clicking an operation script, starting execution from the initial command ID, and clicking the operation stop to end the automatic test of the function in the execution process;

step S34, clicking "close" to close the dialog box;

step S35, clicking the automatic vehicle distribution, and completing analysis and operation of the automatic vehicle distribution;

step S36, giving out a pop-up alarm of operation completion after all operations are completed, and giving out a successful or failed execution result to each step in an operation interface;

and step S37, storing an automatic test log executed at the time at a designated position, and taking the automatic test log as a verification log to facilitate inquiry.

According to a second aspect of the present invention there is provided an electronic device comprising a memory and a processor, the memory having stored thereon a computer program, the processor implementing the method when executing the program.

According to a third aspect of the present invention, there is provided a computer readable storage medium having stored thereon a computer program which when executed by a processor implements the method.

Compared with the prior art, the invention has the following advantages:

1. the invention effectively avoids the possible omission of complex and repeated operability tests;

2. the invention effectively reduces the whole test period and accelerates the update iteration and application of the product;

3. the invention effectively saves test time, and places the process of executing the script for a long time in non-working time;

4. the invention improves the quality of the product, and the full coverage test ensures that the product has higher robustness and the field defect escape rate is reduced to the minimum.

5. The invention is completely and automatically completed, thereby avoiding possible errors caused by manual operation;

6. the invention defines the test result, and is convenient and quick to locate possible problems;

7. the invention adopts a mode of directly embedding the software simulation message, and provides a method and a channel for the subsequent more functional expansion.

Drawings

FIG. 1 is a block diagram of an automated test verification method according to the present invention

FIG. 2 is a schematic diagram of a workstation interface operation dialog in accordance with the present invention;

FIG. 3 is a diagram of a Lua script generation test command file interface of the present invention;

FIG. 4 is a functional and interface design diagram of a main framework and drivable task types of the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.

The method can automatically complete the ATS part test work, thereby effectively avoiding input errors and output inspection errors caused by human factors, improving the test efficiency and the working quality, reducing the cost and realizing quick and accurate regression test. In addition, in the ATS simulation training of the user, some automatic tools are added, so that the operation convenience can be effectively improved, the test execution time can be saved, and the manual work intensity can be reduced.

The automatic test verification method based on the script language and the automatic execution framework of the embedded ATS software is completed by matching the following two parts, as shown in figure 1:

1. and generating a script file of the automatic test by combining the Lua script with the static data of the specific line. The script file names generated in the figure 3 are named by test functions, such as files of a road crossing test are named as road crossing automatic tests, xml, and further comprise a road crossing test, a platform buckling automatic test, a platform jump stop automatic test, a platform departure advance automatic test, a platform stop time automatic test, a planning vehicle automatic test and the like. Each record in the file serves as a separate execution unit, and all fields are combined into a complete MANUAL operation message (manual_device_operator) to be sent to the ATS system for simulating MANUAL operation. The execution unit that the system can discern includes platform car, automatic car, sets up first sign indicating number car, inspection train information, cancel the car of detaining, automatic car of deleting, set up jump stop, set up stop time, set up the route, cancel the route, launch in advance etc.. Each execution unit format varies according to the requirements of the message format. Specific fields of the platform buckle vehicle include: command type, command number, pre-command number, trigger time, execution period, timeout time, display name, centralized station number, station name, etc.; the specific fields of the header code vehicle are set to comprise: command type, command number, pre-command number, trigger time, execution period, timeout time, display name, central station number, train number, destination number, direction of operation, etc. Time-division second time (no preamble command) in which the trigger time indicates that the execution unit is expected to start running; the preamble number indicates a command number if the preamble is a preamble. The command number indicates the number of the execution unit, and needs to be kept unique in a command batch file for marking the actual execution object. The command type is used as a command name for script identification and execution logic after extracting custom content; the display name indicates a name displayed when a list or editing is performed.

Files for generating batch test scripts can be independently operated, and testers can be used for offline production; the method can also be directly called by C++ code in workstation software, and is used for generating batch tasks on line in real time and driving execution.

2. Within the ATS system, the workstation software interface provides a corresponding dialog box or menu as an entry for automatic testing, such as the "script command" shown in fig. 2, and pops up a dialog box after clicking. The commands in the configuration file under the specific path can be loaded by clicking a script loading button, and after the commands are loaded, the commands are executed by clicking a script running button, the execution state of the script can be terminated and restored by clicking a script stopping button, and the dialog box can be closed after the execution is finished. The dialog box is a modeless dialog box, and closing is just hidden. The buttons are enabled/disabled by state. If the script is loaded initially, the script cannot be loaded, and the script cannot be repeatedly run after the script is run. Closing, namely hiding, and pressing at any time. The dialog box is a general dialog box, and for any of the following functions, different xml command files are loaded through the dialog box. Command status is divided into waiting, executing, success, failure. Clicking on the "generate script" button in the dialog box opens a new dialog box, specifies the type of task to be generated, and the corresponding input file or path selection. The generation of the result will automatically fill the current list to begin execution.

Providing an automatic train distribution function, specifically, analyzing all train gauge numbers in a plan, finding gauge numbers from all stations to an originating point in a period of time (such as within 3 minutes) before and after the current time, if a certain gauge number does not have the station to the originating point before the current time, no instant train adding is needed, and generating a time train adding command from the first station to the originating point. Then, each table number is analyzed for the found table number and 4 stations to the point of departure, whether the table number coincides with the 3 stations in the other N-1 table numbers is found, if so, the table number whose scheduled arrival time is before the table number is found and is recorded as the "adding front table number" of the table number (if a plurality of table numbers coincide with the stations in which the current table number exists, the table number whose time is the latest at the coinciding station is found as the "adding front table number"). Then randomly find a table number, analyze which of its 4 stations to the origin is closest to the current time, add the car at that station, and register that station as "occupied". And then, traversing the to-be-added list numbers circularly, and finding out a list number which is not provided with a 'adding preamble list number' or is added with the 'adding preamble list number', and sequentially finding out the stations which are nearest to the current time and are not occupied from 4 stations to the starting point (if a certain station in the 4 stations is occupied, the stations can only be searched for an addable station from the stations behind the station). Thereafter, the adding of the vehicle list numbers is repeated circularly until all the list numbers are added (the circulation times are the number of the initial list numbers to be added, namely, adding is completed for one list number in each circulation).

FIG. 4 is a functional and interface design diagram of the main frame and the drivable task types in the present invention, and the following steps are described in detail with reference to FIG. 1:

step 401, a main body frame design, the initialization and the circulation judgment of a command list are processed, the frame lua and an external C++ host program are mutually called by utilizing a fixed interface function, and the processing of the command list formed by various commands is realized;

step 402, a task can be driven to correspond to a row of task objects in xml, each task category corresponds to a lua file with the same name, and a driving interface code of the task is realized in the lua file;

step 403, adding a car at a certain position of the line, setting an automatic car running, and judging whether the train is added normally at the position (by monitoring the corresponding event, checking whether the corresponding train is added and whether the position is correct);

step 404, a train number is set as the planned train. Judging whether the command is successfully executed or not by monitoring the corresponding message;

step 405, using the same output command, checking the same input state (tentatively in bit state, if it is included in xml definition and using different command definition), and can be summarized as a command (if the command format cannot conform to the definition described below, a new command can be defined separately), sending a command to the server according to the configuration file, checking the device_status_change according to the configuration file, and judging the execution status of the command. The judged equipment return state can be given by using a list configuration mode, so that the configuration is clearer;

step 406, setting the jump stop of the station and checking the execution condition of the command through the station state;

step 407, checking the task completion status of the train, and outputting the status of the route handling or outputting to the departure station. And (3) normally finishing: such as to arrive at and stop at a specified destination (speed 0). Abnormal conditions: if the train stops in the middle for more than a certain time. Whether the train is automatically deleted after the train meets the condition is specified;

in step 408, a certain car group number is set as the head-up car. Judging whether the command is successfully executed or not by monitoring the corresponding message;

step 409, setting a change strategy of the change button, and judging whether the command is successfully executed according to the returned device status message;

step 410, setting the stop time of the station and checking the execution condition of the command through the station status;

in step 411, the skip stop condition of the train is detected, and other stations are uniformly skip stopped except that the train does not skip stop after arriving at the station at the last station. And automatically deleting the vehicle after reaching the end point. Detecting the stop time and the running grade condition of the train;

step 412, tracking a train, when the current stop is not the destination address, setting a departure command after the allowed number of seconds of stop, and checking the departure condition of the train;

step 413, directly creating a current day plan through command call;

step 414, directly deleting the current day plan through command call;

in step 415, a train is deleted directly from the simulation system.

By adopting the automatic test verification method based on the script language and the automatic execution framework of the embedded ATS software, the escape rate of the defects of the product can be effectively reduced, and the quality of the product and the data can be improved. The efficiency in the regression test of the release of the ATS product and the point-to-point test of the data preparation can be obviously improved. Meanwhile, good guarantee is provided for the stable operation of the project site.

The foregoing description of the embodiments of the method further describes the embodiments of the present invention through embodiments of the electronic device and the storage medium.

The electronic device of the present invention includes a Central Processing Unit (CPU) that can perform various appropriate actions and processes according to computer program instructions stored in a Read Only Memory (ROM) or computer program instructions loaded from a storage unit into a Random Access Memory (RAM). In the RAM, various programs and data required for the operation of the device can also be stored. The CPU, ROM and RAM are connected to each other by a bus. An input/output (I/O) interface is also connected to the bus.

A plurality of components in a device are connected to an I/O interface, comprising: an input unit such as a keyboard, a mouse, etc.; an output unit such as various types of displays, speakers, and the like; a storage unit such as a magnetic disk, an optical disk, or the like; and communication units such as network cards, modems, wireless communication transceivers, and the like. The communication unit allows the device to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The processing unit performs the various methods and processes described above, such as the inventive method. For example, in some embodiments, the inventive methods may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device via the ROM and/or the communication unit. One or more of the steps of the method of the invention described above may be performed when the computer program is loaded into RAM and executed by a CPU. Alternatively, in other embodiments, the CPU may be configured to perform the methods of the present invention by any other suitable means (e.g., by means of firmware).

The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a Complex Programmable Logic Device (CPLD), and the like.

Program code for carrying out methods of the present invention may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present invention, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

While the invention has been described with reference to certain preferred embodiments, it will be understood by those skilled in the art that various changes and substitutions of equivalents may be made and equivalents will be apparent to those skilled in the art without departing from the scope of the invention. Therefore, the protection scope of the invention is subject to the protection scope of the claims.

Claims (12)

1. An ATS automatic test method based on a scripting language, which is characterized by comprising the following steps:

s1, generating a script file of an automatic test by combining a Lua script with static data of a specific line;

step S2, merging and putting the generated script file under an ATS system workstation software appointed directory according to the need;

and S3, the workstation interface enters an automatic test interface through a button or a menu, and a test command is loaded to automatically complete the test.

2. The automated testing method of ATS based on scripting language according to claim 1, wherein said step S1 specifically comprises the steps of:

step S11, running different scripts and reading line static data configuration;

step S12, checking the correctness of the read data;

and step S13, generating a corresponding automatic test script file according to the executed script and the selected different parameters.

3. The automated testing method of ATS based on scripting language according to claim 2, wherein the line static data configuration includes TLE data and plan data.

4. The automated test method of ATS based on scripting language according to claim 1, wherein the script file name generated in step S1 is named with test function.

5. The automated test method of ATS based on scripting language according to claim 1, wherein each record in the scripting file is used as a separate execution unit, and all fields are combined into a complete manual operation message to be sent to ATS system for simulating manual operation.

6. The automated test equipment (ATS) test method based on scripting language according to claim 5, wherein the execution units capable of being identified by the ATS system comprise platform car-locking, automatic car-adding, head car-setting, train information checking, car-unlocking, automatic car-deleting, jump-stopping setting, stop time setting, route-cancelling and car-launching in advance.

7. The automated testing method of ATS based on scripting language according to claim 5, wherein the execution unit formats are different according to the requirements of the message formats.

8. The automated test method of ATS based on scripting language according to claim 1, wherein generating batches of said script files is run independently, and the tester is used for offline production; or the batch tasks are directly called by C++ codes in the workstation software and used for generating batch tasks on line in real time and driving the execution.

9. The automated testing method of ATS based on scripting language according to claim 1, wherein said step S2 specifically includes:

step S21, combining a plurality of stations into a file according to the test quantity and the different test scripts generated by each station to serve as one-time automatic test content;

s22, putting the script command file combined according to the actual situation under a workstation software directory;

and S23, copying the script file for generating the test command file to a designated directory of the workstation for generating the script command on line in real time and synchronously executing the script command.

10. The automated testing method of ATS based on scripting language according to claim 1, wherein said step S3 specifically includes:

step S31, clicking a batch command and a script command on a workstation interface menu, and popping up an automatic test operation dialog box;

step S32, clicking a loading script, reading a script command file stored under the specified directory in the step S2, and displaying the script command file in an operation dialog box according to the display name configured in the command;

step S33, clicking an operation script, starting execution from the initial command ID, and clicking the operation stop to end the automatic test of the function in the execution process;

step S34, clicking "close" to close the dialog box;

step S35, clicking the automatic vehicle distribution, and completing analysis and operation of the automatic vehicle distribution;

step S36, giving out a pop-up alarm of operation completion after all operations are completed, and giving out a successful or failed execution result to each step in an operation interface;

and step S37, storing an automatic test log executed at the time at a designated position, and taking the automatic test log as a verification log to facilitate inquiry.

11. An electronic device comprising a memory and a processor, the memory having stored thereon a computer program, characterized in that the processor, when executing the program, implements the method of any of claims 1-10.

12. A computer readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any one of claims 1-10.

Images