Comments 41
Из описанного у вас достаточно стройная и эффективная система. Есть два вопроса: почему вы не используете распространенный шаблон PageObject (по крайней мере такое ощущение сложилось из ваших примеров) и почему не взяли за основу существующий фреймворк, например Thucydides?
PageObject рассматривали, он нам не подошел, так как логика нашей системы — не экраны, а объекты. Но многие подходы взяли оттуда, я слежу за ним.
Фреймворки даже не рассматривали, хотя и зря. Из-за наивного желания сделать самостоятельно и хорошо. В середине 2011 года я еще не знал, по каким критериям их выбирать, теперь знаю, но у нас уже есть свой. Со всеми его плюсами и минусами.
Фреймворки даже не рассматривали, хотя и зря. Из-за наивного желания сделать самостоятельно и хорошо. В середине 2011 года я еще не знал, по каким критериям их выбирать, теперь знаю, но у нас уже есть свой. Со всеми его плюсами и минусами.
Про фреймворк спросил, потому что мне очень не нравится подход с хранением шагов в javadoc. Нужно постоянно заботиться об их синхронности с тестом, что нелегко при постоянно меняющихся тестах. Взгляните на систему отчетов Thucydides — там все генерируется из тестового кода, шаги легко повторно использовать, привязка к требованиям через аннотации и куча полезностей. Наличие своего фреймворка не преграда, знаю команды, которые перешли с самописных и очень счастливы.
Еще пара советов по вашей статье:
— если вы для каждого элемента имеете ID, то используйте CSS локатор #my_id или на крайний случай оптимизированный XPath локатор id(«my_id») на основе функций XPath
— EMMA как инструмент для измерения покрытия кода отмирает, в Java мире сейчас принято использовать JaCoCo
Еще пара советов по вашей статье:
— если вы для каждого элемента имеете ID, то используйте CSS локатор #my_id или на крайний случай оптимизированный XPath локатор id(«my_id») на основе функций XPath
— EMMA как инструмент для измерения покрытия кода отмирает, в Java мире сейчас принято использовать JaCoCo
Наши тесты пишутся по постановкам и на самом деле меняются достаточно редко. Но — я думал о переходе на готовый фреймворк, Очень уж нравится балансировка тестов, в меньшей степени — синхронизация сценариев и отчеты. Вполне возможно, что это нам светит.
Xpath ищем по id через нашу обертку, проблем нет.
За JaCoCo спасибо, не слышал, Скоро посмотрим, что это.
Xpath ищем по id через нашу обертку, проблем нет.
За JaCoCo спасибо, не слышал, Скоро посмотрим, что это.
Отличаются ли локаторы элементов в зависимости от того, какому браузеру отдается страница? Как обходите данное неудобство?
Функциональные тесты на одном браузере. Под верстку отдельные тесты. Разные действия и проверки.
завидую черной завистью :) Превосходная работа.
Надо завидовать белой и стремиться к лучшему. Эти ребята еще круче сделали, с полным циклом от приемочных критериев до тестов с детальными отчетами по покрытию функциональности. Вот ссылка на их прошлое выступление.
Хороший доклад. Интересно было бы посмотреть на код и CI.
«Слона надо есть по кусочкам» — на моей памяти сделать сразу и по всем канонам — провальная затея. Только когда все осознают, что нам необходимо переходить на новый уровень — тогда дело и двинется.
Так что для меня пока и описанная система — верх совершенства :)
Так что для меня пока и описанная система — верх совершенства :)
Круто у вас все! Статья очень интересная, спасибо!
А как вы параллелите тесты Selenium? Я в эту сторону особо не копал, у нас они выполняются в пределах 30-40 минут, ввиду их немногочисленности. Есть мысли покопать в сторону Selenium Grid.
В целом у нас считается что тесты через UI имеют наименьшую ценность. Все покрывается Unit тестами, в том числе и бизнес логика. Хотя есть целое API для быстрого написания устойчивых тестов Selenium, но менеджмент не считает это возможностью как-то упростить жизнь ручным тестеровщикам (к слову редко кто воспринимает тесты через UI всерьез, по моим наблюдениям). Может у вас есть весомый комментарий к этому, как повлиять на такое мировоззрение менеджмента?
Тестируем мы вот это (например): Пример решения на платформе
А тесты выглядят так (мы завязываемся на серверную реализацию, и управляем UI с точки зрения более высокоуровневых объектов, таких как форма, кнопка, поле ввода, список, вкладка, окно, а не HTML элементов):
А как вы параллелите тесты Selenium? Я в эту сторону особо не копал, у нас они выполняются в пределах 30-40 минут, ввиду их немногочисленности. Есть мысли покопать в сторону Selenium Grid.
В целом у нас считается что тесты через UI имеют наименьшую ценность. Все покрывается Unit тестами, в том числе и бизнес логика. Хотя есть целое API для быстрого написания устойчивых тестов Selenium, но менеджмент не считает это возможностью как-то упростить жизнь ручным тестеровщикам (к слову редко кто воспринимает тесты через UI всерьез, по моим наблюдениям). Может у вас есть весомый комментарий к этому, как повлиять на такое мировоззрение менеджмента?
Тестируем мы вот это (например): Пример решения на платформе
А тесты выглядят так (мы завязываемся на серверную реализацию, и управляем UI с точки зрения более высокоуровневых объектов, таких как форма, кнопка, поле ввода, список, вкладка, окно, а не HTML элементов):
Пример кода
[Test]
public void CreateDocumentFromOperation()
{
var operationCaption = "LinkedDocDocumentOperation";
var linkedDocEntity = new EntityTestInfo()
{
EntityName = typeof(LinkedDoc).Name,
EntityCaption = "The linked doc."
};
var grid = Env.Navigation.OpenList(linkedDocEntity);
grid.Toolbar.Click(operationCaption);
var docForm = Env.TabPanel.GetForm(linkedDocEntity.EntityName);
docForm.GetField<TextField>(ReflectionHelper.GetMemberInfo<LinkedDoc>(f => f.Caption).Name).SetText("Boo-yaa!");
docForm.Toolbar.Click("Создание", "Завершить операцию {0}".FormatWith(operationCaption));
docForm.Toolbar.Click("Черновик", "AutoGenerated {0}".FormatWith("Создать SampleDoc из текущей операции"));
var sampleDocEntity = new EntityTestInfo()
{
EntityName = typeof(SampleDoc).Name,
EntityCaption = "The sample doc."
};
var newDocForm = Env.TabPanel.GetForm(sampleDocEntity.EntityName);
var caption = newDocForm.GetField<TextField>(ReflectionHelper.GetMemberInfo<SampleDoc>(f => f.Caption).Name).GetValue();
Assert.AreEqual("Boo-yaa!", caption, "Кэпшен созданого документа отличается от ожидаемого");
}
А вот пример отчета о падении: www.peeep.us/0586b385
Хм.
Отчет удобен в том плане, что генерируется автоматически.
А скажите, кто читает ваши отчеты? Тестировщики? Программисты? Менеджеры? Кто с ними реально работает.
Если бы я был программистом, то мне удобней был бы стек, лог приложения и строка в которой надо ставить breakpoint.
Если ручной тестер — отличный отчет.
Если менеджер — то нужен заголовок теста.
Ну или какие у вас там есть роли?
Отчет удобен в том плане, что генерируется автоматически.
А скажите, кто читает ваши отчеты? Тестировщики? Программисты? Менеджеры? Кто с ними реально работает.
Если бы я был программистом, то мне удобней был бы стек, лог приложения и строка в которой надо ставить breakpoint.
Если ручной тестер — отличный отчет.
Если менеджер — то нужен заголовок теста.
Ну или какие у вас там есть роли?
Есть роли менеджер и разработчик.
Менеджер смотрит факт падения теста (красный кружочек в TeamCity), блокирует выпуск версии, ставит задачу разработчику разобраться с тестом.
Разработчик иногда заглядывает в тесты, иногда смотрит этот лог, пытается повторить проблему по нему, зафиксировать, решить.
Как-то так. Там кстати есть стектрейс:
Упал на Assert. Если бы была серверная ошибка, то показался бы её трейс.
Все это генерируется автоматически, по шагам теста. Т.е. вручную пишутся только ассерты, можно добавлять информацию по шагам. Когда случилось падение — снимаются скриншоты. Если пришло с сервера что-то, что может быть ошибкой, то это так же приписывается к логу, ну и т.п.
Т.к. этим ограниченно пользуются, то мне непонятно в какую сторону развивать. Вышло во все по немногу. Конечного потребителя, плотно работающего с этими тестами нет :\ Собственно отсюда мой местами нелепый интерес, посмотреть как оно у белых людей :)
Менеджер смотрит факт падения теста (красный кружочек в TeamCity), блокирует выпуск версии, ставит задачу разработчику разобраться с тестом.
Разработчик иногда заглядывает в тесты, иногда смотрит этот лог, пытается повторить проблему по нему, зафиксировать, решить.
Как-то так. Там кстати есть стектрейс:
NUnit.Framework.AssertionException: Форма не содержит информацию о зависимостях Expected: True But was: False at NUnit.Framework.Assert.That(Object actual, IResolveConstraint expression, String message, Object[] args) at Selenium.GridActionTest.OnlyOpenActionFoms() in d:\Team\BuildAgent\SedDatServAgent2\work\195b9fcc838c17ee\Source\Selenium\GridActionTest.cs:line 105
Упал на Assert. Если бы была серверная ошибка, то показался бы её трейс.
Все это генерируется автоматически, по шагам теста. Т.е. вручную пишутся только ассерты, можно добавлять информацию по шагам. Когда случилось падение — снимаются скриншоты. Если пришло с сервера что-то, что может быть ошибкой, то это так же приписывается к логу, ну и т.п.
Т.к. этим ограниченно пользуются, то мне непонятно в какую сторону развивать. Вышло во все по немногу. Конечного потребителя, плотно работающего с этими тестами нет :\ Собственно отсюда мой местами нелепый интерес, посмотреть как оно у белых людей :)
Параллелим — просто 3-6 дочерних сборок с разным набором тестов. В круге четвертом об этом есть.
А я со своей колокольни считаю, что менеджмент ваш прав. Мы писали UI тесты, решая определенный класс проблем. Если у вас их нет — зачем вам UI? А если есть — так его и предъявить менеджерам.
Воспримут всерьез когда вы этими тестами начнете решать проблемы неработающего интерфейса при работающей бизнес логике. Когда UI тесты писать будет проще, чем Unit. Когда UI будут писать все, а юнит только программисты. Например так.
А я со своей колокольни считаю, что менеджмент ваш прав. Мы писали UI тесты, решая определенный класс проблем. Если у вас их нет — зачем вам UI? А если есть — так его и предъявить менеджерам.
Воспримут всерьез когда вы этими тестами начнете решать проблемы неработающего интерфейса при работающей бизнес логике. Когда UI тесты писать будет проще, чем Unit. Когда UI будут писать все, а юнит только программисты. Например так.
А не думали о настоящей паралельности? Ведь большинство тестов UI не конфликтуют друг с другом, а серверную часть нагружают крайне мало. Выходит что весь пакет тестов можно выполнить за время самого длинного теста.
Я вообще разработчик View. Мои проблемы тесты UI решают — мы не выпускаем продукт, в котором не запускается интерфейс (а раньше были прецеденты). А какие классы проблем решаете вы? По статье понятно что у вас большой стек кейсов по прикладным и бизнес задачам, но например какие они? Что конкретно решают, кто решил что это важные аспекты, от кого исходила инициатива написать тест кейс, или зафиксировать процесс (кроме ручных тестеровщиков, как я понял из статьи)?
Я вообще разработчик View. Мои проблемы тесты UI решают — мы не выпускаем продукт, в котором не запускается интерфейс (а раньше были прецеденты). А какие классы проблем решаете вы? По статье понятно что у вас большой стек кейсов по прикладным и бизнес задачам, но например какие они? Что конкретно решают, кто решил что это важные аспекты, от кого исходила инициатива написать тест кейс, или зафиксировать процесс (кроме ручных тестеровщиков, как я понял из статьи)?
Наши UI друг с другом еще как конфликтуют — специфика приложения плюс большие фикстуры.
У нас намного больше клиентского кода, чем серверного. Соответственно и ошибки могут проявляться только при отображении данных, работе с данными в интерфейсе.
Приоритеты кейсов — опыт тестировщиков и мудрые указания аналитиков.
Имитация бизнес процесса проще решается через нашу тестирующую систему, а не unit тестами благодаря развитым DSL.
У нас намного больше клиентского кода, чем серверного. Соответственно и ошибки могут проявляться только при отображении данных, работе с данными в интерфейсе.
Приоритеты кейсов — опыт тестировщиков и мудрые указания аналитиков.
Имитация бизнес процесса проще решается через нашу тестирующую систему, а не unit тестами благодаря развитым DSL.
DSL в смысле языка для тестов, или в смысле языка для прикладной (бизнес) логики? А в целом понял, спасибо!
В идеале бы свести написания хотя бы скелета теста к тому, чтоб протыкать аналитику по его же процессу в интерфейса. Тогда, наверно, этим реально начнут пользоваться. Своего рода запись макросов.
В идеале бы свести написания хотя бы скелета теста к тому, чтоб протыкать аналитику по его же процессу в интерфейса. Тогда, наверно, этим реально начнут пользоваться. Своего рода запись макросов.
Прокомментирую за wolonter насчет настоящей параллельности (я также работаю в этой компании):
Приближенно: Время выполнения тестов=Общее время тестов / Количество серверов
Сейчас у нас Время выполнения тестов 2 ч.
Чтобы сделать прохождение тестов за 15 минут надо всего лишь увеличить количество серверов в 8 раз.
Также для тестов на Selenium основная загрузка не из-за серверной части приложения, а из-за браузера, который очень интенсивно потребяет память и CPU.
Предвосхищая вопрос о headless браузере, скажу, что у нас динамическое приложение со сложной клиентской логикой на JavaScript.
Приближенно: Время выполнения тестов=Общее время тестов / Количество серверов
Сейчас у нас Время выполнения тестов 2 ч.
Чтобы сделать прохождение тестов за 15 минут надо всего лишь увеличить количество серверов в 8 раз.
Также для тестов на Selenium основная загрузка не из-за серверной части приложения, а из-за браузера, который очень интенсивно потребяет память и CPU.
Предвосхищая вопрос о headless браузере, скажу, что у нас динамическое приложение со сложной клиентской логикой на JavaScript.
Отлично! Спасибо за статью и расскрытия темы с плагинами для дженкинса. Обнаружил пару интересных.
Меня интересует несколько иной вопрос.
В дженкинсе тестируются только постоянно присутствующие ветви в git?
Всмысле если девелопер делает свою ветвь для конкретной фичи то он тестирует «у себя» или есть автоматизация создания дженкинс-джоба?
П.С. как вы в плане непрерывной развертки (Continuous Delivery)? Какие принципы? Наработки?
Меня интересует несколько иной вопрос.
В дженкинсе тестируются только постоянно присутствующие ветви в git?
Всмысле если девелопер делает свою ветвь для конкретной фичи то он тестирует «у себя» или есть автоматизация создания дженкинс-джоба?
П.С. как вы в плане непрерывной развертки (Continuous Delivery)? Какие принципы? Наработки?
Автоматически — только develop.
Ветвь для фичи можно протестировать, запустив специально созданную для этого сборку. Они уже есть, 4 штуки.
С ужасом и радостью осознаю, что и к Continuous Delivery мы идем. Медленно, но идем.
Ветвь для фичи можно протестировать, запустив специально созданную для этого сборку. Они уже есть, 4 штуки.
С ужасом и радостью осознаю, что и к Continuous Delivery мы идем. Медленно, но идем.
А почему с ужасом? :)
Ветвь для фичи можно протестировать, запустив специально созданную для этого сборку
А подробности не расскорите… я как-то не придумал как к этому лучше подойти…
и да почему с ужасом? ;)
Ужас от того, что работать придется с боевыми серверами. Не тестовыми.
А какие именно подробности?
А какие именно подробности?
Я также причастен к этой системе, могу прокомментировать:
* В сборке для develop константа «develop» зашита в настройке job, сборка инициируется по коммиту.
* В сборках веток используется параметр с нетривиальным именем BRANCH :), сборка запускается вручную.
* В сборке для develop константа «develop» зашита в настройке job, сборка инициируется по коммиту.
* В сборках веток используется параметр с нетривиальным именем BRANCH :), сборка запускается вручную.
Почему вы выбрали Git вместо Mercurial? Рассматривался ли Mercurial в качестве DVCS вообще?
Изначально мы вообще на Subversion начинали.
Рассматривали Git vs Mercurial, победил Git в силу большей распространенности в нашей компании и того, что не нашли ни одного аргумента против Git
Рассматривали Git vs Mercurial, победил Git в силу большей распространенности в нашей компании и того, что не нашли ни одного аргумента против Git
Случались ли у вас проблемы с необходимостью небольших исправлений в уже выпущенных релизах, и в связи с чем как часто вы выполняете git rebase?
( Проблема описана здесь: habrahabr.ru/post/123700/ )
( Проблема описана здесь: habrahabr.ru/post/123700/ )
Краткий ответ — мы очень часто выполняем git rebase, но это не имеет отношения к необходимости небольших исправлений в уже выпущенных релизах.
Полный ответ —
Мы используем модель git flow (можно посмотреть nvie.com/posts/a-successful-git-branching-model/)
Проблем при необходимости внесения небольших изменений нет. Делается обычно 3 коммитами
* от тега с версий отцепляется ветка, изменяются номера версий на следующую младшую + SNAPSHOT (мы используем Maven)
* в этой ветке делается исправляющий коммит (или он забирается из ветки develop с помощью git cherry-pick)
* убирается из версий слово SNAPSHOT,
Работа по изменению номеров версий выделена в отдельные задачи Jenkins, разработчику надо лишь сделать исправляющий коммит.
git rebase делается в рамках работы над задачей
* разрабтчик отцепляет ветку от develop
* делает коммит
* тесты, тесты, тесты
* перед слиянием в ветку develop выполняется git rebase develop для получения изменений от других разработчиков, разрешаются конфликты.
* выполняется git merge в ветке develop
По проблемам автора статьи habrahabr.ru/post/123700/
1. Мне нужно знать на какой ветке было зафиксировано ab3e2afd для того, чтобы знать, включать ли его в описание изменений будущего релиза.
Мы описываем изменения по задачам. Все изменения всегда фиксируются лишь в ветке develop. Лишь багофиксовые изменения фиксируются в несколько веток, тогда задачу привязываем к нескольким версиям.
2. Мне нужно знать какое изменение было первым в ветке «release», потому что я хочу начать новую тематическую ветку с этого изменения в качестве начальной точки так, чтобы я всегда был в курсе происходящего в главной ветке насколько это возможно, и быть уверенным, что смогу выполнить чистое слияние в главную ветку и выпустить релиз.
У нас главная ветка — develop, мы постоянно делаем в нее слияние. Релиз выпускается не слиянием в главную ветку кучи коммитов и последующим разгребанием проблем, а отцеплением от всегда стабильной (ну почти :)) develop. Выпуск версии — посмотреть, что все тесты проходят и запустить задачу в Jenkins. которая проставит версию.
3. Мне нужно знать где началась ветка «topic» для того, чтобы я мог сложить все патчи вместе и отослать их своим коллегам для рецензии.
Для выполнения отдельной задачи создается патч и коллегам высылается ветка, которую надо сравнивать лишь с develop. Тем более мы пользуемся gitlab для рецензирования, достаточно указать ветку с изменениями и ветку, изменения относительно которой надо посчитать.
Полный ответ —
Мы используем модель git flow (можно посмотреть nvie.com/posts/a-successful-git-branching-model/)
Проблем при необходимости внесения небольших изменений нет. Делается обычно 3 коммитами
* от тега с версий отцепляется ветка, изменяются номера версий на следующую младшую + SNAPSHOT (мы используем Maven)
* в этой ветке делается исправляющий коммит (или он забирается из ветки develop с помощью git cherry-pick)
* убирается из версий слово SNAPSHOT,
Работа по изменению номеров версий выделена в отдельные задачи Jenkins, разработчику надо лишь сделать исправляющий коммит.
git rebase делается в рамках работы над задачей
* разрабтчик отцепляет ветку от develop
* делает коммит
* тесты, тесты, тесты
* перед слиянием в ветку develop выполняется git rebase develop для получения изменений от других разработчиков, разрешаются конфликты.
* выполняется git merge в ветке develop
По проблемам автора статьи habrahabr.ru/post/123700/
1. Мне нужно знать на какой ветке было зафиксировано ab3e2afd для того, чтобы знать, включать ли его в описание изменений будущего релиза.
Мы описываем изменения по задачам. Все изменения всегда фиксируются лишь в ветке develop. Лишь багофиксовые изменения фиксируются в несколько веток, тогда задачу привязываем к нескольким версиям.
2. Мне нужно знать какое изменение было первым в ветке «release», потому что я хочу начать новую тематическую ветку с этого изменения в качестве начальной точки так, чтобы я всегда был в курсе происходящего в главной ветке насколько это возможно, и быть уверенным, что смогу выполнить чистое слияние в главную ветку и выпустить релиз.
У нас главная ветка — develop, мы постоянно делаем в нее слияние. Релиз выпускается не слиянием в главную ветку кучи коммитов и последующим разгребанием проблем, а отцеплением от всегда стабильной (ну почти :)) develop. Выпуск версии — посмотреть, что все тесты проходят и запустить задачу в Jenkins. которая проставит версию.
3. Мне нужно знать где началась ветка «topic» для того, чтобы я мог сложить все патчи вместе и отослать их своим коллегам для рецензии.
Для выполнения отдельной задачи создается патч и коллегам высылается ветка, которую надо сравнивать лишь с develop. Тем более мы пользуемся gitlab для рецензирования, достаточно указать ветку с изменениями и ветку, изменения относительно которой надо посчитать.
Sign up to leave a comment.
Девять кругов автоматизированного тестирования