2. • Soll alle Fehler finden
• Testzyklen in Nullzeit
• Verifikation klappt auf Anhieb
• Knappe Zeit
• Knappes Budget
• Häufige Änderungen
Die Schmerzen des Test-Managers
Wenn Sie hier sitzen, gehe ich davon, dass Sie zumindest einen Teil des hier dargestellten Anforderungsdrucks verspüren.
Wie kann man Systemtests automatisieren?Ganz außen an die echten Systemschnittstellen ranVorteile:Wir testen die Mechanik und gesamte Elektronik immer mit.Keinerlei Änderung am TestlingNachteile:Langsam, aufwendig und fehleranfällig.
Wie kann man Systemtests automatisieren?An die Signalleitungen gehenVorteile:Viel schneller und zuverlässiger.Nachteile:Testinstrumente beschaffen (aus der Testständen für funktionale Tests „ausleihen“)Simulation des Verhaltens der Peripherie kann ziemlich kompliziert seinElektronik muss Zugang ermöglichen (Leiterbahnen nicht im x-ten Layer)Eventuell bekommen die Systemtests den Charakter von Integrationstests. Ihre Aussagekraft muss plausibilisiert werden, zum Beispiel durch manuelle Systemtests oder Vergleich der simulierten mit der echten Peripherie usw.
Wie kann man Systemtests automatisieren?Treiber oder so mit Testschnittstelle patchenVorteile:Kein Ärger mit der Elektronik.Nachteile:Man braucht natürlich auch Infrastruktur zur Kommunikation mit dem Testling.Man testet nicht wirklich das was man ausliefern will.Geänderte Komponenten müssen parallel gepflegt werden.
Wie kann man Systemtests automatisieren?DfT – an vorhandenen Kommunikationskanälen („Testpunkten“)zwischen Treibern und Rest der Software angreifenVorteile:Software wird ohne Änderungen getestet.Nachteile:Nur mit DfT seitens der Softwaremachbar.Und natürlich auch hier Infrastruktur zur Kommunikation mit dem Testling nötig.
Wie kann man Systemtests automatisieren?Zusätzliche „Testpunkte“ inmitten der SoftwareVorteile:Schneller, weil Abkürzungen gegangen werden können.Schneller, weil Fehlerzustände frühzeitig entdeckt werden, nicht erst bei Fehlerwirkung.Nachteile:Tests brechen häufiger.
Wie kann man Systemtests automatisieren?In der Praxis wird man kombinieren.
Gerade die Automatisierung von Systemtests kann schwierig und teuer sein.Design forTestability – ein Begriff aus Elektronikentwicklung – kann Automatisierungskosten drastisch senken oder Testautomatisierung erst möglich machen.
Für den Test von Embedded Devices werden Testinstrumente zur Stimulierung und Messung des Testobjekts (ATE – automatedtestequipment) benötigt. Diese kann man fertig kaufen. Als Beispiel sieht man hier:Einen LabJack U3-HV: ein einfaches IO-Board, das per USB angeschlossen wird. Einfache Bedienung per .NET Schnittstelle.Daneben sieht man ein PXI-Testsystem. PXI ist ein standardisiertes Format für Gehäuse und Steckkarten und stammt aus dem Bereich der Produktionsautomatisierung.Meistens wird noch eine elektrische Adaptierung benötigt, siehe auch nächstes Bild.
Wir ziehen die hier die Anzahl von Testläufen heran, die ohne Automatisierung durchgeführt werden würden.Wir berechnen daherden minimalen ROI der Automatisierung – das spart man auf jeden Fall durch die Automatisierung.Manche ziehen stattdessen die Anzahl der automatisierten Durchführungen heran.Das übersteigert den Nutzen der Automatisierung.Andererseits sind viele Vorteile der Automatisierung bei dieser Berechnung nicht eingepreist.Diese Vorteile sind auch sehr schwierig zu quantifizieren oder vorherzusagen.
Und was wenn die Tester (die keine Entwickler sind) die Komponententests schreiben müssen?
Die Entwicklung kann die Verifizierungstests automatisieren unabhängig davon, ob die IV&V die Verifizierungstests manuell oder automatisiert durchführt.Damit hat die Entwicklung regelmäßig eine Vorschau das Verifizierungsergebnis minus nicht automatisierbarer Verifizierungstests.Bei einem roten Verifizierungstests droht nämlich im Allgemeinen nach der Fehlerbehebung eine vollständige Wiederholung statt wie während der Entwicklung üblich einem partiellem Regressionstest.Das Resultat ist ruhiger Schlaf für das Entwicklungsteam weitgehend ohne Angst vor einem Durchfallen bei der Verifizierung.Die IV&V kann die Verifizierung mit automatisierten Verifizierungstests durchführen.Gründe dafür können der Zeitdruck am Ende der Entwicklung oder aber auch die Kosten für Wiederholungen bei Fehlschlägen der Verifizierung oder bei Aktualisierungen der Software sein.Dazu kann die von der Entwicklung produzierte Test-Infrastruktur wiederverwendet werden.Voraussetzung ist aber meist eine Prüfmittel-Validierung der Test-Infrastruktur.Zudem muss auf den geänderten Fokus „Test toverify“ während der Verifizierung statt „testto kill“ während der Entwicklung geachtet werden.
Lassen Sie Systemtests nicht Ihr einziges Mittel sein.Machen Sie Gebrauch von Komponenten- und Integrationstests als Bestandteil Ihrer Test-Strategie.Problem bei Unit Tests: kodierende Tester, testende Entwickler?
Wenn das Budget nicht reicht und man zu wenig Systemtests hat, braucht man über andere Teststufen nicht nachdenken.Wenn das Budget aber reicht, kann man die Testtiefe überproportional steigern, indem man etwas von dem Budget in Komponenten- und Integrationstests investiert.
Untere Teststufe bilden jeweils Fundament der nächsten Teststufen.Nach unten hin sinkt der Aufwand pro Test und steigt die Anzahl der Tests.Obere Teststufen prüfen stichprobenartig Ergebnisse der unteren Teststufen, haben aber prinzipiell anderen Fokus als untere Teststufe.Komponententests prüfen Verhalten einzelner Komponente, finden eher lokale Fehler in der Komponente.Integrationstests prüfen Zusammenspiel der Komponente, finden eher Schnittstellenprobleme.Durchaus realistisch mehrere Integrationsstufen zu haben.
Systemtests habe auch ihre Vorteile.Systemtests müssen trotzdem sein.
Gehört unbedingt ins Arsenal gegen BugsFindet Bugs, die man mit Tests kaum findetFortgeschrittene Verfahren reduzieren Falschmeldungen
Vorteile von Reviews:Fehlererkennung sehr frühKosten/Nutzen-Verhältnis sehr gutErfolgsrezepte:Nicht die Zeit der Beteiligten mit unwichtigen Details verschwenden. Review-Objekte optimal vorbereiten (Spell Check, Formatierung von Code, Überprüfung von Kodierungsregeln).Inhaltliche Fehler suchen, nicht nur Formfehler.Für das challenging muss man sich nicht endlos tief einlesen: hast Du an X gedacht?Eventuell mit Tool unterstützenWenn Reviews im regulierten Umfeld zwangsweise gemacht werden müssen:Reviews zum Nutzen der Entwicklung einsetzen und nicht als (reine) Pflichtübung ansehen.