testomat.io управление авто тестамиЗдравствуйте.
На проекте появилась возможность завести автоматизацию “с нуля”. Хотелось бы все сделать по уму.
Язык и инструменты выбраны. И самый актуальный вопрос: как организовать покрытие тестами, по сценариям или по страницам.
Т.е. берем отдельную страницу и покрываем тестами функционал на ней.
Или пишем тесты по юзер сторям/сценариям? в данном случае в тестах возможны переходы по страницам приложения.
Поделитесь опытом, как у вас? Какие приимущества/недостатки.
У нас кукумбер. Там можно каждому тесту назначать свой тег.
Вы можете каждому тесту ставить тег страницы и тег фичи. Потом гонять тесты, как вам нужно.
Насколько понимаю, фишка с тегами не является чисто кукумберовской.
А какой тестовый фреймворк?
Pytest.
С тэгами понятно. Но если говорить в общем. Вы организуете по страницам или фичам? Или скажем так, с чего лучше начать: с основных страниц или основных сценариев?
Щас вот простите, потому что ответ - не ответ. Но основные страницы и содержат основные фичи.
А вообще, пожалуй, больше по фичам.
Есть фича. Пишем под нее тест. Пока писали тест, описали часть страницы. Раз описана страница, можно и соседние тесты написать, если недолго (акцент все же на фичи)
2 лайка
Способ без “У нас кукумбер” ))
У нас все намного проще, есть ручные регресс тесты в каком то трекере где у каждого теста перед названием ID этого test-case (“A23: Users - Add new user”)
Когда этот тест поступает на автоматизацию то нам достаточно просто назвать так же тестовый метод (“A23UsersAddNewUser”) ну и собственно в этом еще кроется ответ на вопрос “фича или страница” т.к ручные тесты у нас проверяют функционал какой то фичи для какого то модуля системы, но не стоит забывать что эта фича может использовать 3, 5 и 10 страниц.
На выходе в том же TeamCity все понятно, какой функционал упал и ручной QA заходя TeamCity по названию тестового метода находит такой же тест в трекере и прогоняет его в ручную да бы убедится что дефект не на стороне проекта.
После прогона этого теста ручным QA он заводит репорт, если баг был в проекте то на разработчика, если в тестовой системе то на автоматизатора.
Но опять это все зависит от проекта, где то заставляют все логировать и скринить каждый упавший тест потому что ТАК ХОЧЕТ ЗАКАЗЧИК, где то еще какие то факторы и т.д.
1 лайк
Есть пирамида тестирования, судя из которой UI тесты находятся практически на самом верху(я думаю вы как раз таки и о них говорите). У нас на проэкте UI тесты пишутся в виде User Flow.
Т. е - есть User Story - берём и покрываем не тестами. Если эта User Story связана на ещё такие же Story , которые уже покрыты, то нужно обновить тесты.
Основная идея - это сделать так, чтобы UI тесты покрывали только User Flow и один и тот же функционал не проверялся несколько раз разными тестами.
1 лайк
Тоже Python3, тоже PyTest. В кратце поведаю как делается у нас. Вообще планирование тестов - это самая важная составляющая написания автотестов (имхо). Почему? Потому что рано или поздно они будут идти очень долго и их надо будет параллелить. И вот вы первый месяц показываете команде как вы работете, пушите тесты в огромном количестве, а потом оказывается что 3 из 5 проверяют один и тот же функционал. В интернете вы могли натыкаться на такое типа-правило: один тест - один ассерт. Чуть, муть и компот. Иначе если следовать этому правилу - вы будете ждать сутки прохождения своих тестов.
Теперь по вашему вопросу: сначала все делится на фичи, на фичу пишется e2e тест - то что делает пользователь, доходя до конца фичи с минимальным взаимодействием со странцей (проверка базового функционала), далее идут различные функциональные тесты, которые говорят что элементы на странице работают правильно (алёрты и тд). Далее идут частные случаи (заглушки и тд). И если вы дошли до частных случаев и впринципе описан весь функционал фичи - вы все сделали правильно.
3 лайка
Я так понимаю, что человека интересует удобная организация тестов на проекте. Но у меня возникает вопрос что это за тесты которые накиданы на одной странице? Обычно тестируют на UI законченные User Story, так как только они и имеют смысл и ценность для пользователя системы и именно за них платят разработке. Возможно, у них все сценарии имеют предусловия, которые приводят систему в нужное состояние, минуя предыдущие станицы, этого я не знаю и из контекста сложно понять. Желание бить на страницы понятно: если разработчик поменял код только на одной странице, то можно запустить лишь те тесты, которые проверяют только её и не запускать лишнее. Но с другой стороны, если есть длинные многостраничные сценарии, то как хранить их при данном подходе? Он был бы хорош для API, где каждый метод можно рассматривать изолированно, а вот с сайтами это смотрится уже как-то чужеродно. Я бы смотрел на месте топик-стартера в сторону тэгов/категорий тестов. Но там тоже может выйти так себе. Еще вижу как причину, чтобы разбивать по страницам - это чтобы проще было делать правки в случае изменения бизнес-логики или структуры страницы. Тогда будет вроде как легко видно какие тесты нужно подправить, но с другой стороны эти вещи обычно не хранят в тесте и выносят в отдельные хелпер-классы и методы и как раз на том уровне делают иерархию сродни страницам (любимый всеми Page Object). Отсюда у меня проистекает некое непонимание вопроса. Чего хочет добиться автор вопроса.
Я уже добился 
Могу объяснить почему возник вопрос. У нас в конторе тесты писали девелоперы. Когда я у них спросил как организованны тесты, они сказали что по страницам: берут страницу и покрывают тестами все модули, фичи. Потом следующую страницу. Взаимодействие между страницами минимальное, например проверка что при действии “А” откравается страница “В” с данными “С”.
В случае написания тестов по юзер сценариям, полюбому будет взаимодействие между станицами.
Я понимаю, что можно и так, и так. Интересно было какой подход больше используется.
Привет! 
Конечно, подход по построению тестового фреймворка относителен, Если в твоем случае уже есть некоторые тесты с логикой по страницам, то по хорошему эту же логику стоит и наследовать далее.
Но классическое начало покрытия продукта автотестами - это сделать смоук, что проходит по всему продукту. Это могут быть как end-to-end: так и тесты unit-типа (один тест - одна проверка). В построение смоука можно включить базовую бизнес логику и поведение элементов на фронте.
Например, поначалу покрываешь рероутинг между всеми страницами, потом - взаимодействие с ui элементами, которые могут быть на каждой из них, тем самым сохранив это поведение в универсальные методы (если это java, например), которые будешь переиспользовать в тестах для других страниц.
Потом постепенно “сужать” круг покрытия функционала к более узконаправленному, исходя из фич и сторей.
Так тебе будет проще построить архитектуру фреймворка и постепенно оптимизировать код.
1 лайк
+1 к последнему комментарию, тут все от специфики зависит, например у меня сейчас фичи фактически на странице находятся и глобальных сценариев толком нет (на прошлом проекте были и это жесть), так что я сперва делаю смоук всей системы, затем по страницам, но т.к. времени, как обычно, не хватает, то покрывается самая востребованная логика, ну и регрешен чек-лист.
Почему 1 тест = 1 assert - это чушь? Просто интересно)
Потому что если мы говорим о тестировании WEB UI, как правило мы говорим и о Selenium WD. А тесты начинаются с обязательного сетапа перед каждым тестом - открытие браузера, логин в систему и переход до тестового стенда. Так вот если вы на каждый тест кейс будете писать новый тест и использовать один ассерт в тесте, то 30% времени ваших тестов это как раз сетап, о котором я говорил. Вы просто теряете это время в пустую и тратите время разработчиков, которые ждут фидбек от ваших тестов. Плюс еще добавьте то, что как правило тесты в CI выполняются не на быстрых девайсах и скорость открытия того же хрома будет не такая как на вашей рабочей машине. А вообще, если вы это спрашиваете, то перед вами явно никогда не стоял вопрос об уменьшении времени тестов и параллелизации
Это хорошо для юнит-тестов, и легковесных интеграционных. Там вынести один ассерт в один тест удобно и дешево в плане затрат на setup / teardown перед каждым тестом. В сложных сценариях в рамках одного теста происходит значительное число проверок (другое дело, что проверки внутри теста можно сделать независимыми друг от друга, т.е. как бы мини-тестики внутри одного сценария), и дробить их на независимые тесты неудобно для отчетов, и дорого, если у вас перед каждым тестом стоит тяжелый setup, н-р развернуть виртуалку из бэкапа.
На самом деле, дело исключительно в структуре тестов.
Если есть тестовый класс - как тест сьют, а каждый метод этого класса это 1 тест кейс
То все setup штуки будут выполняться для класса, перед началом тестов
А потом идут методы, где в каждом по 1 assert
И мне это вполне кажется логичным
Если метод зафейлится, сразу понятно по какой причине, потому что в методе 1 проверка.
Вот в наших тестах, как раз, как вы сказали мини-тестики (тест-кейсы) внутри одного тестового класса.
Почему это неудобно в плане отчётов?
Мне трудно говорить, насколько это может быть неудобным для вас, т.к. я ваши отчеты не видел В моем случае нужно было, чтобы несколько проверок в отчете были представлены как один тестовый сценарий.
Ну тут опять-таки кто какие отчеты использует😊 у нас с Allure, и вроде подошло неплохо)
Вы можете эти тест-кейсы запустить в произвольном порядке? Или запустить только некоторые из них? У вас в manual TC тоже один expected result?
Хотел бы вас попросить показать проверки в тест кейсах, даже интересно, но мне уже кажется, вы допустили архитектурную ошибку в этой конструкции. У вас тесты получаются зависимые друг от друга. Либо вы фейлите весь сьют, если у вас где-то посередине ошибка. Ну это тогда тоже не есть правильно. Тест кейс сам по себе должен иметь возможность запуститься отдельно, а не после ваших предыдущих проверок.