В матрице совместимости биометрический вход работает на одном устройстве, но недоступен на другом с той же версией ОС. Как проверить зависимость результата от аппаратных возможностей устройства?
Нужно проверять не только версию ОС и модель устройства, но и набор доступных биометрических возможностей: наличие сенсора, зарегистрированной биометрии, включённой блокировки экрана и поддерживаемого системой класса аутентификации. Сравнение следует проводить на устройствах с разными возможностями, фиксируя системный результат доступности биометрии до запуска основного сценария приложения.
Если биометрия недоступна из-за оборудования или настроек устройства, приложение не должно трактовать это как дефект авторизации. Оно должно корректно предложить предусмотренный запасной способ входа либо явно сообщить, что функция недоступна.
Мобильные приложения работают поверх большого числа комбинаций ОС, аппаратных компонентов и системных настроек. Биометрия особенно хорошо показывает эту проблему: одинаковая версия платформы не гарантирует наличие одного и того же сенсора, метода распознавания или состояния регистрации пользователя.
Системные средства вроде LocalAuthentication на iOS и BiometricPrompt на Android появились как абстракции над конкретными способами проверки личности. Они позволяют приложению не реализовывать распознавание самостоятельно, но не устраняют различия в возможностях устройств.
Тест только на одном современном телефоне подтверждает лишь успешный сценарий на конкретной конфигурации. Он не показывает, что произойдёт на устройстве без биометрического сенсора, без зарегистрированного отпечатка или лица, с отключённой блокировкой экрана либо с иной поддерживаемой системой категорией биометрии.
Неверный вывод приводит к двум типичным ошибкам. Тестировщик может зарегистрировать аппаратное ограничение как дефект приложения или, наоборот, принять случайный переход к PIN-коду за корректную поддержку биометрии. В результате пользователи получают либо недоступный вход без объяснения причины, либо ошибочное обещание одинакового поведения на всех устройствах.
Сначала нужно разделить возможность использовать биометрию и результат конкретной попытки аутентификации. В первой группе проверяют наличие поддерживаемого оборудования, регистрацию биометрии в настройках, активность системной блокировки и разрешённый приложению способ входа. Во второй — успешное распознавание, отказ пользователя, несколько неудачных попыток, отмену системного диалога и переход к резервному методу.
Для диагностики полезна матрица по возможностям, а не только по названиям моделей:
На iOS нужно учитывать различие между Touch ID и Face ID, а также системную доступность выбранного способа аутентификации. На Android различия дополнительно зависят от реализации производителя и того, какие системные биометрические классы устройство считает пригодными для конкретной операции. Поэтому нельзя строить ожидаемый результат только на названии версии ОС.
Каждый тест должен фиксировать исходные условия: модель и версию ОС, наличие и тип биометрии, факт регистрации данных, состояние блокировки экрана и выбранный резервный сценарий. Для автоматизации желательно подготавливать состояния устройства отдельно, потому что эмулятор не всегда воспроизводит аппаратные и системные ограничения реального телефона.
Компромисс состоит в размере матрицы. Проверять каждую модель невозможно, поэтому выбирают представителей классов возможностей и наиболее значимые версии ОС, а затем дополняют их данными с реальных устройств и отчётов пользователей. При этом критичный сценарий отказа следует проверять на нескольких производителях, поскольку одинаковый системный контракт может иметь различия в пользовательском поведении.
На одном устройстве Android вход по отпечатку проходил, а на другом с той же версией ОС кнопка биометрии сразу исчезала. Были рассмотрены три варианта: считать это дефектом интерфейса, добавить кнопку принудительно или проверить системную доступность функции до построения экрана.
Первый вариант был слишком рискованным: он игнорировал возможность отсутствия сенсора или зарегистрированной биометрии. Принудительное отображение кнопки также было неверным, поскольку пользователь мог получить действие, которое система не способна выполнить. Выбрали третий вариант: приложение запрашивало системное состояние доступности, показывало биометрический вход только при подходящей конфигурации и сохраняло вход по коду как резервный путь.
После этого отдельно проверили устройство без сенсора, устройство с незарегистрированной биометрией, отмену системного диалога и несколько неудачных попыток. Результатом стало предсказуемое поведение интерфейса: аппаратная недоступность больше не выглядела как случайная ошибка авторизации, а пользователь всегда имел понятный запасной сценарий.
1. Достаточно ли проверить устройство с биометрическим сенсором, но без зарегистрированного отпечатка или лица?
Нет. Наличие оборудования и готовность биометрии к использованию — разные состояния. Система может поддерживать сенсор, но считать функцию недоступной, пока пользователь не зарегистрировал биометрические данные или не настроил обязательную блокировку экрана.
Такой сценарий нужно включать в тестовую матрицу отдельно. Ожидаемый результат обычно состоит не в показе ошибки сервера, а в корректном переходе к регистрации, коду или другому предусмотренному способом входа — в зависимости от требований продукта.
2. Нужно ли ожидать одинаковый интерфейс и одинаковое название биометрического метода на iOS и Android?
Нет. Платформы могут использовать разные типы сенсоров и разные системные формулировки. Даже внутри одной платформы интерфейс и доступный метод зависят от устройства и настроек пользователя.
Тестировать следует пользовательский контракт: понятно ли, что произойдёт, можно ли отменить операцию, корректно ли обработан отказ и доступен ли резервный вход. Привязка проверки к конкретной надписи, пиктограмме или виду системного диалога делает тест хрупким.
3. Можно ли считать успешный вызов системной биометрии доказательством защищённости приложения?
Нет. Успешная системная аутентификация подтверждает прохождение проверки, предоставленной платформой, но не доказывает корректность всей бизнес-логики приложения. Нужно отдельно проверить, что после успеха открывается только разрешённый ресурс, результат не принимается повторно некорректным образом, а выход из учётной записи действительно отменяет локальный доступ.
Кроме того, следует проверить отказ, отмену, временную блокировку после неудачных попыток и изменение системной биометрии. Эти события могут требовать повторной авторизации или сброса локального доверия, поэтому один успешный сценарий не покрывает жизненный цикл функции.