Entwicklergestützte CTS

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

Testabdeckung

CTS-D wie CTS und Die CTS-Prüfung kann nur Folgendes erzwingen:

  • Alle öffentlichen APIs, die im Entwickler-SDK beschrieben werden (developer.android.com) für ein bestimmtes API-Level.
  • Alle MÜSSEN Anforderungen, die in der Android-Kompatibilität Definition Document (CDD) für eine bestimmte API-Ebene.

Anforderungen, die nicht obligatorisch sind (z. B. AUSSCHLIESSLICH EMPFOHLEN, SOLLTE, KÖNNEN), sind optional und können nicht mit CTS getestet werden.

Da alle APIs und CDD-Anforderungen an ein bestimmtes API-Level gebunden sind, gilt für alle CTS die Tests (CTS, CTS-D und CTS Verifier) mit demselben API-Level verbunden sind wie ihre zugehörige APIs oder Anforderungen. Wenn eine bestimmte API verworfen oder geändert wird, muss der entsprechende Test verworfen oder aktualisiert werden.

Regeln für die CTS-Testerstellung

  • Ein Test muss konsistent zum gleichen objektiven Ergebnis führen.
  • Mit einem Test muss ermittelt werden, ob ein Gerät bestanden wird oder nicht. Dazu wird das Gerät getestet. einmal zu verwenden.
  • Ersteller von Tests müssen alle Faktoren entfernen, die sich auf die Testergebnisse auswirken könnten.
  • Wenn ein Gerät einen bestimmten Hardwarezustand/eine bestimmte Umgebung/Einrichtung benötigt, ist diese Einrichtung muss in der Commit-Nachricht klar definiert sein. Beispiele für eine Anleitung zur Einrichtung, Siehe CTS einrichten.
  • Der Test darf maximal sechs Stunden lang sein. Wenn es für einen Zeitraum von sollten Sie die Begründung in Ihrem Testvorschlag angeben, damit wir ihn prüfen können.

Das folgende Beispiel zeigt eine Reihe von Testbedingungen zum Testen einer App: Einschränkung:

  • Das WLAN ist stabil (für einen Test mit WLAN).
  • Das Gerät bleibt während des Tests unbewegt (oder nicht, je nach Test).
  • Das Gerät ist von einer Stromquelle mit X Prozent des Akkustands getrennt.
  • Es werden keine Apps, Dienste im Vordergrund oder Hintergrunddienste ausgeführt, mit Ausnahme von: CTS
  • Der Bildschirm ist bei Ausführung von CTS ausgeschaltet.
  • Das Gerät ist NICHT isLowRamDevice.
  • Die Einschränkungen für den Energiesparmodus oder die App wurden vom die sofort einsatzbereit sind.

Teilnahmeberechtigung für Tests

Wir akzeptieren neue Tests, die ein Verhalten erzwingen, das nicht von der bestehenden CTS getestet wird. CTS Verifier oder CTS-D-Tests. Jeder Test, bei dem ein Verhalten überprüft wird, das nicht zum Umfang gehört unserer Testabdeckung werden abgelehnt.

CTS-Übermittlungsprozess

  1. Testvorschlag schreiben: Ein App-Entwickler reicht mit Problemverfolgung von Google beschreibt das identifizierte Problem und schlägt einen Test vor, dafür. Das Angebot muss die zugehörige CDD-Anforderungs-ID enthalten. Das Android-Team prüft den Vorschlag.
  2. CTS-Test entwickeln: Nachdem ein Angebot genehmigt wurde, erstellt der Antragsteller eine CTS. Test auf AOSP im Hauptzweig (AOSP/main) Das Android-Team prüft den Code.
  3. Test veröffentlichen:Reichen Sie Ihr Änderungsprotokoll am AOSP/main ein und wählen Sie es dann aus der Aktueller androidx-tests-dev-Branch. Der Test ist jetzt öffentlich verfügbar.

Richtlinien für das Schreiben von CTS-D-Tests

  • Folgen Sie dem Java Code Style Guide.
  • Führen Sie alle unter CTS-Entwicklung beschriebenen Schritte aus.
  • Füge deine Tests dem entsprechenden Testplan hinzu:
    • Verwende include-filters, um dem CTS-D-Testplan deine neuen Tests hinzuzufügen: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Verwende exclude-filters, um deine neuen Tests aus dem CTS-Haupttestplan auszuschließen: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Alle errorprone-Warnungen und -Vorschläge in build_error.log verarbeiten.
  • Rebasieren Sie Ihre Änderungen auf head. Dazu gehören cts-developer.xml und cts-developer-exclude.xml Testpläne.
  • Besprechen Sie mit Ihrem technischen Ansprechpartner bei Google, ob Ihr Testlauf durchgeführt wurde. in ein vorhandenes CTS-Modul integriert werden. Wenn das nicht möglich ist, helfen sie dir, um ein neues Modul zu erstellen.
  • Erstellen Sie im neuen Testmodul für jedes neu erstellte Testmodul eine OWNERS-Datei -Verzeichnis.
    • Die Datei OWNERS sollte die folgenden Informationen enthalten: Google-Testinhaber, mit dem Sie zusammenarbeiten:
    • # Bug component: xxx
    • Google Test Inhaber-LDAP
  • Geben Sie in AndroidTest.xml die folgenden Parameter an. Weitere Informationen finden Sie unter die 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
  • Informationen zum Angeben des richtigen minSDK findest du unter <uses-sdk>. Dokumentation.
  • Fügen Sie neue Testmethoden, -klassen oder -module beim Einchecken der CTS-D hinzu. Testplan zu testen und sie wie für den Haupt-CTS-Testplan neue Tests durchführen.

CTS-D-Test ausführen

CTS-D-Testplan über die Befehlszeile ausführen mit run cts --plan cts-developer.

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

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

Akzeptieren und freigeben

Nachdem eine Testanfrage gesendet wurde, wird sie von einem internen Team geprüft, eine CDD-Anforderung oder ein dokumentiertes API-Verhalten getestet. Wenn der Test ob sie eine gültige Anforderung oder ein gültiges Verhalten überprüft, wird diesen Testfall zur weiteren Prüfung an einen Google-Entwickler weiterleiten. Die Google Der Entwickler wird sich mit Ihnen in Verbindung setzen und Ihnen Feedback zur Verbesserung des Tests geben. bevor es in CTS akzeptiert werden kann.

Weitere Informationen finden Sie unter Releasezeitplan und Zweiginformationen .