--- title: "Frühzeitige Softwaretests bestätigen das Design" date: "2018-07-02" categories: - "app-development" - "mobile" - "mobile-development" - "mobiletogether" tags: - "early-software-testing" - "mobile-development" - "mobiletogether" - "software-tools" description: Frühzeitiges Softwaretesting ist besonders wichtig für Entwickler, die an Anwendungen für mobile Geräte arbeiten, die auf verschiedenen Plattformen laufen und unterschiedliche Hardwareeigenschaften sowie Betriebssystemfunktionen aufweisen. --- Status: #blog Tags: #early-software-testing #mobile-development #mobiletogether #software-tools Categories: [mobile-development](/blog/de/category/mobile-development.md) | [mobile-development](/blog/de/category/mobile-development.md) | [mobile-development](/blog/de/category/mobile-development.md) | [mobile-development](/blog/de/category/mobile-development.md) # Frühzeitige Softwaretests bestätigen das Design "Frühzeitig und häufig testen" ist eine Strategie aus dem agilen Software-Engineering, die sich zu einer Grundregel für Softwareentwickler in allen Bereichen entwickelt hat. Frühzeitiges Software-Testing ist besonders wichtig für Entwickler, die an plattformübergreifenden Anwendungen arbeiten, da sie mobile Geräte mit unterschiedlichen Hardwareeigenschaften und Betriebssystemfunktionen unterstützen müssen. MobileTogether bietet Funktionen, um frühzeitig Softwaretests in den Entwicklungsprozess zu integrieren, ohne dass für jede mobile Plattform zeitaufwändige Kompilierungs-, Bereitstellungs- und Debugging-Zyklen erforderlich sind. Auf der Altova-Website wird die Funktion "[MobileTogether Simulator](https://www.altova.com/de/mobiletogether/app-development#test-app)" für frühzeitige Softwaretests beschrieben, und wir haben in unserem Blog über die Möglichkeit geschrieben, bestimmte Aktionen aufzuzeichnen und in [Testfällen](https://www.altova.com/blog/automated-testing-for-mobile-apps/) erneut auszuführen. Dieser Beitrag beschreibt die Funktion "Testlauf auf Client". Sie ist in den MobileTogether Designer integriert, um Entwicklern die Möglichkeit zu geben, App-Designs sofort zu überprüfen und die Logik und Funktionalität auf jedem unterstützten mobilen Gerät oder jeder Plattform zu validieren – Android, iOS, Windows Desktop oder Windows Phone. [![](/blog/images/shutterstock_88166515.jpg)](shutterstock_88166515.jpg) Eine Testphase beim Kunden ist besonders nützlich für die frühen Softwaretests von Anwendungen, die: - Nutzen Sie mobile Funktionen, die in der Designer-Anwendung auf der Windows-Plattform nicht verfügbar sind, wie beispielsweise SMS-Nachrichten - Verwenden Sie Aktionen, die sich je nach Betriebssystem leicht unterschiedlich verhalten, beispielsweise die Aktion "Geolokalisierung anzeigen", bei der die standardmäßige Kartenanwendung des Clients geöffnet wird - Es muss auf einem brandneuen Mobilgerät getestet werden, dessen Bildschirmabmessungen möglicherweise nicht mit denen eines Testgeräts für Designer übereinstimmen Für einen Testlauf bei einem Kunden sind die Anforderungen sehr gering: Auf dem mobilen Gerät, das für den Test verwendet wird, muss die MobileTogether Client-Anwendung installiert sein, das mobile Gerät und der MobileTogether Designer-Arbeitsplatz müssen sich im selben Netzwerk befinden, und die Netzwerkadresse des Designer-Arbeitsplatzes muss als MobileTogether-Server auf dem mobilen Gerät konfiguriert sein. Sobald das Client-Gerät bereit ist, kann der Entwickler einen Testlauf auf dem Client über das Menü des Designer-Projekts oder über die praktische Symbolleiste starten: [![Testversion des Symbols für die Client-Symbolleiste zur frühzeitigen Softwareprüfung in MobileTogether](/blog/images/MobileTogether-toolbar-1.png)](MobileTogether-toolbar-1.png) Schauen wir uns eine App an, die sich noch in der Entwicklung ist und GPS-Funktionen nutzt. Der Entwickler hat für die Vorschau das iPhone 6 Plus verwendet. Die früheste Möglichkeit, die App zu testen, bietet der [MobileTogether-Simulator](https://www.altova.com/de/mobiletogether/app-development#test-app), eine Funktion des MobileTogether Designers, die jederzeit während der Entwicklung verfügbar ist. Das Hauptfenster des Simulators zeigt die App so, wie sie auf dem ausgewählten Testgerät angezeigt wird. Entwickler können das Testgerät auswählen, um die Benutzeroberfläche so anzuzeigen, wie sie auf verschiedenen iOS-, Android-, Windows- und anderen Geräten erscheinen wird, oder sogar während der Entwicklung zwischen Hoch- und Querformat umschalten. Der Simulator aktualisiert außerdem die Änderungen, die im Datenbaum der Seitenressourcen während der Ausführung der App auftreten. Das Nachrichtenfenster im Designer zeigt einen detaillierten, schrittweisen Bericht über die Aktivitäten während der Ausführung, einschließlich der Nachrichten zwischen der Client-App und dem Server. Bedienelemente, die eine Benutzerinteraktion erfordern, sind während der Simulation alle aktiviert. Hier ist ein Screenshot der App, die im Simulator ausgeführt wird: [![Frühe Softwaretests im MobileTogether-Simulator](/blog/images/MobileTogether-simulator-window.png)](MobileTogether-simulator-window.png) Zwei Probleme treten sofort auf: Der Simulator liefert keine korrekten GPS-Koordinaten. Stattdessen verwendet er eine Datendatei, um die Bewegung des mobilen Geräts und die aktualisierten GPS-Koordinaten zu simulieren. Außerdem öffnet der Button "Kartenansicht" in der App Bing Maps auf der Windows-Workstation, auf der der Designer läuft, obwohl er auf einem echten iPhone standardmäßig Apple Maps als Kartenanwendung öffnen sollte. Wir können die Funktion "Testlauf auf Gerät" verwenden, um die App auf einem echten mobilen Gerät auszuführen, um die GPS-Funktionalität zu testen und die Funktion "Kartendarstellung" zu überprüfen. Für den ersten Test verwenden wir ein Android-Smartphone. Durch Klicken auf die Schaltfläche "Testlauf auf Gerät" öffnet sich ein neues Fenster im Designer: [![Durchführung eines Testlaufs beim Kunden zur frühzeitigen Softwareprüfung](/blog/images/trial_run-1.png)](trial_run-1.png) Zu diesem Zeitpunkt fungiert die Designer-Anwendung auch als MobileTogether-Server. Das interne Nachrichtenfenster öffnet sich, sobald das Client-Gerät die App startet. Der Entwickler klickt im Designer-Dialog auf "Ja", um fortzufahren, und die App wird auf dem Client-Gerät ausgeführt. Sofort stellen wir ein unerwartetes Problem fest: Die Standard-Textgröße ist extrem klein: [![Erster Testlauf auf einem Android-Smartphone](/blog/images/screenshot-1-Android.png)](screenshot-1-Android.png) Wir könnten einfach den "Abc+"-Button anklicken, um die Textgröße zu erhöhen, und die Endbenutzer dazu auffordern, dasselbe zu tun. Das wäre jedoch eine ungeschickte und wenig benutzerfreundliche Lösung. Stattdessen können wir im Designer das Fenster "Testlauf auf Client" verwenden, um den Datenbaum der Anwendung während des Betriebs einzusehen: [![Frühzeitige Überprüfung von Kundendaten im Rahmen eines Testlaufs auf dem System des Kunden](/blog/images/trial_run-2.png)](trial_run-2.png) Das Element "textSize" im persistenten Datenspeicher enthält einen Wert, der die Schriftgröße für Textbeschriftungen und Schaltflächen in absoluten Pixeln festlegt. Der feste Wert von 20 wurde als Standardwert gewählt und sah während der Entwicklung für das iPhone 6 Plus in Ordnung, funktioniert aber nicht für das aktuelle Gerät. Wir können die Standard-Textgröße problemlos von einem festen Wert in eine Funktion umstellen, die sich an den Pixeldimensionen für jedes einzelne Endgerät anpasst. Anschließend können wir sofort einen neuen Testlauf durchführen. MobileTogether stellt globale Variablen bereit, die Entwicklern Zugriff auf verschiedene Eigenschaften jedes Endgeräte ermöglichen, während die App ausgeführt wird. Das Fenster "Globale Variablen" im Designer zeigt die Werte für das ausgewählte Testgerät an. Hier ist ein Screenshot der Werte für das iPhone 6 Plus: [![Fenster für globale Variablen im MobileTogether Designer](/blog/images/global-variables.png)](global-variables.png) Anstatt einen Standardwert von 20 Pixeln für das Element "textSize" zu verwenden, können wir eine Funktion erstellen, die auf der globalen Variablen "MT_DeviceHeight" basiert. Zwanzig geteilt durch 736 ergibt ungefähr 2,7 Prozent. Wir werden diesen Wert verwenden, um eine XPath-Funktion zu erstellen, die die anfängliche Größe von "textSize" basierend auf jedem Client-Gerät festlegt: [![Die Verwendung einer Funktion zur Anpassung der Textgröße basierend auf dem verwendeten Endgerät](/blog/images/textSize-function.png)](textSize-function.png) Jetzt können wir einen weiteren Testlauf auf dem Gerät des Kunden mit einem Android-Smartphone durchführen, um das Ergebnis zu überprüfen. [![Zweiter Testlauf beim Kunden zeigt die neu berechnete Textgröße](/blog/images/new-textSize.png)](new-textSize.png) Das oben gezeigte Fenster für die Testausführung zeigt den neu berechneten Standardwert für die Schriftgröße, und hier ist ein neuer Screenshot vom Telefon: [![Testlauf beim Kunden, um die neue Standardtextgröße zu überprüfen](/blog/images/screenshot-2-Android.png)](screenshot-2-Android.png) Die standardmäßig berechnete Textgröße, die auf der Höhe des Gerätebildschirms basiert, ist deutlich sinnvoller und benutzerfreundlicher! Außerdem kann die Textgröße weiterhin mithilfe der "Abc-"- und "Abc+"-Schaltflächen angepasst werden, da diese lediglich Werte von oder zu dem Element "textSize" addieren oder subtrahieren. Nun können wir zu unserer ursprünglichen Aufgabe zurückkehren, nämlich die Funktionalität des "Map View"-Buttons in der App zu überprüfen. Im Folgenden sind Screenshots einer Seite der App sowie die entsprechende Kartenansicht für ein Android-Smartphone dargestellt:       [![Testlauf eines Android-Smartphones beim Kunden zur frühzeitigen Softwareprüfung](/blog/images/screenshot-3-Android.png)](screenshot-3-Android.png) [![Der "Kartenansicht"-Button auf dem Android-Smartphone öffnet Google Maps während der frühen Softwareprüfung](/blog/images/screenshot-4-Android.png)](screenshot-4-Android.png) Und hier sind die gleichen Ansichten, aufgenommen mit einem iPhone:       [![Ein Screenshot des iPhones während der frühen Softwaretests](/blog/images/iPhone-screen-1.png)](iPhone-screen-1.png) [![Das iPhone öffnet Apple Maps während der frühen Softwaretests](/blog/images/iPhone-screen-2.png)](iPhone-screen-2.png) Alle vier Screenshots oben wurden während einer Testphase auf dem Gerät des Kunden erstellt. Die genaue Darstellung der Karten auf jeder Plattform wird durch die Funktionen und Benutzereinstellungen in der jeweiligen Kartenanwendung bestimmt. Beispielsweise bietet Google Maps auf dem Android-Smartphone die Straßenansicht, während die Karten-App von Apple diese Funktion nicht bietet. Sie können frühzeitige Softwaretests mit der Funktion "Trial Run auf dem Client" durchführen und dabei alle anderen Funktionen von MobileTogether nutzen, um elegante Anwendungen zu entwickeln, indem Sie den kostenlosen MobileTogether Designer [herunterladen](https://www.altova.com/de/download/mobiletogether.html). Dieser wird mit integrierter Hilfe, Tutorials und zahlreichen Beispielen geliefert.