автоматизирование тестирования, тестирование GUI - для QT, есть что опенсорсное?

[Denjs]

 Господа, подошел вплотную к вопросу о необходимости автоматизированного тестирования собственного приложения.
Т.к. пишу на QT тут вроде и QTestLib framework от Троллей Нокии предлагается... но нет там автоматизации тестирования.

Интересует a-ля RationalRobot но опенсорсное, желательно заточенное под QT. Возможно с необходимостью встраивания в программу.

Мне нужно что :
1) запись действий пользователя, возможность проигрывания действий пользовтаеля.
2) составления сценария тестирования на основе записанных действий пользовтеля. (для автоматизации тестирования GUI и функциональных требований)

естственно, желательно кроссплатформенное ^_^)

Собственно и собираюсь применять это для 2-х целей
- ведение полного лога всех действий пользователя (т.е. часть что бы никто из юзверей не смел пищать что "последовательность дейтсвий установить не удалось")
- автоматизация тестирования (проигрывание набора действий в пользовательском интерейсе с проверкой в ключевых местах до первого сбоя).

Пока думаю/пробую варианты создания собственного фреймворка.
Перехватывать глобально QEvent я научился, идентифицировать виджеты тоже (пусть и через необходимость именования всей цепочки от родителя до подчиненного).... - т.е. логи действий в GUI у меня теперь могут писаться, и вроде есть вся информация о том, что бы проиграть это все (клавиатура и мышь)... и QtScript тут вроде вообще очень к делу....
... но пока не начал погружаться в это полностью - хотел бы в последний раз оглядеться.... может и не надо мне это делать? может есть на что посмотреть, что обсудить, что поприменять?
Какие грабли могут меня ждать на данном пути?

[SASA]

http://www.froglogic.com/

[eugene]

интересно почем?

[vipet]

фролоджик стоит дохрена

[Denjs]

http://www.froglogic.com/

гы) вкусно конечно)
особенно "object picker", браузер  по свойствам и выхватывание структуры из DOM для отображаемого текста... )))  интересны также методы языка для скриптования действий...
в общем спасибо за ссылку, они круты, буду учиться глядючи на них и их фичи запомню, но денег не дам...
во первых самому пока мало....
да и эклипс мне не нравиццо, ....
в третьих я не уверн что могу встроить его в своё приложение для мониторинга действий пользователя на его стороне.

ещё варианты?

[Denjs]

Маленький анонс можно?


 (^^^^ кликабельно, ссылка на "Йю-ТюбЪ")

Анонс опенсорсной компоненты для автоматического тетстирования GUI для приложений на базе Qt4 - QDroid`s QDRTestMaster.

Компонента является расширением (плагином) скриптового фреймворка QDroid и будет включена в состав следующего релиза QDroid.

Работа компоненты продемонстрирована на примере "стандартной" графической оболочки для QD4ORM - orm-фреймворка для Qt4. В настоящее время тоже готовится к релизу.

Надеюсь до нового года (т.е. до конца 2010) - все будет)

В общем "потыркавшись" и не найдя ничего интересного, начал делать своё)))
Компонента работает только с Qt4-приложениями (перехватываются события QCoreApplication) и требует адаптации самого приложения (сейчас это интеграция в приложение фреймворка-QDroid - для работы компоненты требуется "скриптовая обвязка" которая загружает и запускает компоненту, обрабатывает её события, ведет лог успешности проведения тестов-проверок и т.п.)

В настоящее время ведутся работы по "допиливанию к релизу".
Могу предоставить компоненту заинтересованным.

Анонс делаю в надежде услышать вопросы и пожелания о фичах подобной системы - возможно успею что-то сделать)))
ну и конечно услышать мнение общественности о востребованности такой компоненты)))

[AlekseyK]

Очень нужно!!! Есть уже успехи?

[Denjs]

на текущий момент это скорее заготовка.

есть следующие возможности, ограничения и свойства:

Ограничения :
* тестируемое приложение - только Qt-Based - т.е. без включения не-qt виджетов.
* тестируемое приложение должно самостоятельно подключить внешнюю "динамическую" библиотеку libqdroid (библиотека скриптового фреймворка QDroid)
* приложение должно самостоятельно запросить у libqdroid на исполнение обслуживающий скрипт компоненты тестирования (скрипт загрузит компоненту тестирования, подключится к сигналам компоненты, будет выводить от четы о тестировании и пр).
* все виджеты вашего приложения должны быть проименованы (свойство objectName): все - от главного окна до последней кнопки - причем на всем пути подчинения от главного окна до дочернего. Виджеты идентифицируются строкой содержащей путь вложения виджетов (типа "mainwindow/frame001/buttonA")

Возможности :
* запись и воспроизведение событий:
(1) Клик мыши, движение мыши, нажатия клавиш (и комбинаций) - все адресуемое в тот или иной виджет Qt-приложения (только Qt-приложения. Нажить "пуск" с помощью моей компоненты не выйдет)

*  возможность добавить следующие тесты (или "проверки"):
(2) проверка виджета на наличие (выбираете виджет)
(3) проверка появления виджета с ожиданием (выбираете виджет который надо дождаться)
(4) проверка значения атрибута виджета (выбираете виджет, а потом из ниспадающего списка - набор обнаруженных свойств)
(5) проверка значения "атрибута по умолчанию" у виджета (выбираете виджет, система сама запоняет атрибут и берет текущее значение атрибута. Выбирается то значение, что отображается на экране. Поддерживается извлечение значений из ячеек QTreeWidget (с точки зрения окна - весь QTreeWidget - это один большой виджет без дочерних)

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

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

Трудности и минусы.
* записанная последовательность действий - это именно только последовательность событий или проверок в файле. Без ветвлений или циклов.
* нет никакой скриптовой обработки шагов - последовательность играется строго от начала до самого конца.
* редактирование записанной последовательности действий - только в ручном режиме, через правку текста файла.
 файл с событиями выглядит так:

Код:

 time=2010.09.30_14:11:42.468; action=          MouseMove; object=userLoginForm/userName_lineEdit; options=x=34 y=9 button=NoButton modifiers=0 glx=539 gly=495; 
 time=2010.09.30_14:11:42.687; action=          MouseMove; object=userLoginForm/userName_lineEdit; options=x=34 y=10 button=NoButton modifiers=0 glx=539 gly=496; 
 time=2010.09.30_14:11:42.703; action=          MouseMove; object=userLoginForm/userName_lineEdit; options=x=34 y=11 button=NoButton modifiers=0 glx=539 gly=497; 
 time=2010.09.30_14:11:42.765; action=          KeyPress; object=userLoginForm/userName_lineEdit; options=key=82 text=\\r modifiers=0 isautorepeat=false; 
 time=2010.09.30_14:11:42.781; action=          MouseMove; object=userLoginForm/userName_lineEdit; options=x=34 y=12 button=NoButton modifiers=0 glx=539 gly=498; 
 time=2010.09.30_14:11:42.890; action=          KeyRelease; object=userLoginForm/userName_lineEdit; options=key=82 text=\\r modifiers=0 isautorepeat=false; 

* не поддерживается перетаскивание.
* если у приложения есть модальные окна - могут быть проблемы при записи/проигрывании действий.
* интерфейс контрольной панели компоненты тестирования "не интуитивен". совершенно.


Вот собственно и все пока. Это увы - заготовка и не более. Если решитесь использовать это,  помогу чем могу, но вам надо будет вложиться в допиливание этого до нормальной программы. По моим оценкам - около 2-х недель минимум фул-тайм...  если что - пишите, буду публиковать актуальные исходники и будем думать как играться дальше.

Применять её у себя я так и не стал, потому что время выделенное на данную задачу вышло, а достаточно удобного инструмента я сделать не успел (как минимум правки скриптов не руками, "схлопывание" движений мышью при записи и пр.) а потом была смена работы и другая нагрузка...

[yuraborodin]

Приветствую, Denjs!
Меня тоже интересует этот вопрос. Нарыл кучу информации по тестированию GUI под Linux. Тестируемое приложение использует Qt.
Так воть сначала была идея использовать функции библиотеки X11 (с расширениями XTest, XRecord). Поэкспериментировал,  все работает, но с глюками и много еще нужно делать. Да и  функциональность не устраивает - отсутствуют функции верификации значений свойств и состояний элементов GUI. Способ снятия скриншотов и их сравнение с эталонами, либо использовать OCR - что-то рука не поднимается (хотя посмотрел кое какие инструменты - xvvidcap, OpenCV, tesseract).
Потом нашел коммерческий инструмент Squish. Интересно, каким образом Squish встраивает хук в тестируемое приложение? Подгружает динамическую библиотеку?, но ведь в таком случае в тестируемое приложение необходимо будет включить некий участок кода (заглушку), чтобы связать его с сервером Squish.
Я думаю вы уже читали концепцию Squish - (ссылка - http://doc.froglogic.com/squish/latest/all/tgs-concepts-web.html ), и там это наглядно показывается.
Далее нашел инструмент Hooq ( http://www.fredemmott.co.uk/blog/2010/01/18/Qt4%20GUI%20Testing%20with%20Hooq ) , инструмент для тестирования Qt приложений.
Поглядел на него - есть пара глюков, но работает лучше, чем при использовании X11 либы.
Эта прога загружает тестируемую прогу через GDB (для линуксовых прог), отладчик подгружает некоторые библиотеки, символы к ним, и библиотеку для перехвата событий класса QEvent. Главная программа тестирования общается с этой заглушкой хуком по протоколу tcpip. Все хорошо работает, но есть некоторые ограничения и глюки. Но нет возможности получить информацию о элементах на виджете - не перехватывая события нажатий  клавиатуры и мыши. Ну с этим все.

Мое мнение, что тестирование можно производить некоторыми способами:
1) реализовать некоторый интерфейс со стороны тестируемого ПО - для связи динамических библиотек тестирования с объектами тестируемого ПО.
2) использовать концепцию межпроцессного взаимодействия - чрез pipe, tcpip, dcop, d-bus, corba или свой как в 1ом пункте.
3) низкоуровневое программирование - через клики и ввод клавиатуры, а там анализ скриншотов или вывод результатов работы в файл(что упрощает анализ).

Меня интересует каким образом вы реализовали свой фреймворк. Судя по предыдущему посту, написали библиотеку, и тестируемое приложение подгружает его динамически, в этом случае нужно будет в код проекта включать заглушку для связи с библиотекой (мне кажется что в Squish тоже так? )

Жду ваших размышлений.

[Denjs]

Меня интересует каким образом вы реализовали свой фреймворк. Судя по предыдущему посту, написали библиотеку, и тестируемое приложение подгружает его динамически, в этом случае нужно будет в код проекта включать заглушку для связи с библиотекой (мне кажется что в Squish тоже так? )

по ссылкам пока бегать не пробежался... попозже попробую осилить. Спасибо, думаю там будет что интересного. Особенно за Hooq спасибо).

Моя реализация самая простая: : в большей части базируется на возможностях системы метаданных Qt.
Задача основного приложения - передать управление в библиотеку в функцию инициализации, и после возврата - оно(приложение) продолжает работать как будто никакой библиотеки тестирования нет.

Библиотека при инициализации, получает указатель QApplication::instance() и далее от него все и пляшет : ставится фильтр событий, получается список корневых виджетов приложения и пр.; полученные события фильтруются и записываются.
Проигрывание событий осуществляется через отсылку событий объектам.

Кстати, вот тут похожая тема затрагивается: http://www.prog.org.ru/topic_18620_0.html - но там хитрее - Пантер делает "прокси-прослойку-библиотеку" для QtGui4.dll - т.е. теоретически, можно работать с событиями любого Qt-приложения.

[yuraborodin]

Доброе время суток. Не мог бы кинуть ссылку на исходники по сабжу?

[Denjs]

Доброе время суток. Не мог бы кинуть ссылку на исходники по сабжу?

сабж идёт как расширение для QDroid и без него не работает (кто-то же должен обрабатывать сигналы и настраивать объект и пр? зато всё внутренности использования компоненты у вас доступны):
http://developer.berlios.de/project/showfiles.php?group_id=10448
смотрите снимок сорсов 2011.06.09_rev262 или более поздний
каталог "./qDroid_Bot_Hive/qdlib_testMaster"
не забудьте глянуть "./qDroid_Bot_Hive/qdlib_testMaster/scripts/libQDrTestMaster_start.qs" - это стартовый скрипт, который должны запросить на исполнение у ядра фреймворка методами библиотеки libqdroid.so/.dll . Пример работы с библиотекой - см "./qDroid_Bot_Hive/libqdroid.app" (просто шаблон как я помню) и "./qDroid_Bot_Hive/qdroid.shell.app"(консольная запускалка для скриптов. которая QDroid.****.exe или "/usr/bin/qdroid")

т.е. сценарий следующий: тестируемое приложение должно загрузить libqdroid, и сказать ему выполнить скрипт "libQDrTestMaster_start.qs".
далее приложение работает само по себе, а вы работаете с виджетом тестовой библиотеки (желтенький на верху поверх всего) сами.

ЗЫ: Извините за gui-интерфейс, он совершенно "not-userfrendly@", особенно в части запуска существующего сценария. Буду рад услышать пожелания, и принять доработки)))
ЗЗЫ: ещё libQDrTestMaster_start.qs может не заработать из-за ориентировки на устаревшие/несуществующие компоненты. увы, поковыряться в этом смогу не ранее чем через несколько дней.
ЗЗЗЫ: под линуксом, надо ещё поменять концы строк у .qs скриптов, иначе указание "!#/usr/bin/qdroid" не заработает. Ну и под линукс я пока это дело не тестировал, хотя проблем особых быть не должно.

[yuraborodin]

Ух Вы и написали там ЦЕЛУЮ систему  
Целый день разбирался. Пока разрбираюсь.
Наткнулся на грабли: вылетает в сегфолт через модуль libqdroid.app.bin

Код:

tosha@vbox:~/QDroid/qDroid_Bot_Hive/bin/lin$ ./libqdroid.app.bin libQDrTestMaster_start2.qs
[1] 
"application dir: [/home/tosha/QDroid/qDroid_Bot_Hive/bin/lin] 
" 
[2] 
"[0086]: <<lib /home/tosha/QDroid/qDroid_Bot_Hive/bin/lin/./qdroid NOT a library::Unknown error>> 
" 
[3] 
[0106]: <<lib  "/home/tosha/QDroid/qDroid_Bot_Hive/bin/lin/./libqdroid.so"  Loaded::  "Unknown error" >>  
 
[4] 
[0119]: <<OK : lib loaded succesfull:: lib filename [ "/home/tosha/QDroid/qDroid_Bot_Hive/bin/lin/./libqdroid.so" ]>>  
 
[5] 
[6] 
[7] 
main.c::0165: OK... function _setLogFile resolved. 
::: _setLogFile()= "/home/tosha/QDroid/qDroid_Bot_Hive/bin/lin/libqdroid.app.log" 
main.c::0165: OK... function get_counter resolved. 
::: _get_counter()= 0 
::: _get_counter()= 1 
::: _get_counter()= 2 
main.c::0179: OK... function init_run resolved 
lib:init_run()::0020 started... 
Segmentation fault
tosha@vbox:~/QDroid/qDroid_Bot_Hive/bin/lin$ 

Как понимать? Я подумал, что это имеет отношение к Вашему "ещё libQDrTestMaster_start.qs может не заработать из-за ориентировки на устаревшие/несуществующие компоненты."
Но ведь непосредственно (через qdroid интерпретатор) скрипт выполняется (появляется желтая полоска наверху с надписью QDroid...)!

[Denjs]

Ух Вы и написали там ЦЕЛУЮ систему  
Целый день разбирался. Пока разрбираюсь.
Наткнулся на грабли: вылетает в сегфолт через модуль libqdroid.app.bin
...
Как понимать?

Никак не понимать. Это пример, который не обовлялся и не проверялся на работоспособность уже давно. И по моему, он и не должен уметь запускать скрипт, переданный в параметрах командной строки. Это не qdroid.shell

Я подумал, что это имеет отношение к Вашему "ещё libQDrTestMaster_start.qs может не заработать из-за ориентировки на устаревшие/несуществующие компоненты."
Но ведь непосредственно (через qdroid интерпретатор) скрипт выполняется (появляется желтая полоска наверху с надписью QDroid...)!

В общем libqdroid.app.bin - это просто пример. Пример загрузки llibqdroid. Илюстрация того, что должно делать ваше приложение, если хочет загрузить libqdroid. Причем возможно устаревший пример. Не ждите от него сейчас ничего. Это просто "набор исходных текстов", "иллюстрация".
Я обновлю его и тогда уже будете думать над ним....

А вот qdroid.shell - это "весьма рабочая вещь". Я с ней каждый день сейчас практически работаю.

"ещё libQDrTestMaster_start.qs может не заработать из-за ориентировки на устаревшие/несуществующие компоненты."
Но ведь непосредственно (через qdroid интерпретатор) скрипт выполняется (появляется желтая полоска наверху с надписью QDroid...)!

то что расшиение загружается - это уже хорошо))) но ещё далеко не все.
Объект testMaster - обслуживается скриптом, который собират статистику удачных и проваленных проверок, выдает вам отчет и прочее. Отображать отчет - он вполне возможно захочет используя устаревшие функции некоторых компонент или компоненты которых нет в поставке QDroid... на в скидку не помню. хотя не должна, конечно.

[yuraborodin]

Пришлось попотеть, чтобы запустить тестмастер скрипт libQDrTestMaster_start2.qs через libqdroid.app.bin.
Описанный в прошлом моем сообщении сегфолт вылетал по следующей причине: не был передан указатель на QObject в функции  _init_run();
я поправил следующие строчки в libqdroid.app/main.cpp
//строка ~№141  
typedef QVariant (*TF_init_run) (QStringList,QObject* );//инициация движка и запуск скрипта
//строка ~№214    
qDebug()<< " _init_run(argList) =" << _init_run(argList,&app);

После  этого вроде заработало.

Далее несколько вопросов-проблем:

1. Неясно, что выполняет эта фича (да и кажется не функционирует): красный регион с словом "Свойства" при его наведении на каком-либо виджете?
С остальными проблемами разобрался(выбор виджета, установка свойств ObjectName, глюки с мышкой).

2. Обнаружил, что не реализованы запись драгдропов, контекстного меню, колесика и т.п. (QEvent::Wheel,QEvent::ContextMenu,QEvent::Clipboard,QEvent::DragEnter,QEvent::DragLeave,QEvent::DragMove,QEvent::Drop)
Попробую допилить это.
Но прежде надо что-то делать со тест-скриптом. Надо его, к примеру, преобразовать в скриптовую форму, хотя бы QtScript (в hooq так и реализовано). Есть какие идеи насчет этого?

3. Интерфейс. Согласен, абсолютно не дружественный, но не так все уже плохо.
 Я рассматриваю такой вариант:
-добавить в библиотеку тест_мастера передачу параметров режимов тестирования - 1) тестирование (проигрывание скрип тестов, и без панелей, выдача только окна отчета или его вывода в файл в требуемой форме) и 2) редактирование - запись, настройки и редактир. скриптов
-в режиме редактирования - небольшая панель с кнопками: запись/стоп, проиграть записанную последовательность (текущую записанную), настройки(организация тест-сценариев,пути,группы тестов,редактирование).

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

Вроде все.
Жду ответа!