Abstract : Coverage testing is a crucial method for verifying the correctness of software functional structure and identifying problems. It requires specific tools to achieve good results and meet both quality and time requirements. Understanding and adapting mature tools is essential for effectively utilizing them. This paper takes the construction of a pure software-mode embedded software coverage testing environment using the Testbed testing tool and the LambdaPRO embedded software development platform as an example. It discusses the problems that need to be solved during the construction of this pure software-mode embedded coverage testing environment and its advantages and disadvantages. Keywords : Embedded system; Coverage testing; Instrumentation; Probe; Target machine; Historical information 0 Introduction Software testing is a broad concept. Considering its role throughout the entire software lifecycle, testing can be divided into module testing, integration testing, and system testing. Testing can be categorized into static inspection and dynamic runtime testing. Dynamic runtime testing can be further divided into white-box testing (or coverage testing) based on program structure and black-box testing based on functionality. Testing not only focuses on program functionality but also performance testing, stress testing, and so on. Coverage testing is a white-box testing method. Testers must have the program's specifications and listing, and design test cases based on the program's internal structure. Its basic principle is to use test cases to cover as much of the program's internal logic as possible to discover errors and problems. Therefore, coverage testing is generally applied in the early stages of software testing, namely the unit testing phase. Common coverage methods or strategies include: statement coverage, decision coverage, condition coverage, decision/condition coverage, and condition combination coverage. Other coverage strategies include: modified condition/decision coverage (often abbreviated as MCDC), path coverage, function coverage, call coverage, linear code sequence and jump coverage, data flow coverage, target code branch coverage, loop coverage, and relational operator coverage. As software scales, the number of test cases required to achieve comprehensive coverage becomes increasingly large. Therefore, selecting an appropriate coverage strategy based on the characteristics of the software under test is crucial. At the same time, reasonable testing objectives must be determined. Achieving 100% coverage often comes at a high cost and should be combined with methods such as formal review to discover more software faults. [Full text download of pure software model implementation for embedded software coverage testing]