Блог

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

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

Веб-сервисы - достаточно распространенный вид компонент распределенных систем. Фактически это один из интерфейсов удаленного вызова процедур. То есть, из некоторой программы мы можем отправить запрос на выполнение некоторой операции на стороне сервера и получить результат выполнения операции, при этом графический интерфейс не задействован. Подобные компоненты позволяют реализовать интеграцию между различными системами, которые изначально между собой не связаны. Отчасти это делает веб-сервисы достаточно популярными, как результат - они используются в достаточно большом количестве приложений, а это в свою очередь влечет необходимость их тестировать, в том числе и автоматически. Для этой задачи есть и специальные средства, наподобие soapUI, но помимо этого возможность тестирования веб-сервисов имеется и в более полновесных средствах, в т.ч. и в TestComplete. В TestComplete, начиная с 6-й версии как раз была добавлена возможность тестирования веб-сервисов. Рассмотрим, как это реализуется и каким образом можно проверить веб-сервисы.

Автоматизированное тестирование на уровне GUI содержит в себе много сюрпризов, связанных с работой с оконными объектами. Причем сюрприз заключается в том, что наиболее изящное решение проблемы с поддержкой описаний оконных объектов в актуальном состоянии для каждого отдельно взятого средства может быть свое. Но это наиболее удачное решение. Тем не менее, есть ряд механизмов, имеющих аналоги в различных средствах. Одним из примеров является Mapping оконных деклараций, позволяющий некоторым оконным объектам ставить в соответствие некоторый псевдоним. Подобное решение в TestComplete обладает одним ключевым недостатком: при изменении иерархии оконного объекта приходится переделывать маппинг всех дочерних объектов. Альтернативой этому стало введение с 6-й версии TestComplete такой функциональности как Alias, которая позволяла регулировать иерархию псевдонимов. Но у такого решения есть другой недостаток: низкая скорость. Соответственно, нужны механизмы, позволяющие оперативно реагировать на изменение GUI, при этом корректировки желательно минимизировать. Давайте рассмотрим конкретный пример.

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

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

Оператор typeof используется для определения типа переменной. Существует 6 возможных значений, которые возвращает typeof: "number," "string," "boolean," "object," "function," and "undefined".

В этом посте мы немного улучшим этот оператор, чтобы иметь возможность определять такие типы данных, как дата ("date") и массив ("array").
 

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

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

Очень часто при автоматизации тестовых сценариев можно натолкнуться на шаги вида: "повторите шаги 1-12" или еще интересней, "повторите все шаги" + некоторые поправки. То есть в конечном итоге при реализации нам надо будет полностью продублировать код определенных шагов. А излишнее дублирование может вызвать ряд трудностей при модификациях тестов, при поддержке тестов. Любые изменения надо вносить во все вхождения повторяющегося кода. А это дополнительная потеря времени. Как этого избежать:

В очередной раз, наталкиваясь на различные публикации по автоматизированному тестированию, наталкиваюсь на мнение людей, что как только упоминается какое-нибудь heavy-weight big vendor средство автотестирования (кстати как правило стараются не называть конкретное средство ), то к нему сразу же привязывается "диагноз" что ли - unmaintainable scripts. Но если упоминается что-нибудь писанное на коленке или представляющее собой некоторую библиотеку, то такой проблемы изначально якобы нет. Я, конечно, склоняюсь к идее, что лучше взять что-то мелкое, но оно будет успешно выполнять поставленные задачи, чем взять что-то здоровое и громоздкое, а потом думать, куда бы его прикрутить.

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

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

• Читаемость
• Расширяемость
• Переносимость
• Оптимальность
• Соответствие требованиям
• Удобство модификации
• Прочее (добавить по вкусу)

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

function TestDXRadioList()
{
	Sys.Process("SchedulerMainDemo").WinFormsObject("frmMain").Activate();
	var oRadioGrp = Sys.Process("SchedulerMainDemo").WinFormsObject("frmMain")
				.WinFormsObject("rgrpView");
	var oOCR = OCR.CreateObject(oRadioGrp);
	Log.Message(oOCR.GetText());
	if(oOCR.FindRectByText("MonthView"))
	{
		oRadioGrp.Click(oOCR.FoundX, oOCR.FoundY);
	}
}

В качестве подарка к Новому году AutomatedQA Corp. анонсировала учебник по TestComplete на русском языке.

Скачать учебник можно здесь.

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

Компания Automated Testing Service Group поздравляет всех с новым 2008 годом!

Пусть в новом году сбудутся все ваши мечты!

ListPrint(lsOut)

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

Столкнулись со странным поведением TestComplete при работе с обычным окном File Download.

Такое окно появляется при попытке загрузить файл из интернета при работе в Internet Explorer.

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

Очень часто на форумах звучит один и тот же вопрос: с чего начинать изучение продукта автоматизации? Здесь мы попытаемся дать ответ на этот вопрос, не привязываясь к какому-либо конкретному продукту.

Неделю назад, 12 сентября 2007 года, нам наконец-то удалось зарегистрироваться на сайте share-it! , не имея собственного продукта для продажи. Так как этот процесс занял некоторое время, мы решили описать его здесь более-менее подробно.

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

Во время записи скриптов в TestComplete при нажатии на обычные кнопки (Button) TestComplete использует метод ClickButton() для нажатия. Например,

var w = Sys.Process("WindowsApplication3"). WinFormsObject("Form1");

w.WinFormsObject("button1").ClickButton();

Рекомендуется сразу же заменить этот метод на метод Click(), так как в будущем обычная кнопка может быть заменена другим элементом управления, для которого метод ClickButton() не подходит.

Например, обычная кнопка может быть заменена кнопкой стороннего производителя. При этом имя кнопки может остаться таким же, как и раньше. При использовании метода Click() вместо ClickButton() эти изменения никак не повлияют на работу скриптов.