Автоматизированное интеграционное тестирование софта на Windows , Ищу методики и тулзы

[Radagast]

Не совсем подходящий раздел, но похоже на форуме нет раздела, посвященного QA/AutoQA.
Несколько дней назад я спросил тоже самое на StackOverflow, но стоящих советов так и не получил
Моя команда пишет desktop-программу (смесь С++/Tcl), которая работает в связке клиент-сервер. На данный момент она работает только на Windows, но скоро нужно будет портировать на Linux. CruiseControl.NET каждую ночь билдит сорцы из SVN, и создает инталлятор на NSIS, но не прогоняет никаких автоматических тестов.
Юнит-тестирование практически невозможно из-за особенностей архитектуры, но интеграционное тестирование может быть легко построено полностью на Tcl скриптах. На данный момент 90% ручного тестирования выглядит так: "Выберите скрипт N, нажмите Execute, дождитесь пока скрипт выполнится и проверьте, что никакие ассерты не зафейлились, поставьте галочку в отчете".
Автоматизированное тестирование должно работать так: установить программу на 3 компа, сконфигурировать её (там надо кое-какие файлы копировать итд), прогнать её, мониторить возможный креш, дождаться пока тестирование закончится, собрать отчет (такие-то тесты прошли, такие-то зафейлились), разослать email. Это всё можно сделать пачкой PowerShell скриптов, но
- В будущем мы захотим добавить больше и больше фич и тестирования, и то что начиналось как маленький скрипт, неконтролируемо разбухает. Так что я хочу минимизировать кол-во скриптов, и для тех моментов когда без них никак, я бы предпочел писать их на bash, а не на Python или Ruby, которых я не знаю.
- я хочу веб-морду, которая красиво будет показывать прогресс теста, и если что-то зафейлилось - красный цвет и прямой доступ к логам
- Нужен какой-то супервайзер, который будет мониторить программу и детектить, если она закрешится или повиснет
- должно работать и на Windows, и на Linux
- в идеале хотелось бы управлять распределенным на несколько компов тестом (напр. запустить тест А на компе 1 и (параллелльно) тест Б на компе 2, дождаться пока они оба закончатся, затем запустить тест В на компе 1 (который использует комп 2 как сервер), и мониторить если что-то закрешится на компе 2.

Так что я ищу инструменты и методы, которые помогут мне сделать всё это, и не слишком сложны в освоении. В идеале, бесплатные, но если попадется что-то хорошее, мы можем взять и лицензию. Хочется по максимуму использовать возможности CruiseControl.NET (бтв у кого-нибудь есть опыт его работы под Linux/Mono?), потому что доказать коллегам, что его надо выкинуть и поставить что-то нормальное вроде Jenkins/TeamCity будет очень трудно.
По минимуму, хочется удаленной установки софта и выполнения консольных комманд и веб-морду. Пока что нагуглил Ansible, SaltStack и STAF/STAX как потенциальных кандидатов, но еще не щупал.
Поиски по интернетам и StackOverflow в основном дают варианты, специфичные для web application, Java EE, Мавен итд.
Заранее спасибо.

Сообщение отредактировано: Radagast - 08.12.14, 11:44

[Qraizer]

Наши заказчики выбрали Jenkins. Вы им писали скрипты на него. Все довольны. Скрипты башовые, под виндой запускаются в цигвине. На предмет веб-морды не знаю, по удалёнке сложно судить. Распределение по разным компам не проблема, скриптование в руки, супервайзер аналогично.
Однако у нас юнит-тесты, в количестве >3000, гоняются в общей сложности ~10 часов. Что там у вас будет с интеграционными, понятия не имею. P.S. Я весьма скептически отношусь к любым фразам типа "юнит-тестирование практически невозможно из-за особенностей ...". Бывает трудоёмкое и потому не окупаемое, однако и тут всегда можно найти компромисс.

[Radagast]

Цитата

Распределение по разным компам не проблема, скриптование в руки, супервайзер аналогично.

Вот отдельно на тему супервайзера хотелось спросить. Знаю, что в PowerShell можно подписаться на ивент из Application log, о том, что что-то закрешилось. совсем хз как это сделать на баше. А есть какая-то кроссплатформенная тулза, которая и на Линуксе будет это мониторить? а в идеале еще и посылать какие-нибудь ивенты в мою прогу чтобы убедится, что GUI-поток отзывчивый.
В глубине души все еще тлеет надежда, что проблема-то распространенная, и кто-то где-то придумал толковый фреймворк, который мог бы взять всю рутинную работу на себя 2014 год на дворе, в конце концов

Сообщение отредактировано: Radagast - 08.12.14, 14:14

[Qraizer]

Это зависит от того, как тесты о фэйлах отчитываются. Наши тупо резюмируют в конце репорта

Number of test cases PASSED: XX
Number of test cases FAILED: YY

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

*** Test Step: Function XXXX returns the correct value *** FAILED ***
Under condition: actual -2114923695(0x81F0D351) expected -2084935125(0x83BA6A2B)

тоже не проблема.

[Radagast]

так если юнит-тест закрешился или повис, он совсем ничего не напишет в лог

[Qraizer]

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

Добавлено 08.12.14, 22:22
Кроме этого тесты могут писать в лог о различных аномалиях. Т.е. неких ситуациях, с которыми тест не должен был столкнуться, и это не относится к тестированию. Например, если у теста кончилась память. Или он столкнулся с невозможностью выставить предусловия для кейза, что может быть обусловлено изменением в производных требованиях, и тест должен был быть проапдейчен, однако его прощёлкали на регрешне.

[Radagast]

ясно, спасибо
еще такой маленький вопросик - есть ли в англоязычной терминологии (особенно аэрокосмической) устоявшийся термин для "идентификатора фичи", который нужен для того, чтобы связать требования клиента с возможностями продукта. Т.е. напр. приходит клиент с 700-страничным customer requirements, мы рядом кладем свой Test procedure, который демонстрирует, какие фичи есть у нашего продукта, и начинаем сопоставлять. В нашей конторе это назвали FunctionID, но мне кажется, должно быть что-то поумнее

[Fester]

Цитата Radagast @ 09.12.14, 07:57

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

use case ?

Добавлено 09.12.14, 08:13
Если бы не линукс, то я бы предложил использовать MS Test Manager в связке с TFS

[Radagast]

имхо "use case" это больше из мира Agile, а у меня тут 100% waterfall. И Use case афаик описывают несколько шагов, а наши FunctionID выглядят примерно как:
"Если значение параметра телеметрии превысило значение определенное в таблице Х, нужно автоматически запустить скрипт из таблицы Y"

[Fester]

Цитата Radagast @ 09.12.14, 09:28

имхо "use case" это больше из мира Agile, а у меня тут 100% waterfall.

какая разница?
"use case" можно дословно перевести как "вариант/способ использования".

Цитата Radagast @ 09.12.14, 09:28

И Use case афаик описывают несколько шагов

зависит от уровня абстракции

Цитата Radagast @ 09.12.14, 09:28

"Если значение параметра телеметрии превысило значение определенное в таблице Х, нужно автоматически запустить скрипт из таблицы Y"

это test case при этом use case'ы тестируются test cesa'ами

[Qraizer]

Цитата Radagast @ 09.12.14, 07:57

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

Обязательно. Это требование отраслевых стандартов. Требования разных уровней -- от системного до низкого -- включают тегированные утверждения, которые в обязательном порядке трассируются по уровням друг на друга. Тесты проверяют требования, в обязательном порядке трассируя кейзы на тестируемые в них теги требований. Код, реализующий требования, в обязательном порядке трассируется на соответствующие теги требований. Всё отслеживается.

Добавлено 09.12.14, 13:07
P.S. Забудьте о боевиках, где обиженный конструктор берёт управление самолётом и рулит им с ноута из дому. Это фантастика.

[Radagast]

Qraizer
а есть об этом какая-то стоящая книжка/блог? именно в контексте airspace

[Qraizer]

Ну... DO-178c, действующий ныне Стандарт. Он не бесплатный. Есть российский аналог, не помню, как называется, почти точь в точь, но ещё дороже вроде бы.

Добавлено 09.12.14, 14:07
Только если ты ожидаешь увидеть так инструкции, как тестировать, писать код или требования, не найдёшь. Там этого нет и не должно быть. Там описываются требования организации процесса производства, а не его реализации.

Сообщение отредактировано: Qraizer - 09.12.14, 14:08

[Radagast]

Qraizer
спасибо!

самый первый вопрос все еще в силе

Сообщение отредактировано: Radagast - 09.12.14, 17:10

[Qraizer]

Это какой? Вот этот, что ли:

Цитата Radagast @ 08.12.14, 11:42

- В будущем мы захотим добавить больше и больше фич и тестирования, и то что начиналось как маленький скрипт, неконтролируемо разбухает. Так что я хочу минимизировать кол-во скриптов, и для тех моментов когда без них никак, я бы предпочел писать их на bash, а не на Python или Ruby, которых я не знаю.

Во-первых, я не понимаю, что такое "добавить больше и больше фич и тестирования". С моей точки зрения фичи плодить не требуется, пока не захочется чего-нибудь эдакого. А для эдакого есть скрипты. Поэтому не могу себе представить, как можно плодить фичи, не добавляя скриптов для их реализации. Больше и больше тестирования подразумевает больше и больше тестов. Это скажется на количестве тестов, но на количестве скриптов это не может сказаться.
Во-вторых, касательно скриптов в Дженкинсе я вроде сказал. Наши скрипты забирают тесты из SVN, оттуда же берут тестируемый билд, гоняют, через конвертер репорты гонят XML, которые Дженкинс уже обрабатывает сам, кратко дифференциально отчитывается и сохраняет подробные диффы для ручного анализа, если вдруг тот кому понадобится. Это работает как часть ночных сборок, запускается ...по-моему кроном на линухах, а на виндовой удалёнке стандартным планировщиком заданий. Или вручную ежели припрёт кому.

Это не реклама Дженкиска, может кто ещё лучше предложит. Просто это наш опыт, за который я могу отвечать как за вполне положительный.