Uruchamianie testów CTS Verifier na wielu urządzeniach

Na tej stronie znajdziesz instrukcje korzystania z testów Better Together CTS Verifier (CTS-V) na Androidzie 16 QPR2 lub nowszym.

Konfigurowanie testów na wielu urządzeniach po stronie hosta

W tej sekcji dowiesz się, jak skonfigurować testy na wielu urządzeniach.

1. Sprawdź, czy komputer stacjonarny spełnia wymagania systemu operacyjnego CTS.

2. Wykonaj kroki 2 i 5 z sekcji Instalowanie oprogramowania na komputerze, aby zainstalować i sprawdzić, czy adb, AAPT2 i Python są prawidłowo zainstalowane na komputerze.

   • Wersja Pythona powinna być 3.11 lub nowsza. Aby sprawdzić wersję Pythona, uruchom polecenie python3 --version. Jeśli wersja jest niższa niż 3.11, zainstaluj najnowszą oficjalną wersję Pythona. Więcej informacji znajdziesz w sekcji Pobrane pliki na stronie python.org.
   • Niektóre testy wymagają, aby host miał moduł Pythona venv. W systemach Debian i Ubuntu ten moduł może nie być domyślnie zainstalowany. Aby sprawdzić, czy Twoja wersja Pythona ma moduł venv, uruchom polecenie python3 -m venv venv. Jeśli to polecenie się nie powiedzie, pojawi się komunikat o błędzie. Postępuj zgodnie z wyświetlanymi instrukcjami, aby zainstalować pakiet python3.x-venv.

3. Przygotuj 2 pasujące do siebie testowane urządzenia, na których skonfigurowano CTS-V.

   • Informacje o konfigurowaniu urządzenia znajdziesz w artykule Konfigurowanie urządzenia.
   • Instrukcje konfigurowania CTS-V znajdziesz w artykule Konfiguracja.

4. Otwórz sekcję konfiguracji dla wybranego typu testu:

   • Informacje o testach NFC znajdziesz w artykule Konfigurowanie testów NFC.
   • W przypadku testów połączenia z punktem dostępu Wi-Fi przejdź do sekcji Konfigurowanie testów połączenia z punktem dostępu Wi-Fi.
   • Aby przetestować moduł CDM, zapoznaj się z sekcją Konfigurowanie standardowych testów na 2 urządzeniach, a następnie z sekcją Konfigurowanie testów CDM.

   Jeśli testu nie ma na tej liście, przejdź do sekcji Konfigurowanie standardowych testów na 2 urządzeniach.

Konfigurowanie testów NFC

Testy NFC wykorzystują jedno urządzenie DUT i jeden chip NFC PN532.

Aby skonfigurować testy NFC:

1. Kup chip NFC PN532. Zalecamy All-In-One PN532.

2. Na testowanym urządzeniu otwórz aplikację Ustawienia.

3. Włącz NFC.

4. Umieść chip NFC:

   • W przypadku telefonów umieść czytnik NFC urządzenia DUT w sposób pokazany na rysunku 1:

     

     Rysunek 1. Położenie chipa NFC.

   • W przypadku innych typów urządzeń umieść chip obok anteny NFC urządzenia.

5. Podłącz chip NFC PN532 do stacji roboczej za pomocą kabla USB.

Opcjonalnie: skonfiguruj testy połączenia z punktem dostępu Wi-Fi

Testy połączenia z punktem dostępu Wi-Fi (CtsWifiConnectionTests) sprawdzają łączność między testowanym urządzeniem a punktem dostępu. Zdecydowanie zalecamy przeprowadzenie tych testów, ale nie są one wymagane w CTS-V w przypadku Androida 16 w wersji QPR2.

Te testy wymagają urządzenia i punktu dostępu OpenWrt Banana Pi R3.

Aby skonfigurować testy połączenia z punktem dostępu Wi-Fi:

1. Kup i skonfiguruj punkt dostępu Banana Pi R3. Więcej informacji znajdziesz w artykule Konfigurowanie punktu dostępu Banana Pi BPI-R3.

2. Opcjonalnie: jeśli nie masz skrzynki ekranującej, zalecamy skrzynkę ekranującą JTP-SR101. Kup to pudełko, korzystając z tych informacji:

   Dong Guan Zheng Sheng Electronics Technology Co., LTD
   Bohui Industrial Park, Panlong Road, Liaobu Town, Dongguan City, Guangdong Province, Chiny
   Osoba kontaktowa: Forest Pan
   E-mail: [e-mail]
   Telefon (Chiny): [phone]

   Uwaga: ekranowanie umożliwia izolację sygnału zewnętrznego, a urządzenie i AP mogą być oddalone od siebie o 10 cm.

3. Podłącz DUT i AP do hosta i umieść je w ekranowanej komorze RF. Urządzenie i punkt dostępu powinny być oddalone od siebie o co najmniej 10 cm. Na rysunku 2 widać tę konfigurację:

   

   Rysunek 2. DUT i AP w pudełku ekranowanym.

4. Użyj SSH, aby sprawdzić, czy punkt dostępu jest dostępny z hosta.

Konfigurowanie standardowych testów na 2 urządzeniach

W przypadku domyślnej konfiguracji z 2 urządzeniami:

1. Umieść 2 pasujące urządzenia z Androidem w odległości około 20 cm od siebie.

2. Aby zapewnić czyste środowisko, umieść oba urządzenia w osłonie.

   Uwaga: jeśli masz problemy z tymi testami i potrzebujesz pomocy, sprawdź, czy testy zostały przeprowadzone na obu urządzeniach w osłonie.

3. Opcjonalnie: skonfiguruj sniffer OTA do debugowania Wi-Fi.

Konfigurowanie testów CDM

test_permissions_sync() – element testowania zachowuje się inaczej w zależności od rodzaju kompilacji urządzeń, na których jest wykonywany. Konieczne jest, aby producenci OEM testowali obie kompilacje – debugowalną (userdebug lub eng) i niedebugowalną (user) – i aby testy w obu przypadkach zakończyły się powodzeniem.

Wyjątek

Klauzula CDD dotycząca implementacji interfejsu Permissions Sync API wymaga jedynie, aby interfejs ten mógł przesyłać dane między urządzeniami przez bezpieczny kanał. Implementacja bezpiecznego kanału nie jest wymagana w ramach zgodności z CDD, więc ten test można pominąć w przypadku wersji, których nie można debugować (wersji użytkownika), ale tylko wtedy, gdy chcesz zrezygnować z obsługi funkcji synchronizacji uprawnień CDM.

Testy muszą być przeprowadzane bez wyjątku w przypadku kompilacji z możliwością debugowania.

Wymagania wstępne dotyczące testowania na wersjach, których nie można debugować

Jeśli nie kwalifikujesz się do zwolnienia na podstawie poprzednich klauzul, sprawdź, czy spełniasz te wymagania wstępne:

Kanał bezpieczny używa AVF (AttestationVerificationFramework) do weryfikacji wiarygodności sprzętu. Atesty generowane przez obie strony zawierają kilka informacji o nich samych, aby zapewnić, że w ich systemie nie doszło do żadnych nieautoryzowanych zmian. Podczas procesu weryfikacji AVF sprawdza te stany:

• Urządzenie ma dostęp do internetu
• Urządzenie korzysta z weryfikowanego rozruchu, a kompilacja musi być podpisana kluczem wersji, a nie kluczem deweloperskim.
• Program rozruchowy urządzenia jest zablokowany. Szczegółowe instrukcje znajdziesz w artykule na temat blokowania bootloadera.
• Poziomy poprawek systemu operacyjnego, kluczowego rozruchu i dostawcy kluczy są w zakresie 12 miesięcy. Nie używaj kompilacji starszej niż rok.

• Atest urządzenia jest oparty na jednym z zatwierdzonych przez dostawcę certyfikatów głównych. Określ zaufane główne certyfikaty w nakładce zasobów vendor_required_attestation_certificates.xml.

Przeprowadzanie testów na wielu urządzeniach po stronie hosta (AOSP 16 lub nowszy)

CTS Verifier 16 wprowadza obsługę testów na wiele urządzeń po stronie hosta. Te testy można przeprowadzać za pomocą automatycznych skryptów na hoście, zamiast ręcznie na urządzeniu. Po zakończeniu każdego testu wyniki są automatycznie przesyłane do testowanego urządzenia i wyświetlane w aplikacji CTS Verifier.

Z tej sekcji dowiesz się, jak przeprowadzać testy na wielu urządzeniach po stronie hosta.

Przeprowadzanie testów na wielu urządzeniach

Aby przeprowadzić test na wielu urządzeniach:

1. Na stacji roboczej do testowania uruchom cts-v-hostkonsolę w katalogu, w którym rozpakowano pakiet ZIP CTS-V:

   ./android-cts-verifier/android-cts-v-host/tools/cts-v-host-tradefed
   

2. W aplikacji CTS Verifier na urządzeniu kliknij Host-side Tests (Testy po stronie hosta). Ilustracja 3 przedstawia testy po stronie hosta w aplikacji CTS Verifier:

   

   Rysunek 3. Testy na wiele urządzeń po stronie hosta w aplikacji CTS Verifier.

   Wyświetli się lista modułów testowych po stronie hosta do testów na wielu urządzeniach.

3. Określ nazwę modułu testowego, który chcesz uruchomić. Na przykład moduł CompanionDeviceManager jest wymieniony jako CtsCompanionDeviceManagerMultiDeviceTestCases.

   Uwaga: jeśli w aplikacji CTS Verifier klikniesz moduł po stronie hosta, nie zobaczysz listy poszczególnych przypadków testowych. Zamiast tego interfejs automatycznie wypełnia się wynikami elementu testowania po wykonaniu modułu na hoście.

4. W konsoli cts-v-host uruchom to polecenie:

   run cts-v-host -m test_module_name
   

   Na przykład:

   run cts-v-host -m CtsCompanionDeviceManagerMultiDeviceTestCases
   

   Uwaga: jeśli uruchomisz polecenie cts-v-host bez użycia parametru -m test_module_name, spróbuje ono uruchomić wszystkie moduły testowe, ignorując odchylenia w wymaganiach dotyczących urządzenia i sprzętu. Zamiast tego wykonaj polecenie run cts-v-host-default-devices, aby uruchomić testy
   Uwaga: możesz wskazać konkretne testowane urządzenia, podając ich numery seryjne: run cts-v-host -m test_module_name -s\ device1_serial -s device2_serial ...

   Po zakończeniu testów w konsoli xTS wyniki pojawią się w aplikacji CTS Verifier. Testy oznaczone na zielono zostały zaliczone. Testy oznaczone na czerwono nie zostały zaliczone. Na rysunku 4 przedstawiono przykładowe wyniki testów CtsCompanionDeviceManager:

   

   Rysunek 4. Wyniki testów na wiele urządzeń po stronie hosta w aplikacji CTS Verifier.

   Uwaga: wyniki po stronie hosta są automatycznie dodawane do ogólnego raportu z testu CTS-V.

Opcjonalnie: przeprowadzanie testów połączenia z punktem dostępu Wi-Fi

Aby przeprowadzić testy połączenia z punktem dostępu Wi-Fi:

1. Edytuj plik konfiguracji testbedu (WifiConnectionTestbed.yaml). Ten plik znajduje się w katalogu, w którym rozpakowano CTS-Verifier:

   ./android-cts-verifier/android-cts-v-host/testcases/CtsWifiConnectionTests/x86_64/connection/WifiConnectionTestbed.yaml
   

2. Zmień wartość pola hostname na adres IP punktu dostępu na podstawie lokalnych ustawień SSH. Aby sprawdzić adres IP, przeczytaj artykuł Sprawdzanie adresu IP punktu dostępu.

   Poniższy przykład pokazuje lokalizację pola hostname w pliku WifiConnectionTestbed.yaml:

   TestBeds:
   - Name: WifiConnectionTestbed
     Controllers:
       # Specify settings for the AP.
       OpenWrtDevice:
       - hostname: AP-IP
         skip_init_reboot: True
   

3. W konsoli cts-v-host uruchom to polecenie:

   run everything -m CtsWifiConnectionTests
   

   Uwaga: więcej informacji o konsoli cts-v-host znajdziesz w artykule Uruchamianie testów na wielu urządzeniach.

Rozwiązywanie problemów z testami na wielu urządzeniach

W tej sekcji znajdziesz pomoc w rozwiązywaniu potencjalnych problemów.

Rozwiązywanie problemu z brakiem odpowiedzi na żądanie GetFirmwareVersion podczas testów NFC

Jeśli podczas przeprowadzania testów na wielu urządzeniach pojawi się komunikat verify_firmware_version RuntimeError: No response for GetFirmwareVersion, oznacza to, że testy nie mają dostępu do płytki NFC PN532.

Aby rozwiązać ten problem, znajdź ścieżkę szeregową używaną przez płytkę NFC PN532 na hoście, np. dev/ttyUSB1, a następnie ręcznie określ ją za pomocą argumentu --module-arg w konsoli:

run cts-v-host -m CtsNfcHceMultiDeviceTestCases --module-arg CtsNfcHceMultiDeviceTestCases:pn532_serial_path:/dev/ttyUSB1

Rozwiązywanie problemów z komunikatem o błędzie „Transakcja nie powiodła się” podczas testów NFC

Jeśli w przypadku wszystkich testów NFC otrzymujesz komunikat Transaction failed, check device logs for more information., prawdopodobnie oznacza to, że układ NFC DUT nie może wykryć układu PN532.

Jeśli do hosta jest podłączonych kilka urządzeń, a na niektórych z nich nie ma czytnika PN532, mogło zostać wybrane nieprawidłowe urządzenie DUT. Więcej informacji znajdziesz w artykule Konfigurowanie testów NFC.

Aby rozwiązać ten problem, wykonaj jedną z tych czynności:

• W poleceniu testowym po stronie hosta ustaw prawidłowy numer seryjny testowanego urządzenia za pomocą flagi -s.

• Odłącz od hosta wszystkie urządzenia inne niż DUT.

CDM test case test_permissions_sync is ignored

Jeśli test jest przeprowadzany na urządzeniach, na których nie można debugować aplikacji, sprawdź, czy nie obowiązuje Cię zwolnienie. W przeciwnym razie sprawdź, czy oba urządzenia spełniają wymagania wstępne.