Shulou(Shulou.com)06/03 Report--

Editor's note: with the increasing security attention of industry software, carrying out comprehensive unit / integration testing at the beginning of product testing has gradually become a key link in the process of development and testing, which will help to find hidden dangers as soon as possible. reduce development costs and more adequate functional verification. ISO26262 and ASPICE also put forward corresponding requirements for the implementation of unit / integration testing. The unit test of the code requires functional testing of each independent unit in the program, and the unit combination of several hierarchical structures, if it has a clear function, can also be called a module. For integration testing, it is required to test the modules with complete functions. Here, the modules with complete functions can be called components, and the combinatorial testing of each component is gradually realized by means of incremental testing. integration testing can also be seen as a process of comprehensive verification of the functions of these components and the combined functions of these components.

This article comes from the white paper "Component Testing of Test Objects in C++-Writing scenarios for integration testing in TESSY" issued by Hitex, the original factory of Tessy, at the end of November.

1 from unit to component

1.1 types of test objects

We will discuss "unit testing", "module testing", "integration testing" and "component testing" based on the type of test object, focusing on temporal component testing (assuming the software is C or C++ development).

♦ 1.1.1 standalone unit

A single function is the smallest reasonable test object in C language programs, which is usually regarded as a unit. If the programming language is Clover, then the method is treated as a unit.

Unit testing is a functional verification based on the interface of the unit under test (that is, input and output). When the unit test is carried out, the program under test will actually be compiled and executed. If the "unit" being tested calls other functions, it can be replaced by creating pile functions to ensure the smooth progress of the test and improve the test efficiency.

♦ 1.1.2 hierarchical units

Multiple units with hierarchical structure can be carried out in a way similar to a single unit test, taking the top-level unit as the test object, paying attention to the overall function, and the called unit as the internal implementation, testing for the overall input and output.

Fig.1 uses the top-level unit as the unit hierarchy of the test object

From a technical point of view, this can be achieved by replacing the called unit without a pile function. You can still think of it as a unit test as above, but a larger unit.

This can also be seen as integration tests in the unit hierarchy, because to some extent, they must work correctly together to pass the test. Such a unit hierarchy can also be referred to as a Module, but I don't want to use this term because it may be confused with the concept of the source module of the CCompact + program. A C source module cannot be directly used as a module test object because it is defined by syntax, while the module used for module testing is usually defined by semantics. Testing of multiple unit hierarchies is technically very similar to a single unit test, and since the topic of the current document is component testing, testing of functional hierarchies is further discussed.

♦ 1.1.3 Units that interact and have no temporal relationship

Contrary to the cell hierarchy, we next assume that there is not necessarily an invocation relationship between units. However, we assume that these units work together, such as manipulating common data to achieve a common goal.

The well-known abstract data type "stack" and its push and pop operations are a straightforward example. Independent testing of pop and push operations is a unit test, but the necessary integration tests are still required. The integration test consists of a series of pop and push operations. The input of the test case consists of the initial content of the stack and the parameter values of the push operation, resulting in the return value of the pop operation and the final state of the stack. If push and pop operations may result in additional calls to units, such as calls to error handling units with stack overflow / underflow, these calls are also the expected results of the integration test case.

Fig.2 unit tests are insufficient for push and pop operations of the abstract data type "stack"

The term "Module" may be more appropriate for such a collection of collaboration units, but I prefer to use the term "component" because it has a different meaning than the Cmax Cure + source module.

The internal structure of Fig.3 components and its interface with the outside

At least one of the units contained in the component must have the ability to call from outside the component to drive the component. Usually several units of a component come from external calls, and we call these units "component functions" or "component units". Testing a component no longer consists of (one or more) calls to a single unit (as described in the above two sections), but consists of a series of calls to (different) component units. The call to the component unit activates the component, and like a single unit test, the component's test case includes input and output data (variables of the component and parameters of the called component unit). A component may have internal units that cannot be called from outside the component and can only be obtained through function calls within the component.

The work done by the internal unit, if any, has nothing to do with component testing, so in component testing, the entire component is treated as a black box. However, what is relevant to the component test results is the sequence of calls from within the component to the (callable) units in other components. This involves the number of calls, the order of calls, and the parameters that the calls are passed to other components.

Obviously, the functions of the units in the component and the interfaces between them are verified by component testing in most cases. Therefore, component testing can be seen as an integration test of units in a component.

♦ 1.1.4 interacting and time-dependent units

In the previous section, timing is not the point, whether it is the duration of the firing call of the component or the time between the firing call of the component and the result call of another component. However, this is an important test to check whether the response is fast enough after receiving the trigger call, that is, within a fixed time frame.

In order to be able to test the timing behavior of components in a simulated environment, a simulated time base is needed. This means that a unit within a component is called within a known isometric time (for example, per 10ms), which is usually the case when the component executes under the control of the real-time operating system (RTOS) and uses time-slicing (such as OSEK), but a simple interrupt-driven application usually meets this requirement.

Calls to this unit represent the "heartbeat" of the component, and they provide a (simulated) time reference for testing the timing behavior of the component. The heartbeat function is often referred to as "handler function" or "work task" or simply "tick".

Fig.4 if the heartbeat function exists, you can test the timing behavior

2 example of C++ stack

2.1 introduction

As mentioned earlier, the abstract data type stack is a typical example, and integration testing in Tessy requires the use of Tessy's component testing capabilities (accessible in the scenario editor perspective). Moreover, push and pop do not call each other, but communicate on common data (stacks), so pure unit testing techniques are not applicable because they require units to have a single entry point, that is, unit testing focuses on testing a single function / method.

Fig.5 stack.push and stack.pop do not call each other and need integration testing

2.2 Test object source code

Source code of the Fig.6 test object (stack.cpp)

Note: the last three lines of the source code are not stack implementations, but are required by Tessy. Due to the use of # ifdef, the tick () function appears only when the source file is processed by Tessy.

2.3 Tessy preparation work

Select GCC (C++) for the test environment, select Component for the test type, and import the code.

Fig.7 chooses compilation environment

2.4 Interface Settin

Create a new variable my_stack as the instantiated object.

Fig.8 interface settin

2.5 Test case design and execution

Create the first test case: verify the on-and-off stack operation.

Design and implementation results of Fig.9 scenario 1

Create a second test case: the purpose of this use case is to verify the functional implementation in the case of stack underflow.

Select Test Cases Separately on the Edit Test Execution Settings interface to execute two scenarios respectively. The scenario and result are shown in the following figure.

Design and implementation results of Fig.10 scenario 2

In the use case design interface of SCE, the action for the pointer is as follows: create an object for the pointer * arr and specify it as an array of length 4 The pointer to this target is allocated by Tessy to the variable arr in the object my_stack, that is, the allocated memory replaces the memory allocated by the constructor of the test object, which appears in both the Inputs and Outputs column items because the interface to the pointer object was previously set to INOUT.

Fig.11 creates an object for pointer * arr

Fig.12 scenario 2 SCE executes the actual result

Constant moisture of longitude and weft

6 / F, Block D, Zhizhen Building, 7 Zhichun Road, Haidian District, Beijing

Tel: 010-64840808

Mailbox: market_dept@hirain.com

Web site: www.hirain.com

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.