Technologia CTS oparta na pomocy deweloperów

Ta strona zawiera wytyczne dotyczące korzystania z usługi CTS opartej na deweloperach (CTS-D).

Zasięg testu

CTS-D, takie jak CTS, Weryfikator CTS, może egzekwować tylko następujące warunki:

  • Wszystkie publiczne interfejsy API opisane w pakiecie SDK dla deweloperów (developer.android.com) dla określonego poziomu interfejsu API.
  • Wszystkie MUSZĄ wymagania uwzględnione w sekcji dotyczącej zgodności z Androidem Dokument definicji dla określonego poziomu interfejsu API (CDD).

Wymagania, które nie są MUSZĄ, takie jak Zdecydowanie ZALECANE, POWINNY MAJ, są opcjonalne i nie można ich przetestować za pomocą CTS.

Wszystkie wymagania dotyczące interfejsów API i CDD są powiązane z konkretnym poziomem interfejsu API, dlatego wszystkie CTS (CTS, CTS-D i weryfikator CTS) są powiązane z tym samym poziomem API związanych z nimi interfejsów API lub wymagań. W przypadku wycofania lub zmiany danego interfejsu API odpowiadający mu test musi zostać wycofany lub zaktualizowany.

Reguły tworzenia testów CTS

  • Test musi konsekwentnie dawać ten sam celowy wynik.
  • Test musi ustalić, czy urządzenie jest zaliczone, czy nie. jeden raz.
  • Twórcy testów muszą usunąć wszystkie możliwe czynniki, które mogą mieć wpływ na ich wyniki.
  • Jeśli urządzenie wymaga określonego stanu sprzętu, środowiska lub konfiguracji, musi być wyraźnie zdefiniowany w komunikacie zatwierdzenia. Na przykład instrukcje konfiguracji Więcej informacji znajdziesz w artykule Konfiguracja CTS.
  • Jednorazowo test nie może trwać dłużej niż 6 godzin. Jeśli ma działać przez podaj uzasadnienie w swojej propozycji testu, abyśmy mogli ją sprawdzić.

Poniżej znajdziesz przykładowy zestaw warunków testowania aplikacji ograniczenie:

  • Wi-Fi działa stabilnie (na potrzeby testu wymagającego użycia 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, którego poziom naładowania baterii wynosi X procent.
  • Żadne aplikacje, usługi działające na pierwszym planie ani usługi w tle nie działają, z wyjątkiem CTS.
  • Podczas działania narzędzia CTS ekran jest wyłączony.
  • Urządzenie NIE jest typu isLowRamDevice.
  • Oszczędzanie baterii / ograniczenia aplikacji nie zostały zmienione w w stanie gotowym do użycia.

Możliwość przeprowadzenia testu

Akceptujemy nowe testy, które wymuszają działanie, które nie jest testowane przez istniejący CTS, lub testami CTS-D. Każdy test sprawdzający zachowanie poza zakresem odrzucenia naszego zasięgu testów.

Proces przesyłania CTS

  1. Pisanie testowej oferty pakietowej: deweloper aplikacji przesyła testową ofertę pakietową, używając atrybutu Google Issue Tracker, opis zidentyfikowanego problemu i proponowanie testu, który zostanie sprawdzony; . Oferta pakietowa musi zawierać powiązany identyfikator wymagań CDD. Zespół Androida sprawdza propozycję.
  2. Opracowywanie testu CTS: po zatwierdzeniu oferty pakietowej przez jej zgłaszający tworzy się CTS. testu w AOSP w gałęzi głównej (AOSP/main). Zespół Androida sprawdza kod.
  3. Opublikuj test: prześlij listę zmian AOSP/main i wybierz ją w najnowsza gałąź 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:
    • Użyj narzędzia include-filters, aby dodać nowe testy do planu testów CTS-D: 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.
  • Rozwiąż wszystkie problemy ze wszystkimi ostrzeżeniami i sugestiami (errorprone) w narzędziu build_error.log.
  • Wprowadź zmiany do head. Obejmuje to cts-developer.xml i cts-developer-exclude.xml planów testów.
  • Skontaktuj się z przedstawicielem zespołu inżynierów Google, aby ustalić, czy Twój przypadek testowy można uwzględnić w istniejącym module CTS. Jeśli to nie pomoże, otrzymasz pomoc utwórz nowy moduł.
  • Dla każdego nowo utworzonego modułu testowego utwórz plik OWNERS w nowym module testowym. katalogu.
    • Plik OWNERS powinien zawierać następujące informacje uzyskane z: właściciela testów Google, z którym współpracujesz:
    • # Bug component: xxx
    • Właściciel testu Google (ldap)
  • W polu AndroidTest.xml określ poniższe parametry. Więcej informacji: przykładowe pliki (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łowy pakiet minSDK, zapoznaj się z sekcją <uses-sdk> dokumentacji.
  • Podczas sprawdzania nowych metod testowania, klas lub modułów dodaj je do sekcji CTS-D. i wykluczyć je z głównego planu testów CTS tak samo jak nowych testów.

Przeprowadź test CTS-D

Uruchamianie planu testów CTS-D z wiersza poleceń za pomocą funkcji 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 zwolnienie

Gdy prześlesz żądanie testowe, zespół wewnętrzny sprawdzi je, aby upewnić się, sprawdza zgodność z wymaganiami CDD lub udokumentowane działanie interfejsu API. Jeśli test to zespół sprawdza słuszne wymagania lub zachowanie, przekaże to zgłoszenie testowe inżynierowi Google do dalszego sprawdzenia. Informacje o Google inżynier skontaktuje się z Tobą i poinformuje, jak możemy ulepszyć test przed zatwierdzeniem w usłudze CTS.

Zobacz Harmonogram publikacji i informacje o oddziałach .