Tests auf der Android-Plattform

Das Android Open Source Project (AOSP) bietet mehrere Tools und Test-Suites 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 dem NDK entwickelt 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-System teilnehmen. Dazu gehören die potenzielle Lizenzierung von Google Play, die potenzielle Lizenzierung der App- und API-Suite Google Mobile Services (GMS) und die Verwendung der Android-Marke. Jeder kann den Android-Quellcode verwenden. Damit ein Gerät als Teil des Android-Ökosystems betrachtet wird, muss es jedoch mit Android kompatibel sein.
Artefakt
Ein Build-bezogenes Protokoll, das eine 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 für kommerzielle Zwecke, die als Binärdatei oder als Quelle in AOSP zum Download zur Verfügung steht. Die CTS besteht aus einer Reihe von Unit-Tests, die in Ihren täglichen Workflow integriert werden können. CTS soll Inkompatibilitäten aufdecken und dafür sorgen, dass die Software während des gesamten Entwicklungsprozesses kompatibel bleibt.

CTS- und Plattformtests schließen sich nicht gegenseitig aus. Hier sind einige allgemeine Richtlinien:

  • Wenn ein Test die Korrektheit von Framework-API-Funktionen oder -Verhaltenen bestätigt und der Test für alle OEM-Partner erzwungen werden soll, sollte er im CTS enthalten sein.
  • Wenn ein Test dazu dient, Regressionen während der Plattformentwicklung zu erkennen, möglicherweise eine Berechtigung zum Ausführen erfordert und von Implementierungsdetails abhängt (wie im 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 Abstraktionsschichten niedrigerer Ebene zu oder führen einen Roh-IPC mit verschiedenen Systemdiensten aus. 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 über den Befehl am instrument gestartet wird. Dabei wird der betreffende App-Prozess neu gestartet und mit dem grundlegenden App-Kontext initialisiert. Außerdem wird ein Instrumentierungs-Thread innerhalb der virtuellen Maschine des App-Prozesses gestartet. CTS enthält Instrumentierungstests.

Logcat

Ein Befehlszeilentool, mit dem ein Protokoll mit Systemmeldungen erstellt wird, einschließlich Stack-Traces, wenn das Gerät einen Fehler auslöst, und Meldungen, die Sie über die Log-Klasse aus Ihrer App geschrieben haben.

Logging

Mit einem Protokoll werden Ereignisse des Computersystems wie Fehler erfasst. Die Protokollierung unter Android ist aufgrund der verschiedenen Standards, die im Logcat-Tool kombiniert werden, komplex.

postsubmit test

Ein Android-Test, der ausgeführt wird, wenn ein neuer Patch in einen gemeinsamen Kernel-Branch committet wird. Wenn Sie aosp_kernel als Teil des Branchesnamens 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 wird, dass Fehler in die gemeinsamen Kernel eindringen.

Trade Federation

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

Vendor Test Suite (VTS)

Eine Reihe umfangreicher Funktionen für Android-Tests, die einen testgetriebenen Entwicklungsprozess fördern und die Tests 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 prüft die Richtigkeit des Testergebnisses. Ein Plattformtest kann Folgendes umfassen:

  • (Typ 1) Framework-APIs mit dem Android-Framework üben Beispiele für APIs, die genutzt werden:
    • Öffentliche APIs für Drittanbieter-Apps
    • Ausgeblendete APIs für privilegierte Apps, nämlich System-APIs oder private APIs (@hide, protected oder package private)
  • (Typ 2) Android-Systemdienste direkt über Raw Binder oder IPC-Proxys aufrufen.
  • (Typ 3) Direkte Interaktion mit HALs über Low-Level-APIs oder IPC-Schnittstellen.

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

Und jetzt?

Hier finden Sie eine Liste mit Dokumenten, in denen Sie weitere Informationen finden: