Automatyczna infrastruktura testów

Android 9 zawiera infrastrukturę pakietu testów dostawcy (VTS) do automatycznego testowania VTS, CTS i innych testów na urządzeniach partnerów z podstawowym obrazem systemu (GSI) AOSP. Wcześniej przeprowadzanie tych testów wymagało dużej ilości pracy ręcznej. Nowa infrastruktura testowa VTS została zaprojektowana tak, aby obsługiwać automatyczne testowanie wiele razy dziennie na wielu urządzeniach.

Architektura

Zautomatyzowana infrastruktura testowa VTS korzysta z tej architektury:

Gdy test zostanie uruchomiony, automatyczna infrastruktura testowa VTS wykona te zadania:

1. Pobiera artefakty kompilacji i zasoby testowe z różnych lokalizacji:
   • Partner Android Build (PAB). W przypadku GSI, VTS i niektórych innych kompilacji.
   • Lokalny system plików, Google Cloud Storage lub inny system kompilacji specyficzny dla dostawcy. Dla partnerów, którzy nie przechowują kompilacji w chmurze Google.
2. Wgrywa artefakty kompilacji (z urządzenia) i GSI (z AOSP) na podłączone urządzenia.
3. Uruchamia testy VTS za pomocą lokalnego TradeFed lub TradeFed w chmurze.
4. Raportowanie wyników testów do panelu VTS

Proces jest koordynowany przez kontroler hosta VTS (HC), czyli urządzenie w laboratorium, które steruje działaniem wszystkich podłączonych urządzeń poddawanych testom. HC odpowiada za pobieranie najnowszych kompilacji, wgrywanie ich na urządzenia i wywoływanie testów (lokalnie lub za pomocą narzędzia commander). Komunikuje się też z harmonogramem w chmurze i kieruje ruch między harmonogramem a instancją TradeFed (lub innym narzędziem) działającą na HC. Więcej informacji o kontrolerze hosta znajdziesz w artykule Architektura kontrolera hosta.

Dostawcy zasobów

Testy automatyczne wymagają zasobów, takich jak kompilacje systemu, pliki testowe i artefakty VTS. Można je co prawda tworzyć ze źródeł, ale łatwiej jest regularnie tworzyć je z najnowszej wersji i udostępniać artefakty do pobrania.

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

• Wersja Androida partnera. Dostęp programowy przyznawany na poziomie poszczególnych kont.
• Lokalny system plików (lub podobny). W przypadku partnerów, którzy nie korzystają z wersji Androida dla partnerów.

Zasoby obejmują dostawców kompilacji dla obu opcji, którzy będą używani do późniejszego flashowania urządzeń. Dostawcy ci pochodzą z jednego build_provider.py, który przechowuje kompilacje w lokalnych katalogach tymczasowych.

Kompilacja Androida dla partnerów

W Androidzie 8.1 i starszych wersjach 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.

Ustanawianie dostępu

Dostęp programowy korzysta z protokołu OAuth2 w interfejsach API Google, aby uzyskać dostęp do wymaganych wywołań RPC. Korzystając ze standardowego podejścia do generowania danych logowania OAuth2, partner musi skonfigurować w Google parę identyfikator klienta/tajny klucz. Gdy PartnerAndroidBuildClient po raz pierwszy zostanie skierowany na ten klucz tajny, otworzy okno przeglądarki, w którym użytkownik będzie mógł zalogować się na konto Google. Spowoduje to wygenerowanie danych logowania OAuth2 potrzebnych do dalszego działania. Dane logowania (token dostępu i token odświeżania) są przechowywane lokalnie, co oznacza, że partnerzy powinni logować się tylko raz.

Żądanie POST dotyczące adresu URL

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

• identyfikator kompilacji, cel kompilacji
• nazwa zasobu
• konar
• nazwę wersji kandydującej do publikacji oraz informację, czy jest to kompilacja wewnętrzna.

Żądanie POST jest odbierane przez metodę downloadBuildArtifact interfejsu buildsvc RPC, która zwraca adres URL umożliwiający dostęp do zasobu.

• W przypadku zasobów APK Clockwork Companion adres URL jest czytelnym adresem URL hostowanym na platformie PAB (która jest chroniona przez uwierzytelnianie i dostępna z odpowiednimi danymi logowania OAuth2).
• W przypadku innych zasobów adres URL jest długim, niechronionym adresem URL z wewnętrznego interfejsu Android Build API (który wygasa po 5 minutach).

Pobieranie adresu URL

Aby uniknąć fałszowania żądań z innej witryny, interfejs buildsvc RPC wymaga, aby token XSRF był przesyłany metodą POST wraz z innymi parametrami. Ten token zwiększa bezpieczeństwo procesu, ale utrudnia dostęp programowy, ponieważ jest teraz wymagany do uzyskania dostępu (jest dostępny tylko w JavaScript na stronie PAB).

Aby uniknąć tego problemu, w Androidzie 9 zmieniliśmy schemat nazewnictwa adresów URL wszystkich plików (nie tylko APK), tak aby używać przewidywalnych nazw adresów URL do uzyskiwania dostępu do list artefaktów i adresów URL artefaktów. PAB używa teraz wygodnego formatu adresu URL, który umożliwia partnerom pobieranie zasobów. Skrypty HC mogą łatwo pobierać te pakiety APK, ponieważ format adresu URL jest znany, a HC może obejść problemy z XSRF/plikami cookie, ponieważ nie potrzebuje buildsvc RPC.

Lokalny system plików

Dostawca kompilacji, korzystając z katalogu z listą artefaktów (lub plikiem ZIP), ustawia odpowiednie obrazy na podstawie zawartości katalogu. Za pomocą narzędzia gsutil możesz kopiować pliki z Google Cloud Storage do katalogu lokalnego.

Kompilacje Flash

Po pobraniu najnowszych obrazów urządzenia na hosta należy wgrać je na urządzenia. Odbywa się to 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:

• Flashowanie tylko GSI
• Flashowanie poszczególnych obrazów z systemu głównego (np.fastboot flash boot boot.img)
• Wgrywanie wszystkich obrazów z głównego systemu. Przykład:
  • fastboot flashall (za pomocą wbudowanego narzędzia flashall)
  • fastboot flash (pojedynczo)

Przeprowadzanie testów

W Androidzie 9 infrastruktura testów automatycznych VTS obsługuje tylko platformę testową TradeFed, ale w przyszłości może zostać rozszerzona o obsługę innych platform.

Po przygotowaniu urządzeń możesz wywołać testy, korzystając z jednej z tych opcji:

• Jeśli używasz TradeFed lokalnie, użyj polecenia test w kontrolerze hosta, które przyjmuje nazwę planu testów 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 wyszukuje niezrealizowane przebiegi testów.

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

Raportowanie wyników

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