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