CTS obsługiwane przez deweloperów

Na tej stronie znajdziesz wytyczne dotyczące korzystania z testów CTS-D.

Pokrycie testowe

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

  • Wszystkie publiczne interfejsy API opisane w pakiecie SDK dla programistów (developer.android.com) na określonym poziomie 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 przetestować za pomocą CTS.

Wszystkie interfejsy API i wymagania CDD są powiązane z określonym poziomem interfejsu API, dlatego 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 konkretny interfejs API zostanie wycofany lub zmieniony, odpowiedni test musi zostać wycofany lub zaktualizowany.

Reguły tworzenia testów CTS

  • Test musi zawsze dawać ten sam 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ą wyeliminować wszystkie możliwe czynniki, które mogłyby wpłynąć na wyniki testu.
  • Jeśli urządzenie wymaga określonego stanu sprzętu, środowiska lub konfiguracji, konfiguracja ta musi być wyraźnie określona w komentarzu do zatwierdzenia. Instrukcje dotyczące konfiguracji znajdziesz w artykule Konfigurowanie CTS.
  • Test nie może trwać dłużej niż 6 godzin. Jeśli test ma trwać dłużej, podaj uzasadnienie w propozycji testu, abyśmy mogli je sprawdzić.

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

  • połączenie Wi-Fi jest stabilne (w przypadku testu, który z niego korzysta);
  • Urządzenie pozostaje nieruchome podczas testu (lub nie, w zależności od testu).
  • Urządzenie jest odłączone od źródła zasilania, a poziom baterii wynosi X%.
  • Nie są uruchomione żadne aplikacje, usługi na pierwszym planie ani usługi w tle z wyjątkiem CTS.
  • Podczas uruchamiania CTS ekran jest wyłączony.
  • Urządzenie NIE jest isLowRamDevice.
  • Oszczędzanie baterii i ograniczenia aplikacji nie zostały zmienione w stosunku do stanu fabrycznego.

Kryteria uczestnictwa w teście

Akceptujemy nowe testy, które wymuszają zachowanie nieprzetestowane przez istniejące testy CTS, CTS Verifier lub CTS-D. Każdy test, który sprawdza zachowanie wykraczające poza zakres naszych testów, jest odrzucany.

Proces przesyłania CTS

  1. Napisz propozycję testu: deweloper aplikacji przesyła propozycję testu za pomocą Google Issue Tracker. Opisuje w niej zidentyfikowany problem i proponuje test, który pozwoli go sprawdzić. Oferta musi zawierać powiązany identyfikator wymagania CDD. Zespół Androida sprawdza propozycję.
  2. Opracuj test CTS: po zatwierdzeniu propozycji jej autor tworzy test CTS w AOSP w najnowszej gałęzi Androida (android17-release). Zespół Androida sprawdza kod i jeśli go zaakceptuje, wybiera zmianę i scala ją z wewnętrzną gałęzią deweloperską. Szczegółowe informacje znajdziesz w artykule Gdzie mogę zaproponować zmiany w AOSP?.

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

  • Postępuj zgodnie z przewodnikiem po stylu kodu w Javie.
  • Wykonaj wszystkie czynności opisane w artykule Tworzenie CTS.
  • Dodaj testy do odpowiedniego planu testów:
    • Użyj include-filters, aby dodać nowe testy do planu testów CTS-D: platform/cts/tools/cts-tradefed/res/config/cts-developer.xml.
    • Użyj exclude-filters, aby wykluczyć nowe testy z głównego planu testów CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Obsługuj wszystkie ostrzeżenia errorprone i sugestie w build_error.log.
  • Zmień bazę zmian na head. Obejmuje to plany testów cts-developer.xml i cts-developer-exclude.xml.
  • Skontaktuj się z osobą kontaktową w Google ds. inżynierii, aby dowiedzieć się, czy Twój przypadek testowy można uwzględnić w istniejącym module CTS. Jeśli nie, pomogą Ci 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 Google
  • W sekcji 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łową wartość minSDK, zapoznaj się z dokumentacją elementu <uses-sdk>.
  • Podczas rejestrowania nowych metod, klas lub modułów testowych 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.

Uruchamianie testu CTS-D

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

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

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

Zaakceptowanie i zwolnienie

Po przesłaniu prośby o test wewnętrzny zespół sprawdza, czy testuje ona wymaganie CDD lub udokumentowane działanie interfejsu API. Jeśli test sprawdza prawidłowe wymaganie lub zachowanie, zespół przekazuje go inżynierowi Google do dalszej analizy. Inżynier Google kontaktuje się z Tobą, aby przekazać Ci opinię o tym, jak można ulepszyć test, zanim zostanie on zaakceptowany w CTS.

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