Testen der Android-Plattform

AOSP bietet mehrere Tools und Testsuiten zum Testen verschiedener Teile Ihrer Implementierung. Bevor Sie mit diesem Abschnitt fortfahren, sollten Sie mit den folgenden Begriffen vertraut sein:

Android-kompatibles Gerät
Ein Gerät, das jede Drittanbieter-App ausführen kann, die von Drittentwicklern unter Verwendung des 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 sind zur Teilnahme am Android-Ökosystem berechtigt. Dazu gehört die potenzielle Lizenzierung des Google Play Store, die potenzielle Lizenzierung der App- und API-Suite Google Mobile Services (GMS) sowie die Nutzung der Marke Android. Jeder kann gerne den Android-Quellcode verwenden, aber um als Teil des Android-Ökosystems betrachtet zu werden, muss ein Gerät Android-kompatibel sein.
Artefakt
Artefakte sind Build-bezogene Protokolle, die eine lokale Fehlerbehebung ermöglichen.
Kompatibilitätsdefinitionsdokument (CDD)
Ein Dokument, das die Software- und Hardwareanforderungen für ein Android-kompatibles Gerät auflistet.
Kompatibilitätstest-Suite (CTS)

Eine kostenlose, kommerzielle Testsuite, 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 Arbeitsablauf integriert werden können. Ziel von 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. Hier sind einige allgemeine Richtlinien:

  • Wenn ein Test die Korrektheit von Framework-API-Funktionen oder -Verhalten bestätigt und er bei allen OEM-Partnern durchgesetzt werden soll, sollte er im CTS erfolgen.
  • Wenn ein Test darauf abzielt, Regressionen während der Plattformentwicklung abzufangen, für die Ausführung möglicherweise eine privilegierte Berechtigung erforderlich ist und er möglicherweise von Implementierungsdetails (wie in AOSP veröffentlicht) abhängig ist, sollte es sich um einen Plattformtest handeln.
Google Mobile Services (GMS)

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

GoogleTest (GTest)

GTest ist ein C++-Test- und Mocking-Framework. GTest-Binärdateien greifen normalerweise auf Abstraktionsschichten auf niedrigerer Ebene zu oder führen Roh-IPC für verschiedene Systemdienste durch. Der Testansatz für GTest ist normalerweise eng mit dem zu testenden Dienst verknüpft. CTS enthält das GTest-Framework.

Instrumentierungstest

Ein Instrumentierungstest stellt eine spezielle Testausführungsumgebung bereit, die durch den Befehl am instrument gestartet wird, in der der Zielanwendungsprozess neu gestartet und mit dem grundlegenden Anwendungskontext initialisiert wird und ein Instrumentierungsthread innerhalb der virtuellen Maschine des Anwendungsprozesses gestartet wird. CTS enthält Instrumentierungstests.

Logcat

Logcat ist ein Befehlszeilentool, das ein Protokoll von Systemmeldungen erstellt, einschließlich Stack-Traces darüber, wann das Gerät einen Fehler auslöst, und Meldungen, die Sie aus Ihrer App mit der Log Klasse geschrieben haben.

Protokollierung

Unter Protokollierung versteht man die Verwendung eines Protokolls, um Computersystemereignisse, wie z. B. Fehler, zu verfolgen. Die Anmeldung unter Android ist aufgrund der Mischung der verwendeten Standards, die im Logcat-Tool kombiniert werden, komplex.

Postsubmit-Test

Android-Postsubmit-Tests werden durchgeführt, wenn ein neuer Patch in einen gemeinsamen Kernel-Zweig übernommen wird. Wenn Sie aosp_kernel als Teilzweignamen eingeben, können Sie eine Liste der Kernelzweige mit verfügbaren Ergebnissen anzeigen. Ergebnisse für android-mainline finden Sie beispielsweise unter https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid .

Test vorab einreichen

Presubmit-Tests werden verwendet, um zu verhindern, dass Fehler in die allgemeinen Kernel eingeführt werden.

Handelsverband

Trade Federation, auch Tradefed genannt, ist ein kontinuierliches Test-Framework, das für die Durchfü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)

Die Android Vendor Test Suite (VTS) bietet umfangreiche Funktionen für Android-Tests, fördert einen testgesteuerten Entwicklungsprozess und automatisiert HAL- und Betriebssystem-Kernel-Tests.

Plattformtesttypen

Ein Plattformtest interagiert normalerweise mit einem oder mehreren Android-Systemdiensten oder HAL-Schichten (Hardware Abstraction Layer), übt die Funktionalitäten des Testsubjekts aus und stellt die Korrektheit des Testergebnisses sicher. Ein Plattformtest könnte:

  • (Typ 1) Üben Sie Framework-APIs mithilfe des Android-Frameworks aus. Spezifische APIs, die ausgeübt werden, können Folgendes umfassen:
    • Öffentliche APIs für Apps von Drittanbietern
    • Versteckte APIs, die für privilegierte Apps gedacht sind, nämlich System-APIs oder private APIs ( @hide , or protected , package private`)
  • (Typ 2) Rufen Sie Android-Systemdienste direkt über Raw Binder oder IPC-Proxys auf.
  • (Typ 3) Interagieren Sie direkt mit HALs über Low-Level-APIs oder IPC-Schnittstellen.

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

Was kommt als nächstes?

Im Folgenden finden Sie eine Liste der nächsten Dokumente, die Sie lesen könnten: