Automatyczna infrastruktura testów

Android 9 zawiera infrastrukturę Vendor Test Suite (VTS) do automatycznego testowania VTS, CTS i innych testów na urządzeniach partnerów z ogólnym obrazem systemu (GSI) AOSP. Wcześniej przeprowadzanie tych testów wymagało wielu czynności wykonywanych ręcznie. 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, infrastruktura automatycznego testowania VTS wykona te zadania:

1. Pobiera artefakty kompilacji i zasoby testowe z różnych lokalizacji:
   • Partner Android Build (PAB). W przypadku obrazu GSI, platformy 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 TradeFeda lub TradeFeda 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 kodu, a potem udostępniać artefakty do pobrania.

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

• Wersja Androida partnera Dostęp programowy jest przyznawany w odniesieniu do 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 później będą używani do flashowania urządzeń. Dostawcy kompilacji pochodzą z jednego build_provider.py, który przechowuje kompilacje w lokalnych katalogach tymczasowych.

Wersja 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/klucz tajny. 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
• gałąź
• 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 innych witryn, interfejs buildsvc RPC wymaga przesłania tokena XSRF za pomocą metody POST wraz z innymi parametrami. Ten token zwiększa bezpieczeństwo procesu, ale utrudnia dostęp programowy, ponieważ do uzyskania dostępu wymagany jest teraz token (dostępny tylko w JavaScript na stronie PAB).

Aby uniknąć tego problemu, w Androidzie 9 zmieniono 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 pliki 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ą (lub plikiem ZIP) artefaktów, 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 inne platformy.

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.