CTS obsługiwane przez deweloperów

Na tej stronie znajdziesz wskazówki dotyczące korzystania z CTS opracowanego przez deweloperów (CTS-D).

Pokrycie testowe

CTS-D, podobnie jak CTS i CTS Verifier, może egzekwować tylko te wymagania:

  • Wszystkie publiczne interfejsy API opisane w pakiecie SDK dla deweloperów (developer.android.com) dla określonego poziomu interfejsu API.
  • Wszystkie wymagania MUST zawarte w dokumencie definicji zgodności (CDD) Androida dla określonego poziomu interfejsu API.

Wymagania inne niż MUST, takie jak STRONGLY RECOMMENDED, SHOULD i MAY, są opcjonalne i nie można ich testować za pomocą CTS.

Ponieważ wszystkie interfejsy API i wymagania CDD są powiązane z określonym poziomem interfejsu API, wszystkie testy CTS (CTS, CTS-D i CTS Verifier) są powiązane z tym samym poziomem interfejsu API co powiązane z nimi interfejsy API lub wymagania. Jeśli określony interfejs API zostanie wycofany lub zmieniony, odpowiadający mu test musi zostać wycofany lub zaktualizowany.

Reguły tworzenia testów CTS

  • Test musi zawsze dawać ten sam obiektywny wynik.
  • Test musi określać, czy urządzenie przechodzi test, czy nie, poprzez jednorazowe przetestowanie go po wyjęciu z pudełka.
  • Twórcy testów muszą usunąć wszystkie możliwe czynniki, które mogą wpływać na wyniki testów.
  • Jeśli urządzenie wymaga określonego stanu sprzętu, środowiska lub konfiguracji, ta konfiguracja musi być wyraźnie określona w wiadomości o zatwierdzeniu. Przykładowe instrukcje konfiguracji, znajdziesz w artykule Konfigurowanie CTS.
  • Test nie może trwać dłużej niż 6 godzin. Jeśli musi trwać dłużej, w propozycji testu podaj uzasadnienie, abyśmy mogli je sprawdzić.

Oto przykładowy zestaw warunków testowych do testowania ograniczenia aplikacji:

  • Sieć Wi-Fi jest stabilna (w przypadku testu, który z niej korzysta).
  • Podczas testu urządzenie pozostaje nieruchome (lub nie, w zależności od testu).
  • Urządzenie jest odłączone od źródła zasilania, a poziom baterii wynosi X procent.
  • Żadne aplikacje, usługi na pierwszym planie ani usługi działające w tle nie są uruchomione, z wyjątkiem CTS.
  • Podczas działania CTS ekran jest wyłączony.
  • Urządzenie NIE jest urządzeniem isLowRamDevice.
  • Oszczędzanie baterii ani ograniczenia aplikacji nie zostały zmienione w stosunku do stanu „po wyjęciu z pudełka”.

Kryteria uczestnictwa w testach

Akceptujemy nowe testy, które wymuszają zachowanie nieprzetestowane przez dotychczasowe testy CTS, CTS Verifier lub CTS-D. Każdy test, który sprawdza zachowanie wykraczające poza zakres naszego pokrycia testowego, zostanie odrzucony.

Proces przesyłania CTS

  1. Napisz propozycję testu: deweloper aplikacji przesyła propozycję testu za pomocą narzędzia Google Issue Tracker, opisując zidentyfikowany problem i proponując test, który go sprawdzi. Propozycja musi zawierać powiązany identyfikator wymagania CDD. Zespół Androida sprawdza propozycję.
  2. Opracuj test CTS: po zatwierdzeniu propozycji osoba przesyłająca tworzy test CTS w AOSP w najnowszej gałęzi Androida (android17-release). Zespół Androida sprawdza kod i, jeśli zostanie zaakceptowany, wybiera zmianę i scala ją z wewnętrzną gałęzią deweloperską. Szczegółowe informacje znajdziesz w artykule Gdzie mam zgłaszać zmiany w AOSP?.

Wskazówki dotyczące pisania testów CTS-D

  • Postępuj zgodnie z przewodnikiem po stylu kodu Java.
  • Wykonaj wszystkie czynności opisane w artykule Tworzenie CTS.
  • Dodaj testy do odpowiedniego planu testów:
    • Aby dodać nowe testy do planu testów CTS-D, użyj include-filters: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Aby wykluczyć nowe testy z głównego planu testów CTS, użyj exclude-filters: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Rozwiąż wszystkie ostrzeżenia i sugestie errorprone w pliku build_error.log.
  • Zmień bazę zmian na head. Dotyczy to planów testów cts-developer.xml i cts-developer-exclude.xml.
  • Skonsultuj się z osobą kontaktową w Google, aby sprawdzić, czy Twój przypadek testowy można uwzględnić w istniejącym module CTS. Jeśli nie, pomoże Ci ona utworzyć nowy moduł.
  • W przypadku każdego utworzonego modułu testowego utwórz plik OWNERS w nowym katalogu modułu testowego.
    • Plik OWNERS powinien zawierać te informacje uzyskane od właściciela testu w Google, z którym współpracujesz:
    • # Bug component: xxx
    • LDAP właściciela testu w Google
  • W pliku AndroidTest.xml określ te parametry. Przykłady znajdziesz w plikach przykładowych (1, 2) :
    • Instant_app lub not_instant_app
    • secondary_user lub not_secondary_user
    • all_foldable_states lub no_foldable_states
  • Aby określić prawidłowy minSDK, zapoznaj się z dokumentacją <uses-sdk>.
  • Podczas sprawdzania nowych metod testowych, klas lub modułów dodaj je do planu testów CTS-D i wyklucz z głównego planu testów CTS w taki sam sposób jak w przypadku nowych testów.

Uruchom test CTS-D

Uruchom plan testów CTS-D z wiersza poleceń za pomocą run cts --plan cts-developer.

Aby uruchomić konkretny przypadek testowy, użyj polecenia run cts --include-filter "test_module_name test_name".

Informacje o uruchamianiu pełnego CTS znajdziesz w artykule Uruchamianie testów CTS.

Akceptacja i wydanie

Gdy prześlesz prośbę o test, zespół wewnętrzny sprawdzi, czy testuje ona wymaganie CDD lub udokumentowane zachowanie interfejsu API. Jeśli zespół stwierdzi, że test sprawdza prawidłowe wymaganie lub zachowanie, przekaże ten przypadek testowy inżynierowi Google do dalszego sprawdzenia. Inżynier Google skontaktuje się z Tobą i przekaże Ci opinie na temat tego, jak można ulepszyć test, zanim zostanie on zaakceptowany w CTS.

Szczegółowe informacje o harmonogramie wydań CTS znajdziesz w artykule Harmonogram wydań i informacje o gałęziach.