Есть проект. В проекте есть множество ролей и профилей, под которыми приходится работать и проверять, как они работают между собой. Для того чтобы работать под каждым профилем, под ним необходимо войти в систему. Часто требуется, чтобы например несколько профилей были авторизованы одновременно, чтобы проверить их взаимодействие. Приведу один реальный кейс.
Есть профиль “А”
Есть профиль “B”
Все деалется через UI интерфейс. Сначала, нужно зайти в систему под профилем “А”. Создать материал, отправить его на модерацию, и оставаясь в системе, авторизоваться в инкогнито вкладке профилем “B” и одобрить(модерировать) этот материал. При этом у обоих профилей нужно проверить еще и всплывающее сообщение о том, что материал был отправлен на модерацию и одобрен.
И подобных кейсов очень много, проверяется доступность профилей к разным материалам, разные профили имеют разные права доступа и так далее.
Вопрос:
Как и с помощью чего я могу подумать над автоматизацией подобных сценариев?
Я пробовал писать скрипты на java script в хромовской консоли разработчика и использовать postman. Где пытался автоматизировать некоторые кейсы влоб через API. Но этот способ не покрывает большей части интерфейсных проверок. Пробовал писать UI тесты. Где все само логинится и разлогинивается. Но эти тесты получаются супер обьемные и супер нестабильные. И в добавок ко всему этому, еще и невозможно одновременно держать несколько отрытых вкладок. Короче говоря, ситуация кажется мне безвыходной. Потому что система получается слишком заковыристой и врпинципе неавтоматизируемой.
Поделитесь кто как и с помощью чего решал подобные задачи?
И в добавок ко всему этому, еще и невозможно одновременно держать несколько отрытых вкладок.
Вариант 1.
Можно поднять дравер_А для профиль “А” -> Cделать там логИн и все что нужно -> Поднять дравер_Б для профиль “Б” ( не закрывая драйвер_А ) -> сделать в профиле “Б” все что нужно.
В дравере_А - проверить всплывающее окно для А ( или что вы там проверяете)
В дравере_Б - осуществить проверку для Б
Инструменты:
Селениум на удобном вам языке
Вариант 2.
Можно поднять дравер_А для профиль “А” -> Cделать там логИн и все что нужно
Затем с помощью АПИ колов залогиниться профилем “B” и заапруивть или замодерировать материал.
В дравере_А - проверить всплывающее окно для А ( или что вы там проверяете)
Повторить тест для профиль “B” ( только теперь поднимать драйвер для “B” , а все действия для профиль “А” делать колами в АПИ)
Инструменты:
Селениум на удобном вам языке
Что-то для работы с АПИ колами ( мы юзаем restAssured на Джаве)
Спасибо за ответ! А правда что google теперь не поддерживает selenium web driver? Я слышал что он перестал это делать, сказав что теперь есть puppeteer - юзайте его, он круче. И второй вопрос, не понимаю почему selenium так популярен, один мой знакомый java-разработчик говорит, что на selenium писать - это боль и страдания. И я боюсь, что рано или поздно я все равно приду к выводу, что кроме selenium нет никаких адекватных альтернатив
Вы мыслите как мануальный тестировщик, какие анонимные окна? в жизни никто так не работает. Чтобы увидеть материал на одобрение, вам надо лишь создать его под другим юзером, я бы это делала через апи, если возможно. Данные авторизации держать в HashMap, авторизация тоже через апи.
Т.е. все прекондишны максимально через апи, одобрять тоже через апи, на UI смотреть только размещение и работу контролов, проверка тоже через апи.
Мой стек это Java и Selenium для UI. Но это только потому что я с ним работаю, вы можете выбрать другой язык и Selenide для UI, например.
Все тесты должны быть максимально атомарны и независимы.
Хорошее замечание. Кстати я слышал что selenide получше silenium будет. Потому что вроде бы UI автоматизация более проще, и другие плюшки. Что вы думаете по этому поводу?Ну и в целом спасибо за ваши советы!
И кстати. Автоматизированное UI тестирование направленно на максимальную имитацию действий пользователя. Как быть с тем, что пользователи не используют отдельное API для модерации например. Они все делают через интерфейс. В таком случае получается что UI автотесты c использованием API не проверяют часть того же интефейса. А на фронте много багов может возникать из-за того, что сломалась какая-то внутренняя логика. Потому что теже кнопки пользовательского интерфейса не всегда завязаны на какое-то API. Что делать в таком случае?
Тесты должны быть атомарные, каждый тест должен проверять отдельный функционал.
Например вам нужно написать тесты на создание айтемов,
Test 1 - Создать айтем 1
Test 2 - Создать айтем 2
Но айтем 2 содержит айтем 1, поэтому вы создаете айтем 1 через апи чтобы не делать тесты зависимыми и чтобы каждый тест проверял свой функционал. Получается вы создадите два айтема 1, один как конкретный UI тест, второй как прекондишн через апи
Многие TA именно так и делают/советуют делать. И я не отрицаю что так правильно и круто.Но у меня возникают следующие вопросы, в которых я хочу разобраться. Потому что если я кому-нибудь, скажу что так вот правильно автоматизировать, без весомых аргументов. Мои слова в пух и прах разнесут какими-нибудь другими аргументами. Я хочу понять и именно обьяснить почему так правильно.
Соответственно вопросы:
Почему так правильно? (кроме того что быстрее и проще и т.д) - это я примерно представляю
Есть ли какие-то альтернативные варианты, если создать предусловия через API - невозможно например
На мой взгляд получается та же самая зависимость. Только теперь, чтобы создать айтем2 мы используем не UI тест а API тест. Получается что мы зависим от того, чтобы API тестом был создан айтем1
API методы более надежные и в разы быстрее UI методов. Если UI метод может не сработать по ряду причин (поменялись локаторы, плохо настроены ожидания, вылезло чтото непонятное на странице, попап или пермишн какойто) то Apі таким не страдает и если какойто API call не проходит(хотя до этого проходил) то это 99% баг приложения, а не плохо написаный метод.
Есть альтернатива манипулировать базой данных напрямую, делать инсерты, но это сложнее чем сделать один колл в АПИ.
Если у вас тест в котором нужно сначала сделать много прекондишенов в которых вы тоже кучу всего проверяете, то имеет смысл разбить это дело на несколько тестов и иметь 2-3 надежных теста чем один мега тест который может обломиться в 10 местах.
Альтернативный вариант - вставить данные напрямую в базу данных. Сделать несколько файлов с данными, для каждого из тестов, вставлять их перед каждым тестом (следовательно удаляя другие тестовые данные перед этим).
В селениде просто уже реализованы те удобные вещи, которые вы бы реализовывали в своем фреймворке, типа логирования, таймаутов и т.п. Я с ним не работала, только презентахи смотрела, но ничего против не имею порог вхождения ниже ,чем в просто Селениум.
Смотрите, если вам надо проверить, работает ли кнопка, вы проверяете ее на UI, например, что выскочил попап. Если кнопка делает изменения в базе, то вы базу проверяете через sql запрос, или через api. Если кнопка делает и то и то, то это 2 разных теста. Элементы UI проверяются через UI, бизнес-логику я бы проверяла на апи, а на UI только то, что должно отображатся на UI, работу кнопок, данные, которые пришли с апи правильно отображаются.
Пользователи делают через интерфейс, но все что сделано сохраняется где-то в базе, в противном случае оно все исчезает после окончания сессии браузера.
testomat.io управление авто тестами
, если селениум это прям боль.
порог вхождения ниже ,чем в просто Селениум.