Если тесты не проверяют права доступа разных ролей, начните с одного важного действия и двух владельцев данных. Разрешённый пользователь должен выполнить действие над своей записью; другой пользователь — получить отказ без изменения этой записи. Скрытая кнопка проверяет интерфейс, но сама по себе не доказывает запрет на сервере.
Подготовьте отдельный стенд, тестовые аккаунты и искусственные записи без данных клиентов. До отправки запросов согласуйте правила доступа с владельцем продукта. Проверка не должна угадывать права из существующего поведения: иначе тест закрепит ошибку как норму. Рабочие аккаунты и чужие реальные объекты для таких экспериментов не подходят.
Матрица начинается с действия, а не названия должности
| Контекст | Условное правило | Что проверять |
|---|---|---|
| Редактор, своя запись | Изменение разрешено | Сохранение нужного поля |
| Редактор, чужая запись | Изменение запрещено | Отказ и неизменность объекта |
| Наблюдатель, видимая запись | Только чтение | Нельзя изменить через запрос |
| Без сессии | Нет доступа | Нет закрытых данных в ответе |
Таблица условная: реальная система может разрешать редактору работу со всеми записями отдела. Добавьте область организации, состояние объекта и конкретное действие — просмотр, экспорт, изменение, удаление. Одинаковая роль в двух компаниях не обязательно даёт доступ к одним объектам. Администратора не используйте как универсальный аккаунт для всех сценариев.
Кнопку убрали — запрос всё равно проверяем
- Создать запись владельца A и сохранить исходное значение.
- Войти тестовым пользователем B с ограниченными правами.
- Отправить предусмотренный приложением запрос к этой тестовой записи.
- Проверить согласованный отказ и отсутствие закрытых полей в ответе.
- Прочитать запись разрешённым способом от имени A: значение не изменилось.
Не привязывайте все отказы к одному произвольному HTTP-коду: ожидаемый ответ определяется контрактом приложения. Важно, чтобы действие не прошло и ответ не раскрыл защищённые сведения. Если запись меняется фоновой задачей, проверяйте и её отсутствие. Красный баннер при уже выполненном изменении не является успешной защитой.
Сессии ролей нельзя незаметно смешать
Playwright позволяет готовить отдельные состояния авторизации для нескольких ролей. Его документация предупреждает: сохранённое состояние браузера может содержать чувствительные cookies и заголовки; такие файлы нельзя помещать в репозиторий. Источник проверен 11 октября 2026 года. Доступ к артефактам тестирования тоже ограничивайте.
Условный план, не готовый тест:
actor: editor_B
object_owner: editor_A
action: update_title
expected: denied
verify_after: title_equals_original
artifact: обезличенный идентификатор запускаПеред действием подтвердите текущую личность штатным безопасным способом, например по имени тестового пользователя в кабинете. При параллельных запусках выдавайте разные записи, чтобы соседний тест не менял объект проверки. Очистку выполняйте от специально разрешённого аккаунта, а не повышая права участника отрицательного сценария.
Снятие роли — отдельная проверка
Согласуйте, когда изменение прав должно вступать в силу: немедленно или после предусмотренного обновления сессии. Проверьте существующую сессию и новую после снятия роли. Нельзя объявить старую сессию допустимой только потому, что так получилось в первом запуске. То же касается переноса записи в другой отдел или закрытия доступа к организации.
- Разрешённое действие действительно выполняется.
- Запрещённый запрос не меняет данные и не создаёт фоновую работу.
- Чтение и экспорт проверены отдельно от редактирования.
- Каждый отрицательный сценарий имеет понятную причину отказа.
Первый полезный результат — небольшая утверждённая матрица с проверяемыми последствиями. Пройдите её вручную на искусственных данных, затем автоматизируйте. Когда правила изменятся, обновляйте договорённость и тест вместе: зелёный отчёт должен подтверждать актуальные права, а не вчерашнюю модель доступа.