Infrastruktura do automatycznego testowania

Android 9 zawiera infrastrukturę pakietu testów dostawcy (VTS) do automatycznego testowania VTS, CTS lub innych testów na urządzeniach partnerów z systemem AOSP GSI. Wcześniej uruchamianie tych testów było bardzo żmudną czynnością manualną. Nowa infrastruktura testów VTS została zaprojektowana tak, aby obsługiwać automatyczne testowanie wielokrotnie dziennie na wielu urządzeniach.

Architektura

Infrastruktura testowania automatycznego VTS korzysta z tej architektury:

Gdy test zostanie uruchomiony, infrastruktura automatycznego testowania VTS wykonuje te czynności:

1. Pobiera artefakty kompilacji i zasoby testowe z różnych lokalizacji:
   • Partner Android Build (PAB). Dla GSI, platformy VTS i kilku innych kompilacji.
   • Lokalny system plików, Google Cloud Storage lub inny system kompilacji specyficzny dla danego dostawcy. Dla partnerów, którzy nie przechowują kompilacji w chmurze Google.
2. Flashes build artifacts (from the device) and the GSI (from AOSP) onto the connected device(s).
3. Uruchamia testy VTS za pomocą lokalnego interfejsu TradeFed lub interfejsu TradeFed w chmurze.
4. raportuje wyniki testów do panelu VTS;

Proces jest koordynowany przez kontroler hosta VTS (HC), czyli maszynę w laboratorium, która kieruje działaniem wszystkich podłączonych urządzeń będących w trakcie testowania. Centrum pomocy odpowiada za pobieranie najnowszych kompilacji, wyświetlanie ich na urządzeniach i wywoływanie testów (lokalnie lub za pomocą polecenia). Komunikacja odbywa się również z planistą chmury, który kieruje ruchem między planistą a instancją TradeFed (lub innym elementem) działającą na HC. Szczegółowe informacje o kontrolerze hosta znajdziesz w artykule Architektura kontrolera hosta.

Dostawcy zasobów

Testowanie automatyczne wymaga zasobów takich jak kompilacje systemu, pliki testów i artefakty VTS. Chociaż można je skompilować z źródła, łatwiej jest regularnie tworzyć je z tip-of-tree, a potem publikować artefakty do pobrania.

Partnerzy mogą uzyskać dostęp do zasobów automatyzacji w tych lokalizacjach:

• Tworzenie wersji Androida partnera. Dostęp zautomatyzowany przyznawany na poziomie konta.
• Lokalny system plików (lub podobny). Dla partnerów, którzy nie korzystają z kompilacji Androida dla partnerów.

Zasoby do korzystania z flashowania urządzeń obejmują dostawców kompilacji dla obu opcji, rozszerzając pojedynczą usługę build_provider.py, która przechowuje kompilacje w lokalnych katalogach tymczasowych.

Kompilacja Androida dla partnera

W przypadku wersji Androida 8.1 i starszych partnerzy Androida musieli odwiedzić stronę Partner Android Build (https://partner.android.com/build), przejść do swojego konta i pobrać najnowsze obrazy systemu za pomocą interfejsu użytkownika. Aby pomóc partnerom uniknąć tego powolnego i pracochłonnego procesu, Android 9 obsługuje automatyczne pobieranie tych zasobów z PAB po podaniu odpowiednich danych logowania.

Przyznaj dostęp

Dostęp automatyczny do wymaganych RPC korzysta z protokołu OAuth2 w interfejsach API Google. Aby użyć standardowego podejścia do generowania danych logowania OAuth 2, partner musi skonfigurować parę identyfikator klienta/klucz tajny w Google. Gdy PartnerAndroidBuildClient wskazuje ten obiekt tajny po raz pierwszy, otwiera okno przeglądarki, w którym użytkownik może zalogować się na swoje konto Google, i generuje dane logowania OAuth2 niezbędne do przejścia dalej. Dane logowania (token dostępu i token odświeżania) są przechowywane lokalnie, co oznacza, że partnerzy powinni logować się tylko raz.

Żądanie POST do adresu URL

Kliknięcie linku do zasobu w PAB powoduje wysłanie żądania POST zawierającego niezbędne dane dotyczące tego zasobu, w tym:

• build id, build target
• nazwa zasobu
• gałąź
• nazwa kandydata do wersji oraz informacja, czy kandydat jest kompilacją wewnętrzną

Żądanie POST jest odbierane przez metodę downloadBuildArtifact interfejsu buildsvc RPC, która zwraca adres URL, za pomocą którego można uzyskać dostęp do zasobu.

• W przypadku zasobów pakietu APK aplikacji Clockwork Companion adres URL to zrozumiały adres URL hostowany w PAB (który jest chroniony uwierzytelnianiem i dostępny za pomocą odpowiednich danych logowania OAuth2).
• W przypadku innych zasobów adres URL jest długim, niezabezpieczonym adresem URL z wewnętrznego interfejsu API Android Build (który wygasa po 5 minutach).

Pobieranie adresu URL

Aby uniknąć fałszowania żądań z innych witryn, usługa buildsvc RPC wymaga przesłania tokena XSRF wraz z innymi parametrami. Chociaż ten token zwiększa bezpieczeństwo procesu, znacznie utrudnia też dostęp programowy, ponieważ do uzyskania dostępu wymagany jest teraz token (dostępny tylko w JavaScript na stronie PAB).

Aby uniknąć tego problemu, Android 9 zmienia schemat nazewnictwa adresów URL dla wszystkich plików (nie tylko plików APK), tak aby używał przewidywalnych nazw adresów URL na potrzeby dostępu do list artefaktów i adresów URL artefaktów. W PAB używany jest teraz wygodny format adresu URL, który umożliwia partnerom pobieranie zasobów. Skrypty Centrum pomocy mogą łatwo pobierać te pliki APK, ponieważ format adresu URL jest znany, a Centrum pomocy może pominąć problemy z XSRF/plikami cookie, bo nie trzeba w nim pomijać RPC.buildsvc

Lokalny system plików

Mając katalog z listą (lub plikiem ZIP) artefaktów, dostawca kompilacji ustawia odpowiednie obrazy na podstawie zawartości katalogu. Możesz użyć narzędzia gsutil, by skopiować pliki z Google Cloud Storage do katalogu lokalnego.

Kompilacje Flash

Po pobraniu najnowszych obrazów urządzeń na hosta należy je zaktualizować. Jest to realizowane za pomocą standardowych poleceń adb i fastboot oraz podprocesów Pythona na podstawie ścieżek do plików tymczasowych przechowywanych przez dostawców kompilacji.

Obsługiwane działania:

• Wyświetlanie tylko GSI
• Wyświetlanie pojedynczych obrazów z głównego systemu (np. fastboot flash boot boot.img)
• Flashing all images from the main system. Przykład:
  • fastboot flashall (za pomocą wbudowanego narzędzia flashall)
  • fastboot flash (po jednym naraz)

Przeprowadzanie testów

W Androidzie 9 infrastruktura automatycznego testowania VTS obsługuje tylko uprzęże testowe TradeFed, ale w przyszłości można ją rozszerzyć, tak aby obsługiwała inne uprzęże.

Po przygotowaniu urządzeń możesz wywoływać testy za pomocą jednej z tych opcji:

• Jeśli używasz TradeFed lokalnie, w kontrolerze hosta użyj polecenia test, które przyjmuje nazwę planu testu VTS (np. vts-selftest) i uruchamia test.
• Jeśli używasz klastra TradeFed (opcjonalnie połączonego z MTT), w konsoli kontrolera hosta użyj polecenia lease, które sprawdza niewykonane testy.

Jeśli używasz usługi TradeFedCluster, usługa ta działa lokalnie jako menedżer zdalny. W przeciwnym razie testy są wywoływane za pomocą podprocesów Pythona.

Wyniki raportu

Wyniki testów są automatycznie przesyłane do niektórych projektów w panelu VTS przez VtsMultiDeviceTest.