Wie sollten wir Komponententests und Systemtests für ein Programm organisieren, das eine Hardware emuliert (das ist wie vmWare)?
Hintergrund:
Wir haben seit vielen Jahren einen Computer aus den 1980er Jahren und zugehörige Peripheriegeräte und Software verwaltet. Das System ist für unsere Kunden wichtig und sie wollen es nicht ersetzen. Wir haben uns daher entschieden, Emulatoren für einige der Hardware zu entwickeln. Das Problem ist, dass es in vielen tausend Seiten Schreibmaschinen geschriebener Text schlecht dokumentiert ist. Es ist daher Versuch und Fehler-Entwicklung.
Das Problem:
Wir haben derzeit keine Komponententests des Emulators und die Systemtests sind sehr add-hock. Es ist schwierig zu testen, ob ein komplexes Betriebssystem in allen Aspekten funktioniert, indem Sie das Text-Terminal eingeben und die Dateneingabe von externen Systemen simulieren. Der einzige Weg, den wir gerade testen, ist, einen großen Eingangsdruck von externen Systemen (über X.25) hinzuzufügen und einige schwere Operationen regelmäßig zu automatisieren. Aber du vermisst es so sehr.
Ich habe früher für eine Firma gearbeitet, die etwas Vergleichbares macht. Um unser System zu testen (das eigentlich ein dynamischer Binär-Übersetzer, kein Emulator war), haben wir ein Testframework geschrieben, das die gleichen Befehle nativ und übersetzt ausführt und dann die Ergebnisse vergleicht. Wir begannen damit mit Userspace-Programmen, aber als wir anspruchsvollere Produkte entwickelten, verwendeten wir die gleichen Techniken, um das Testen von emulierter Hardware zu automatisieren. Grob gesagt, wollen Sie einige Programme schreiben, die auf diese Hardware zugreifen und alles erledigen, indem Sie die gesamte Ausgabe an das Terminal oder ein Log irgendwo ablegen. Führen Sie dann diese Programme auf beiden Seiten (real und emuliert) aus und vergleichen Sie die Ausgabe. Abhängig davon, wie genau Ihre Emulation sein soll, müssen Sie möglicherweise einige Skripte verwenden, um bestimmte Teile der Ausgabe zu ignorieren - Adressen, Hostnamen, diese Art von Dingen.
Die andere Sache, auf die man beim Emulieren von Hardware achten sollte, sind Zustandsänderungen: Ein bestimmter Befehl könnte auf beiden Seiten die gleiche Ausgabe ergeben, aber den internen Zustand auf verschiedene Arten ändern. Dies kann schwer zu antizipieren sein, aber im Allgemeinen müssen Sie den betroffenen internen Zustand identifizieren und zusammen mit der Ausgabe für jeden Befehl ausgeben.
Bevor wir gekauft wurden, begannen wir mit der Arbeit an etwas noch Klügerem, indem wir Kernel-Tracing-Tools zur schrittweisen Überwachung des Betriebssystem- / Hardwarezustands bei unseren Tests verwendeten und dann die Abfolge der Schritte zwischen nativen und übersetzten Läufen verglichen. Dies wurde nie vollständig entwickelt, sah aber sehr vielversprechend aus.
Leider waren all diese Sachen intern und closed-source, also kann ich Sie nicht auf etwas hinweisen, mit dem Sie rennen und spielen können, aber die Idee ist sehr solide - wir hatten tausende von automatisierten Tests wie diese auf jedem Build von unsere Übersetzer mit sehr zufriedenstellenden Ergebnissen.
Edit: Je mehr ich über dieses Problem nachdenke, desto mehr freue ich mich darüber. Ich nehme nicht an, dass Ihr Projekt Open Source ist, aber wenn es so wäre, würde ich gerne mitmachen. Fühlen Sie sich frei, mich zu kontaktieren, wenn das eine Möglichkeit ist.
Tags und Links unit-testing c++ testing automated-tests emulation