t.me/atinfo_chat Telegram группа по автоматизации тестирования

Как и с помощью каких интсрументов автоматизировать. Если нужно часто менять профили для авторизации и проверять их взаимодействие

design-patterns
management
framework
автоматизация
user
pattern
Теги: #<Tag:0x00007f21d45157f0> #<Tag:0x00007f21d45153b8> #<Tag:0x00007f21d4515020> #<Tag:0x00007f21d4514ad0> #<Tag:0x00007f21d4514710> #<Tag:0x00007f21d45143c8>

(Евгений ) #1

Есть проект. В проекте есть множество ролей и профилей, под которыми приходится работать и проверять, как они работают между собой. Для того чтобы работать под каждым профилем, под ним необходимо войти в систему. Часто требуется, чтобы например несколько профилей были авторизованы одновременно, чтобы проверить их взаимодействие. Приведу один реальный кейс.

Есть профиль “А”
Есть профиль “B”

Все деалется через UI интерфейс. Сначала, нужно зайти в систему под профилем “А”. Создать материал, отправить его на модерацию, и оставаясь в системе, авторизоваться в инкогнито вкладке профилем “B” и одобрить(модерировать) этот материал. При этом у обоих профилей нужно проверить еще и всплывающее сообщение о том, что материал был отправлен на модерацию и одобрен.

И подобных кейсов очень много, проверяется доступность профилей к разным материалам, разные профили имеют разные права доступа и так далее.

Вопрос:
Как и с помощью чего я могу подумать над автоматизацией подобных сценариев?
Я пробовал писать скрипты на java script в хромовской консоли разработчика и использовать postman. Где пытался автоматизировать некоторые кейсы влоб через API. Но этот способ не покрывает большей части интерфейсных проверок. Пробовал писать UI тесты. Где все само логинится и разлогинивается. Но эти тесты получаются супер обьемные и супер нестабильные. И в добавок ко всему этому, еще и невозможно одновременно держать несколько отрытых вкладок. Короче говоря, ситуация кажется мне безвыходной. Потому что система получается слишком заковыристой и врпинципе неавтоматизируемой.
Поделитесь кто как и с помощью чего решал подобные задачи?


(Vladislav Sobol) #2

И в добавок ко всему этому, еще и невозможно одновременно держать несколько отрытых вкладок.

Вариант 1.

Можно поднять дравер_А для профиль “А” -> Cделать там логИн и все что нужно -> Поднять дравер_Б для профиль “Б” ( не закрывая драйвер_А ) -> сделать в профиле “Б” все что нужно.
В дравере_А - проверить всплывающее окно для А ( или что вы там проверяете)
В дравере_Б - осуществить проверку для Б

Инструменты:
Селениум на удобном вам языке

Вариант 2.
Можно поднять дравер_А для профиль “А” -> Cделать там логИн и все что нужно
Затем с помощью АПИ колов залогиниться профилем “B” и заапруивть или замодерировать материал.
В дравере_А - проверить всплывающее окно для А ( или что вы там проверяете)

Повторить тест для профиль “B” ( только теперь поднимать драйвер для “B” , а все действия для профиль “А” делать колами в АПИ)

Инструменты:
Селениум на удобном вам языке
Что-то для работы с АПИ колами ( мы юзаем restAssured на Джаве)


(Евгений ) #3

Спасибо за ответ! А правда что google теперь не поддерживает selenium web driver? Я слышал что он перестал это делать, сказав что теперь есть puppeteer - юзайте его, он круче. И второй вопрос, не понимаю почему selenium так популярен, один мой знакомый java-разработчик говорит, что на selenium писать - это боль и страдания. И я боюсь, что рано или поздно я все равно приду к выводу, что кроме selenium нет никаких адекватных альтернатив


(Vladislav Sobol) #4

А правда что google теперь не поддерживает selenium web driver?

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

Так вы бы у него спросили что он может посоветовать в качестве альтернативы :grinning: , если селениум это прям боль.


(Vatslau) #5

поднапрягитесь и сделайте изменения через базу/апи
а на UI только проверки результата
иначе это будет боль)


(Евгений ) #6

Я вообще не представляю как это делается). Но спасибо за идею. Может найду какую-то информацию, по этому вопросу


(Olga) #7

Вы мыслите как мануальный тестировщик, какие анонимные окна? в жизни никто так не работает. Чтобы увидеть материал на одобрение, вам надо лишь создать его под другим юзером, я бы это делала через апи, если возможно. Данные авторизации держать в HashMap, авторизация тоже через апи.
Т.е. все прекондишны максимально через апи, одобрять тоже через апи, на UI смотреть только размещение и работу контролов, проверка тоже через апи.
Мой стек это Java и Selenium для UI. Но это только потому что я с ним работаю, вы можете выбрать другой язык и Selenide для UI, например.
Все тесты должны быть максимально атомарны и независимы.


(Евгений ) #8

Хорошее замечание. Кстати я слышал что selenide получше silenium будет. Потому что вроде бы UI автоматизация более проще, и другие плюшки. Что вы думаете по этому поводу?Ну и в целом спасибо за ваши советы!


(Евгений ) #9

И кстати. Автоматизированное UI тестирование направленно на максимальную имитацию действий пользователя. Как быть с тем, что пользователи не используют отдельное API для модерации например. Они все делают через интерфейс. В таком случае получается что UI автотесты c использованием API не проверяют часть того же интефейса. А на фронте много багов может возникать из-за того, что сломалась какая-то внутренняя логика. Потому что теже кнопки пользовательского интерфейса не всегда завязаны на какое-то API. Что делать в таком случае?


(Viktor) #10

Тесты должны быть атомарные, каждый тест должен проверять отдельный функционал.
Например вам нужно написать тесты на создание айтемов,
Test 1 - Создать айтем 1
Test 2 - Создать айтем 2
Но айтем 2 содержит айтем 1, поэтому вы создаете айтем 1 через апи чтобы не делать тесты зависимыми и чтобы каждый тест проверял свой функционал. Получается вы создадите два айтема 1, один как конкретный UI тест, второй как прекондишн через апи


(Евгений ) #11

Многие TA именно так и делают/советуют делать. И я не отрицаю что так правильно и круто.Но у меня возникают следующие вопросы, в которых я хочу разобраться. Потому что если я кому-нибудь, скажу что так вот правильно автоматизировать, без весомых аргументов. Мои слова в пух и прах разнесут какими-нибудь другими аргументами. Я хочу понять и именно обьяснить почему так правильно.
Соответственно вопросы:

  1. Почему так правильно? (кроме того что быстрее и проще и т.д) - это я примерно представляю
  2. Есть ли какие-то альтернативные варианты, если создать предусловия через API - невозможно например
  3. На мой взгляд получается та же самая зависимость. Только теперь, чтобы создать айтем2 мы используем не UI тест а API тест. Получается что мы зависим от того, чтобы API тестом был создан айтем1

(Vladislav Sobol) #12

API методы более надежные и в разы быстрее UI методов. Если UI метод может не сработать по ряду причин (поменялись локаторы, плохо настроены ожидания, вылезло чтото непонятное на странице, попап или пермишн какойто) то Apі таким не страдает и если какойто API call не проходит(хотя до этого проходил) то это 99% баг приложения, а не плохо написаный метод.
Есть альтернатива манипулировать базой данных напрямую, делать инсерты, но это сложнее чем сделать один колл в АПИ.
Если у вас тест в котором нужно сначала сделать много прекондишенов в которых вы тоже кучу всего проверяете, то имеет смысл разбить это дело на несколько тестов и иметь 2-3 надежных теста чем один мега тест который может обломиться в 10 местах.


(Valentin G ) #13

Альтернативный вариант - вставить данные напрямую в базу данных. Сделать несколько файлов с данными, для каждого из тестов, вставлять их перед каждым тестом (следовательно удаляя другие тестовые данные перед этим).


(Olga) #14

Точнее удалять данные после прохождения теста.


(Olga) #15

В селениде просто уже реализованы те удобные вещи, которые вы бы реализовывали в своем фреймворке, типа логирования, таймаутов и т.п. Я с ним не работала, только презентахи смотрела, но ничего против не имею :slight_smile: порог вхождения ниже ,чем в просто Селениум.

Смотрите, если вам надо проверить, работает ли кнопка, вы проверяете ее на UI, например, что выскочил попап. Если кнопка делает изменения в базе, то вы базу проверяете через sql запрос, или через api. Если кнопка делает и то и то, то это 2 разных теста. Элементы UI проверяются через UI, бизнес-логику я бы проверяла на апи, а на UI только то, что должно отображатся на UI, работу кнопок, данные, которые пришли с апи правильно отображаются.


(Olga) #16

Пользователи делают через интерфейс, но все что сделано сохраняется где-то в базе, в противном случае оно все исчезает после окончания сессии браузера.


(Михаил Братухин) #17

Уже есть и довольно давно очень полезный доклад от Николая Алименкова с Selenium Camp про данную вещь, рекомендую к ознакомлению:
Bro, manage test data like a pro! (Mikalai Alimenkou, Ukraine) [RU]

Ну и про информацию вот из этой статьи не забываем:
Синтетические vs реальные тестовые данные: плюсы, минусы, подводные камни

Надеюсь, будет полезно. Насчет использования как “аргумента”, то сильно сомневаюсь, что кому-то захочется во все эти детали погружаться.


(Евгений ) #18

Еще как будет[quote=“Mihail_Bratuhin, post:17, topic:22857”]
Надеюсь, будет полезно
[/quote]

Еще как будет. Для меня сейчас важна любая информация


(Евгений ) #19

Всем огромное спасибо за примеры советы и помощь!