Testy na wielu urządzeniach

VTS obsługuje testy wymagające interakcji między wieloma urządzeniami z Androidem.

Architektura

VTS używa platformy TradeFed do pobierania i przekazywania numerów seryjnych urządzeń do testowania modułów.

Rysunek 1. VTS przekazuje numery seryjne urządzeń.

Wymagania dotyczące urządzeń, takie jak liczba urządzeń i ich typy, są określone w konfiguracji planu testów. Możesz na przykład określić plan testów, który wymaga 2 urządzeń z Androidem z docelami kompilacji Sailfish.

Przydział urządzeń

Infrastruktura testów (zwykle harmonogram testów) przydziela dostępne urządzenia, które spełniają wymagania określone w konfiguracji planu testów, do platformy VTS. Przydzielone urządzenia są zarezerwowane dla planu testowego, nawet jeśli moduł testowy ich nie używa. Pliki binarne agenta VTS są następnie przesyłane na wszystkie przydzielone urządzenia i uruchamiane na nich (chyba że otrzymano instrukcję, aby tego nie robić). Dzięki temu połączenia TCP służące do poleceń w powłoce i wywołań RPC HAL są dostępne dla wszystkich urządzeń w skrypcie testowym.

Przygotowywanie testów

Platforma uruchamia narzędzia do przygotowywania testów na wszystkich urządzeniach, dla których otrzymała numery seryjne. Przygotowywanie danych może odbywać się na jednym lub wielu urządzeniach:

  • Przygotowywanie danych na potrzeby kierowania na pojedyncze urządzenie (np. w VtsDeviceInfoCollector):
    • Można go określić tylko w konfiguracji planu testów z wymaganą listą urządzeń (w przyszłych wersjach będzie można konfigurować na poziomie modułu).
    • Otrzymaj tylko 1 numer seryjny urządzenia.
    • Wykonywanie zadań przygotowywania i czyszczenia na konkretnym urządzeniu.
  • Przygotowywanie docelowych urządzeń na wielu urządzeniach (np. w VtsPythonVirtualenvPreparer):
    • Może być określony w konfiguracji planu testów lub konfiguracji modułu testowego.
    • Otrzymywanie wszystkich numerów seryjnych urządzeń
    • Uruchom zadania przygotowywania i czyszczenia na każdym urządzeniu lub na wszystkich urządzeniach.

Testowanie modułów

Po zakończeniu konfigurowania hosta/urządzeń przez osoby przygotowujące testy moduły testowe otrzymują listę urządzeń. Na każdym module testowym na wielu urządzeniach uruchamiany jest jeden moduł testowy Pythona po stronie hosta. Przydzielone urządzenia z Androidem są dostępne w modułach testów Pythona jako lista obiektów AndroidDevice:

devices = self.android_devices
device1 = devices[0]
device1_serial = device1.serial

Wszystkie przydzielone urządzenia są zarezerwowane na potrzeby planu testowego, mimo że moduł testowy w planie korzysta tylko z 1 urządzenia.

Komunikacja z urządzeniem podczas testowania

Skuteczne testy na wielu urządzeniach z Androidem wymagają komunikacji między przypisanymi urządzeniami. Podczas opracowywania takich testów musisz określić, jak nawiązać komunikację między przypisanymi urządzeniami. W następnych sekcjach znajdziesz 3 przykłady komunikacji (twórcy testów mogą jednak projektować inne modele).

Typ 1: testy HAL po stronie hosta

Testy HAL po stronie hosta mogą używać sterowników HAL VTS, które są domyślnie przesyłane na urządzenia:

Rysunek 2. Test HAL po stronie hosta.

W tym scenariuszu:

  • Logika testu jest wykonywana na hoście.
  • Skrypt testowy po stronie hosta wysyła wywołania RPC do sterowników na każdym urządzeniu.
  • Host koordynuje interakcje urządzeń.

Typ 2: testy oparte na agencie po stronie hosta

Zamiast używać na urządzeniu agentów VTS, test po stronie hosta może przesłać na każde urządzenie własny agent (aplikację lub plik binarny):

Rysunek 3. Test po stronie hosta oparty na agencie.

W tym scenariuszu:

  • Logika testu jest wykonywana na hoście.
  • Aplikacja agenta (lub plik binarny) jest instalowana na każdym urządzeniu.
  • Skrypt testowy po stronie hosta wysyła polecenia do aplikacji na każdym urządzeniu.
  • Host koordynuje interakcje urządzeń.

Na przykład testy Next Billion User w bieżącym repozytorium VTS to testy na stronie hosta, oparte na aplikacji i przeznaczone na wiele urządzeń.

Typ 3: testy HIDL po stronie docelowej

Testy HIDL po stronie docelowej na wielu urządzeniach umieszczają całą logikę testu w binarnych plikach testowych po stronie urządzenia, co wymaga synchronizacji urządzeń podczas wykonywania testu:

Ilustracja 4. Test HIDL oparty na celu

W tym scenariuszu:

  • Testowanie logiki na urządzeniach.
  • Platforma po stronie hosta zapewnia wstępną identyfikację urządzenia.
  • Test binarny po stronie docelowej wymaga synchronizacji:
    • Ten sam binarny plik testowy na wszystkich urządzeniach.
    • różne binarne pliki testowe dla każdej roli.

Przykład: plan testów na wielu urządzeniach

W tym przykładzie określono konfigurację 2 urządzeń:

  • Urządzenie 1 zawiera dostawcę kompilacji i VtsDeviceInfoCollectorprzygotowywanie celu.
  • Urządzenie 2 zawiera dodatkowy moduł FilePusher, który przesyła na urządzenie 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 w Pythonie po stronie hosta

Szczegółowe informacje i przykłady dotyczące osób przygotowujących testy znajdziesz w artykule przygotowujących testy. Pełny przykład obsługiwany przez hosta na wielu urządzeniach znajdziesz w sekcji hello_world_multi kodu Codelab. 

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')