Top 10 tips for embedded software testing

In the embedded software development process, generally, the time spent on testing and coding is (in fact, more ), this ratio keeps decreasing as your programming and testing level increases,

In the embedded software development process, generally, the time spent on testing and coding is (in fact, more ), this ratio keeps decreasing as your programming and testing level increases. However, software testing is very important to the average person, many years ago, to have a deeper understanding of embedded systems, a developer asked Oracle How can I know and understand what my system is doing?

Oracle was a little surprised at this problem, because no one asked this question at the time, most of the questions asked by contemporary embedded developers are superficial questions such as "How can I make the program run faster" and "what compiler is best. Therefore, in the face of this unusual but almost mature question, Oracle is delighted and seriously replied to him: Your question is very deep and mature, because it is possible to continuously improve the level of understanding. To encourage the persistent programmer, Oracle told him 10 tips about embedded software development and testing:

1. understand how to use tools

2. detect memory problems as soon as possible

3. in-depth understanding of code optimization

4. do not make yourself haystack

5. reproduce and isolate problems

6. backward

7. determine test integrity

8. improving code quality means saving time

9. discover it, analyze it, and solve it.

10. use the beginner's thinking

These 10 secrets have been widely spread in the industry, benefiting many people. This article focuses on these 10 tips.

1. understand how to use tools

Generally, embedded systems have high requirements on reliability. The failure of security of embedded systems may lead to disastrous consequences. even if it is a non-secure system, mass production may cause serious economic losses. This requires strict testing, validation, and verification of embedded systems, including embedded software. As more and more fields use software and microprocessor to control a variety of embedded devices, it is increasingly important to quickly and effectively test the increasingly complex embedded software.

Just like the tools needed for car repair, good programmers should be able to use various software tools skillfully. Different tools have different application scopes and functions. With these tools, you can see what your system is doing, what resources it occupies, and what external things it is dealing. A tool may help you easily solve problems that have been depressing for several days. Unfortunately, you just don't know. So why do so many people always think of using test tools after they get stuck? There are many reasons. There are two main reasons. One is fear, and the other is inertia. Fear is that it requires skills to add test tools or test modules to code, and new errors may be introduced, so they always prefer to eliminate bugs by constantly modifying the re-compilation code, the results do not help. Lazy because they are used to simple testing methods such as printf. The following describes some common embedded testing tools.

◆ Source code-level debugger [Source-levelDebugger]

This type of Debugger generally provides single-or multi-step debugging, breakpoint setting, memory detection, variable viewing, and other functions. it is the most fundamental and effective debugging method for embedded debugging. For example, gdb provided by VxWorksTornadoII belongs to this type.

◆ Simple and practical printing and display tool [printf]

Printf or other similar printing and display tools are estimated to be the most flexible and simple debugging tools. Printing various variables during code execution allows you to know the code execution status. However, printf imposes a lot of interference on normal code execution (generally, printf occupies CPU for a long time) and needs to be used with caution. it is best to set the print switch to control printing.

◆ ICE or JTAG debugger [In-circuitEmulator]

ICE is a device used to simulate the CPU core. it can detect the internal operation of the CPU in real time without interfering with the normal operation of the timer. Similar to the features provided by the desktop debugging software: complex conditional breakpoints, advanced real-time tracking, performance analysis, and Port analysis. ICE generally has a special CPU, called a bond-out CPU. This is a type of encapsulated CPU that can be accessed through special connections to the internal signal of the CPU. when the CPU is encapsulated, you cannot "see. When used together with powerful debugging software on the workstation, ICE provides the most comprehensive debugging function you can find. However, ICE also has some disadvantages: expensive; cannot work at full speed; likewise, not all CPUs can be used as external CPUs. from another perspective, these external CPUs are unlikely to be promptly replaced by new CPUs.

Although JTAG (JointTestActionGroup) was initially developed to monitor IC and circuit connections, this serial interface extends its use, including support for debugging.

◆ ROM monitor [ROMMonitor]

A rom monitor is a small program that resides in the embedded system ROM and communicates with debugging software running on the workstation through a serial or network connection. This is a cheap method, and of course the lowest-end technology. In addition to a communication port and a small amount of memory space, it does not require any dedicated hardware. It also provides the following functions: download code, run control, breakpoint, one-step, and observe and modify registers and memory. Because the ROM monitor is part of the operating software, it only works when your application is running. If you want to check the CPU and application status, you must stop the application and go to the ROM monitor again.

◆ Data monitor [DataMonitor]

When the CPU is not stopped, the monitor not only displays the specified variable content, but also collects and graphically displays the variation process of each variable.

◆ OS monitor [OperatingSystemMonitor]

The OS monitor displays events such as task switching, semaphore sending and receiving, and interruption. On the one hand, these monitors can present the relationship and time relationship between events. on the other hand, they can also provide a diagnosis for problems such as Semaphore priority reversal, deadlock, and interruption latency.

◆ Performance analysis tool [Profiler]

It can be used to test the CPU consumption. The profiler tool lets you know where the system bottleneck is, CPU usage, and where optimization is needed.

◆ Memory test tool [MemoryTeseter]

You can find out the memory usage problems, such as memory leakage, memory fragmentation, and memory crash. If you find that the system has some unpredictable or intermittent problems, you should use the memory testing tool for testing.

◆ Run the tracker [ExecutionTracer]

It can display the functions executed by the CPU, who is calling, what are the parameters, and when to call them. This tool is mainly used to test the code logic and detect exceptions in a large number of events.

◆ Overwrite tool [CoverageTester]

It mainly shows the code executed by the CPU and lets you know that the code branches are not executed. This helps improve code quality and eliminate useless code.

◆ GUI testing tool [GUITester]

Many embedded applications have some form of graphical user interfaces for interaction. some system performance tests are performed based on the user input response time. GUI testing tools can be used as script tools to run test cases in the development environment, its functions include recording and playback of operations, capturing screen display for future analysis and comparison, setting and managing the test process (the Rational robot and Mercury Loadrunner tools are outstanding representatives ). Many embedded devices do not have a GUI, but they can often insert embedded devices to run GUI test scripts. Although this method may require changes to the tested code, however, it saves time for functional testing and regression testing.

◆ Homemade tool [Home-madetester]

In embedded applications, sometimes some tools need to be compiled for specific purposes to achieve certain testing purposes. The video stream recording and display tool I have compiled has helped the company find several hidden bugs by helping to test the stream direction and changes of video conferences.