Android-Plattformtests

Das Open-Source-Projekt von Android (AOSP) bietet mehrere Tools und Testsuites. um verschiedene Teile der Implementierung zu testen. Bevor Sie die Seiten in dieser sollten Sie mit den folgenden Begriffen vertraut sein:

Android-kompatibles Gerät
Ein Gerät, auf dem jede von Drittanbietern entwickelte Drittanbieter-App ausgeführt werden kann mit dem Android SDK und NDK. Android-kompatible Geräte müssen die Anforderungen der Compatibility Definition Document (CDD) und übergeben Sie den Kompatibilitätstest-Suite (Compatibility Test Suite, CTS). Mit Android kompatibel Geräte zur Android-Plattform gehören, darunter potenzielle Lizenzierung von Google Play, potenzielle Lizenzierung des der GMD-Suite (Google Mobile Services) und APIs sowie die Verwendung der Marke Android. Jeder ist herzlich dazu eingeladen, Android-Quellcode verwenden, aber um als Teil des Android-Ökosystems zu gelten, muss ein Gerät 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 Android-kompatibles Gerät.
Kompatibilitätstest-Suite (Compatibility Test Suite, CTS)

Eine kostenlose, kommerzielle Testsuite, die als Binär- oder als Download verfügbar ist Quelle in AOSP. Die CTS besteht aus einer Reihe von Einheitentests, Ihren täglichen Arbeitsablauf zu erleichtern. Ziel von CTS ist es, Inkompatibilitäten aufzudecken. um sicherzustellen, 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 bei einem Test Regressionen bei der Plattformentwicklung erkannt werden sollen, und für deren Ausführung möglicherweise eine privilegierte Genehmigung erforderlich ist. Implementierungsdetails (wie in AOSP veröffentlicht), sollte es eine Plattform sein, testen.
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ärprogramme sind in der Regel Zugriff auf untergeordnete Abstraktionsebenen oder reine IPC für verschiedene Systeme . Der Testansatz für GTest ist normalerweise eng mit dem Dienst, der getestet wird. CTS enthält das GTest-Framework.

Instrumentierungstest

Eine spezielle Testausführungsumgebung durch den Befehl am instrument gestartet, wobei der Zielanwendungsprozess wird neu gestartet und mit dem grundlegenden App-Kontext initialisiert. Instrumentierungs-Thread wird innerhalb des App-Prozesses gestartet Maschine. CTS enthält Instrumentierungstests.

Logcat

Ein Befehlszeilentool, das ein Protokoll von Systemmeldungen erstellt, einschließlich Stacktraces, die Aufschluss darüber geben, wann das Gerät einen Fehler ausgibt und welche Meldungen Sie erhalten aus Ihrer App mit der Klasse Log geschrieben wurde.

Logging

Die Verwendung eines Protokolls zum Nachverfolgen von Computersystemereignissen wie als Fehler. Die Protokollierung in Android ist aufgrund der Kombination von Standards komplex, im Logcat-Tool kombiniert.

Test nach dem Senden

Android-Test, der durchgeführt wird, wenn ein neuer Patch an ein Common Kernel Branch. Wenn Sie aosp_kernel als unvollständigen Zweignamen eingeben, sehen Sie eine Liste der Kernel-Zweige mit verfügbaren Ergebnissen. Beispiel: Ergebnisse zu android-mainline finden Sie unter https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.

Vorabtest

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

Handelsföderation

Auch „Tradefed“ genannt, ein kontinuierlicher Test für Tests auf Android-Geräten entwickelt. Beispiel: Tradefed wird verwendet, um Tests der Kompatibilitätstest-Suite und der Vendor Test Suite durchzuführen.

Anbieter-Test-Suite (VTS)

Eine Reihe umfassender Funktionen für Android-Tests, Förderung eines testgesteuerten Entwicklungsprozesses und Automatisierung Hardwareabstraktionsschicht (HAL) und Kerneltests des Betriebssystems

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 mit RAW-Binder oder IPC-Proxys aufrufen .
  • (Typ 3) Interagieren Sie über Low-Level-APIs oder IPC-Schnittstellen direkt mit HALs.

Tests der Typen 1 und 2 sind normalerweise Instrumentierungstests, während Tests des Typs 3 in der Regel GTests.

Wie geht es weiter?

Im Folgenden finden Sie eine Liste von Dokumenten, die Sie lesen können, um ausführlichere Informationen zu erhalten: