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 kilka razy dziennie na wielu urządzeniach.

Architektura

Infrastruktura automatycznego testowania 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: VTS i kilka innych kompilacji.
   • Lokalny system plików, Google Cloud Storage lub inny system kompilacji specyficzny dla danego dostawcy. Dla partnerów, którzy nie przechowują wersji w chmurze Google.
2. Migawki kompilują artefakty (z urządzenia) i GSI (z AOSP) w połączonych urządzeń.
3. Uruchamia testy VTS za pomocą lokalnego interfejsu TradeFed lub interfejsu TradeFed w chmurze.
4. Raportuje wyniki testu w 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. HC odpowiada za pobieranie najnowszych wersji, instalowanie ich na urządzeniach i uruchamianie 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. Więcej informacji: kontrolera hosta, patrz sekcja Host Architektura kontrolera.

Dostawcy zasobów

Automatyczne testowanie wymaga zasobów, takich jak kompilacje systemu, pliki testowe Artefakty VTS. Chociaż można je tworzyć na podstawie źródeł, łatwiej jest je i regularnie budować je od czubka drzewa, a potem publikować artefakty do pobrania.

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

• Partner Android Build. dla każdego konta.
• Lokalny system plików (lub podobny). Dla partnerów, którzy nie używać kompilacji Androida partnera.

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 pobierz te zasoby z PAB, gdy podaj odpowiednie dane logowania.

Uzyskiwanie dostępu

Dostęp programowy korzysta z protokołu OAuth 2 w interfejsach API Google, aby uzyskać dostęp do wymaganych poleceń RPC. Korzystanie z standardowa do generowania danych logowania OAuth2 identyfikator/tajny klucz klienta z Google. Gdy usługa PartnerAndroidBuildClient po raz pierwszy odwołuje się do tego sekretu, otwiera okno przeglądarki, aby użytkownik mógł zalogować się na swoje konto Google. Generuje to dane logowania OAuth2 potrzebne do dalszych działań. Dane logowania (token dostępu i token odświeżania) są przechowywane lokalnie, co oznacza, że partnerzy muszą się zalogować tylko raz.

Żądanie POST dla 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:

• identyfikator kompilacji, cel kompilacji
• nazwa zasobu
• gałąź
• nazwa wersji kandydackiej i to, czy jest to kompilacja wewnętrzna;

Żądanie POST jest odbierane przez metodę downloadBuildArtifact wywołania RPC buildsvc, które zwraca adres URL, którego można użyć do uzyskać dostęp do zasobu.

• W przypadku zasobów pakietu APK aplikacji Clockwork Companion adres URL to czytelny adres URL hostowany w PAB (chroniony uwierzytelnianiem i dostępny za pomocą odpowiedniego protokołu OAuth2), dane logowania).
• 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 sprawia, że bezpieczniejszym przetwarzaniem danych, utrudnia też dostęp zautomatyzowany, (dostępny tylko w kodzie JavaScript strony PAB) jest teraz również wymagane do uzyskania dostępu.

Aby uniknąć tego problemu, Android 9 zmienia URL schemat nazewnictwa wszystkich plików (nie tylko plików APK) tak, by używać przewidywalnych nazw adresów URL dostęp do list artefaktów i adresów URL artefaktów. PAB używa teraz wygodnego adresu URL format, który umożliwia partnerom pobieranie zasobów; Skrypty Centrum pomocy można pobierać te pliki APK, ponieważ format adresu URL jest znany, więc Centrum pomocy może pominąć Problemy z XSRF/plikiem cookie, ponieważ nie wymagają RPC buildsvc.

Lokalny system plików

Jeśli katalog zawiera listę artefaktów (lub plik ZIP), dostawca kompilacji ustawia odpowiednie obrazy na podstawie zawartości katalogu. Aby skopiować pliki z Google Cloud Storage do katalogu lokalnego, możesz użyć narzędzia gsutil.

Kompilacje Flash

Po pobraniu najnowszych obrazów urządzeń na hosta należy je wgrać na urządzenia. 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
• migające pojedyncze obrazy 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 (pojedynczo)

Przeprowadzanie testów

W Androidzie 9 infrastruktura automatycznego testowania VTS obsługuje tylko testowy zestaw narzędzi TradeFed, ale w przyszłości może zostać rozszerzona, aby obsługiwać inne zestawy narzędzi.

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

• Jeśli korzystasz z The TradeFed lokalnie, użyj polecenia test na hoście kontroler, który nosi nazwę planu testów VTS (np. vts-selftest) i przeprowadza test.
• Jeśli używasz klastra TradeFed (opcjonalnie połączonego z MTT), użyj lease w konsoli kontrolera hosta, które szuka niezrealizowane uruchomienia testów.

Jeśli korzystasz z klastra TradeFedCluster, działa TradeFed lokalnie jako menedżer zdalny. W przeciwnym razie testy są wywoływane przy użyciu podprocesów Pythona.

Raportowanie wyników

Wyniki testów są automatycznie przekazywane do niektórych projektów panelu VTS przez VtsMultiDeviceTest