Home

Автор: Ольга Назина (Киселева)

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

В своей книге про тест-дизайн я написала ряд чит-листов, которыми и хочу теперь поделиться. Сегодня поговорим про ролевую модель в 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-канале   

Обсудить в форуме