Bachelor-Arbeit-Latex/065_2_bewertung.tex

\section{Tests}
	\label{sec:tests}

	\subsection{Route aufzeichnen}
		\subsubsection{Koordinaten Plausibilität}

	\subsection{Routen Management}
		Die Verwaltung der Routen kann getestet werden, indem die einzelnen Aktionen zur Routenverwaltung ausgeführt werden. Als Vorbereitung muss eine Route aufgezeichnet werden, dementsprechend muss der vorausgegangene Test \texttt{Route aufzeichnen} erfolgreich abgeschlossen worden sein. Für den Umfang dieses Tests wurde festgelegt, dass die Route 10 Punkte beinhalten soll. Die Anzahl der bereits aufgezeichneten Punkte kann im Menü des Aufzeichnungsmodus verfolgt  und abschließend im Menü \texttt{Route} überprüft werden. In diesem Menü können die einzelnen Koordinaten der Punkte betrachtet werden, diese werden wieder notiert, um die Richtigkeit der Daten im Verlauf des Tests prüfen zu können.

		\subsubsection{Route exportieren}
			Nach Abschluss der Vorbereitung kann die Route exportiert werden, dafür muss der zugehörige Menüpunkt aufgerufen werden. In diesem muss eine \texttt{ID} für die Route vergeben werden. In diesem Fall wird dafür die Zahl \(98\) gewählt. Nach der Bestätigung wird der Ausgang des Exports mitgeteilt. In diesem Fall erscheint die Meldung \glqq \texttt{Export complete}\grqq\ mit dem Code \(201\). Zur Überprüfung der gespeicherten Daten kann die Route über die folgende URL abgerufen werden: \url{https://rover.kleiax.de/api/98}. Die empfangenen Daten des Endpunktes der API entsprechen den übermittelten Daten.
			\par
			Ein erneuter Versuch, die Route mit derselben \texttt{ID} zu exportieren, schlägt richtigerweise mit dem Code \(419\) fehl, da die \texttt{ID} bereits verwendet wird und dadurch sichergestellt werden kann, dass diese nicht durch eine fehlerhafte Eingabe überschrieben oder verfälscht wird.

		\subsubsection{Route importieren}
			Um überprüfen zu können, ob die exportierte Route bei dem folgenden Test auch tatsächlich wieder geladen wird, muss zunächst die zwischengespeicherte Route gelöscht werden. Dafür existiert der Menüeintrag \glqq\texttt{Clear}\grqq\ oder der Rover wird neu gestartet. Für den Test wurde ein Neustart über das Menü ausgeführt. In dem Menüeintrag \texttt{Points} kann zusätzlich überprüft werden, ob eine Route vorhanden ist. Der eigentliche Test besteht darin, über den Menüpunkt \texttt{import} die zuvor gewählte \texttt{ID} zu selektieren und anschließend durch die Bestätigung den Import auszuführen. Bei einem Erfolg wird die Meldung \glqq \texttt{Import Complete}\grqq\ mit dem Code \(202\) erwartet.
			\par
			Nach dem Erhalt der Erfolgsbestätigung wurden die importierten Koordinaten mit den exportierten Koordinaten abgeglichen und es wurde Gleichheit festgestellt. Der Versuch eine nicht existierende Route zu importierten, schlägt erfolgreich mit dem Code \(418\) fehl.

		\subsubsection{Route löschen}
			Die Löschung konnte ebenfalls erfolgreich getestet werden, indem der passende Menüeintrag ausgewählt und wieder die \texttt{ID} \(98\) ausgewählt wurde. Die Rückmeldung lautete \glqq \texttt{Delete complete}\grqq\ mit dem Code \(202\). Der Versuch, die bereits gelöschte ID erneut zu löschen, wird mit dem Fehlercode \(418\) quittiert. Zur Überprüfung, ob die Daten gelöscht wurden, kann die API-URL aus dem ersten Test aufgerufen oder es kann versucht werden, die gelöscht Route zu importieren. Beides schlägt wie erwartet mit dem Code \(418\) fehl.

	\subsection{Route abfahren}
		\subsubsection{Genuigkeitsprüfung stören}


\section{Rover}
	Während der Nutzung im Zuge der Entwicklung und der Tests sind allgemeine Erkenntnisse zu dem Rover erlangt worden. Diese werden im Folgenden thematisiert und beziehen sich hauptsächlich auf die Handhabung und die Umweltanforderungen, welche durch die Architektur des Rovers gestellt werden.

	\subsection{W-LAN}
		Durch die benötigten Korrekturdaten für das GNSS-Modul, welche über das Internet übertragen werden, muss der Rover stets auf eine Internetverbindung zugreifen können. Der Vorteil dieser Übertragungsmethode liegt in der Verfügbarkeit im Gegensatz zu spezielleren Lösungen, dadurch wird nicht zwingend eine eigene Basisstation benötigt. Das Problem liegt darin, wie die Verbindung hergestellt wird. Im aktuellen Ausbau verfügt der Rover lediglich über W-LAN. Den bereits in Kapitel \ref{ssec:wlan-description} beschriebenen Spezifikationen, kann die Reichweite von W-LAN Netzwerken entnommen werden. Mit den vom Rover unterstützen \(2,4 GHz\) Band, mit der besten Reichweite, ist eine Abdeckung des Einsatzgebietes sehr aufwendig. Außerdem ist Konfiguration des Rovers für Änderungen des W-LANs durch Konfiguration oder Standortwechsel anfällig.
		\par
		Die aktuelle Lösung besteht darin, ein Mobilfunktelefon mit aktivierten W-LAN Access Point in der Nähe des Rovers zu halten oder dieses in dem Rover mitfahren zu lassen. Allerdings werden dadurch nicht alle zuvor genannten Probleme behoben, daher wäre an dieser Stelle eine Optimierung, welche diesen Umweg überflüssig werden lässt, angebracht.

	\subsection{Handhabung}
		Die Steuerung des Rovers ist an die Fernbedienung gebunden, welche ebenfalls das \(2,4 GHz\) Band nutzt und damit denselben Reichweiten Einschränkungen unterliegt. Für den aktuellen Entwicklungsstand des Rovers reicht dies aus, insbesondere weil das Bedienkonzept zu diesem Zeitpunkt den Sichtkontakt zu dem Rover für viele Aktionen voraussetzt.
		\par
		Des Weiteren gibt es nur wenige Fehler, auf welche der Rover reagieren kann, wie der Verlust der Korrekturdaten oder eine zu geringe Spannung des Akkus. Alle anderen Fehler können nicht detektiert werden. Die erkennbaren Fehler können dem Nutzer nur mitgeteilt werden, wenn sich dieser mit der aktivierten Fernbedienung in Reichweite befindet und der Nutzer sich in dem richtigen Menüpunkt befindet. Lediglich die Abschaltung des Rovers aufgrund eines zu geringen Ladestands wird auf dem Display ohne Benutzereingabe angezeigt.

	\subsection{mehr?}