Embedded Software Testing Method Based on Modular Design

Embedded Software Testing Method Based on Modular Design

Abstract: This paper analyzes the characteristics of embedded software and reviews the traditional software testing methods. Based on the characteristics of embedded software, it proposes a four-level testing process and an integrated testing model for embedded software, the analysis is carried out based on the examples of developing the numerical control system.

Keywords: Modular Design Embedded Software Testing Method Testing model Numerical Control System

Embedded design has become the only path to industrial modernization and intelligence. embedded products have already penetrated into all walks of life. Embedded systems have a high degree of specialization, and the overall inheritance of the system is relatively small. To ensure system stability, software testing has become an important part of embedded development. Due to the characteristics of embedded software, traditional software testing theory cannot be directly used for testing embedded software. Therefore, it is important to study the testing of embedded software.

1. Basic Concepts
1.1 Modular Design
Software design is based on certain methods. In the face of increasingly complex software development tasks, people have proposed various software design models. Based on user requirements and the task functions to be implemented by the system, large software is divided into relatively small modules. In order to reduce the correlation between modules, the logical structure between modules is relatively independent, there is no function cross call, and data transmission is completed by global variables. This is the basic idea of modular design. The core of modular design is module independence, which mainly includes functional independence and structural independence, which makes the division of labor in software development easy to implement. Software testing is a key link in software development. The software testing model based on modular design is simple, and error detection and error correction are easy to implement. The following describes the basic software testing principles of Modular Software Design Based on the software model of single link data transfer.

In Figure 1, function f (X-Y) is defined as an interface function from module X to module y, which is used to display data from module X into module y through a terminal. If an error occurs after Module C is executed, the data interface function f (B-C) of Module B and Module C determines whether the data from Module B is wrong. If F (B-C) is good, it proves that Module C has an error; if F (B-C) is passing a data error, then check if F (A-B) is passing a data error, if it is good, it indicates that Module B has an error. You can use this method to isolate errors in sequence, that is, you can easily locate the module where the error is located. This is the basic principle of software testing in modular design.

1.2 Embedded System
Embedded system development has its own characteristics. Generally, we first develop the hardware part, mainly including forming a bare metal platform, porting Real-time Operating Systems as needed, and developing underlying hardware drivers. After the hardware platform passes the test, the software development and debugging should be based on the hardware platform, which is also a test of the hardware platform. The entire embedded system development process 2 is shown.

Therefore, it can be said that the development process of embedded systems is a process of coordination between hardware and software, mutual feedback and mutual testing. In general, in embedded system software, the boundaries between underlying drivers, operating systems, and applications are unclear and may even be compiled together as needed. This is mainly because of the hardware dependency of software in the embedded system. Embedded Software depends on hardware. During software testing, the actual operating environment of the tested software must be simulated to the maximum extent to ensure the reliability of testing. Unclear boundaries between underlying programs and applications increase the difficulty of testing. during testing, only when the embedded system platform and underlying programs are confirmed to be correct can applications be tested, in addition, it is difficult to locate errors during system tests. Software specialization is also an important feature of embedded software. The embedded software design is based on a certain target hardware platform and oriented to fixed tasks. Therefore, once loaded to the target system, the functions must be completely determined. This feature determines the poor inheritance of embedded application software, extended system testing time, and increased testing costs. Another important feature of embedded software is real-time performance. This is explained from the perspective of software execution, that is to say, the execution of embedded software must meet certain time constraints. In an embedded system, the complexity of the algorithm of the application software and the task scheduling of the operating system determine the allocation and consumption of system resources. Therefore, when testing the system's real-time performance, it is necessary to use certain testing tools to analyze and test the complexity of the application algorithm and the task scheduling of the operating system. It can be seen that embedded software has its own characteristics compared with traditional object-oriented and process-oriented software. It is necessary and meaningful to study the testing of embedded software based on these features.

1.3 Embedded Software Testing
Software testing is a process of ensuring the quality and correctness of software code from the economic and efficiency perspectives. Software testing is an important part in software development and a key link from the development process to the application process. Embedded Software is no exception. Figure 3 shows a unified test model for embedded software testing. Software testing has gradually become a mature discipline. Our predecessors have made a lot of research on the testing of object-oriented and process-oriented non-real-time software. Most of the methods can be used to test embedded software.

Depending on different indicators, software testing methods have different division methods. Different stages of testing during software development can be divided into Module Testing, integration testing, and system testing. The target code can be divided into dynamic and static tests based on whether the target code needs to be run. The visibility of the target code can be divided into white-box tests (Structure tests) and black-box tests (functional tests ). In software testing, each test method is not isolated. Various testing methods are usually nested to achieve the most economical and effective test Purpose. For example, in the unit test phase of the software, you can use the black box test and white box test methods to perform dynamic tests respectively.

It is worth mentioning that in software testing in recent years, the coverage rate of test code has gradually become a unified standard for Software Testing. Therefore, no matter what test method is used, it is necessary to increase code coverage during software testing as much as possible. The software test code coverage rate is based on the white box test method. Therefore, to improve the software test code coverage rate, the tester must be clear about the source code structure and have a program design document, in order to design test cases so that the test overwrites every statement in the internal structure of the program as much as possible to improve code coverage.

2. Four-level test process of embedded software based on Modular Design
According to the development process of the embedded system, in order to achieve the most economical functions of the system, the embedded system is tested using a top-down, layer-by-layer approach, the four-level test process of embedded software based on modular design is presented. In the level-4 test, when an error is found after the test is completed before this test phase, you can queue errors before this test phase and locate errors during this test phase. This is not an absolutely accurate method, but it maximizes the time for locating errors.

2.1 System Platform Test
This part includes hardware circuit testing, operating system and underlying driver testing. Hardware Circuit Testing requires a dedicated test tool. I will not describe it here. The testing of the operating system and underlying drivers mainly includes testing the task scheduling, real-time performance, and data transmission rate of the communication port of the operating system. After testing in this phase, the system should be a complete embedded system platform. You only need to add applications to complete specific tasks.

2.2 module test
A large embedded software system is divided into several relatively small task modules, which are encoded by different programmers at the same time. After coding, you must test a single module before integrating the modules. Because there is no support for data transfer from other data modules, the test section in this phase is carried out on the host machine (the host machine has abundant resources and a convenient debugging environment ). In this phase, we conduct white-box testing to test every function, every condition branch, and every program statement as much as possible to improve the coverage rate of code testing. As only a single module is correct can the need for overall integration, the test of a single module must be complete and complete. In the module test phase, the construction of test cases should not only test the normal operation of the system, but also conduct a boundary test. The boundary test is to test the maximum and minimum values of a certain data variable, and conduct a cross-border test at the same time, that is, to test the running status of the system by inputting data variables that are not input. The ideal embedded system should not be caused by user information interaction, which is also a basic requirement of embedded design. Therefore, no matter what test is performed, the system crashes and should be treated as a test error. In the module test phase, based on the basic idea of Modular programming, large modules can also be divided into small modules according to the Compact program in the module. In the program, the interface function is designed for the entry of data transmission between small modules to quickly locate errors. The nested idea of this module is used for software testing. The internal structure of the module is clear and the data link is simple.

2.3 integration test
After a software module is tested correctly, all modules are integrated for testing. This phase mainly refers to identifying errors in the logic structure after data transmission between modules and system composition. On the host machine, the black box and white box methods are used for testing. The actual running environment should be simulated to the maximum extent, it can block some functions that are difficult to simulate without affecting system execution and data transmission. Integration testing is a stage in which the advantages of modular design software are fully reflected. Before integration testing, programmers should compile module interface functions based on the input and output of data between modules. This should be done by programmers in different software modules, then integrate the module interface functions into the entrance of the receiving data module. According to the previous analysis, the software module of single-link data transmission is easy to locate the software module where the error is located during integration testing. The data of a software module is not necessarily provided by only another module, that is, the data link of the software module is not necessarily a single link, during testing, data transmission of complex link structures can be divided into single-link data transmission for error locating. When you modify the software module of the output data, a new error may be introduced to the software module of the input data. Therefore, the associated matrix is introduced here to determine the module to be tested after a module is modified.

Assume that the modular design of embedded system software consists of the software module AI (I = 1, 2 ,..., M, n). M indicates the row number of the matrix, and N indicates the column number of the matrix. The matrix shown in Figure 5 is its associated matrix.

In the association matrix, AIJ = 1 indicates that AJ accepts the data output from AI. Therefore, when AI is modified to re-test AI, AJ needs to be re-tested.

Integration Testing tests software module errors in integration when you have a program design document, program structure, and data structure. During integration testing, the module interface function locates the error code and determines the software module to be re-tested based on the association matrix. Figure 6 shows a modular embedded software integration test model.

2.4 System Test
After the integration test is complete, exit the host machine test environment, port the system to the target machine, complete the application to the on-site environment, and perform a black box test on the system from the user's perspective, verify each specific feature. As the tester has no knowledge about the execution of the program content program, it is difficult to locate errors in this test phase. Unexpected testing and destructive testing should be carried out in the system testing phase, that is, testing of incentive activities and man-made destructive testing that should not occur during normal system execution to further verify the system performance. In the system test phase, the Code should not be modified immediately after an error is determined. The test cycle should be determined based on the Occurrence Frequency of the error. The Code should be modified at the end of each test period for repeated tests. Otherwise, this not only increases the number of complete test tasks, but also reduces the test reliability.

2.5 Test Result Analysis
The analysis of the test result can locate the error, instruct the programmer to modify the code, and point out the program for testing and further specify the test direction. The analysis of test results is a process of analyzing, comparing, and Locating Errors Based on test results and pre-test results. The analysis of the test result is the final step of a test. The differences between the software running environment and the actual running environment and the impact of various external factors should be considered during the analysis.

2.6 Construction and Management of Test Cases
A test case is a file designed to test the target program that includes input items and pre-results. Depending on the test environment and test target program, it can be divided into documents in a certain format or some input behavior (such as a button. The construction of test cases should cover all possible value ranges as much as possible, so that the test overwrites all program code as much as possible, so as to improve the test coverage of the code without redundant, repetitive, and meaningless tests. In different stages of embedded software testing, different test cases should be constructed; in the system platform testing stage, test cases for system task scheduling, real-time performance and underlying driver should be constructed; in the module test phase, a test case for a certain module should be constructed; In the integration test phase, a test case should be constructed for the data transmission and structure skew issues during system integration; in the system test phase, you need to construct a test case that combines one or more functions of a function, or use a test case that has been verified on similar products. Test cases can be reused. In addition, there are a wide variety of test cases during large-scale software development, which should be managed in a certain way. Using databases to manage test cases is a good choice. Test Cases are divided according to the test phase, and then uniquely identified by keywords. This makes it easy to use, modify, and save test cases. You can call up test cases directly by querying them.

3. Numerical Control System Software Test
The numerical control system adopts the ARM7 processor and the operating system adopts the real-time operating system μC/OS. It is a typical embedded system. Due to the complexity of the numerical control system, tasks are divided in detail during the development process, and software development adopts modular development. Module division and data flow direction 7.

An association matrix can be constructed based on the software module and data flow direction shown in Figure 7, as shown in figure 8.

During the development process, several modules are respectively encoded by different programmers and tested by the programmers respectively, and covered by the white box test method. Finally, before the integration test, according to the association matrix, the programmer compiled the module interface function f (A1-A2), F (A1-A4), F (A1-A5), F (A1-A6), F (F2-A3), F (A3-A4), F (A4-A5), F (F5-A6), F (A6-A2 ), then, the system is tested based on the test model shown in Figure 6 and the association matrix shown in figure 8. The analysis shows that the coverage rate of some key modules, such as the decoding module and the knife complementing module, is above 90%. Figure 9 shows the stable performance of the entire system after testing. Figure 10 shows the parts processed by the system, which has been produced in small batches.

 

4 Conclusion
After analyzing the characteristics of embedded software and Traditional testing methods, this paper proposes a four-level testing process and an integrated testing model. This test method is used to test the Development of Engineering Machinery controllers and numerical control systems. The test efficiency and reliability meet the requirements. The methods of single-link data transmission, such as error locating, module interface functions, and association matrix, can also be used in object-oriented and object-oriented software systems.

Welcome to repost this article, please indicate the source of the article: Vince Testing Technology Research Center http://blog.csdn.net/vincetest