Как стать автором
Обновить

Комментарии 38

AutoIt это мощный инструмент не только для тестера, но и для виндового системного администратора. Здорово экономит время!
тема интересная
Фигасе, думал на хабре один я знаю о AutoIt. На самом деле очень прикольная штука, достаточно богатый функционал, возможность имитировать действия пользователя, возможность создавать GUI + компиляция в exe, что еще нужно для быстрого прототипирования? потоков разве только…
Я на нём вполне себе мелкие коммерческие утилитки писал. :)
Будете смеятся — я сделал для (вместо) диплома программу тестирования знаний. Тестирование непосредственно было на html+jquery, а разные тесты я соеденил в GUI от AutoIt.

Вот сейчас предлагают сделать систему для авторизации запуска программ. Тоже AutoIt поможет :)
а ещё так можно писать ботов к онлайн играм) хотя обычно это далеко не лучший подход
а оно позволяет записывать действия и потом конвертировать это в скрипт?
думаю да, во всяком случае его брат AutoHotKey точно может
Да, есть рекордер. Но почти всегда желательно руками потом допилить.
благодарю. тогда буду смотреть.
Есть несколько утилит генерирующих код autoit из действий пользователя, но, насколько я помню получаемый из них код слишком нестабилен относительно автоматизации, там в основном записываются клики мышью привязанные к пикселям экрана и нажатия клавиш клавиатуры. Ничего интеллектуального. Одна из утилит называется AutoItMacroGenerator
Буквально вчера обновился с сайта, почему то выпилили из поставки программу AutiItWriter но засунули нечто глючное типа MacroRecorder, сходу в интернете готовых решений не нашел, так как не горит, отложил напотом, в крайнем случае скачаю версию постарее (там идет сборка с редактором SciTE).

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

AutoIt — там свой бейсикоподобный язык, есть возможность вызова функций из системных dll и т.п. достаточный но сложные проекты лучше кодить на чем-то другом, а autoit использовать как вызываемую и даже генерируемую прослойку.
Как-то автоматизировал подгрузку расписания в систему бронирования авиакомпании через AutoIT. По клику запускалась какая-то замороченная программа для диспетчеров что-ли (причем с расшаренного диска, который неизвестно где находился, к тому же), в ней тыкалась куча кнопочек, в итоге сохранялась пара файлов с расписаниями, потом через curl в bat-файле это все загружалось на сервер, там парсилось и пихалось в базу.

Работает уже года 2. Каждое утро одна девочка, приходя на работу, тыкает в зеленую иконку, начинается мельтешение окон и расписание обновляется.

Правильное решение с использованием API стоило бы неслабых денег (там какое-то лицензирование) и писалось/отлаживалось бы явно не за пару дней.
тыкает зеленую иконку, зеленая иконка… зеленая иконка — это AutoHotKey! Не AutoIt я использовал, а AutoHotKey) Что сути дела, впрочем, сильно не меняет.
Очень интересная тема, продолжайте, пожалуйста!
Сам занимаюсь автоматизацией тестирования игр. До последнего времени использовал связку python, pywinauto, Test Complete. Очень неприятно, что все они закрыты и скриптам приходится просто кликать/нажимать клавиши «вслепую». Чувствую, что процесс может быть более рациональным — буду рад ознакомиться с чужим опытом :)
Присоединяюсь. Давайте еще статьи по этой теме!
Привязка к значениям координат окна в таких тестах не есть хорошее решение. Для такого способа критичны будут изменения разрешения экрана (напр. переход в 120 DPI) или размеров шрифтов, элементов управления (к примеру ширины полос прокрутки и т.д). Интересно, как с этим справляется AutoIt3?
Если же тестирование всегда производится в неизменяемой среде, то другое дело…
Опять же изменение GUI программы (напр. скины) обяжет вас писать другие наборы тест-кейсов для всех случаев.
При почти любом изменение тестируемой области придется редактировать скрипт. Тоже самое надо будет делать используя коммерческие комплексы типа test complete. И с меньшей вероятностью изменять код нужно будет в интегрированном в проект игры языке. Но, как мне кажется, привести код к рабочему виду не составит много времени. Другое дело когда делается полный редизайн диалога. Там придется писать все снова. От этого никто не застрахован. Это я описал действия при плановом одноразовом изменении концепции игры(диалога, шрифта, разрешения).

А если в игре используется несколько версий шрифтов, элементов управления, скинов и разрешений экрана, самым простым вариантом будет main скрипт который содержит процедуры анализирующие что используется в текущей сборке и в зависимости от результата скрипт запускает один или несколько sub скриптов соответствующих конфигурации игры.
А вы не пробывали в большей степени смотреть в сторону юнит-тестирования, а не функционального? В любом случае пиксел-зависимые тесты достаточно трудно поддерживать при изменяющихся условиях. Сравнение с эталонными картинками и чек-суммами будет приводить к необходимости постоянно их обновлять. Лучшие тесты, это те, которые будут работать не зависимо от изменяющихся условий.
В топике рассматривается именно возможность автоматизировать тестирование уже скомпилированной, закрытой игры не имеющей отладочной информации игры, т.е. релиза. В моем случае, когда я пришел в проект почти все было уже написано, а программисты наотрез отказались писать юниты, ибо поздно уже, и внедрять луа, ибо не умеют.
Автоматизировал «работу» с игрушкой одной, достаточно популярной. Начинал с AutoIt, но как раз встроенные достаточно бедные возможности OCR и стали преградой.

В итоге написал небольшую обертку над винапи, имитирующие движения мыши/нажатия клавиш, и «универсальную», в рамках моих целей, библиотеку автоматизации процесса автоматизации :) Если кратко — то суть в разбивке всего процесса на шаги, где каждый шаг сводится к нахождению области на экране (простейший OCR) и выполнению действия (мышь/кнопка).

Потратив однажды пару дней, автоматизация шага теперь проходит за пару минут — добавлением класса с параметрами поиска. С#. Поначалу задумывался над выкладыванием в опен-сорс, но в такой специфичной области наврядли кто-то будет использовать чьи-то сторонние поделки, когда нет уверенности что поделка «подойдет» и отсутствует коммьюнити :)

Кстати, у того же AutoIt есть AutoItX — ActiveX библиотека для использования в своих разработках… но неудобство собственно ActiveX (регистрация на пользовательских компах) перевесила изначальное нежелание писать своё :)
Эх, жаль. С удовольствием бы глянул код. А то сейчас сам подключаю библиотеку AutoIt.
Я то же с удовольствием бы глянул код… :)
скиньте в личку почту — на выходных упакую и скину. пригодится — буду рад :)
AutoIt — рулит! Уже использовал его для релайбилити тестирования программы, а сейчас пишу скрипты для тестирования локализации. Очень интересно.
Не совсем понятно, зачем в данном случае AutoIt, если есть UI Automation и <a href-http://uiautomationverify.codeplex.com/>библиотека для работы с ним из PowerShell


Visual UIA Verify может в числе прочего и запускать тесты.
Ах да, UIA нормально работает с ресайзнутыми приложениями и в высоких DPI
Заметил фейл со ссылкой. Исправляюсь
AutoIt потому что я его использую для решения практически всех задач, кроме веба.
UI Automation позволяет работать с играми, например HMM3?
Autoit + MozRepl + ff_au3 = Web
я имел ввиду создание сайтов)
Было бы интересно почитать развернутый топик о практическом использовании, подводные камни и т.п.
как на счет работы с DirectX приложениями и играми? можно автоитом что нить сделать?
В этом и есть преимущество описанного выше способа. В алгоритме нет привязки к конкретному приложению, только графические области. Также есть возможность «наложить» скриптовые контролы на игровые. Например в игре Х есть кнопка, которая выглядит как автомобиль, соответственно симуляция нажатия кнопки может быть только координатная, но мы можем создать эту кнопку в качестве обьекта autoIt, описать ее свойства и методы взаимодействия, что позволит в дальнейшем обращаться к этой кнопке в игре не как mouseclick(x,y) (клик по координатам экрана), а controlclick($buttonCar) (клик по конкретной кнопке).
спасибо, и хотелось бы видеть в следущей статье вариант для DX игры =) а то у нас например с этим не заладилось.
Я использовал авто-хот-кей.
К слову надо добавить что у этих интерпретаторов функционал куда выше чем банальное запоминание тычков по клавишам. Там неплохая поддержка винапи, так что можно сделать многое. Но для этого надо читать документацию, кстати часть ее переведена на русский добровольцами.
Ну в PowerShell кроме нативной поддержки FCL (и .Net сборок вообще), COM, WMI, WebServices и пр., умеет еще и компилировать сборки в рантайме (на C#, VB.Net, JS.Net), что означает кроме прочего P/Invoke и не просто «неплохую поддержку винапи», а ПОЛНУЮ поддержку Win32 и Native API:
add-type -Namespace Native -Name DateTime -member @"
[DllImport("ntdll.dll")]
public static extern uint NtQuerySystemTime(out long SystemTime);
"@

$time = 0
[Native.DateTime]::NtQuerySystemTime([ref]$time)
[System.Windows.Forms.MessageBox]::Show($time)


В Win7 стоит «из коробки» в Vista и XP прилетает обновлением. Что еще надо для счастья
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории