Используйте подход, основанный на экранировании RF, в сочетании с мониторингом ADB logcat и инспекцией TLS с помощью Charles Proxy для проверки предоставления токенов и генерации криптограмм при ухудшенных условиях сигнала. Сосредоточьтесь на трех критически важных векторах: управление жизненным циклом службы HCE во время обмена APDU, обработка ошибок VTS SDK при плохих условиях RF и сохранение состояния потока 3DS2 во время переключений сети. Документируйте HEX нагрузки APDU с использованием фильтров Logcat в Android Studio, чтобы проверить, что HCE HostApduService правильно реагирует на команды SELECT PPSE и GPO, даже когда аттенюация сигнала моделирует физическое расстояние от терминала POS. Поддерживайте матрицу тестирования, которая изменяет силу поля NFC от -60 дБм до -90 дБм, вручную переключая Режим в самолете, чтобы смоделировать тайм-ауты протокола ISO 14443.
Во время проверки интеграции VTS для банковского приложения первого уровня мы обнаружили критическое состояние гонки при аттенюации поля NFC. Быстрое удаление устройства от терминала POS во время обмена командой GPO (Получить параметры обработки) привело к тому, что служба HCE вошла в «зомби-состояние». В этом состоянии стек NFC Android сообщал, что служба активна, но апплет Visa не смог сгенерировать Application Cryptogram (AC), что привело к таинственной ошибке «Ошибка чтения карты» на дисплее терминала.
Первый подход заключался в изменении физического расстояния вручную без измерительных инструментов. Хотя этот метод не требовал специального оборудования и мог быть выполнен немедленно любым тестировщиком, он оказался неэффективным, поскольку время реакции человека препятствовало постоянному поддержанию точного порога -80 дБм, необходимого для вызова обрушения поля RF в момент обмена командой GPO.
Второй стратегией было использование автоматизированного UI тестирования с помощью Appium для сценариев перемещения устройства и изменения состояния сети. Хотя это обеспечивало точный контроль времени, это нарушало требования ручного тестирования для этой конкретной сертификации и не могло смоделировать сложные мультипутевые помехи RF, вызванные захватом устройства рукой и поглощением телесной ткани.
Третье решение разработало систематический протокол ручного тестирования с использованием ферритовой палатки с переменными слоями аттенюации и включенными флагами отладки сервиса nfc в Android с помощью команд оболочки ADB. Этот подход позволил тестировщикам точно контролировать силу поля, одновременно наблюдая за временем APDU в реальном времени через adb logcat | grep HostApduService, хотя он требовал дорогостоящего оборудования для тестирования RF и значительного времени на настройку для правильной калибровки уровней аттенюации.
Мы выбрали третий подход, потому что он обеспечивал воспроизводимый контроль над средой RF, сохраняя при этом исследовательский характер ручного тестирования, необходимого для выявления тонких вопросов удобства использования. Эта методология показала, что служба HCE неправильно реализует обработчик команды ISO 14443-4 DESELECT, из-за чего служба зависала, когда поле RF падало ниже оперативного порога во время активной связи. Эта информация была бы невозможна для получения только с помощью автоматизированного тестирования, так как требовала наблюдения человека за конкретным временем сообщения об ошибке на терминале POS.
Реализовав правильную обработку DESELECT в колбэке onDeactivated() сервиса, мы полностью исключили зомби-состояние. Последующее регрессионное тестирование подтвердило отсутствие призрачных транзакций в 400 ручных тестах с различными профилями аттенюации. Приложение затем успешно прошло сертификацию Visa TTE (Тестирование интеграции терминала) с первой попытки, что сэкономило три недели потенциальной переработки.
Как вы проверяете временные ограничения ответа APDU, когда метки времени Android Logcat имеют миллисекундную точность, а спецификации EMV требуют микросекундной точности?
Вы не можете полагаться исключительно на Logcat для микросекундного тайминга, поэтому необходимо использовать комбинацию анализаторов протокола USB, таких как Total Phase Beagle, или трекеры Ellisys Bluetooth/NFC, чтобы захватить метки времени передачи сырого слоя RF независимо от системы-хоста Android. В то же время коррелируйте эти аппаратные метки времени с возвращаемыми значениями HostApduService.processCommandApdu() в Logcat, чтобы выявить задержки обработки. В частности, убедитесь, что БЕСПРОВОДНОЙ ответ терминалу POS происходит в пределах FGT (Frame Guard Time) в 242 ETU (Elementary Time Units) согласно ISO 14443-4, и вручную вычислите дельту между захватом RF и вводом Logcat, чтобы обнаружить задержку службы HCE, которая может вызвать таймауты терминала в периоды пиковых нагрузок транзакций.
Какой ручной метод выявляет сбои токенизации VTS, когда SDK возвращает общий код ошибки ERROR_UNKNOWN вместо конкретных кодов состояния HTTP?
Когда Visa Token Service SDK скрывает сетевые ошибки, вам необходимо вручную декомпилировать Smali код отладочной сборки или использовать Charles Proxy с отключенным SSL пином, чтобы перехватить HTTPS трафик между клиентом VTS и конечными точками TSP (Поставщик услуг токенов). Ищите вызов API provisionToken() и вручную проверяйте JSON ответ на наличие поля tokenInfo.tokenStatus; если оно возвращает INACTIVE или SUSPENDED немедленно после предоставления, проверьте под-объект tokenInfo.errorDetails. Кроме того, вручную инициируйте коллизии Provisioning ID (PID), пытаясь предоставить один и тот же PAN (Основной номер счета) на двух различных устройствах одновременно, чтобы проверить, что служба HCE корректно обрабатывает ответы HTTP 409 (Конфликт), предлагая пользователю деактивировать существующий токен, а не аварийно завершаться.
Как вы проверяете непрерывность потока 3DS2 без трения, когда генерация отпечатка устройства (SDK запросителя 3DS) блокируется режимом Doze Android или агрессивной оптимизацией батареи OEM?
Вам необходимо вручную активировать режим Doze с помощью команд ADB (adb shell dumpsys deviceidle force-idle) Immediately перед началом транзакции, а затем проверить, успешно ли 3DS2 SDK собирает параметры устройства (такие как deviceID и sdkAppID) или возвращает sdkTransID с неполными показателями вызова вызова. Проверьте Logcat на наличие записей с тегом THREE_DS, показывающих compInd: N (индикатор завершения ложный) при составлении сообщения CReq. Кроме того, вручную исключите банковское приложение из оптимизации батареи в настройках, специфичных для OEM (таких как Samsung's Device Care или Xiaomi's MIUI). Повторите тест, чтобы подтвердить, что поток без трения (при котором никакие вызовы не представлены) завершается успешно только тогда, когда нагрузка Device Fingerprint содержит все необходимые поля, гарантируя, что вы проверяете как ухудшенный путь аутентификации, так и оптимальный путь во время ручных регрессионных циклов.