Tests auf der Android-Plattform

Das Open-Source-Projekt für Android (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 alle Drittanbieter-Apps ausgeführt werden können, die von Drittanbieterentwicklern mit dem Android SDK und NDK geschrieben wurden. 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-Dienste (GMD)-Suite mit 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 Build-bezogenes 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 Quelle in AOSP heruntergeladen werden kann. Das CTS ist eine Reihe von Unit-Tests, die in Ihren täglichen Workflow integriert werden sollen. 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 in einem Test die Richtigkeit von Framework-API-Funktionen oder ‑Verhaltensweisen bestätigt wird und der Test bei allen OEM-Partnern erzwungen werden soll, muss er im CTS enthalten sein.
  • Wenn ein Test dazu gedacht ist, Regressionen während der Plattformentwicklung zu erkennen, möglicherweise eine privilegierte Berechtigung für die Durchführung erfordert und von Implementierungsdetails (wie in AOSP veröffentlicht) abhängt, 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 Raw-IPC für verschiedene Systemdienste 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 mit dem Befehl am instrument gestartet wird. Der Ziel-App-Prozess wird neu gestartet und mit dem grundlegenden App-Kontext initialisiert. Außerdem wird ein Instrumentation-Thread in der virtuellen Maschine des App-Prozesses gestartet. Das CTS enthält Instrumentierungstests.

Logcat

Ein Befehlszeilentool, das ein Log von 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 wird verwendet, um Ereignisse im Computersystem, z. B. Fehler, zu verfolgen. Die Protokollierung in Android ist komplex, da im Logcat-Tool verschiedene Standards kombiniert werden.

Test nach der Einreichung

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

Handelsföderation

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 Tests der Compatibility Test Suite und der Vendor Test Suite verwendet.

Vendor Test Suite (VTS)

Eine Reihe umfassender Funktionen für Android-Tests, die einen testorientierten Entwicklungsprozess fördern und das Testen der Hardware-Abstraktionsschicht (Hardware Abstraction Layer, HAL) und des Betriebssystemkernels automatisieren.

Plattformtesttypen

Bei einem Plattformtest wird in der Regel mit einem oder mehreren Android-Systemdiensten oder HAL-Ebenen interagiert, die Funktionen des Testobjekts werden ausgeführt und die Richtigkeit des Testergebnisses wird bestätigt. Ein Plattformtest kann Folgendes umfassen:

  • (Typ 1) Framework-APIs mit dem Android-Framework testen. Die verwendeten APIs können Folgendes umfassen:
    • Öffentliche APIs für Drittanbieter-Apps
    • Verborgene APIs für privilegierte Apps, nämlich System-APIs oder private APIs (@hide oder protected, 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 normalerweise GTests sind.

Und jetzt?

Hier finden Sie eine Liste von Dokumenten, in denen Sie detailliertere Informationen finden: