Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Как писать автотесты для разных проектов в рамках одного продукта?


#1

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

Раньше я писал тесты только для “коробочного” продукта. Я бы хотел узнать у участников форума - сталкивались ли вы с подобным и как решали подобные задачи? Может решением будет использование какого-либо конкретного тестового фреймворка?


(rmerkushin) #2

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


#3

Приведу конкретный пример - на форме может быть разное количество табов, разное количество полей для заполнения. Я свои тесты обычно пишу линейно: найти конкретный таб, поле и заполнить. Но в данном случае предлагается написать “умный” тест, который будет находить все табы, переходить по ним и заполнять все поля. Хотя наверняка там будут в последствии выявляться скрытые проблемы.
Я посмотрел описание Robot Framework и понял так: для каждого ключевого слова пишется низкоуровевый код, и далее складывается кирпичиками под каждый сценарий?


(Sergey Korol) #4

Если функционал может отличаться, то о каких универсальных тестах речь? Будете лепить миллион проверок if present в каждый тест? Ваш пифоменс упадет в итоге до нуля, ровно как и профит от автомейшена.Тесты в любом случае будут отличаться в плане степов. Да и какой смысл миксовать тесты / пейджи различных подпродуктов в одну кучу? Особенно если над ними потенциально могут работать разные люди.

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


#5

Да, я тоже придерживаюсь этого мнения, что универсальный тест сложен в разработке и поддержке. Да и неправильно это как-то.
А поводу разбиения на подклассы - как раз об этом и думал. В данном случае смотрю в сторону Html Elements.


(Антон) #6

Чтобы не плодить if-else итд можно вынести специфические пейджи в отдельные *.jar файлы и в мавене подключать нужные через профили мавена.
В итоге у тебя во фреймворке будут только хелперы, модельки, какие-то классы-родители, фабрики, может глобальные степы… ну и эти самые универсальные тесты :smile: а вся специфика будет в *.jar файлах…
Не уверен в удобстве :wink: но как вариант пойдет :smile:


(rmerkushin) #7

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


(Oleksandr Khotemskyi) #8

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

Универсальные тесты - не думаю что это хорошо, не совсем понятно что тогда проверяется в них если элементы могут быть, могут нет, а тест ведь пройдет в любом случае.

Или проблема в том что сложно найти элемент на странице из-за меняющейся верстки страницы?


(Александр Таранков) #9

А разработка как ведется? Тоже всё “if-фами” хреначат? А релиз-циклы у проектов наверняка разные? Изменения вносятся в разное время и тесты надо будет стабилизировать и менять в разное время, разными людьми. Если это всё будет в одной куче, все будут друг другу только мешать: одни хотят стабильный код тестов, другие - постоянно их менять, покрывая очередную порцию функционала. Через ветвление решать наверное можно, но с мержем замучаетесь, а главное - для чего?

Под каждый проект должен быть свой набор тестов, которые проверяют логику этого проекта. Если есть переиспользуемый функционал, под него можно написать и общие тесты, разбить это всё по проектам/подпроектам maven-а в соответствии с тем как разбит функционал самого тестируемого продукта, сделать зависимости между модулями и сборку проектов по отдельности, включая зависимости от общего функционала.

В общем разбиение на общие и частные модули надо “подсмотреть” в структуре пакетов самого продукта/проектов