Robot framework что это
Тестирование устройств с помощью Robot Framework
Robot Framework
Тестируемое устройство
32-разрядный CPU с тактовой частотой до 240 МГц
Для примера был создан Arduino-скетч, работающий следующим образом: ESP32 принимает данные по UART, при получении символа «1» контроллер зажигает светодиод (пин D2); при получении символа «0» светодиод отключается. Также в прошивке реализован BLE GATT-сервис с одной read-only характеристикой, которая содержит текущее состояние светодиода (подробнее про BLE GATT-сервисы можно прочитать здесь. Таким образом, управление светодиодом осуществляется через UART, а с помощью BLE можно узнать текущее состояние светодиода.
Исходный код скетча
Схема подключения плат в тестовом стенде:
Установка Robot
Для запуска тестов из данной статьи необходимо установить несколько пакетов:
Также для работы с внешними пинами понадобится утилита wiringpi, которую можно установить из репозитория Raspberry Pi OS:
Пример теста в Robot
несколько пробелов подряд (от двух и больше). В примерах в данной статье в качестве разделителя используются 4 пробела подряд
Некоторые ключевые слова возвращают значение, которое можно записать в переменную. Например, ключевое слово Set Variable используется для записи аргумента в указанную переменную $
Ключевые слова могут завершаться успешно (Success) и неуспешно (Fail). В случае, если ключевое слово завершилось неуспешно, тест-кейс, в котором произошёл вызов ключевого слова, так же завершается с результатом Fail. Например, ключевое слово Should Be Equal As Strings сравнивает строки, и возвращает Fail, если они не равны.
В Robot присутствует большое количество встроенных ключевых слов, также существует возможность создавать собственные ключевые слова в разделе *** Keywords ***.
Рассмотрим следующий тест-сьют в качестве примера:
Для запуска данного тест-сьюта надо сохранить его в отдельный файл и запустить следующей командой:
Как можно увидеть, Test Case Pass Example завершился успешно, а Test Case Fail Example завершился неуспешно. Узнать подробнее, на каком ключевом слове тест-кейс завершился неудачей, можно, посмотрев лог-файл simple_test.log:
Как видно из лог-файла, ключевое слово Should Be Equal As Strings во втором тест-кейсе завершилось с результатом Fail, т.к. переменная $ не равна Hello world.
Также в лог-файле можно увидеть, что при запуске тест-сьюта помимо исполнения ключевых слов, описанных в секции *** Test Cases *** вызывались ключевые слова из секции *** Settings ***: Suite Setup и Suite Teardown вызываются в начале и в конце тест-сьюта соответственно, а Test Setup и Test Teardown в начале и в конце каждого тест-кейса соответственно. Секция Setup используется для предварительных настроек необходимых для каждого тест-кейса, а Teardown для операций, которые необходимо выполнять в конце теста независимо от его результата (например, для закрытия программ запущенных внутри теста, или для удаления временных файлов).
Пишем тесты для embedded-устройства
Для проверки функций, реализованных в описанном выше скетче, напишем два тест-кейса: Test LED Switch On и Test LED Switch Off. Каждый из данных тест-кейсов будет содержать следующий сценарий:
отправка команды для включения/отключения LED («1» в первом случае, и «0» во втором) по UART (через USB)
проверка состояния светодиода с помощью чтения линии GPIO.0 на rPi
проверка значения GATT-характеристики с помощью BLE
Используем готовые библиотеки
Для начала напишем основу теста с использованием сторонних (будем использовать стороннюю библиотеку SerialLibrary для отправки команды по UART) и встроенных библиотек (будем использовать встроенную библиотеку Process для запуска утилиты gpio, которая позволяет читать состояние пина rPi).
Для включения/отключения светодиода нам необходимо создать ключевые слова, которые отправляют «1» либо «0» по UART. Для этого сначала необходимо в секции *** Settings *** подключить библиотеку SerialLibrary (Library SerialLibrary), а также вызвать на этапе Test Setup ключевое слово для конфигурирования последовательного порта (Open Serial Port). Непосредственно включение и отключение светодиода будет производиться ключевыми словами Turn LED On и Turn LED Off, внутри которых происходит вызов Write Data, реализованного в библиотеке SerialLibrary.
Для проверки состояния светодиода создадим ключевое слово, внутри которого происходит вызов утилиты gpio. Для запуска внешних программ в Robot есть встроенная библиотека Process. Для нашей задачи подойдёт ключевое слово Run Process, которое принимает на вход название вызываемой программы и передаваемые аргументы, а возвращает результат выполнения команды, в т.ч. вывод программы в stdout. Для чтения состояния пина GPIO.0 нужно вызвать gpio read 0, после чего проверить, вывела программа «1» или «0». Для сравнения состояния пина с ожидаемым будем использовать ключевое слово Should Be Equal As Integers.
В итоге у нас получился следующий тест-сьют:
Пишем собственную библиотеку
Исходный код библиотеки:
Итоговый тест проверяет корректность работы устройства, а именно: отправляет по UART команду на включение, либо отключение светодиода, проверяет корректность состояния светодиода в BLE GATT-сервисе и проверяет фактическое состояние светодиода с помощью чтения состояния GPIO-пина. Оба написанных тест-кейса проходят успешно:
Заключение
Тестирование в сфере embedded-устройств несколько сложнее, чем тестирование чисто программных продуктов, т.к. требует создания отдельного тестового стенда для подключения к внешним интерфейсам тестируемого устройства. Но решение этих сложностей окупается уменьшением ошибок в выпускаемом продукте и возможностью контролировать качество в процессе разработки и поддержки устройства. За рамками данной статьи осталось множество вопросов, связанных с тестированием в embedded, например: автоматическое тестирование железа без цифровых интерфейсов, интеграция Robot Framework в Jenkins, подключение измерительных приборов к тестовому стенду и т. д. Но, надеюсь, что этот короткий обзор возможностей Robot-а поможет embedded-командам по крайней мере начать применять практики автоматизированного тестирования в своих разработках.
Мой опыт знакомства и работы с Robot Framework
Чуть более года назад я впервые попробовал в работе Robot Framework. За время моего участия в довольно масштабном проекте я испытал на своей шкуре два разных подхода к автоматизации тестирования с помощью этого инструмента: написание тестов на чистом DSL Robot Framework и работу в связке с Python. Если первый путь имеет низкий порог входа, то второй, на мой взгляд, удобнее с точки зрения поддержки крупных проектов. Хотя фундаментальной разницы между подходами нет. Так или иначе, все сводится к поиску библиотек.
Однако об особенностях подходов поговорить стоит.
Кто такой Robot и с чем его едят
Наверное, стоит начать с представления этого мощнейшего инструмента.
Robot Framework – это фреймворк для keyword-driven-тестирования. Он используется для автоматизации приемочного тестирования и ATDD (подхода к разработке через приемочное тестирование). Эта система имеет простой в использовании синтаксис тестовых данных и позволяет автоматизировать тесты с использованием ключевых слов. Кроме того, у Robot Framework есть отличные встроенные и сторонние библиотеки, позволяющие без изобретения собственных велосипедов быстро начинать и встраивать автоматизацию в рабочие процессы – тот самый низкий порог входа, о котором я говорил выше.
Основная структура Robot Framework реализована с использованием Python и работает также на Jython (JVM) и IronPython (.NET).
Примеры использования, а также полную документацию по фреймворку и внутренним библиотекам можно найти на официальном сайте проекта: http://robotframework.org/.
Мои первые шаги. Подход первый
Впервые с Robot Framework я столкнулся год назад, после смены места работы. До этого мне доводилось автоматизировать только на Java и C#.
Выбирая для себя инструментарий, с которым придется разбираться в существующих тестах, я опросил новых коллег на тему их предпочтений. Единого мнения о лучшей IDE для работы с Robot Framework у них не было. В основном работать с Robot Framework позволяют плагины для различных текстовых редакторов и IDE, типа PyCharm. И собранные мной рекомендации разделились 50/50 между Atom и PyCharm. Конечно, есть RIDE, но это не панацея. На тот момент (год назад) я не нашел по ней нормальной документации, а в той, что нашел, не увидел каких-то больших плюсов для своей задачи. Поэтому для начала решил попробовать Atom с плагинами. Клонировав репозиторий, стал потихоньку изучать, что же происходит в наших тестах и в самом Robot Framework.
Меня подключили к проекту фактически на все готовенькое. Там уже работала связка Jython + Robot Framework, была собрана огромная кодовая база (написанная на самом DSL Robot Framework) из более чем 1000 тестов и нескольких тысяч строк кода вспомогательных библиотек на Java.
Как я понимаю, когда проект начинался, т.е. еще до моего прихода в отдел, над ним в основном работали специалисты по Java, да и сам тестируемый продукт был на Java, поэтому, выбирая подход, ориентировались на имеющиеся ресурсы. В целом расчет был примерно такой: решив некоторые проблемы, связанные с интеграцией Robot Framework и Java (в основном из-за того, что Java – компилируемый язык, а тот же Python и тесты в связке Python + RF – интерпретируемые), можно было потом легко привлекать сторонних специалистов, знающих только DSL Robot Framework, и спокойно писать тесты на кейвордах. Правда, коллегам пришлось затратить довольно много усилий в создание библиотек на Java, поэтому без условий со стороны заказчика они такой путь рекомендовать бы не стали.
Проделав небольшой рефакторинг, в рамках своей первой задачи я впервые запустил тесты. Поскольку использовалась связка Jython + RF, все собиралось maven, а robot-файлы просто копировались в target-директорию для последующего исполнения.
Рефакторинг затронул большое количество тестов, поэтому первый прогон занял минут 15. После его окончания пришло время взглянуть на отчеты, предоставляемые Robot Framework.
Стандартный отчет (на скриншоте выше) состоит из файлов report.html и log.html:
Плюс в том, что выводом можно управлять: есть разные уровни логирования, определяющие, какая информация выводиться будет, а какая нет. Уровень можно настраивать хоть для каждой строки по отдельности через метод встроенной библиотеки. При этом не лишним оказывается знание порядка выполнения вызовов внутри теста и вспомогательных библиотек – проще отловить момент ошибки.
Используя в качестве основного средства DSL Robot Framework, мы проработали около полугода. За это время я из личных предпочтений перешел с Atom на VSCode, но сути подхода это не меняло.
Однако проект развивался. В финальной итерации вспомогательная библиотека для работы с БД насчитывала 6700 строк кода на чистом Robot Framework. При таких масштабах кодобазы ее стало сложно поддерживать – на рефакторинг требовались ресурсы, которые не были выделены.
Финальное слово в применении первого подхода принадлежало бизнесу. Заказчик нашего проекта вел работу и с другими командами над смежными задачами. В одном из параллельных треков он увидел, с его точки зрения, более результативный и наглядный именно для менеджмента вариант использования Robot Framework, который и начали внедрять.
Подход второй
Второй подход представлял собой разработку тестов на Python в связке с Robot Framework. Вместо того, чтобы создавать все на синтаксисе DSL Robot Framework, мы начали писать вспомогательные библиотеки и прочие низкоуровневые взаимодействия с тестируемым продуктом на Python. А Robot Framework, по сути, становился просто раннером.
Поскольку Python – чистый высокоуровневый язык, а не DSL, тут больше возможностей по структурированию, легче во всем этом разобраться. Как минимум, можно использовать IDE для Python, которая поможет найти одинаковые методы (они делают одно и то же, но называются по-разному) или даже часть кода за тебя напишет. Какие-то данные можно было оборачивать в генераторы, на функции навешивать декораторы и т.п. На этом фоне инструментарий первого подхода (чистого Robot Framework) выглядит довольно сурово – по сути, то был «Блокнот» с подсветкой синтаксиса. Никаких тебе сеттеров или геттеров, которые IntelliJ пишет за тебя. Так что я был рад вернуться к высокоуровневому языку. Работа с данным подходом больше похожа на обычную разработку. Правда, есть и ложка дегтя. Без дополнительных плясок понять, что упало внутри Python, вызванного из RF, невозможно.
Потихоньку начали писаться первые тесты и вспомогательные библиотеки для нашей подсистемы. За то время, что мне довелось работать с новым подходом, я ощутил, что с другим инструментом действительно появляется больше возможностей. Но по сути написание тестов не сильно видоизменилось. В данном конкретном проекте внутри Python-кода все равно вызывались методы встроенных библиотек Robot Framework. Это было связано с особенностью требований заказчика к разработке тестов. Мы просто отделили исполняемую часть от алгоритма тест-кейса.
А что лучше?
Лично мне по душе второй подход. Однако выбирая путь своего проекта, стоит отталкиваться от задачи – кто и как пишет тесты.
Как я уже говорил выше, Python (второй подход) дает больше возможностей, однако в этом случае на проекте необходимы люди, знакомые с этим языком. Сам по себе Robot Framework (и первый подход) менее требователен – к нему можно подступиться, прочитав официальную документацию по его DSL. Уже после изучения user guide можно создавать любые тесты – они будут выглядеть довольно чисто.
В итоге Robot Framework и то, как мы его использовали поначалу, больше подойдут вчерашним ручным тестировщикам без явного опыта программирования на языках высокого уровня. Написать тест сможет даже человек, не сильно причастный к программированию, просто вызывая необходимые ключевые слова.
Однако если хочется по примеру нашего проекта держать исполняемую часть отдельно, а заодно рефакторить код в дружелюбных IDE, второй подход – для вас.
Robot Framework для автоматизации тестирования: ограничения и плюшки
В автоматизации тестирования я уже более 11 лет. Скажу сразу, что являюсь поклонником старомодного тестирования на Java и очень настороженно отношусь к различным готовым фреймворкам. Если вы придерживаетесь такого же мнения или только задумываетесь об использовании Robot Framework, в этой статье я постараюсь рассказать вам о его ограничениях и, конечно же, опишу все его достоинства.
Я столкнулся с Robot Framework около года назад. Перед нами стояла задача силами двух инженеров автоматизировать довольно большой объем тестов в сжатые сроки, т.к. ручная регрессия перестала влезать в разумные рамки. Сам проект связан с пожарной безопасностью. Тестировать предстояло Web-часть в трех браузерах и Mobile-часть на множестве iOS и Android телефонов и планшетов. Помимо этого, в наличии были тесты, которые взаимодействовали и с Web, и с Mobile. Конечно, это не ракету построить, но и не совсем тривиально. Честно скажу, я сопротивлялся, мы долго думали и в итоге, по совокупности внутренних и внешних факторов, выбрали Robot Framework.
Пара слов и картиночек для знакомства с Robot Framework
Прежде чем разбирать плюсы и минусы, давайте очень коротко поговорим о том, что же такое Robot Framework. Возможно, кто-то впервые видит это название.
Robot Framework – это keyword-driven фреймворк, разработанный специально для автоматизации тестирования. Он написан на Python, но для написания тестов обычно достаточно использовать готовые ключевые слова (кейворды), заложенные в этом фреймворке, не прибегая к программированию на Python. Нужно лишь загрузить необходимые библиотеки, например, SeleniumLibrary, и можно писать тест. В этой статье я дам общее представление о Robot Framework, но если после прочтения вы захотите углубиться в тему, то советую обратиться к официальной документации. В конце статьи также приведены ссылки на популярные библиотеки.
Что ж, перейдем к «картиночкам». Вот так может выглядеть простой проект в IDE (на примере всеми любимой Википедии):
Синий и зеленый – папки с файлами для описания страниц и тестов соответственно. Так можно реализовать page object паттерн.
Коричневый – драйвера для различных браузеров.
Красный – тело теста.
Желтый – консоль, из которой можно запускать тесты и видеть консольные сообщения (полноценные логи не тут, но об этом позже).
Как видно, в тесте сплошные «обертки» в стиле BDD (можно не применять такой синтаксис, но лично мне он тут кажется удобным). Имплементация находится в объектах страниц, например:
В стандартной секции Settings мы видим подгрузку библиотеки для работы с Selenium, а в другой стандартной секции Keywords находятся имплементации наших самописных ключевых слов.
Думаю, для получения общего представления этого достаточно. Детальное описание работы с Robot Framework лежит за рамками моего поста
Плюсы и минусы
В этой части я расскажу о плюсах и минусах Robot Framework, с которыми столкнулась наша команда. Учитывая специфику задач на проекте, наверняка у вас будут и свои «подводные камни». Я буду перечислять, двигаясь, на мой взгляд, от более значимого достоинства/недостатка к менее значимому.
Плюшки
Низкий порог входа
Как я уже писал выше, Robot Framework является keyword-driven фреймворком, а не языком программирования. Хоть синтаксис и схож с Python, знаний программирования требуется несколько меньше или, скажем так, их применение не обязательно там, где это позволяет сложность самой задачи. Однако, при необходимости можно пользоваться переменными, циклами, функциями, возвращающими значения, и т.п. Ближайшими альтернативами могут показаться Pytest и Selenide, но они требуют большей подготовки пользователя, нежели Robot Framework. Например, одной из встроенных стандартных библиотек является BuiltIn. Там вы можете найти такие кейворды как Sleep, Log, Run Keyword If, Should Be Equal As Strings и т.п. и написать что-то вроде:
Run Keyword If ‘$
Поддержка Web и Mobile
Robot Framework неплохо работает в связке Mobile+Web (как end-to-end, так и атомарные тесты).
Наши Web тесты работают с Chrome, FF и IE. Мобильная часть работает как с локальными реальными устройствами на Android и iOS, так и с устройствами с фермы SauceLabs. Ограничение – реальное локальное iOS-устройство можно тестировать только с Mac. И вообще iOS требует гораздо больше внимания, ведь тот же веб-драйвер для него надо пересобирать самостоятельно. (Тестирование iOS – это отдельная большая тема, и если интересно, дайте знать в комментариях, мне есть о чем рассказать)
Есть возможность задавать тестам тэги. Тэгами может быть любая информация, которая пригодится нам для идентификации теста: ID теста, список компонент, к которым относится тест, и т.п. Этим мы обеспечиваем связь тестов с тестами или требованиями (traceability) и задаем необходимую информацию для конфигурирования запуска тестов. Указав в запускалке один тэг, мы можем запустить все тесты, которые относятся к определенному компоненту, или же можем при запуске явным образом перечислить тест-кейсы, которые надо запустить (удобно при регрессионном тестировании). Подробнее про тэги по ссылке.
Хорошие отчеты из «коробки»
Для предоставления стандартной отчетности ничего придумывать не надо. Отчеты создаются автоматически без единой дополнительной команды. Есть возможность объединения результатов разных тестовых прогонов. В результате прогона по умолчанию создаются три файла:
Output.xml – результаты тестов в формате XML. Пригодятся для мерджа результатов командой rebot. Пример:
Log.html – подробные результаты в HTML-формате. Полезны больше для разработчиков тестов. Пример:
Report.html – высокоуровневые результаты без подробной детализации. Полезны для демонстрации людям «со стороны» и менеджменту. Пример:
BDD из «коробки»
Синтаксис Gherkin языка с его нотациями Given, When, Then и And включен по умолчанию, и любой шаг может быть записан как в этой нотации, так и без нее. Можно использовать нотации или нет – тесты просто игнорируют их. К примеру, эти два кейворда с точки зрения фреймворка идентичны:
Welcome page should be open
And welcome page should be open
Page Object паттерн
On Main page on Users tab I click Create user icon
где кейворд “On Main page on Users tab I click Create user icon” хранится в отдельном робот файлике, скажем, с названием mainPage.robot. Этот файлик мы подгружаем в наш файл с тестами по необходимости.
См. также пример из секции «Пара слов и картиночек для знакомства с Robot Framework».
Параллельный запуск
Параллельный запуск становится возможным благодаря альтернативной запускалке тестов под названием Pabot. Стандартным предустановленным способом является команда robot. Естественно, тесты должны быть на это рассчитаны и не должны влиять друг на друга
Грабли
Отсутствует возможность отладки встроенными средствами
Имеется ввиду классическая расстановка брейкпоинтов. Приходится либо выводить что-то дополнительное в лог, либо ставить временные слипы и так обходить эту проблему. В сети описаны некоторые способы прикрутить дебаг, но для уровня целевой аудитории Robot Framework это сложновато.
Не поддерживается AWS
AWS (Amazon Web Services – коммерческое публичное облако, ферма мобильных устройств) не поддерживает тесты на Robot Framework. AWS работает таким образом, что код исполняется на стороне Amazon, и тесты в формате Robot Framework не допустимы. Зато другая ферма, SauceLabs, устроена по другому принципу и прекрасно работает с Robot Framework (есть проблемы с администрированием их сервиса из России, но они решаются общением со службой поддержки или работой под VPN).
IDE сложности
RIDE (Robot IDE), специальная IDE для Robot Framework, мягко говоря, сырая. Режим работы в табличном виде (как раз для воплощения идеи keyword-driven фреймворка) выглядит так:
Режим работы в редакторе текста:
Ни в одном из двух предлагаемых режимов работать невозможно. Приложение периодически «падает» (хотя на других проектах такого нет). В режиме текста нет элементарного Go to Definition. В режиме таблиц Go to Definition есть, но сам этот режим крайне неудобен для средних и больших проектов.
PyCharm работает лучше, но, к сожалению, существующие плагины не справляются с автокомплитом некоторых библиотек (например, SeleniumLibrary)
Плохая поддержка сторонних библиотек
Готовые, уже существующие в сети библиотеки зачастую не поддерживаются. Пользователей мало, и они переходят в разряд зомби. Например, работа с почтой, сравнение скриншотов и т.п. Можно, конечно, написать свои библиотеки на чистом Python (и Robot Framework это позволяет), но смысла в такой схеме остается мало.
Справедливости ради стоит сказать, что нам для наших целей не пришлось писать ничего на Python и хватило добытых не без труда готовых библиотек.
Выводы
Выбор инструмента Robot Framework для нашего проекта был абсолютно верным и позволил выполнить наши обязательства в срок и с надлежащим качеством. Однако, надо понимать, что это, конечно же, не «серебряная пуля», есть много «но», которые надо иметь в виду.
Инструмент – это всего лишь средство для достижения поставленной цели, и не всегда надо микроскопом забивать гвозди, даже если это выглядит эффектно. Ругать или нахваливать Robot Framework я не берусь. Скажу лишь, что это хороший инструмент для своих целей