Użyj podejścia opartego na ekranowaniu RF w połączeniu z monitorowaniem logcat ADB i inspekcją TLS w Charles Proxy, aby zweryfikować proces tokenizacji i generowanie kryptogramów w warunkach degradacji sygnału. Skoncentruj się na trzech krytycznych wektorach: zarządzanie cyklem życia usługi HCE podczas wymiany APDU, obsługa błędów SDK VTS w trudnych warunkach RF, oraz zachowanie stanu przepływu wyzwań 3DS2 podczas przełączeń sieciowych. Dokumentuj ładunki HEX APDU za pomocą filtrów Logcat w Android Studio, aby zweryfikować, że HostApduService HCE poprawnie odpowiada na polecenia SELECT PPSE i GPO, nawet gdy osłabienie sygnału symuluje fizyczną odległość od terminala POS. Utrzymuj matrycę testów, która zmienia siłę pola NFC od -60 dBm do -90 dBm, ręcznie przełączając tryb Samolot w celu symulacji limitów czasowych protokołu ISO 14443.
Podczas weryfikowania integracji VTS dla aplikacji bankowej klasy premium odkryliśmy krytyczny warunek wyścigu podczas osłabiania pola NFC. Szybkie oddalenie urządzenia od terminala POS podczas wymiany polecenia GPO (Get Processing Options) spowodowało, że usługa HCE weszła w "stan zombie". W tym stanie stos NFC w Androidzie zgłaszał usługę jako aktywną, ale aplet Visa nie był w stanie wygenerować Kryptogramu Aplikacji (AC), co skutkowało tajemniczym błędem „Błąd odczytu karty” na wyświetlaczu terminala.
Pierwsze podejście polegało na ręcznym zmienianiu fizycznej odległości bez narzędzi pomiarowych. Chociaż ta metoda nie wymagała specjalistycznego sprzętu i mogła być natychmiast wykonana przez każdego testera, okazała się nieskuteczna, ponieważ czas reakcji człowieka uniemożliwiał konsekwentne utrzymanie dokładnego progu -80 dBm potrzebnego do uruchomienia spadku pola RF w dokładnym momencie wymiany GPO.
Drugą strategią było zautomatyzowane testowanie UI z użyciem Appium, aby zarejestrować ruch urządzenia i zmiany stanu sieci. Chociaż oferowało to precyzyjną kontrolę nad czasowaniem, naruszało wymóg testowania manualnego dla tego konkretnego wymogu certyfikacyjnego i nie mogło symulować złożonego zakłócenia wielościeżkowego RF, wywołanego przez chwyt dłonią i absorpcję tkanki ciała.
Trzecie rozwiązanie skonstruowało systematyczny protokół testów manualnych z użyciem namiotu Faradaya z zmiennymi warstwami osłabienia oraz flagami debugowania usługi nfc w Androidzie włączonymi za pomocą poleceń powłoki ADB. To podejście pozwoliło testerom precyzyjnie kontrolować siłę pola, jednocześnie obserwując w czasie rzeczywistym czas APDU za pomocą adb logcat | grep HostApduService, chociaż wymagało kosztownego sprzętu do testów RF i znacznego czasu konfiguracji, aby dokładnie skalibrować poziomy osłabienia.
Wybraliśmy trzecie podejście, ponieważ zapewniało ono powtarzalną kontrolę nad środowiskiem RF, zachowując jednocześnie eksploracyjny charakter testowania manualnego, którego celem było wykrywanie subtelnych problemów z użytecznością. Ta metodologia ujawniła, że usługa HCE nie implementowała poprawnie obsługi komendy ISO 14443-4 DESELECT, co powodowało zablokowanie usługi w momencie, gdy pole RF spadło poniżej progów operacyjnych podczas aktywnej komunikacji. Ta informacja byłaby niemożliwa do uzyskania tylko poprzez testy automatyczne, ponieważ wymagała ludzkiej obserwacji czasu specyficznych komunikatów o błędach na terminalu POS.
Wdrożając odpowiednią obsługę DESELECT w wywołaniu zwrotnym onDeactivated() usługi, całkowicie wyeliminowaliśmy stan zombie. Subsekwentne testy regresyjne potwierdziły brak transakcji duchów w 400 testach manualnych z różnymi profilami osłabienia. Aplikacja zdała certyfikację Visa TTE (Testy Integracji Terminali) przy pierwszym zgłoszeniu, oszczędzając trzy tygodnie potencjalnego przetwarzania.
Jak weryfikujesz ograniczenia czasowe odpowiedzi APDU, gdy znaczniki czasowe Logcat w Androidzie mają precyzję milisekundową, ale specyfikacje EMV wymagają precyzji mikrosekundowej?
Nie możesz polegać wyłącznie na Logcat dla pomiarów mikrosekundowych, więc musisz używać połączenia analizatorów protokołów USB, takich jak Total Phase Beagle lub Ellisys Bluetooth/NFC na przechwytywanie znaczników czasu transmisji na warstwie RF niezależnie od systemu gospodarza Android. Jednocześnie skoreluj te znaczniki czasowe sprzętowe z wartościami zwracanymi przez HostApduService.processCommandApdu() w Logcat, aby zidentyfikować opóźnienia w przetwarzaniu. Specyficznie upewnij się, że odpowiedź BEZPRZEWODOWA do terminala POS występuje w ciągu FGT (Czasu Guard Frame) wynoszącego 242 ETU (Elementary Time Units) zgodnie z ISO 14443-4, i ręcznie oblicz różnicę pomiędzy przechwyceniem RF a wpisem w Logcat, aby wykryć opóźnienie usługi HCE, które mogłoby spowodować czasowe limitacje terminala w szczytowych obciążeniach transakcyjnych.
Jaka technika manualna ujawnia błędy provisioningowe VTS, gdy SDK zwraca ogólny kod błędu ERROR_UNKNOWN zamiast specyficznych kodów statusu HTTP?
Gdy Visa Token Service SDK zaciemnia błędy sieciowe, musisz ręcznie dekompilować kod Smali wersji debugowania lub użyć Charles Proxy z wyłączonym pinningiem SSL, aby przechwycić ruch HTTPS między klientem VTS a punktami końcowymi TSP (Dostawca Usług Tokenizacji). Szukaj wywołania API provisionToken() i ręcznie sprawdź odpowiedź JSON w polu tokenInfo.tokenStatus; jeśli zwraca INACTIVE lub SUSPENDED natychmiast po provisioning, sprawdź pod-obiekt tokenInfo.errorDetails. Dodatkowo ręcznie wyzwól kolizje Provisioning ID (PID), próbując jednocześnie zaktywować ten sam PAN (Podstawowy Numer Konta) na dwóch różnych urządzeniach, aby zweryfikować, że usługa HCE poprawnie obsługuje odpowiedzi HTTP 409 (Konflikt) poprzez wezwanie użytkownika do dezaktywacji istniejącego tokena, zamiast wywoływać awarię.
Jak weryfikujesz ciągłość przepływu bezdotykowego 3DS2, gdy generacja Device Fingerprint (SDK aplikacji 3DS Requestor) jest zablokowana przez tryb Doze w Androidzie lub agresywne optymalizacje baterii OEM?
Musisz ręcznie wyzwolić tryb Doze za pomocą poleceń ADB (adb shell dumpsys deviceidle force-idle) tuż przed zainicjowaniem transakcji płatniczej, a następnie obserwować, czy SDK 3DS2 skutecznie gromadzi parametry urządzenia (takie jak deviceID i sdkAppID) lub zwraca sdkTransID z niekompletnymi wskaźnikami wyzwania. Sprawdzaj Logcat pod kątem wpisów oznaczonych tagiem THREE_DS, które pokazują compInd: N (wskaźnik ukończenia fałszywy) w momencie konstrukcji komunikatu CReq. Ponadto ręcznie dodaj aplikację bankową do wyjątków optymalizacji baterii w ustawieniach specyficznych dla OEM (takich jak Samsung's Device Care lub Xiaomi's MIUI oszczędzanie baterii) i powtórz test, aby potwierdzić, że przepływ bezdotykowy (gdzie nie przedstawiono wyzwania) udaje się tylko wtedy, gdy ładunek Device Fingerprint zawiera wszystkie wymagane pola, zapewniając, że weryfikujesz zarówno degradacyjną ścieżkę uwierzytelnienia, jak i optymalną ścieżkę podczas manualnych cykli regresji.