Тут поделились ссылочкой, http://sourceforge.net/projects/blueducksda/. Проект, который комбинирует Selenium и AutoIt.

Я бы сказал, - гремучая смесь. Кто уже пользовался? Интересно, стоит ли использовать?

есть небольшой вопрос по автоматизаци одного сценария. Есть страница где заполняются данные и есть страница в другом месте где эти данные отображаются. необходимо проверить что они идентичные. так как поля находятся на разных страницах простым assertEquals у меня не найдет одного поля. Кроме как сохранять значения в переменные я не придумал. Может быть есть более лаконичное и красивое решение.

Одной из наиболее серьезных проблем при автоматизации функционального тестирования на уровне GUI является высокая чувствительность тестов к изменениям GUI. По-хорошему, подобная ситуация не должна возникать, так как автоматизация подобного рода ставится тогда, когда пользовательский интерфейс более-менее стабилен. Но это идеальная ситуация. В реальности, продукт меняется по всем направлениям и в том числе это касается пользовательского интерфейса. Так или иначе какие-то мелкие изменения имеют место (поле переименовали, переместили, поменяли некоторые идентификаторы) и это уже влияет на работоспособность тестов. Частично, можно реализовать гибкий механизм поиска объектов, на который подобные изменения не повлияют, но в большинстве случаев корректировок самих реализаций тестов не избежать. Соответственно, надо как-то минимизировать трудозатраты на корректировку. Наиболее эффективным решением данной проблемы можно назвать вынесение оконных деклараций во внешний ресурс и использование "псевдонимов". Подобное реализовано в WinRunner ( GUI Map ), QTP, RFT ( в котором есть возможность маппинга и все оконные объекты можно классифицировать как mappable и non-mappable ), TestComplete ( NameMapping и Alias, появившийся в поздних версиях ). Суть подобных решений в том, чтобы некоторому оконному объекту с заданными атрибутами поставить в соответствие некоторое имя, которое и будет использовано для обращения к данному оконному объекту.

Во многих средствах подобный механизм реализован, но существует много различных решений, которые фактически представляют собой некоторую библиотеку с прикрученным тестовым движком. В этом случае приходится пользоваться возможностями языка, на котором эти тесты пишутся. В качестве примера рассмотрим язык Ruby и конкретно его порт под Selenium RC. Почему взят именно Ruby? Во-первых, на Ruby есть еще несколько решений аналогичных Selenium RC и возможности языка, там применимы в той же мере. Во-вторых, Ruby - один из примеров языков интерпретируемого типа, у которого есть возможность динамического формирования и компоновки объектов. Подобные механизмы имеются и во многих других скриптовых языках ( в частности JavaScript ), поэтому Ruby был выбран в качестве демонстрации самой возможности подобной компоновки. На других языках подобные решения реализуются по аналогии с поправкой на специфику.

Как известно, в Selenium оконные объекты распознаются с помощью локаторов - специальных строк вида:

<how>=<value>, где

how - определяет атрибут, по которому ищется объект. Это может быть id,name, dom, xpath и многие другие ( в документации по Selenium о локаторах достаточно много расписано )
value - непосредственно значение атрибута, по которому ищется объект

То есть одна строка идентифицирует объект. У подобного решения есть одно достаточно сильное преимущество - простота использования. Но подобная строка не отражает логического смысла объекта. Например, локатор

xpath=//img[@alt=‘The image alt text’]

Позволит определить, какой объект реально искать на форме, но совсем непонятно, какая форма должна быть. То есть с точки зрения удобства чтения мы не в состоянии фиксировать, на какой странице находится данная ссылка, достаточно сложно выявить логический смысл самой ссылки ( а это важно, так как при чтении кода больше упор ведется на логический смысл нежели фактические атрибуты ). Соответственно, удобно было бы сделать псевдоним вида: 

<Псевдоним страницы>.<Псевдоним объекта>

просто для удобства чтения. Для этого можно сделать классы-обертки вида:

class MyPage

     def lnkLink()
          "xpath=//img[@alt='The image alt text']"
     end

end

После чего мы можем создать экземпляр данного класса:

wTestPage = MyPage.new

и вместо локатора использовать выражение вида:

wTestPage.lnkLink

Уже проще, так как в случае модификации атрибутов ссылки нам не надо будет менять локаторы во всех тестах, достаточно будет внести корректировки в объявлении класса. Также это решение удобно тем, что оконные декларации - это такая же часть програмного кода, что и непосредственно реализации тестов. Но тем не менее, немного неудобно нагромождать большое количество подобных классов, а если тестируемое приложение содержит много страниц, то классов будет много, что влечет за собой большое количество файлов. Поэтому, зачастую целесообразно отделить ресурсы ( оконные декларации ) от движка ( непосредственно програмной реализации ). В качестве аналога можно вспомнить NameMapping в TestComplete. Файл, описывающий правила маппинга - это XML-файл. Соответственно, можно попробовать сделать аналогичную реализацию на Ruby. Тем более в данном случае задача заметно проще, так как практически нет иерархии объектов, а сами объекты описываются одной строкой, а не множеством атрибутов.

Часть 1

Часто при работе автотестов возникают ситуации, когда приложение может вести себя по-разному и в зависимости от полученной реакции приложения нужно выполнить определенные действия. Наиболее четко это выражено в тестировании GUI, когда после выполнения некоторых операций мы ожидаем один из возможных вариантов реакции системы. Самый простой пример: у нас есть окно Notepad и нам надо реализовать функционал по его закрытию. То есть, нужно нажать на крестик в правом верхнем углу. Но если уже был введен некоторый текст, то вначале появится сообщение о подтверждении сохранения изменений. В этом случае нам дополнительно надо еще обработать диалог закрытия окна. Если подобную задачу реализовывать в виде некоторой вспомогательной функции, то обе ситуации надо обрабатывать.

Безусловно, эту обработку можно делать последовательно. В случае с вышеприведенным примером можно после нажатия крестика проверить наличие окна сообщения, выполнить действия при появлении этого окна, а затем уже спокойно ждать закрытия главного окна. Но уже в этом простом примере наблюдается неэффективное использование времени выполнения. Если окна подтверждения сохранения нет, то мы потратим впустую некоторое время на его ожидание. Опять же, был описан достаточно простой случай, но может так случиться, что один и тот же функционал работает по-разному в зависимости от настроек, при этом нужно реализовать универсальную функцию. В этом случае последовательная обработка разных объектов может оказаться неспособной реализовать поставленную задачу.

Наиболее эффективным решением с точки зрения рационального оспользования времени выполнения является последовательный опрос требуемых объектов втечение заданного промежутка времени. То есть, если применить псевдо-код, то реализация описывается следующим фрагментом:

startTimer();
while( getElapsedTime() > iTimeout ){

    i = 0;

    foreach control in ( controlList ){
        if( control.property == expected ){
            return i;
        }
    }
}

return -1;

В этом примере:

• startTimer() - инициирует работу таймера
• getElapsedTime() - возвращает время прошедшее с момента инициации таймера
• iTimeout - максимальное время ожидания
• expected - ожидаемое значение некоторого проверяемого свойства
• controlList - список элементов управления, у которых надо проверить значение property на соответствие значению expected.

Часть 2

Одной из наиболее серьезных проблем при разработке автотестов ( особенно функциональных на уровне GUI ) является синхронизация выполнения тестов с работой тестируемого приложения. Иными словами, действия, которые выполняются в автоматическом тесте, должны осуществляться именно в тот момент, когда приложение находится в требуемом для данного действия состоянии. В противном случае мы можем получить картину, когда тест пытается делать клики, вводить текст, в то время как форма, над которой осуществляются данные действия, отсутствует. В результате, наш тест идет проторенными методами, но совсем непонятными путями. Если при этом нет никаких механизмов выравнивания состояния, то подобное может серьезно подкосить выполнение пакета тестов в целом.

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

Наиболее простым вариантом является установка задержек. Практически во всех средствах для автоматизации функционального тестирования есть инструкции, которые просто делают паузу в выполнении. Так, во многих решениях присутствуют функции вида: sleep( nSec ) или wait( nSec ). В TestComplete это делается вызовом BuiltIn.Delay(), в Java для этого есть вызов Process.sleep( ). Все эти решения имеют схожую структуру - единственный параметр, указывающий время, на которое установить паузу.

Преимущества данного решения:

1. Простота - использование встроенной функции/метода достаточно простое и понятное
2. В некоторых случаях подобные вставки позволяют избежать "заклинивания" выполнения, когда 2 достаточно ресурсоемкие операции выполняются друг за другом ( в частности в SilkTest в некоторых случаях пауза в 1 секунду позволяла избегать заклинивания выполнения команд Агента ).
3. Достаточно эффективное решение для операций, которые имеют фиксированное время "опоздания", например, появление окна сообщения, выданного клиентским скриптом на веб-странице. В этом случае пауза нужна просто для того, чтобы четко синхронизировать тест с моментом точного появления окна

Тем не менее, у данного решения есть и недостатки:

1. Нерациональное использование времени выполнения - некоторые операции, особенно, обработка различных клиент-серверных запросов, могут занимать различное время, даже для одной и той же команды. Соответственно, паузу целесообразно делать на интервал времени, покрывающий максимальное время ожидания. В результате, если действие выполнилось раньше, то пауза все равно действует фиксированное время, отчего мы теряем до нескольких минут на одном подобном ожидании. Если подобных действий будет много, то суммарная потеря времени выполнения будет составлять вплоть до нескольких часов.
2. На разных средах тестируемое приложение может работать с разной скоростью, соответственно, нужно во всех вхождениях инструкции для паузы перестраивать время ожидания.
3. Подобные паузы не отражают причин, по которым они проставлены, из-за чего подобный код весьма затруднительно читать. Также в тестовом коде может быть слишком много подобных инструкций, отчего код разрастается весьма ощутимо без видимых на то причин
4. Подобные паузы не гарантируют, что тестируемое приложение достигло нужного состояния

Статья является модификацией более ранней версии, опубликованной в журнале “Windows Tech Journal”(10/96) и протоколами 14й Международной Конференции в Тестировании Программного Обеспечения, соответственно. Автор благодарит ST Labs за поддержку.

Ситуация 1. Во время разработки продукт передается от одного разработчика к другому. Каждый новый разработчик обнаруживает, что документация к продукту уже устарела и процесс разработки нарушен. После анализа в течение месяца каждый объявлял о неудачном проектировании и настаивал на необходимости написания больших объемов нового кода. По прошествии еще нескольких месяцев разработчик уходил или продукт передавался другому человеку, и весь процесс повторялся заново.

Ситуация 2. Программисты быстро реализовали проект без достаточного понимания того, какие же задачи он должен был решать. Спустя много месяцев после завершения, при анализе результатов обнаруживается, что система в эксплуатации и обслуживании стоит дороже, чем проведение того же процесса, который система автоматизировала, вручную.

Ситуация 3. 100000$ было потрачено на внедрение современного набора инструментов для разработки. Вскоре обнаружилось, что данные инструменты не настолько мощные, портативные, надежные, чтобы использовать их для достижения значительных успехов в разработке. После ближайших двух лет попыток заставить их работать, инструменты были заброшены.

Ситуация 4. Продукт был разработан для автоматизации набора бизнес - задач. Но задачи были изменены настолько, что проект совсем отдалился от графика и результаты работы системы автоматизации стали недостоверными.  Периодически, сотрудники отдела разработки освобождались от работы над проектом, чтобы помочь решить задачи вручную, от этого они еще больше отдалялись от разработанной системы автоматизации.

Ситуация 5.  Программа, состоящая из нескольких сотен почти независимых функций, вводится в эксплуатацию сразу после поверхностного  тестирования. Незадолго до запуска, большая часть функций была неактивна, так как находилась в состоянии отладки. Почти год прошел c того момента, когда хоть кто-то заметил, что эти функции вообще отсутствуют. 

Эти небольшие эпизоды из моей собственной практики, но я уверен, что они знакомы многим. Это распространенные жалобы на то, что многие программные продукты проваливаются. И это не должно нас удивлять – со стороны, программы кажутся очень простыми, но ведь проблема в деталях, не так ли? Опытные разработчики программного обеспечения отлично это знают, и к началу нового проекта подходят настороженно и скептично.

Автоматизация тестирования также непроста. Рассмотрим еще раз ситуации, приведенные ранее. В основном, каждый из этих случаев был попыткой автоматизировать тестирование. Девять лет я управлял группами по тестированию программного обеспечения и занимался автоматизацией тестирования (имейте ввиду, в компаниях богатых и разбирающихся в разработке программных продуктов). Наиболее важным открытием для меня стало то, что проекты тестирования программного обеспечения настолько же близки к краху, как и любые другие программные продукты. По сути, в моем опыте, они проваливались чаще, в основном, потому что большинство организаций не уделяло такой же заботы и профессионализма для тестовых продуктов, как делалось это в текущих проектах.

Странно, что почти все эксперты по тестированию, практикующие тестировщики, менеджеры по тестированию, и, конечно же, компании, продающие инструменты для тестирования, рекомендуют автоматизировать тестирование с таким чрезвычайным энтузиазмом. Хотя, возможно, «странно» не совсем правильное слово. В итоге, инструменты для автоматизации проектирования и разработки были огромной прихотью, и инструменты для тестирования просто другая сторона таких продуктов. От объектно-ориентированного до «безпрограммистского» программирования, идеалистическая пропаганда не новость в нашей индустрии. Так, может, высокое качество общедоступной информации и анализа автоматизации тестирования не такое уж удивительное, а скорее, просто знак незрелости данной области. Как сообщество приверженцев автоматизации, возможно, мы еще в фазе восхищения идеей автоматизации тестирования, но еще не разобрались в подводных камнях. Поспешу согласиться, что автоматизация – это отличная идея. Мне нравиться что-то автоматизировать гораздо больше, чем выполнять какие-либо другие задачи. Большинство тестировщиков, работающих полный день, и, наверное, все разработчики мечтают, что можно будет нажать большую зеленую кнопку и позволить лаборатории верных роботов сделать всю тяжелую работу по тестированию, тем самым освобождая их самих для более возвышенных занятий, как, например, сетевые компьютерные игры. Не смотря на это, если бы достигли этого Шангри-Ла, мы все равно должны были бы продолжать действовать с осторожностью.

Эта статья является критическим анализом «скриптового и проигрывательного» стиля автоматизации регрессионного тестирования приложений с графическим интерфейсом.