Integration Test Technology for High Quality Embedded System Development

However, software integration and testing are very difficult, especially for embedded systems. Due to less input and output, the operability and visibility of the system are very limited. Abnormal system states are particularly difficult to test because the system must be brought into a state before determining the behavior of the system in that state.

This paper puts forward the idea of injecting the instrumentation code into the implementation of UML model, in order to improve the controllability, observability and testability of the system. The test instrument can be applied in the development and target environment, and interactive system debugging can be carried out at the model level. In batch processing mode, test instrument is the basis of data acquisition, initialization and test automation. This paper aims to: briefly introduce model-based software engineering and the implementation of these models; The integration test method of model-based software is summarized; Determine the important running time data and execution key points in the model system; Several schemes of collecting and operating model data at run time are described; Enable the test instrument to test automatically.

Software failure refers to the wrong instruction or calculation in the program. The execution of software failure will lead to software status error. When the error is transmitted to the output and presented outside the system as an abnormal result, the fault will occur. Program controllability refers to the ability of a test system to force the tested program to follow a specific execution path, or there may be errors in the execution along this path. Program observability refers to the ability of the test system to find out the error state and then point out the fault.

The internal state of the system is very important to determine the correctness of the test. The output of the system is determined by the initial state of the system and its input. For systems with different initial states, even if the inputs are the same, the outputs will be different. The final state of the system must also be considered as part of evaluating the correctness of the test, because the incorrect internal state will eventually be transmitted to the output of the system and lead to errors. The complexity of the system also makes it more difficult to predict the correct output of the system.

Initial state input -- > final state output

In the "black box" test method, only the external input and output of the system can be known. A special test excitation sequence is needed to transmit the error to the output in order to distinguish the error from the correct program. The longer the special sequence required, the less testable the program is. Similar to the "black box", the controllability and observability of embedded system are also low. The results of evaluating the internal state of the final system can shorten the special input sequence required to detect errors, resulting in smaller and easier test cases. The test instrument strives to improve the controllability and observability of the software program at the same time, so as to obtain a more testable program.

The technology of using test support instruments in application code is a "glass box" test method. When developing the UML model of the system, the developer must understand the tasks to be completed by the system. The error isolation strategy based on test instrument can apply the knowledge of UML model to integration testing. The operation and state of the system are more visible at the analysis level than at the coding level, because the latter is affected by implementation details.

Setting the initial system state of the test only from external input requires a specific external excitation sequence. System operation under abnormal state is the key to verification in many embedded applications, but it is not easy to generate these initial states. The technology described in this paper can use test means to greatly improve controllability and observability.

Steps of integration test

Integration testing can be divided into two important stages: dynamic verification and target integration. Dynamic verification is to run the UML model in the development environment, and its purpose is to determine the correctness of the model. Target integration involves integrating software and hardware in the target environment. Both dynamic verification and target integration are carried out at the analysis level, using the same tool, i.e. test support instrument.

There are many reasons to conduct dynamic verification testing as much as possible: Hardware availability, hardware / software separation, shorter debugging cycle, and the use of tools. If you can be sure that there is no problem with the model after the running test of dynamic verification, the debugging of target integration can focus on the interface between system components or specific platform problems.

a. Building embedded system model with UML

The effective application of UML model in software engineering of embedded application requires that the development process can ensure that the model is strict and complete; Optimize the generated system implementation without affecting the model; The overall structure of the system is maintained by the process through multiple versions and required upgrades.

In order to achieve these goals, model-based software engineering adopts a transformation method. This transformation method is mainly discussed to add test support to the code, but this technology can also be applied to manually implemented UML models. The characteristics of this conversion method are described below.

b. Analytical model

Analysis is the process of establishing an implementation independent model scheme for the problem itself. The effective analysis model is rigorous and complete, and has nothing to do with the implementation method. UML is a standard symbol defined by OMG, which is mainly used to express analysis and modeling. The analysis process can produce:

Domain model: This is a UML class diagram, which decomposes the system into independent subject areas, called domains. These domains are represented by packages and dependent arrow display bridges, where the latter is the flow of requirements between domains. The domain can be analyzed or developed by other methods, such as manually written code, inherited code, generated from other sources, imported from a library, etc. Domain services are the methods that make up domain interfaces. Since a domain defines a complete specification for a problem area, it can be tested independently and then combined with other domains for further testing.

Information model: for each domain to be analyzed, UML class diagram can be used to define the classes that make up the domain structure. Classes are related to each other and can inherit other classes.

Scenario model: the UML sequence table or UML collaboration diagram captures the main context of a specific domain and is used to represent the interaction between domain services (operations), class services (Methods), class event messages and foreign services referenced by the domain.

State model: for each class that receives event messages, the UML state diagram can be used to capture the class cycle and define the state related characteristics of the class.

Behavior model: a detailed and explicit behavior description will be generated for each domain service, class service and state behavior. This is expressed by a behavioral language, which provides a complete analysis level execution primitive without affecting the implementation. Using behavior language to express behavior details can retain a great degree of freedom before realizing the transformation stage of analysis primitives, which is very important for optimization.

c. Design

Design is the process of generating policies and mechanisms that map analysis constructs to the runtime environment. The concept is different from the analysis, and most of the preliminary design work can be carried out independently of the analysis activities.

d. Conversion

Transformation is the process of mapping the UML model of each domain to be analyzed to the implementation with design strategies. The design is carried out in two stages:

Structure design: identify the execution unit (thread / task / process) of the system, assign it to the processor, and assign the domain to the unit.