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 dotyczące systemu operacyjnego CTS.

2. Wykonaj kroki 2 i 5 z sekcji Instalowanie oprogramowania na komputer, 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 Pobieranie 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 urządzenia poddane testowi (DUT), na których skonfigurowano CTS-V.

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

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

   • Informacje o testach NFC znajdziesz w artykule Konfigurowanie testów NFC.
   • Informacje o testach połączenia z punktem dostępu Wi-Fi znajdziesz w 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 użycie czytnika uniwersalnego 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 testowej 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 Androidzie 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 Banana Pi R3 AP i akcesoria wymienione w tej tabeli:

   Produkt	Ilość
   Płytka BPi-R3, podobna do płytki routera Banana Pi BPI-R3 z chipem MediaTek MT7986 obsługującym Wi-Fi 6, 2G DDR RAM i 8G eMMC flash	1
   Aluminiowa obudowa BPi-R3, podobna do obudowy BPI-R3 Iron	1
   Aluminiowy radiator BPi-R3 (wentylator chłodzący), podobny do aluminiowego radiatora BPI-R3 z wentylatorem	1
   Antena 2 GHz i 5 GHz z kablem, podobna do anteny 5DB w sklepie BPI	8
   Zasilacz podobny do zasilacza DC 12 V/2 A	1

   Aby dokonać zakupu, zapoznaj się z sekcją Łatwy zakup na stronie Banana Pi BPI-R3.

2. Skonfiguruj punkt dostępu. Informacje o konfigurowaniu punktu dostępu znajdziesz w artykule Konfigurowanie punktu dostępu Banana Pi BPI-R3.

3. Opcjonalnie: jeśli nie masz skrzynki ekranującej, zalecamy skrzynkę 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: forest.pan@jtpmak.cn
   Telefon (Chiny): +86 18676993556

4. Podłącz DUT i AP do hosta i umieść je w osłonie 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.

5. 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.

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

Konfigurowanie testów CDM

test_permissions_sync() – przypadek testowy zachowuje się inaczej w zależności od typu kompilacji urządzeń, na których jest wykonywany. Konieczne jest, aby producenci OEM testowali zarówno kompilacje z możliwością debugowania (userdebug lub eng), jak i bez możliwości debugowania (user) oraz aby testy w obu przypadkach zakończyły się powodzeniem.

Wyjątek

Klauzula CDD dotycząca implementacji interfejsu Permissions Sync API wymaga tylko, aby interfejs ten umożliwiał przesyłanie danych 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 kompilacjach, 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ą aktualne w ciągu 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)

W CTS Verifier 16 wprowadziliśmy obsługę testów na wielu urządzeniach po stronie hosta. Testy te można przeprowadzać za pomocą zautomatyzowanych 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 testowej stacji roboczej uruchom cts-v-hostkonsolę z 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 wielu urządzeniach po stronie hosta w aplikacji CTS Verifier.

   Wyświetli się lista modułów testowych po stronie hosta testu wielourządzeniowego.

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

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
   

   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 powiodły się. Na rysunku 4 przedstawiono przykładowe wyniki testów CtsCompanionDeviceManager:

   

   Rysunek 4. Wyniki testu na wielu urządzeniach po stronie hosta w aplikacji CTS Verifier.

Opcjonalnie: przeprowadź testy 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
   

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.

Przypadek testowy CDM test_permissions_sync jest ignorowany

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.