CTS von Entwicklern

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

Testabdeckung

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

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

Anforderungen, die nicht als „MUSS“ gekennzeichnet sind, z. B. „DRINGEND EMPFOHLEN“, „SOLLTE“ oder „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 auch alle CTS-Tests (CTS, CTS-D und CTS Verifier) an dieselbe API-Ebene 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.
  • Ein Test muss ermitteln, ob ein Gerät die Anforderungen erfüllt oder nicht. Dazu wird das Gerät einmal direkt nach dem Auspacken getestet.
  • Testentwickler müssen alle möglichen Faktoren entfernen, die sich auf die Testergebnisse auswirken könnten.
  • Wenn für ein Gerät eine bestimmte Hardwarekonfiguration, Umgebung oder Einrichtung erforderlich ist, muss diese in der Commit-Nachricht klar definiert sein. Eine Beispielanleitung finden Sie unter CTS einrichten.
  • Der Test darf nicht länger als sechs Stunden am Stück laufen. Wenn er länger laufen muss, geben Sie die Gründe in Ihrem Testvorschlag an, damit wir ihn überprüfen können.

Im Folgenden finden Sie ein Beispiel für eine Reihe von Testbedingungen zum Testen einer App-Beschränkung:

  • Die WLAN-Verbindung ist stabil (für einen Test, der auf WLAN basiert).
  • Das Gerät bleibt während des Tests an derselben Stelle (oder nicht, je nach Test).
  • Das Gerät ist von jeder Stromquelle getrennt und hat einen Akkustand von X Prozent.
  • Es werden keine Apps, Dienste im Vordergrund oder Dienste im Hintergrund ausgeführt, mit Ausnahme von CTS.
  • Das Display ist ausgeschaltet, während CTS ausgeführt wird.
  • Das Gerät ist NICHT isLowRamDevice.
  • Der Energiesparmodus und die App-Beschränkungen wurden seit dem Auspacken nicht geändert.

Testberechtigung

Wir akzeptieren neue Tests, die ein Verhalten erzwingen, das nicht von vorhandenen CTS-, CTS Verifier- oder CTS-D-Tests getestet wird. Alle Tests, die ein Verhalten außerhalb des Umfangs von unserer Testabdeckung prüfen, werden abgelehnt.

CTS-Einreichungsprozess

  1. Testvorschlag erstellen: Ein App-Entwickler reicht über Google Issue Tracker einen Testvorschlag ein, in dem das Problem beschrieben und ein Test vorgeschlagen wird, um es zu überprü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 neuesten Release-Zweig von Android (android17-release). Das Android-Team prüft den Code. Wenn er akzeptiert wird, wird die Änderung ü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-Codestil-Leitfaden.
  • Führen Sie alle Schritte unter CTS-Entwicklung aus.
  • Fügen Sie Ihre Tests dem entsprechenden Testplan hinzu:
    • Verwenden Sie include-filters, um Ihre neuen Tests dem CTS-D-Testplan 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.
  • Beheben Sie alle errorprone-Warnungen und -Vorschläge in build_error.log.
  • Führen Sie für Ihre Änderungen eine Rebase-Operation auf head durch. Dazu gehören die Testpläne cts-developer.xml und cts-developer-exclude.xml.
  • Klären Sie mit Ihrem Google-Ansprechpartner für die Entwicklung, ob Ihr Testfall in ein vorhandenes CTS-Modul aufgenommen werden kann. Wenn das nicht möglich ist, hilft er Ihnen beim Erstellen eines neuen Moduls.
  • 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) für Beispiele:
    • Instant_app oder not_instant_app
    • secondary_user oder not_secondary_user
    • all_foldable_states oder no_foldable_states
  • Die richtige minSDK-Version 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.

Wenn Sie einen bestimmten Testfall ausführen möchten, verwenden Sie run cts --include-filter "test_module_name test_name".

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

Annahme und Release

Nachdem eine Testanfrage eingereicht wurde, prüft ein internes Team, ob damit eine CDD-Anforderung oder ein dokumentiertes API-Verhalten getestet wird. Wenn der Test 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 gibt Ihnen Feedback dazu, 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 Zweigen.