Выбор окружения для автоматизации тестирование web-приложения

общие вопросы
, , ,
#1

Передо мной поставлена задача по автоматизации тестирования большого проекта, находящегося в стадии активной разработки, но уже работающего на боевой системе. В проект постоянно дописываются новые фичи. Это веб-приложение, использующее много асинхронных элементов (AJAX).
Проект постоянно пересобирается, в качестве CI используется TeamCity.

Сейчас все трестируется вручную кучей тестировщиков, планируется автоматизировать рутинные действия + параллельное выполнение тестов в автоматическом режиме по ночам. Тут Selenium Grid, как я понимаю нужно использовать. Также нужно удобное и красивое отображение репортов о тестах.

Мной предложено решение Selenide+jnit+maven. Пока понятия не имею, как это прикручивать к TeamCity, но почти на 100% уверен, что это выполнимо.

Руководитель проекта рекомендует посмотреть в сторону webdriver.io. В качестве языка программирования там используется JavaScript, что лично мне не очень нравится, я бы лучше Java использовал. Но не только же язык определяет выбор.

И так вопрос. Что и почему мне выбрать из этих вариантов? Или что-то третье?

#2

А в чем руководитель проекта видит преимущества такого выбора? На самом деле ни один язык не лучше и не хуже, а проект должно интересовать то, на чем быстрее вы сможете написать. (За исключением тех случаев, если захотите писать на редкой платформе, которую потом никто поддержать не сможет.)

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

#3

Я еще поговорил с ним, ему просто JS удобнее. А мне без разницы на чем писать, я одинаково плохо знаю Java и JS. И Selenide мне очень понравился. В результате остановились на решении. Selenide + Maven + junit + TeamCity.
Задачи такие:

  1. Собственно регрессионное тестирование.
  2. Тестирование должно проводится в автоматическом режиме после девелоперские сборок, это обеспечивает TeamCity.
  3. Необходим параллельный запуск тестов. Это обеспечивает junit.
  4. Необходимы репорты в xml, чтобы красиво их показать в TeamCity.

Все ли верно я описал?

#4

пункт 3 - рекомендую смотреть в сторону testng, а не junit. Если у вас нет собственного более менее готового решения, который вы писали или с которым работали (судя по “я одинаково плохо знаю Java и JS” опыта у вас немного), примеров для параллелизации тестов больше с testng.

#5

Ок. Попытаюсь из сравнить. Почитаю что-нибудь. Selenide, вроде бы поддерживает оба решения.
А по поводу красивых репортов, что скажете?

#6
  1. Советую использовать язык программирования, который используется в проекте - что у вас на бэкэнде(Java/C#/PHP)?
  2. За “регрессионное тестирование”/“в автоматическом режиме после девелоперские сборок” отвечают настроенные “Сборки”/“Ворки”/“Билды” - точно не знаю как в терминах CI TeamCity это называется.
  3. Параллельность можно обеспечить разными путями, в зависимости от пункта 1 скорее.
  4. Репорты генерируются тест раннерами(например как вы писали jUnit), которые после прогона “Сбоки” из пункта 2 будут доступны в читаемом в виде в вашей CI.
1 лайк
#7

  1. По поводу выбора языка. Не понимаю этого совета совсем. Зачем использовать то, на чем проект написан? Тестируем UI, а не код, даже не юниттесты нужны. А спросить про практически любой язык в нашей компании есть у кого.

  2. С этим разберемся, спецы по тимсити есть у нас.

  3. Что за пути? Например, при выборе Java + Selenium + Selenide + junit (или testing).

#8

это дело можно прикрутить и к тому, и к другому. (Опять таки я видел больше примеров с testng)

#9

По репортам:
http://allure.qatools.ru/
Как интегрировать в TeamCity:
http://wiki.qatools.ru/display/AL/Allure+TeamCity+Plugin

По параллелизации тестов/сьютов jUnit+Maven:
http://internetka.in.ua/junit-tests-parallel/

#10

Поскольку вы тестируете UI могу предположить, что вы захотите кроссбраузерное тестирование. Не юзал Allure TeamCity Plugin, но судя по скринам там можно выбрать только 1 путь к allure-results. Т.е. если я правильно понял, то для каждого браузера должна быть своя задача в TeamCity и соответсвенно свой отчет, или же использовать Allure CLI. Поправьте, если я не прав?

В jenkins можно указывать несколько путей с результатами и получить в одном отчете результаты для разных браузеров.

Отсюда вы можете распаралелить тесты для кроссбраузерности.

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

#11

Потому что кроме вопросов по синтаксису, конструкциям итд конкретного языка, у тебя еще будет очень много вопрос по смежным темам, вроде сборки проекта, использоанию тестовых фреймворков , отчетов, да что там, даже по работе с IDE тебе смогут сразу сильно упростить жизнь окружающие, но только если ты будешь использовать те же инструменты, что и они. Уверен, что твои коллеги могут без проблем во всем разобраться, и тебе помочь, вот только время у них на это не будет особо да и желания, если проект написан на, скажем, php, а ты используешь в тестах Java, там вообще вся экосистема разная, ни кому не будет интересно в этом разбираться. А если ты свалишь, кому потом это все поддерживать. А так, любой член команды всегда сможет тебе помочь букавально мельком взглянув в код. Плюс подсказать изначально верные пути и у тебя уже не будет вопросов, вроде jUnit или TestNG итд.
Далее, даже если сейчас ты не планируешь какой-либо интеграции UI тестов с бэкэндом тестируемого приложения, то в будущем такая связка может понадобиться или просто сильно упростит тебе жизнь – возможность, скажем, исопльзуя контролер реги, сразу создать пользователя итд.
Кароче просто поверь, это правлиьный путь, который все рекомендуют. Тут может быть выбор только в том случае, когда ты хорошо знаешь один язык и интсрументы вокруг него, но проект использует другой. Тогда еще можно исктаь плюсы и минусы, да и то, даже в этом случае я бы начал изучать язык проекта. Так как это позволит тебе лучше понимать техническую часть самого проекта.

1 лайк
#12

именно поэтому вместо использования того, на чем проект написан, чаще всего используют язык с предельно понятным синтаксисом и, если дело касается какого-то фреймворка, с упором на внятный API этого фреймворка. Скажу так: все проблемы описанные вами могут быть исключены, если сами тесты являются самостоятельным изолированным проектом - со своим исполняемым энвайронментом, может даже репозиторием и CI решением (в случае с black box, GUI\UX, regression) очень частая практика.

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

“коллеги могут без проблем во всем разобраться” - опыт подсказывает, что ВО ВСЕМ разобраться никто не хочет помогать. И уж точно в моем понимании языковые проблемы ( а не проектные ) человеку свойственно обращаться за помощью на испытательном сроке на позиции джуниора. Очень приятно, конечно, убивать зайцев за изучением языка, но я убежден, что [quote=“Tokin, post:11, topic:8721”]
Кароче просто поверь, это правлиьный путь, который все рекомендуют.
[/quote]
-не истина в абсолюте.

Наверное, мы просто смотрим на вопрос выбора языка с разных позиций :slight_smile: В малых фирмах, например, где нет ни одного программиста на скриптовом языке ( Питон, жи-эс, Руби ), а 95% знают Java - да, писать на Java тесты будет в фаворе. В фирмах же с большой текучкой кадров\бурно развивающимися проектами\мультиязыковыми специалистами имхо общерыночные вопросы превалируют на джуниоро-ориентированными проблемами выбора языка как такового.

#13

В продолжении прошлогоднего разговора.
По поводу языка Вы меня не убедили. И не убедите. :smile:
Ну, не люблю я MS и C#, соответственно.

А к решению, которое я описывал выше java + selenide + junit + maven + teamcity, решили прикрутить Cucumber, чтобы простые мануальные тестировщики писали тесты. :smile:
Пока пробуем перед тем, как принять решение о внедрении.

Что скажете на этот счет?

#14

Please don’t use Cucumber

#15

Вы уже не первый, кто так говорит.
Основным аргументом против Огурца звучит, что стейкхолдеры не смогут/не будут использовать Gherkin. В моем случае, это будут делать мануальные тестировщики, которые всю регрессию постоянно делают руками. А когда билды бывают по несколько раз в день, они сходят с ума. Так что этой проблемы не будут.

#16

а Вы точно уверены что они будут их делать / у них будет на это время?
Особенно, если

#17

Да. На это специально будет выделено время.
Регрессия, конечно, при новом билде проводится не полностью, а только в изменяемом месте. Полностью проводится перед заливом на бой и сразу после.

#18

Я не являюсь ненавистником бдд, но как-то особого желания его использовать пока не возникало :smile:

Можете так же почитать недавние обсуждения:

#19

Вот буквально свежая тема. Человеку нужно описать автотесты в виде кейсов, т.к. раньше это не делалось.

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

С тех пор предпочитаю BDD, чтоб для всех была прозрачность.

#20

Нашел свою старую тему. Захотелось написать, что вышло.
Как указано выше выбирали Selenide. Не полетело, моего знания программирования (не Java даже, а в целом) не хватило, правда сейчас, спустя 4 месяца работы, я бы мог что-то путное сделать. Выбрали, как и хотел руковрдитель проекта, Webdriver.io. Пришлось быстро учить JS, понимать кое-что из Node.js, но ничего сверхъестественного.
А фреймворк реально крутой, почти все, что нужно нам делает, что не мог, дописали.
Тестовый сценарии пишем на огурце (и уже начали мануальные тестировщики писать, как и задумывалось), реализация на JS. Тесты бегают на TeamCity и локально.
Пока не победили одну проблему, но она не приоритетна. Тесты на CI нестабильны, а локально, отлично работают.
Если есть вопросы, задавайте, попробую ответить.

2 лайка