Tests auf der Android-Plattform

Das Open-Source-Projekt für Android (Android Open Source Project, AOSP) bietet mehrere Tools und Testsuiten zum Testen verschiedener Teile Ihrer Implementierung. Bevor Sie die Seiten in diesem Abschnitt verwenden, sollten Sie mit den folgenden Begriffen vertraut sein:

Android-kompatibles Gerät
Ein Gerät, auf dem jede Drittanbieter-App ausgeführt werden kann, die von Drittanbietern mit dem Android SDK und NDK geschrieben wurde. Android-kompatible Geräte müssen die Anforderungen des Compatibility Definition Document (CDD) erfüllen und die Compatibility Test Suite (CTS) bestehen. Android-kompatible Geräte können am Android-Ökosystem teilnehmen. Dazu gehören die potenzielle Lizenzierung von Google Play, die potenzielle Lizenzierung der Google Mobile Services (GMS) Suite von Apps und APIs sowie die Verwendung der Android-Marke. Jeder kann den Android-Quellcode verwenden. Damit ein Gerät jedoch als Teil des Android-Ökosystems gilt, muss es Android-kompatibel sein.
Artefakt
Ein buildbezogenes Log, das die lokale Fehlerbehebung ermöglicht.
Compatibility Definition Document (CDD)
Ein Dokument, in dem die Software- und Hardwareanforderungen für ein Android-kompatibles Gerät aufgeführt sind.
Compatibility Test Suite (CTS)

Eine kostenlose Testsuite in kommerzieller Qualität, die als Binärdatei oder als Quellcode in AOSP heruntergeladen werden kann. Die CTS ist eine Reihe von Unit-Tests, die in Ihren täglichen Workflow integriert werden können. Ziel der CTS ist es, Inkompatibilitäten aufzudecken und sicherzustellen, dass die Software während des gesamten Entwicklungsprozesses kompatibel bleibt.

CTS- und Plattformtests schließen sich nicht gegenseitig aus. Allgemeine Richtlinien:

  • Wenn ein Test die Korrektheit von Framework-API-Funktionen oder -Verhaltensweisen bestätigt und der Test für alle OEM-Partner erzwungen werden soll, muss er in der CTS enthalten sein.
  • Wenn ein Test Regressionen während der Plattformentwicklung erkennen soll, möglicherweise eine Berechtigung mit erhöhten Rechten erfordert und von Implementierungsdetails abhängt (wie in AOSP veröffentlicht), sollte es sich um einen Plattformtest handeln.
Google Mobile-Dienste (GMD)

Eine Sammlung von Google-Apps und APIs, die auf Geräten vorinstalliert werden können.

GoogleTest (GTest)

Ein C++-Test- und Mocking-Framework. GTest-Binärdateien greifen in der Regel auf Abstraktionsebenen niedrigerer Ebene zu oder führen eine direkte IPC-Kommunikation mit verschiedenen Systemdiensten durch. Der Testansatz für GTest ist in der Regel eng mit dem zu testenden Dienst verknüpft. CTS enthält das GTest-Framework.

Instrumentierungstest

Eine spezielle Testausführungsumgebung, die mit dem Befehl am instrument gestartet wird. Dabei wird der Ziel-App-Prozess neu gestartet und mit einem grundlegenden App-Kontext initialisiert. Außerdem wird ein Instrumentierungs-Thread in der virtuellen Maschine des App-Prozesses gestartet. CTS enthält Instrumentierungstests.

Logcat

Ein Befehlszeilentool, das ein Log mit Systemmeldungen erstellt, einschließlich Stacktraces, wenn das Gerät einen Fehler ausgibt, und Meldungen, die Sie mit der Klasse Log aus Ihrer App geschrieben haben.

Logging

Ein Log verwenden, um Computerereignisse wie Fehler zu verfolgen. Das Logging in Android ist komplex, da verschiedene Standards verwendet werden, die im Logcat-Tool kombiniert werden.

Postsubmit-Test

Ein Android-Test, der ausgeführt wird, wenn ein neuer Patch in einen gemeinsamen Kernel-Branch übernommen wird. Wenn Sie aosp_kernel als Teil des Branch-Namens eingeben, wird eine Liste der Kernel-Branches mit verfügbaren Ergebnissen angezeigt. Ergebnisse für android-mainline finden Sie beispielsweise unter https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

Presubmit-Test

Ein Test, mit dem verhindert werden soll, dass Fehler in die gemeinsamen Kernel eingeführt werden.

Trade Federation

Auch Tradefed genannt, ein kontinuierliches Testframework, das für die Ausführung von Tests auf Android-Geräten entwickelt wurde. Tradefed wird beispielsweise verwendet, um Tests der Compatibility Test Suite und der Vendor Test Suite auszuführen.

Vendor Test Suite (VTS)

Eine Reihe umfassender Funktionen für Android-Tests, die einen testgetriebenen Entwicklungsprozess fördern und das Testen der Hardwareabstraktionsschicht (HAL) und des Betriebssystemkernels automatisieren.

Plattformtesttypen

Ein Plattformtest interagiert in der Regel mit einem oder mehreren Android-Systemdiensten oder HAL-Ebenen, testet die Funktionen des Testobjekts und bestätigt die Korrektheit des Testergebnisses. Ein Plattformtest kann Folgendes umfassen:

  • (Typ 1) Framework-APIs mit dem Android-Framework testen. Zu den spezifischen APIs, die getestet werden, gehören:
    • Öffentliche APIs für Drittanbieter-Apps
    • Versteckte APIs für Apps mit erhöhten Rechten, nämlich System-APIs oder private APIs (@hide oder protected, package private)
  • (Typ 2) Android-Systemdienste direkt mit Raw-Binder- oder IPC-Proxys aufrufen.
  • (Typ 3) Direkt mit HALs über APIs auf niedriger Ebene oder IPC-Schnittstellen interagieren.

Tests vom Typ 1 und 2 sind in der Regel Instrumentierungstests, während Tests vom Typ 3 normalerweise GTests sind.

Nächste Schritte

Hier finden Sie eine Liste von Dokumenten mit weiteren Informationen: