From d45e9ba2cd26dbcaad0626142cf4d8aff9dc3155 Mon Sep 17 00:00:00 2001 From: cs-99 <ckhuemonma@web.de> Date: Sat, 5 Jun 2021 14:37:41 +0200 Subject: [PATCH] --- .gitignore | 3 +- literatur.bib | 112 ++++++++++++++++++++++++++++---------------------- notizen.txt | 102 +++++++++++++++++++++++++++++++++++++++++++++ thesis.tex | 2 +- 4 files changed, 167 insertions(+), 52 deletions(-) create mode 100644 notizen.txt diff --git a/.gitignore b/.gitignore index 8669670..22177b2 100644 --- a/.gitignore +++ b/.gitignore @@ -251,5 +251,4 @@ TSWLatexianTemp* *.sta # this thesis -thesis.pdf -notizen.txt \ No newline at end of file +thesis.pdf \ No newline at end of file diff --git a/literatur.bib b/literatur.bib index 90ca2d6..f2baa1c 100644 --- a/literatur.bib +++ b/literatur.bib @@ -1,13 +1,14 @@ % Encoding: UTF-8 @Article{Pepper2007, - author = {C. Pepper and S. Balakirsky and C. Scrapper}, - title = {Robot simulation physics validation}, - year = {2007}, - booktitle = {Proceedings of the 2007 Workshop on Performance Metrics for Intelligent Systems - {PerMIS} {\textquotesingle}07}, - doi = {10.1145/1660877.1660890}, - file = {:1660877.1660890.pdf:PDF}, - publisher = {{ACM} Press}, + author = {C. Pepper and S. Balakirsky and C. Scrapper}, + title = {Robot simulation physics validation}, + year = {2007}, + booktitle = {Proceedings of the 2007 Workshop on Performance Metrics for Intelligent Systems - {PerMIS} {\textquotesingle}07}, + doi = {10.1145/1660877.1660890}, + file = {:1660877.1660890.pdf:PDF}, + publisher = {{ACM} Press}, + readstatus = {skimmed}, } @Book{Bihlmaier2014, @@ -45,7 +46,7 @@ file = {:2370216.2370410.pdf:PDF}, publisher = {{ACM} Press}, ranking = {rank2}, - readstatus = {read}, + readstatus = {skimmed}, } @Article{lim2010automated, @@ -73,54 +74,67 @@ 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, - author = {Mark Utting and Alexander Pretschner and Bruno Legeard}, - journal = {Software Testing, Verification and Reliability}, - title = {A taxonomy of model-based testing approaches}, - year = {2011}, - month = {apr}, - number = {5}, - pages = {297--312}, - volume = {22}, - doi = {10.1002/stvr.456}, - file = {:stvr.456.pdf:PDF}, - publisher = {Wiley}, + author = {Mark Utting and Alexander Pretschner and Bruno Legeard}, + journal = {Software Testing, Verification and Reliability}, + title = {A taxonomy of model-based testing approaches}, + year = {2011}, + month = {apr}, + number = {5}, + pages = {297--312}, + volume = {22}, + doi = {10.1002/stvr.456}, + file = {:stvr.456.pdf:PDF}, + publisher = {Wiley}, + readstatus = {skimmed}, } @InProceedings{Hansel2015, - author = {Joachim Hansel and Thomas Vogel and Holger Giese}, - booktitle = {2015 {IEEE} International Conference on Self-Adaptive and Self-Organizing Systems Workshops}, - title = {A Testing Scheme for Self-Adaptive Software Systems with Architectural Runtime Models}, - year = {2015}, - month = {sep}, - publisher = {{IEEE}}, - doi = {10.1109/sasow.2015.27}, - file = {:07306570.pdf:PDF}, + author = {Joachim Hansel and Thomas Vogel and Holger Giese}, + booktitle = {2015 {IEEE} International Conference on Self-Adaptive and Self-Organizing Systems Workshops}, + title = {A Testing Scheme for Self-Adaptive Software Systems with Architectural Runtime Models}, + year = {2015}, + month = {sep}, + publisher = {{IEEE}}, + doi = {10.1109/sasow.2015.27}, + file = {:07306570.pdf:PDF}, + readstatus = {skimmed}, } @InProceedings{Gonzalez2018, - author = {Carlos A. Gonz{\'{a}}lez and Mojtaba Varmazyar and Shiva Nejati and Lionel C. Briand and Yago Isasi}, - booktitle = {Proceedings of the 21th {ACM}/{IEEE} International Conference on Model Driven Engineering Languages and Systems}, - title = {Enabling Model Testing of Cyber-Physical Systems}, - year = {2018}, - month = {oct}, - publisher = {{ACM}}, - doi = {10.1145/3239372.3239409}, - file = {:3239372.3239409.pdf:PDF}, + author = {Carlos A. Gonz{\'{a}}lez and Mojtaba Varmazyar and Shiva Nejati and Lionel C. Briand and Yago Isasi}, + booktitle = {Proceedings of the 21th {ACM}/{IEEE} International Conference on Model Driven Engineering Languages and Systems}, + title = {Enabling Model Testing of Cyber-Physical Systems}, + year = {2018}, + month = {oct}, + publisher = {{ACM}}, + doi = {10.1145/3239372.3239409}, + 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;} diff --git a/notizen.txt b/notizen.txt new file mode 100644 index 0000000..f0997c8 --- /dev/null +++ b/notizen.txt @@ -0,0 +1,102 @@ +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 + diff --git a/thesis.tex b/thesis.tex index 4eab5b4..3c27e7b 100644 --- a/thesis.tex +++ b/thesis.tex @@ -132,7 +132,7 @@ \printbibliography[heading=bibintoc]\label{sec:bibliography}% \appendix -\input{sections/appendix} +\input{sections/appendix.tex} \confirmation -- GitLab