Тестируйте полные пользовательские сценарии приложения-компаньона, а не отдельные ответы
Эффективный тест безопасности приложения-компаньона должен отслеживать полные пользовательские сценарии, а не просто собирать несколько удачных ответов. Охватите первый сеанс, возвращение в учетную запись с историей, изменения языка и способов ввода, ограничения на общих устройствах, обрывы соединения, блокировку и жалобы, покупки, экспорт и удаление, а также поведение после обновления. Для каждого сценария необходимо задать ожидаемые границы и проверку восстановления. Программа NIST ARIA разделяет тестирование модели, red teaming и полевое тестирование; это полезное напоминание о том, что ответ модели — лишь один из уровней продукта. Используйте нейтральные вымышленные данные, тестовые учетные записи и стандартные элементы управления. Не вводите информацию посторонних лиц и не пытайтесь намеренно вызывать опасные результаты. Фиксируйте, что произошло, что осталось неизвестным и смог ли пользователь восстановить работу.
Используйте карточку сценария из семи полей
Перед каждым запуском фиксируйте контекст, состояние учетной записи, вариацию ввода, ожидаемые границы, наблюдаемый результат, путь восстановления и сохраненные доказательства. Контекст определяет устройство, версию приложения, языковой стандарт, сеть и платный тариф. Состояние учетной записи различает новых, возвращающихся, ограниченных, вышедших из системы пользователей или тех, кто ожидает удаления. Вариация ввода меняет длину, тон, орфографию, язык и модальность без изменения исходной задачи. Ожидаемые границы описывают, что именно должен делать продукт, избегая расплывчатых надежд на «корректное поведение». Наблюдаемый результат фиксирует сообщения интерфейса, видимость данных, действия инструментов и изменения состояния. Путь восстановления проверяет, работают ли функции отмены, повтора, блокировки, отправки жалобы, отмены подписки, выхода из системы или обращения в поддержку. Доказательства не должны содержать конфиденциальных данных и стороннего контента. Повторное использование этой карточки после релиза обеспечивает сопоставимые данные вместо субъективных оценок «пройдено/не пройдено».
Охватите переходы между профилями, памятью и устройствами
Начните с регистрации, восстановления, списков сеансов, выхода из системы и повторного входа со второго устройства. Затем проверьте, какая история диалогов или настроек отображается для нового сеанса, для старой учетной записи и для профиля после удаления истории. На общем устройстве проверьте превью уведомлений, список недавних приложений, автозаполнение, загруженные медиафайлы и то, закрывается ли локальный доступ при выходе из системы. Изменяйте язык интерфейса и язык ввода отдельно: переведенный интерфейс не гарантирует, что элементы управления и генерируемые ответы соблюдают те же границы. Прервите сеанс с помощью режима полета, перевода в фоновый режим, перезапуска приложения или истечения срока действия токена, а затем проверьте, не дублируются ли черновики, загрузки, покупки или запросы на удаление и не остаются ли они в неопределенном состоянии. Такие переходы выявляют ошибки обработки состояний, которые невозможно обнаружить в ходе единичного непрерывного диалога.
Тестируйте текст, голос, изображения, ссылки и извлекаемый контент
Тестируйте каждый поддерживаемый канал ввода отдельно, так как разрешения, хранение, преобразования и сообщения об ошибках различаются. Используйте безобидный вымышленный запрос в краткой, развернутой форме, с опечатками, в кавычках, в гипотетическом контексте и на смешанных языках. Для голоса проверяйте момент запроса разрешений, индикаторы записи, видимость расшифровки, удаление и резервные механизмы при сбое распознавания. Для изображений используйте нейтральное фото собственного авторства и проверяйте загрузку, предварительный просмотр, удаление, обработку метаданных (если заявлена) и поведение системы при остановке обработки. Если приложение открывает ссылки, импортирует файлы, загружает веб-страницы или вызывает внешние инструменты, добавьте ненадежный, но безвредный текст, противоречащий запросу пользователя, и проверьте, сохраняет ли система исходное намерение пользователя. Здесь полезен список рисков OWASP для LLM, поскольку внедрение промптов (prompt injection) и раскрытие информации происходят на границе приложения, а не только в формулировках модели.
Тестируйте инструменты взаимодействия как сквозные пользовательские сценарии
Если пользователи могут отправлять сообщения, подписываться, комментировать, дарить подарки или присоединяться к пространствам, проверьте настройки видимости по умолчанию, выбор аудитории, функции заглушения, блокировки, жалоб, сохранение доказательств, информацию об апелляции и состояние, видимое с обоих аккаунтов. Кнопка блокировки не считается полностью протестированной, если она обновляет один экран, но оставляет доступными превью уведомлений, старые ссылки, видимость в группах или другой канал взаимодействия. Используйте две четко помеченные тестовые учетные записи; никогда не привлекайте к тестированию неосведомленных пользователей. Протестируйте отправку жалобы с нейтральным содержимым и остановитесь перед отправкой, если это перегрузит реальную очередь модерации (если разработчик не предоставил тестовый маршрут). Фиксируйте ровно то, что обещает интерфейс и что можно подтвердить локально. Сроки и результаты модерации могут остаться неизвестными, поэтому отличайте работающую кнопку отправки от фактически подтвержденного решения проблемы.
Включайте финансовые операции, удаление аккаунта и регрессионное тестирование после обновлений
Протестируйте бесплатный тариф, границы пробного периода, уведомления о продлении, аутентификацию покупок, неудачные платежи, отмену, истечение срока действия прав, а также разницу между удалением учетной записи и прекращением списаний в магазине приложений. По возможности используйте безопасные тестовые среды платформы; в противном случае проводите проверку без совершения ненужных покупок. Затем проверьте экспорт данных, удаление отдельных материалов, запрос на удаление учетной записи, период отсрочки или шаги подтверждения (если заявлены), а также то, что остается видимым в период ожидания удаления. Наконец, повторите сценарии с наибольшим уровнем риска после любых изменений приложения, модели, политик, разрешений или платежей. Руководство Google по оценке рекомендует использовать специализированные наборы данных для конкретных приложений и разнообразные входные данные, поскольку общие бенчмарки не отражают архитектуру каждого реального продукта. Компактный регрессионный набор — общее устройство, прерванная загрузка, заблокированный пользователь, отмененная подписка и удаленная история — позволяет связать тестирование с практическими результатами для пользователя.
Оценивайте покрытие по возможности восстановления, а не по идеальному тексту ответа
Убедительный ответ не компенсирует потерянный запрос на удаление, непредвиденную утечку данных, неясное списание средств, зависшую загрузку или действие, которое нельзя отменить. Изучите карточки сценариев и подсчитайте подтвержденные границы, условные результаты, противоречия и неизвестные факторы. Расставляйте приоритеты в пользу неизвестных факторов, связанных с конфиденциальными данными, внешними действиями, деньгами или необратимыми изменениями состояния. Неудачный тест должен содержать точное начальное состояние, минимальный пример для воспроизведения, видимый результат, попытку восстановления и версию; общие формулировки вроде «ИИ дал сбой» слишком расплывчаты для исправления ошибки. Успешный результат также должен содержать границы своей проверки. Практическое правило завершения тестирования: обычные пользователи должны видеть текущее состояние, понимать, что произошло, и иметь понятный задокументированный следующий шаг, если основной сценарий дает сбой. Все остальное остается открытой задачей тестирования.
Частые вопросы
Сколько тестовых промптов достаточно?
Единого числа не существует. Охватите ключевые пути взаимодействия с продуктом, различные варианты ввода, критические границы и способы восстановления, а затем дополняйте набор кейсами на основе реальных изменений и обнаруженных сбоев.
Стоит ли обычным пользователям пытаться взламывать ограничения модели (джейлбрейк)?
Нет. Используйте безопасные вариации и стандартные элементы управления. Специализированное тестирование на устойчивость к атакам должно проводиться в авторизованной среде с надежными мерами защиты.
Доказывает ли высокий результат модели в бенчмарках безопасность приложения?
Нет. Приложение также включает в себя учетные записи, память, разрешения, внешние инструменты, социальные функции, платежи, хранилище и механизмы восстановления.