Продвинутая система тестирования софта:, Есть идеи? Опции

[Evgeny_CD]

Готовлю я тут потихоньку платфому для новых проектов, и возникла вот
такая задача.

Есть код на C. Plain ANSI C, все чин-чинарем. Система функций, из
которых снаружи виден только вход и выход.

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

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

Тестировщик довольно прост: задаем данные, генерируем отсчеты, и на
вход. Он пишет лог: в какой последовательности мы чего на вход
подавали.

"Приниматель" данных просто пишет лог - в какой последовательности
чего приняли.

Ну и анализатор этих логов - где чего взглюкнуло.

Лично я (может, я старомоден?) после такой проверки спал бы куда
спокойнее, чем даже после такого замечательного моделирования, как тут
http://aly.projektas.lt/Projects/MATLAB/DT...coderEvanse.htm

Собственно, тут нет никакого противоречия - MATLAB совершенно
замечательная вещь для разработки, я же говорю о полностью
автоматизированное методике тестирования.

Возникает вопрос, как это сделать? Если использовать нормальную
embedded OS (типа eCos) в режиме синтетического порта (когда OS и
подчиненные ей задачи живут под Linux), то понятно. Устраиваем связь
наших функций с тестером посредством Linux IPC (Inter Proces
Commnunication) и тестируем до посинения.

Но возникает вопрос, на чем писать сам тестер?

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

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

Нашлась вот такая штука
http://www.swig.org/

SWIG is a software development tool that connects programs written in
C and C++ with a variety of high-level programming languages. SWIG is
used with different types of languages including common scripting
languages such as Perl, PHP, Python, Tcl, Ruby and PHP. The list of
supported languages also includes non-scripting languages such as C#,
Common Lisp (CLISP, Allegro CL, UFFI), Java, Modula-3 and OCAML. Also
several interpreted and compiled Scheme implementations (Guile,
MzScheme, Chicken) are supported. SWIG is most commonly used to create
high-level interpreted or compiled programming environments, user
interfaces, and as a tool for testing and prototyping C/C++ software.
SWIG can also export its parse tree in the form of XML and Lisp
s-expressions. SWIG may be freely used, distributed, and modified for
commercial and non-commercial use.

http://codeguru.com/csharp/.net/net_asp/sc...cle.php/c11103/
статья по теме

Я пока толком не разобрался, но по доке выглядит просто супер!

Вопросы:

1. Кто-нибудь этот SWIG юзал? Как оно?
2. Какие вообще существуют продвинутые методики проверки С программ?

[Major]

Вот еще линочка (если никогда не были на rsdn):
http://www.rsdn.ru/res/book/prog/beck.xml
http://www.rsdn.ru/Forum/?mid=414288

Здорово что вы прониклись подходом XP (по частям он известен всем, и многи частями его пользуют, но бек смог сделать резюме).
Но в embedded я с трудом вместе с ним...
Типичная "проблема":
Например есть на плате устройство, управляется через SPI.
Пишу класс управления устройством. Устройство одно! Тут либо паттерн singletone что правильно, либо все методы и члены сделать как static, что быстро для исполнения и компактно по коду....
Вот и приплыл. Не могу себя отучить для embedded писать нормально.
Применение static вместо паттерна "одиночка" затрудняет тестирования, так нельзя сделать наследование интерфейса, и гонять програмно подставленые потоки. Либо приходится заранее в класс внедрять возмодность поставы, что тоже хреново.

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

В принципе на форуме можно уже создавать раздел "методологии проектирования" для устройств, ПЛИС, программ, плат.

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

Сообщение отредактировал Major - Jan 30 2006, 03:40