Im letzten Blogpost habe ich die unterschiedlichen Testarten vorgestellt sowie den automatisierten Testablauf von Android-Anwendungen. Im vorliegenden Blogpost gebe ich Einblicke in das Performance-Testing von iOS-Anwendungen.

Während der Recherche für diese Masterarbeit habe ich versucht, ein einheitliches Testsystem sowohl für Android als auch für iOS-Anwendungen zu finden. Wäre es möglich mit einem einzelnen Framework Anwendungen auf beiden Betriebssystemen zu testen, so wäre das Ergebnis besser untereinander vergleichbar, auch wenn unterschiedliche Endgeräte verwendet worden wären. Da Apple jedoch ein geschlossenes Betriebssystem ist, wurde außer der von Apple zur Verfügung gestellten Entwicklungsumgebung Xcode und dem standardmäßig mitgelieferten Profiling Tool Instruments, kein anderes Tool gefunden. Somit wurde in Xcode sowohl entwickelt als auch getestet. Instruments besteht aus einzelnen Instrumenten, welche zur Messung unterschiedlichster Parameter bereitgestellt werden.

Nach der Recherche habe ich mich dazu entschieden, das Instrument Activity Monitor für die CPU- und RAM-Messung heranzuziehen. Mit dem Activity Monitor ist eine Aufnahme der einzelnen Testfälle möglich und das Resultat einer Messung ist eine Zeitreihe, welche als Graph dargestellt wird. Aus diesem können pro Sekunde die beiden Werte (CPU und RAM-Verbrauch) abgelesen werden. Leider ist es in XCode nicht möglich, die Ergebnisse eines Testdurchgangs zu exportieren, weshalb die Werte für jede Sekunde händisch in eine Excel-Tabelle übertragen und gespeichert werden mussten. Dies nahm bei drei Anwendungen und drei getesteten Interaktionsszenarien (Testfällen) pro Anwendung und jeweils 20 Durchgängen pro Interaktion durchaus viel Zeit in Anspruch.

Beim Erstellen der Testfälle für iOS kam es bei der Anwendung, welche mit dem Flutter Framework erstellt wurde zu einem unerwarteten Problem. Obwohl die Anwendung auf dem iPhone ohne Probleme lief, ließen sich keine Tests starten und Xcode zeigte lediglich eine Fehlermeldung, dass das Framework Flutter nicht gefunden werden konnte. Dieser Fehler konnte trotz intensiver Recherche und diversen Anfragen in Flutter-Foren nicht behoben werden, weshalb nur auf drei Anwendungen getestet wurde.

Anders als beim Testen der Android Anwendungen, können nicht alle vier iOS-Anwendungen mit einem einzigen Testskript getestet werden, da der Testaufbau in Xcode das nicht zulässt. Hier muss pro Anwendung und Testfall getestet werden, da die Tests direkt in der Anwendung verfasst werden. Dies war bei Android anders, hier konnte zwischen den einzelnen Testfällen und Anwendungen in einem einzigen Testskript gewechselt werden. Für die beiden Interaktionsszenarien Öffnen und Schließen des Navigation Drawers und Übergang zwischen zwei Bildschirmen wurden die gleichen zeitlichen Abläufe verwendet. So konnte sichergestellt werden, dass die unterschiedlichen Entwicklungsansätze der Anwendungen auf iOS auf der Ebene der einzelnen Interaktionen untereinander vergleichbar waren. Bei der Interaktion Scrollen durch eine virtuelle Liste trat das Problem auf, dass trotz gleichen Zeitabständen bei den einzelnen Interaktionen, die Testszenarien bei den unterschiedlichen Entwicklungsansätzen unterschiedlich lang waren. Das war darauf zurückzuführen, dass das iOS Betriebssystem mit dem sogenannten idle Status zur Schonung des Energieverbrauchs arbeitet. Das bedeutet, dass das Gerät möglichst wenige Ressourcen verbrauchen möchte und auch nur für Mikrosekunden, alle nicht genutzten Ressourcen hinunterfährt. Bei der nativen iOS-Anwendung wurde zwischen den Swipe-Gesten keine Pause eingebaut, bei der React Native und der Ionic/Capacitor-Anwendung wurde nach einem Swipe eine Pause von drei Sekunden, mittles der sleep()-Methode, eingebaut. Ohne dieser, wurden die drei Swipes-Gesten so schnell nacheinander durchgeführt, dass die Anwendungen den zweiten und dritten Swipe nicht immer wahrnahmen.

Alles in allem war das Testen der iOS-Anwendungen mit deutlich mehr Aufwand verbunden, unabhängig vom händischen Übertragen der Ergebnisse in eine Excel-Datei, als das Testen der Android-Anwendungen. Wenn Fehler auftraten, habe ich deutlich länger gebraucht, um diese zu lösen, als bei Android. Ich habe auch das Gefühl, dass die Android Community deutlich aktiver und hilfsbereiter ist als die iOS-Community. Als in der Entwicklung der Android Testfälle Fehler auftragen, konnten diese durch eine Recherche im Internet und in unterschiedlichen Foren relativ schnell behoben werden. Wenn Fehler in Xcode auftraten, konnten diese weniger gut recherchiert werden, da deutlich weniger Einträge zu finden waren. Hier habe ich auch beobachten können, dass sich die einzelnen Versionen von Xcode stark voneinander unterscheiden und vorgeschlagene Lösungen, die für ein bestimmtes Problem vor zum Beispiel zwei Jahren vorgeschlagen wurden, im neuen Xcode nicht mehr umsetzbar sind. Das machte die Testentwicklung für die iOS-Anwendungen etwas langwieriger als deren Android-Pendants.