Как протестировать веб-сайт, используя несколько учетных записей пользователей и браузерных сред

Создайте матрицу ролей и способностей.

Перечислите каждую роль среди таких действий, как просмотр информационной панели, приглашение пользователей, редактирование контента, удаление записей и экспорт данных. Отметьте каждый ожидаемый результат как разрешающий, отрицающий или условный. Создайте хотя бы одно приспособление учетной записи для каждой роли и предоставьте ему предсказуемые данные. Проверьте как видимое поведение пользовательского интерфейса, так и авторизацию сервера: скрытие кнопки не является доказательством того, что неавторизованный запрос заблокирован. Включите пользователей, чьи разрешения изменяются во время активного сеанса.

Выберите изоляцию, соответствующую тесту.

Для автоматизированных регрессий свежие контексты Playwright или специальные профили Selenium могут изолировать тестовые случаи и уменьшить утечку состояний. При ручном исследовательском тестировании именованные профили рабочего стола могут сделать переключение между ролями пользователей менее подверженным ошибкам. Social Browser обеспечивает видимый рабочий процесс, ориентированный на профиль, который может подходить как для ручной, так и для автоматической проверки. Какой бы метод вы ни использовали, держите тестовые учетные записи и промежуточные среды отдельно от производственных удостоверений клиентов.

Тестируйте межпользовательские события, а не только статические страницы.

Создайте общий документ в качестве владельца, пригласите редактора, а затем проверьте режим просмотра только для чтения в другом профиле. Отмените доступ и проверьте, отражают ли изменения оба клиента. Повторите то же самое с уведомлениями, устаревшими вкладками браузера, выходом из системы и одновременным редактированием. Обратите внимание на кэшированный пользовательский интерфейс: на экране могут отображаться старые элементы управления, даже если сервер корректно отклоняет действие. Запишите как визуальное состояние, так и фактическую реакцию.

Храните данные испытаний одноразовыми и доступными для проверки.

Не используйте повторно действующие токены клиентов и не копируйте производственные базы данных без надлежащей анонимизации. Назовите профили по среде и роли и при необходимости сбросьте тестовые учетные записи между наборами. Сохранение сеанса полезно для отладки неудачного потока, но не должно автоматически сохраняться в предположительно чистом тесте. Сохраняйте минимальное количество снимков экрана или трассировок и редактируйте личные поля, прежде чем делиться дефектами.

Тест ролевой матрицы: приглашение не должно предоставлять дополнительные разрешения.

Ситуация

Приложение для совместной работы имеет владельца, который может приглашать людей, редактора, который может изменять содержимое проекта, и средства просмотра, которое может читать утвержденные записи. Выполнение этих тестов на обычной общей вкладке браузера может привести к путанице в ролях, поскольку файлы cookie сайта обычно используются вкладками одного и того же профиля.

Как безопасно запустить его

Создайте пользователей только для тестирования с известными назначениями ролей и предоставьте каждому отдельный контекст браузера или профиль. Попросите владельца пригласить редактора, а затем подтвердите панель управления редактора и права на редактирование. Затем откройте тот же проект, что и Viewer, и убедитесь, что элементы управления редактированием отсутствуют и что серверная часть отклоняет прямой запрос на запись. Измените роль зрителя, пока его сеанс остается открытым, и проверьте правильность обновления разрешений.

Как рабочий процесс может дать сбой

Отсутствие кнопки редактирования — это наблюдение пользовательского интерфейса, а не подтверждение контроля доступа. И наоборот, кэшированная кнопка может по-прежнему отображаться, даже если серверная часть правильно отклоняет запрос. Записывайте как поведение, видимое браузером, так и ответ службы. Никогда не используйте реальных клиентов или списки приглашенных на производство только для создания тестовых приспособлений.

Что считается завершением

Результат регрессии определяет роль каждой тестовой учетной записи, ожидаемую матрицу разрешения/запрета и точное проверяемое действие. Неудачные тесты должны быть воспроизводимы в новых контекстах, при этом все сохраненные снимки экрана должны быть свободны от ненужных личных данных.

Практические шаги проверки

1. Изолируйте сеансы владельца, редактора и просмотра.
2. Подтвердить авторизацию сервера, а также видимые элементы управления.
3. Разрешение на тестирование меняется во время активного сеанса.
4. Уничтожить или сбросить тестовые приспособления после набора

Пример: применение руководства на практике.

Приложение для управления проектами имеет роли менеджера, участника и наблюдателя. Тестировщик оставляет открытыми три изолированных профиля, обновляет проект в качестве менеджера, а затем проверяет, что может видеть каждая другая роль. Наконец, менеджер отзывает участника и проверяет, что существующие вкладки больше не могут вносить изменения.

Часто задаваемые вопросы

Могут ли разные вкладки имитировать разных пользователей?

Могут, если настроены изолированные контексты, но обычные вкладки в одном профиле часто используют файлы cookie одного и того же сайта.

Заменяет ли выделенный профиль проверку разрешений сервера?

Нет. Авторизация должна обеспечиваться серверной частью приложения, а также представляться пользовательским интерфейсом.

Официальная документация и дополнительная литература

Используйте эти основные ссылки для проверки соответствующих возможностей и разрешений платформы. Документация поставщика может измениться; прежде чем действовать, подтвердите текущие условия и версию продукта.

• Драматург: Контексты браузера