Интересует чем можно себе помочь. Необходимо тестировать интерфейс приложений. Т.е. нужно иметь возможность потыкать по кнопкам, пооткрывать менюшки в приложениях на WinFroms и WPF (очень нужно). Чтоб софтина автоматически могла находит кнопки. Идеальна возможность писать скрипт на C#-подобном языке. Есть ли такой идеал в природе? Спасибо!

Здравствуйте, Хэлкар, Вы писали:

Х>Интересует чем можно себе помочь. Необходимо тестировать интерфейс приложений. Т.е. нужно иметь возможность потыкать по кнопкам, пооткрывать менюшки в приложениях на WinFroms и WPF (очень нужно). Чтоб софтина автоматически могла находит кнопки. Идеальна возможность писать скрипт на C#-подобном языке. Есть ли такой идеал в природе? Спасибо!

Идеала нет, но, возможно, под ваши задачи подойдет Ranorex (http://www.ranorex.com/).

Здравствуйте, Хэлкар, Вы писали:

Х>Интересует чем можно себе помочь. Необходимо тестировать интерфейс приложений. Т.е. нужно иметь возможность потыкать по кнопкам, пооткрывать менюшки в приложениях на WinFroms и WPF (очень нужно). Чтоб софтина автоматически могла находит кнопки. Идеальна возможность писать скрипт на C#-подобном языке. Есть ли такой идеал в природе? Спасибо!

Не знаю насчет WPF, а вот WinForms можно тестировать при помощи NUnitForms (про WPF см комменты внизу).

Пока что смотрю Test Automation FX.

Здравствуйте, Хэлкар, Вы писали:

Х>Интересует чем можно себе помочь. Необходимо тестировать интерфейс приложений. Т.е. нужно иметь возможность потыкать по кнопкам, пооткрывать менюшки в приложениях на WinFroms и WPF (очень нужно). Чтоб софтина автоматически могла находит кнопки. Идеальна возможность писать скрипт на C#-подобном языке. Есть ли такой идеал в природе? Спасибо!

1. Поиск по форуму рулит.

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

Здравствуйте, Хэлкар, Вы писали:

Идеальна возможность писать скрипт на C#-подобном языке.

White.
Увы, не идеал, но работает и использовать удобно. На сайте примеры и все такое.
Есть недостаток — для нестандартных контролов (например ДевЭкспресс) придется писать декораторы самому, но
это быстро, да и исходники есть.

XSH>1. Поиск по форуму рулит.

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

XSH>2. Я бы изо всех сил советовал до последнего пытаться отделить GUI от логики, чтобы потом его подменить чем-то более легко и беспроблемно тестируемым. И только когда логика уже полностью протестирована, задуматься над тем, чтобы тестировать GUI.

А мне для этого и надо. Регрешн тесты писать. Основные юзкейсы пробежать быстро.

A>White.
Да, мне очень понравилось, но нет надежды заставить тестировщиков писать под него. Для этого им исходники изучать придется. А в Test Automation FX есть возможность ткнув по кнопке получить ее данные.

Здравствуйте, Хэлкар, Вы писали:

A>>White.
Х>Да, мне очень понравилось, но нет надежды заставить тестировщиков писать под него. Для этого им исходники изучать придется. А в Test Automation FX есть возможность ткнув по кнопке получить ее данные.

Хотя для White есть распознавалка, но она очень сырая еще.

Отпишите пожалуйста когда определитесь с инструментом, тоже интересно.

На данный момент ситуация такая.

Протестировал следующее:
1. White – очень удобная для разработчика библиотека, но не имеет UI и требует знания кода приложения. (C#)
2. Test Automation FX – удобная вещь, с UI (интегрируется в VS2008), но так и не смогла нажать на одну кнопку (впоследствии смогла, но двойном кликом — видимо проблема была в том, что кнопка была не с обработчиком события а кидала команду). (C#)
3. Randorex 1.5 и 2.0 (RC) – интересная вещь (особенно 2.0, но она сырая). Имеет хороший UI и умеет записывать скрипты. (C#)
4. TestCompleate 6.50 – нашел все кнопки, но он стоит $999 и код надо писать на VB.
5. HP QuickTest — похоже для работы с WPF приспособлена плохо (можно улучшать приспособление, путем написания XML-описаний классов).
Не протестированы: BorlandSilkTest, IBM Rational Functional Tester, NUnitForms.

Сейчас стараюсь приручить Test Automation FX — манов по ней мало

Здравствуйте, Хэлкар, Вы писали:

Х>На данный момент ситуация такая.

Х>Протестировал следующее:
Х>...
Х>4. TestCompleate 6.50 – нашел все кнопки, но он стоит $999 и код надо писать на VB.

Небольшое уточнение. Код там можно писать на нескольких языках, но это все равно не C#. Да и тяжеловат тул в использовании для неподготовленных людей. А для мелких задач дороговато. Хотя, из heavy-weight средств для работы на уровне GUI это наиболее дружелюбная штука для .NET

Х>5. HP QuickTest — похоже для работы с WPF приспособлена плохо (можно улучшать приспособление, путем написания XML-описаний классов).

У QuickTest есть много недостатков, примерно 10000 зеленых американских недостатков. И опять же, это тоже heavy-weight. Причем он уже не идет отдельно, а как часть Quality Center. То есть там в комплекте тест-менеджер + багтрекер + еще разные компоненты инфраструктуры тестировщиков. В общем, если у вас это всё уже есть, то рассматривать QuickTest вообще нет смысла.

Х>Не протестированы: BorlandSilkTest,

И не пробуйте. Во-первых, порядка 9000$, во вторых — там свой встроенный язык со смешанным синтаксисом ( что-то среднее между C и VB ), в-третьих, вот как раз с поддержкой .NET контролов у него уже давно проблемы, как правило поддерживаются далеко не самые последние версии.

Х>IBM Rational Functional Tester,

Все тесты пишутся на Java, что для C#-based проектов несколько глупо. Опять же, не из дешевых

Х>NUnitForms.

Х>Сейчас стараюсь приручить Test Automation FX — манов по ней мало

Еще гляньте что-то типа UI Automation. Это бесплатная библиотека как раз для .NET объектов

В принципе, могу посоветовать только копать в сторону средств, интегрированных с Visual Studio или отдельных .NET-based библиотек. В вашем случае это даст наиболее оптимальное соотношение между ценой, качеством и интегрированностью (имеется ввиду, что легче будет прикрутить к процессу сборки, например).

Здравствуйте, Marduk, Вы писали:

Х>>4. TestCompleate 6.50 – нашел все кнопки, но он стоит $999 и код надо писать на VB.

M>Небольшое уточнение. Код там можно писать на нескольких языках, но это все равно не C#. Да и тяжеловат тул в использовании для неподготовленных людей. А для мелких задач дороговато. Хотя, из heavy-weight средств для работы на уровне GUI это наиболее дружелюбная штука для .NET

Да, там есть некий C#Script, VBScript и что-то еще. Просто самый адекватный из них как ни странно VB (но и он поддерживает intellyseance очень слабо). Но как не странно нашим тестерам TestCompleate нравится больше всего.


Х>>Сейчас стараюсь приручить Test Automation FX — манов по ней мало

M>Еще гляньте что-то типа UI Automation. Это бесплатная библиотека как раз для .NET объектов

Глядел кстати, забыл написать. Да, вещь тоже интересная. Но также как и White только для разработчиков.

Здравствуйте, Хэлкар, Вы писали:

Х>Здравствуйте, Marduk, Вы писали:

Х>>>4. TestCompleate 6.50 – нашел все кнопки, но он стоит $999 и код надо писать на VB.

M>>Небольшое уточнение. Код там можно писать на нескольких языках, но это все равно не C#. Да и тяжеловат тул в использовании для неподготовленных людей. А для мелких задач дороговато. Хотя, из heavy-weight средств для работы на уровне GUI это наиболее дружелюбная штука для .NET

Х>Да, там есть некий C#Script, VBScript и что-то еще. Просто самый адекватный из них как ни странно VB (но и он поддерживает intellyseance очень слабо). Но как не странно нашим тестерам TestCompleate нравится больше всего.

Там есть C# Script, C++ Script, JScript, VBScript , что фактически различные вариации active scripting движка + DelphiScript, но это отдельная тема.
Я обычно предпочитаю использовать JScript, так как у него более-менее сбалансированный синтаксис, а также он позволяет обрабатывать исключения хотя бы локально (в VBScript этот механизм если и есть, то в изрядно кастрированном виде). Но если из ваших тестеров есть ребята, которые уже работали с аналогичными системами ( WinTask, QuickTest, TestPartner ), скрипты которых используют VBScript, то тогда лучше уже использовать VBScript.

Опять же, советую посмотреть внимательно на цену. 999 у.е. — это скорее всего именная лицензия стандартной версии. Это означает, что там будет базовый набор компонент и расчитано на то, что легально имеет право этой версией пользоваться только тот человек, на которого эта версия зарегистрирована. В общем, посмотрите внимательнее на эти опции. Там цена варьируется вплоть до 4500$. Но это enterprise floating license.

Х>>>Сейчас стараюсь приручить Test Automation FX — манов по ней мало
M>>Еще гляньте что-то типа UI Automation. Это бесплатная библиотека как раз для .NET объектов
Х>Глядел кстати, забыл написать. Да, вещь тоже интересная. Но также как и White только для разработчиков.

А тут всё относительно. На самом деле разные record&play программы для автоматизации тестирования на самом деле требуют более-менее адекватного умения программировать. Требования, конечно, пониже, так как код автотестов должен быть изначально проще кода тестируемого приложения, но тем не менее, возможность record&play ( зачастую именуемая как record&pray ) нужна либо в маркетинговых целях (тупо замануха), либо чтобы просто получить какое-то подобие работающего кода.

Так что, если нужно поставить автоматизацию в достаточно больших объемах или просто на долгосрочную перспективу, то пожалуй лучше ребят настроить на использование библиотек типа UI Automation, White и т.п. Некоторым из тестировщиков вполне может быть интересно чуть прокачаться по части навыков того же C# с возможностью вырасти в разрабы (лично наблюдал 5 примеров таких переходов из автотестеров в девелоперы). Мотивация есть, в-общем.

M>А тут всё относительно. На самом деле разные record&play программы для автоматизации тестирования на самом деле требуют более-менее адекватного умения программировать. Требования, конечно, пониже, так как код автотестов должен быть изначально проще кода тестируемого приложения, но тем не менее, возможность record&play ( зачастую именуемая как record&pray ) нужна либо в маркетинговых целях (тупо замануха), либо чтобы просто получить какое-то подобие работающего кода.

Обычно Record используется не на прямую, а после обработки. Т.е. потыкал, записал, что-то исправил. В этом случае это удобная фича.

Здравствуйте, Хэлкар, Вы писали:

M>>А тут всё относительно. На самом деле разные record&play программы для автоматизации тестирования на самом деле требуют более-менее адекватного умения программировать. Требования, конечно, пониже, так как код автотестов должен быть изначально проще кода тестируемого приложения, но тем не менее, возможность record&play ( зачастую именуемая как record&pray ) нужна либо в маркетинговых целях (тупо замануха), либо чтобы просто получить какое-то подобие работающего кода.

Х>Обычно Record используется не на прямую, а после обработки. Т.е. потыкал, записал, что-то исправил. В этом случае это удобная фича.

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

А если это точечная задача, то методика, описанная вами вполне подойдет.

Основная проблема записываемого кода — это его низкая maintainability. И чем больше тестов, тем сложнее будет это все поддерживать в рабочем состоянии

Написание стабильных тестов — непростая задача. В особенности, если они будут интегрироваться в билд-сервер (в идеале на Continious Integration Build). Если не предпринимать специальных архитектурных решений, то тест будет частенько падать. В основном из-за того, что при использовании Record & Play не учитываются паузы между действиями — для автоматизации нетривиальных контролов нужно ставить нечто типа цикла ожидания для четкой фиксации какого-то события, окончания действия и т.д.
Очень полезной практикой является запуск автотестов при каждой заливке девелоперами и рассылка письма на команду, если при очередном сабмите упал автотест — позволяет оперативно обнаруживать баги.
Но по своему опыту могу сказать, что отладить и настроить такой процесс очень непросто

О! Привет, Вов!

Это безусловно. Но мы такие тесты используем для тестирования общих юз-кейсов, которые практически не меняются со временем.
Кстати Test AutomationFX умеет ждать появления нужного контрола на экране.

Здравствуйте, Хэлкар, Вы писали:

Х>О! Привет, Вов!

Х>Это безусловно. Но мы такие тесты используем для тестирования общих юз-кейсов, которые практически не меняются со временем.

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

Х>Кстати Test AutomationFX умеет ждать появления нужного контрола на экране.

Это умеют многие. На худой конец, если для написания тестов используется какой-то язык программирования общего назначения ( C, C++, Java, C#, Perl и т.п. ), то практически всегда там найдутся средства делать некие тайм-ауты, через которые можно просто "прозванивать" нужный объект.

Х>>Кстати Test AutomationFX умеет ждать появления нужного контрола на экране.

M>Это умеют многие.

Ага, есстественно, я имел в виду, что он это делает автоматически.