Чит-лист — это шпаргалка по выбранной теме, что не забыть проверить. Берете чит-лист как основу, адаптируете под свой проект, и готово!

В своей книге про тест-дизайн я написала ряд чит-листов, которыми и хочу теперь поделиться. Сегодня поговорим про ролевую модель в GUI и API — это когда у нас есть разграничение прав для отдельных пользователей / целых групп (им назначается роль).

Набор ролей может быть очень обширным — права только на просмотр, на редактирование, на редактирование конкретной сущности или даже одного поля в этой сущности, просмотр конкретной страницы (отчетность или аудит), создание связи…

Но если брать в целом, обычно у нас есть:

  • простые пользователи — у каждой группы свой набор прав;

  • админ — всесильный пользователь;

  • гость — неавторизованный пользователь (это, по сути, проверка на ноль).

Давайте разберемся, как будем их проверять:

  1. GUI — графический интерфейс пользователя

  2. API — программный интерфейс

  3. Сочетание ролей

  4. Итого

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-канале   

Комментарии (2)