GipsySh

может стоит поиграться с ВМВарой ?

Да, есть идея использовать API для VMware - выполнять первую часть скрипта, потом выполнять логон (в VMware, действительно, это можно автоматически сделать), а потом уже вторую часть...
Видимо, так и придется делать... Хотелось просто сделать скрипт как можно менее зависимым от дополнительного ПО. Но, увы...

samurai08,
разумеется, модульное тестирование не будет основным. Оно планируется как дополнение к существующему процессу тестирования с целью его усиления. В системе постоянно добавляется новый функционал, поэтому модульное тестирование помогло бы в этом случае проверять, что при добавлении этого нового функционала не был "сломан" функционал, реализованный ранее.

Tuchka_84, большое спасибо за описание практической реализации! И отдельное спасибо за ссылку на cppunit! Уже скомплировала для него нужные библиотеки и начала осваивать его.

Уважаемые коллеги!
прошу помощи! необходимо организовать отдел тестировния в организации, в которой понятия не имеют, что это вообще такое. даже не знаю с чего начинать... тестовая среда очень условная (серевера отдельного нет), каждый день обновляется. bug tracking нет вообще, ошибки пишут на клочке бумаги, потом теряют. разработчиков 20 - тестер 1... документации нет, даже пользовательской. комплекс изучить можно только методом "тыка".

Без баг-трекинга процесс тестирования вообще немыслим... Хуже всего в таком случае тестировщику - ошибки не систематизированы, теряются, а виноват потом будет как раз тестировщик.
Думаю, в такой ситуации, когда никто понятия не имеет о тестировании и разработчики не проявляют интузиазма по поводу каких-то нововведений, нужно первым делом ненавязчиво "приучить" всех к баг-трегинку. Причем, он должен быть как можно проще. Есть бесплатно распространяемый инструмент Trac - http://ru.wikipedia.org/wiki/Trac , http://trac.edgewall.org/
Посмотрите, возможно, он Вам подойдет.
Сама работаю с ним недавно. До этого работала с TFS, поэтому если сравнивать, то:
основные плюсы Trac: легко изучаем (интуитивно понятно, как с ним работать), работа с системой осуществляется через веб-интерфейс, поэтому не требует установки дополнительного ПО (на рабочем месте конкретного работника).
Но есть и минусы:
не очень удобная схема отслеживания жизненного цикла дефекта (но, в принципе, если у вас пока цель - просто систематизировать ошибки, собрать и хранить их описания в одном месте, то, думаю, это не принципиально. К тому же, исходный код Trac'а открыт, думаю, теоретически при необходимости можно доработать - не уточняла этот вопрос). Ну, и видимо, все-таки нужен будет сервер...
Вообщем, суть всего выше сказанного вкратце - первым делом определитесь с баг-трегингом. Затем приступите к разработке тестов.

В принципе, такая возможность есть, но я попробовала уже проверить для дескрипторов с номерами от 3 до 9 (включительно) и итог везде получился одинаковый :(

нет, экран - это не только STDOUT, но еще и STDERR и STDLOG (и еще не помню что)
попробуйте еще вот

cd %systemdrive%\
"my.exe" /param 2>&1 3>&1  >> C:\test.txt
pause

во вторых - а что пишет ? может у вас там ошибка в "cd %systemdrive%\" или до них ?

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

cd %systemdrive%\
"my.exe" /param 2>&1 3>&1  >> C:\test.txt
more C:\input.txt 2>&1 3>&1  >> C:\test.txt
pause

в файл test.txt будут записаны данные из input.txt. И всё - для первой команды результат выведется только в окно командной строки :(