CTS von Entwicklern

Auf dieser Seite finden Sie die Richtlinien für die Verwendung von CTS-D (Developer-Powered CTS).

Testabdeckung

Mit CTS-D können wie mit CTS und CTS Verifier nur die folgenden Anforderungen durchgesetzt werden:

  • Alle öffentlichen APIs, die im Entwickler-SDK (developer.android.com) für ein bestimmtes API-Level beschrieben sind.
  • Alle MUST-Anforderungen, die im Android Compatibility Definition Document (CDD) für ein bestimmtes API-Level enthalten sind.

Anforderungen, die nicht als MUST gekennzeichnet sind, z. B. STRONGLY RECOMMENDED, SHOULD oder MAY, sind optional und können nicht mit dem CTS getestet werden.

Da alle APIs und CDD-Anforderungen an ein bestimmtes API-Level gebunden sind, sind auch alle CTS-Tests (CTS, CTS-D und CTS Verifier) an dasselbe API-Level gebunden wie die zugehörigen APIs oder Anforderungen. Wenn eine bestimmte API eingestellt oder geändert wird, muss der entsprechende Test eingestellt oder aktualisiert werden.

Regeln für die CTS-Testerstellung

  • Ein Test muss immer dasselbe objektive Ergebnis liefern.
  • Bei einem Test muss ermittelt werden, ob ein Gerät besteht oder nicht. Dazu wird das Gerät einmal direkt nach dem Auspacken getestet.
  • Testentwickler müssen alle möglichen Faktoren entfernen, die die Testergebnisse beeinflussen könnten.
  • Wenn ein Gerät bestimmte Hardwarebedingungen, Umgebungsbedingungen oder eine bestimmte Einrichtung benötigt, muss diese Einrichtung in der Commit-Nachricht klar definiert werden. Eine Beispielanleitung finden Sie unter CTS einrichten.
  • Der Test darf nicht länger als 6 Stunden am Stück laufen. Wenn der Test länger laufen muss, geben Sie bitte die Gründe dafür in Ihrem Testvorschlag an, damit wir ihn prüfen können.

Im Folgenden finden Sie eine Reihe von Testbedingungen zum Testen einer App-Einschränkung:

  • Das WLAN ist stabil (für einen Test, der auf WLAN basiert).
  • Das Gerät bleibt während des Tests an seinem Platz (oder nicht, je nach Test).
  • Das Gerät ist nicht mit einer Stromquelle verbunden und der Akkustand beträgt X %.
  • Es werden keine Apps, Dienste im Vordergrund oder Dienste im Hintergrund ausgeführt, mit Ausnahme von CTS.
  • Das Display ist während der Ausführung von CTS ausgeschaltet.
  • Das Gerät ist NICHT isLowRamDevice.
  • Der Energiesparmodus / die App-Beschränkungen wurden seit dem Auspacken nicht geändert.

Voraussetzungen für Tests

Wir akzeptieren neue Tests, die ein Verhalten erzwingen, das nicht durch vorhandene CTS-, CTS Verifier- oder CTS-D-Tests getestet wird. Tests, die ein Verhalten außerhalb des Testabdeckungsbereichs prüfen, werden abgelehnt.

CTS-Einreichungsprozess

  1. Testvorschlag erstellen:Ein App-Entwickler reicht über den Google Issue Tracker einen Testvorschlag ein, in dem das Problem beschrieben und ein Test vorgeschlagen wird, um es zu prüfen. Der Vorschlag muss die zugehörige CDD-Anforderungs-ID enthalten. Das Android-Team prüft den Vorschlag.
  2. CTS-Test entwickeln:Nachdem ein Vorschlag genehmigt wurde, erstellt der Einreicher einen CTS-Test in AOSP im Branch für die aktuelle Android-Version (android16-release). Das Android-Team prüft den Code und wenn er akzeptiert wird, wird die Änderung per Cherry-Pick übernommen und in den internen Entwicklungszweig zusammengeführt. Weitere Informationen finden Sie unter Wo kann ich Änderungen an AOSP vorschlagen?.

Richtlinien zum Schreiben von CTS-D-Tests

  • Halten Sie sich an den Java Code Style Guide.
  • Führen Sie alle Schritte aus, die unter CTS-Entwicklung beschrieben sind.
  • Fügen Sie Ihre Tests dem entsprechenden Testplan hinzu:
    • Verwenden Sie include-filters, um dem CTS-D-Testplan platform/cts/tools/cts-tradefed/res/config/cts-developer.xml Ihre neuen Tests hinzuzufügen.
    • Verwenden Sie exclude-filters, um Ihre neuen Tests aus dem Haupt-CTS-Testplan platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml auszuschließen.
  • Beheben Sie alle errorprone-Warnungen und -Vorschläge in build_error.log.
  • Führen Sie ein Rebase Ihrer Änderungen auf head durch. Dazu gehören die Testpläne cts-developer.xml und cts-developer-exclude.xml.
  • Wenden Sie sich an Ihren Google-Ansprechpartner für technische Fragen, um zu klären, ob Ihr Testlauf in ein vorhandenes CTS-Modul aufgenommen werden kann. Wenn das nicht möglich ist, helfen sie Ihnen, ein neues Modul zu erstellen.
  • Erstellen Sie für jedes neue Testmodul eine OWNERS-Datei im Verzeichnis des neuen Testmoduls.
    • Ihre OWNERS-Datei sollte die folgenden Informationen enthalten, die Sie vom Google-Testinhaber erhalten, mit dem Sie zusammenarbeiten:
    • # Bug component: xxx
    • Google-Testinhaber-LDAP
  • Geben Sie in AndroidTest.xml die folgenden Parameter an. Beispiele finden Sie in den Beispieldateien (1, 2):
    • Instant_app oder not_instant_app
    • secondary_user oder not_secondary_user
    • all_foldable_states oder no_foldable_states
  • Informationen zum Festlegen des richtigen minSDK finden Sie in der Dokumentation zu <uses-sdk>.
  • Wenn Sie neue Testmethoden, ‑klassen oder ‑module einchecken, fügen Sie sie dem CTS-D-Testplan hinzu und schließen Sie sie auf dieselbe Weise wie bei neuen Tests aus dem Haupt-CTS-Testplan aus.

CTS-D-Test ausführen

Führen Sie den CTS-D-Testplan über die Befehlszeile mit run cts --plan cts-developer aus.

Verwenden Sie run cts --include-filter "test_module_name test_name", um einen bestimmten Testlauf auszuführen.

Informationen zum Ausführen des vollständigen CTS finden Sie unter CTS-Tests ausführen.

Annahme und Freigabe

Nachdem eine Testanfrage eingereicht wurde, prüft ein internes Team, ob damit eine CDD-Anforderung oder ein dokumentiertes API-Verhalten getestet wird. Wenn festgestellt wird, dass mit dem Test eine gültige Anforderung oder ein gültiges Verhalten überprüft wird, leitet das Team diesen Testfall zur weiteren Überprüfung an einen Google-Entwickler weiter. Der Google-Techniker wird sich mit Feedback dazu bei Ihnen melden, wie der Test verbessert werden kann, bevor er in CTS aufgenommen werden kann.

Weitere Informationen zum CTS-Releaseplan finden Sie unter Releaseplan und Informationen zu Branches.