In embedded engineering, the behavior of functions often depends on the state of peripherals, the contents of registers, and various system flags. To verify whether a function maintains stable performance under different conditions, a tool is needed that can replicate the operating environment, manage scenario changes, and record execution details. Tessy is suitable for handling such tasks; once the project is prepared, testing can gradually cover more scenarios. Below, I will break down the testing of embedded functions into two parts: “How to Execute Tests” and “How to Prepare the Testing Environment,” helping everyone establish a more robust verification method during project advancement.
EditSearch Image
Please click to enter image description (up to 18 characters)
1. How to Test Embedded Functions: Clarifying Operating Conditions
Embedded functions are usually sensitive to inputs, variable states, and peripheral behaviors, so it is necessary to record the conditions required for function execution more comprehensively during testing.
1. Ensure the project compiles correctly in the current environment
Tessy completes testing through compilation and execution, so the project setup must be complete. After entering the software, open 【Settings】→【Compiler Setup】 in the menu, select the toolchain used by the project, and fill in the header file paths, macro definitions, and peripheral-related declaration files. If the project lacks these elements, the test code will directly report errors during generation.
2. Supplement external variables required for function execution
Embedded functions frequently read global flags, status bits, or communication counters. To make the tests more reflective of actual usage conditions, these variables can be added in the 【Init Variables】 section of the test case window, setting different initial values based on the operating scenario, such as whether the device is ready, whether error flags are cleared, and whether the receive buffer has data.
The execution judgment of the function often relies on these states, so the accuracy of these value settings significantly impacts the results.
3. Establish test scenarios for different situations
Create several test cases in 【Test Cases】 to allow the function to run under more conditions. For example, variations of normal inputs, values close to boundaries, abnormal values, and error flag set states. Tessy will independently save these scenarios, allowing them to be executed one by one or all at once during runtime.
This way, testing can cover more logical branches rather than just verifying the most common cases.
4. Execute and analyze results
After running the test cases, you can see the function’s inputs, return values, and variable changes in the 【Results】 interface. The coverage interface 【Coverage】 will show which statements and branches were triggered. If a certain logic segment remains untriggered for a long time, it may require additional test cases or a re-examination of input conditions.
Through result records and coverage information, one can gain a more intuitive understanding of the function’s performance under different conditions.
2. How to Prepare the Testing Environment: Making the Execution Process Closer to the Real System
For embedded projects, whether the testing environment is reasonable directly affects the credibility of the execution results. In addition to the function itself, the surrounding operating conditions should be made as consistent with the real system as possible.
EditSearch Image
Please click to enter image description (up to 18 characters)
1. Organize the project structure to clarify dependencies
Embedded projects often have a large number of files, and the path relationships can be complex. If the directory structure is too messy, testing will frequently encounter “file not found” or “invalid path” errors. You can maintain a unified include directory in the development project, create separate folders for common modules, and use a consistent structure in the testing project to allow the software to correctly analyze dependencies.
The more stable the paths, the less effort required for subsequent maintenance.
2. Provide alternative behaviors for hardware-related functions
During testing, if real hardware cannot be accessed, many driver functions need to be simplified with alternative behaviors. Enter 【Stub Settings】 to set fixed return values or lightweight judgment logic for dependent functions, allowing the main function’s business process to run smoothly. For example, returning a set value when reading a register or simulating success or failure during communication interface calls.
There is no need to fully simulate hardware; just ensure that the function’s judgment process can continue.
3. Pre-set system states to make scenarios closer to real conditions
Whether the function is initialized before execution, whether error flags are cleared, and whether counters reach thresholds can all affect results. Different variable states can be set in different test cases to verify the function’s performance under various system conditions.
The closer the testing is to actual operating conditions, the more valuable the results will be.
4. Use coverage information to determine if additional tests are needed
The coverage page shows whether the function’s statement branches have been touched. If certain logic remains untriggered for a long time, it is likely necessary to add new scenarios or check whether the dependent behaviors are correctly simulated. Coverage information is not only an indicator for project acceptance but also an important basis for completing functional logic.
3. Making the Testing Project Suitable for Long-Term Use
Embedded projects typically have long cycles, and if the testing content is organized properly, subsequent version maintenance will be much smoother.
1. Organize test cases by function and scenario for clearer structure
Separate normal inputs, boundary inputs, and abnormal scenarios for easier identification of the scenarios that need to be checked each time code is modified.
2. Maintain a stable project directory to reduce the workload of repeated path fixes
Path changes can affect all test cases in the project; maintaining a fixed directory structure can reduce unnecessary maintenance costs.
3. Use execution records and coverage information to assist in troubleshooting
Each run’s records are kept in the project, including inputs, return values, and variable changes. As the number of runs increases, these records will become important references for understanding module behavior and tracking issues.
EditSearch Image
Please click to enter image description (up to 18 characters)
Conclusion
In embedded projects, function testing relies more on the environment, states, and behaviors of dependent modules, rather than just the inputs themselves. The structure of the project, global variables, peripheral states, and the settings of alternative functions all affect the final results. By organizing these conditions more comprehensively, the testing process will gradually align with the actual operating methods of the system, and it will also reduce regression costs as the project scales up.
TESSY authorized distributor – Makeding Software
Website: https://www.tessy.net.cn/Phone: 18015636924Email: [email protected]