Testowanie na wielu urządzeniach

VTS obsługuje testy, które wymagają interakcji między wieloma urządzeniami z Androidem.

Architektura

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

Rysunek 1. Numery seryjne urządzeń, które przeszły test VTS.

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 platformami docelowymi Sailfish.

Przydział urządzeń

Infrastruktura testowa (zwykle harmonogram testów) przydziela do platformy VTS dostępne urządzenia, które spełniają wymagania określone w konfiguracji planu testów. Przydzielone urządzenia są zarezerwowane dla planu testów, nawet jeśli moduł testowy ich nie używa. Pliki binarne agenta VTS są następnie przesyłane i uruchamiane na wszystkich przydzielonych urządzeniach (chyba że wyraźnie określono, że nie mają być uruchamiane). Dzięki temu połączenia TCP dla poleceń powłoki i wywołań RPC HAL są dostępne dla wszystkich urządzeń w skrypcie testowym.

Osoby przygotowujące testy

Framework uruchamia preparaty testowe na wszystkich urządzeniach, dla których otrzymał numery seryjne. Przygotowujący miejsce docelowe mogą obsługiwać jedno lub wiele urządzeń:

  • Przygotowujący dane o urządzeniu (przykład w przypadku 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ć go na poziomie modułu).
    • Otrzymasz tylko jeden numer seryjny urządzenia.
    • Uruchamiaj zadania przygotowania i czyszczenia na konkretnym urządzeniu.
  • Przygotowywanie celów na wiele urządzeń (przykład w VtsPythonVirtualenvPreparer):
    • Można go określić w konfiguracji planu testów lub modułu testowego.
    • Otrzymywanie wszystkich numerów seryjnych urządzeń
    • Uruchamiaj zadania przygotowawcze i czyszczące na każdym urządzeniu lub na wszystkich urządzeniach.

Testowanie modułów

Moduły testowe otrzymują listę urządzeń po zakończeniu konfigurowania hosta lub urządzeń przez osoby przygotowujące test. Dla każdego modułu testowego obejmującego wiele urządzeń uruchamiany jest jeden moduł testowy Pythona po stronie hosta. Przydzielone urządzenia z Androidem są dostępne w modułach 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, nawet jeśli moduł testowy w planie używa tylko jednego urządzenia.

Komunikacja z urządzenia podczas testowania

Skuteczne testy na wielu urządzeniach z Androidem wymagają komunikacji między przydzielonymi urządzeniami. Podczas opracowywania takich testów musisz określić, jak nawiązać komunikację między przydzielonymi urządzeniami. W kolejnych sekcjach znajdziesz 3 przykłady komunikacji (jednak twórcy testów mogą 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 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.
  • Koordynuje interakcje z urządzeniem.

Typ 2. Testy oparte na agencie po stronie hosta

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

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.
  • Koordynuje interakcje z urządzeniem.

Na przykład testy Next Billion User w bieżącym repozytorium VTS są testami po stronie hosta, opartymi na aplikacjach i przeprowadzanymi na wielu urządzeniach.

Typ 3. Testy HIDL po stronie urządzenia

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

Rysunek 4. Test HIDL oparty na celu.

W tym scenariuszu:

  • Logika testu jest wykonywana na urządzeniach.
  • Platforma po stronie hosta zapewnia wstępną identyfikację urządzenia.
  • Testowy plik binarny po stronie docelowej wymaga synchronizacji:
    • Ten sam plik binarny testu na wszystkich urządzeniach.
    • Różne pliki binarne testu 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 VtsDeviceInfoCollectorprzygotowującego urządzenie docelowe.
  • Urządzenie 2 zawiera dodatkowego FilePusher przygotowującego, który przesyła na urządzenie grupę powiązanych plików sterowanych przez hosta.
<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 przygotowywania testów znajdziesz w artykule Przygotowywanie testów. Pełny przykład dotyczący wielu urządzeń po stronie hosta znajdziesz w samouczku 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')