- ros community empfiehlt unit, integration und regression testing
- schnellere inkrementelle updates (probleme von kleinen änderungen direkt gefunden)
- refactoring verlässlicher da direkt getestet
- besseres code design, da gezwungen code testbar zu schreiben -> funktionen und framework separat gehalten
- wiederkehrende bugs werden verhindert
weitere http://wiki.ros.org/action/show/Quality/Tutorials/UnitTesting?action=show&redirect=UnitTesting
- lücke zwischen testdaten in simulation und echten daten bei echtem roboter
-> RUT kann Lücke verkleinern, nicht schließen
- manuelle testmethoden wie program inspection werden nicht betrachtet, nur automatisches testen
- Test Kategorisierungen
- white box testing: internes arbeiten des komponenten bekannt; black box: nicht bekannt
- funktional oder nicht-funktional
- scope: unit tests testen fragmente, integration tests testen interaktion der fragmente
- zweck: fehler finden, API verifizieren ODER als Teil des Entwicklungsprozesses (Test-Driven-Development)
RUT Requirements:
- basiert auf Simulationen die Sensoren und Aktoren ausreichend gut darstellen können
- ausreichend bedeutet zu testende aufgabe wird mit gleicher wahrscheinlichkeit erfolgreich real und simuliert ausgeführt
- gut designte software architektur -> mehrere abstraktionsschichten
- präferiert: datenfluss kann ohne direkte softwareänderungen verändert werden (runtime statt compiletime)
- glücklicherweise state of the art in Akademie und wird momentan standard in industrie
RUT:
- tests robots, not just their isolated software components
-> testen gegen höchstes abstraktionslayer
- jeder RUT sollte eigenständig ausgeführt werden können, unabhängig von anderen RUTs
-> tests können idealerweise parallel laufen indem jede test instanz eine andere simulator instanz verwendet, ansonsten zurücksetzen nach jedem test (sequentiell ablaufen)
- aktor und sensordaten können je nach notwendigkeit sehr oft oder grob aufgezeichnet werden
- erfolg oder fail sehr abhängig davon was als ausreichend genau angesehen wird -> momentane simulationen schon sehr genau tendenz steigend
RUT Kosten:
- relativ kleiner implementierungsaufwand: input kreieren, interface aufrufen, ergebnis mit gewünschtem vergleichen
-> Modelle zum Simulieren oft bereits vorhanden (z.B. CAD Modelle vorhanden durch bauen des roboters)
-> Simulationen wie Gazebo MORSE, V-Rep stellen viele aktoren und sensoren zur verfügung
- aufwand groß falls simuliertes objekt (z.b. sensor) nicht verfügbar oder nicht das nötige interface besitzt
Chung2007 software testing for intelligent robots
-charakteristik zu software qualität findet sich in ISO 9126 https://de.wikipedia.org/wiki/ISO/IEC_9126
-vorgeschlagenes test case design basierend auf nutzerbedürfnissen:
- user requirements identifizieren
- test szenario designen
- so viele szenarien bis alle requirements gedeckt sind
- test cases designen die szenario überprüfen (hinsichtlich ISO 9126)
lim2010automated An Automated Test Method for Robot Platform and Its Components
Santos2018 Property-Based Testing for the Robot Operating System
-komponenten als black box betrachtet
-nutzen einer Property-Based Testing Library zum finden einer sequenz von inputs (ros topics) die vorgegebene Eigenschaft(en) invalidiert oder System crasht
PBT: properties meist verhältnis zwischen input und output (z.B. reverse von reverse von liste gibt liste zurück)
- formalere beschreibung des zu testenden systems nötig statt nur beispielszenarien
+ inputs werden automatisch ausgewählt (potentiell auch generiert) (-> -potentiell redundante tests)
Zusammenfassung:
- hilft bisher nicht gesehene fehler zu entdecken
- nicht zum grundständigen Testen geeignet (durch Zufallskomponente oder schwierige formale beschreibung), eher als Ergänzende Testmethode
Ernits2015 Model-based integration testing of ROS packages:a mobile robot case study
- RUT Ansatz mit white box metrik statement und branch coverage kombiniert mit model basiertem testing
Model based testing:
-basiert auf modell dass beschreibt wie sich das system verhält -> Testfälle lassen sich ableiten
Pueschel2018 Testing Self-Adaptive Systems: A Model-based Approach to Resilience
Abschnitt 2.2 Model-based Testing
Klassifizierungen: -statisches Testen (z.b. reviews oder mit tools) oder dynamisch (ausführung des Systems mit Testfällen)
-grey-box (zwischen white box und black box) tests werden designt wie black-box aber mit wissen über interne funktionsweise