Чит-лист — это шпаргалка по выбранной теме, что не забыть проверить. Берете чит-лист как основу, адаптируете под свой проект, и готово!
В своей книге про тест-дизайн я написала ряд чит-листов, которыми и хочу теперь поделиться. Сегодня поговорим про ролевую модель в GUI и API — это когда у нас есть разграничение прав для отдельных пользователей / целых групп (им назначается роль).
Набор ролей может быть очень обширным — права только на просмотр, на редактирование, на редактирование конкретной сущности или даже одного поля в этой сущности, просмотр конкретной страницы (отчетность или аудит), создание связи…
Но если брать в целом, обычно у нас есть:
простые пользователи — у каждой группы свой набор прав;
админ — всесильный пользователь;
гость — неавторизованный пользователь (это, по сути, проверка на ноль).
Давайте разберемся, как будем их проверять:
GUI — графический интерфейс пользователя
Для любого действия в системе пробуем выполнить его под:
пользователем, у которого есть на это права;
пользователем, у которого нет на это прав;
гостем;
админом.
Если стоит задача проверить саму ролевую модель, то берем роль и проверяем для каждой действия, для которых:
есть доступ;
нет доступа.
Например, я, как автор статей на хабре, могу редактировать свои статьи. Тогда пробуем:
отредактировать свою статью;
отредактировать чужую статью (убедиться, что кнопки редактирования нет, попробовать открыть редактор по прямой ссылке).
Если у вас есть какие-то явные ограничения вида:
Эту кнопку показывать только менеджеру VIP-клиентов
То важно проверить не только менеджера VIP-клиентов, но и все остальные роли — что они такую кнопку не видят.
API — программный интерфейс
Всё то же самое, что и в GUI, просто тут мы вызываем методы, а не нажимаем на кнопки в интерфейсе.
Если проверяем метод, то под пользователем, у которого:
есть права на вызов;
нет прав.
Если проверяем саму ролевую модель, то берем роль и вызываем каждый метод по 1-2 раза — чтобы доступ был / не было. Возьмем для примера систему Cards, согласно ТЗ на ролевую модель — «пользователь, указанный через user-id (имитирует вход через LDAP в реальной жизни) в методе getUser видит только себя)». Чтобы это проверить, отправляем 2 запроса:
getUser по себе;
getUser по другому пользователю.
Иногда бывает, что ограничение накладывается частично — например, оператор может отредактировать информацию по клиенту типа VIP-статуса, но не может отредактировать ФИО и другие паспортные данные. Как такое проверить? Верно, отправляем запрос на редактирование, в котором:
доступное для редактирования поле;
недоступное;
в одном запросе сразу и доступное (VIP), и недоступное (ФИО) поле — как система поведет себя в таком случае? Не исправит ли вип-флаг, выдав ошибку на ФИО?
А ещё может быть ограничение на просмотр конкретных полей. Особенно это актуально для GraphQL API, где набор полей в ответе указывается клиентом. Запрашиваем в ответе:
поля, на которые есть доступ (например, имя пользователя для user_viewer в Cards, метод getUser)
поля, к которым нет доступа (данные по карте в том же примере);
и то, и другое.
Сочетание ролей
Тестируя роли, нужно проверять их:
отдельно;
вместе (сочетания).
Потому что бывает так, что настраивается ряд «мелких» ролей:
работа с админкой
работа со вводом данных
работа с отчетами
...
А потом делают группы пользователей, собирая права доступа из этих мелких ролей. Как бы раздавая браслеты, разрешающие заходить в ту или иную зону аквапарка.
Поэтому проверяем, что будет, когда у пользователя:
одна роль — как работают роли по отдельности? Проверяем каждую;
две и более разные, не затрагивающие друг друга роли (неконфликтующие);
две и более конфликтующие (оператор, который только видит + оператор, умеющий редактировать — роли могут накладываться с ошибкой «настройте всё правильно», а могут просто игнорировать ту, которая дает меньше прав);
ноль ролей — зайти под гостем или пользователем, которого ещё не добавили ни в одну из групп.
Итого
При тестировании ролевой модели нужно для каждой роли проверить все действия и / или методы API. Смотрим, что обе ситуации обрабатываются правильно:
есть доступ;
нет доступа.
Отказ в доступе в GUI можно попробовать обойти (например, кнопки в интерфейсе нет, а мы идем по прямой ссылке). А отказ доступа в API нужно исследовать подробнее:
нет прав на весь метод;
нет прав на методы при определенном условии (вызываем не свои данные);
нет прав на возвращаемые поля (особенно актуально для GraphQL API).
Сами роли проверяем по отдельности и вместе — как они взаимодействуют друг с другом? Правильно ли конфликтуют, если это требуется? А что, если у пользователя ещё нет ни одной роли?
PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале