Обзор Robot Framework

Цель данной статьи — описать Robot Framework, раскрыть возможности применения и преимущества его использования на проекте, а также поделиться подходами, которые были использованы на практике.

Описание Robot Framework

Robot Framework (далее, RF) — это open-source фреймворк, основанный на Python, представляющий расширяемую платформу автоматизации тестирования для сквозного приемочного тестирования и разработку через приемочное тестирование (ATDD). Его можно использовать для тестирования распределенных гетерогенных приложений, где требуется проверка нескольких технологий и интерфейсов. Тестовые сценарии пишутся с использованием keyword testing методики и записываются в формате таблицы.

Преимущества использования Robot Framework

Keyword Driven Testing (KDT) подход: имея в наличии ключевые слова, разработкой тестов может заниматься QA специалист без навыков или с минимальными навыками программирования.
Многообразие внутренних библиотек: для RF существует свыше 40 различных библиотек, если функциональности из готовых библиотек будет недостаточно, то можно реализовать и подключить свою библиотеку.
Собственная среда разработки RIDE. Кроме того, в случае необходимости, имеется возможность использования плагинов для работы в IDE и некоторых текстовых редакторах.
Удобные и подробные логи с результатами выполнения тестов: из них можно получить много информации в случае проблем с тестами.
Большое и активное сообщество: ответы на многие вопросы можно получить достаточно оперативно в течение дня.
Плагины для Jenkins, Maven, Ant: облегчают процесс интеграции с CI, упрощают развертывание в Java.
Возможность интеграции с системами управления тестированием TestRail и TestLink, используя Listener.

Недостатки использования Robot Framework

Нет параллельного запуска тестов. В данный момент активно ведутся доработки в этой области.
Поддерживается работа только с Python 2.7. Данный недостаток может быть несущественным, если работа ведётся в Java. Также в данный момент весь Robot Framework активно переделывается под Python 3.
BDD требует написания собственных библиотек.
Если вы живете в Финляндии, вероятно, у вас не будет выбора, какой тестовый фреймворк использовать. :)

Применение RF хорошо отражает следующая иллюстрация, спасибо SQA Days

Подходы к созданию тестов на Robot Framework

Keyword Driven Testing – это представление тестовых скриптов, выраженное в синтаксических единицах языка — ключевых словах (keywords), которые могут соответствовать атомарному действию (щелчок мышью, нажатие клавиш и т.п.) или представлять собой целые скрипты, которые выполняют более сложные действия.

Несколько ключевых слов могут объединяться в действия (actions). В результате мы имеем возможность выражать тестовые сценарии на высоком и, главное, понятном каждому уровне абстракции. При этом разработкой ключевых слов может заниматься один или несколько программистов, а результатами пользоваться все, включая специалистов без глубоких знаний в программировании. Ведь достаточно легко составить сценарий, который проверит, например, создание клиента:

Add Customer ${customerId}
Check Client Exists ${customerId}

Test-driven development (TDD) — это подход к разработке и тестированию, при котором сначала создаются тесты, которым должен удовлетворять код, и только потом его реализация.

Behavior-driven development (BDD) — развитие подхода TDD к разработке и тестированию, при котором особое внимание уделяется поведению продукта в терминах бизнеса. Такие тесты проверяют различные сценарии, которые интересны непосредственно клиенту.

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

Но, как было отмечено выше, в нативных библиотеках могут отсутствовать необходимые функции или имеющейся функциональности будет недостаточно для выполнения тестирования. Тогда можно самостоятельно реализовать необходимую функциональность в виде своей библиотеки. Например, в нашем случае нам было недостаточно функциональности при работе с базой данных, поэтому необходимую функциональность мы реализовали в Java коде, который и подключался в виде библиотеки к проекту.

IDE для работы с Robot Framework

RIDE. Является собственной IDE для работы с RF, установка простая и понятная, могут быть проблемы при установке на 64-битной версии ОС, но всё решается установкой соответствующей версии wxPython. Кроме этого, в этой среде можно удобно отлаживать тесты.
Eclipse plugin. Про удобство и стабильность работы в Eclipse ничего не могу сказать, т. к. основная IDE — это IntelliJ IDEA, но возможно кому-то пригодится.
Sublime plugin. Установка плагина будет описана ниже по тексту статьи.
IntelliBot. Достаточно удобный плагин, но последнее обновление было более 2-х лет назад (01.06.2016).
Robot plugin. Ничего примечательного не могу сказать, последнее обновление было несколько лет назад.
Robot Framework Support. Пользовался исключительно данным плагином, всё удобно и понятно, а самое главное — прилетают обновления.
Run Robot Framework file. Используется для запуска теста из контекстного меню. К сожалению, не приходилось сталкиваться.

Установка плагина в Sublime Text 3

Для того, чтобы появилась подсветка синтаксиса .robot в Sublime Text, необходимо:

Если Sublime Text не установлен, скачиваем тут.
Запускаем Sublime Text и вызываем консоль управления плагинами сочетанием Ctrl+` или в меню «View > Show Console menu».
Выполняем Python скрипт, который добавит поддержку Package Control.sublime-package.
Вызываем командную строку для управления плагинами ctrl+shift+p и вводим Package Control: Install Package.
В открывшемся окне ищем Robot Framework Assistant.
Перезапускаем Sublime Text и наслаждаемся результатом:

Запуск и работа с тестами в Java

Хочу поделиться тем, как мы запускали тесты на RF в связке с Java, постараюсь отразить некоторые моменты использования, которые могут пригодиться, на примере Maven проекта.

1. Для начала мы добавили зависимости RobotFramework и Javalib-core нужной версии в pom.xml. После чего на Java выполнили разработку методов-кейвордов, при этом кейворды чаще всего относились к бизнес-логике тестируемого продукта, а значит были уникальными, но встречалось и дублирование функций существующих в стандартных библиотеках.

2. Структура проекта имеет следующий вид:
./
├───library — хранятся все библиотеки проекта;
├───resource — настраиваемая конфигурация, файл с импортом библиотек;
├───run — директория со скриптами и результатами выполнения тестов;
├───test — директория с .robot файлами (тестами);
└───variable — статичные переменные.

Для запуска использовался скрипт:

3. Импорт методов был реализован через вспомогательный файл, в котором указывали какие библиотеки и переменные подключаются:

4. Запуск осуществляли уже при помощи скрипта:

run -s %suite_name% или run -t %test_name%

5. После чего получали готовый отчёт виде html страницы, который можно открывать в любом браузере и наслаждаться результатами или ломать голову, почему всё не работает и главное — кто всё сломал.

Интеграция Robot Framework с CI

Jenkins

При интеграции с Jenkins не должно возникнуть проблем из-за того, что имеется плагин, который упрощает интеграцию.

Необходимо добавить в Jenkins плагин Robot Framework Plugin.
Добавить конфигурацию для запуска тестов. У RF есть полезная функция: возможность перезапускать провалившиеся тесты, а так как на практике некоторое количество тестов может оказаться нестабильным, из-за различных проблем, мы реализовали bash скрипт, при помощи которого выполняется перезапуск провалившихся тестов:

Что происходит в данном скрипте:

Проверяем атрибуты командной строки и сохраняем в переменную $outputDir имя целевого каталога — данное решение использовали из-за того, что может запускаться разное количество сьютов или тестов в одной Job и порядковый номер аргумента с целевым каталогом может отличаться в разных случаях.
Выполняем запуск тестов (скрытые строки 19-25).
Получаем количество упавших тестов из xml файла с результатами, если количество отлично от 0, перезапускаем упавшие тесты. После чего мержим результаты дополнительного прогона с основным (скрытые строки 34-44). Стоит отметить: в плагине есть ошибка, из-за чего в Jenkins на странице с результатами количество успешных тестов может не совпадать с фактическим количеством.

3. Выбрать в шаге после сборки Publish Robot Framework Result и указать директорию с файлом output.xml:

4. Запустить тесты и дождаться окончания. При этом при попытке просмотреть отчёт в Linux системах очень вероятно вместо отчёта получить такой результат:

Пугаться не стоит, всё дело в том, что на уровне системы нельзя выполнять скрипты, а сам файл отчета содержит большое количество скриптов. Для устранения данной проблемы достаточно открыть консоль сценариев Jenkins и выполнить:

System.setProperty(«hudson.model.DirectoryBrowserSupport.CSP»,»sandbox allow-scripts; default-src ‘none’; img-src ‘self’ data: ; style-src ‘self’ ‘unsafe-inline’ data: ; script-src ‘self’ ‘unsafe-inline’ ‘unsafe-eval’ ;»)

Работать данное решение будет до первой перезагрузки сервера. Если нужно постоянное решение, лучше вынести в настройки переменных окружения:

JENKINS_JAVA_OPTIONS=»-Djava.awt.headless=true -Dhudson.model.DirectoryBrowserSupport.CSP= «
или добавить в секции <arguments> в файле jenkins.xml
“-Dhudson.model.DirectoryBrowserSupport.CSP=»default-src ‘self’; script-src ‘*’; connect-src ‘*’; img-src ‘*’; style-src ‘*’;»

TeamCity

Настройка тоже не должна вызвать особых трудностей:

Отчёт необходимо генерировать в виде xunit, для этого необходимо выполнить запуск тестов с флагом -x %имя_отчёта%.xml.
В настройках проекта: Build Features->XML report processing -> Ant Junit -> указать путь до сгенерированного отчета.

Подробнее можно почитать в статье.

Отмечу, что отчеты RF можно интегрировать в любую CI-систему, если она поддерживает публикацию JUnit.

Выводы

Robot Framework представляет собой достаточно мощный и не слишком сложный в использовании инструмент, который при правильном применении позволяет добиться впечатляющих результатов практически без дополнительных затрат. При сравнении его с другими фреймворками может показаться, что он тяжелый и неповоротливый, неудобный.

Но существует ли идеальный проект, который подойдет всем и каждому и при этом не будет перегружен? Несомненным преимуществом использования RF, я считаю, является наличие большого количества библиотек и активное сообщество.

Присмотритесь к нему, кто знает, возможно, он пригодится и вашему проекту. При грамотном применении, конечно, а иначе можно начать забивать гвозди микроскопом. Но это тема отдельной статьи.

Полезные ссылки

Документация по Robot — http://robotframework.org/robotframework/#user-guide
Wiki на code.google — https://code.google.com/archive/p/robotframework/wikis/DocumentationIndex.wiki
Параллельный запуск тестов — https://github.com/mkorpela/pabot