CTS obsługiwane przez deweloperów

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

Pokrycie testami

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

  • Wszystkie publiczne interfejsy API opisane w pakiecie SDK dla programistów (developer.android.com) dla określonego poziomu interfejsu API.
  • Wszystkie wymagania MUST zawarte w dokumencie definicji zgodności z Androidem (CDD) 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.

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 przykładowej 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:

  • Sieć Wi-Fi jest stabilna (w przypadku testu, który z niej 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 naładowania baterii wynosi X%.
  • Nie działają ż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 dotyczące aplikacji nie zostały zmienione w stosunku do stanu „po wyjęciu z pudełka”.

Kryteria uczestnictwa w teście

Akceptujemy nowe testy, które wymuszają zachowanie nieobjęte istniejącymi testami CTS, CTS Verifier ani CTS-D. Każdy test, który sprawdza zachowanie wykraczające poza zakres naszego pokrycia testowego, zostanie odrzucony.

Proces przesyłania pakietu 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 (android16-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 CTS Development (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.
    • 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 i sugestie errorprone 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, pomoże Ci utworzyć nowy moduł.
  • W przypadku każdego utworzonego modułu testowego utwórz plik OWNERS w katalogu nowego 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 dodawania 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.

Przeprowadź test 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.

Akceptacja i zwolnienie

Gdy prześlesz prośbę o przeprowadzenie testu, wewnętrzny zespół sprawdzi, czy testuje ona wymaganie CDD lub udokumentowane działanie interfejsu API. Jeśli test sprawdza prawidłowe wymaganie lub zachowanie, zespół przekaże go inżynierowi Google do dalszej analizy. Inżynier Google skontaktuje się z Tobą, aby przekazać Ci opinię 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.