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) na określonym poziomie 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. Przykładowe instrukcje 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 w propozycji testu uzasadnienie, 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 testów 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 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, 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 osoba, która ją przesłała, tworzy test CTS w AOSP w najnowszej gałęzi Androida (android16-qpr2-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?.

Wytyczne 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:
    • 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 w 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 ustalić, 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 w jego katalogu plik OWNERS.
    • 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ą 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 wymaganie lub zachowanie, zespół przekaże ten przypadek testowy 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.