Тестирование Установщиков На Windows, Когда Вам Это Нужно Быстро И Дешево

Счастливые веб-тестеры, используйте Selenium, и вы не ошибетесь.

Счастливые Java-тестеры — для них есть тестовые фреймворки, в особо сложных случаях — siculi. Мы привезли на тестирование консольные приложения — здесь хороши Python и Perl. А что насчет рабочего стола? Тестирование приложений типа «черный ящик» в Windows, в частности установщиков (например, msi-пакетов) привело меня в лагерь автоитов, в связи с тем, что моя автоматизация каждый раз натыкается на одни и те же грабли, которые я выделил ниже.

Что нужно от автотеста установщика:

Нажмите вместо меня там, где необходимо - в русской и английской версиях интерфейса и без редактирования исходного кода.
Есть много разных способов сделать это, но мне больше понравился способ Автоит — достаточно знать имя экземпляра объекта и можно отправить ему сообщение о клике, единственный недостаток — нужно знать название окна, где находится наша кнопка, как на русском, так и на английском языке.
Не стоит возиться с кучей одинакового кода, например, если для нажатия кнопки 2 или кнопки 3 мне нужно пройти путь через окна 1, 2 и 3, я бы хотел объединить нажатия кнопок в окнах 1, 2, 3 в какую-то абстракцию «путь к кнопкам 2 и 3» и вызывать ее как нужно.
Сообщает о блокировке, пока удалось дозвониться, в общем, что я и сделал.
Может быть, даже делать скриншоты перед нажатием кнопок? Скрытый текст я реализую это позже
Отчет о результате, если все было сделано, дым-тест, показывающий, что все действия действительно были выполнены, а не что кнопки были нажаты.
Для установщика - появились ли файлы, активны ли службы, запускается ли интерфейс.
Я не хочу перекомпилировать и распространять новый exe. Хочу отредактировать неудавшийся автотест прямо на той машине, где он провалился, среда написания автотеста не должна вносить изменения в окружение - JAVA, .
net и т.д. Случаев сотни - мои тесты прошли на ура, у клиента нет - забыли прикрепить какой-то .
net. В основном по этой причине отвалились варианты использования siculi — откатывать java, чтобы проверить, что и без нее все не работает, очень накладно.
Тестировщик в обычном мире, полном боли и отчаяния, не такой, как показан в гладком маркетинговом ролике про tfs, если очень повезет - вы и девушка, которая тщательно следует плану тестирования (мне не повезло и девочка пропала).
Ей не нужен питон, тысячи тысяч фич из cpan. Нам нужно убрать рутину.
Еще один бонус в бренной реальности - тестировщиками будут студенты-заочники, круто, но как только студент освоит Perl и Python, он начнёт заниматься кодингом и ему очень повезёт, если он сумеет выполнить поставленную задачу по тестированию.
Для него.
Так у меня в ходе тестирования возникла идея минимума возможностей программирования.
Путь выполнения не одинаков во всех операционных системах; где-то окно uac появляется, где-то нет, не хочется каждый раз с этим заморачиваться.
Должен быть способ каким-либо образом разветвиться при выполнении тестового пути.

Собрав все в список, я пришел к следующей мысли - мне нужен свой кликер окон.

с настройками в ini-файлах и отчетах .

Ок, учтем опыт поколений, воспользуемся unix-путем: разделим задачу на две части — кликер и генератор отчетов.

Кликер нажимает на объекты — кнопки, указанные в простом, желательно самодокументируемом, текстовом файле и имитирует нажатия клавиш.

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

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

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

LogMessage=Возьмите первое окно, нажмите кнопку1

WindowsNameEnglish=Настройка системы

WindowsTextEnglish=Добро пожаловать в

Элемент=[КЛАСС:Кнопка; ПРИМЕР: 1]

WindowsNameРусский=Установка системы

WindowsTextРусский=для выхода из мастера

ОтправитьКейТекст=

LogMessage=Возьмите второе окно, нажмите кнопку2

WindowsNameEnglish=Настройка системы

WindowsTextEnglish=Добро пожаловать в

Элемент=[КЛАСС:Кнопка; ПРИМЕР: 2]

WindowsNameРусский=Установка системы

WindowsTextРусский=Вы устанавливаете

ОтправитьКейТекст=

[Настройка кликов]

LogMessage=Возьмите третье окно, нажмите кнопку1

WindowsNameEnglish=Настройка системы

WindowsTextEnglish=Завершено

Элемент=[КЛАСС:Кнопка; ПРИМЕР: 1]

WindowsNameРусский=Установка системы

WindowsTextРусский=Все готово

ОтправитьКлючевойТекст=

[Нажмите «Отмена»]

LogMessage=Возьмите третье окно, нажмите кнопку2

WindowsNameEnglish=Настройка системы

WindowsTextEnglish=Завершено

Элемент=[КЛАСС:Кнопка; ПРИМЕР: 2]

WindowsNameРусский=Установка системы

WindowsTextРусский=Все готово

ОтправитьКлючевойТекст=

Собственно, теперь, имея описание того, что можно сделать с установщиком, соберем тестовый путь, описав его в другом ini-файле testway1.ini. Скрытый текст [инициалы] счетчик операций=7 ClickerIniPath="ways.ini" sLogPath="logs.txt" [testWay] case1 = Путь к настройке кнопки case2=Настройка кликов Если нам нужно протестировать кнопку отмены, мы создадим еще один ini-файл, testway2.ini. Скрытый текст [инициалы]

счетчик операций = 7

ClickerIniPath="ways.ini"

sLogPath="logs2.txt"

[testWay]

case1 = Путь к настройке кнопки

case2=Нажмите «Отмена»

countOps — количество настроек, считываемых за раз изways.ini — на данный момент их 7: LogMessage, WindowsNameEnglish, WindowsTextEnglish, Element, WindowsNamerussian, WindowsTextrussian, SendKeyText. sLogPath — имя файла для сообщений, LogMessage. Остальное, наверное, понятно из названий.

Свойство Элемента придется определять с помощью программы Au3Info.exe. Пример кода, который может работать с такими ini-файлами, clickAndType.au3: Скрытый текст #включать

$sLogMsg=""

$TestWayIniPath="clickandtype.ini"

если $CmdLine[0]<> 0 Тогда $TestWayIniPath=$CmdLine[1]

$countOps=IniRead($TestWayIniPath,'инициалы',"countOps","7")

$ClickerIniPath=IniRead($TestWayIniPath,'инициалы','ClickerIniPath',«clicker.ini»)

$sLogPath=IniRead($TestWayIniPath, 'инициалы', 'sLogPath', «logs.txt»)

$TestWay = IniReadSection($TestWayIniPath, 'testWay')

Если @error Then MsgBox(4096, "", "Произошла ошибка, возможно, нет INI-файла.

") Выход КонецЕсли ; Прочитать выбранный путь выполнения От $TestWayElement=1 до $testWay[0][0] $ControlsActivities = IniReadSection($ClickerIniPath,$TestWay[$TestWayElement][1]) Если @error Then

MsgBox(4096, "", "Произошла ошибка, вероятно, нет файла INI. „& $ClickerIniPath&' '&$TestWay[$TestWayElement][1])

КонецЕсли

$stopCycle=abs($ControlsActivities[0][0]/$countOps)

От $Elements=0 до $StopCycle-1

$win=$ControlsActivities[$Elements*$countOps+2][1]

$wintex=$ControlsActivities[$Elements*$countOps+3][1]

$ControlToPress=$ControlsActivities[$Elements*$countOps+4][1]

$winEng=$ControlsActivities[$Elements*$countOps+5][1]

$wintexEng=$ControlsActivities[$Elements*$countOps+6][1]

$SendString=$ControlsActivities[$Elements*$countOps+7][1]

$sLogMsg=$ControlsActivities[$Elements*$countOps+1][1]

_FileWriteLog($sLogPath, 'Window:'&$win&' '&$wintex&' Action:'&$sLogMsg)

Пока 1

если WinActive($win,$wintex) Тогда

$winEng=$выигрыш

$wintexEng=$wintex

Цикл выхода

ИначеЕсли WinActive($winEng,$wintexEng) тогда

$win=$winEng

$wintex=$wintexEng

Цикл выхода

КонецЕсли

спать(3)

WinActivate($win,$wintex)

WinActivate($winEng,$wintexEng)

Конец

если $controlToPress<> "" затем

ControlClick($win,$wintex,$ControlToPress)

КонецЕсли

если $SendString<> "" Затем

Отправить($SendString)

КонецЕсли

_FileWriteLog($sLogPath, 'Готово')

Следующий

Следующий

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

Как всем этим управлением можно добиться разветвления из пункта 7? Все очень просто, при запуске тест висит в трее и ждет появления указанного окна.

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

Про второй тест — генератор отчетов — пожалуй, писать не буду, там все очень индивидуально.

Хорошо, мне это может понравиться, что дальше, Брэйн? Нам нужно избавиться от плохой практики запуска автотеста своими руками; Хорошая идея — подготовить специальные виртуальные машины, сделать снимок BeforeInstallXXX, который будет содержать в автозапуске батник вида runme.bat: Скрытый текст msiexec /i "\\fileshare\install\installer.msi" запустить «testway1»/подождать clickAndType.exe \\fileshare\install\testway1.ini Останется только поместить протестированный установщик в общую папку и перезагрузить виртуальные машины.

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

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

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

При этом скажу, что мне не посчастливилось найти какую-либо информацию по тестированию установщиков в Windows простым гуглением.

Теперь она будет здесь.

Теги: #autoit #тестирование ИТ-систем

Последнее изменение: 2024-12-19 05:12:58

Вместе с данным постом часто просматривают: