Entwicklergestützte CTS

Auf dieser Seite werden die Nutzungsrichtlinien für CTS-D (von Entwicklern unterstützte CTS) beschrieben.

Testabdeckung

CTS-D kann wie CTS und CTS Verifier nur Folgendes erzwingen:

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

Nicht verbindliche Anforderungen wie „EMPFOHLENE METHODE“, „SOLLTE“ und „KANN“ sind optional und können nicht mit CTS getestet werden.

Da alle APIs und CDD-Anforderungen an eine bestimmte API-Ebene gebunden sind, sind alle CTS-Tests (CTS, CTS-D und CTS Verifier) an dasselbe API-Level wie die zugehörigen APIs oder Anforderungen gebunden. 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.
  • Mit einem Test muss bestimmt werden, ob ein Gerät die Prüfung besteht oder nicht bestanden wird. Dazu wird das Gerät einmalig getestet.
  • Die Tester müssen alle Faktoren entfernen, die sich auf die Testergebnisse auswirken könnten.
  • Wenn für ein Gerät eine bestimmte Hardwarekonfiguration oder -umgebung erforderlich ist, muss diese Konfiguration in der Commit-Nachricht klar definiert sein. Eine Beispielanleitung zur Einrichtung finden Sie unter CTS einrichten.
  • Der Test darf maximal sechs Stunden lang sein. Wenn der Test länger laufen muss, geben Sie bitte in Ihrem Testvorschlag den Grund dafür an, damit wir ihn prüfen können.

Im Folgenden finden Sie ein Beispiel für Testbedingungen zum Testen einer App-Einschränkung:

  • Das WLAN ist stabil (bei einem Test, der auf WLAN basiert).
  • Das Gerät bleibt während des Tests unbewegt (oder nicht, je nach Test).
  • Das Gerät ist von der Stromversorgung getrennt 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 KEIN isLowRamDevice.
  • Die Energiesparmodus-/App-Einschränkungen wurden nicht geändert.

Voraussetzungen für den Test

Wir akzeptieren neue Tests, die ein Verhalten erzwingen, das nicht von bestehenden CTS-, CTS-Verifier- oder CTS-D-Tests getestet wird. Alle Tests, bei denen ein Verhalten geprüft wird, das nicht in den Testumfang fällt, werden abgelehnt.

CTS-Übermittlungsprozess

  1. Testvorschlag verfassen: Ein App-Entwickler reicht über den Google Issue Tracker einen Testvorschlag ein, in dem er das erkannte Problem beschreibt und einen Test vorschlägt, um es zu prüfen. Der Vorschlag muss die zugehörige CDD-Anforderungen-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 Hauptzweig (AOSP/main). Das Android-Team prüft den Code.
  3. Test veröffentlichen:Reichen Sie Ihre CL am AOSP/main ein und übernehmen Sie sie dann in den neuesten androidx-tests-dev-Branch. Der Test ist jetzt öffentlich verfügbar.

CTS-D-Testrichtlinien

  • Beachten Sie den Java-Code-Styleguide.
  • Führen Sie alle unter CTS-Entwicklung beschriebenen Schritte aus.
  • Füge deine Tests dem entsprechenden Testplan hinzu:
    • Verwenden Sie include-filters, um dem CTS-D-Testplan Ihre neuen Tests hinzuzufügen: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Verwenden Sie exclude-filters, um Ihre neuen Tests aus dem Haupt-CTS-Testplan auszuschließen: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Bearbeiten Sie alle errorprone-Warnungen und build_error.log-Vorschläge.
  • Nehmen Sie einen neuen Basiszweig auf head vor. Dazu gehören die Testpläne cts-developer.xml und cts-developer-exclude.xml.
  • Wenden Sie sich an Ihren Google-Entwickler, um festzustellen, ob Ihr Testfall in ein vorhandenes CTS-Modul aufgenommen werden kann. Andernfalls helfen sie Ihnen, ein neues Modul zu erstellen.
  • Erstellen Sie für jedes neue Testmodul eine OWNERS-Datei im Verzeichnis des neuen Testmoduls.
    • Die OWNERS-Datei sollte die folgenden Informationen enthalten, die Sie von Ihrem Google-Testverantwortlichen erhalten haben:
    • # Bug component: xxx
    • Google-Testinhaber ldap
  • Geben Sie unter AndroidTest.xml die folgenden Parameter an. In den Beispieldateien (1, 2) finden Sie Beispiele:
    • Instant_app oder not_instant_app
    • secondary_user oder not_secondary_user
    • all_foldable_states oder no_foldable_states
  • Informationen zum Angeben der 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 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 Testfall auszuführen.

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

Annahme und Freigabe

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

Weitere Informationen zum CTS-Veröffentlichungszeitplan finden Sie unter Veröffentlichungszeitplan und Informationen zu Branches.