нужны идеи по организации автоматического тестирования серверного софт

Тема целиком (не поместилась): нужны идеи по организации автоматического тестирования серверного софта на нескольких компьютерах

Господа, а не занимается ли тут кто-нибудь автоматическим тестированием серверного софта, когда в процессе задействовано несколько компьютеров?

У меня к вам серьёзный вопрос: Как Вы это делаете?

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

Что я пытаюсь понять как автоматизировать:

Корпоративная среда, несколько продуктов сторонних производителей, и один — свой.

Есть одна машина, на которой бегает domain controller со всеми пользовательскими профайлами, принадлежностью их к группам, правами доступа и проч. Назовём её для дальнейших рассуждений DC (as in Domain Controller). Она в тестах участвовать не обязана — считаем, что все тестовые пользователи созданы руками заранее.

Есть вторая, где бегает MS Exchange Server, и живут пользовательские почтовые ящики. Эту назовём EXCH07 (потому что там Exchange 2007, но когда-то надо будет добавить отдельную для тестирования Exchange 2010, и, к сожалению даже 2003 — появятся EXCH10 и EXCH03). Для засылки массового количества имейлов с прицепами или просто текстовых сообщений есть питоновский скрипт, принимающий разные параметры (диапазон адресов кому и от кого слать, с прицепами или без, папка с исходниками что слать или откуда выковыривать текст для безприцепных имейлов, сколько их заслать, и т.п. — т.е., процесс спама автоматизирован, и документов, считаем, что есть достаточно. Реально — чуть меньше терабайта.) и есть папки с файлами, которые можно рассылать.

На третьей машине бегает Enterprise Vault (Symantec-овский продукт, используемый для ахривирования всей пользовательской почты... да-да, все большие (или только публичные — не помню) американские компании по закону обязаны сохранять переписку своих сотрудников, и, чтобы не зависеть от воли пользователей с их желанием иногда что-то удалить, делают это на регулярной основе — сохраняют всё, что видят). Эту машину назовём EVLT. Теоретически, архивирование происходит по правилам — либо по достижении некоторого объёма пользовательского mail-box-а, либо каждую ночь, либо в особо параноидальных случаях — каждые 15 минут. Для целей тестирования допустим, что архивирование происходит каждые 15 минут. (Оно ещё может запускаться руками, но программного интерфейса, кажется, к функции "архивировать всё" или "архивировать вот этот ящик немедленно" нет.)

Наконец, на отдельной машине есть собственно тестируемый продукт — по сути — crawler&indexer, который (тоже по команде, но к нему есть java-интерфейс, чтобы запустить его автоматически) облазит содержимое eVault-а, индексирует его целиком или только всё новое с момента последней архивации, и даёт возможность искать текст в документах (имейлах и прицепах) в сотни раз эффективнее, чем eVault это умеет делать сам на больших объёмах информации (поисковый запрос выполняется за доли секунды вместо часов, которые занимает поиск средствами самого eVault-а). Эту машину назовём AUT (как в Application Under Test).

...Новые билды возникают, допустим, раз в пару недель. Руками прогнать все придуманные на сегодня текст-кейсы занимает ну дня два. Но у высокого руководства есть добросовестное заблуждение, что всё должно тестироваться автоматически, и в силу разных политических причин задача разубедить его в неэффективности такого подхода не стоит. Отсюда вопрос: как бы вы подошли к решению задачи автоматизировать процесс end-to-end тестирования?

Типичный ручной тест-кейс:
1. заслать питоновским скриптом в ящики user01...user010 прицепами в случайном порядке все файлы из папки AttachmentFilesFolder (там вордовые и икселовские документы, PDF-ы, PowerPoint-овские презентации и текстовые файлы). Туда же заслать plain-text-ом имейлы с текстами файлов из папки TextAttachments. (Занимает, например, минут 20 для тысячи-другой отосланных файлов.)
2. после того, как скрипт из п.1 отработал, убедиться на машине EXCH07, что в Exchange-вских Inbox-ах появились отосланные имейлы, записать в блокнотик в каком и сколько.
3. руками на машине EVLT запустить архивацию всех мейл-боксов на EXCH07 сервере. (можно, конечно, поставить какой-то тайм-аут, и дождаться, когда через 15 минут — чаще eVault не умеет — заархивирует всё сам)
4. убедиться в Outlook-е, что все имейлы были успешно заархивированы (там меняется иконка, показывающая, что в аутлуке осталась только "заглушка", а физически сообщение переехало в eVault)
5. на AUT машине запустить crawler — сейчас делается руками, но это — тестируемый продукт, и считаем, что доступ к программистам, которые объяснят как этой функцией воспользоваться из java-кода есть. (Обход всех файлов занимает в зависимости от того всё индексируем или только новые сообщения — от десятка минут до нескольких часов. В реальной жизни может занимать недели, но у нас же — тестовая среда, и имейлов — ну, сотня тысяч, а не десятки миллионов, как у конечных пользователей...)
6. после того, как crawler отработал, и всё проиндексировано, через браузер (gwt-приложение, имитирующее fat client, или просто сайт с ajax-ом и поисковым интерфейсом с фильтрацией, как в обычных книжных библиотеках) становится возможно искать слова из отосланных имейлов или прицепленных к ним файлов, и проверить сколько сообщений и прицепов (в результатах индексации и парсинга они видны отдельными строчками) теперь есть в архиве.

Целью тест-кейса является убедиться, что уникальную строку, отосланную сегодня, удаётся найти.
(Другим тест-кейсом будет, например, что залогиненный user01 видит через поисковый интерфейс в браузере только документы, отосланные в его ящик, и не видит отосланные юзеру02. Или — что из отосланных трёх имейлов все три появились с сегодняшней датой. И т.п.)

Вопрос или приглашение порассуждать: как связать и выстроить в очередь задачи на разных компьютерах и управлять всеми, убеждаясь, что следующая ждёт результатов предыдущей?
(Руками это всё делается через remote desktop с одного, разумеется, компьютера.)

Вариант 1:
все запскается из одного скрипта через DCOM на разных машинах. Кадлая следующая команда ждет кода завершения предыдущей

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

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

Главная идея следующая: на каждом сервере запускаем скрипт\программу, которая выполняет нужный мониторинг, проверки. На своем же компе запускаем основную тест-программу, которая и будет верховодить порядком выполнения подчинённых тестов, давать им команды и выводить результаты. Взаимодействие между основным тестом и остальными можно наладить посредством, например, сокетов. Можно всё, конечно самому создать, а можно поискать готовые решения по фразе "distributed testing", а далее просмотреть найденные документы на предмет синхронизации тестов. После недолгого гугления натолкнулся на туториал о том, как это делается в довольно популярном продукте TestComplete.

ch_ip, stmark, спасибо, понял куда рыть.