Arten der CI-Automatisierung

Im Folgenden finden Sie einige typische Formen der Automatisierung, die Sie in Ihrem CI-System verwenden können.

Einfache Jobs

  • Erstellen:Wenn Sie ein Projekt von Grund auf neu erstellen, sorgen Sie dafür, dass die neuen Änderungen korrekt kompiliert werden und alle Bibliotheken und Tools miteinander kompatibel sind.

  • Lint- oder Stilprüfungen:Dieser Schritt ist optional, wird aber empfohlen. Wenn Sie Stilregeln erzwingen und statische Analysen durchführen, können die Codeüberprüfungen präziser und zielgerichteter sein.

  • Lokale oder hostseitige Tests:Sie werden auf dem lokalen Computer ausgeführt, auf dem der Build ausgeführt wird. Unter Android ist dies normalerweise die JVM, sodass sie schnell und zuverlässig sind. Dazu gehören auch Robolectric-Tests.

Instrumentierte Tests

Tests, die auf Emulatoren oder physischen Geräten ausgeführt werden, erfordern eine gewisse Bereitstellung. Sie müssen warten, bis die Geräte gestartet oder verbunden sind, sowie andere Vorgänge, die die Komplexität erhöhen.

Es gibt mehrere Möglichkeiten, instrumentierte Tests für CI auszuführen:

  • Über Gradle Managed Devices können die zu verwendenden Geräte definiert werden (z. B. „Pixel 2 Emulator für API 27“). Außerdem wird die Gerätebereitstellung übernommen.
  • Die meisten CI-Systeme enthalten ein Drittanbieter-Plug-in (auch als "Aktion", "Integration" oder "Schritt" bezeichnet), um Android-Emulatoren zu verarbeiten.
  • Delegieren Sie instrumentierte Tests an eine Gerätefarm wie Firebase Test Lab. Gerätefarmen werden wegen ihrer hohen Zuverlässigkeit verwendet und können auf Emulatoren oder physischen Geräten ausgeführt werden.

Leistungs Regressionstests

Wir empfehlen, zur Überwachung der App-Leistung Benchmark-Bibliotheken zu verwenden. Für die Automatisierung von Leistungstests während der Entwicklung sind physische Geräte erforderlich, um konsistente und realistische Testergebnisse zu gewährleisten.

Das Ausführen von Benchmarks kann lange dauern, insbesondere wenn Sie eine hohe Abdeckung von Code und Nutzerpfaden haben, für die Sie ein Benchmarking durchführen. Anstatt alle Benchmarks für jedes zusammengeführte Feature oder jeden zusammengeführten Commit auszuführen, sollten Sie sie im Rahmen eines regelmäßig geplanten Wartungs-Builds ausführen, z. B. einem nächtlichen Build.

Leistungsüberwachung

Sie können Leistungsabfälle mithilfe der Schrittanpassung überwachen. Durch die Schrittanpassung wird ein rollierendes Fenster der vorherigen Build-Ergebnisse definiert, die Sie mit dem aktuellen Build vergleichen. Bei diesem Ansatz werden mehrere Benchmark-Ergebnisse zu einem Regressionsspezifischen Messwert kombiniert. Sie können die Schrittanpassung anwenden, um das Rauschen während eines Regressionstests zu reduzieren.

Dadurch wird die Wahrscheinlichkeit von falsch positiven Ergebnissen reduziert, die auftreten können, wenn die Benchmark-Zeiten für einen einzelnen Build zu niedrig sind und die Benchmark dann noch einmal normalisiert wird.

Regressionsprüfungen für die Testabdeckung

Die Testabdeckung ist ein Messwert, mit dem Sie und Ihr Team entscheiden können, ob Tests eine Änderung ausreichend abdecken. Dies sollte jedoch nicht der einzige Indikator sein. Üblicherweise richten Sie eine Regressionsprüfung ein, die fehlschlägt oder eine Warnung ausgibt, wenn die Abdeckung relativ zum Basiszweig abnimmt.