Тестирование прав пользователей: для чего используется и какие бывают права доступа

Тестирование прав доступа в контроле безопасности программного продукта играет особую роль. Оно призвано проверить, какие действия, имеющий определённый статус пользователь, может выполнить в рамках своей роли (например, оставить комментарий, заказать товар), а какие не может (допустим, заблокировать другого пользователя, изменить или удалить его комментарии). Также следует посмотреть, как ведёт себя веб-ресурс, если пользователь попытается выполнить операцию, недопустимую для его статуса.

Тестирование прав пользователей

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

Роли

На нашем сайте их три:

  • Пользователь без регистрации. Это аноним. Он имеет право только на просмотр страниц. Он не имеет прав добавлять свои комментарии, голосовать, скачивать книги себе на ПК;
  • Пользователь прошедший регистрацию. Он имеет определённый ник, может добавлять и исправлять данные о себе, наделён правом покупки билета, добавления комментариев и загрузки к себе на комп приглянувшейся ему книги;
  • Администратор. У него полный доступ к сайту. Он имеет право блокировать пользователей, цензурировать и удалять их комментарии.

Роли пользователей

Как проходит тестирование прав пользователей

В первую очередь подстрахуемся, чтобы играясь с настройками, случайно не удалить пользователя с правами «Супер-админа». Для этого создаём ещё одного пользователя по возможностям сравнимым с возможностями администратора. Далее последовательность действий следующая:

  1. Меняем в различных браузерах права доступа пользователей. Этим мы разделяем пользовательские сессии;
  2. Проверяем ограничения пользователей относящихся к разным ролям. В частности, пытаемся добавить комментарий в статусе незарегистрированного пользователя. Затем то же самое делаем в статусе зарегистрированного. Так проходим по всем функциям, присущим той или иной роли;
  3. Тестируем, как блокируются сущности. При продаже билетов крайне важно, чтобы доступ к элементу не получили одновременно несколько пользователей. Имеются два способа блокировки. Оптимистичная при сохранении проверяет блокировку доступа на предмет более новой версии данных, которую оставил другой пользователь. Если она имеется, то другой пользователь может снова загрузить этот экземпляр сущности. Пессимистичная блокировка требуется, когда с пессимистичной возникает слишком много проблем. При ней только один пользователь в определённый момент времени может использовать и изменить данный вариант сущности;
  4. Создаём тестовую матрицу. На ней сразу видно, какие действия разрешены различным ролям, а какие запрещены. Это поможет ничего не упустить и значительно ускорит нашу работу.

Пример матрицы доступа