Черно-серое тестирование REST API и пользовательского интерфейса

Question

Мы выбираем, какую систему автоматизированного приемочного тестирования начать использовать (переключить) в нашей компании.В настоящее время большинство серверных тестовых примеров написаны нашим бывшим тестировщиком на Python, и новым тестировщикам сложно использовать и поддерживать его;для пользовательского интерфейса мы используем Каркас робота.

Я хотел бы использовать что-то стандартное, чтобы новые "типичные тестировщики с улицы" могли начать использовать, и в то же время это должно быть достаточно гибким.

На моих предыдущих работах тестировщики использовали SoapUI или даже Apache JMeter с Groovy scripting, но по какой-то причине людям в моей нынешней компании это не нравится.

Мы рассматриваем Физическая форма или каркас робота.

Требования:

• его следует использовать как для серверной части (REST API, некоторые проверки базы данных), так и для тестирования пользовательского интерфейса
• он должен использовать простой язык, чтобы даже непрограммисты / тестировщики могли понять тестовые примеры (владельцы продуктов должны иметь возможность видеть, соблюдены ли все критерии приемлемости).
• он должен поддерживать интеграцию с Jenkins
• он должен поддерживать управление версиями тестовых примеров, чтобы для конкретной версии продукта мы также могли проверять соответствующие тестовые примеры прямо сейчас мы используем TestRail (test case management SW);поэтому было бы неплохо, если бы он интегрировался с ним (по крайней мере, его можно запрограммировать, чтобы отправлять туда результаты тестирования) или полностью заменяет его

Я просто быстро поиграл с Fitnesse, и для меня табличная форма выглядит довольно уродливо.Также на первый взгляд документ не очень хорош (я не нашел возможных "команд", напримерутверждения, некоторый цикл) и документация, напримеростальная установка еще хуже (отсутствует).

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

Есть какие-нибудь идеи, опыт?

Спасибо, Радек

PS:Я задавал этот вопрос также на форуме QA, но он гораздо менее активен, чем StackOverflow, так что извините за это дублирование.

Answer 1

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

1. Вы можете использовать единый инструмент (и, следовательно, единый формат отчетности) для МЫЛО- и ОТДЫХ-сервисы на основе проверки базы данных, тестирование пользовательского интерфейса на веб-основе, и даже тестирование настольных приложений.Он также может быть использован для интеграции и модульных тестов, хотя для этой работы часто существуют инструменты получше.
2. Вы можете использовать роботизированные тесты для реализации ручных тестов с помощью Диалоги библиотека или пользовательская библиотека.Я видел значительное ускорение производительности тестировщиков, когда они запускали ручные тесты, написанные в robot, по сравнению с аналогичными тестами, написанными в Microsoft Word.К сожалению, в Интернете мало написано об этой мощной функции, но вы можете получить такого же рода отчеты, контроль версий, пометки и т.д.функции для всех ваших приемочных тестов, как ручных, так и автоматизированных.
3. Если вы потратите время на создание хорошей библиотеки ключевых слов, тесты могут быть легко прочитаны (и записаны!) не тестировщиками
4. Существует плагин робота для jenkins это упрощает просмотр результатов тестирования
5. Наборы тестов Robot framework включают в себя обычные текстовые файлы, чтобы они могли быть версифицированы прямо вместе с вашим кодом.
6. Test output - это очень простой для понимания и анализа XML-файл.Он также может генерировать вывод в стиле xunit для интеграции с другими инструментами.Robot также поставляется с инструментами для преобразования этого xml-файла в понятные для человека журналы и отчеты.Тот Самый интерфейс прослушивателя позволяет легко записывать или транслировать результаты тестирования в режиме реального времени.
7. Растет число инструменты и плагины редактора которые работают с роботом, чтобы члены вашей команды могли использовать те инструменты, которые им наиболее удобны.
8. Робот - это очень расширяемый -- библиотеки ключевых слов могут быть написаны практически на любом языке - изначально на python, а также на java, если вы работаете с jython, или на языках .NET, если вы работаете с IronPython.И с помощью интерфейс удаленной библиотеки, вы можете написать ключевые слова на любом языке, которые могут открывать сокет и действовать как сервер.

Что касается приспособлений для тестов БД, то существует общий библиотека баз данных на основе Java, и общий библиотека баз данных на основе Python который может подключаться практически к любой общей базе данных.Существует также библиотека, специально предназначенная для общения с MongoDB.

В связи с вашим вопросом о управлении версиями, robot обладает очень мощным механизм маркировки это может оказаться вам полезным.Вы могли бы, например, пометить все тесты версией продукта, с которой они поставляются.Затем вы просто проверяете все, но не используете роботов параметры командной строки выбрать только тесты, помеченные определенной версией.В качестве дополнительного преимущества тегирования отчеты разбивают статистику прохождения / неудачи по тегам.

Робот - это не идеальная тестовая система, но она очень хорошая.Я бы сказал, что существует множество одинаково хороших тестовых фреймворков, но я не уверен, что есть какие-то объективно лучшие.Конечно, для перечисленных вами важных для вас вещей robot framework делает все, что вам нужно.

Answer 2

Я был в практичном сценарии ранее. Нам пришлось решить между РФ, Fitnesse и IBM STAF / Stax

Мы выбрали робот Framework, и она работала хорошо.

1. его следует использовать для обеих бэкэнда (API отдыха, некоторые проверки БД) и UI Тестирование - для отдыха, RF's Запросы Библиотека вместе с различными библиотеками БД могут использоваться вместе.
2. это должно использовать простой язык, поэтому даже не программисты / тестер могут понять тестовые случаи (владельцы продуктов должны видеть Открыты ли все критерии приемки) - РФ предназначен для именно это.
3. Он должен поддерживать интеграцию с jenkins - rf имеет a jenkins Плагин
4. он должен поддерживать версию тестовых случаев, так что для конкретного Версия продукта Мы также можем проверить соответствующие тестовые случаи прямо сейчас - RF Теги Функция будет хорошо работать для этого

Существует робот Framework API , так что это довольно программируется в соответствии с Требования к интеграции.