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 MUST-Anforderungen, die im Android Compatibility Definition Document (CDD) für eine bestimmte API-Ebene enthalten sind.

Anforderungen, die keine MUST-Anforderungen sind, z. B. STRONGLY RECOMMENDED, SHOULD und MAY, 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 den Test besteht 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 Einrichtung in der Commit-Nachricht klar definiert sein. Eine Beispielanleitung finden Sie unter CTS einrichten.
  • Der Test darf nicht länger als 6 Stunden am Stück ausgeführt werden. Wenn er länger ausgeführt werden muss, geben Sie bitte die Gründe in Ihrem Testvorschlag an, damit wir ihn überprüfen können.

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

  • WLAN ist stabil (für einen Test, der auf WLAN basiert).
  • Das Gerät bleibt während des Tests an einem Ort (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.
  • Die Einstellungen für den 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 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 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 für das Schreiben von CTS-D-Tests

  • Halten Sie sich an den Java Code Style Guide.
  • 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 ein Rebase auf head durch. Dazu gehören die Testpläne cts-developer.xml und cts-developer-exclude.xml.
  • Fragen Sie Ihren technischen Ansprechpartner bei Google, 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 neuen Testmodulverzeichnis.
    • 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 Veröffentlichung

Sobald 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.