Тестирование инсталляторов: Автоматизируем вход Winlogon

от автора

Допустим, мы выбрали удовлетворяющий нас инструмент(и тут я имею в виду не только ту штуку из прошлой статьи, но и вменяемые инструменты навроде TFS etc), даже заставили его делать какую-то часть работы за нас. Мы смогли автоматизировать установку продукта и вот уже казалось, что счастье, оно — вот, протяни руку и… обнаружь, что на последнем этапе инсталляции нам необходимо пережить перезагрузку системы. А может быть даже в последствии загрузиться под ограниченной учетной\доменной\прочей записью. А если не повезло настолько, что Ваш продукт — изменяет msgina.dll, то… да-да, я имею в виду, что нам надо влезть под winlogon и автоматизировать вход учетной записи.

Казалось бы — что может нас остановить? Создадим службу, стартующую после перезагрузки, которая оживит процесс с нужным автотестом, а он уже прочтет из файлика — под каким пользователем загрузиться и сделает всю работу.

Анамнез

Как и задумано, я создал службу, посмотрел, что она может запускать команду ping localhost > c:\outping.txt сразу после перезагрузки, до входа в систему. Заменил ping на свой автотест и ничего не сработало. Службы которые могут запуститься до первого входа в систему запускаются от имени системной учетной записи localsystem и не могут быть интерактивными. Это значит, что будучи запущенным мой автотест не получил объекта системы, который описывает отображаемые на экране окна, так называемый desktop. Суть в том, что в системе windows существует три области в которые можно отображать окошки — default(грузится после ввода логина\пароля), winlogon(отображает всем знакомый запрос аутентификации) и невидимая область для неинтерактивных служб.

Фраза такая обтекаемая

Я тут сознательно избегаю терминологии дабы статья не выросла в это или цитирование главы «Сеансы, оконные станции, рабочие столы и оконные сообщения» книги Марка Русиновича «Утилиты Sysinternals. Справочник администратора»

Переключение между этими областями можно осуществлять вызовом функции winapi SetThreadDesktop

Ок, подумал кодер- всего-то надо вызвать 1 функцию winapi, стартануть свой автотест, ну и скомпилить статической линковкой, чтоб тестер не мучился с зависимостями. Ок, подумал тестер, всего-то теперь надо будет проверить на всех системах еще и прогу для запуска прог. Нельзя же не тестировать инструмент тестирования. Однако я не пошел по этому пути — с недавних пор при встрече с непонятными вещами в поведении Windows и грозящем изобретении велосипедов я стал прибегать к построению запроса к гуглу, начинающегося с фамилии Руссинович. Это сработало и в этот раз. Нас выручит PSexec.

Рецепт

  1. Скачаем srvAny и инсталлируем ее в тестовую среду
  2. Укажем в параметре Application программы srvAny строчку «полный\\путь\\к_psexec\\PSexec.exe /x /s /d /accepteula cmd.exe». Собственно параметр /x и обеспечивает запуск в рабочем окружении winlogon
  3. Перезагрузимся, дождемся приглашения к аутентифиации, если все сделали правильно — на заднем фоне замаячит консоль cmd. Заменим cmd на свой автотест( для tfs я так понимаю надо запускать тест-агента с некими параметрами) вводящий логин-пароль\проверяющий работоспособность новой msgina. Готово.

ссылка на оригинал статьи http://habrahabr.ru/post/199234/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *