KR100942987B1 - Method for test procedure optimize of robot software component - Google Patents

Abstract

PURPOSE: A method for test procedure optimize of robot software component is provided to have an efficient test procedure even if the number of test case is increased and the optimizing scheme of the test procedure gets complicated. CONSTITUTION: By back stepping from the final state(Exit) to the beginning state(RI) to find previous state for each test case. A test procedure is especially drawn each test case. The test procedure is classified based on the test case of the just before metastasizing to the final state as each group. With metastasizing to the state transition final state all state(SL1) find. With metastasizing to the angular states found in the first step all state (SL2) of the just before find. The state (RI,RA,RS), which is not overlapped with the state found in the first step immediately, all state (SL3) of the just before find. The state (RR), which is not overlapped with states found in the first, and the second step immediately, all state (SL4) of the just before find.

Description

Method for test procedure optimize of Robot software component

The present invention relates to a method for deriving a test procedure for performing a state transition test of a robot software component that conforms to the Robotic Technology Component (RTC) standard. Optimization of state transition test procedures for robot software components that derive both test cases and non-responsive test cases, resulting in test procedures using back stepping techniques to reduce duplicate test cases It is about a method.

A leading organization in the development of the Robotic Technology Component (RTC) standard, which is an international standard organization, the OMG (Object Management Group) standard, and the AIST of Japan (Advanced Industrial Science and Technology), which develops to use and develop RTC. A tool, OpenRTM-aist [1], is developed and distributed.

The structure of the RTC is shown in FIG. 1, and the state transition test tests whether the RTC operates correctly according to a specification.

State transition diagram of the RTC is shown in Figure 2, the activity includes the core logic (core logic) of the component, the core logic operates according to the state of the state machine (state machine) of the activity. The state machine of the activity is represented as the bottom of the dotted line in the Alive state of Figure 2. In the Inactive state, it does nothing and starts to perform functions when it becomes active.

If an error occurs in the active state, the state is changed to the error state, and if an error is reset, the state returns to the inactive state.

Core logic is the part that implements the function and operation of a specific component. For example, it refers to a part where an algorithm for controlling actuators by processing sensor data is implemented.

And although not represented in Figure 1, there is a thread that controls the behavior of CoreLogic, called Execution Context. The state of this Execution Context is the same as the upper part of the dotted line of the Alive state of FIG. 2, and the core logic operates only when the state of the Alive state is Running, and the core logic does not operate in the Stopped state.

In FIG. 2, the alive state is divided by a dotted line, which means that the two divided parts are in parallel processing relationship with each other. In other words, it does not affect the state of each other. Actually, experiments in OpenRTM-aist showed that they are not processed in parallel.

Therefore, the state transition diagram for RTC operating in OpenRTM is shown as below.

3 is a state transition diagram, all events necessary for state transition are expressed, but callback functions generated when a state is transitioned according to an event are the same as in FIG.

The Stopped / Steady Error '(SS'), Stopped / Inactive '(SI'), and Stopped / Active '(SA') states represent virtual states. In fact, if you execute the ExecutionContext :: activate_component event in the Stopped / Inactive state, the component does not react.

If you enter the ExecutionContext :: start event again, the transition is not to the Running / Inactive (RI) state, but to the Running / Active (RA) state.

4 shows a screen for giving an event to an RTC on OpenRTM-aist. Activate, Deactivate, Reset, Start, and Stop represent ExecutionContext :: activate_component, ExecutionContext :: deactivate_component, ExecutionContext :: reset_component, ExecutionContext :: start, and ExecutionContext :: stop, respectively.

State transition testing using the state transition diagram of FIG. 3 generally proceeds in the following order.

State transition testing

5 is a testing technique through a general state transition diagram. State transition diagrams show the relationship between states, that is, transitions between states, events and inputs that change states, and behaviors caused by changes in states. In other words, based on the state transition diagram, a test can be designed according to the following general procedure.

(1) Status-Event Table Configuration

(2) Transition tree configuration

(3) reaction test case configuration

(4) Responseless test case configuration

(5) Guard test case configuration

(6) test procedure configuration

FIG. 6 is a table of state-event tables that transition from one state to another state in the state transition diagram when an event is input.

The state transition tree determines the number of cases in which each state transitions to the next state, and includes all the states transitioned by the event.

Reaction test cases are derived by converting all paths through which state transitions by events into test cases in the state transition tree. Test procedures represent the order in which tests are executed, and their order is determined by the start and end states of test cases.

This will be described in more detail as follows.

(One). Status-Event Table Configuration

As shown in FIG. 6, on the OpenRTM-aist, the robot software component transitions to the RI state after passing through the Created state and receives no user input. Therefore, the state transition testing is performed with the start state as the RI state.

Here, 25SI, 31SI ', 38SA', 44SA '51SS', and 57SS 'represent virtual states SS', SI ', and SA', as described with reference to FIG. And the bold, underlined and underlined state like ' 1 RI ' does not transition, but it indicates that an error message has occurred. The transition to the exit state indicates component termination.

(2). State Transition Tree Configuration

FIG. 7 is a diagram illustrating each state transition tree based on the state-event table of FIG. 6.

Here we construct a 0-switch state transition tree that summarizes the case where one transition occurs. If the 1-switch transition is a tree, it represents a transition twice, such as RA-> RI-> SI.

(3). Reaction test case configuration

8 is a diagram illustrating a reaction test case through a state-event table and a state transition tree. In the action part, there is an item called Error Msg, which is an action that appears in OpenRTM-aist and displays an error message on the screen.

(4). Responseless test case configuration and guard test case configuration

In this state transition testing, there was nothing that could constitute a non-response test case and was ignored. In addition, the state having a guard is represented by a reaction test case by dividing the state into different states according to the guard. (V012, V020, V021 in FIG. 8)

(5). Derivation of test procedure

Using the reaction test case configured in FIG. 8, the start state and the end state are determined based on the order in which the test cases are to be performed. And write as shown in Figure 9 to confirm that all the test cases can be performed.

For example, you can simply write a procedure like this:

tp1: V001-> V002-> V005-> V006-> V003-> V024-> V026.

tp2: V003-> V025-> V030-> V031-> V032-> V033-> V029...

…

tpn:…

This simple method can quickly and easily produce an efficient test procedure that includes all test cases in state transition testing with simple state transitions, but as the relationship between states becomes more complex and the number of test cases increases, There was a problem that is very difficult to derive the procedure.

Accordingly, the present invention is to solve the above problems, an object of the present invention is to analyze the RTC operation on OpenRTM-aist to derive an efficient test procedure (back stepping) method in the state transition test This study provides a method for optimizing state transition test procedures for robotic software components that makes the relationship between states complicated and increases the number of test cases.

The optimization process of the state transition test procedure for the robot software component according to the present invention starts with a running / incident (RI) state, which is a start state, for testing a robot software component that complies with the RTC standard, and receives an event to the next state. Create a state-event table that represents the transition of, create a state transition tree that calculates the number of cases where each state transitions to the next state, and then, from the start state (RI), each state is transitioned by an event. A method for deriving a test procedure indicating a procedure for executing a test from the test case by converting all paths up to a final state to a test case, wherein the path is derived from the final state. Backstepping step by step until the starting state (RI) Is a test procedure filtering process, a test procedure derivation process for deriving a test procedure for each test case for each state transition from a start state (RI) to a final state (Exit) in the filtering process, and the final state (Exit). Based on the test case immediately before the transition to the)), the procedure optimization process for classifying the test procedure into each group, and the test procedure generated by combining each of each group in the test procedure calculated in the procedure optimization process It is characterized by including the completion of the procedure for deriving each procedure.

The test case filtering process includes a first step of finding all the states SL1 immediately before the state transition to an exit state, and each state SL1 found in the first step. A second step of finding all the states SL2 immediately before the transition, and a state (RI, RA, RS) not overlapping with the state SL1 found in the first step among the states SL2 found in the second step. The third step of finding all the state (SL3) immediately before the extracted state (RI, RA, RS), and the first and second of the state (SL3) found in the third step And extracting a state RR that does not overlap with the states SL1 and 2, and then finding a fourth state immediately before the extracted state RR.

The procedure optimization process classifies all test procedures derived from the test procedure derivation process into six groups according to the state immediately before the final state (SI, SI ', SA, SA', SS, SS '). The test procedure of each group is derived and combined into one test procedure, wherein each group is a first step of searching for a separately checked test case closest to each state, and immediately following the state of the searched test case. The procedure connects the test cases of the previous test procedure with a second step found in the test procedure, a state close to the exit state found in the next test procedure, and the procedure And a fourth step of generating an accumulated new test procedure.

In the method for optimizing the state transition test procedure for the robot software component according to the present invention, it is possible to derive an effective test procedure even if the relationship between states becomes complicated and the number of test cases increases by systematically deriving the test procedure. In addition, the time required to write a test procedure and the number of test cases performed throughout the entire test procedure are reduced, thereby reducing the test time required for software components that conform to the RTC specification.

First, in order to perform the state transition test, the present invention must first have a state transition diagram of the test object. It then creates a state transition table, uses it to build a state transition tree, and creates a reaction test case.

Here, the state transition table organizes each state transition by an event by state transition and test case, and state transition represents a state in which each state transitions to the next state. N-switch state transition is n + in each state. Represents all transitions that occur when one transition occurs, and the present invention uses a 0-switch state transition tree.

Each test case has an entry state (RI), an event, an action, and an exit state. It becomes a reaction test case when a state action or any action occurs, and a non-response test case when there is no response to a specific event. In the present invention, a reaction test case is used.

All written test cases should be executed through one or several test procedures. The test procedure represents the order in which the test cases are executed. The test procedure is determined according to the start state and end state of the test case.

Multiple test procedures can involve performing the same test case. Typically, a check table is created by simply checking to derive the test procedure to perform all test cases.

10 is a diagram illustrating a state transition tree for implementing a method for optimizing a state transition test procedure for a robot software component according to an embodiment of the present invention.

First, the backstepping level 1 SL1, which is a state immediately before the state transition to the final state Exit, is extracted. SL1 = {SI, SI ', SA, SA', SS, SS '}

In backstepping level 2 SL2, the states immediately before the states extracted in the backstepping level SL1 are found. SL2 = {RI, SI _SI , SI _{SI '} , SI', RA, SA _SA , SA _{SA '} , SA', RS, SS _SS , SS _{SS '} , SS'}

Here, SI _SI and SI _{SI '} states are actually SI states, but are separated by subscripts to distinguish which state is extracted by backstepping. In the case of judging whether the state is duplicated, it is determined to be the same as SI.

The states extracted in the backstepping level SL2 are classified into three categories as follows.

① does not belong to SL1, RI, RA, RS status that appears first in SL2,

② SI _SI , SI _{SI '} states belonging to SL2 and having RI in the previous state,

(Here, the states that have RI just prior to them are SI and RA. They can go to RI state and no longer backstepping.)

③ It belongs to SL1, SI _SI , SI _{SI '} and classified into SI', SA _SA , SA _{SA '} , SA', SS _SS , SS _{SS '} , and SS' state, which does not have RI as the previous state. Since we have performed backstepping before, we do not backstep here anymore.)

Backstepping level 3 SL3 finds the immediately preceding states of RI, RA, and RS states (classified as ①) extracted from backstepping level 2 SL2.

SL3 = {RI _RI , RA _RI , RR _RI , SI _RI , SA ', RI _RA , RA _RA , SI', SA _RA , RA _RS , RS, RR _RS , SS _RS }

It is classified into three categories as follows.

④ RR _RI state, which does not belong to SL1, SL2, but appears first in SL3,

(5) the states belonging to SL1 and SL2 and having RI in the immediate state, RI _RI , RA _RI , SI _RI , RA _RA , RI _RA , RA _RS state,

(6) It is classified into SL1, SL2 and SA ' _RI , SI' _RA , SA _RA , RS _RS , RR _RS , SS _RS states which belong to the RR _RI state and do not have RI as the previous state.

Finally, the back-stepping level 4 (SL4) The find the earlier state of (a classified ④) RR _RI state condition extracted from the back-stepping level 3 (SL3). SL4 = {RS, SS '}

As such, each state was backstepped and each level was classified according to the next backstepping capability.

The classifications " 2, 3 " of SL2, " 5, 6 " of SL3, and SL4 extracted at each back stepping level no longer perform back stepping. Among the states extracted from classifications ② and ⑤, there is no problem in deriving the procedure because the previous state is the starting state (RI), but the remaining states of classifications ③, ⑥ and SL4 are backstepping to go to the starting state (RI). Will do more.

11A and 11B are tables showing test procedures derived by back-stepping the state tree of FIG. 10, where the state is transferred to the table as it starts from the start state (RI), and starts from SI or RA. The starting state (RI) was added to the previous state and moved.

The procedure optimization process is classified into six groups according to the states immediately before the final state (SI, SI ', SA, SA', SS, SS ') in FIGS. 11A and 11B.

Determine if a procedure in each group is included in another procedure, and if so, remove the procedure. Search the procedures of all groups in order and check the first test case separately. In each group of procedures, search for the separately checked test case closest to the starting state (RI). The state of the retrieved separately checked test case is found in the next procedure. (If it does not exist in the next procedure, it finds itself in the state of the test case retrieved in the next procedure.) Test the previous procedure using the state found in the next procedure close to the exit state. Connect the cases. (Use the state you find yourself close to the Exit state to connect test cases in the following procedure.)

A new cumulative procedure appears, linking the two procedures. Use this new procedure to create another new procedure by repeating the above procedure with other procedures in the same group.

12A to 12F illustrate a procedure of creating a procedure for each group, and connecting the procedure at the top of each table to the procedure immediately below so as not to affect the first test case. It is possible to calculate one test procedure for each group that performs all the test cases shown in. The procedure shown in the last row is the last test procedure created.

The procedure completion process extracts the test procedure finally generated for each group during the test procedure optimization process.

FIG. 13 is a table display diagram illustrating a procedure of extracting the procedure of the last row derived from FIGS. 12A to 12F, in which the final test procedure derived from the test optimization process includes a case where several test cases are included in one cell. In other words, test cases that are maintained in their own state when different events cause the same state transitions are optimized test procedures in which only one test case is represented in one cell to represent the actual test procedure. Will be derived.

FIG. 14 is a table confirming whether the actual procedure in FIG. 13 includes all test cases.

1 is a diagram of a robot software component structure in which an internal function is added to a basic robot software component structure proposed by an RTC standardized by OMG.

2 is a state transition diagram of a component managed by a state machine of the activity of FIG. 1,

3 is a state transition diagram for an RTC operating in OpenRTM,

4 is a screen display for giving an event to the RTC on OpenRTM-aist,

5 is a diagram illustrating a general procedure of state transition testing,

FIG. 6 is a diagram summarizing a transition to another state when each state receives an event in the state transition diagram of FIG. 3.

FIG. 7 is a diagram illustrating a state transition tree based on FIG. 6.

FIG. 8 is a diagram illustrating all paths through which the specific state is transferred to the next state by a specific event through the state transition tree of FIG. 7, wherein each path is represented by a test case.

9 is a check table for checking whether a test case is performed through a test procedure so that all test cases are performed.

10 is a diagram showing a state transition tree for implementing a method of optimizing a state transition test procedure for a robot software component according to an embodiment of the present invention;

11A to 11B are diagrams showing an intermediate test procedure derived according to an embodiment of the present invention.

12A to 12F illustrate test procedures calculated through a procedure optimization process according to an embodiment of the present invention.

FIG. 13 is a diagram illustrating a completed test procedure in which portions of different events shown in FIGS. 12A to 12F cause the same state transition,

FIG. 14 illustrates a check table for confirming whether all test cases shown in FIG. 13 are included in a test procedure.

Claims (6)

To test a robot software component that complies with the Robot Technolocy Component (RTC) specification, it generates a state-event table indicating the transition to the next state starting from the starting running / incident (RI) state and receiving events. After creating a state transition tree that calculates the number of cases where the state transitions to the next state, all paths from the starting state (RI) to the final state (Exit) where each state is transitioned by the event are passed to the test case. In the method for deriving a test procedure derived from the test case, the test procedure indicating the execution order of the test from the test case, A test case filtering process of finding a previous state for each test case by back stepping from the final state to the start state RI step by step; A test procedure derivation process of deriving a test procedure for each test case for each state transition from a start state (RI) to a final state (Exit) in the test case filtering process; A procedure optimization process of classifying the test procedure into each group based on a test case immediately before transition to the final state; And A state transition test for a robot software component, comprising: a procedure for completing a procedure for deriving a combined test procedure for each group from each test procedure calculated in the procedure optimization process. How to optimize your procedure. The method of claim 1, The test case filtering process may include a first step of finding all the states SL1 immediately before the state transition to the final state Exit; A second step of finding all the states SL2 immediately before the transition to each state SL1 found in the first step; Among the states SL2 found in the second step, the state RI, RA, RS that is not duplicated with the state SL1 found in the first step is extracted, and immediately before the extracted state RI, RA, RS. A third step of finding all states SL3 of the; And After extracting the state RR which is not duplicated with the states SL1 and 2 found in the first and second stages among the states SL3 found in the third stage, all states immediately before the extracted state RR (4) finding a SL4; and a method for optimizing a state transition test procedure for a robot software component, comprising: a; The method of claim 2, The states SL2 to SL4 of each step found through backstepping in the second to fourth stages generate test cases in groups for the same state transition, but all test cases are used through the first to fourth stages. A method of optimizing a state transition test procedure for a robot software component, characterized in that The method of claim 1, The test procedure derivation process is characterized by deriving a series of states and test cases in the order of transition for the state transition of all paths from the start state (RI) to the final state (Exit) found in the test case filtering process. How to optimize state transition test procedures for robot software components. The method of claim 1, The procedure optimization process classifies all test procedures derived from the test procedure derivation process into six groups according to the state immediately before the final state (SI, SI ', SA, SA', SS, SS '). Therefore, the test procedures of each group are derived and combined into one test procedure. Each group comprising: a first step of searching for a separately checked test case closest to each state; A second step of finding a state of the searched test case in a next test procedure; A third step of connecting test cases of a previous test procedure by using a state close to an exit state among the states found in the next test procedure; And a fourth step of connecting the procedure to generate a cumulative new test procedure. The method of claim 5, The method for optimizing the state transition test procedure for the robot software component, characterized in that the test procedure generated for each group in the fourth step sequentially lists each test case according to each state transition.

Images