Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Тестирование прав разных ролей юзеров. Разделение тестов на уровнях UI и API.

gui
api
Теги: #<Tag:0x00007fedb8411010> #<Tag:0x00007fedb8410e58>

(Dinara Demi) #1

У меня возникла следующая проблема на проекте.
У нас на проекте около 7 разных ролей с разными правами, в добавок у каждой из ролей могут меняться права в зависимости от добавленной ему роли, в общем получается около 40 разных кейсов, которые нужно проверить автотестами.
Мануальный тестер хочет, чтобы все тесты писались только на уровне UI (а это и долго, и тесты уже длятся больше 20 часов и т.д.), потому что так всегда было до меня на этом проекте.
А согласно пирамиде тестирования здравому смыслу, часть новых тестов я хочу писать (а существующие переписать) на уровне API.
Но есть одна загвоздка, я в этом новичок, поэтому мне нужно понимать, что можно писать на уровне апи, а что обязательно нужно проверять на UI (то есть как разделить между ними проверки грамотно), к тому же мне потом это нужно будет объяснить тестеру и команде.
Возьмем конкретный пример: мне нужно написать тесты, покрывающие проверку прав разных ролей написания, редактирования, удаления коммента и права видеть чужие комменты. При этом это нужно проверить в 40 разных случаях( так как права юзера могут поменяться, если у него появляется добавочная роль), на 3 разных страницах.
Проверка прав происходит на бэкэнде, но конечно же нужно проверить и на фронте, что кнопки видимы, кликабельны и т.д.
Правильно ли я рассжудаю. Пишу один E2E тест на UI: я могу зайти под админом (так как у него всемогущая роль и можно будет разом всё проверить), сделать всевозможные манипуляции с комментами.
Затем все остальные поверки для других ролей и их комбинаций сделать через API.
Пожалуйста, помогите разобраться, а то уже голова кругом идет, а посоветоваться не с кем))


(Дмитрий Еремин) #2

Так

  1. Идея, что все протестить на уроне API будет удобнее и быстрее - правильная
  2. Понимание того, что UI все равно тестить придется - тоже норм

Я не видел системы, но предположу:
Просто сообщать на UI, в какой роли залогинен пользователь - нелогично. 7 ролей, надо писать кучу логики, что если такая роль, показывай это, если другая - то.
Существует подход, когда анонимный юзер логинится на сайте (запрос уходит к API) и получает, в ответ, помимо user-info еще перечень прав: что можно делать. Так удобнее разрабатывать UI и всегда можно добавлять/удалять/менять роли, не переживая за UI

Если я прав, то нужно изолировать компоненты и тестить:

  1. Тесты на API, где мы проверяем, что в ответе правильный перечень прав для роли
  2. Тесты на API, где пытаемся совершить действия, которые нельзя. Например, гость пытается поменять информацию о товаре (не знаю, о чем ваша система). Тут даже не важно, есть ли такой товар и валидны ли значения - вам должен вернуться статус 403. Значит проверка прав происходит до выполнения операций (да и вообще, проверка есть)
  3. Тесты на API, где пытаемся совершить действия, которые можно.
  4. Дальше, идеальная ситуация состоит в том, что вы берете ваш UI фреймворк (что там у вас? Angular, React, Vue?) и смотрите, какими инструментами они тестируются (у ангуляра есть свой модуль для тестирования, у реакта - Jest и т.д.)
  5. Мокаете сервер, мол, если юзер логинится так, верни перечень прав админа, если вот так - перечень прав юзера
  6. И пишете тесты, проверяющие, что вам правильно отображаются нужные UI-компоненты
  7. Ну и сколько-нибудь selenium-тестов сверху присыпьте, чтобы убедиться, что все это работает вместе хорошо. К тому же, позитивные сценарии (где пользователи джелают то, что им можно у вас реализованы в других тестах)