Vom Entwickler unterstütztes CTS

Auf dieser Seite werden die Nutzungsrichtlinien für Developer-Powered CTS (CTS-D) 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 MUSS-Anforderungen, die im Android Compatibility Definition Document (CDD) für eine bestimmte API-Ebene enthalten sind.

Nicht-MUSS-Anforderungen wie DRINGEND EMPFOHLEN, SOLLTEN, DÜRFEN 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 dieselbe API-Ebene gebunden wie die zugehörigen APIs oder Anforderungen. Wenn eine bestimmte API veraltet ist oder geändert wird, muss der entsprechende Test veraltet oder aktualisiert werden.

CTS-Testerstellungsregeln

  • Ein Test muss stets das gleiche objektive Ergebnis liefern.
  • Bei einem Test muss festgestellt werden, ob ein Gerät die Prüfung besteht oder nicht, indem das Gerät einmal im Auslieferungszustand getestet wird.
  • Testersteller müssen alle möglichen Faktoren beseitigen, die die Testergebnisse beeinflussen könnten.
  • Wenn ein Gerät eine bestimmte Hardwarebedingung/-umgebung/-konfiguration benötigt, muss diese Konfiguration in der Commit-Nachricht klar definiert werden. Beispiel-Einrichtungsanweisungen finden Sie unter Einrichten von CTS .
  • Der Test darf nicht länger als 6 Stunden am Stück laufen. Sollte eine längere Laufzeit erforderlich sein, fügen Sie bitte die Begründung Ihrem Testvorschlag bei, damit wir ihn prüfen können.

Im Folgenden finden Sie einen Beispielsatz von Testbedingungen zum Testen einer App-Einschränkung:

  • WLAN ist stabil (für einen Test, der auf WLAN basiert).
  • Das Gerät bleibt während des Tests stationär (oder auch nicht, je nach Test).
  • Das Gerät ist bei X Prozent Akkustand von der Stromquelle getrennt.
  • Außer CTS werden keine Apps, Vordergrunddienste oder Hintergrunddienste ausgeführt.
  • Der Bildschirm ist während der Ausführung von CTS ausgeschaltet.
  • Das Gerät ist NICHT isLowRamDevice .
  • Die Batteriespar-/App-Einschränkungen wurden gegenüber dem „Out-of-the-box“-Zustand nicht geändert.

Testberechtigung

Wir akzeptieren neue Tests, die ein Verhalten erzwingen, das nicht durch bestehende CTS-, CTS-Verifier- oder CTS-D-Tests getestet wird. Jeder Test, der ein Verhalten prüft, das außerhalb unseres Testumfangs liegt, wird abgelehnt.

CTS-Einreichungsprozess

  1. Schreiben Sie einen Testvorschlag: Ein App-Entwickler reicht mithilfe von Google Issue Tracker einen Testvorschlag ein, in dem er das identifizierte Problem beschreibt und einen Test zur Überprüfung vorschlägt. Der Vorschlag muss die zugehörige CDD-Anforderungs-ID enthalten. Das Android-Team prüft den Vorschlag.
  2. Entwickeln Sie einen CTS-Test: Nachdem ein Vorschlag genehmigt wurde, erstellt der Einreicher einen CTS-Test für AOSP im Hauptzweig (AOSP/main). Das Android-Team überprüft den Code.
  3. Test veröffentlichen: Senden Sie Ihren CL auf AOSP/main und wählen Sie ihn dann im neuesten androidx-tests-dev Zweig aus. Der Test ist jetzt öffentlich verfügbar.

Richtlinien zum Verfassen von CTS-D-Tests

  • Befolgen Sie den Java Code Style Guide .
  • Befolgen Sie alle in CTS-Entwicklung beschriebenen Schritte.
  • Fügen Sie Ihre Tests dem entsprechenden Testplan hinzu:
    • Verwenden Sie include-filters um Ihre neuen Tests zum CTS-D-Testplan hinzuzufügen: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml .
    • Verwenden Sie exclude-filters , um Ihre neuen Tests vom Haupttestplan von CTS auszuschließen: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml .
  • Behandeln Sie alle errorprone Warnungen und Vorschläge in build_error.log .
  • Rebasieren Sie Ihre Änderungen an head . Dazu gehören die Testpläne cts-developer.xml und cts-developer-exclude.xml .
  • Arbeiten Sie mit Ihrem technischen Ansprechpartner bei Google zusammen, um zu ermitteln, ob Ihr Testfall in ein vorhandenes CTS-Modul aufgenommen werden kann. Wenn dies nicht möglich ist, helfen sie Ihnen beim Erstellen eines neuen Moduls.
  • Erstellen Sie für jedes neu erstellte Testmodul eine OWNERS-Datei im neuen Testmodulverzeichnis.
    • Ihre OWNERS-Datei sollte die folgenden Informationen enthalten, die Sie vom Google-Testinhaber erhalten haben, mit dem Sie zusammenarbeiten:
    • # Bug component: xxx
    • Google-Testbesitzer-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 Angeben des richtigen minSDK finden Sie in der <uses-sdk>-Dokumentation .
  • Wenn Sie neue Testmethoden, Klassen oder Module einchecken, fügen Sie diese dem CTS-D-Testplan hinzu und schließen Sie sie auf die gleiche Weise wie bei neuen Tests aus dem Haupt-CTS-Testplan aus.

Führen Sie Ihren CTS-D-Test durch

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

Um einen bestimmten Testfall auszuführen, verwenden Sie run cts --include-filter "test_module_name test_name" .

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

Annahme und Freigabe

Sobald eine Testanfrage eingereicht wurde, wird sie von einem internen Team überprüft, um sicherzustellen, dass eine CDD-Anforderung oder ein dokumentiertes API-Verhalten getestet wird. Wenn festgestellt wird, dass 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-Techniker weiter. Der Google-Ingenieur wird sich mit Ihnen in Verbindung setzen und Ihnen Feedback dazu geben, wie der Test verbessert werden kann, bevor er in CTS akzeptiert werden kann.

Einzelheiten zum CTS-Veröffentlichungsplan finden Sie unter Veröffentlichungsplan und Brancheninformationen .