testomat.io управление авто тестамиРуководство по приготовлению бутербродов из Selenium. Часть 3 – Рекомендации по развитию автоматизации
</div><p style="text-indent: 20px;" align="justify"><strong>5. Зачем нам понадобилось прикрутить Coded UI Test</strong></p>
В один прекрасный день в Easy Projects .NET появился новый функционал,
ну очень сложный для автоматизации. Много Ajax-запросов, Java Script.
Средств Selenium RC явно не хватало. Мы занялись поиском
вспомогательного инструмента автоматизации, который бы справился с
возникшими проблемами, так как новый функционал был очень важен для
проекта, так называемая «киллер фича» – ее тщательно нужно было
проверять. К слову, Selenium 2.0 WebDriver тогда был еще в совсем не
стабильном состоянии. Собственно говоря, особых поисков не было, это
примерно как на выборах президента Беларуси – выборы есть, но все знают
кто победит. Все дело, в том, что к тому моменту вышла новая версия
Visual Studio в которой появился замечательный инструмент автоматизации –
Coded UI Test. И к этому моменту он успешно использовался на другом
нашем проекте Birdview Projects,
и мы знали про все его преимущества и недостатки. Также плюсом являлся
тот факт, что Coded UI Test умеет работать с Silverlight. В качестве
альтернативы мы рассматривали Telerik WebUI Test Studio от Telerik. Но очевидный перевес был на стороне Coded UI Test.
Не буду вдаваться в подробности технической реализации – это тема отдельной статьи. В плане архитектуре в нашем фреймворке особых изменений не произошло. Просто добавился еще один слой Coded UI, содержащий команды. Данный слой примерно эквивалентен Selenium Document, не беря в расчет некоторые моменты реализации. Вот такая вот структура ButerbroD-а получилась при использовании в качестве драйверов веб-интерфейса Selenium RC и Coded UI Test:
Отличительно особенностью реализации тестов на Coded UI заключается в том, что при создании абстракции страницы помимо элементов и проверок мы реализуем все действия на данной странице. Это связанно с особенностями реализации Coded UI. На уровне атомарных действий просто вызываются методы со страницы. Далее все, как и с Selenium RC. Набор атомарных и составных действий позволяет нам использовать методы как Selenium RC, так и Coded UI Test в любой последовательности. Выглядит это примерно так:
Данное решение работоспособное и оправдало себя, хотя и потребовалось некоторое время на стабилизацию. На данный момент мне бы хотелось переписать авто-тесты с Coded UI на Selenium WebDriver, а Coded UI оставить только для тестирования Silverlight модулей.
6. Как автоматизация работает у нас на проекте
Тесты должны запускаться достаточно часто. Если для вас запуск тестов является проблемой, то данную ситуацию нужно срочно решать. Мы на проекте начинали с ручного запуска тестов при выходе новой сборки продукта. Разработчики предоставляли команде тестирования установочные файлы. Тестировщики вручную «раскатывали» приложение и запускали на них авто-тесты. Новые сборки на тестирование поставляли один раз в одну-две недели. Тесты запускались каждый раз при выходе нового билда. Этот подход был не совсем удобен, поэтому через некоторое время перешли на непрерывную интеграцию (англ. Continuous Integration). Это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Фактически, мы смогли отказаться от стандартной процедуры приемки нового билда, сейчас за нас все выполняет робот! Авто-тесты выполняются регулярно на специально выделенном сервере практически после каждого изменения. Сперва авто-тесты запускали при каждом изменении кода. Когда тестов стало совсем много и уже никто не ждал, пока тесты выполняться, решено было авто-тесты запускать только при ночных сборках продукта. Для реализации Continuous Integration используется система TeamCity, которая мне очень нравится. В TeamCity предоставляются достаточно обширные возможности для конфигурации тестов. В качестве системы для работы с исходным кодом и контроля версий используется Mercurial (TortoiseHg). Ночные тесты выполняются на интеграционной ветке при наличии изменений. На остальных ветках авто-тесты запускаются по усмотрению команд (у нас на проекте несколько команд разработки). Как правило, на временных ветках тесты запускаются при завершении задачи и перед объединением с интеграционной веткой. Вот так выглядят ветки проекта Easy Projects .NET в TortoiseHg, для каждой из этой веток запускаются тесты:
Авто-тесты для нового функционала разрабатываются в одной ветки вместе с этим функционалом, вместе с кодом они попадают в основную ветку. Авто-тесты для уже существующего функционала разрабатываются и стабилизируются в отдельной ветке. В ветке в которой изменяется функциональности продукта, что в свою очередь приводит к падению авто-тестов должны быть исправлены все падающие тесты. Таким образом, для каждой ветки у нас имеется свой набор стабильно работающих тестов. Задачи на автоматизацию создаются командой при планировании очередного спринта.
При ночном прогоне авто-тестов, каждый тестовый набор выполняется на
чистой базе. Это сделано для того, что бы избежать побочных ошибок при
выполнении тестов. Помимо ночных запусков тестов, существует еще один
набор тестов для запуска уже собранных приложений. В данном случае, для
запуска авто-тестов в конфигурационном файле нужно всего-то прописать
адрес тестируемого приложения.
Изначально тесты разрабатывались только под FireFox и Internet Explorer.
Так как функциональных дефектов, характерных только Internet Explorer
авто-тесты не находили (их действительно не было), то мы решили
отказаться от поддержки Internet Explorer. И тем самым сэкономить
временные затраты на поддержку.
Спустя некоторое время стало очевидно, что из-за большого числа
авто-тестов время их выполнения значительно выросло. Было решено
распараллелить выполнение тестов. Распараллеливание организовали с помощью TFS,
сейчас полный набор тестов (более пятьсот тестов) выполняется в три
потока. Полный набор тестов выполняются около полутора часов.
Мы заботимся о качестве наших тестов. Тесты должны быть легко сопровождать,
для этого нужно соблюдать чистоту кода. Комментарии и заметки в
авто-тестах обязательны. Помимо этого для тест-кейсов, выполняемых
вручную, мы проставляем в системе управления проектом статус
автоматизации. Заавтоматизированные дефекты помечаются опцией в
информации о дефекте, при этом пытаемся заавтоматизировать все серьезные
дефекты. Данная минимальная документация действий позволяет оценить
степень покрытия требований или тест-кейсов. Для того, чтобы тесты были
легко сопровождаемыми, нужно стараться давать понятные имена методам и
переменным. Не забывайте проводить регулярно код ревью. Автоматизация –
это по сути то же самое программирование, поэтому применяйте все лучшие
из практик программистов и для авто-тестов.
Старайтесь извлечь от авто-тестов максимум пользы.
Тесты можно запускать на различных конфигурациях, браузерах,
локализациях и т. д. Авто-тесты мы даже использовали для провидения
нагрузочного тестирования, конечно это громко сказано. Но некоторые
замеры нам удалось сделать. Благо HG позволяет собирать статистику о
времени прогона тестов.
Не забывайте про надежность тестов. Тесты должны быть в достаточной мере стабильными. Если регулярно некоторые тесты падают, то их нужно отключить и стабилизировать.
Еще один важный момент заключается в оптимизации
тестов. Старайтесь не использовать дублирующих проверок, действий.
Старайтесь минимизировать шаги, если это можно. Например, когда мы
убрали лишние Login-ы в тестах (используем механизм куки), общее время
прохождения тестов сократилось на восемь минут! Иногда (не часто)
полезно измерять покрытие кода (Code Coverage)
авто-тестами. Особенно актуально измерять покрытие, когда нет
нормальной тестовой документации и автоматизация не имеет стихийного
характера. Для измерения покрытия кода авто-тестами мы использовали
программу dotTrace.
В принципе, подобных инструментов хватает на рынке программных
продуктов. Информация, полученная в результате Code Coverage, будет
полезной для оценки текущего состояния автоматизации. Периодически
полезно пересматривать имеющиеся у вас тесты. Так как тесты имеют
свойство устаревать, их нужно обновлять, модернизировать, старые тесты
можно выкидывать из общего запуска.
Какие вспомогательные инструменты я чаще всего использую при разработки тестов:
7. Планы на будущее
В связи с выходом Selenium 2.0 WebDriver, естественно мы
заинтересовались возможностями данного инструментами и возможностью
перехода с Selenium RC на WebDriver. Эксперименты показали, что особых
проблем с переходом не должно быть. Некоторые места ButerbroD-а
желательно подправить, например можно отказаться от ButerbroD-ных
механизмов поиска локаторов в пользу метода Find.By
WebDriver-а. Конечно, делать это не обязательно. Ну а сами методы
Selenium RC можно постепенно переписывать работая в режиме совместимости
с WebDriver (WebDriverBackedSelenium). Пока особой необходимости
переходить на WebDriver не имеет смысла, так как все тесты работают
успешно и особых проблем с написанием новых тестов не наблюдается.
Самый главный план на будущее – выложить ButerbroD в open sourse для свободного распространения. Давайте ButerbroD-ить вместе! Все новости о развитии проекта ButerbroD будут появляться в моем блоге.
8. Заключение
История автоматизации тестирования на проекте Easy Projects .NET не
закончена, она будет продолжаться. Надеюсь, на ваших проектах
автоматизация также будет развиваться 
. ButerbroD также будет развиваться, постепенно обрастать жирком. Выше
описанный подход к автоматизации нельзя назвать идеальным, но он
работает и работает очень хорошо! Внедрения автоматизации
функционального тестирования позволило нашей команде значительно
увеличить качество выпускаемого продукта, а также усовершенствовать
процесс работы над проектом. Процесс становления автоматизации был
совсем не прост, но мы смогли добиться больших успехов. Автоматизация
стала неотъемлемой частью рабочего процесса. Я искренне рад, что смог
принять участие в этом интересном деле и внести существенную лепту в его
успех!
Хочу поблагодарить всю команду проекта Easy Projects .NET и всех ребят из Logic Software за помощь в приготовлении ButerbroD-ов! Особое спасибо всем тем, кто стоял у истоков нашей истории автоматизации!
Отдельные слова благодарности хочу сказать Павлу Почобуту и Александру Лавриновичу! Без них ButerbroD не был бы таким, какой есть.
Надеюсь, ButerbroD-ы пришлись вам по вкусу! 