views:

179

answers:

5

I've written a small operating system for embedded project running on small to medium target.

I added some automated unit test with a high test code coverage (>95%), but the scope is only the static part.
I got some code metrics as complexity and readability.
I'm testing my code with a rule checker with MiSRA support, and of course fixed all warnings.
I'm testing the code with a static analyzer and again fixed all warnings.

What can I do now to test - and improve - the reliability of my OS ? How about the dynamic part ?

+1  A: 

Check out the software-testing entry on wikipedia. It's a rather comprehensive description of the different branches of testing. You might find a new idea or two there.

bitc
It's an interesting start, but I don't know how to handle the dynamic behavior of my OS. I will follow the link for investigation !
TridenT
+1  A: 

Things missing in your list:

  • If you are not already doing it then also run the unit tests on the target hardware, to check for compiler and hardware issues.

  • Code reviews, check especially for race conditions

You could also review the generated assembly code, if it is not too big.

starblue
Code reviews are good, but it's 'one shot'. The review for assembly code was partially done, but what results should I show ?
TridenT
+1  A: 

Try Atomic Object's site. Try this also..

Also James Greening.

Gutzofter
Mock technic is rather difficult in C (the OS is written in C + ASM) and heavy compared to C++. But it might be the only solution !
TridenT
I believe they use code generation a lot also.
Gutzofter
+1  A: 

Try writing some unit tests for the dynamic part. Then run the tests on the target hardware. Run the tests on hardware with more cores Run the tests on hardware with only one core

Vary target system clock speed and run the dynamic tests.

should shake out most timing issues.

Tim Williscroft
Maybe it's the only solution ! But write unit / integration test with timing evaluation, on the target, with multiple cores ... I will write unit test during 10 years ?!?
TridenT
Run the dynamic tests on the target. (1) experimentrun the dynamic tests on development hardware with more or less cores (2) experiments. Run on target with different clock speed (1) experiment. A total of 5 experiments.
Tim Williscroft
+1  A: 

Seems like you have done a lot to test your system. I think the next step would get other projects or people to use it. Other users would quickly show you were robustness problems are.

Gerhard
yes, and they already ask for a better user documentation :)
TridenT