Кто пробовал работать с Systir?

[Dale]

Собственно, сабж. Кому-нибудь из форумчан доводилось работать с этим продуктом?

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

Ну и попутный вопрос: а какие инструменты вы используете для системного тестирования своих продуктов и с каким успехом?

[baldr]

Dale, проект на rubyforge.org не выглядит живым: дата July 7, 2006
Да и по сути - похоже просто надстройка над Test::Unit.

Для тестирования через веб-интерфейсы писал тесты на Ruby/Watir, правда сейчас этим не занимаюсь почти - но тесты работают. Пробовал WatiN, но он был сыроват. Сейчас у нас пытаются использовать Selenium.

[Dale]

.

Добавлено через 4 минуты и 50 секунд:

Dale, проект на rubyforge.org не выглядит живым: дата July 7, 2006

Уже посмотрел там. Но в более свежих статьях регулярно упоминается применение Systir, причем именно версии 0.5, да и на сайте Atomic Objects ссылаются как на поныне используемый инструмент. Есть надежда, что эта версия достаточно функциональна, хоть и давно не обновлялась.

Да и по сути - похоже просто надстройка над Test::Unit.

Да, разработчики упоминали об этом.

Для тестирования через веб-интерфейсы писал тесты на Ruby/Watir, правда сейчас этим не занимаюсь почти - но тесты работают. Пробовал WatiN, но он был сыроват. Сейчас у нас пытаются использовать Selenium.

Пожалуй, я задал слишком общий вопрос насчет системного тестирования, надо бы конкретизировать. Мне нужен инструмент для системного тестирования firmware микроконтроллеров, а если получится, то и оборудования. Вряд ли получится для этого приспособить web-инструментарий.

Может, есть аналогичные решения для десктопных приложений? Возможно, их будет проще приспособить, если с Systir Не получится.

[x77]

а как тестировать? посылать некие команды на контроллер и получать результат? тогда можно попробовать через QA TestComplete.

типичный сценарий работы:

1. указывается запускаемое приложение (в твоем случае, я так понимаю, то, что работает с контроллером
2. записывается тест (запоминаются все действия пользователя, т.е. нажатия на клавиатуру, мышу и др.)
3. создается чек-пойнт (т.е. сверка результата с неким эталоном)

ну и все. у меня на этой ботве работают ночные сборки, т.е. ночью выкачивается проект из CVS, собирается, на сборку натравливаются регрессионные тесты, утром я прихожу на работу и в почте нахожу письмо с результатами тестирования.

плюсы этой штуки в том, что она интегрируется в 10 языков программирования, любой тест можно сконвертировать в скрипт одного из четырех языков (VB, Delphi, Java, C#), можно использовать свои функции и процедуры.

может быть, его скриптовый язык позволит и с ком-портами  работать - не знаю, не проверял. если нет - придется писать свою прогу для контроллера, видимо. но при определенных условиях сборки (включение в экзешник отладочной информации, а также инфы для внешнего дебаггера TD32) TestComplete позволяет работать с тестируемым приложением не на уровне виндовых окон ("нажать на форме такой-то такую-то кнопку" или "ввести такой-то текст в такое-то поле ввода"), а на уровне полноценного объекта, используя методы и свойства, доступные в родной среде разработки.

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

если я правильно задачу понял, конечно.

[baldr]

Если спускаться на уровень тестирования пониже - на интеграционный (что имеет в виду x77) - то это будет как раз задача для hudson, например.

[x77]

baldr, не, хадсон - это наоборот уровень повыше, Continious Integration. подразумевает юнит-тестирование и блочные тесты, сборку, тестирование и развертывание по триггерам (на чек-ин файла с определенной меткой) и пр.

я говорю про простейшие тесты, не подразумевающие внедрения в тестируемый код.

Добавлено через 1 минуту и 12 секунд:
baldr, хадсон - это целая (_:_), тестить им микроконтроллер - это просто офигеть

[baldr]

x77, Dale говорил про системное тестирование, а это уровень выше AFAIK. Я просто прокомментировал идею насчет "ночных сборок".
Очевидно, что для уровня посылки команд придется писать какое-то свое приложение, выдающее интерфейс уровню выше.
А вот уже этот уровень может быть как TestComplete, QuickTest, Selenium или кто угодно...

[x77]

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

[Dale]

а как тестировать? посылать некие команды на контроллер и получать результат? тогда можно попробовать через QA TestComplete.
...
т.е. задача сведется к тому, чтобы некая приблуда отправляла и получала какие-то команды контроллеру. а дальше уже на основе TC писать тесты с использованием этой приблуды.

если я правильно задачу понял, конечно.

Парни из Atomic Objects пишут, что они присобачили к тестовому компьютеру специальный стенд, способный генерировать и считывать массу цифровых и аналоговых сигналов, и добавили в Systir средства для работы с ним. А дальше системное тестирование выглядит примерно таким образом.

Например, проверяется функция зарядки аккумулятора. На вход контроля напряжения контроллера со стенда по команде Systir подается напряжение, соответствующее разряженному аккумулятору. В ответ контроллер должен включить зарядный ток. Этот ток измеряется стендом, и Systir проверяет, что этот ток действительно соответствует ожидаемому.

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

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

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

[x77]

Dale, а в твоем случае, что будет являться стендом и нужен ли он там вообще? как контроллер к компу цепляется?

[Dale]

Dale, а в твоем случае, что будет являться стендом

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

и нужен ли он там вообще?

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

как контроллер к компу цепляется?

В общем случае - никак (нет необходимости). Ну или почти никак (через программатор). Хотя если в конкретной конструкции UART не задействован, я бы предпочел подключить его к виртуальному терминалу на отладочном компьютере, чтобы иметь возможность при необходимости выводить диагностику.

[x77]

Dale, то, что я имел в виду - TestComplete - это приблуда для тестирования десктопных приложений. ее основная прелесть в том, что она позволяет записать действия пользователя как неий макрос, и потом этот макрос воспроизводить и сравнивать результаты с неким эталоном. результатом может быть файл, часть файла, значение в БД, значение в поле ввода какой-то программы, и т.д.

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

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

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

[Dale]

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

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

Судя по статьям, в Atomic Object именно этому и научили Systir. Я видел их тестовые сценарии, они написаны прямо в примитивах предметной области: "подать 12 вольт на датчик напряжения", "проверить состояние индикатора ошибки" и т.д. Хотелось бы в итоге достичь чего-то наподобие.

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

То, что она для регрессионного тестирования, как раз только плюс - это означает лишь, что она работает быстро (или у нас просто разное толкование "регрессионности"). А вот если она жестко заточена на работу с GUI, то, возможно, это ограничит возможность ее использования для данной цели.

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

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

[x77]

ну тогда все упирается в стенд. вернее, в возможность им рулить с компа.

[Dale]

ну тогда все упирается в стенд. вернее, в возможность им рулить с компа.

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

Например, если система тестирования умеет делать ввод/вывод текста на COM, можно обучить стенд языку наподобие

Код:

SetU(1) = 12.2 // установить напряжение на аналоговом выходе 2
GetU(3) // считать напряжение с аналогового входа 3
SetPort(3, 1) = 1 // установить бит 1 цифрового порта 3

Тогда для конкретного девайса остается еще доопределить макросы типа

Код:

#define SetAccumVoltage SetU(1)
#define AlarmSoundOn SetPort(3, 1)

и т.п., и можно писать сценарии тестирования прямо на языке предметной области.

[x77]

я на работе проверю, можно ли к TC цеплять свои функции из dll, например.

[RXL]

Я вот читаю и немного не понимаю (особенно в свете предпоследнего поста): коли тестирование железа - вещь специфическая и нестандартизированная, а тесты прекрасно можно писать как обычную программу, то зачем нужен Systir и иже с ними? Только потому, что программу на скриптовом языке не нужно предварительно компилировать?

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

Код:

    SET_PPM 1 ; Установить выход сигнала 1.
    SET_TIMER CFG_1MS_TIMER_DELAY ; установить таймер на 1 мс.
    CLR_PPM 2 ; Снять выход сигнала 2.

Если где ошибка, то смотрим макрос и вызываемые им функции, а описание логики компактно и прозрачно.

[Dale]

...зачем нужен Systir и иже с ними? Только потому, что программу на скриптовом языке не нужно предварительно компилировать?

В основном да. Традиция - писать скрипты на интерпретируемом языке и выполнять немедленно, без промежуточных ступеней. Тем более что Systir основан на Ruby, а это достаточно мощный язык.

Ну и плюс инструмент хорошо интегрируется в общую систему CI, а для самописных тестовых программ придется это делать самому. Пусть и не слишком сложная, но все же лишняя работа.

[Sla]

в свое время писали тесты на Tcl\tk
условно скажем, заказчиком был вот этот "поц" http://www.elbrus.com/solutions/guitesting/detailed
история длинная и неинтересная
что получилось - получилась система скриптов, и gui
тесты - те же самые скрипты.

[x77]

Dale ТестКомплит тоже интегрируется в CI. если CI тот же хадсон - туда вообще все, что угодно можно синтегрировать, там сборка идет на ант-овских build.xml. Систир не видел, а вот ТС мне очень нравится. Писать можно на 4 языках, а не на одном, тест можно записать, как макрос, а потом преобразовать в скрипт и дописать в нужных местах логирование, скриншоты, проверку значений по БД и пр. в общем, это надо попробовать.

[Dale]

Спасибо, приму к сведению. Если с Systir'ом не прокатит, TC будет следующим кандидатом.