Skip to content
Snippets Groups Projects
Commit d45e9ba2 authored by cs-99's avatar cs-99
Browse files

No commit message

No commit message
parent d1bcb426
No related branches found
No related tags found
No related merge requests found
...@@ -252,4 +252,3 @@ TSWLatexianTemp* ...@@ -252,4 +252,3 @@ TSWLatexianTemp*
# this thesis # this thesis
thesis.pdf thesis.pdf
notizen.txt
\ No newline at end of file
...@@ -8,6 +8,7 @@ ...@@ -8,6 +8,7 @@
doi = {10.1145/1660877.1660890}, doi = {10.1145/1660877.1660890},
file = {:1660877.1660890.pdf:PDF}, file = {:1660877.1660890.pdf:PDF},
publisher = {{ACM} Press}, publisher = {{ACM} Press},
readstatus = {skimmed},
} }
@Book{Bihlmaier2014, @Book{Bihlmaier2014,
...@@ -45,7 +46,7 @@ ...@@ -45,7 +46,7 @@
file = {:2370216.2370410.pdf:PDF}, file = {:2370216.2370410.pdf:PDF},
publisher = {{ACM} Press}, publisher = {{ACM} Press},
ranking = {rank2}, ranking = {rank2},
readstatus = {read}, readstatus = {skimmed},
} }
@Article{lim2010automated, @Article{lim2010automated,
...@@ -73,20 +74,6 @@ ...@@ -73,20 +74,6 @@
readstatus = {read}, readstatus = {read},
} }
@Article{Haddadin2009,
author = {Sami Haddadin and Alin Albu-Schäffer and Gerd Hirzinger},
journal = {The International Journal of Robotics Research},
title = {Requirements for Safe Robots: Measurements, Analysis and New Insights},
year = {2009},
month = {aug},
number = {11-12},
pages = {1507--1527},
volume = {28},
doi = {10.1177/0278364909343970},
file = {:0278364909343970.pdf:PDF},
publisher = {{SAGE} Publications},
}
@Article{Utting2011, @Article{Utting2011,
author = {Mark Utting and Alexander Pretschner and Bruno Legeard}, author = {Mark Utting and Alexander Pretschner and Bruno Legeard},
journal = {Software Testing, Verification and Reliability}, journal = {Software Testing, Verification and Reliability},
...@@ -99,6 +86,7 @@ ...@@ -99,6 +86,7 @@
doi = {10.1002/stvr.456}, doi = {10.1002/stvr.456},
file = {:stvr.456.pdf:PDF}, file = {:stvr.456.pdf:PDF},
publisher = {Wiley}, publisher = {Wiley},
readstatus = {skimmed},
} }
@InProceedings{Hansel2015, @InProceedings{Hansel2015,
...@@ -110,6 +98,7 @@ ...@@ -110,6 +98,7 @@
publisher = {{IEEE}}, publisher = {{IEEE}},
doi = {10.1109/sasow.2015.27}, doi = {10.1109/sasow.2015.27},
file = {:07306570.pdf:PDF}, file = {:07306570.pdf:PDF},
readstatus = {skimmed},
} }
@InProceedings{Gonzalez2018, @InProceedings{Gonzalez2018,
...@@ -121,6 +110,31 @@ ...@@ -121,6 +110,31 @@
publisher = {{ACM}}, publisher = {{ACM}},
doi = {10.1145/3239372.3239409}, doi = {10.1145/3239372.3239409},
file = {:3239372.3239409.pdf:PDF}, file = {:3239372.3239409.pdf:PDF},
ranking = {rank1},
readstatus = {skimmed},
}
@InProceedings{Ernits2015,
author = {Juhan Ernits and Evelin Halling and Gert Kanter and Juri Vain},
booktitle = {2015 European Conference on Mobile Robots ({ECMR})},
title = {Model-based integration testing of {ROS} packages: A mobile robot case study},
year = {2015},
month = {sep},
publisher = {{IEEE}},
doi = {10.1109/ecmr.2015.7324210},
file = {:07324210.pdf:PDF},
ranking = {rank1},
readstatus = {read},
}
@PhdThesis{Pueschel2018,
author = {Georg Püschel},
school = {Technische Universität Dresden},
title = {Testing Self-Adaptive Systems: A Model-based Approach to Resilience},
year = {2018},
file = {:testing_self-adaptive_systems.pdf:PDF},
ranking = {rank4},
readstatus = {read},
} }
@Comment{jabref-meta: databaseType:bibtex;} @Comment{jabref-meta: databaseType:bibtex;}
Bihlmaier2014 Robot Unit Testing
- 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
-hierarchisches test model:
-System testing (Software Component)
-Integration Testing (Hardware API)
-Unit Testing (Hardware)
-grenzwert analyse, äquivalenzklassen tests, entscheidungstabellen
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
-Testorakel beschreibt vorrausgesagten Output (für bestimmten Input)
-kann komplettheit und genauigkeit beinhalten
-kann bei komplexen systemen nur sehr beschränkte teilmenge aller input-output paare beschreiben
-> beim test development müssen kriterien angegeben werden, die spezifizieren wann test erfolgreich war
-typischerweise werden inputs in äquivalenzklassen sortiert und grenzwertanalyse durchgeführt
-> grenzen der äquivalenzklassen werden getestet da sich dort häufig fehler finden
-> -abhängigkeiten zwischen den inputs werden nicht beachtet
-testausführung kann automatisiert werden
-> test design (blackbox tests) automation möglich durch Model Based Software Design
-> sinnvoll für context-abhängige komplexe (self-adaptive) systeme
-> MBT möglich auf allen testebenen, aber nicht kompatibel mit white box testing, da MBT nur externen status überprüft
-> erwartetes verhalten wird in modellen beschrieben, mit denen automatisch test-fälle generiert werden
Model-based Testing Prozess:
1. Modell erstellen. Modell muss Anforderungen des Systems widerspiegeln. Aufwand und Granularität werden in einem "test plan" kontrolliert
-Modell kann durch nicht angegebene technische ausführung als plattform-unabhängig eingestuft werden
- es sollte angegeben werden welche elemente des modells welchen anforderungen entsprechen
2. Generierung: aus dem Modell werden Test Fälle generiert (Test case generator) (auf dem gleichen abstraktionslevel wie das modell selbst)
-ein testfall besteht aus einer sequenz von operationen die auf das system angewandt werden
-> wenn system endlos laufen kann, gibt es auch unendlich viele testfälle
-> test engineer muss "test selection criterion" oder "test adequace criterion" angeben, damit generieren der testfälle terminiert
-> neben testfällen kann "requirement traceability matrix" und "model coverage report" generiert werden
-> ordnen requirements den testfällen zu, damit können nach testausführung verletzte Anforderungen festgestellt werden
3. Konkretisierung: abstrakte Testfällen werden zu ausführbaren Tests
- transformation (z.b. via templates) oder adapter der abstrakte Operationen auf das Interface des Systems mapped (in Runtime)
4. Ausführen: tests werden sequentiell ausgeführt und results aufgezeichnet
5. Analyse: Ergebnisse werden analysiert, Fehler gemeldet und gefixt
-> Zentraler Unterschied zu traditionellem test prozess ist die Modellierung und die testfallgenerierung durch das modell
weiter bei Potential Types of Test Models, Metamodels, and Notations
...@@ -132,7 +132,7 @@ ...@@ -132,7 +132,7 @@
\printbibliography[heading=bibintoc]\label{sec:bibliography}% \printbibliography[heading=bibintoc]\label{sec:bibliography}%
\appendix \appendix
\input{sections/appendix} \input{sections/appendix.tex}
\confirmation \confirmation
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment