Method for automatically creating a test script

Abstract

The invention relates to a computer-implemented method (10) for automatically creating at least one test script (12) for a traffic-specific computer programme of a traffic safety system, said method comprising the method steps of: a) providing traffic-specific route data (18), the route data (18) being subdivided into a plurality of complex route data sets (20; 20a, b); b) providing a keyword-driven test model (24), the test model (24) comprising: - a modelling reference (26) to test-relevant route data (36) in the traffic-specific route data (18); - a modelling instruction (28) for creating test instructions to the computer programme to be tested; c) extracting test-relevant route data (36) from a route data set (20; 20a, b) determined by means of the modelling reference (26); d) creating the test script (12) for at least one test scenario (40) depending on the extracted test-relevant route data (36) and the modelling instruction (28).

Description

[0001] Procedure for automatically creating a test script

[0002] Background of the invention

[0003] The invention relates to a computer-implemented method for automatically creating at least one test script for a traffic-specific computer program of a traffic safety system.

[0004] The traffic-safe design and planning of traffic route sections places high demands. In the area of ​​rail transport in particular, a centrally monitored and regulated traffic control system, namely a signal box or a trackside control system, must be provided to monitor the traffic system and its components. To ensure traffic-safe control, the traffic control system or signal box takes into account as much of the route information available in the traffic system it controls as possible. The route information is typically provided to the traffic control system in the form of digital route data or is stored as such in the traffic control system. A wide variety of route information, such as different route or track layouts and / or different traffic or field elements, such as (announcement) beacons in rail transport, may need to be taken into account.

[0005] To meet the high safety requirements, computers and software are used in the development of traffic control systems. These simulations support the testing of a large number of possible real-world and safety-relevant traffic scenarios. Such traffic scenarios can include, for example, a train passing through a section of track, a combination of multiple switch positions, a train registering with a Radio Block Center (RBC) of the European Train Control System (ETCS), or compliance with certain traffic regulations. Furthermore, a timetable system can be tested as a traffic scenario before real-life use, with specific trains scheduled to travel through or reach different sections of track at specific times.The simulation-based testing of traffic control can thus ensure the correct input of signals into the traffic control system and the correct output of signals by the traffic control system already in an early development phase of the traffic control system and / or a potential traffic safety system.

[0006] However, in order to conduct a simulation-based test, the actually planned and / or existing route information (route data) must be virtually mapped in conjunction with the possible real-world traffic scenarios. A single mapping of a single real-world traffic scenario on a single specific route section is typically done using a single test script. Within the test script, the traffic scenario to be tested is broken down into a series of sequential test steps. A test step can, for example, consist of the aforementioned train passing a specific signal on a specific route section. The test steps are run through step by step when the test script is executed, and the result of a test step is examined for any deviation from the expected result.To enable the safe development of traffic control, a large number of test scripts must typically be created, ideally mapping all possible or known real-world traffic scenarios on all specific route sections to be considered. This allows the safety and functionality of the route section controlled by the traffic control system, e.g., a railway station, to be optimally ensured.

[0007] However, the aforementioned individual test scripts are usually created manually in a specific programming language, resulting in considerable time and expense due to the large number of test scripts required for the traffic-safe design of a traffic-controlled road section. Furthermore, many of the manually created test scripts must be laboriously revised manually when changes are made to a traffic-related road section or higher-level regulations, further increasing the time and expense. The state of the art in such cases currently provides for the selection or prioritization of traffic scenarios. While such selection or prioritization of traffic scenarios can shorten development time, this only results in significant compromises in terms of safety aspects.

[0008] [1] provides a representative overview of keyword-driven testing approaches, highlighting recent developments. However, current testing approaches are unsuitable for application to the extensive and complexly structured route data, especially in rail transport, and cannot satisfactorily address the aforementioned challenges in the development of traffic safety systems.

[0009] An automated framework for the dynamic creation of test scripts for software testing is known from [2]. The framework is designed to create permutations from a combination of manually selected reference scripts and manually selected parameters. Therefore, the described framework cannot be applied to more complex data structures, which makes it particularly unsuitable for use in the conception and design of traffic safety systems in rail transport. Furthermore, the described framework uses a specific execution language and is thus dependent on the execution language of the target application executing the test scripts.

[0010] [3] describes a test automation framework for a computer system, comprising a scripting module for creating at least one script. The script defines test actions with respect to an identified and stored set of objects and a stored test data set. The described framework is designed for use in website testing, but is unsuitable for use with complex data structures.

[0011] [4] describes a system and method for creating and maintaining regression test scripts. A test script generator is configured to use key information from a graphical user interface identified by a recording device to create test scripts. Models are used as an internal exchange format to store scripts manually recorded during test execution. The method is geared toward capture and playback testing. The approach, and in particular the data processing, is applied to primitive data and is unsuitable for use with complex data structures.

[0012] A computer-implemented method and system for performing automated tests and retests is known from [5]. The method uses a test case generator to automatically generate a test program for a specific test case. However, the method described in [5] is also not suitable for creating test scripts based on complex data.

[0013] [6] describes a system and method for model-based testing of an industrial system, comprising modeling the functionality of an industrial system using a specific modeling language—here, UML (Unified Modeling Language). However, using a single specific modeling language prevents the method from being applied to systems with a different modeling language.

[0014] A method for creating test cases for safety-critical software in a train control system is known from [7]. Starting with a state diagram, the requirements of the train control system are first determined and mapped into a simplified sequence model. The correctness of the sequence model is ensured by simulation and model testing procedures. The creation of test scripts is not planned.

[0015] A framework for automated software testing of web applications is known from [8]. This framework is data-driven and unsuitable for use cases involving complex data.

[0016] An automated testing tool for software is known from [9]. However, this tool is also not suitable for use in the area of ​​complex traffic-specific data.

[0017] Object of the invention

[0018] It is an object of the invention to reduce the time and cost required for the safe development of traffic control and, at the same time, to maintain a high safety standard.

[0019] Description of the invention

[0020] This object is achieved according to the invention by a method having the features according to claim 1. The subclaims represent preferred embodiments of the invention.

[0021] According to the invention, a computer-implemented method is provided.

[0022] The computer-implemented method is designed or configured to automatically create at least one test script for a traffic-specific computer program of a traffic safety system.

[0023] A test script in the sense of the invention is to be understood as a list of commands that are executed by a target application, in particular a computer program or a "scripting machine." The test scripts are typically used to automatically execute many, particularly consecutive, individual actions on a computer. The test scripts created by the method can be designed for execution in semi-automated and / or fully automated test environments. In other words, the test script can be designed to input test signals to the computer program at predetermined interfaces of the computer program to be tested and also return the computer program's response to the test signal (fully automated). Furthermore, it can be provided that the test script interrupts the test of the computer program and awaits manual input from an operator (semi-automated).

[0024] The term "transport-specific" is understood above and below to mean an adaptation to a specific type of transport. Types of transport can include, for example, road transport, air transport, and / or water transport. Preferably, the term "transport-specific" is understood to mean an adaptation for use in rail transport, in particular rail transport.

[0025] The traffic safety system typically has one or more computers for executing a computer program, preferably an operating program. In other words, the functionality of the traffic safety system is based on a computer program. The traffic safety system also typically has an electronic system for regulating traffic within a traffic system. The traffic system can be understood as a closed number or as a network of directly or indirectly connected route sections, for example roads in road traffic, waterways in shipping traffic, airways in aviation traffic, or track sections in rail traffic. In other words, the traffic safety system monitors and regulates the traffic within a system it controls, for example motor vehicles in road traffic, ships in shipping traffic, aircraft in aviation traffic, and trains in rail traffic.For example, the functionality of a traffic safety system in rail traffic can be ensured by a signal box. The signal box can, for example, protect routes within the rail system controlled by the signal box. The traffic system is usually adjacent to other traffic systems.

[0026] The computer-implemented method according to the invention comprises at least the following method steps:

[0027] One method step involves providing traffic-specific route data. Route data, as previously described and in the following, refers to a collection of various route information. The individual route data items can differ in terms of their respective route data type. The route data type can, for example, be in the form of a numerical value, e.g., coordinates, and / or a designation. The route data is preferably provided, in particular stored, on a data carrier. Typically, the route data includes all operationally relevant route information. For example, in rail transport, the route data can consist of a list of all planned and / or existing field elements (balises, switches, signaling devices, etc.), the number and / or type of field elements, a number of different route sections, and / or topology data within the closed transport system.The list is not intended to be exhaustive.

[0028] According to the invention, the route data, or rather the collection of route information, is provided divided into a plurality of complex route data sets. In other words, the route data sets are designed as complex data types. Complex data types are understood above and below to mean a summary of several different route data. For example, route data about the route type, such as its function, and traffic elements associated with the route section, such as a start field element and a destination field element, can be assigned to the route. An individual route data set can contain further route data sets. By using complex route data sets, a central data management system can be accessed when creating the test script. This eliminates the need to provide and maintain an additional database with test-relevant route data.

[0029] A route section is understood above and below to be a section of the transport system defined by a predetermined starting point and a predetermined end point. The predetermined starting and end points are preferably determined using transport elements and / or topology data. In rail transport, a route section can be understood, for example, as any track section located between two axle counters. Typical route sections in rail transport include, for example, a specific track section in rail transport, a station area, open lines, a route block, an operating point (e.g., station, stopping point, stop, level crossing, junction, transfer point, etc.).

[0030] A traffic element is understood above and below to mean a sensor element, an actuator element and / or a signaling element that is used to monitor and control traffic. Typical traffic elements in rail transport are, for example, field elements, axle counters and / or switches. This list is not intended to be exhaustive. Topology data is understood above and below to mean the position and / or arrangement data of traffic elements. In a further method step, the invention provides for the provision of a data-driven test model. A test model is understood above and below to mean an abstract basic framework of a specific traffic scenario to be tested (test scenario / test case), which only achieves computer-related or test-case-related executability in combination with the corresponding route data.For example, a traffic scenario may involve a vehicle crossing a section of road at a predetermined speed, with the section of road only being defined by including the route data.

[0031] For example, a traffic scenario in rail transport may include a train scenario, whereby different train scenarios may differ in terms of train length, train type, carriage sequence, train formation, train division into through carriages, etc. This list is not exhaustive.

[0032] For example, a test scenario in rail transport may include a safety-relevant scenario, in particular a flank protection, a slip path, etc., a timetable scenario, a passenger transport scenario, a freight transport scenario, a single-wagon transport scenario, a train detection scenario, a spatial separation scenario, etc. This list is not intended to be exhaustive.

[0033] According to the invention, the test model has at least one modeling reference. The modeling reference refers to the test-relevant, traffic-specific route data that is included in the test scenario predetermined in the test model when creating the test script. In other words, the modeling reference refers to the route data to be included, through which the test scenario achieves computer-readable executability. The modeling reference can be multi-level. For example, the modeling reference first points to a relevant (higher-level) route data set and then to the route data or route data sets to be extracted from the route data set. For example, in rail transport, a reference can first be made to a specific route section and then to the start / destination field elements that define the route section.

[0034] The modeling reference is keyword-driven. This makes it particularly easy to reference the route data contained in the complex route datasets.

[0035] The term "keyword-driven" is understood above and below to mean a training in the use of abstract generic terms, whereby the reading of the concrete data is preceded by one or more sub-processes.

[0036] According to the invention, the test model further comprises at least one modeling instruction. The modeling instruction is provided for incorporating at least one test instruction. The test instruction is designed to instruct the computer program to be tested according to a test scenario of the test script. Preferably, the modeling instruction contains a plurality of test instructions to be included. The at least one test instruction can be different with respect to the respective test scenario. The test instruction can be contained in the test model. Furthermore, the modeling instruction can refer to test instructions provided outside the test model. In other words, the test instructions can be provided and / or managed externally, i.e., outside the test model. The test instruction can be accessed during the creation of the test script.For example, it can be provided that a train scenario provided in the test model, for example a train entry scenario into a station via various track sections and traffic elements, is read directly from the provided test instructions.

[0037] The test model preferably includes modeling constraints. Modeling constraints are typically provided in the test model as concrete data. Modeling constraints can, for example, provide initial conditions for the test scenario. For example, a modeling constraint can include the speed of a mode of transport at the beginning of the test scenario.

[0038] The test model can have multiple subsections. This allows for faster maintenance of the test model. Preferably, the test model has a first section containing the modeling reference, which refers to the test-relevant route data (pattern description for data that should be used). Furthermore, the test model preferably has a second section containing the modeling instruction, which refers to test instructions to be included for the test steps to be performed. Particularly preferably, the test model has a third section containing the modeling constraints, in which the respective test scenario is specifically defined.

[0039] A further method step according to the invention involves extracting test-relevant route data from a route dataset determined via the modeling reference. The extraction can be keyword-driven. Preferably, the extraction is performed using pattern recognition (pattern matching). Through data-type-independent functional programming, pattern recognition enables an automated search for patterns in the complex route datasets that match a pattern specified in the modeling reference. For example, a pattern can be in the form of a term or keyword.

[0040] In a subsequent method step, the test script is created for at least one test scenario based on the extracted test-relevant route data and the modeling instruction. In other words, a test script designed to test the traffic-specific computer program is created, which contains specific route data and specific test instructions for a specific test scenario. The route data and / or test instructions are assigned to the individual test steps of the test script on a test case-by-test basis. In summary, the invention thus enables the automated creation or generation of at least one test script from a large number of route data provided in complex route data sets. The route data is integrated into one or more corresponding test steps when creating the test script.In other words, when creating the test script, the modeling references to the route data specified in keywords are replaced with actual route data. The test script thus contains one or more test steps required for realistic testing of the traffic-specific computer program. This can significantly reduce the time and cost required for the traffic-safe design and testing of the traffic safety system. This particularly benefits test implementation during the test design process, maintenance, and use of the test scripts. The degree of automation and safety standards can be maintained.

[0041] In an exemplary, practical application of the method according to the invention, the design of a rail station can be presented below. Route data can initially be stored in the form of rail-specific or station-specific data. In particular, the route data can be provided by a data management system, or access to the data management system can be permitted during the creation of the test script. The station-specific data can, for example, include various light signals that are assigned, for example, to a complex route data set "signaling device 1." Furthermore, the "signaling device 1" can have further route data, for example, position information in a trackside coordinate system, in particular rail coordinates.The track data set "Signaling Device 1" can also be assigned to another track data set, for example, "Track 1." A test scenario can, for example, stipulate that a train enters the station at a predetermined speed and stops before the "Stop" signal. The automated creation of this test script can stipulate that a separate test script is created for each track section of the station and for each signaling device in order to ensure the safety-relevant stopping of the train at a stop signal under all conceivable train entry paths into the station.

[0042] In a preferred embodiment of the computer-implemented method, test-relevant route data is extracted from several determined route data sets in method step c). This is typically the case when the modeling reference refers to several route data sets, or when several route data sets are determined through the modeling reference, e.g., through pattern recognition (pattern matching). Method step d) is typically repeated for several, preferably each, determined route data set. In other words, different test scripts with different route data can be created starting from the same test model. For example, a first test script can be created for a first route, another test script for a second route, and an nth test script for an nth route.

[0043] An embodiment of the computer-implemented method is preferred in which the at least one modeling instruction is data-driven and / or keyword-driven. The term "data-driven" is understood above and below to refer to a design for incorporating concrete data, here test instructions. Data-driven incorporation simplifies the provision of the data to be included. Keyword-driven incorporation simplifies the maintenance or care of the data to be provided.

[0044] In a preferred embodiment of the computer-implemented method, the test model is derived from a test metamodel. A test metamodel is understood above and below to be an abstract framework for a plurality of test models to be created. Typically, the test metamodel has an undefined modeling reference and / or an undefined modeling instruction. By defining at least one modeling reference and / or at least one modeling instruction, at least one, in particular several, test models can be derived from the test metamodel. The test model is thus a derived instance of a test metamodel. The test metamodel comprises abstract design rules for the test models derived from it. This allows the test models to be maintained at a higher-level abstract level by the test metamodel, which can save further time and money.

[0045] Further preferred is an embodiment of the computer-implemented method in which the test model has a traffic-specific test modeling language, wherein the test script is created in a specific test environment language. A test modeling language is understood above and below to be a formulation adapted to the traffic system to be secured. The test modeling language is text-based and uses terms from the specific traffic system. For example, terms such as beacon, track section, field element, train, etc. are used for rail transport. This can simplify the application-specific handling of the test model. A test environment language is understood above and below to be a language used by a simulation environment executing the test script. The test modeling language can be the same as the test environment language.The test environment language is typically adaptable to the computer program under test.

[0046] Furthermore, the test modeling language can be data-independent. This allows the modeling language to be applied to any different traffic-specific route data. This enables the application of test models independently of the project and increases the possibility of reusing the test model. Instead of manually implementing a data-dependent test script for each project, only a data-independent test model is used together with project-specific data to generate executable test scripts. Furthermore, an embodiment of the computer-implemented method is preferred in which the specific test environment language differs from the test modeling language. A test script can thus be created in any test environment language, regardless of the test modeling language used. This makes it particularly easy to use the test models and route data in other test environments.In other words, the maintenance and handling of the test model or the creation of the test script can be done in the traffic-specific language, while the execution of the test script takes place in a different language. This allows the test script to be created and applied without special knowledge of the test environment language.

[0047] For example, the test environment language of the traffic-specific test model can be adapted to a test execution environment for semi-automated test execution, for example SimBa (Simulation based / TUS).

[0048] The test environment language can be machine-readable and / or human-readable. The implementation of the method preferably includes corresponding "exporters" for this purpose, which generate the created test script for application-specific test environments. The test script can be provided as machine-readable and / or human-readable output. For example, it can be provided that the created test script is provided as machine-readable output for the "SimBa" and / or "TUS" test environment. Furthermore, it can be provided that a human-readable output is generated as a means of communication for validating the test execution and the test results.

[0049] In a preferred embodiment of the computer-implemented method, the test script is created using a test script generator. The test script generator is preferably independent of the specific syntax of the test modeling language and the route data. Special so-called "importers" can be used to convert inputs to the test script generator into an internal format of the test script generator, which is then used to create the test script. This facilitates the automatic creation of test scripts, as the test script generator can be kept independent of external influences or code changes.

[0050] Further preferred is an embodiment of the computer-implemented method in which railway-specific route data and a railway-specific modeling language are used. This allows the design and development of traffic safety systems in rail transport, in particular signal boxes, to be accelerated and modeled more cost-effectively.

[0051] Further advantages of the invention will become apparent from the description and the drawings. Likewise, the above-mentioned and further-described features can be used individually or in combination in any desired manner. The embodiments shown and described are not intended to be exhaustive, but rather are exemplary in nature for describing the invention.

[0052] Detailed description of the invention and drawing

[0053] Fig. 1 shows a schematic representation of a sequence of a computer-implemented method according to the invention for the automated creation of a test script.

[0054] Fig. 2 shows a further schematic representation of the computer-implemented method from Fig. 1.

[0055] Fig. 3 shows a schematic representation of various components of a rail transport system through which route data is provided.

[0056] Fig. 4a schematically shows a test scenario executed by a test script for a train entering a station in an initial state. Fig. 4b schematically shows the test scenario from Fig. 4b with a train entering the station in a final state.

[0057] The method 10 is explained below with reference to the following figures of the drawing, wherein the explanation refers by way of example to a concrete application case of the design of a traffic safety system (not shown) in rail transport.

[0058] Fig. 1 and Fig. 2 show schematic representations of the computer-implemented method 10 according to the invention.

[0059] The method 10 is designed to automatically create at least one test script 12. Preferably, the method 10 automatically creates several test scripts 12.

[0060] The at least one test script 12 created in the method 10 is designed to test a traffic-specific computer program of the traffic safety system. In other words, the method 10 automatically creates test scripts 12 that can ensure proper functioning and control of the computer program of the traffic safety system.

[0061] For this purpose, traffic-specific route data 18 are provided in a method step 16. The traffic-specific route data 18 are typically divided into a plurality of complex route data sets 20.

[0062] A further method step 22 provides for the provision of a test model 24. The test model 24 has at least one keyword-driven modeling reference 26 to test-relevant traffic-specific route data 36.

[0063] The test model 24 also has at least one modeling instruction 28 for incorporating test instructions 30. The test instructions 30 contain instructions from the test script 12 to be created to the computer program to be tested. Each test instruction 30 preferably forms a separate test step of the test script 12. The test instructions 30 can, as shown in Fig. 3, be stored in the test model 24. Furthermore, the test instructions 30 can also be provided outside the test model 24, for example, on a computer-readable storage medium (not shown). In this case, the modeling instruction 28 can be data-driven. Alternatively or additionally, the test instructions 30 can be provided in one or more complex data structures. In this case, the modeling instruction 28 is preferably keyword-driven.

[0064] The test model may also include modeling constraints 32. Typically, the modeling constraints 32 are provided as concrete or primitive data in the test model 24.

[0065] A further method step 34 provides for the extraction of test-relevant route data 36 from a route data set 20 of the route data 18 determined via the modeling reference 26. The extraction of the test-relevant route data 36 is preferably carried out by pattern recognition (pattern matching), wherein the modeling reference 26 has a search pattern that is compared with a data pattern of the route data sets 20 and / or the route data 18.

[0066] A subsequent method step 38 of the computer-implemented method 10 provides for the creation of the test script 12 for at least one test scenario 40 (see Fig. 3) depending on the extracted test-relevant route data 36 and the modeling instruction 28. Furthermore, modeling constraints 32 can be taken into account when creating the test script 12 or the test scenario 40.

[0067] When creating the test script 12 or the test scenario 40, the test-relevant route data 36 and the test instructions 30 are integrated into a test sequence of the test script 12 for the test scenario 40 according to the modeling instruction 28. In other words, the test-relevant route data 36 and the test instructions 30 are transferred in the corresponding test step of the test script 12.

[0068] The test script 12 is preferably created by a test script generator 42. Particularly preferably, the pattern matching is also performed by the test script generator 42.

[0069] Fig. 3 shows a section of a rail transport system 43 in a schematic representation with several components. Route data 18 (see Fig. 2) is provided for each component. In the case shown, the route data 18 is thus rail transport-specific or station-specific route data 18. As shown, the route data 18 can relate to a station 44 that is located between a first track 46 and a second track 48. In addition, the first and second tracks 46, 48 are connected to a first track section 54 and a second track section 56 via switches 50, 52. The tracks 46, 48 and the track sections 54, 56 each have axle counters 58a-f, which can, for example, ensure that the corresponding track 46, 48 or track section 54, 56 is clear.In other words, the route data 18 concerns not only station 44 but also tracks 46, 48 and track sections 54, 56 as well as several traffic elements.

[0070] According to Fig. 3, the first track 46 and the axle counters 58e, 58f are assigned to a first route data set 20a, and the second track 48 and the axle counters 58b, 58c are assigned to a second route data set 20b. The route data sets 20a, 20b thus each relate to at least one track 46, 48 or one route section, as well as two traffic elements.

[0071] The route data 18 can include designations, status information, states, and / or topology data for the station 44, the first and second tracks 46, 48, the route sections 54, 56, and the traffic elements. In other words, the aforementioned components can be embodied as complex route data sets 20, 20a, 20b.

[0072] The route data 18 can be provided for creating a test script 12 according to the method 10 (Figs. 1, 2).

[0073] For example, a test model 24 provided according to the method 10 may provide that at least one test scenario 40 (see Fig. 2) is created in at least one test script 12 for the route data 18.

[0074] Figs. 4a and 4b schematically show an exemplary test scenario 40, here in the form of a train 60 entering the station 44.

[0075] In the exemplary test scenario 40 shown, the test model 24 can have the keyword "track" as a modeling reference 26 (see Fig. 2). During test script creation, the keyword "track" is compared with the route data 18 (see Fig. 2) according to method 10 (see Fig. 1). In the present case, the comparison of the keyword "track" results in two matches in the route data 18, namely the first track 46 and the second track 48. Subsequently, at least one test script 12 can be created with a train entry scenario of the train 60 onto the first track 46. Preferably, test scripts 12 are created for all possible train entry scenarios of the train 60.

[0076] Fig. 4a shows the test scenario 40 in an initial state according to the train entry scenario of the train 60 onto the first track 46 according to a first test step of the test script 12. As shown, the train 60 is located at the axle counter 58a. The initial position of the train 60 can, for example, be derived from the modeling boundary conditions 32 of the test model 24 during the creation of the test script 12.

[0077] In the first test step shown, it can be provided that the axle counter 58a reports a track blockage to the traffic safety system. This allows a safety-relevant reaction of the computer program to the message from the axle counter 58a to be checked. For example, the computer program can cause the tracks 46, 48 to be blocked for further trains 60 in response to the message from the axle counter 58a.

[0078] Further test steps of test script 12 may, for example, involve a step-by-step crossing of switch 50 and / or axle counter 58e. For each test step, a check of the safety-relevant response of the traffic safety system's computer program can be ensured.

[0079] Fig. 4b shows the test scenario 40 described in Fig. 4a in a possible final test step. The train 60 is located between the axle counters 58e and 58f in a stopping position at the station 44. The test step can provide that the axle counter 58e reports to the traffic safety system when the train 60 completely crosses the axle counter 58e. Furthermore, no report may be sent from the axle counter 58f to the traffic safety system. In this case, a response of the traffic safety system's computer program to be checked could, for example, be the release of the second track 48.

[0080] List of reference symbols

[0081] 10 procedures;

[0082] 12 test script;

[0083] 16 process steps;

[0084] 18 route data;

[0085] 20, 20a, b track data set;

[0086] 22 process step;

[0087] 24 test model;

[0088] 26 Modeling reference;

[0089] 28 Modeling instructions;

[0090] 30 Test instructions;

[0091] 32 modeling boundary conditions;

[0092] 34 process steps;

[0093] 36 test-relevant route data;

[0094] 38 process steps;

[0095] 40 test scenarios;

[0096] 42 test script generator;

[0097] 43 rail transport system;

[0098] 44 train station;

[0099] 46 first track;

[0100] 48 second track;

[0101] 50, 52 switch;

[0102] 54 erster Streckenabschnitt;

[0103] 56 zweiter Streckenabschnitt;

[0104] 58a-f Achszähler;

[0105] 60 Zug. Literaturliste

[0106] [1] „On the Evolution of Keyword- Driven Test Suites", Rwemalika et al.

[0107] [2] EP 2 605 141 Al; Automated framework for dynamically creating test scripts for software testing". [3] US 10,565,095 B2; Hybrid testing automation engine.

[0108] [4] IN 367205; A system and method for generating and maintaining regression test scripts.

[0109] [5] US 8,826,084 Bl; Method and system for implementing automated test and retest procedures. [6] US 8,443,336 B2; System and method for applying model-based testing to train control systems.

[0110] [7] CN 106814730 B; Train operation control system safety critical software test case generating method.

[0111] [8] Selenium https: / / de.wikipedia.org / wiki / Selenium

[0112] [9] FitNesse https: / / en.wikipedia.org / wiki / FitNesse

Claims

Patent claims Computer-implemented method (10) for automatically creating at least one test script (12) for a traffic-specific computer program of a traffic safety system; comprising the method steps: a) providing (16) traffic-specific route data (18), wherein the route data (18) are divided into a plurality of complex route data sets (20; 20a, b); b) providing (22) a test model (24), wherein the test model (24) comprises: • a keyword-driven modeling reference (26) to test-relevant route data (36) in the traffic-specific route data (18); • a modeling instruction (28) for creating test instructions (30) for the computer program to be tested; c) extracting (34) test-relevant route data (36) from a route data set (20; 20a, b) determined via the modeling reference (26); d) creating (38) the test script (12) for at least one test scenario (40) as a function of the extracted test-relevant route data (36) and the modeling instruction (28). The computer-implemented method (10) according to claim 1, wherein in method step c), a plurality of test-relevant route data (36) are extracted from a plurality of determined route data sets (20; 20a, b) using the same modeling reference (26), wherein method step d) is repeated for a plurality of, preferably each, determined route data set (20; 20a, b).

3. Computer-implemented method (10) according to claim 1 or 2, wherein the at least one modeling instruction (26) is data-driven and / or keyword-driven.

4. Computer-implemented method (10) according to one of the preceding claims, wherein the test model (24) is derived from a test metamodel.

5. Computer-implemented method (10) according to one of the preceding claims, wherein the test model (24) comprises a traffic-specific test modeling language, wherein the test script (12) is created in a specific test environment language.

6. The computer-implemented method (10) of claim 5, wherein the specific test environment language differs from the test modeling language.

7. Computer-implemented method (10) according to one of the preceding claims, wherein the test script (12) is created by means of a test script generator (42).

8. Computer-implemented method (10) according to one of the preceding claims, wherein railway-specific route data (18) and a railway-specific modeling language are used.

Images