Я хотел бы услышать, как другие люди сталкиваются с Robot Framework для автоматического приемочного тестирования.
Каковы его основные сильные и слабые стороны, а также любое сравнение с другими структурами (в основном Fitnesse и Selenium)?
Код, который будет протестирован, - это код в реальном времени, устаревший код, в основном на С++.
Я использовал Robot Framework в трех разных компаниях, охватывающих около шести лет в то время, когда я пишу это, и все так или иначе были успешными.
Первое место, которое я использовал Robot, - это веб-приложение на основе Java для компании интернет-туризма высшего уровня. Мы использовали Robot с Jython, которые позволяют нам создавать ключевые слова на Java и непосредственно действовать с тестируемой системой. Мы использовали селен для управления веб-браузером, причем большая часть нашего тестирования находилась в Firefox. Хотя усилия по тестированию были в значительной степени успешными с организацией QA, организация развития не смогла охватить ее - они предпочли использовать JUnit, а не Robot.
Моя вторая компания, которую я чувствую, была безусловным успехом. Мы использовали Robot множеством способов. Первичное использование было для запуска IE для принятия и регрессионного тестирования очень успешного коммерческого веб-приложения .NET. Мы также использовали его для тестирования iPad-приложения, объединив селен с appium. Мы использовали Robot для тестирования служб RESTful, которые поставляли данные в приложение. Мы написали специализированные ключевые слова, которые позволяют нам проводить анализ изображений, а также мы использовали тесты Robot для быстрого анализа нашего обучающего оборудования перед каждой тренировкой. У нас были ключевые слова, которые позволяют нам делать снимки базы данных перед тестом и восстанавливать базу данных после теста.
Мы также начали использовать Robot для ручного тестирования. Мы поместили ручные тестовые примеры в Robot, что позволило нам использовать функции отчетности и меток Robot. Когда эти тесты будут выполняться, они попросят пользователя выполнить ручные шаги, которые оказались намного более эффективными, чем когда у нас были тестеры, которые читали инструкции вручную из инструмента управления тестовыми случаями или документа Word.
Третья компания была крупной компанией (доход за 1 доллар США) с довольно большим ИТ-персоналом. У них были тестеры с очень низким техническим мастерством (я помню тот, кто понятия не имел, что такое командная строка). У нас была одна команда, посвященная написанию основного набора ключевых слов, а также обучение и наставничество для других команд. Я думаю, что использование робота сыграло важную роль в использовании некоторых из менее опытных тестеров, хотя даже с ключевыми словами высокого уровня это была борьба с ними.
Совсем недавно я переехал в очень маленькую компанию с несколькими разработчиками и без специальных тестеров. Мы приняли использование объектов страницы с рамкой робота, и теперь у нас есть исключительно стабильный набор легко читаемых приемочных тестов высокого уровня. Использование робота в этой компании было безусловным успехом.
Самая большая сила робота - его гибкость. Мы использовали Robot для поддержки ручного тестирования, тестирования сервисов SOAP и REST, тестирования веб-интерфейса UI, тестирования базы данных, тестирования изображений и тестирования мобильных приложений. Поскольку робот настолько прост в распространении с помощью дополнительных библиотек, почти ничего не вы можете проверить, если вы готовы засучить рукава и написать несколько ключевых слов. В зависимости от вашей установки вы можете писать ключевые слова в Python, Java,.NET или на самом деле просто о любом языке через удаленный API Robot.
Поскольку тестовые примеры роботов и ключевые слова написаны простым текстом, вы не заблокированы для использования запатентованного инструмента для создания или просмотра тестов. Пользователи могут выбрать инструмент по своему выбору - Visual Studio, Eclipse, Emacs, Notepad и т.д. Существует также специальная IDE (RIDE) для роботов, хотя я ее не рекомендую. Кроме того, поскольку файлы представляют собой простой текст, они хорошо интегрируются с другими программными инструментами - их легко отличить и слить, искать и т.д.
Робот позволяет легко писать тесты низкого качества. Несмотря на то, что есть возможности документировать ключевые слова и тестовые примеры, а также использовать человекочитаемые имена для ключевых слов, тестовых примеров и переменных, нет хорошего способа обеспечить соблюдение лучших практик. Написание большого количества тестов и ключевых слов требует дисциплины. Как говорится, робот дает вам много веревки, чтобы повесить себя.
Еще одна слабость заключается в том, что темпы прогресса на роботе довольно медленные. С положительной стороны, Robot является надежным и относительно свободным от ошибок, поэтому нет необходимости в частых исправлениях. Тем не менее, есть запросы функций, которые томятся в своем журнале проблем в течение многих лет без движения, что может быть обескураживающим.
Во всех компаниях нам понравилось использовать гибкость, предоставляемую синтаксисом Robot, для создания тестов, управляемых данными, тестов стиля BDD, а также простых процедурных тестов. И во всех случаях, поскольку тесты представляют собой текстовые файлы, тестовые активы были легко управляемы с помощью наших инструментов SCM (Mercurial, Subversion, Git)
Для меня Robot оказался прост в использовании, чрезвычайно прост в распространении и полезен для широкого круга задач тестирования, от модульного тестирования функций python до тестирования веб-сервисов, интерфейса браузера и планшета тестирования, тестирования изображений, тестирования баз данных и даже повышения эффективности ручного тестирования.
Мы используем Robot Framework на моем месте работы уже несколько лет с умеренным успехом. Как и плакат, мы также работаем на С++. Мы потратили некоторое время на оценку робота против Fitnesse/Slim, и в то время оба решения были хорошими, но решающими факторами были (по состоянию на 2009 год):
С технической точки зрения мы использовали SWIG для соединения между Robot и С++. Мы завершаем наши тестовые светильники в SWIG и связываем их с тестовым кодом производства - предоставляем нам модуль python, который может быть импортирован роботом.
Мы используем формат .txt для ввода Robot почти исключительно - мы обнаружили, что эта версия лучше управляется, ее легче читать, и мы просто не использовали расширенные функции HTML (с чего мы начали). Кроме того, мы используем "BDD Style" . Синтаксис робота. Мы используем GoogleMock с некоторыми обертками, чтобы помочь нам установить ожидания, которые проверяются во время разгона каждого теста Robot.
Что касается организации тестов, мы остановились на следующем подходе (с вдохновением от подхода Дейла Эмери, приведенного здесь):
Например, у телефона может быть что-то вроде этого:
// PhoneProject/MakingCalls/DialAPhoneNumber.txt
*** Test Case ***
A user can dial a US number with an area code, up to 10 digits
Given a phone without any numbers dialed
Expect the attempted phone number to be 123-456-7890
When a user enters the numbers 1234567890
// A separate MakingCallsKeywords.txt or something similar
*** Keyword ***
Given a phone without any numbers dialed CreateNewDialer
Expect the attempted phone number to be ${phoneNumber} ExpectDialedNumber ${phoneNumber}
When a user enters the numbers ${numbersEntered} DialNumbers ${numbersEntered}
// MakingCallsFixture.cpp (which gets wrapped by SWIG)
std::wstring MakingCallsFixture::DialNumbers(const std::wstring& numbersEntered)
{
... Drive production code ...
}
// CreateNewDialer, ExpectDialedNumber also go here
Затем мы объединили бы это с модульными тестами, которые охватывают угловые условия (например, разрешено не более 10 цифр) - или, может быть, это будет еще один приемочный тест (исполняемый спецификатор) в зависимости от того, кто читает тесты и их знакомство с доменом.
Мы создаем проект этих спецификаций и проверяем экспертов домена и команду до начала работы. Это помогло устранить ряд недоразумений на раннем этапе.
Я использовал платформу Robot для следующих сценариев
тестирование пользовательского интерфейса
1. Рамка роботов действительно хороша для тестирования ui
2. Framework поставляется с редактором Ride, который можно использовать для написания тестовых примеров.
3. Вам не обязательно быть экспертом по командам селена и селена доступны для поиска в редакторе Ride.
4. Вы можете использовать общий код, используя ключевые слова и общие Ресурсы. Позволяет просто повторно использовать тестовые примеры и тестировать библиотечный код.
5 Вы можете легко вызвать функцию библиотеки python для выполнения более утомительных задач.
Для Тестирования служб я обнаружил, что платформа Robot немного сложна в использовании для автоматизации тестирования, которую я выполнял.
. Наш уровень обслуживания приложений полностью написан на C/С++. Я лично работаю на ноутбуке Windows и наше приложение находится на сервере Linux.
Я нашел инфраструктуру фитнеса гораздо более полезной и простой в автоматизации.
У Fitnesse были ниже упомянутые дополнительные функции, которые позволяли легко писать тестовые примеры. Я не мог найти похожие функции в Robot.
Таблица решений. Вы можете написать тестовые примеры в формате microsoft xls. Каждая строка в сетке данных будет представлять собой тестовый пример. Каждая строка будет иметь набор входов и выходов. Выходам будет предшествовать знак вопроса в заголовке.
Таблица запросов. Вывод теста будет списком данных, которые вы хотите проверить.
Также фитнес позволяет легко интегрироваться с другими языками, такими как C (используя Slim Service). Это не требует какого-либо интеграционного кодирования. Тест-тесты Fitnesse непосредственно выполняют испытательные приборы, геттеры, сеттеры.
Резюме моего опыта:
Нашел простой в использовании для автоматизации пользовательского интерфейса.
Обнаружено, что для автоматизации обслуживания это немного сложно.