CN112131094A - Method and device for testing track signal system software and storage medium - Google Patents
Method and device for testing track signal system software and storage medium Download PDFInfo
- Publication number
- CN112131094A CN112131094A CN201910553493.4A CN201910553493A CN112131094A CN 112131094 A CN112131094 A CN 112131094A CN 201910553493 A CN201910553493 A CN 201910553493A CN 112131094 A CN112131094 A CN 112131094A
- Authority
- CN
- China
- Prior art keywords
- test
- testing
- software
- unit
- simulation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3644—Software debugging by instrumenting at runtime
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3648—Software debugging using additional hardware
- G06F11/3656—Software debugging using additional hardware using a specific debug interface
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/366—Software debugging using diagnostics
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application provides a method, a device and a storage medium for testing track signal system software, wherein the method comprises the following steps: loading a test case, analyzing the test case, acquiring an equipment identifier required to be started, generating a step list to be executed, wherein the equipment identifier comprises a simulation test environment identifier and at least one subsystem software identifier, starting related simulation test environment and subsystem software according to the equipment identifier, and creating a simulation test environment interface and subsystem software interface; according to the step list, testing operation is carried out through the simulation testing environment interface and/or the subsystem software interface, and a testing result is generated; and generating a test report according to the test result. By the method, automatic testing of software of each subsystem in the urban rail transit signal system can be realized, and the technical problems of low testing efficiency and high human resource consumption of manual testing in the prior art are solved.
Description
Technical Field
The present disclosure relates to the field of rail transit technologies, and in particular, to a method and an apparatus for testing rail signal system software, and a storage medium.
Background
The urban rail transit signal System comprises a plurality of intercommunicating subsystems such as an Automatic Train monitoring System (ATS), a Vehicle-mounted control System (VOBC), a Computer Interlocking (CI), a Zone control System (ZC), and the like, and software of the subsystems needs a lot of tests before formal online to ensure safety and reliability.
Currently, the software testing is a manual testing performed by software testers according to test cases, the testers operate the software of different subsystems according to the test cases, and whether the software is abnormal is judged through a simulation test environment, user interface display of a monitoring system and a driver's cab, log information and subsequent behaviors of the software. In the related technology, the testing efficiency of manual testing is low, the workload of software testers is large, and when the software version is updated and iterated faster or the software versions are more, human resources are consumed more.
Disclosure of Invention
The present application is directed to solving, at least to some extent, one of the technical problems in the related art.
Therefore, the application provides a method and a device for testing track signal system software and a storage medium, which are used for realizing automatic testing of software of each subsystem in an urban track traffic signal system and solving the technical problems of low testing efficiency and high human resource consumption of manual testing in the prior art.
An embodiment of a first aspect of the present application provides a method for testing track signal system software, including:
loading a test case;
analyzing the test case, acquiring an equipment identifier required to be started, and generating a step list to be executed, wherein the equipment identifier comprises a simulation test environment identifier and at least one subsystem software identifier;
starting related simulation test environment and subsystem software according to the subsystem software to be started, and creating a simulation test environment interface and a subsystem software interface;
according to the step list, testing operation is carried out through the simulation testing environment interface and/or the subsystem software interface, and a testing result is generated;
and generating a test report according to the test result.
According to the testing method of the track signal system software, the testing case is loaded and analyzed, the equipment identification required to be started is obtained, the step list to be executed is generated, the equipment identification comprises the simulation testing environment identification and at least one subsystem software identification, relevant simulation testing environment and subsystem software are started according to the equipment identification, a simulation testing environment interface and subsystem software interface is created, further, testing operation is performed through the simulation testing environment interface and/or the subsystem software interface according to the step list, the testing result is generated, and the testing report is generated according to the testing result. Therefore, the automatic testing of the software is realized, and when the software of each subsystem needs to be tested, the testing of the case can be completed only by loading and analyzing the corresponding testing case, so that the testing efficiency and the testing flexibility are improved, the human resource consumption is greatly reduced, and the workload of testing personnel is reduced. In addition, the number of the subsystem software can be multiple, that is, the subsystem software can be accessed in the same test case, so that the automatic test of the subsystem interaction scene can be completed only by starting the related subsystem software according to the test case for the test scene needing the subsystem interaction, the test process is simplified, and the test efficiency is improved.
The embodiment of the second aspect of the present application provides a testing apparatus for track signal system software, including:
the loading module is used for loading the test cases;
the analysis module is used for analyzing the test case, acquiring an equipment identifier required to be started and generating a step list to be executed, wherein the equipment identifier comprises a simulation test environment identifier and at least one subsystem software identifier;
the initialization module is used for starting related simulation test environment and subsystem software according to the subsystem software to be started and creating a simulation test environment interface and a subsystem software interface;
the test module is used for carrying out test operation through the simulation test environment interface and/or the subsystem software interface according to the step list to generate a test result;
and the generating module is used for generating a test report according to the test result.
According to the testing device of the track signal system software, the testing case is analyzed by loading the testing case, the equipment identification required to be started is obtained, the step list to be executed is generated, the equipment identification comprises the simulation testing environment identification and at least one subsystem software identification, relevant simulation testing environment and subsystem software are started according to the equipment identification, a simulation testing environment interface and subsystem software interface are created, further, testing operation is performed through the simulation testing environment interface and/or the subsystem software interface according to the step list, the testing result is generated, and the testing report is generated according to the testing result. Therefore, the automatic testing of the software is realized, and when the software of each subsystem needs to be tested, the testing of the case can be completed only by loading and analyzing the corresponding testing case, so that the testing efficiency and the testing flexibility are improved, the human resource consumption is greatly reduced, and the workload of testing personnel is reduced. In addition, the number of the subsystem software can be multiple, that is, the subsystem software can be accessed in the same test case, so that the automatic test of the subsystem interaction scene can be completed only by starting the related subsystem software according to the test case for the test scene needing the subsystem interaction, the test process is simplified, and the test efficiency is improved.
An embodiment of a third aspect of the present application provides an automatic test device, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and when the processor executes the computer program, the automatic test device implements the test method for the track signal system software according to the embodiment of the first aspect.
An embodiment of a fourth aspect of the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the method for testing the track signal system software according to the embodiment of the first aspect.
Additional aspects and advantages of the present application will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the present application.
Drawings
The foregoing and/or additional aspects and advantages of the present application will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:
fig. 1 is a schematic flowchart illustrating a method for testing track signal system software according to an embodiment of the present application;
FIG. 2 is an exemplary diagram of class relationships for test cases;
FIG. 3 is an exemplary diagram of one testing step for testing a computer interlocking subsystem;
FIG. 4 is a timing diagram of a test process for testing interlocking software;
FIG. 5 is a diagram illustrating a test method for testing a plurality of subsystem software according to an embodiment of the present application;
fig. 6 is a flowchart illustrating a method for testing track signal system software according to another embodiment of the present application;
FIG. 7 is an exemplary diagram of implementing flow control functions using set keywords;
fig. 8 is a flowchart illustrating a method for testing track signal system software according to another embodiment of the present application;
fig. 9 is a flowchart illustrating a testing method of track signal system software according to yet another embodiment of the present application;
FIG. 10 is an exemplary illustration of a train upgrade test case;
FIG. 11 is an exemplary diagram of template files referenced in a train upgrade test case;
fig. 12 is a schematic structural diagram of a testing apparatus for track signal system software according to an embodiment of the present application;
fig. 13 is a schematic structural diagram of a testing apparatus for track signal system software according to another embodiment of the present application;
fig. 14 is a schematic structural diagram of a testing apparatus for track signal system software according to yet another embodiment of the present application.
Detailed Description
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.
A method, an apparatus, and a storage medium for testing track signal system software according to embodiments of the present application are described below with reference to the accompanying drawings.
At present, most software testers perform manual testing on each subsystem software in an urban rail transit signal system according to test cases, so that the testing efficiency is low, and the consumption of human resources is high. The inventor finds that the test for the data accuracy and the flow correctness is heavier in the test of each subsystem software, the test steps of the test are relatively fixed, but the test by adopting a manual test mode still needs high attention of a tester. For some pressure test cases for testing the stability of software, the test process takes longer time, when the software is tested to be abnormal, the time period of suspicious problems is wider, and the difficulty of testing personnel for checking the problems is high. In addition, when the software version is updated faster or the software versions are more, more testers are required to participate in the testing work, and the testing labor is more tense.
Aiming at the problems, the application provides a test method of track signal system software, which can complete the test of a case by compiling a test case into a test script and only loading and analyzing the corresponding test script when the software of each subsystem needs to be tested, thereby realizing the automatic test of the software and reducing the consumption of manpower resources.
Fig. 1 is a schematic flow chart of a method for testing track signal system software according to an embodiment of the present application, where the method may be executed by a device for testing track signal system software according to the embodiment of the present application, or may be executed by a computer.
As shown in fig. 1, the method for testing the track signal system software may include the following steps:
The testing case can be compiled by a tester according to actual testing requirements, the tester can compile a plurality of testing cases in advance, and when a certain subsystem software needs to be tested, the required testing case can be selected from the plurality of testing cases.
As an example, the testing device of the track signal system software may provide a user operation interface for a tester, where all selectable test cases are displayed in the user operation interface, the tester may select a required test case from the user operation interface according to a test requirement, and after the tester completes the selection, the testing device of the track signal system software loads the test case selected by the tester. Wherein, the tester can select one or more test cases according to the test requirement.
In the embodiment, one test case can access different subsystem software, so that for a test scene needing subsystem software interaction, the related subsystem software can be written into the same test case, and the test of the interaction of a plurality of subsystems can be completed only by loading one test case.
102, analyzing the test case, acquiring an equipment identifier required to be started, and generating a list of steps to be executed, wherein the equipment identifier comprises a simulation test environment identifier and at least one subsystem software identifier.
In this embodiment, after the test device of the track signal system software finishes loading the test case, the loaded test case may be analyzed, the test number, the test object, the identifier of the simulation test environment that needs to be started for executing the test case, the identifier of the at least one subsystem software that needs to be started, the test step unit, and the like are read from the test case, and the test step corresponding to the test step unit is added to the step list.
The subsystem software to be started at least comprises the subsystem software to be tested, namely a test object, and can also comprise other subsystem software which needs to interact with the subsystem software to be tested in the test process.
In a specific implementation, the entire test case may be managed by the test management class module test _ manager, as shown in fig. 2, and fig. 2 is an exemplary diagram of a class relationship of the test case. As shown in fig. 2, a plurality of classes such as a parser module parser, a case list module case _ list, a report generation module html _ util, and a tool module xmlutil are managed under the test _ manager. The system comprises an xmlutil module, a template file and a parameter variable replacing module, wherein the xmlutil module is used for providing a test case analyzing tool, analyzing a test case by using the tool provided by the xmlutil module, analyzing a template file quoted in the test case, and replacing the parameter variable in the template file, wherein the template file is an xml file and is generated by abstracting a plurality of test cases with basically the same test steps; the case _ list module is used for displaying a case unit list, each test _ case in the case _ list is a case unit, each case unit corresponds to a test case, each case unit comprises a case number case _ id, a case name case _ name, a step list step, a simulation test environment needing to be started, subsystem software xx _ on and the like, parameters of each part in the test _ case are determined according to an analysis result of the test case, and the step list step comprises a plurality of specific execution steps test _ step; the parsing module parser is used for parsing the testing step to generate a specific execution instruction, and controlling the testing process, such as pausing and stopping; the html _ util module is used for generating a test report after the test is completed. When subsystem software needs to be tested, a tester can select a required test case, after the test case selected by the tester is loaded by a testing device of the track signal system software, the test case is analyzed by using an xmlutil module, an analysis result is stored in case _ list, after the analysis is completed, a test step in a step list steps is analyzed by using an analysis module parser to generate a corresponding operation instruction, the test is performed according to the operation instruction, and after all test steps in the step list are completed, a test report is generated by using an html _ util module.
It should be noted that, when a plurality of loaded test cases are available, each test case may be sequentially analyzed to obtain the subsystem software to be started and the step list corresponding to each test case, and the analysis result of each test case corresponds to one test _ case in fig. 2.
103, starting related simulation test environment and subsystem software according to the equipment identifier, and creating a simulation test environment interface and subsystem software interface.
In this embodiment, after the test case is analyzed, the testing apparatus of the track signal system software may start the corresponding subsystem software and the simulation test environment according to the obtained device identifier to be started, and create the simulation test environment interface and the subsystem software interface.
For example, after the test case is analyzed, xx _ on includes ate _ on and VOBC _ on in the case unit test _ case shown in fig. 2, and the testing apparatus of the track signal system software starts the simulation test environment and the vehicle-mounted control system VOBC.
It should be noted that the simulation test environment interface and the subsystem software interface may be created after the simulation test environment and the subsystem software are started according to the acquired subsystem software to be started, or each subsystem software interface and the simulation test environment interface may be pre-established, and after the simulation test environment and the subsystem software are started, the corresponding interface is called according to the acquired subsystem software to be started, which is not limited in this application.
It can be understood that after the simulation test environment and the subsystem software are started, a communication connection is established between the simulation test environment and the subsystem software to ensure that the internal service is operated.
And step 104, performing test operation through the simulation test environment interface and/or the subsystem software interface according to the step list to generate a test result.
In this embodiment, after the step list is generated by analyzing the test case, the testing device of the track signal system software may perform a testing operation through the simulation testing environment interface and/or the subsystem software interface according to the testing steps in the step list, so as to generate a testing result.
As can be seen from fig. 2, the test _ step includes a plurality of parameters, such as test object, test module, test operation, test parameter, expected result except, etc. FIG. 3 is an exemplary diagram of one test step for testing a computer interlocking subsystem. As shown in fig. 3, if the test object is "CI", the test module is "route", the test operation is "check signal", the test parameters are "S0102, S _ grn _ color", and the expected result is "1", the track signal software-based test apparatus tests the router module of CI through the system interface of CI, and obtains the test result.
In a possible implementation manner of the embodiment of the present application, before performing a testing operation according to the step list and through the simulation testing environment interface and/or the subsystem software interface to generate a testing result, the testing device of the orbit signal system software may first establish a ZeroMQ (ZMQ for short, similar to a series of interfaces of Socket) connection with the simulation testing environment and establish a telnet connection with the subsystem software. ZMQ can implement a one-to-many connection relationship, in this embodiment, the testing apparatus of the track signal system software implements cross-process message delivery through a publish-subscribe mode of ZMQ; lua is arranged in each subsystem software to be used as a debugging means, and a testing device of the track signal system software sends a Lua command to the subsystem software through telnet connection so as to obtain the state of the subsystem variable or trigger the execution of the subsystem function.
Further, after ZMQ connection with the simulation test environment is established, initialization operation may be performed on ZMQ connection, and after telnet connection with the subsystem software is established, initialization operation may be performed on the telnet connection to ensure that ZMQ connection and the telnet connection can be used normally. The initialization operation may include, for example, document configuration, internal variable initialization, file path setting, and the like.
In a possible implementation manner of the embodiment of the application, the testing device of the track signal system software performs the testing operation in the simulation testing environment interface and/or the subsystem software interface according to the step list, and when the testing result is generated, may send the operation instruction to the simulation testing environment interface according to the testing step in the step list, and obtain the relevant feedback state variable from the subsystem software interface, and/or send the operation instruction to the subsystem software interface, and obtain the relevant feedback state variable from the simulation testing environment interface. The method is suitable for testing the state variables in the subsystem software, such as testing the track occupation information; the method for sending the operation instruction to the subsystem software interface and acquiring the relevant feedback state variable from the simulation test environment interface is suitable for testing the output simulation quantity in the subsystem software, such as testing the relay drive. Then, after the feedback state variable is obtained, the feedback state variable may be compared with a corresponding expected state variable, and a test result may be generated according to the comparison result. The method and the device support the test steps to be executed and the feedback state variables to be acquired from different interfaces, the flexibility of the test is improved, and the next test step does not need to be executed after the feedback state variables are acquired, so that the test time is saved, and the test efficiency is improved.
For example, in the testing step shown in fig. 3, the testing apparatus based on the track signal software may obtain the feedback state variable corresponding to the test from the simulation testing environment interface or from the CI interface, and compare the obtained feedback state variable with the expected result "1" to obtain the testing result. When the test result is failure, the test step and the information such as the difference between the feedback state variable value and the expected result can be recorded so as to feed back to a tester when a test report is finally output.
And 105, generating a test report according to the test result.
In this embodiment, after all the test steps in the step list are executed, the test results generated in the test process may be summarized to generate a test report. And then, the test report can be fed back to related testers, so that the testers can obtain the test condition of the subsystem software, and further, corresponding correction measures are taken according to the test condition to adjust the subsystem software.
It should be noted that, when a plurality of loaded test cases are available, after the step list corresponding to one test case is executed, the subsystem software and the simulation test environment related to the next test case are started, and the step list corresponding to the next test case is executed until all the loaded test cases are executed. When the test report is generated according to the test result, the test report corresponding to the test case may be generated according to the test result corresponding to each test case, or after all the loaded test cases are executed, a total test report may be generated according to the test result corresponding to each test case, which is not limited in this application.
Further, in a possible implementation manner of the embodiment of the present application, after all the test steps in the step list are executed, the simulation test environment and the subsystem software related to the test case may be closed, and when the next test case starts, the simulation test environment and the subsystem software are restarted, so as to avoid mutual influence between the test cases.
Fig. 4 is a timing chart of a test process for testing the interlocking software, and in this example, a test case which relates to the interlocking software alone is taken as an example. The method comprises the steps that a tester selects a test case required by testing the interlocking software, a testing device loads the test case selected by the tester and analyzes the test case to obtain subsystem software to be started for executing the test case, namely the interlocking software, a step list is generated according to an analysis result, and after the analysis is completed, the testing process is started. Specifically, as shown in fig. 4, first, the simulation test environment and the interlock software are started, and a simulation test environment interface and an interlock software interface are created inside the test apparatus, where a subscription and release client program of ZMQ is stored in the simulation test environment interface, that is, a ZMQ message sending and receiving client is established, and corresponding initialization operation is performed, and a telnet interface communicating with the interlock software is stored in the interlock software interface, that is, telnet connection with the interlock software is established, and corresponding initialization operation is performed. And after the simulation test environment and the interlocking software are operated, the simulation test environment and the interlocking software are periodically communicated to ensure the operation of the internal service. After that, the specific test steps in the step list are executed, and the operation command may be sent to the simulation test environment according to the test steps to obtain the relevant variable state from the interlocking software through the Lua command, or the operation command may be sent to the interlocking software according to the test steps to obtain the relevant variable state from the simulation test environment through ZMQ. Furthermore, the testing device compares the acquired state of the relevant variable with expected data to judge a testing result. As shown in fig. 4, the test steps in the step list are executed in a loop, and after one test step is executed, the next test step is executed continuously until all the test steps in the step list are executed, and the test case is ended. And after the test case is finished, closing the simulation test environment and the interlocking software which are started according to the test case.
The test method for the track signal system software provided by the embodiment of the application can load different test cases to test different subsystem software. Fig. 5 is an exemplary diagram of testing a plurality of subsystem software by using the testing method proposed in the embodiment of the present application. As shown in fig. 5, a test case corresponding to each subsystem software to be tested may be loaded, after the test case is analyzed, the related subsystem software related to the test case is started, the number of the subsystem software may be one or more, and an interface corresponding to an object identifier is obtained according to the object identifier related to the test step in the test case, for example, when the object identifier is CI, that is, the interlock software is obtained, the interlock software interface is obtained, and the test step is executed through the obtained interlock software interface. And after executing one test step, judging whether the test steps in the currently executed test case are all executed, if not, continuing to execute the next test step, and if so, closing the subsystem software and the simulation test environment related to the test case to carry out the next test case. The execution process of each test case can be referred to fig. 4. And after all the test cases are executed, outputting a test report according to the test result, and finishing the test.
It should be noted that, in order to avoid the mutual influence of the test cases, the subsystem software and the simulation environment may be restarted at the beginning of each test case.
According to the testing method of the track signal system software, the testing case is analyzed by loading the testing case, the equipment identification required to be started is obtained, the step list to be executed is generated, the equipment identification comprises the simulation testing environment identification and at least one subsystem software identification, the relevant simulation testing environment and subsystem software are started according to the equipment identification, the simulation testing environment interface and the subsystem software interface are created, further, the testing operation is performed through the simulation testing environment interface and/or the subsystem software interface according to the step list, the testing result is generated, and the testing report is generated according to the testing result. Therefore, the automatic testing of the software is realized, and when the software of each subsystem needs to be tested, the testing of the case can be completed only by loading and analyzing the corresponding testing case, so that the testing efficiency and the testing flexibility are improved, the human resource consumption is greatly reduced, and the workload of testing personnel is reduced. In addition, the number of the subsystem software can be multiple, that is, the subsystem software can be accessed in the same test case, so that the automatic test of the subsystem interaction scene can be completed only by starting the related subsystem software according to the test case for the test scene needing the subsystem interaction, the test process is simplified, and the test efficiency is improved.
In a possible implementation manner of the embodiment of the present application, as shown in fig. 6, on the basis of the embodiment shown in fig. 1, before step 101, the following step may be further included:
The keywords can be set by self-definition, and the keywords can be divided into service keywords and other keywords. The service keywords are related to specific services, such as checking the light color of a signal, adding a car and the like; other keywords are related to adjusting the test flow, such as waiting, resuming, jumping steps, etc., and may also be keywords set for making the test process more visible, such as separators for distinguishing the test progress, etc.
In the service keywords, the keywords may have a function of controlling the flow. For example, fig. 7 is an exemplary diagram for implementing a flow control function by using a set keyword, and as shown in fig. 7, a parameter of the test step is "while _ ne", which indicates that a current step is checked in a loop manner, and a wait time can be customized after while _ ne, as an example, the default wait time is 600 seconds, which is not limited in the present application. And when the operation is executed in a circulating way when the acquired feedback state variable of the testing step is inconsistent with the expected result, and the testing step fails when the operation is overtime, namely the waiting time is up and the feedback state variable consistent with the expected result is not acquired. The keywords are suitable for the test cases with uncontrollable time points when the variable matching is successful in the test process.
In this embodiment, the testing step may be controlled according to the set keyword.
For example, the waiting step may be generated by using the keyword "wait" and setting a corresponding waiting time, and the set waiting time is waited before executing a specific testing step, so as to ensure that the initialization of the subsystem software to be tested is completed.
For another example, the keyword segarator may be used to add a separation prompt "- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -.
In this embodiment, according to the testing step of the keyword control generation, an Extensible Markup Language (XML) may be applied to generate a testing case for the carrier.
Compared with a scheme of organizing the test cases by a custom language, the test case compiling method based on the XML language has the advantages that the test cases are generated by taking the XML language as a carrier, difficulty in compiling the test cases is reduced, and operation is simpler.
For some test cases, the test steps are essentially the same, except that the specific data is different. The template file can be generated according to the conditions that the test cases are similar in height process and different in parameters, and then only the template file needs to be called in a specific test case, different test cases are achieved through simple parameter replacement, and therefore the compiling efficiency of the test cases is improved. The above process is described in detail with reference to fig. 8.
Fig. 8 is a flowchart illustrating a method for testing track signal system software according to another embodiment of the present application. As shown in fig. 8, on the basis of the foregoing embodiment, the method for testing track signal system software may further include the following steps:
When the test steps are multiple, the multiple test steps can be controlled by using preset keywords.
In this embodiment, when the template file is generated according to at least one test step, different parameters in a plurality of test cases need to be replaced with specific characters, and when a test case is generated, the specific characters in the template file are replaced by setting the required parameters. Wherein, a template file can be generated for the carrier by XML.
As an example, the template file may be "base _" as the initial key, for example, the template file may be named "base _ upgrade to FAM mode. xml", and the specific steps required for the test are recorded in the template file and replaced with a "$" headed string where specific data is required.
In this embodiment, the generated template file cannot be run alone, but can be configured in a test case. In particular, XML may be applied to configure template files into test cases for carriers.
As an example, a template file may be referred to by "< include >" in a test case, specific data to be configured in the template file may be set by "< parameter id ═" $ XX ">" in the test case, and when a test step in the test case is parsed, the set specific data is replaced in the template file, so as to obtain the test step to be executed.
The template file is generated according to at least one testing step, and the XML is applied to configure the template file into the testing case, so that the compiling efficiency of the testing case can be improved, the mixed calling of the specific testing step and the testing step in the template file is realized, and the testing flexibility is improved.
Further, on the basis of the foregoing embodiment, as shown in fig. 9, in step 102, analyzing the test case to generate a list of steps to be executed may include the following steps:
The test step units can be identified by step, step and test and the content between step form a test step unit, which is shown in fig. 3, and one test step unit corresponds to one test step.
In this embodiment, when analyzing the test case, the analysis may be performed from the first test step unit, the first test step unit in the test case is obtained first, and whether the test step unit is an expansion unit is determined, the subsequent steps are executed according to the determination result, after one test step unit is analyzed, the next test step unit is continuously executed until all test step units in the test case are analyzed, and the analysis is completed.
In the test case, the expansion unit can be identified according to "< include > </include >", when the test step unit includes "< include > </include >", the test step unit is judged to be the expansion unit, step 402 is executed, otherwise, the test step unit is judged not to be the expansion unit, and step 404 is executed.
In this embodiment, when the test step unit is an extension unit, the corresponding replacement parameter information is read, and a replacement parameter table is generated. The replacing parameter information is set through < parameter id ═ XX "> in the test case, and a character string with a" $ "heading can be read as the replacing parameter information. For example, if the parameter set in the extension unit is "< parameter id ═ $ add car track" >, the read replacement parameter information is "$ add car track".
And when the testing step unit is an expansion unit, reading the corresponding template file. For example, if the expansion unit includes a statement "< include >/base/base _ upgrade to FAM mode. xml </include >", the template file "base _ upgrade to FAM mode. xml" is read.
And step 403, replacing the parameter variables in the template file according to the replacement parameter table, and adding the test steps in the template file to the step list.
In this embodiment, after the replacement parameter table is generated and the template file is read, the parameter variables in the template file may be replaced according to the replacement parameter table and added to the step list. Specifically, the position of the template file where the specific parameter is needed may be replaced by using the replacement parameter information in the replacement parameter table, and then the test step in the template file is added to the step list. The step list stores test steps required to be executed in the test, and the test steps in the step list are executed in sequence when the test is carried out.
In specific implementation, after the template file is read, the template file can be analyzed, the test steps in the template file are sequentially read, the read test steps are added to a step list for waiting execution, when the test steps related to parameter replacement are read, the parameter variables in the test steps are replaced by the replacement parameter information in the replacement parameter table, and the test steps after parameter variables are replaced are added to the step list. And sequentially reading the test steps in the template file until all the test steps in the template file are read, withdrawing the template file, and returning to the next test step unit after the expansion unit is read.
In step 404, it is determined whether the test step unit is a split hint character unit.
In this embodiment, when it is determined that the test step unit is not the extension unit, it is further determined whether the test step unit is the separation hint character unit.
Specifically, whether the step unit is the separator cue character unit can be judged by judging whether "< separator > </separator >" is included in the test step unit. If the test step unit includes "< syndrome > </syndrome >", then the test step unit is determined to be a separation cue character unit, step 405 is executed, otherwise, the test step unit is determined to be a normal execution test step unit, and step 406 is executed.
In this embodiment, when the test step unit is the separation prompt character unit, the separation string required to be output is stored, and the step of outputting the separation string corresponding to the test step unit is added to the step list.
For example, the test procedure units are as follows:
<step>
the FAM is upgraded again after the stability of the FAM is degraded to CM
</step>
Judging that the test step unit is a separation prompt character unit, upgrading to the FAM again after degrading the stability of the separation character string to CM, storing, and adding the operation steps of upgrading to the FAM again after degrading the stability of the output FAM to CM into the step list.
And after the separation prompt character unit is added into the step list, continuing to read the next test step unit, if the test step unit is read, continuing to judge whether the test step unit is an expansion unit, executing the relevant steps in the embodiment according to the judgment result, and if the test step unit is not read, determining that all test step units in the test case are read completely, and starting to execute the steps in the step list for testing.
The related information of the test procedure unit includes, but is not limited to, the object, parameter, operation, etc. involved in the test procedure unit.
In this embodiment, when the test step unit is neither the extension unit nor the separation prompt character unit, it may be determined that the test step corresponding to the test step unit is a normal execution test step, information of an object, a module, an operation, and the like related to the test step unit is stored, and the test step corresponding to the test step unit is added to the step list to wait for execution. And then, continuously acquiring the next test step unit, if the test step unit cannot be acquired, indicating that all the test step units in the test case are completely read, and starting the test, otherwise, returning to execute the step 401.
Fig. 10 is an exemplary diagram of a train upgrade test case, and fig. 11 is an exemplary diagram of a template file cited in the train upgrade test case. As shown in fig. 10, in the preliminary unit pretest, if the parameter value of ate _ on, ci _ on, and vobc _ on is 1, and the parameter value of zc _ on is 0, the test case is analyzed, and the obtained device identifier includes ate, ci, and vobc, that is, in the case unit test _ case shown in fig. 2, xx _ on includes: ate _ on, ci _ on, and vobc _ on. Then, starting to read the test step units in the test case, reading the first test step unit, waiting for 10 seconds to ensure that the software of each subsystem is initially completed, wherein the test step unit is a common test step execution unit, storing the relevant parameters of the test step unit, and adding the waiting step waiting for 10 seconds into a step list; then, reading a second test step unit, wherein the test step unit is a separation prompt character unit, automatically turning back 2 cars and the separation prompt character string to be output to 52 to be stored, and adding the output step of outputting the separation prompt character string to the step list; reading a third testing step unit, which is an expansion unit, entering the template file "base _ upgrade to FAM mode. xml", as shown in fig. 11, and starting to read each testing step in the template file. Wherein, when reading the test steps in the template file, the parameters in the first test step are replaced by the character string "$ add _ car _ track" specified in the test case. And reading all the test steps in the template file in sequence, adding the test steps in the template file into the step list until the template file is finished, returning the test case, continuing to read the fourth test step unit in the test case, reading each test step unit in the test case in sequence until all the test step units are read, and completing the analysis of the test case. And then starting the interlocking software, the vehicle-mounted control software and the simulation test environment, and starting to execute the test steps in the step list in sequence. And when the test steps in the step list are all executed, finishing the test and outputting a test report.
According to the testing method of the track signal system software, the template file is set and quoted in the testing case, so that the compiling efficiency of the testing case can be improved.
In order to implement the above embodiments, the present application further provides a testing apparatus for track signal system software.
Fig. 12 is a schematic structural diagram of a testing apparatus for track signal system software according to an embodiment of the present application.
As shown in fig. 12, the test apparatus 60 for track signal system software includes: a loading module 610, a parsing module 620, an initialization module 630, a testing module 640, and a generation module 650.
The loading module 610 is configured to load a test case.
The analyzing module 620 is configured to analyze the test case, obtain an identifier of the device to be started, and generate a list of steps to be executed, where the identifier of the device includes an identifier of the simulation test environment and an identifier of at least one subsystem software.
The initialization module 630 is configured to start the related simulation test environment and subsystem software according to the device identifier, and create a simulation test environment interface and subsystem software interface.
And the test module 640 is configured to perform a test operation through the simulation test environment interface and/or the subsystem software interface according to the step list, and generate a test result.
In a possible implementation manner of the embodiment of the present application, the test module 640 is specifically configured to send an operation instruction to the simulation test environment interface according to the test step in the step list, and obtain a relevant feedback state variable from the subsystem software interface, and/or send an operation instruction to the subsystem software interface, and obtain a relevant feedback state variable from the simulation test environment interface; and comparing the feedback state variable with the corresponding expected state variable, and generating a test result according to the comparison result.
And a generating module 650, configured to generate a test report according to the test result.
In a possible implementation manner of the embodiment of the present application, the initialization module 630 is further configured to establish ZMQ connection with the simulation test environment; and establishing telnet connection with subsystem software.
Further, the initialization module 630 is further configured to perform an initialization operation on ZMQ connection and to perform an initialization operation on ZMQ connection.
In a possible implementation manner of the embodiment of the present application, as shown in fig. 13, on the basis of the embodiment shown in fig. 12, the testing apparatus 60 of the track signal system software may further include:
a case generation module 600, configured to set keywords and control the testing steps by using the keywords; and generating a test case for the carrier by applying XML according to the test step.
In a possible implementation manner of the embodiment of the present application, the case generation module 600 is further configured to generate a template file according to at least one test step; and configuring the template file to the test case by applying XML as a carrier.
In this embodiment, the parsing module 620 is specifically configured to: acquiring a test step unit in a test case, and judging whether the test step unit is an expansion unit or not; if the test step unit is an expansion unit, reading corresponding replacement parameter information, generating a replacement parameter table, and reading a corresponding template file; replacing parameter variables in the template file according to the replacement parameter table, and adding the testing steps in the template file into the step list; if the test step unit is not an expansion unit, judging whether the test step unit is a separation prompt character unit, if so, storing a separation character string needing to be output, and adding the separation character string to the step list; and if the test step unit is not the separation prompt character unit, storing the relevant information of the test step unit, and adding the test step corresponding to the test step unit to the step list.
In a possible implementation manner of the embodiment of the present application, as shown in fig. 14, on the basis of the embodiment shown in fig. 12, the testing apparatus 60 of the track signal system software may further include:
and a closing module 660, configured to close the simulation test environment and the subsystem software related to the test case after all the test steps in the step list are executed.
It should be noted that the foregoing explanation of the embodiment of the method for testing track signal system software is also applicable to the testing apparatus of the track signal system software of the embodiment, and the implementation principle thereof is similar, and is not repeated here.
According to the testing device of the track signal system software, the testing case is analyzed by loading the testing case, the equipment identification required to be started is obtained, the step list to be executed is generated, the equipment identification comprises the simulation testing environment identification and at least one subsystem software identification, relevant simulation testing environment and subsystem software are started according to the equipment identification, a simulation testing environment interface and subsystem software interface are created, further, testing operation is performed through the simulation testing environment interface and/or the subsystem software interface according to the step list, the testing result is generated, and the testing report is generated according to the testing result. Therefore, the automatic testing of the software is realized, and when the software of each subsystem needs to be tested, the testing of the case can be completed only by loading and analyzing the corresponding testing case, so that the testing efficiency and the testing flexibility are improved, the human resource consumption is greatly reduced, and the workload of testing personnel is reduced. In addition, the number of the subsystem software can be multiple, that is, the subsystem software can be accessed in the same test case, so that the automatic test of the subsystem interaction scene can be completed only by starting the related subsystem software according to the test case for the test scene needing the subsystem interaction, the test process is simplified, and the test efficiency is improved.
In order to implement the foregoing embodiments, the present application further provides an automatic test device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the automatic test device implements the test method for the track signal system software according to the foregoing embodiments.
In order to implement the foregoing embodiments, the present application further proposes a computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, implements the method for testing the track signal system software according to the foregoing embodiments.
In the description herein, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the application. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.
Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing steps of a custom logic function or process, and alternate implementations are included within the scope of the preferred embodiment of the present application in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present application.
The logic and/or steps represented in the flowcharts or otherwise described herein, e.g., an ordered listing of executable instructions that can be considered to implement logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
It should be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
It will be understood by those skilled in the art that all or part of the steps carried by the method for implementing the above embodiments may be implemented by hardware related to instructions of a program, which may be stored in a computer readable storage medium, and when the program is executed, the program includes one or a combination of the steps of the method embodiments.
In addition, functional units in the embodiments of the present application may be integrated into one processing module, or each unit may exist alone physically, or two or more units are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a stand-alone product, may also be stored in a computer readable storage medium.
The storage medium mentioned above may be a read-only memory, a magnetic or optical disk, etc. Although embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application, and that variations, modifications, substitutions and alterations may be made to the above embodiments by those of ordinary skill in the art within the scope of the present application.
Claims (20)
1. A test method for track signal system software is characterized by comprising the following steps:
loading a test case;
analyzing the test case, acquiring an equipment identifier required to be started, and generating a step list to be executed, wherein the equipment identifier comprises a simulation test environment identifier and at least one subsystem software identifier;
starting related simulation test environment and subsystem software according to the equipment identifier, and creating a simulation test environment interface and a subsystem software interface;
according to the step list, testing operation is carried out through the simulation testing environment interface and/or the subsystem software interface, and a testing result is generated;
and generating a test report according to the test result.
2. The method of claim 1, further comprising:
and after all the testing steps in the step list are executed, closing the simulation testing environment and the subsystem software related to the testing case.
3. The method of claim 1, wherein generating test results from the step list and performing test operations via the simulation test environment interface and/or the subsystem software interface comprises:
sending an operation instruction to the simulation test environment interface according to the test steps in the step list, and acquiring a related feedback state variable from the subsystem software interface, and/or sending an operation instruction to the subsystem software interface, and acquiring a related feedback state variable from the simulation test environment interface;
and comparing the feedback state variable with the corresponding expected state variable, and generating a test result according to the comparison result.
4. The method of claim 1, further comprising, prior to said generating test results from said step list and by performing test operations in said simulation test environment interface and/or said subsystem software interface:
establishing an ZMQ connection with the simulation test environment;
and establishing telnet connection with the subsystem software.
5. The method of claim 1, prior to the loading test cases, further comprising:
setting keywords and controlling the testing steps by using the keywords;
and generating the test case for the carrier by applying XML according to the test step.
6. The method of claim 5, further comprising:
generating a template file according to at least one test step;
and applying XML as a carrier to configure the template file to the test case.
7. The method of claim 6, wherein the parsing the test case to generate a list of steps to be performed comprises:
acquiring a test step unit in the test case, and judging whether the test step unit is an expansion unit or not;
if the test step unit is an expansion unit, reading corresponding replacement parameter information, generating a replacement parameter table, and reading a corresponding template file;
and replacing parameter variables in the template file according to the replacement parameter table, and adding the test steps in the template file into the step list.
8. The method of claim 7, wherein after said determining whether said testing step element is an expansion element, further comprising:
if the test step unit is not an expansion unit, judging whether the test step unit is a separation prompt character unit, if so, storing a separation word string needing to be output, and adding the separation word string into the step list.
9. The method of claim 8, wherein after said determining whether said test step element is a split prompt character element, further comprising:
and if the test step unit is not the separation prompt character unit, storing the relevant information of the test step unit, and adding the test step corresponding to the test step unit to the step list.
10. A testing apparatus for track signaling system software, comprising:
the loading module is used for loading the test cases;
the analysis module is used for analyzing the test case, acquiring an equipment identifier required to be started and generating a step list to be executed, wherein the equipment identifier comprises a simulation test environment identifier and at least one subsystem software identifier;
the initialization module is used for starting related simulation test environment and subsystem software according to the equipment identifier and creating a simulation test environment interface and a subsystem software interface;
the test module is used for carrying out test operation through the simulation test environment interface and/or the subsystem software interface according to the step list to generate a test result;
and the generating module is used for generating a test report according to the test result.
11. The apparatus of claim 10, further comprising:
and the closing module is used for closing the simulation test environment and the subsystem software related to the test case after all the test steps in the step list are executed.
12. The apparatus of claim 10, wherein the test module is specifically configured to:
sending an operation instruction to the simulation test environment interface according to the test steps in the step list, and acquiring a related feedback state variable from the subsystem software interface, and/or sending an operation instruction to the subsystem software interface, and acquiring a related feedback state variable from the simulation test environment interface;
and comparing the feedback state variable with the corresponding expected state variable, and generating a test result according to the comparison result.
13. The apparatus of claim 10, wherein the initialization module is further configured to:
establishing an ZMQ connection with the simulation test environment;
and establishing telnet connection with the subsystem software.
14. The apparatus of claim 10, further comprising:
the case generation module is used for setting keywords and controlling the test steps by using the keywords;
and generating the test case for the carrier by applying XML according to the test step.
15. The apparatus of claim 14, wherein the case generation module is further to:
generating a template file according to at least one test step;
and applying XML as a carrier to configure the template file to the test case.
16. The apparatus of claim 15, wherein the parsing module is specifically configured to:
acquiring a test step unit in the test case, and judging whether the test step unit is an expansion unit or not;
if the test step unit is an expansion unit, reading corresponding replacement parameter information, generating a replacement parameter table, and reading a corresponding template file;
and replacing parameter variables in the template file according to the replacement parameter table, and adding the test steps in the template file into the step list.
17. The apparatus of claim 16, wherein the parsing module is further configured to:
if the test step unit is not an expansion unit, judging whether the test step unit is a separation prompt character unit, if so, storing a separation word string needing to be output, and adding the separation word string into the step list.
18. The apparatus of claim 17, wherein the parsing module is further configured to:
and if the test step unit is not the separation prompt character unit, storing the relevant information of the test step unit, and adding the test step corresponding to the test step unit to the step list.
19. An automatic test equipment comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing a method of testing the track signal system software according to any one of claims 1 to 9 when executing the computer program.
20. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out a method of testing track signal system software according to any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910553493.4A CN112131094A (en) | 2019-06-25 | 2019-06-25 | Method and device for testing track signal system software and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910553493.4A CN112131094A (en) | 2019-06-25 | 2019-06-25 | Method and device for testing track signal system software and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112131094A true CN112131094A (en) | 2020-12-25 |
Family
ID=73850045
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910553493.4A Pending CN112131094A (en) | 2019-06-25 | 2019-06-25 | Method and device for testing track signal system software and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112131094A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113268415A (en) * | 2021-05-11 | 2021-08-17 | 卡斯柯信号(成都)有限公司 | Interlocking rule automatic test system and method based on test case |
| CN115086209A (en) * | 2022-05-10 | 2022-09-20 | 浙江众合科技股份有限公司 | Signal system digital intelligent test method based on edge computing platform |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040267485A1 (en) * | 2003-06-30 | 2004-12-30 | Penov Francislav P | Test execution framework for automated software testing |
| CN101968770A (en) * | 2010-11-01 | 2011-02-09 | 北京航空航天大学 | Reusable embedded software testing and developing method and system |
| US20130042222A1 (en) * | 2011-08-08 | 2013-02-14 | Computer Associates Think, Inc. | Automating functionality test cases |
| CN103257925A (en) * | 2013-04-28 | 2013-08-21 | 株洲南车时代电气股份有限公司 | Automatic testing device, system and method for train operation monitoring record software |
| CN108108297A (en) * | 2016-11-25 | 2018-06-01 | 腾讯科技（深圳）有限公司 | The method and apparatus of automatic test |
-
2019
- 2019-06-25 CN CN201910553493.4A patent/CN112131094A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040267485A1 (en) * | 2003-06-30 | 2004-12-30 | Penov Francislav P | Test execution framework for automated software testing |
| CN101968770A (en) * | 2010-11-01 | 2011-02-09 | 北京航空航天大学 | Reusable embedded software testing and developing method and system |
| US20130042222A1 (en) * | 2011-08-08 | 2013-02-14 | Computer Associates Think, Inc. | Automating functionality test cases |
| CN103257925A (en) * | 2013-04-28 | 2013-08-21 | 株洲南车时代电气股份有限公司 | Automatic testing device, system and method for train operation monitoring record software |
| CN108108297A (en) * | 2016-11-25 | 2018-06-01 | 腾讯科技（深圳）有限公司 | The method and apparatus of automatic test |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113268415A (en) * | 2021-05-11 | 2021-08-17 | 卡斯柯信号(成都)有限公司 | Interlocking rule automatic test system and method based on test case |
| CN115086209A (en) * | 2022-05-10 | 2022-09-20 | 浙江众合科技股份有限公司 | Signal system digital intelligent test method based on edge computing platform |
| CN115086209B (en) * | 2022-05-10 | 2024-03-12 | 浙江众合科技股份有限公司 | Signal system digital intelligent test method based on edge computing platform |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109683899B (en) | Software integration method and device | |
| EP2245551B1 (en) | Identification of elements of currently-executing component script | |
| CN110765018B (en) | Automatic interface testing method and equipment | |
| US20130326486A1 (en) | Keyword based software testing system and method | |
| CN107463500B (en) | Debugging method, medium, system and computing device of test script | |
| CN110013672B (en) | Method, device, apparatus and computer-readable storage medium for automated testing of machine-run games | |
| RU2005110041A (en) | EFFECTIVE CORRECTION OF PROGRAMS | |
| US20020116153A1 (en) | Test automation framework | |
| CN110930131A (en) | Vehicle maintenance method, device, equipment and medium | |
| CN112131094A (en) | Method and device for testing track signal system software and storage medium | |
| CN111176910A (en) | System function testing method and device | |
| KR20200067474A (en) | Fault injection test method and system for vehicle software based on autosar | |
| CN114880220A (en) | Development system and method for vehicle automatic driving software | |
| CN112543478B (en) | WiFi module automatic test method and device, computer equipment and storage medium | |
| CN112596784B (en) | Iterative version deployment method and device | |
| CN112148599A (en) | Performance pressure measurement method, device and equipment | |
| KR101252358B1 (en) | Apparatus and method for testing plc command | |
| CN110659195A (en) | Android program crash positioning method, storage medium, electronic device and system | |
| US11958511B2 (en) | Train signal system and linkage method therefor | |
| CN113434387A (en) | Script-driven-based automatic testing tool and system | |
| CN113778460A (en) | Production environment deployment method and device | |
| CN115878448A (en) | Database test method, distributed database and storage medium | |
| CN115473832B (en) | Internet of vehicles end cloud communication testing method, device, server, client and system | |
| CN113890825B (en) | Interactive upgrade test method and device of equipment, storage medium and electronic equipment | |
| CN116932414B (en) | Method and equipment for generating interface test case and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |