Тестирование инсталляторов в Windows, когда надо быстро и дешево

Что надо от автотеста инсталлятора:

1. Кликать, вместо меня, там где надо — в русской и английской версиях интерфейса и чтобы без правки исходников. Для этого есть много разных способов, но мне больше понравился путь Аutoit — достаточно знать имя экземпляра объекта и можно послать ему сообщение о нажатии, единственный минус — надо знать имя окна, где расположена наша кнопка, как на русском, так и английском.
2. Не парить кучей одинакового кода, например, если для нажатия кнопки 2 или кнопки 3 мне надо пройти путь через окна 1, 2 и 3, я бы хотел объединить нажатие кнопок в окнах 1, 2, 3 в некую абстракцию «путь к кнопкам 2 и 3» и вызывать ее по мере надобности.
3. Отчеты о завале, докуда успел докликать, вобщем, что делал. Может быть даже делать скрины перед нажатием кнопочек?
   Скрытый текст

   Как-нибудь потом реализую
4. Отчет о результате если все сделал, смоук тест о том, что все действия реально выполнились, а не что кнопки нажались. Для инсталлятора — появились ли файлы, активны ли службы, запускается ли интерфейс.
5. Не хочу перекомпилировать и раскидывать новые еxe. Хочу править завалившийся автотест прямо на машине где он завалился, среда написания автотеста не должна вносить изменений в окружение — JAVA, .net, etc. Сотни случаев — у меня тесты прошли на ура, у клиента нет — приложить какой-нибудь .net забыли. В основном по этой причине отвалились варианты использования siculi- очень уж накладно откатывать java, для проверки, что без нее все тоже не работало.
6. Тестер в обычном мире, полном боли и отчаяния, не том что показан в маркетинговом гладком ролике о tfs это если сильно повезет — ты и девочка, которая аккуратно идет по тест-плану (мне вот не везет и девочка отсутствует). Ей не нужен python, тысячи тысяч возможностей из cpan. Нужно — убрать рутину. Еще бонусом в тленной реальности тестерами будут на пол-ставочные студенты, круто, но как только студент освоит perl, python, он сбежит в кодеры и сильно повезет, если он успеет выполнить ту задачу по тестированию, которую ему ставили. Так я пришел к мысли о минимуме возможностей для программирования во время тестирования.
7. Путь выполнения не на всех операционных системах одинаков, где-то появляется окошко uac, где-то нет, я не хочу заморачиваться на это каждый раз. Должен быть способ какого-то ветвления при выполнении тестового пути.

Сведя все в список я пришел к следующей идее — мне нужен свой кликер окошек с настройками в ini-файлах и отчетами.
Ок, учтем опыт поколений, будем использовать unix-way: разобъем задачу на две части — кликер и формирователь отчета.
Кликер кликает по указанным в простейшем, желательно самодокументированном, текстовом файле объектам — кнопкам, имитирует нажатия с клавиатуры.

Формирователь отчета — отдельная прожка, пишется под каждый конкретный случай, может проверять службы, создание в нужном месте файликов, сравнивать вывод к примеру команды dir c эталоном и проч если, надо. В большинстве случаев его даже не надо, тк опыт показывает, что постоянно требуется проверять новый функционал и его придется смотреть самостоятельно.

Пример настроек для кликера: файл ways.ini, в котором содержатся уникальные пути выполнения теста:

Собственно теперь, имея описание того, что можно делать с инсталлятором, соберем тестовый путь, описав его в другом ini-файле, testway1.ini.

Если нам понадобится проверить кнопку кансел — сделаем другой ini файлик, testway2.ini

countOps — количество за раз считываемых настроек из ways.ini — сейчас их 7 штук: LogMessage, WindowsNameEnglish, WindowsTextEnglish, Element, WindowsNameRussian, WindowsTextRussian, SendKeyText. sLogPath — имя файла для сообщений, LogMessage. Остальное наверняка понятно из названий. Свойство Element придется определять через программку Au3Info.exe

Пример кода, что сможет работать с такими ini-файлами, clickAndType.au3:

Прожка для запуска требует параметр — имя файла для получения настроек (testway2.ini, например, в котором указано, что выполнить из файла ways.ini).

Как же всем этим хозяйством добиться ветвления из пункта 7? Все очень просто, при запуске тест виснет в трей и ждет появления указанного окошка, можно параллельно запустить несколько программок-автотестов, одна из которых, к примеру, будет реагировать на окошко с требованием ввода пароля, введет его и изначальный тест продолжит свое выполнение как будто ничего не случилось.
Про вторую прожку — формирователь отчета я пожалуй не буду писать, очень уж там все индивидуально.

Ок, оно за меня может кликать, что дальше, Брейн? Надо избавиться от порочной практики по запуску автотеста своими руками, хорошая идея — подготовить специальные виртуалки, сделать снепшот BeforeInstallXXX, который будет содержать в автозапуске батник вида, runme.bat:

Осталось лишь размещать в файловой шаре тестируемый инсталлятор и перезагружать виртуальные машинки. Если быть достаточно везучим, можно на файловой шаре также разместить и сам автотест, тогда все изменения будут централизованы и вы сэкономите время на копировании файлов настроек testway.ini, ways.ini в каждую виртуалку.

По мере роста ваших запросов, скорее всего вы придете к мысли, что функционал runme.bat надо усложнять, насколько я могу судить, скоро предстоит реализовывать третью программку — раннер, который заменит runme.bat, и, видимо, будет уметь в зависимости от каких-то условий выбирать параметр запуска clickAndType.exe

9 из 10 ставлю на то, что все вышеописанное — это велосипед, который был изобретен уже 1000 раз 1000 разных людей и на самом деле все уперлось в то, что все они имели фатальный недостаток-написаны не мной, бонусом написаны программистами, которые в порывах максимальной универсальности нередко порождали монстров, я же, являясь основным заказчиком и пользователем был заинтересован в простоте инструмента таким его и реализовывал. Заодно скажу, что найти какую-либо информацию по тестированию инсталляторов в windows простым гуглением мне не посчастливилось. Теперь же она будет здесь.