Testy na wielu urządzeniach

VTS obsługuje testy, które wymagają interakcji między wieloma systemami Android urządzenia.

Architektura

VTS wykorzystuje platformę TradeFed do pobierania i przekazywania numerów seryjnych urządzeń w celu testowania modułów.

Rysunek 1. VTS przekazujące numery seryjne urządzeń.

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

Podział urządzeń

Infrastruktura testowa (zwykle algorytm szeregowania testów) przydziela dostępne urządzeń, które spełniają wymagania określone w konfiguracji planu testów, VTS. Przydzielone urządzenia są zarezerwowane na potrzeby abonamentu testowego, nawet jeśli nie są wykorzystywane w module testowym. Pliki binarne agentów VTS są następnie przekazywane do i w nich uruchamiane wszystkich przydzielonych urządzeń (chyba że wyraźnie zabronią ich uruchamiania). Dzięki temu masz pewność, czy połączenia TCP z poleceniami powłoki i RPC HAL są dostępne dla wszystkich w skrypcie testowym.

Osoby przygotowujące do testów

Platforma uruchamia przygotowania do testów na wszystkich urządzeniach, na które została przesłana numerów seryjnych. Przygotowanie do kierowania na grupy docelowe może obejmować pojedyncze lub wiele urządzeń:

  • Przygotowane do kierowania na 1 urządzenie (przykład: VtsDeviceInfoCollector):
    • Można ją określić tylko w konfiguracji planu testów z wymaganymi lista urządzeń (przyszłe wersje będą zezwalać na konfigurowanie na poziomie modułu).
    • Może otrzymać tylko 1 numer seryjny urządzenia.
    • Uruchamianie zadań związanych z przygotowywaniem i czyszczeniem na konkretnym urządzeniu.
  • Przygotowanie do kierowania na wiele urządzeń (przykład: VtsPythonVirtualenvPreparer):
    • Można ją określić w konfiguracji planu testów lub w module testowym konfiguracja
    • Otrzymuj wszystkie numery seryjne urządzenia
    • Uruchamianie zadań związanych z przygotowywaniem i czyszczeniem na poszczególnych lub wszystkich urządzeniach.

Moduły testowe

Moduły testowe otrzymują listę urządzeń po zakończeniu konfiguracji przez osoby przygotowujące do testów host/urządzenia. Jeden moduł testowania Pythona po stronie hosta dla każdego urządzenia na wielu urządzeniach z modułu testowego. Przydzielone urządzenia z Androidem są dostępne w modułach testowych Pythona jako listę Urządzenie z Androidem obiekty:

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

Wszystkie przydzielone urządzenia są zarezerwowane w ramach abonamentu, nawet jeśli test w planie używa tylko jednego urządzenia.

Komunikacja z urządzeniem podczas testowania

Skuteczne testy na wielu urządzeniach z Androidem obejmują komunikację między przydzielonymi urządzenia. Opracowując takie testy, musisz określić, jak określić komunikacji między przypisanymi urządzeniami. W sekcjach poniżej trzech przykładowych metod komunikacji (deweloperzy mogą jednak opracowywać inne wersje, modeli ML).

Typ 1. Testy HAL po stronie hosta

Testy HAL po stronie hosta mogą korzystać ze sterowników VTS HAL, które są przekazywane do urządzeń domyślnie:

Rysunek 2. Test HAL po stronie hosta.

W takim przypadku:

  • Logika testowa jest wykonywana na hoście.
  • Po stronie hosta skrypt testowy wysyła wywołania RPC do sterowników każdego urządzenia.
  • Interakcje z urządzeniami koordynowane po stronie hosta.

Typ 2. Testy oparte na agentach po stronie hosta

Zamiast używać agentów VTS na urządzeniu, test po stronie hosta (aplikację lub plik binarny) do każdego urządzenia:

Rysunek 3. Test oparty na agentach po stronie hosta.

W takim przypadku:

  • Logika testowa jest wykonywana na hoście.
  • Aplikacja agenta (lub plik binarny) instaluje się na każdym urządzeniu.
  • Skrypt testowy po stronie hosta wysyła polecenia do aplikacji na każdym urządzeniu.
  • Interakcje z urządzeniami koordynowane po stronie hosta.

Na przykład parametr Dalej miliardy testów z udziałem użytkowników w obecnym repozytorium VTS odbywa się po stronie hosta na wielu urządzeniach.

Typ 3: testy HIDL po stronie docelowej

Testy HIDL na wielu urządzeniach po stronie docelowej umożliwiają przetestowanie całej logiki testowej po stronie urządzenia pliki binarne, które wymagają testów do synchronizowania urządzeń podczas testów; wykonanie:

Rysunek 4. Test HIDL oparty na wartości docelowej.

W takim przypadku:

  • Logika testowa działa na urządzeniach.
  • Platforma po stronie hosta zapewnia wstępną identyfikację urządzenia.
  • Plik binarny testu po stronie docelowej wymaga synchronizacji:
    • Ten sam testowy plik binarny 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ę 2 urządzeń:

  • Urządzenie 1 zawiera dostawcę kompilacji i VtsDeviceInfoCollector osoba przygotowująca do celu.
  • Urządzenie 2 zawiera dodatkowy moduł przygotowujący do: FilePusher, który push grupę plików powiązanych z hostem urządzenia.
<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 Pythona po stronie hosta

Szczegółowe informacje i przykłady dotyczące osób przygotowujących do testów znajdziesz na stronie Osoby przygotowujące do testów. Kompletne dane po stronie hosta przykład na wielu urządzeniach, zapoznaj się z witaj_świecie_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')