Zautomatyzowana infrastruktura testowa

Android 9 zawiera infrastrukturę Vendor Test Suite (VTS) do automatycznego testowania VTS, CTS lub innych testów na urządzeniach partnerskich, na których działa ogólny obraz systemu AOSP (GSI). Wcześniej przeprowadzanie tych testów było operacją w dużym stopniu ręczną; nowa infrastruktura testowa VTS została zaprojektowana tak, aby wspierać automatyczne testy kilka razy dziennie na wielu urządzeniach.

Architektura

Infrastruktura testów automatycznych VTS wykorzystuje następującą architekturę:

Po uruchomieniu testu infrastruktura testów automatycznych VTS wykonuje następujące zadania:

1. Pobiera artefakty konstrukcyjne i zasoby testowe z różnych lokalizacji:
   • Partnerska kompilacja systemu Android (PAB) . Dla GSI, frameworku VTS i kilku 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. Flash tworzy artefakty (z urządzenia) i GSI (z AOSP) na podłączonych urządzeniach.
3. Przeprowadza testy VTS przy użyciu lokalnego TradeFed lub TradeFed w chmurze.
4. Raportuje wyniki testów do panelu VTS

Proces jest koordynowany przez kontroler hosta VTS (HC), maszynę laboratoryjną, która steruje zachowaniem wszystkich podłączonych testowanych urządzeń. HC jest odpowiedzialny za pobieranie najnowszych kompilacji, flashowanie ich na urządzeniach i wywoływanie testów (lokalnie lub za pośrednictwem dowódcy). Komunikuje się także z programem planującym w chmurze i kieruje ruchem pomiędzy programem planującym a instancją TradeFed (lub inną wiązką) działającą na HC. Aby uzyskać szczegółowe informacje na temat kontrolera hosta, zobacz Architektura kontrolera hosta .

Dostawcy zasobów

Testowanie automatyczne wymaga zasobów, takich jak kompilacje systemu, pliki testowe i artefakty VTS. Chociaż możliwe jest zbudowanie ich ze źródeł, łatwiej jest je regularnie budować z czubka drzewa, a następnie publikować artefakty do pobrania.

Partnerzy mogą uzyskać dostęp do zasobów automatyzacji, korzystając z następujących lokalizacji:

• Partnerska kompilacja Androida . Dostęp programowy przyznawany dla każdego konta.
• Lokalny system plików (lub podobny). Dla partnerów, którzy nie korzystają z wersji Partner Android Build.

Do wykorzystania w późniejszym flashowaniu urządzeń zasoby obejmują dostawców kompilacji dla obu opcji, począwszy od pojedynczego pliku build_provider.py , który przechowuje kompilacje w lokalnych katalogach tymczasowych.

Partnerska kompilacja Androida

W systemie Android 8.1 i wcześniejszych wersjach partnerzy systemu Android musieli odwiedzić witrynę Partner Android Build ( https://partner.android.com/build ), przejść do swojego konta i pobrać najnowsze obrazy systemu za pośrednictwem 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 uwierzytelniających.

Ustal dostęp

Dostęp programowy korzysta z protokołu OAuth2 w interfejsach API Google, aby uzyskać dostęp do wymaganych wywołań RPC. Stosując standardowe podejście do generowania danych uwierzytelniających OAuth2, partner musi skonfigurować w Google parę identyfikator klienta/tajny klucz. Gdy klient PartnerAndroidBuildClient zostanie po raz pierwszy wskazany na ten sekret, otwiera okno przeglądarki, w którym użytkownik może zalogować się na swoje konto Google, co generuje dane uwierzytelniające OAuth2 potrzebne do dalszego działania. Dane uwierzytelniające (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 zawierającego niezbędne dane dla tego zasobu, w tym:

• identyfikator kompilacji, cel kompilacji
• Nazwa zasobu
• oddział
• nazwę kandydata do wydania oraz informację, czy kandydat jest kompilacją wewnętrzną

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

• W przypadku zasobów pakietu APK Clockwork Companion adresem URL jest czytelny adres URL hostowany w PAB (który jest chroniony przed uwierzytelnieniem i dostępny za pomocą odpowiednich poświadczeń OAuth2).
• W przypadku innych zasobów adres URL jest długim, niechronionym adresem URL z wewnętrznego interfejsu API kompilacji systemu Android (który wygasa po pięciu minutach).

Uzyskaj adres URL

Aby uniknąć fałszowania żądań między witrynami, wywołanie buildsvc RPC wymaga przesłania tokenu XSRF z innymi parametrami. Chociaż ten token czyni proces bezpieczniejszym, znacznie utrudnia również dostęp programowy, ponieważ token (który jest dostępny tylko w JavaScript strony PAB) jest teraz również wymagany do uzyskania dostępu.

Aby uniknąć tego problemu, w systemie Android 9 przeprojektowano schemat nazewnictwa adresów URL dla wszystkich plików (nie tylko plików APK), aby używać przewidywalnych nazw adresów URL w celu uzyskania dostępu do list artefaktów i adresów URL artefaktów. PAB korzysta teraz z wygodnego formatu adresu URL, który umożliwia partnerom pobieranie zasobów; Skrypty HC mogą z łatwością pobierać te pliki APK, ponieważ format adresu URL jest znany, a HC może ominąć problemy XSRF/cookie, ponieważ nie potrzebuje wywołania buildsvc RPC.

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 , aby skopiować pliki z Google Cloud Storage do katalogu lokalnego.

Kompilacje Flasha

Po pobraniu najnowszych obrazów urządzeń na hosta obrazy te muszą zostać przesłane na urządzenia. Odbywa się to za pomocą standardowych poleceń adb i fastboot oraz podprocesów Pythona, w oparciu o ścieżki plików tymczasowych przechowywane przez dostawców kompilacji.

Obsługiwane akcje:

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

Uruchom testy

W systemie Android 9 infrastruktura automatycznych testów VTS obsługuje tylko wiązkę testową TradeFed, ale w przyszłości można ją rozszerzyć, aby obsługiwała inne wiązki przewodów.

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

• Używając TradeFed lokalnie, użyj polecenia test w kontrolerze hosta, które pobiera nazwę planu testów VTS (np. vts-selftest ) i uruchamia test.
• W przypadku korzystania z klastra TradeFed (opcjonalnie połączonego z MTT) użyj polecenia lease w konsoli kontrolera hosta, które wyszukuje niezrealizowane przebiegi testowe.

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

Zgłoś wyniki

Wyniki testów są automatycznie raportowane do niektórych projektów dashboardów VTS przez VtsMultiDeviceTest .