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 alle Drittanbieter-Apps ausgeführt werden können, die von Drittanbietern mit dem Android SDK und dem NDK entwickelt wurden. Android-kompatible Geräte müssen die Anforderungen der Compatibility Definition Document (CDD) und übergeben Sie den Kompatibilitätstest-Suite (Compatibility Test Suite, CTS). 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-Dienste (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 Log, das die lokale Fehlerbehebung ermöglicht.
Kompatibilitätsdefinitionsdokument (CDD)
Ein Dokument, in dem die Software- und Hardwareanforderungen für ein Android-kompatibles Gerät aufgeführt sind.
Kompatibilitätstest-Suite (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 bei einem Test die Richtigkeit von Framework-API-Funktionen oder -Verhaltensweisen bestätigt wird, und der Test für alle OEM-Partner durchgeführt werden soll, sollte er in CTS erfolgen.
  • Wenn ein Test dazu dient, Regressionen während der Plattformentwicklung zu erkennen, für die Ausführung eine Berechtigung erforderlich ist und er von Implementierungsdetails (wie in AOSP veröffentlicht) abhängen kann, 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

Die Verwendung eines Protokolls zum Nachverfolgen von Computersystemereignissen wie als Fehler. 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. Beispiel: Ergebnisse zu android-mainline finden Sie unter https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

presubmit-Test

Test, mit dem verhindert wird, dass Fehler in den gängige Kernel.

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 CTS- und Anbieter-Test-Suite-Tests verwendet.

Vendor Test Suite (VTS)

Eine Reihe umfangreicher Funktionen für Android-Tests, Förderung eines testgesteuerten Entwicklungsprozesses und Automatisierung Hardware-Abstraktionsschicht (HAL) und Betriebssystem-Kernel-Tests

Plattformtesttypen

Plattformtests interagieren in der Regel mit einem oder mehreren Android-Systemen oder HAL-Schichten anwenden, der zu testenden Person und erklärt die Richtigkeit der Testergebnis. Ein Plattformtest kann:

  • (Typ 1) Übungs-Framework-APIs mit dem Android-Framework. Spezifische APIs, kann Folgendes beinhalten:
    • Öffentliche APIs für Drittanbieter-Apps
    • Verborgene APIs, die für privilegierte Apps vorgesehen sind, d. h. 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 in der Regel GTests sind.

Wie geht es weiter?

Hier ist eine Liste von Dokumenten, die Sie lesen können, um ausführlichere Informationen zu erhalten: