Сообщений в теме: 8

[ntvisigoth]

День добрый, %username%.

У меня имеется проект приложения с консольным интерфейсом. Пишу сам, причем мультиплатформенно.
Пока будет работать под системами: 1) FreeBSD amd64, i386 8.2 и выше 2) Windows XP и выше.

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

Вопросы

• Существуют ли мульти-платформенные средства тестирования консольных приложений? (предпочтения тем которые без GUI)
• Если "да", то какие? (Приведите пожалуйства названия)

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

Тест-план с проектировал таким:

# inp_cmdline = %(inp_option)s %(input)s
# out_cmdline = %(out_option)s %(output)s
# FullCommand = %(application)s %(inp_cmdline)s %(out_cmdline)s %(options)s

[general]
application = "..\\..\\bin\\Win32-Release\\MalwareCryptor.exe"
report      = "app32_parse_headers.log"
inp_option  = "--source-file"
out_option  = "--output-file"
options     = "--postfix out"
output_md5  =

[empty_input]
input      = "EmptyFile.bin"
input_md5  = "D41D8CD98F00B204E9800998ECF8427E"
exit_code  = 0
output_md5 = 

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

Как то так... То что я привел свою разработку преследует цель дать желающему помочь мне дополнительную ин-
формацию о том что я хочу.

P.S.:
Моя основная специализация это разработка, а не тестирование. Это к тому, что я могу не знать терминологии
профессиональных тестировщиков и поэтому прошу попроще ;)

[OVA]

А что мешает в том же питоне на основе Pyunit наколбасить тестов? Ну прикрутить хелперов, которые выход будут разбирать, прикрутить хелперов которые будут вход собирать и вуаля. Почти те же юнит тесты в плане писанины.

[ntvisigoth]

А что мешает в том же питоне на основе Pyunit наколбасить тестов? Ну прикрутить хелперов, которые выход будут разбирать, прикрутить хелперов которые будут вход собирать и вуаля. Почти те же юнит тесты в плане писанины.

Потому что думаю это будет:

• Громоздким решением
• Привязанным чисто к одной программе

Я же хочу этого избежать!

[OVA]

Это будет нормальный конструктор, не более того. При этом если вам внезапно не понадобится более сложная логика чем вдувание predefined input'ов и сравнение с predefined-же output'ами, то никаких привязанностей толком не будет и будет очень даже компактно + еще получите всю xUnit инфраструктуру нашару. А если понадобится, то там и так и так придется громоздить.


ЗЫ: А вообще я не очень понимаю зачем питон, если делать как вы делаете. Почему не шелл скриптик сразу?

[ntvisigoth]

А что мешает в том же питоне на основе Pyunit наколбасить тестов? Ну прикрутить хелперов, которые выход будут разбирать, прикрутить хелперов которые будут вход собирать и вуаля. Почти те же юнит тесты в плане писанины.

А почему советуете именно этот модуль? Почему не test — Regression tests package for Python или unittest — Unit testing framework ?

[OVA]

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

[ntvisigoth]

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

Насколько понял из истории развития PyUnit, он сейчас часть Фрэймворка unittest. Вы же предложили использовать именно PyUnit :) возникает вопрос: "Вернуться именно к прошлому, т.к. там есть интересная функциональность не вошедшая в современный unittest?" или что-то другое?

Не совсем понял вашу мысль:

Ну прикрутить хелперов, которые выход будут разбирать, прикрутить хелперов которые будут вход собирать и вуаля.

Т.е. написать реализацию setUp() как-то по особому? Как именно? Я понял вас так: пишем setUp() так чтобы он сам лез в ini-файл описывающий тест-план.
А test_*() метод уже согласно заданному контракту выполняет приложение и затем проверяет результаты. Я все правильно понял?

Подытожу: У меня непонимание идеи технической реализации вашего предложения "прикрутить хэлперов".

ЗЫ:
На питоне совсем недавно, могу что-то не совсем корректно говорить и поэтому заранее извинясюь ;)

[OVA]

Плохо читаете.

The Python unit testing framework, sometimes referred to as “PyUnit”

Вроде же одназначно написано.

Хэлпер это не про питон вообще. Это так, например: http://web.cs.wpi.ed...ng-helpers.html

[ntvisigoth]

Случайно наткнулся на свой же пост в гугле ) Для истории и завершенности скажу, чем у меня завершилось дело.

Написал 2 скрипта, один создает отчет, а другой считая потом его его считает эталонным.

Первый скрипт - make_test_report.py

1. входных данных берет:

1) файловый путь до тестовых файлов,
2) путь к тестируемому приложению
3) Командную строку которая нужна п.2

2. На выходе при работе 1.2(см.выше) для каждого тестового файла сохраняются :

1) STDOUT, STDERR
2) В выходной отчет пишутся MD5 от входного файла, STDOUT, STDERR
3) Также в выходной отчет пишутся и retcode возвращаемых тестируемым приложением.
4) В выходной файл в титле пишется ком. строка запускаемого тест. приложения с которой работает на файле

Второй скрипт - SmokyTest.py

1. Входные данные:

1) Путь к эталоном тестовый отчет полученному и проверенному после первого скрипта
2) Файловый путь до тестовых файлов
3) Файловый путь до тестируемого приложения
4) Командная строка берется из тест. отчета

2. Выходные данные:

1. Какой входной файл не совпадает по ожидаемому MD5
2. После какого тест.файла STDOUT не совпадает по ожидаемому MD5
3. После какого тест.файла STDERR не совпадает по ожидаемому MD5
4. Для какого тест. файла не совпадает retcode после выполнения тест. приложения

Затем все это применил в виде Post Build Event в MS Visual studio и получил небольшое "дымчатое тестирование". А более объемные наборы с этими скриптами тоже ведется, но я их после сборки не ставлю, чтобы билд был побыстрее и давал быстро ответ "Хоть как-то работает или нет?". Периодически смотрю на баги и пытаюсь изменить набор тест.файлов для "дымчатого теста", чтобы сразу же видеть свои проблемы, а не потом после объемного ;)