Блог

Оператор 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() эти изменения никак не повлияют на работу скриптов.