В любом из основных языков программирования существуют BDD фреймворки автоматизации. В некоторых даже не один. Основываясь на структурных принципах, описанных в предыдущей статье, в этой я представляю обзор основных фреймворков, существующих сегодня. Поскольку я вряд ли смогу рассмотреть подробно каждый BDD фреймворк в рамках этой серии, состоящей из 101 статьи, моей целью является помочь вам, читатели, выбрать фреймворк, наиболее подходящий именно вам. Для каждого фреймворка имеется сопроводительная online документация с информацией о его специфике и способах использования, но я бы предпочел не дублировать документацию. Используйте эту статью, главным образом, как справочный материал. (Полный список статей можно найти на странице Automation Panda BDD.)
Рано или поздно каждый специалист в сфере автоматизированного тестирования сталкивается с необходимостью ускорять тестовые прогоны, идя для этого на всевозможные ухищрения, в том числе прибегая к инфраструктурным решениям.
Последнее время трендом стало использование инструмента виртуализации Docker, и именно о нём будет данный доклад, а также о ряде других лайф-хаков, которые сыграли большое значение в решении задачи по ускорению прогонов на практике.
В рамках доклада вы получите ответы на следующие вопросы:
что такое Docker, и в каких случаях он позволяет оптимизировать тестовые запуски
как избавиться от классических «болезней» при параллельном выполнении автотестов
как получить достаточное количество окружений для параллельных запусков, изрядно при этом сэкономив
как привнести динамику в жизнь проекта и, в случае необходимости, без труда мигрировать между серверами?
Если бы на модные словечки века проводился конкурс (хоть я и не думаю, что тестированию уже стукнуло сто лет), я почти на 100% уверен, что выиграла бы автоматизация тестирования. Если вы читаете про тестирование или слушаете подкасты, это обычно «автоматизация то», «автоматизация се», «автоматизируйте все».
Оно безусловно чрезмерно употребляется и чрезмерно злоупотребляется, и я готов спорить, что куча людей, дающих советы по автоматизации, не имеют ни малейшего представления, о чем они, черт возьми, говорят. Или, как минимум, их заявления демонстрируют полнейшее непонимание цели автоматизации.
То, что термины «тест-автоматизация» и «автоматизированное тестирование» во многом ошибочны, то, что «автоматизировать» тестирование, в сущности, нельзя, то, что мы можем автоматизировать только его часть, обсуждалось множество раз, бла, бла, бла, я не буду это повторять, и мне скучно говорить об этом снова и снова. Мысль, которая ударила меня как молния, состоит в том, что автоматизации тестирования не существует – есть «тестирование» и есть «автоматизация». Мне кажется, что наше мышление еще недостаточно развилось для того, чтобы мы эффективно их комбинировали. Сейчас покажу.
Автоматизация мобильных приложений – молодая отрасль. В ней пока мало наработанных решений, готовых фреймворков и стабильных утилит. Тестировщик, выбирающий стек автоматизации, далеко не всегда может оценить популярность и нужность той или иной утилиты, ведь знания о них разрознены и труднодоступны.
В этом видео я рассказываю о всех популярных инструментах автоматизации, от драйверов и простых надстроек до универсальных комбайнов, рассматриваю их популярность и целесообразность использования. Если вы не знаете, какой фреймворк выбрать и стоит ли работать с Appium – посмотрите это видео, станет понятнее.
Selenium WebDriver – это, фактически, стандарт для автоматизации Web UI. Отличный инструмент, но, как и все хорошее, зачастую используется неправильно. У меня много вопросов к использованию Selenium WebDriver, и сейчас вы узнаете об этом все!
WebDriver «Юнит-тесты»
«Юнит-тесты на WebDriver» напоминают квадратные круги – они по определению неверны логически. Если мне не изменяет память, юнит-тесты – это тесты белого ящика, что подразумевает прямой доступ к коду продукта. Тесты Web UI, использующие WebDriver – это тесты черного ящика, так как они взаимодействуют с активным, запущенным сайтом. Следовательно, они выше уровня юнит-тестов по определению. Не надо их так называть.
Современные тестовые фреймворки – это комплексные утилиты с богатым фунцкионалом. При помощи JUnit или TestNG можно написать тесты практически любой сложности. Тем не менее, такое богатство функционала зачастую избыточно. Если ваша задача – автоматизировать небольшое мобильное приложение, или вы только начинаете работать с автоматизацией, использование универсальных фреймворков не всегда будет оправдано. Многообразие возможностей и большое количество кода могут отпугнуть начинающих от написания автотестов.
В такой ситуации помогут специализированные фреймворки. Один из таких фреймворков – Cucumber – проектировался как фреймворк для приемочного тестирования, поддерживает Behavior Driven Development, а разработка в нем ведется на языке Gherkin. Этот язык близок к естественным языкам, и код на нем выглядит куда более дружелюбным. Конечно, за шагами Cucumber также стоит некоторое количество кода, но гранулярность и понятность самих шагов облегчает его написание.
В этом видео я рассказываю о префиксах Given, When, Then, And и Or, и об их правильном использовании в тестах.
Трудно ли автоматизировать мобильные приложения с нуля?
Нужно разобраться в инструментах, выбрать из них подходящие, подобрать правильные версии утилит, настроить их работу, а потом ещё и написать код.
Кажется сложным? Вы не одиноки — эта сложность останавливает многих. Порог вхождения в мобильную автоматизацию довольно высок, ведь инструменты только развиваются, а информации о них не так много. Но решать задачу надо, иначе качество вашего приложения не будет достаточным.
На мастер-классе в Екатеринбурге Арсений Батыров рассказывал, как развернуть автоматизацию мобильного приложения на Android с нуля. Ученики установили и настроили все нужные утилиты, запустили эмуляторы и написали первые тесты. На сложную логику времени не хватило, зато каждый смог настроить свою машину, подключить девайс и написать рабочий тест. Продолжить автоматизировать можно будет самостоятельно: всё-таки разбираться в рабочем процесс гораздо проще, чем начинать с нуля.
В моей компании мы внедрили автоматизированную визуальную регрессию в нашу стратегию тестирования для трех продуктов. Мы выбирали разные фреймворки для внедрения, и мы используем автоматизированное визуальное регрессивное тестирование с немного разными целями в каждой команде. В этой статье я делюсь концепцией автоматизированной визуальной регрессии и привожу конкретные примеры ее использования.
Что такое визуальная регрессия?
Внешний вид веб-приложения обычно определяется каскадной таблицей стилей (CSS). Ваш продукт может использовать другую разновидность CSS – например, SCSS, SASS, LESS. Все они описывают формат и развертку вашего пользовательского веб-интерфейса.
Когда вы вносите изменения в продукт, вы, скорее всего, меняете его внешний вид. Вы можете намеренно работать над задачей дизайна – к примеру, исправлять отображение модального диалогового окна – или же разрабатывать часть функциональности, которая проходит через пользовательский интерфейс, что означает, что вам придется менять содержание экрана – к примеру, добавлять поле логина к банковской учетной записи. В обоих случаях вам, возможно, нужно внести изменения в таблицу стилей.
Переход к модели непрерывной поставки ПО повлиял на растущую популярность автоматического тестирования. DevOps тоже голосуют за слом барьеров между традиционными ролями. Тестировщики, умеющие программировать (на самом деле этим автоматизаторы и являются) очень здорово встраиваются в эту новую парадигму.
Автоматизация тестирования предлагает множество потенциальных выгод, включая повышенную эффективность и предоставление работоспособного метода решения сложных задач тестирования. Автоматизирование тестов также дает повышенную систематичность, позволяя более эффективно использовать ресурсы в период провала нагрузки. Однако автоматизация – не панацея. Дабы осознать потенциал автоматизации, нужно быть в курсе трех распространенных ошибок автоматизации тестирования.
