Route search device and route search method

The path search device efficiently verifies application display screen transitions by using nodes and unidirectional links to find the shortest paths, reducing test time and cost.

JP2026114268APending Publication Date: 2026-07-08PANASONIC AUTOMOTIVE SYST CO LTD

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
PANASONIC AUTOMOTIVE SYST CO LTD
Filing Date
2024-12-26
Publication Date
2026-07-08

Smart Images

  • Figure 2026114268000001_ABST
    Figure 2026114268000001_ABST
Patent Text Reader

Abstract

The present invention provides a route search device and route search method that search for the shortest route passing through all specified waypoints. [Solution] In the operational verification process during the development of an application program installed on the equipment under test 100, the test execution system for performing screen transition tests comprises an automatic test design device 11, an automatic test execution device 12, and a test database (DB) 13. The automatic test design device 11 creates and outputs test specification data 22 based on specification data 21 which includes specification data 21A corresponding to the predetermined specifications of the equipment under test 100 and transition test condition setting data (file) 21B set in advance by the operator.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0006] , , ,

[0001] The present invention relates to a route search device and a route search method.

Background Art

[0002] Conventionally, in network construction, a route search method for setting a route passing through a plurality of areas has been proposed.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Similar to the above route search method, when verifying a created application program, it is desired to be able to search for a transition route for verifying whether the transition of the display screen of the application when a predetermined operation is performed is in a desired transition state.

[0005] In view of the above problems, an object of the present invention is to provide a route search device and a route search method capable of searching for a transition route for verifying whether the transition of the display screen of an application when a predetermined operation is performed is in a desired transition state when verifying a created application program.

Means for Solving the Problems

[0006] The path search device of the embodiment is represented by nodes corresponding to waypoints and unidirectional links corresponding to the direction of travel, and all of the nodes are represented by unidirectional links leading to predetermined basic waypoints, and the path search device searches for the shortest path passing through all specified waypoints, and comprises a node extraction unit that extracts two of the nodes connected by a single unidirectional link that are the subject of the test from the path, and a path generation unit that sequentially performs the process of connecting the node on the terminal side of the unidirectional link of the extracted two nodes connected by the unidirectional link as a new starting node, and the starting node of the other two nodes connected by the unidirectional link that has been extracted as a new terminal node, and connecting the new starting node and the new terminal node with a new unidirectional link that corresponds to the shortest path between them, for all the extracted two nodes connected by the unidirectional links to connect them to form the path of the search result. [Effects of the Invention]

[0007] According to the path search device of this disclosure, when verifying a created application program, it is possible to search for a transition path to verify whether the transition path of the application's display screen when a predetermined operation is performed is in a desired transition path state. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is a block diagram illustrating the schematic configuration of a test execution system with a pathfinding function according to an embodiment. [Figure 2] Figure 2 is a functional block diagram of the automated test execution device and the equipment under test. [Figure 3] Figure 3 is a transition diagram showing an example of the display screen transitions of the device under test. [Figure 4] Figure 4 is an explanatory diagram illustrating an example of a condition corresponding to the condition setting data. [Figure 5] Figure 5 is a transition diagram corresponding to the transition conditions "EU-bound" AND "WiFi on". [Figure 6]Figure 6 is a transition diagram corresponding to the transition condition "Android Auto enabled" if AND "WiFi off" AND "Android Auto enabled" are true. [Figure 7] Figure 7 is a processing flowchart of the embodiment. [Figure 8] Figure 8 is a flowchart of the route generation process. [Figure 9] Figure 9 is a schematic representation of the transition diagram corresponding to Figure 5, including the pre-initialization stage. [Figure 10] Figure 10 shows the state in Figure 9, where the transition to be tested has been identified. [Figure 11] Figure 11 is an explanatory diagram (part 1) for a bipartite graph. [Figure 12] Figure 12 is an explanatory diagram (part 2) for a bipartite graph. [Figure 13] Figure 13 is an explanatory diagram (part 3) for bipartite graphs. [Figure 14] Figure 14 is an explanatory diagram of an example of a shortest distance table. [Figure 15] Figure 15 illustrates the minimum-weighted maximum matching based on the shortest distance table. [Figure 16] Figure 16 is an explanatory diagram of the shortest path. [Figure 17] Figure 17 is an explanatory diagram of the shortest path in the transition test. [Figure 18] Figure 18 is an explanatory diagram illustrating a specific example of a situation where rewiring is necessary. [Figure 19] Figure 19 is an explanatory diagram illustrating a specific example of rewiring. [Figure 20] Figure 20 is an explanatory diagram illustrating the transitions between display screens and the display screens themselves as the subject of the test. [Figure 21] Figure 21 is an explanatory diagram for adding a virtual unidirectional link to the display screen you want to test. [Figure 22] Figure 22 is an explanatory diagram (part 1) of the bipartite graph when a virtual unidirectional link is added. [Figure 23]FIG. 23 is an explanatory diagram (part 2) of a bipartite graph when a virtual unidirectional link is added. [Figure 24] FIG. 24 is an explanatory diagram of the result of connecting paths. [Figure 25] FIG. 25 is a diagram arranging the obtained shortest paths in the order of passage. [Figure 26] FIG. 26 is an explanatory diagram of the shortest path in a transition test. [Figure 27] FIG. 27 is a flowchart of the outline processing of the test execution system.

Mode for Carrying Out the Invention

[0009] In each of the following embodiments, a control method of the test execution system 10 of the present disclosure will be described with reference to the drawings. However, each of the following embodiments is only a part of various embodiments of the present disclosure. Each of the following embodiments can be variously modified according to design and the like as long as the object of the present disclosure can be achieved. Also, each of the following embodiments may be realized in appropriate combination including modification examples.

[0010] In addition, each of the figures described in the following embodiments is a schematic diagram, and the ratio of the size and thickness of each component in the figure does not necessarily reflect the actual dimensional ratio.

[0011] FIG. 1 is a schematic configuration block diagram of a test execution system having a path search function according to an embodiment. The test execution system 10 performs a screen transition test in an operation confirmation process during the development of an application program installed in a test target device (for example, an in-vehicle navigation device) 100.

[0012] Here, the screen transition test is a test for verifying that the screen transition is correctly programmed by actually executing the transition of the display screen during the desired operation of the test target device 100. For this reason, when performing a screen transition test, it is necessary to plan a transition path of the display screen in order to shorten the test time and thus reduce the test cost.

[0013] In planning the transition path, the following assumptions are made in the following embodiments. (1) You can return to a specific home screen from any of the display screens. (2) Some screen transitions have conditions set for them to occur, and if these conditions are not met, the transition will not be possible. (3) Even if the transitions are between the same display screens, if the conditions shown in (2) are different, they shall be treated as separate screen transitions and each shall be treated as a screen transition subject to testing. Therefore, in such cases, it shall be necessary to go through each transition path.

[0014] Furthermore, when planning the transition path, the shortest transition path should be designed to pass through all the transition paths designated as test subjects, while satisfying the above prerequisites. In this case, the shortest path will be planned while allowing the same transition path to be traversed multiple times.

[0015] The test execution system 10 is broadly comprised of an automated test design device 11, an automated test execution device 12, and a test database (DB) 13. The automated test design device 11 automatically creates test specification data corresponding to the screen transition test to be performed on the equipment under test 100.

[0016] More specifically, the automated test design device 11 creates and outputs test specification data 22 based on specification data 21, which includes specification data 21A corresponding to the predetermined specifications of the equipment to be tested 100 and transition test condition setting data (file) 21B set in advance by the operator.

[0017] The automated test execution device 12 reads the test specification data 22 created by the automated test design device 14, performs screen transition tests based on the test specification data 22, and outputs test execution result data 23. As a result, the test database 13 records the test specification data 22 and the test execution result data 23 in association.

[0018] Figure 2 is a functional block diagram of the automated test execution device and the equipment under test. The automated test execution device 12 is broadly comprised of a database (DB) reading unit 31, an execution planning unit 32, a determination unit 33, and a recording unit 34.

[0019] The database reading unit 31 reads the test specification data 22 from the test database 13. The execution planning unit 32 controls the operation of the equipment under test based on the loaded test specification data.

[0020] The determination unit 33 receives the operation execution result, which is the result of the operation control of the test equipment, and determines whether the desired screen transition has occurred, and outputs the determination result to the recording unit 34.

[0021] The example given is when the test device 100 is configured as an in-vehicle navigation system. The device under test 100 comprises an operation execution unit 101 and a power supply unit 102.

[0022] The operation execution unit 101 receives power from the power supply unit 102 and performs various operations based on hard key operations, touch panel operations (on-screen operations), peripheral device operations, and vehicle signals on the equipment under test 100, and outputs the operation execution results to the determination unit 33 of the automatic test execution device 12.

[0023] Figure 3 is a transition diagram showing an example of the display screen transitions of the device under test. Here, we will explain using the example of a vehicle navigation system as the test subject device 100. The display screen of the in-vehicle navigation device 100, which is the device under test, has a home screen GH, and the display screen to which it transitions from the home screen GH is configured to differ based on patterns according to the specifications and operating status.

[0024] Specifically, in the example shown in Figure 3, if the in-vehicle navigation system is an EU-spec model and Wi-Fi is enabled, the system transitions from the home screen GH to the display screen Ga for display. Furthermore, after transitioning to display screen Ga, if a WiFi connection is established, the display screen will transition to display screen Gb. Depending on the operating status, the display screen Gb will transition to the display screen Gc.

[0025] Furthermore, if the in-car navigation system is an EU-spec model and Wi-Fi is turned off, the system will transition from the home screen GH to the display screen Gc. When the display state of screen Gc is set to "WiFi connected," the system will then transition to display screen Gd. Furthermore, if Android Auto is supported while the display screen Gc is in its display state, the system will transition to the display screen Ge. Furthermore, if the in-car navigation system is a domestic model, has Wi-Fi enabled, and is already connected to Wi-Fi, the system will transition from the home screen GH to the display screen Gd. The display screen Gd transitions to the display screen Ge.

[0026] If Android Auto is supported, the display screen Gd will be accessed from the Ge screen. Furthermore, if WiFi is turned off on display screen Ge, the system transitions to display screen Gf, and then, if certain conditions are met, it transitions to display screen Gg.

[0027] Although not shown in the diagram, there are paths that allow transitions from all display screens Ga to Gg to the home screen GH. For example, direct transitions to the home screen GH are possible from any of the display screens Ga to Gg by operating the home button on the hardware control keys or the home button on the touch panel.

[0028] Here, we will describe an example of conditions corresponding to the transition test condition setting data 21B. Figure 4 is an explanatory diagram illustrating an example of a condition corresponding to the condition setting data. The first pattern assumes that the device under test is EU-spec, has Wi-Fi enabled, and is already connected to Wi-Fi.

[0029] On the other hand, the second pattern involves testing a device that is EU-spec, but has Wi-Fi turned off and is compatible with Android Auto. The conditions for the transition test, as described in Pattern 1 and Pattern 2, cannot be satisfied simultaneously, and these transition tests must be performed separately.

[0030] Therefore, when the automated test design device 11 creates test specification data 22 based on the specification data 21, which includes specification data 21A and transition test condition setting data (file) 21B, it creates the test specification data 22 by dividing it into patterns.

[0031] Here, we will explain an example of how to determine whether each transition belongs to a transition test pattern when creating the test specification data 22. The control program of the automated test design device 11 determines whether each transition belongs to a transition test pattern by determining whether the proposition "If the pattern condition expression is true, then the transition condition expression is also true" always holds true. Here, the control program functions as a SAT solver to search for a solution to the satisfiability problem.

[0032] First, let's explain using the transition conditions "EU-bound" AND "WiFi on" as an example. If the first pattern condition expression shown in Figure 4, "EU destination" AND "WiFi on" AND "WiFi connected", is true, then the transition condition "EU destination" AND "WiFi on" will always be true.

[0033] On the other hand, even if the second pattern condition expression shown in Figure 4, "EU-bound" AND "WiFi off" AND "Android Auto compatible," is true, the transition condition "EU-bound" AND "WiFi on" is always false because it is not "WiFi off." Therefore, the transition conditions "EU-bound" AND "WiFi on" are determined by the control program of the automated test design device 11 to belong only to the first pattern.

[0034] Next, we will explain using the transition condition "Android Auto compatible" as an example. Even if the first pattern condition shown in Figure 4, "EU-oriented" AND "WiFi on" AND "WiFi connected," is true, the transition condition "Android Auto compatible" is not necessarily true.

[0035] On the other hand, if the second pattern of conditions shown in Figure 4, "EU-oriented" AND "WiFi off" AND "Android Auto compatible," is true, then the transition condition "Android Auto compatible" will always be true. Therefore, the transition condition "Android Auto compatible" is determined by the control program of the automated test design device 11 to belong only to the second pattern.

[0036] Therefore, when the automated test design device 11 creates the test specification data 22, it extracts only the transition screens reachable from the home screen GH, based on the transition conditions of the device under test. For example, it uses only the transition conditions from the transition pattern of the display screen transition diagram of the device under test shown in Figure 3, and creates a new transition diagram. Figure 5 is a transition diagram corresponding to the transition conditions "EU-bound" AND "WiFi on". For example, using only the transition conditions "EU destination" AND "WiFi on", the transition screens reachable from the home screen GH are the display screens Ga to Ge, as shown in Figure 5.

[0037] Figure 6 is a transition diagram corresponding to the transition condition "Android Auto enabled" if AND "WiFi off" AND "Android Auto enabled" are true. Similarly, using only the transition condition "Android Auto compatible," the transition screens reachable from the home screen GH are the display screens Gc to Gf, as shown in Figure 5.

[0038] Next, the operation of the embodiment will be described. Figure 7 is a processing flowchart of the embodiment. The designer creates a transition pattern as shown in Figure 3 (Step S11) based on pre-configured transition specification data such as the source or destination screen and conditions, and pre-configured screen specification data such as the layout and display conditions of display components.

[0039] Next, the designer creates an initialization procedure for the created transition pattern, which is a series of operations necessary to satisfy the conditions (step S12).

[0040] Based on these, the automated test design device 11 uses a SAT solver to extract patterns that do not create logical contradictions with respect to the transition conditions corresponding to the created transition patterns, determines combinations of the extracted patterns (corresponding to the transition diagrams shown in Figures 5 and 6, respectively), and constructs a graph corresponding to the transition diagram for each combination (step S13). Next, the automated test design device 11 functions as a path generation unit that performs path generation processing to generate the shortest path, and generates the shortest path for each graph corresponding to the constructed transition diagram (step S14). The automated test design device 11 then creates and outputs the test specification data 22. As a result, the automated test execution device 12 reads the test specification data 22 created by the automated test design device 11 and executes a screen transition test based on the test specification data 22.

[0041] Here, we will explain in detail the path generation process (step S14) that generates the shortest path as described above. Figure 8 is a flowchart of the route generation process. First, the automated test design device 11 functions as a data generation unit and creates a shortest distance table and a route table using the Floyd-Warshall algorithm (step S21).

[0042] The starting point of a transition (the display screen corresponding to the pre-initialization state or the starting node) and the ending point of a transition (the display screen corresponding to the ending node) that must be traversed are extracted, and a bipartite graph is created based on the direction of the transition (step S22).

[0043] First, let's explain how to extract the start and end points of a transition. Figure 9 is a schematic representation of the transition diagram corresponding to Figure 5, including the pre-initialization stage. In Figure 9, if we consider the pre-initialization screen PI, the home screen GH, and the display screens Ga~Ge as nodes, the transition directions can be considered as unidirectional links LPH, LHa, LHc, LHd, Lab, Lbc, Lbe, LCD, and Lde.

[0044] As shown in Figure 9, the first pattern is a transition diagram that shows the transition from the pre-initialization screen PI to the home screen GH, and then to the display screens Ga to Ge depending on the operation state and device status.

[0045] Figure 10 shows the state in Figure 9, where the transition to be tested has been identified. In the example shown in Figure 9, for example, the transitions to be tested are five types, as shown by the dashed arrows in Figure 10: pre-initialization state → home display screen GH, display screen Ga → display screen Gb, display screen Gb → display screen Gc, display screen Gb → display screen Ge, and display screen Gd → display screen Ge, corresponding to the unidirectional links LPH, Lab, Lbc, Lbe, and Lde.

[0046] Therefore, in the example shown in Figure 10, the starting points of the transitions that must be traversed are the pre-initialization state PI, display screen Ga, display screen Gb, and display screen Gd. Furthermore, the endpoints of the transitions that must be traversed are display screen Gb, display screen Gc, and display screen Ge.

[0047] Figure 11 is an explanatory diagram (part 1) for a bipartite graph. Next, as shown in the right-hand diagram of Figure 11, the starting and ending points of the transitions are connected by unidirectional links, and then arranged in order so that the unidirectional links do not intersect. Next, the starting point of the transition (the display screen corresponding to the pre-initialization state or the starting node) is defined as the first independent set SI1, and the ending point of the transition (the display screen corresponding to the ending node) is defined as the second independent set SI2.

[0048] Figure 12 is an explanatory diagram (part 2) for a bipartite graph. Next, as shown in Figure 12, the unidirectional links LPH, Lab, Lbc, Lbe, Lde, and Lbe shown in Figure 11 are temporarily ignored. Furthermore, the pre-initialization state PI is only passed through once, so it is excluded from the starting point and processed accordingly.

[0049] Figure 13 is an explanatory diagram (part 3) for bipartite graphs. In the state shown in Figure 12, excluding the pre-initialization state PI, all transitions belonging to the first independent set SI1 and the transitions belonging to the second independent set are linked, as shown in Figure 13. Next, the shortest distance table is referenced, weights are applied to the created bipartite graph, and the minimum-weight maximum-matching problem is solved to select the shortest distance link between each point (each display screen) from all the links shown in Figure 13 (step S23).

[0050] Figure 14 is an explanatory diagram of an example of a shortest distance table. In Figure 14, each row corresponds to the starting point of the transition, and each column corresponds to the ending point of the transition. The shortest distance table shows the distance as the number of unidirectional links traversed from the starting point to the ending point. For example, when traveling from the home screen GH to the display screen Gb, if it is necessary to traverse two unidirectional links in the shortest possible time, the distance is calculated as 2.

[0051] Furthermore, since there are no transitionable points in the pre-initialization state, the distance is shown as infinite (inf). Also, the unidirectional links from each display screen Ga, Gb, Gc, Gd, and Ge to the home screen GH are given a distance of 1.

[0052] In the shortest distance table, as shown in the second column from the top, if the home screen GH is the starting point of the transition, then to reach the display screen Ga, which is the end point of the transition, by following the unidirectional links from the home screen GH, only one unidirectional link needs to be followed, so the shortest distance = 1.

[0053] Furthermore, to transition from display screen Ge to display screen Gb, it is necessary to transition from home screen GH → display screen Ga → display screen Gb, so three unidirectional links are needed, resulting in a shortest distance of 3.

[0054] In this way, one of the unidirectional links connecting the endpoint of each transition to the starting point of the transition, which has the shortest distance, is selected for each endpoint of the transition.

[0055] Figure 15 illustrates the minimum-weighted maximum matching based on the shortest distance table. In Figure 15, the numbers above or below the selected unidirectional links, indicated by thick lines, represent the shortest distance. As shown in Figure 15, the shortest distance of the unidirectional link LHa transitioning from the home display screen HG to the display screen Ga is 1.

[0056] Furthermore, the shortest distance to transition from display screen Gb back to display screen Gb is 0, since no transition occurs on display screen Gb. Furthermore, the shortest distance for the unidirectional link LCD transitioning from display screen Gc to display screen Gd is 1, according to the shortest distance table.

[0057] Furthermore, the shortest distance for the unidirectional link Leb transitioning from display screen Ge to display screen Gb is 3, according to the shortest distance table.

[0058] Figure 16 is an explanatory diagram of the shortest path. Next, the automated test design device 11 converts the obtained minimum weight maximum matching solution result into a pass order (step S24).

[0059] Next, the automated test design device 11 converts the sequence into a passage order and determines whether or not the passage order includes dead ends (step S25). If, as a result of the determination in step S25, the sequence of passage does not include any dead ends (step S25; No), the shortest path is calculated by referring to the obtained path table and connecting the start and end points of the transition (step S26). Then, the paths are linked according to the order of passage to obtain the test order (step S27).

[0060] Specifically, by superimposing the unidirectional links LPH, Lab, Lbc, Lde, and Lbe corresponding to the original transitions shown in the right diagram of Figure 11, the shortest path represented by unidirectional link LPH → unidirectional link LHa → unidirectional link Lab → unidirectional link Lbb → unidirectional link Lbc → unidirectional link Lcd → unidirectional link Lde → unidirectional link Leb → unidirectional link Lbe is obtained, as shown in Figure 16.

[0061] Figure 17 is an explanatory diagram of the shortest path in the transition test. As shown in Figure 17, the automated test design device 11 can complete the transition tests of the display screens of all the test target devices 100 shown in Figure 10 in a shorter time by having the automated test execution device 12 perform the tests in the order of route R1 → route R2 → route R3 → route R4 → route R5.

[0062] As described above, according to the embodiment, when searching for a transition path to verify whether the transition of the application's display screen after a predetermined operation is to a desired transition state, a shorter transition path can be easily searched. Consequently, the transition state of the display screen can be grasped in a shorter time, and the operation of the control program of the device under test 100 can be verified in a shorter time.

[0063] The above explanation concerns the case where the sequence is converted to a passage order and it is determined whether or not the passage order includes dead ends, and the sequence does not include dead ends (Step S25; No). However, if the sequence is converted to a passage order and it is determined whether or not the passage order includes dead ends, and the sequence does include dead ends (Step S25; Yes), it is not possible to test all screen transitions, so dead ends are resolved by reconnecting the connections (Step S28).

[0064] Here, I will explain a specific example of switching connections. Figure 18 is an explanatory diagram illustrating a specific example of a situation where rewiring is necessary. First, a shortest distance table and a path table are created using the Floyd-Warshall algorithm (step S21), a bipartite graph is created based on the direction of transition (step S22), the minimum weight maximum matching problem is solved (step S23), and as a result of converting the solution to the minimum weight maximum matching problem into a sequence of passages (step S24), the path may be divided.

[0065] Specifically, as shown in Figure 18, if the traversal sequence includes dead ends, resulting in a path that splits into two: Home screen GH → Display screen Ga → Display screen Gb → Display screen Gc → Display screen Gb → Display screen Gc → Display screen Ge, and an infinite path of Display screen Gd → Display screen Gc → Display screen Ge → Display screen Gf → Display screen Gd →..., then it is necessary to reconnect the paths.

[0066] Figure 19 is an explanatory diagram illustrating a specific example of rewiring. In this case, the dead-end display screen Ge enclosed by the solid line frame FL in Figure 18 and the corresponding infinite path display screen Ge are reconnected using a unidirectional link Lce enclosed by the thin line frame in Figure 19[A], which connects the infinite path display screen Gc and the infinite path display screen Ge, as indicated by the thin line arrow, to form the unidirectional link Lee shown in Figure 19[B]. As a result, the transition path, which was previously a dead end (display screen Ge → display screen Ge → display screen Gf → display screen Gd → display screen Gc), becomes connected, and the transition testing of display screens is automatically performed.

[0067] As explained above, even when dead ends are involved, by switching connections, it becomes easier to find a shorter transition path when searching for a transition path to verify whether the transition of the application's display screen after a predetermined operation is to the desired transition state. Consequently, the transition state of the display screen can be grasped in a shorter time, and the operation of the control program of the test device 100 can be verified in a shorter time.

[0068] The above explanation assumes the test subject is the transition between display screens. However, if the test subject is the transition between display screens and the display screen itself, or more specifically, if you want to include the updating of the display screen as part of the test, you can treat the display screen before the update and the display screen after the update as a virtual screen transition and conduct the test by introducing a virtual unidirectional link.

[0069] Figure 20 is an explanatory diagram illustrating the transitions between display screens and the display screens themselves as the subject of the test. As shown by the dashed line in Figure 20, the transitions to be tested are the transition from display screen Ga to display screen Gb and the transition from display screen Gd to display screen Ge, and the display screen to be tested is display screen Gc, indicated by the dashed circle.

[0070] Figure 21 is an explanatory diagram for adding a virtual unidirectional link to the display screen you want to test. As shown by the added dashed arrow in Figure 21, if the display screen to be tested is the display screen Gc indicated by the dashed circle, a virtual unidirectional link VLcc is added with the display screen Gc as both the starting and ending point of the transition.

[0071] Figure 22 is an explanatory diagram (part 1) of the bipartite graph when a virtual unidirectional link is added. In creating a bipartite graph, as shown in the right-hand diagram of Figure 22, the starting and ending points of the transitions are connected by unidirectional links, and the points are arranged in order so that the unidirectional links do not intersect. Next, the starting point of the transition (the display screen corresponding to the pre-initialization state or the starting node) is defined as the first independent set SI1, and the ending point of the transition (the display screen corresponding to the ending node) is defined as the second independent set SI2.

[0072] Figure 23 is an explanatory diagram (part 2) of the bipartite graph when a virtual unidirectional link is added. Next, as shown in Figure 12, the unidirectional links LPH, Lab, Lde, and VLcc shown in Figure 11 are temporarily ignored, and the pre-initialization state PI is excluded from the starting point since it is only traversed once.

[0073] Then, in the state shown in Figure 22, excluding the pre-initialization state PI, all transitions belonging to the first independent set SI1 and the transitions belonging to the second independent set are connected by links, as shown in Figure 23. The shortest distance table is referenced, the created bipartite graph is weighted, and the minimum-weight maximum-matching problem is solved to select the shortest distance link from all the links shown in Figure 23 for the display transitions between each point (each display screen) and for transitions between identical display screens Gc.

[0074] As a result, the unidirectional link corresponding to the transition shown by the thick arrow in Figure 23 is selected. Next, the shortest path is calculated by referring to the path table and connecting the start and end points of the transitions. The paths are then linked according to the order of passage to obtain the test order.

[0075] Figure 24 is an explanatory diagram of the route connection results. As a result, by stacking unidirectional links LPH, Lab, and Lde, the shortest path is obtained, represented as shown in Figure 16: unidirectional link LPH → unidirectional link LHa → unidirectional link Lab → unidirectional link Lbc → virtual unidirectional link VLcc → unidirectional link LCD → unidirectional link Lde. Next, based on the shortest path obtained, the paths are arranged in the order they are traversed.

[0076] Figure 25 shows the obtained shortest paths arranged in the order they are taken. As shown in Figure 25, the obtained shortest paths are rearranged in the order of passage through paths R1→R2→R3→R4.

[0077] Figure 26 is an explanatory diagram of the shortest path in the transition test. As shown in Figure 26, the automated test design device 11 can complete the transition tests for all transition paths and display screens of the test target shown in Figure 20 in a shorter time by having the automated test execution device 12 perform the tests in the order of path R1 → path R2 → path R3 → path R4.

[0078] As described above, according to this embodiment, even when the test subject includes both the transition path and the display screen, a shorter transition path can be easily searched when searching for the transition path, and consequently, the transition state of the display screen can be grasped in a shorter time, and the operation of the control program of the test subject device 100 can be verified in a shorter time.

[0079] Next, we will explain the operation of the entire test execution system. Figure 27 is an overview flowchart of the test execution system. The automated test design device 11 of the test execution system 10 performs a path search according to the procedure described above (step S31) and automatically creates and outputs test specification data corresponding to the screen transition test to be performed on the equipment under test 100.

[0080] As a result, the automated test execution device 12 reads the test specification data 22 created by the automated test design device 11 and issues an execution instruction for the screen transition test to the device under test 100 based on the test specification data 22 (step S32). The automated test execution device 12 then performs a screen transition test, determines the test results (step S33), and outputs the test execution result data 23.

[0081] Next, the automated test execution device 12 determines whether all screen transition tests have been completed (step S34). In the determination in step S34, if the screen transition test has not yet been completed (step S34; No), the automatic test execution device 12 proceeds back to step S32 and issues an instruction to the device under test 100 to execute the screen transition test.

[0082] In the determination in step S34, if all screen transition tests are completed (step S34; Yes), the test execution result data is output to the test database 13, and the test database 13 records the test result by associating the test specification data 22 and the test execution result data 23, and then the process ends (step S35).

[0083] As described above, according to the embodiment, the automatic test execution device 12 can automatically perform a screen transition test based on the test specification data corresponding to the screen transition test to be performed on the test target equipment 100 created by the automatic test design device 11, and can determine the test results and store them in the test database 13 as test execution result data 23, thereby enabling the screen transition test to be performed more quickly and accurately.

[0084] In this case, when searching for a transition path to verify whether the transition of the application's display screen after a predetermined operation is to the desired transition state, a shorter transition path can be easily searched. Consequently, the transition state of the display screen can be grasped in a shorter time, and the operation of the control program of the test device 100 can be verified in a shorter time.

[0085] The above explanation focused on finding the shortest test path in a screen transition path. However, it is also possible to configure a route search device that calculates the shortest path for a real vehicle by passing through multiple waypoints (corresponding to nodes) and allowing the same path to be taken multiple times, thereby traversing all desired waypoints. Alternatively, in a network, a route search device could be configured to find the shortest path for all test targets in the network by passing through nodes such as routers, allowing the same path to be taken multiple times, thereby traversing all desired waypoints. [Explanation of symbols]

[0086] 10 Test Execution System 11. Automated Test and Design Equipment 12. Automated test execution device 13. Test Database (DB) 14. Automated Test and Design Equipment 21. Specifications Data 21A Specification Data 21B Condition setting data (file) 22 Test Specification Data 23. Test execution results data 31 Database (DB) Reading Unit 32. Implementation Planning Department 33 Judgment section 34 Records Section 100 Test Equipment 101 Operation Execution Unit 102 Power supply section Ga~Gg Display screen Lab Unidirectional Link Lbb unidirectional link Lbc unidirectional link Lbe unidirectional link Lcd unidirectional link Lce unidirectional link Lde unidirectional link Leb unidirectional link Lee unidirectional link LHa unidirectional link Route R1~R5 VLcc Virtual Unidirectional Link

Claims

1. A pathfinding device that is represented by nodes corresponding to waypoints and unidirectional links corresponding to the direction of travel, wherein all of the said nodes have unidirectional links toward a predetermined basic waypoint, and searches for the shortest path that passes through all specified waypoints, A node dispensing unit that extracts two nodes connected by a single unidirectional link that are the subject of the test from the aforementioned path, A path generation unit sequentially performs the process of connecting the two nodes connected by one of the extracted unidirectional links with a new unidirectional link, where the terminal node of the unidirectional link is designated as a new starting node, and the starting node of the other two nodes connected by the extracted unidirectional link is designated as a new terminal node, and connects the new starting node and the new terminal node with a new unidirectional link corresponding to the shortest path, for all two nodes connected by the extracted unidirectional links to form a path resulting from the search, A pathfinding device equipped with the following features.

2. The route generation unit includes a data generation unit that creates a shortest distance table and a route table using the Floyd-Warshall algorithm. The pathfinding device according to claim 1.

3. The route generation unit determines the new unidirectional link based on a predetermined shortest distance table. The pathfinding device according to claim 2.

4. The path generation unit determines the new unidirectional link based on a predetermined shortest distance table by solving a minimum-weight maximum-matching problem. The pathfinding device according to claim 2.

5. If the route generation unit determines that the resulting path includes a dead end and the path is interrupted, the route generation unit will continue the path search by reconnecting the node corresponding to the dead end with the same node in another path that does not include the node corresponding to the dead end. The pathfinding device according to claim 1.

6. The route generation unit generates a route by connecting the single node with a virtual unidirectional link, where the node is the starting node and the ending node, when the route passes through a single node consecutively. The pathfinding device according to claim 1.

7. A pathfinding method that searches for the shortest path passing through all specified waypoints in a path that has unidirectional links leading to a predetermined basic waypoint, represented by nodes corresponding to waypoints and unidirectional links corresponding to the direction of travel, wherein all said nodes are represented by unidirectional links leading to a predetermined basic waypoint, From the aforementioned path, extract the two nodes connected by the single unidirectional link that are the subject of the test, The process of connecting the two nodes connected by one of the extracted unidirectional links, designating the terminal node of the unidirectional link as the new starting node, and the terminal node of the other two nodes connected by the extracted unidirectional link as the new ending node, and then connecting the new starting node and the new ending node with a new unidirectional link corresponding to the shortest path, is carried out sequentially for all two nodes connected by the extracted unidirectional links to connect them and form the search result path. Route search method.

8. The aforementioned new unidirectional link is determined based on a predetermined shortest distance table between the nodes. The pathfinding method according to claim 7.