Technologia CTS oparta na pomocy deweloperów

Na tej stronie znajdziesz wskazówki dotyczące korzystania z usługi CTS-D (Developer-Powered Content System).

Zakres testów

CTS-D, podobnie jak CTS i CTS Verifier, może narzucać tylko te zasady:

  • Wszystkie publiczne interfejsy API opisane w pakiecie SDK dla programistów (developer.android.com) dla danego poziomu API.
  • Wszystkie wymagania MUST zawarte w dokumentacji z definicją zgodności Androida (CDD) dla danego poziomu interfejsu API.

Wymagania niewymagane, takie jak „MOCNO ZALECANA”, „MOŻNA”, „PODOBNIE” są opcjonalne i nie można ich testować za pomocą CTS.

Wszystkie interfejsy API i wymagania CDD są powiązane z konkretnym 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 określony interfejs API został wycofany lub zmieniony, należy wycofać lub zaktualizować odpowiadający mu test.

Reguły tworzenia testów CTS

  • Test musi zawsze dawać ten sam obiektywny wynik.
  • Test musi określać, czy urządzenie spełnia wymagania, czy nie, testując je tylko raz.
  • Twórcy testów muszą wyeliminować wszystkie czynniki, które mogłyby wpłynąć na wyniki testów.
  • Jeśli urządzenie wymaga określonego stanu, środowiska lub konfiguracji sprzętowej, należy wyraźnie określić tę konfigurację w komunikacie zatwierdzenia. Instrukcje dotyczące konfiguracji znajdziesz w artykule Konfigurowanie usługi CTS.
  • Test nie może trwać dłużej niż 6 godzin. Jeśli test musi trwać dłużej, uzasadnij to w propozycji testu, abyśmy mogli ją sprawdzić.

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

  • stabilność Wi-Fi (w przypadku testu, który korzysta z Wi-Fi);
  • Podczas testu urządzenie pozostaje nieruchome (lub nie, w zależności od wyniku testu).
  • Urządzenie jest odłączone od źródła zasilania i ma poziom naładowania baterii X procent.
  • 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 lub ograniczenia dotyczące aplikacji nie zostały zmienione w porównaniu z domyślnymi ustawieniami.

Możliwość przeprowadzenia testu

Akceptujemy nowe testy, które narzucają zachowanie, które nie jest testowane przez istniejące testy CTS, CTS Verifier lub CTS-D. Każdy test, który sprawdza działanie wykraczające poza zakres naszych testów, zostanie odrzucony.

Proces przesyłania danych do CTS

  1. Przygotowanie propozycji testu: deweloper aplikacji przesyła propozycję testu za pomocą Google Issue Tracker, opisując zidentyfikowany problem i proponowając test, który go zweryfikuje. Propozycja musi zawierać powiązany identyfikator wymagań dotyczących CDD. Zespół Androida sprawdza propozycję.
  2. Opracowywanie testu CTS: po zatwierdzeniu oferty pakietowej jej przesyłający tworzy test CTS w AOSP w gałęzi głównej (AOSP/main). Zespół Androida sprawdza kod.
  3. Opublikuj test: prześlij CL na AOSP/main, a potem wybierz go do najnowszej gałęzi androidx-tests-dev. Test jest teraz dostępny publicznie.

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

  • Postępuj zgodnie z przewodnikiem Java Code Style Guide.
  • Wykonaj wszystkie czynności opisane na stronie Tworzenie pliku 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 narzędzia exclude-filters, aby wykluczyć nowe testy z głównego planu testów CTS: platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml.
  • Zarządzaj wszystkimi errorprone ostrzeżeniami i sugestiam w sekcji build_error.log.
  • Wprowadź zmiany do head. Obejmuje to plany testów cts-developer.xml i cts-developer-exclude.xml.
  • Skontaktuj się z osobą kontaktową z zespołu inżynierów Google, aby ustalić, czy możesz uwzględnić swój przypadek testowy w dotychczasowym module CTS. Jeśli nie uda się tego zrobić, zespół pomoże Ci utworzyć nowy moduł.
  • Dla każdego utworzonego nowego modułu testowego utwórz plik OWNERS w nowym katalogu modułu testowego.
    • Plik OWNERS powinien zawierać te informacje, które uzyskasz od właściciela testu Google, z którym współpracujesz:
    • # Bug component: xxx
    • Właściciel testu Google (ldap)
  • W sekcji AndroidTest.xml podaj te parametry. Przykłady plików 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ą <uses-sdk>.
  • Podczas sprawdzania nowych metod, klas lub modułów testowych dodaj je do planu testów CTS-D i wyklucz je z głównego planu testów CTS w taki sam sposób jak w przypadku nowych testów.

Przeprowadzanie testu CTS-D

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

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

Więcej informacji o przeprowadzaniu pełnej wersji CTS znajdziesz w artykule Przeprowadzanie testów CTS.

Akceptacja i publikacja

Gdy prześlesz żądanie testu, wewnętrzny zespół sprawdzi je, aby upewnić się, że testuje ono wymagania dotyczące CDD lub udokumentowane działanie interfejsu API. Jeśli okaże się, że test sprawdza spełnienie ważnego wymagania lub zachowania, zespół przekaże test inżynierowi Google do dalszej analizy. Inżynier Google skontaktuje się z Tobą, aby poinformować Cię, jak można ulepszyć test, zanim zostanie on zaakceptowany w systemie CTS.

Szczegóły harmonogramu CTS znajdziesz w harmonogramie wersji i informacjach o gałęzi.