2010-05-23 4 views
6

Ich habe ein kleines Betriebssystem für das eingebettete Projekt auf kleinen bis mittleren Ziel geschrieben.Wie kann ich die Zuverlässigkeit meines eigenen (kleinen) Embedded-Betriebssystems testen?

Ich habe einen automatisierten Komponententest mit einer hohen Testcodeabdeckung (> 95%) hinzugefügt, aber der Bereich ist nur der statische Teil.
Ich habe einige Code-Metriken als Komplexität und Lesbarkeit.
Ich teste meinen Code mit einem Regelprüfer mit MiSRA-Unterstützung, und natürlich alle Warnungen behoben.
Ich teste den Code mit einem statischen Analysator und wieder alle Warnungen behoben.

Was kann ich jetzt tun, um testen - und verbessern - die Zuverlässigkeit meines Betriebssystems? Wie wäre es mit dem dynamischen Teil?

+0

Es ist zu diesem Zeitpunkt keine Option, die Leute tatsächlich zu benutzen? –

+0

@Tim Beitrag: Ja, 2 Projekte laufen es ... aber ich muss einige Informationen über die Zuverlässigkeit geben! Ich habe nur den statischen Teil getestet. – TridenT

+0

Ist dies ein textbasiertes Betriebssystem? –

Antwort

1

Versuchen Sie, einige Komponententests für den dynamischen Teil zu schreiben. Führen Sie anschließend die Tests auf der Zielhardware aus. Führen Sie die Tests für Hardware mit mehreren Kernen aus. Führen Sie die Tests für Hardware mit nur einem Kern aus

Variieren Sie Zielsystemtaktgeschwindigkeit und führen Sie die dynamischen Tests aus.

sollte die meisten Timing-Probleme ausschütteln.

+0

Vielleicht ist es die einzige Lösung! Aber Schreib Einheit/Integration Test mit Timing-Auswertung, auf dem Ziel, mit mehreren Kernen ... Ich werde Komponententest während 10 Jahren schreiben?!? – TridenT

+0

Führen Sie die dynamischen Tests auf dem Ziel aus. (1) Experiment Führen Sie die dynamischen Tests auf Entwicklungshardware mit mehr oder weniger Kernen (2) Experimente. Auf Ziel mit unterschiedlicher Taktrate (1) experimentieren. Insgesamt 5 Experimente. –

1

Überprüfen Sie die software-testing entry on wikipedia. Es ist eine ziemlich umfassende Beschreibung der verschiedenen Prüfungszweige. Vielleicht finden Sie dort eine oder zwei neue Ideen.

+0

Es ist ein interessanter Anfang, aber ich weiß nicht, wie ich mit dem dynamischen Verhalten meines Betriebssystems umgehen soll. Ich werde dem Link zur Untersuchung folgen! – TridenT

2

Dinge in der Liste fehlt:

  • Wenn Sie nicht bereits dann laufen tut es auch die Unit-Tests auf der Zielhardware, Compiler und Hardware-Probleme zu prüfen.

  • Code-Reviews, überprüfen insbesondere für Rennbedingungen

Sie auch den erzeugten Assembler-Code überprüfen könnte, wenn sie nicht zu groß ist.

+0

Code Bewertungen sind gut, aber es ist "One Shot".Die Überprüfung für den Assemblercode wurde teilweise durchgeführt, aber welche Ergebnisse sollte ich zeigen? – TridenT

1

Versuchen Sie Atomic Object's Website. Versuchen Sie this also..

Auch James Greening.

+0

Mock Technik ist ziemlich schwierig in C (das Betriebssystem ist in C + ASM geschrieben) und schwer im Vergleich zu C++. Aber es könnte die einzige Lösung sein! – TridenT

+0

Ich glaube, dass sie Code-Generierung auch viel verwenden. – Gutzofter

1

Scheint so, als ob Sie viel getan haben, um Ihr System zu testen. Ich denke, der nächste Schritt würde andere Projekte oder Leute dazu bringen, sie zu benutzen. Andere Benutzer würden schnell zeigen, dass Sie Robustheitsprobleme haben.

+0

ja, und sie bitten bereits um eine bessere Benutzerdokumentation :) – TridenT

Verwandte Themen