Current project I’m working on benefits from automated test suite run on few Linux-based devices. Tests are running 24×7, but sometimes device hangs (reason is still under investigation) and SSH access is blocked then.
In order to track the problem I redirected syslog (busybox-based, BTW) via network and added local automatic monitoring service that will show me when a part of my test installation go down.
My current project I’m working on is based on embedded systems and QT platform. Of course the very first task in the project is to implement some kind of testing method to get feedback on software quality. The test system is composed from few components:
First channel collects all crashes (from human and automated tests), second channel is performed fully automatically. Second channel allows to measure MMTF (mean time between failures) and analyse changes in time, probably helping with estimating current software quality state.
Second testing channel requires automatic test driver to inject random UI events (key presses, remote in my case). I used QT message queue for that purpose:
Collecting runtime errors (crashes, failed assertions, …) is very important part of software quality efforts. If you know crash details from your testing team you can handle them even before a tester writes first line of error report (!). That improves development speed.
Probably the fastest method how to create KISS (Keep It Simple Stupid) central crash report repository is to use:
When a QT warning is issued you might not know what code is causing activation of this warning. Warnings are not fatal, application is not stopped with proper backtrace.
QT creators added very useful option for that purpose: QT_FATAL_WARNINGS. If you set:
export QT_FATAL_WARNINGS
You will be correct backtrace under gdb that allow to locate the problem. Application will abort as soon as first QT warning is located.
Java does it pretty well. C++ sucks by default. What is that?: The answer: Backtraces.
Sometimes assert information (file name and line number where assertion occured is not enough to guess where the problem is. It’s useful to see the backtrace (stack trace in Java vocabulary) of calling methods/functions. You can achieve that in C++ using gdb (and analysing generated core files or run the program under debugger), but it’s not a “light” (and elegant) solution (especially for embedded systems).
I’m presenting here a method to collect as meaningful backtraces in C++ as possible. Just link to module below and you will see pretty backtraces on abort/assert/uncaught throw/…
Powered by WordPress