Функциональное тестирование авторизации в Rails

Question

Я знаю , как для запуска функциональных / интеграционных тестов в Rails, этот вопрос касается лучших практик. Допустим, авторизация выполняется с использованием четырех разных пользовательских ролей:

• основной
• редактор
• админ
• супер

Это означает, что для каждого действия возможно до пяти различных вариантов поведения (4 роли + неаутентифицированный / анонимный). Один из подходов, который я выбрал, заключается в проверке каждой роли в каждом действии, например:

• test_edit_by_anonymous_user
• test_edit_by_basic_user
• test_edit_by_editor_user
• test_edit_by_admin_user
• test_edit_by_super_user

Но это, очевидно, приводит к лоту тестов (каждое действие контроллера на сайте действительно должно быть протестировано пять раз). Противоположный подход состоял бы в том, чтобы проверить механизм авторизации изолированно, а затем выполнить проверку подлинности как супер, прежде чем тестировать каждое действие (при настройке), и тестировать только одну версию каждой страницы.

Я пробовал несколько подходов с различной степенью специфичности, но не был полностью удовлетворен чем-либо. Я чувствую себя более комфортно, когда тестирую больше случаев, но объем тестового кода и сложность абстракции были отключены. У кого-нибудь есть подход к этой проблеме, которым он доволен?

Answer 1

Это действительно зависит от того, как вы настроили свой код для проверки авторизации и как вы проверяете его в действиях. Я могу рассказать вам, что мы делаем в качестве примера. У нас есть роли, как у вас, и некоторые страницы, требующие входа в систему, некоторые, требующие роли, а некоторые с разным выводом в зависимости от роли. Мы тестируем каждый тип немного по-разному.

Сначала мы тестируем авторизацию и авторизируемся отдельно.

Кроме того, мы создали фильтры для действий, требующих входа пользователя в систему, а затем других для выполнения определенной роли. Например, check_admin, check_account_owner и т. Д. Затем мы можем проверить, работают ли эти фильтры самостоятельно.

Затем мы добавляем проверки в тестах контроллера, чтобы вызывались правильные фильтры. Мы использовали musta и написали несколько простых расширений, чтобы мы могли добавлять проверки вроде:

should_filter_before_with :check_admin, :new

Таким образом, мы тестируем то, что должно быть проверено, и не более.

Теперь, для более сложных действий, которые выполняют различную логику в зависимости от роли, мы проверяем эти действия для каждой роли, которая содержит специальную логику. Мы не пишем тесты для ролей в этом действии, которые будут отфильтрованы или являются надмножествами других ролей. Например, если действие добавляет дополнительные поля в форму, если вы являетесь администратором, мы тестируем не-администраторов и администраторов. Мы не тестируем администраторов и супер-администраторов, поскольку наш код для проверки ролей понимает, что супер-администраторы - это администраторы.

Кроме того, для шаблонов, которые содержат логику для отображения определенных элементов только для определенных ролей, мы пытаемся переместить этот код в помощники или, если они распространены, например, панель инструментов администратора, в партиалы. Тогда мы сможем проверить их самостоятельно, а не на каждом действии, которое включает их.

Подводя итог, проверьте только то, что вам нужно для данного действия. Точно так же, как вы не будете тестировать внутренние компоненты Rails в своих модульных тестах, если вы пишете общий код для проверки ролей и проверяете его, вам не нужно проверять его снова при каждом действии.

Answer 2

В некоторых ситуациях вам может потребоваться проверить ВСЕ возможные роли и уровни авторизации в отношении различных действий - например, при работе в банке :) В этом случае имеет смысл использовать более динамичный подход к тестированию. Вместо определения каждого контрольного примера вы должны сгенерировать все комбинации.

Несколько лет назад Райан Дэвис выступил с докладом о «матрице функциональных тестов», которая является частью ZenTest. Dr. Nic сделал рецензию, , и в конце поста вы найдете обновленные ссылки в комментариях. Это решение было разработано именно для той проблемы, которую вы описываете. Вы также можете развернуть свое собственное решение, например, запустив тесты во вложенных циклах - идея в основном та же самая.

Answer 3

Рассмотрим приложение, которое имеет 2 роли администратора и только для чтения. Выполните следующие тесты:

1. Войдите в систему только для чтения, выполните некоторые действия и выйдите из системы. Теперь из той же системы и того же браузера войдите в систему с ролью администратора и посмотрите поведение системы. И наоборот.
2. Войдите в систему с ролью администратора, скопируйте значение cookie и выйдите из системы. Теперь войдите в систему с обычной ролью и отредактируйте значение cookie, используя cookimanager + или editthiscookie tool. И если приложение работает, как ожидалось, то это проблема. Повторите приведенный выше тестовый пример 2 с той же машины, того же браузера, с той же машины с другим браузером, с другой машины
3. если это толстое клиентское приложение, выполните обратный инжиниринг и проанализируйте код. Попробуйте изменить логику управления авторизацией (для этого кому-то нужен опыт кодирования) перекомпилируйте код и повторите тест 2-3.
4. с использованием инструмента прерывания прокси-сервера, такого как Burp Suite, для анализа запросов get / post для обеих ролей.

Теперь в зависимости от типа роли, доступной для вашего приложения, решите тестовые случаи.