CTS zasilany przez programistę

Na tej stronie przedstawiono wytyczne dotyczące korzystania z oprogramowania CTS obsługiwanego przez programistę (CTS-D).

Pokrycie testowe

CTS-D, podobnie jak CTS i CTS Verifier, może egzekwować tylko następujące elementy:

  • Wszystkie publiczne interfejsy API opisane w pakiecie SDK dla programistów (developer.android.com) dla określonego poziomu interfejsu API.
  • Wszystkie wymagania MUSZĄ zawarte w dokumencie definicji zgodności systemu Android (CDD) dla określonego poziomu interfejsu API.

Wymagania inne niż MUSZĄ, takie jak ZDECYDOWANIE ZALECANY, POWINNO, MOŻE, są opcjonalne i nie można ich przetestować za pomocą CTS.

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

Zasady tworzenia testów CTS

  • Test musi konsekwentnie dawać ten sam obiektywny wynik.
  • Test musi określić, czy urządzenie przejdzie pomyślnie, czy nie, testując je jednorazowo po wyjęciu z pudełka.
  • Twórcy testów muszą usunąć wszystkie możliwe czynniki, które mogłyby wpłynąć na wyniki testu.
  • Jeśli urządzenie wymaga określonego stanu sprzętowego/środowiska/konfiguracji, konfiguracja ta musi być jasno zdefiniowana w komunikacie zatwierdzenia. Przykładowe instrukcje konfiguracji można znaleźć w sekcji Konfigurowanie CTS .
  • Jednorazowy test nie może trwać dłużej niż 6 godzin. Jeśli konieczne jest dłuższe działanie, prosimy o dołączenie uzasadnienia do propozycji testu, abyśmy mogli ją sprawdzić.

Poniżej znajduje się przykładowy zestaw warunków testowych do testowania ograniczeń aplikacji:

  • Wi-Fi jest stabilne (dla testu opierającego się na Wi-Fi).
  • Urządzenie pozostaje nieruchome podczas testu (lub nie, w zależności od testu).
  • Urządzenie jest odłączone od źródła zasilania, gdy poziom naładowania baterii wynosi X procent.
  • Żadne aplikacje, usługi na pierwszym planie ani usługi w tle nie są uruchomione, z wyjątkiem CTS.
  • Ekran jest wyłączony podczas działania CTS.
  • Urządzenie NIE jest isLowRamDevice .
  • Ograniczenia oszczędzania baterii/aplikacji nie uległy zmianie w porównaniu ze stanem fabrycznym.

Kwalifikowalność testu

Akceptujemy nowe testy, które wymuszają zachowanie, które nie jest testowane przez istniejące testy CTS, CTS Verifier lub CTS-D. Każdy test sprawdzający zachowanie wykraczające poza zakres naszych testów zostanie odrzucony.

Proces składania CTS

  1. Napisz propozycję testu: twórca aplikacji przesyła propozycję testu za pomocą narzędzia Google Issue Tracker , opisując zidentyfikowany problem i proponując test w celu jego sprawdzenia. Oferta musi zawierać powiązany identyfikator wymagania CDD . Zespół Androida sprawdza tę propozycję.
  2. Opracuj test CTS: Po zatwierdzeniu propozycji zgłaszający tworzy test CTS na AOSP w głównej (AOSP/głównej) gałęzi. Zespół Androida sprawdza kod.
  3. Opublikuj test: prześlij swoją licencję CL na AOSP/main , a następnie wybierz ją do najnowszej gałęzi androidx-tests-dev . Test jest już publicznie dostępny.

Wytyczne dotyczące pisania testów CTS-D

  • Postępuj zgodnie z Przewodnikiem po stylu kodu Java .
  • Wykonaj wszystkie kroki opisane w CTS Development .
  • Dodaj swoje 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 errorprone ostrzeżenia 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ę ze swoim inżynierem Google, aby ustalić, czy Twój przypadek testowy można uwzględnić w istniejącym module CTS. Jeśli nie, pomogą Ci stworzyć nowy moduł.
  • Dla każdego nowo utworzonego modułu testowego utwórz plik OWNERS w katalogu nowego modułu testowego.
    • Twój plik OWNERS powinien zawierać następujące informacje uzyskane od właściciela testu Google, z którym współpracujesz:
    • # Bug component: xxx
    • Właściciel testu Google ldap
  • W AndroidTest.xml określ następujące parametry. Przykłady można znaleźć w przykładowych plikach ( 1 , 2 ):
    • Instant_app lub not_instant_app
    • secondary_user lub not_secondary_user
    • all_foldable_states lub no_foldable_states
  • Aby określić poprawny minSDK, zapoznaj się z dokumentacją <uses-sdk> .
  • Meldując nowe metody, zajęcia lub moduły testów, należy je dodać do planu testów CTS-D i wykluczyć 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ń, używając run cts --plan cts-developer .

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

Aby uzyskać informacje na temat uruchamiania pełnego CTS, zobacz Uruchamianie testów CTS .

Akceptacja i uwolnienie

Po przesłaniu żądania testu wewnętrzny zespół sprawdzi je, aby upewnić się, że testuje wymagania CDD lub udokumentowane zachowanie interfejsu API. Jeśli okaże się, że test sprawdza prawidłowe wymaganie lub zachowanie, zespół przekaże ten przypadek testowy inżynierowi Google w celu dalszego sprawdzenia. Inżynier Google skontaktuje się z Tobą i przekaże informacje o tym, jak można ulepszyć test, zanim będzie można go zaakceptować w programie CTS.

Aby uzyskać szczegółowe informacje na temat harmonogramu wydań CTS, zobacz Harmonogram wydań i informacje o oddziałach .