VTS obsługuje testy wymagające interakcji pomiędzy wieloma urządzeniami z systemem Android.
Architektura
VTS wykorzystuje platformę TradeFed do pobierania i przekazywania numerów seryjnych urządzeń do modułów testowych.
Wymagania dotyczące urządzeń, takie jak liczba urządzeń i typy urządzeń, są określone w konfiguracji planu testów. Na przykład możesz określić plan testów, który wymaga dwóch urządzeń z systemem Android z celami kompilacji Sailfish.
Przydział urządzeń
Infrastruktura testowa (zwykle osoba planująca testy) przydziela do frameworku VTS dostępne urządzenia spełniające wymagania określone w konfiguracji planu testów. Przydzielone urządzenia są zarezerwowane dla planu testów, nawet jeśli moduł testowy z nich nie korzysta. Pliki binarne agenta VTS są następnie przesyłane i uruchamiane na wszystkich przydzielonych urządzeniach (chyba że wyraźnie zalecono, aby nie uruchamiać). Dzięki temu połączenia TCP dla poleceń powłoki i pakietów RPC HAL będą dostępne dla wszystkich urządzeń w skrypcie testowym.
Osoby przygotowujące testy
Framework uruchamia narzędzia przygotowujące testy dla wszystkich urządzeń, dla których otrzymał numery seryjne. Osoby przygotowujące cele mogą mieć jedno lub wiele urządzeń:
- Osoby przygotowujące cele na jedno urządzenie (przykład w VtsDeviceInfoCollector ):
- Można go określić tylko w konfiguracji planu testów z wymaganą listą urządzeń (przyszłe wersje umożliwią konfigurację na poziomie modułu).
- Odbierz tylko jeden numer seryjny urządzenia.
- Uruchom zadania przygotowania i czyszczenia na konkretnym urządzeniu.
- Osoby przygotowujące cele na wiele urządzeń (przykład w VtsPythonVirtualenvPreparer ):
- Można określić w konfiguracji planu testów lub konfiguracji modułu testowego
- Odbierz wszystkie numery seryjne urządzenia
- Uruchom zadania przygotowania i czyszczenia dla każdego urządzenia lub wszystkich urządzeń.
Moduły testowe
Moduły testowe otrzymują listę urządzeń po tym, jak osoby przygotowujące testy zakończą konfigurowanie hosta/urządzeń. Dla każdego modułu testowego obsługującego wiele urządzeń działa jeden moduł testowy języka Python po stronie hosta. Przydzielone urządzenia z systemem Android są dostępne z modułów testowych Pythona jako lista obiektów AndroidDevice :
devices = self.android_devices device1 = devices[0] device1_serial = device1.serial
Wszystkie przydzielone urządzenia są zarezerwowane dla planu testów, mimo że moduł testowy w planie korzysta tylko z jednego urządzenia.
Komunikacja urządzenia podczas testów
Efektywne testy multi-Android polegają na komunikacji pomiędzy przydzielonymi urządzeniami. Opracowując takie testy, należy określić, w jaki sposób nawiązać komunikację pomiędzy przydzielonymi urządzeniami. W poniższych sekcjach przedstawiono trzy przykłady komunikacji (jednak twórcy testów mogą dowolnie projektować inne modele).
Typ 1: Testy HAL po stronie hosta
Testy HAL po stronie hosta mogą korzystać ze sterowników VTS HAL, które są domyślnie przesyłane do urządzeń:
W tym scenariuszu:
- Logika testowa jest wykonywana na hoście.
- Skrypt testowy po stronie hosta wysyła wywołania RPC do sterowników na każdym urządzeniu.
- Strona hosta koordynuje interakcje urządzeń.
Typ 2: Testy oparte na agentach po stronie hosta
Zamiast używać agentów VTS na urządzeniu, test po stronie hosta może również wypchnąć własnego agenta (aplikację lub plik binarny) do każdego urządzenia:
W tym scenariuszu:
- Logika testowa jest wykonywana na hoście.
- Aplikacja agenta (lub plik binarny) instaluje się na każdym urządzeniu.
- Skrypt testowy po stronie hosta wydaje polecenia aplikacjom na każdym urządzeniu.
- Strona hosta koordynuje interakcje urządzeń.
Na przykład testy użytkowników Next Billion w bieżącym repozytorium VTS to testy po stronie hosta, oparte na aplikacji i na wielu urządzeniach.
Typ 3: Testy HIDL po stronie docelowej
Testy HIDL po stronie docelowej na wielu urządzeniach umieszczają całą logikę testów w plikach binarnych testów po stronie urządzenia, co wymaga synchronizacji urządzeń podczas wykonywania testu:
W tym scenariuszu:
- Logika testowa jest wykonywana na urządzeniach.
- Struktura po stronie hosta zapewnia wstępną identyfikację urządzenia.
- Plik binarny testowy po stronie docelowej wymaga synchronizacji:
- Ten sam plik binarny testowy dla wszystkich urządzeń.
- Różne pliki binarne testowe dla każdej roli.
Przykład: plan testów na wielu urządzeniach
Ten przykład określa konfigurację dla dwóch urządzeń:
- Urządzenie 1 zawiera dostawcę kompilacji i narzędzie przygotowujące obiekt docelowy
VtsDeviceInfoCollector. - Urządzenie 2 zawiera dodatkowy moduł przygotowujący
FilePusher, który wypycha do urządzenia grupę plików powiązanych z hostem.
<configuration description="VTS Codelab Plan"> ... <device name="device1"> <build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" /> <target_preparer class="com.android.tradefed.targetprep.VtsDeviceInfoCollector" /> </device> <device name="device2" > <build_provider class="com.android.compatibility.common.tradefed.build.CompatibilityBuildProvider" /> <target_preparer class="com.android.tradefed.targetprep.VtsDeviceInfoCollector" /> <target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher"> <option name="push-group" value="HostDrivenTest.push" /> </target_preparer> </device> <option name="compatibility:include-filter" value="VtsCodelabHelloWorldMultiDeviceTest" /> </configuration>
Przykład: skrypt testowy Python po stronie hosta
Szczegółowe informacje i przykłady dotyczące osób przygotowujących testy można znaleźć w artykule Osoby przygotowujące testy . Pełny przykład pracy z wieloma urządzeniami po stronie hosta można znaleźć w ćwiczeniach z programowania hello_world_multi .
def setUpClass(self):
logging.info('number of device: %s', self.android_devices)
asserts.assertEqual(len(self.android_devices), 2, 'number of device is wrong.')
self.dut1 = self.android_devices[0]
self.dut2 = self.android_devices[1]
self.shell1 = self.dut1.shell
self.shell2 = self.dut2.shell
def testSerialNotEqual(self):
'''Checks serial number from two device not being equal.'''
command = 'getprop | grep ro.serial'
res1 = self.shell1.Execute(command)
res2 = self.shell2.Execute(command)
def getSerialFromShellOutput(output):
'''Get serial from getprop query'''
return output[const.STDOUT][0].strip().split(' ')[-1][1:-1]
serial1 = getSerialFromShellOutput(res1)
serial2 = getSerialFromShellOutput(res2)
logging.info('Serial number of device 1 shell output: %s', serial1)
logging.info('Serial number of device 2 shell output: %s', serial2)
asserts.assertNotEqual(serial1, serial2, 'serials from two devices should not be the same')
asserts.assertEqual(serial1, self.dut1.serial, 'serial got from device system property is different from allocated serial')
asserts.assertEqual(serial2, self.dut2.serial, 'serial got from device system property is different from allocated serial')