AutoIt позиционируется как freeware-инструмент для автоматизации рутинных операций в среде Windows (Unix-аналоги будут рассмотрены чуть позже). О функциональности и достоинствах этого продукта можно прочитать по следующим ссылкам: caйт продукта, cтатья в Википедии, руководство по AutoIt от O’Reilly.
Отметим лишь богатство стандартной библиотеки, множество User Defined Functions, отличную документацию, скромную, но уютную среду разработки на базе редактора SciTE и дружелюбный форум пользователей и разработчиков. Для нас AutoIt интересен возможностью облегчить регрессионное тестирование GUI-приложений. Вот небольшой пример:
Задача: создать локального пользователя через оснастку Computer Management; проверить результат.
Примечание: для краткости изложения представленный код не выполняет обработку ошибок (как-то, проверку существования пользователя перед его созданием, неудачный вызов функций и т.п.)
Вариант решения:
$treeitem = "Computer Management (Local)|System Tools|Local Users and Groups" $username = "testuser" Run ('cmd /c "compmgmt.msc"', @SystemDir, @SW_HIDE) WinWaitActive("Computer Management") ControlTreeView ("Computer Management", "", 12785, "Expand", $treeitem) $treeitem = $treeitem & "|Users" ControlTreeView ("Computer Management", "", 12785, "Select", $treeitem) Send ("{AppsKey}{Down}{Enter}") ControlSend("New User", "", "Edit1", $username) ControlClick("New User","", 1170) ControlClick("New User","", 2) Sleep(2000) Send ("{Tab}") $result = ControlListView ("Computer Management", "", "SysListView321", "FindItem", $username) WinClose ("Computer Management") If $result <> -1 Then MsgBox (0, "Test result", "Success") Else MsgBox (0, "Test result", "Failed") EndIf
К числу слабых мест AutoIt можно отнести свой собственный язык программирования и отсутствие механизма исключений (exceptions). О том, как интегрировать вызов функций AutoIt в более мощные языки программирования, мы поговорим в одной из следующих статей.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Pingback : OpenQuality.ru » Python и AutoIt: cлужили два товарища | August 25, 2008
[…] статье, иллюстрирующей работу с AutoIt, был рассмотрен пример […]
Pingback : OpenQuality.ru » AutoIt: чтение конфигурации автотеста | September 16, 2008
[…] составе AutoIt есть отличные возможности для считывания […]
Автор комментария : Artour Bakiev | December 8, 2008
Симпатичный пример: лаконичный и понятный - демонстрирует, кажется, всё что необходимо.
Для меня остался неясным один момент - можно ли заменить вызов Sleep(2000) на вызов функции из семейства WinWait*()?
[Ответить]
Автор комментария : Капитан Аляска | December 8, 2008
Артур, спасибо за вопрос. Ответ: it depends. Функции из семейства WinWait*() ждут какого-то состояния окна: скажем, оно станет активным (WinWaitActive) или не активным (WinWaitNotActive) или просто пока не появится (WinWait) и т.п. То есть, в тех случаях, когда мы ждем какого-то события, связанного с окном, такая замена вполне уместна и даже оправдана. В других случаях надо смотреть.
Если я правильно понял, тебя смущает сам факт недетерминированного Sleep? Явная константа в коде, и неясно, чему она должна быть равна? Меня это тоже смущает, и потому в реальных скриптах (здесь не привел для краткости) использую два варианта:
1. проверяю наличие элементов, которые являются ориентиром того, что ожидание можно закончить (окно, кнопка и т.п.)
2. Sleep ($SleepPeriod). Параметр SleepPeriod считывается из конфигурационного файла и варьируется в различных окружениях. Если хост мало загружен, то значение SleepPeriod меньше, если больше загружен, то и значение больше.
[Ответить]
Автор комментария : Pavel Bulka | May 4, 2009
есть намерение попробовать применить AutoIt для автоматизации тестирования GUI в конфигурациях системы 1С:Предприятие.
Как думаете, возможно ли это вообще?
[Ответить]
Автор комментария : Капитан Аляска | May 4, 2009
Павел, это в сильной степени зависит от тех controls, на которых построены GUI в 1C. Если это Windows Controls, то проблем быть не должно. Если это .Net controls, то могут быть трудности: AutoIt сам по себе не видит эти контролы и, соответственно, не может на них кликнуть. Я видел кастомные решения на форуме AutoIt, но в моем случае они не сработали. Попробуйте!
[Ответить]
Автор комментария : Иван | September 30, 2009
Есть ещё масса программ, имеющих пользовательский интерфейс “псевдографический”, в стиле MS-DOS, или midnight comander’а (наглядный например - торговые ПОС-терминалы которые все видели на кассах), который прорисован использованием текстовых символов среди которых есть какие-то места для ввода данных. Подскажите, что использовать для их автоматизированного тестирования? Под Линуксом?
Заранее благодарю!
[Ответить]
Автор комментария : Капитан Аляска | September 30, 2009
Иван, прежде всего есть возможность запускать AutoIt под Wine. Попробуйте. Если даже AutoIt не “увидит” окна вашего приложения, то по крайней мере можно попробовать его в качестве “кликера”: посылать нажатия клавиш с помощью Send.
Можно посмотреть xAutoClick, KAutoClick и другие подобные “кликалки”.
Помимо этого, есть смысл взглянуть на Gambas.
Но, наверное, вы не просто хотите “кликать”? Важно понять, что именно вы планируете тестировать в программах с псевдографическим интерфейсом и плясать уже от этого. И поговорить с разработчиками: какие фреймворки они используют? Возможно, эти же фреймворки можно задействовать для написания автотестов.
[Ответить]