inhalt.tex 12.1 KB
Newer Older
Christoph Thelen's avatar
Christoph Thelen committed
1 2
\section{Einführung}

3
Die Popularität von Android-Software ist in den letzten Jahren enorm gestiegen. Für Forscher in Programmiersprachen und Software-Engineering ist es unerlässlich, neue Techniken in diesen immer wichtiger werdenden Bereich einzubringen. Suchtechniken erfordern eine Grundlage der Programmanalyse für Android. Im Rahmen der Arbeit wird zunächst auf die verwendte Tool(Gator) eingegangen, wobei erst eine Vorstellung von Tool selbst und die Funktionsweise beschrieben wird. Danach werden relevanten offenen Fragen vorgestellt. Anschließend wird auf Versuchsaufbau und Ergebnisse eingegangen.
Christoph Thelen's avatar
Christoph Thelen committed
4 5 6

\section{Pilot Study}

7 8 9 10 11 12
Testautomatisierung stellt keinen Ersatz für manuelles Testen durch TesterInnen dar, sondern ist vielmehr eine Ergänzung die es ermöglicht eine große Anzahl
von Testfällen (wie z.B. das Finden von Regressionen bei einem langen Testlauf über
Nacht) in der gegebenen Zeit zu bewältigen und sich auf kreative Tätigkeiten (wie z.B. das finden neuer Fehler durch exploratives Testen) zu fokussieren. Tests die häufig durchgeführt werden müssen (z.B. imRahmen eines Releasezyklus) sind bessere Kandidaten für die Automatisierung als solche die nur selten ausgeführt werden. Während es sehr vorteilhaft sein kann komplexe Testabläufe zu automatisieren, tragen mehreren Faktoren (z.B.Unterstützung bestimmter Funktionen, Aufwand, komplexe Interaktionen mehrere
Teilsysteme) dazu bei, dass einige Testfälle nur schwer bzw. nicht kosteneffektiv automatisierbar sind. Die Testautomatisierung muss
flexibel umgesetzt werden und leicht an die Veränderungen des zu testenden Systems anpassbar sein. Dabei empfiehlt sich die Umsetzung eines Testautomatisierungsframeworks.
Damit Tests automatisiert werden können, muss das zu testende System auch ein Mindestmaß an Testbarkeit, wie z.B. geeignete Schnittstellen, geeignete Identifikationsmerkmale etc., mitbringen. Es hängt vom Scenarien ab wo es Manuelletesting verwendet werden soll und wo die Automatisierungs-testverfahren. Es soll manuelle Testing für Exploratory-testing, Usability-testing und Ad-hoc-teting bevorzugt werden. Auf der anderen Seite für Regression-tests, Load-tests, Performance-testing sind Automatisierungs-testverfahren besser.
Christoph Thelen's avatar
Christoph Thelen committed
13

14
\section{GATOR}
Christoph Thelen's avatar
Christoph Thelen committed
15 16 17

\subsection{Funktionsweise}

18 19 20 21 22 23
GATOR ist ein Programmanalyse-Toolkit für Android. Zum Ausführen ist ein Unix-ähnliches Betriebssystem erforderlich. Das Toolkit verwendet entweder Java-Bytecode oder APK Dateien als Eingabe,, die mit dem Soot-Programmanalyse-Framework verarbeitet werden. GATOR-Analysen basieren auf Soot. Die Möglichkeiten, die Gator anbietet sind als folgendes:
\begin{itemize}
\item GUI-Strukturanalyse mit Erweiterungen und Modifikationen
\item Callback-Kontrollflussanalyse mit geringfügigen Erweiterungen
\item Analyse zum Erstellen des Fensterübergangsdiagramms (WTG) mit geringfügigen Erweiterungen
\end{itemize}
Christoph Thelen's avatar
Christoph Thelen committed
24 25

\subsection{Inbetriebnahme}
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76
Da es für Gator eine Unix-ähnliches Betriebsystem erforderlich ist, mussten wir den Linux Betriebsystem als Virtualbox installieren.
\textbf{Erforderliche Sofware:}\\
Um Gator verwenden zu können sollen die folgende Software installert werden:
\begin{itemize}
	\item JDK: Version 1.7+ ist erforderlich
	\item Python: Version 3
	\item Android SDK: Aktuellleste Version. Nach der Installation des SDK sollten auch Unterstützungsdateien für die einzelnen API-Ebenen installiert werden.
\end{itemize}
\textbf{Verwendung von Gator:}
\begin{itemize}
	\item Gator bauen \\ Bevor es Gatoranalyse ausgeführt wird muss man Gator erst bauen. Es gibt zwei  Möglichkeiten um Gator zu bauen: 
	\begin{itemize}
		\item im gator-Verzeichnis verwurzelte Projekt in die IntelliJ-IDE importieren und bauen
		\item Gator-Skript unter dem Gator-Verzeichnis verwenden, um das Projekt zu kompilieren. Das Befehl ist folgendes: \\
		\textbf{./gator b}
	\end{itemize}
	
	\item Vor dem Ausführen von Analysen mit GATOR müssen zwei Umgebungsvariablen definiert werden. Das GatorRoot sollte der Pfad zugewiesen werden, der die AndroidBench- und Gator-Verzeichnisse enthält. Dem ANDROID SDK sollte der Pfad zum Android SDK zugewiesen werden. Unter bash kann dies mit folgenden Befehl getan werden:
\end{itemize}
\textbf{export GatorRoot=PATH\_TO\_ROOT\_DIRECTORY\_OF\_GATOR}
\textbf{export ANDROID\_SDK=PATH\_TO\_ANDROID\_SDK}\\ \\
Der python Script womit man das Gatoranalyse über die Anwendungen ausführen kann ist folgendes: \\ \\
\textbf{./gator a [-v] [-g] [--api API\_LEVEL] -p PATH\_TO\_APK
	[GATOR\_PARAM] [-client] [GATOR\_CLIENT]
	[-clientParam] [GATOR\_CLIENT\_PARAM]
}\\ \\
Bei optionalen Optionen aktiviert die Option '-v' den ausführlichen Modus von GATOR, wodurch die Details der Protokolle 
auf dem Console gedruckt  werden, erhöht. Mit der Option "-g" kann GATOR die Google Play Service-Bibliotheken laden, falls es unter ANDROID SDK-Verzeichnis vorhanden ist. Einige alte Anwendungen erfordern diese Option. Option -api überschreibt die an GATOR gesendete Informationen der API-Ebene . Standardmäßig verwendet GATOR die Ziel-API-Ebene der Anwendung. Aber
es gibt Fälle, in denen einige Anwendungen APIs von API-Stufen verwenden, die über den Ziel-API-Stufen liegen, und die Probleme mit GATOR verursachen. Wenn wir eine Analyse mit einem apk unter /tmp/example.apk mit WTGDemoClient durchführen möchten, wenden wir uns an
folgenden Befehl:\\ \\
\textbf{./gator a -p /tmp/example.apk -client WTGDemoClient}\\ \\
Wenn wir eine Analyse auf demselben apk mit EnergyAnalysisClient durchführen möchten, können wir folgendes Befehl verwenden:\\ \\
\textbf{./gator a -p /tmp/example.apk -client EnergyAnalysisClient
	-clientParam WTPK5}\\ \\
Es gibt folgende Clients von Gator die, die Analyse des Programs ermöglichen: \\
\begin{itemize}
	\item GUIHierarchyPrinterClient\\
	Diese Client druckt den Titel des Widgets aus. Mit diese Information können die weitere Schritte der Analyse ausgeführt werden.
	\item WTGDemoClient\\
	Es erstellt die Window Transition Graph(WTG) des Programs, um die Struktur mehr zu deutlichen.Information über die Anzahl der Pfade usw. ist auch nachvollziehbar.
	\item EnergyAnalysisClient\\
	Es gibt die Max/Min/Free/Used-Memspace aus.
	\item PathGenerationDemoClient\\
	Es gibt Anzahl der erreichbare Pfads aus.
	\item CH5Client\\
	Es gibt die Anzahl der Nodes und Views aus.
	\item ASE15Client\\
	Es gibt die Anzahl der Feasible-Pfads aus.\\ \\
	Beim Gator gibt es auch die Möglichkeit eine benutzerdefinierte GUIAnalyseClient zu schreiben, damit  man die gewünschte daten sammeln kann und die Analyse noch verbessern kann.
	\end{itemize}
 
Christoph Thelen's avatar
Christoph Thelen committed
77 78
\subsection{Offene Fragen}

79 80 81 82 83 84 85 86 87 88
Um Gator zum laufenbringen zu können, müssten wir viele Schwierigkeiten konfrontieren. Erstes Problem war Linux-betriebsystem auf Virtualbox. Es hat immer das System abgestürzt und dafür musste das System immer neue gestartet wurde. Es gab auch keine Möglichkeit um die Emulator in Android-Studio auf Linux auszuführen damit man die angeforderte APK's generieren kann. Deswegen wurde immer eine reales Gerät verwendet. Noch weitere Problem war unklare Ausgabedatei von Gatoranalyse nach dem die oben angegebene Befehle für Programanlyse ausgeführt werden können. Es wurde vom Gator-Clienten auf dem Console immer so gezeigt als ob es irgendwo die angeforderte Daten und Informations ausgibt, aber das war nicht der Fall. Gator bietet auch keine Möglichkeit um die Screenshots von Anwendung zu machen, damit die Analyse weitere Schritten Folgen kann.
Die Dokumentation des Gators ist auch nicht ausreichend, um bessere Analyse ausführen zu können.  Da es wieder und wieder gleiche Fehlermeldungen und Probleme auftreten, haben wir uns entschieden eine andere Alternativ zu haben. Und dafür wurden folgende Tools verwendet: \\
\begin{itemize}
	\item Android Monkey
	\item UIAutomator
	\item Node.js Skript
	\item Python Skript
	
\end{itemize}
Die weitere Analyse von der Anwendungen durch diese Alternative bearbeitet. Es wird diese Analyse in nächsten Teil des Arbeits bzw. Versuchsaufbau erwähnt.
Christoph Thelen's avatar
Christoph Thelen committed
89 90 91

\section{Versuchsaufbau}

92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109
Um die ersten Screenshots erstellen zu können, sollen die Tools Android Monkey und UIautomator Server möglichst gleichzeitig ausgeführt werden. Um Android Monkey auszuführen, soll folgender Befehl ausgeführt werden:\\ \\
{\textbf{adb shell monkey -p your.package.name -v 500}}\\
	
Dabei löst Android Monkey viele Events auf dem Emulator oder auf einem Device aus. Jeder Event sollte am besten jede 500 Millisekunde erzeugt werden. Der Uiautomator Server kann mit Nodejs gestartet werden:\\ \\
{\textbf{node server.js}}\\
UIautomator gibt Screenshots und UI-Hierarchien im Abstand von 500 ms aus. Die Dateien werden in das Ausgabeverzeichnis gespeichert. Der Verzeichnisname ist ein Unix-Zeitstempel. Die abgelegten Dateien enthalten einen Zeitstempel im Format Sekunden.Nanosekunden, der die Sekunden und Nanosekunden des Geräts seit dem Start zählt.\\
Der Unterschied zwischen Mensch und Computer Mobile App Interaktion wird durch den Tool linux-events realisiert. Dafur soll der folgende Befehl ausgeführt werden:\\ \\
{\textbf{python screen.py /tmp/altcoins-data altcoins.json}}\\ \\
/ tmp / altcoins-data ist ein Ordner mit Screenshots und XML-Dumps. Das Skript gibt die erweiterte JSON-Datei mit Informationen zum UI-Status für jedes Ereignis und dem Klassennamen des Ziel-UI-Widgets aus. Für das Erzeugen der JSON-Datei, wurde eine Skriptdatei geschrieben, die diese JSON-Datei mit dem entsprechenden Format erzeugt. Die Werte für die X und Y Koordinate sollen dann manuell aus den Ergebnisse von Android Monkey abgeschrieben werden.\\
Der erste Teil unserer Eingabe sind die Screenshots und XML-Dumps, die während der Ausführung einer App generiert werden. Das Tool geht davon aus, dass beide Dateitypen der Namenskonvention ui\_ <id>. (Png | xml) folgen. Dies bedeutet, dass wir direkt sehen können, welche UI-Hierarchie zu welchem Screenshot gehört.\\
Durch ein Mapping vom Screenshot zur UI-Hierarchie können wir auf das UI-Element schließen, auf dem ein Ereignis ausgeführt wurde. Dies ist nützlich, wenn der jeweilige UI-Trainer diese Informationen nicht bereitstellt.\\
Die JSON-Datei ist die zweite Eingabe: Die genauen Ereignisse werden als Berührungsfolgen einer x- und y-Position auf dem Bildschirm aufgelistet. Jede "Touchsequenz" hat eine eindeutige ID. Dies ist die gleiche ID, die wir zum Identifizieren von zusammengehörigen Screenshots und UI-Hierarchien verwenden.\\
Die Idee hierbei ist, dass wir für jede Berührungssequenz die Ereigniskoordinaten auf dem jeweiligen Screenshot visualisieren. Bei einem einzelnen Tap-Event wird nur ein Event auf dem Screenshot angezeigt. Bei komplexeren Gesten kann jedoch der gesamte Fingerwischvorgang auf demselben Screenshot angezeigt werden.Beispieldatei mit einem einzigen Tipp: 
\begin{figure}[h]
	\center
	\raisebox{-.5\height}{\includegraphics[width=5cm]{images/Tap.png}}%
	\caption{Single Tap Event\\}
\end{figure}
Christoph Thelen's avatar
Christoph Thelen committed
110 111 112



Christoph Thelen's avatar
Christoph Thelen committed
113

114
\section{Ergebnisse}
Christoph Thelen's avatar
Christoph Thelen committed
115

116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135
Nach der Verwendung von oben genannten Tools haben wir folgendes bemerkt: \\
Gator war ausführlich aber hat nicht wie erwartet funktioniert, da es keine verständliche Ausgaben ausgegeben wurden. Daher kann über Gator's Ausgabe nichts vorgesagt werden. Beim Monkey ist es so dass es nicht Usecaseorientiert ist. Es erzeugt random Ereignisse und damit können die Usecases nicht genau bestimmt werden.\\
Andere UITestTools wie z.B. Espresso-Framework kann nach gefordete Usecases orientieren. Mit anderen Worten kann man sagen, dass die Espresso UITests Zielorientiert sind, da es mit Hilfe von verschiedene Matchers und Actions angegeben werden kann was genau getestet werden soll. \\
Anschließend kommen die von uns aufgezeichnete Aufzeichnungen im Blick, was man manuell ausführt. Die sind völlig Usecaseorientiert, da wir wissen welche Usecase wir implementieren wollen und was unsere Erwartungen sind. \\
 

%\section{Diskussion}
%
%In diesem Abschnitt ist eure Meinung gefragt: Was seht ihr in den Daten? Was seht ihr \emph{nicht} (im Vergleich zur Forschungsfrage)?
%
%\subsection{Interpretation}
%
%Wie sind die Ergebnisse zu deuten?
%
%\subsection{Threats to Validity}
%Bitte versucht euch mal daran, Threats to Validity (siehe die Vorlesungsfolien) zu diesem Experiment zu definieren. :-)
%
%\section{Zusammenfassung}
%
%...