Как стать автором
Обновить

Комментарии 24

Мало :) Еще давайте )
О чем? :) об автоматизации в общем или о чем-то конкретном с примерами?
Если будет и о том, и о другом, будет отлично. А если примеры применения бесплатных тулов из жизни приведете, да еще и с рекордерами, да еще и для Win32 — вообще цены не будет.
А то мы, например, самописьками на AutoIt пользуемся, стыдно признаться.
AutoIt в любом случае лучше чем руками :)

С рекордерами в бесплатных тулзах, я боюсь, очень плохо, но попробую.

Лично от себя могу порекомендовать WatiN для .NET или WatiJ для Java(последний как-то не очень развивается). В селениуме одновременно плюсом и минусом является запуск тестов через прокси, то есть через сам селениум, который является Java приложением. Минусом является то, что требуется запускать его(прокси) помимо основного теста, тогда как в WatiN можно тест скомпилировать в один exe файл и давать людям как раз из разряда «тестировщиков низкой квалификации по n-денег». Давно хочу написать про WatiN\WatiJ, но вот как то с кармой в прошлом накосячил(Данное предложение ни в коем случае не является просьбой поднять карму :), лучше скажите как в песочницу написать)
Автотест:

1. Ввод данных — ~10*0.1 = 1 секунда
2. Отображение таблицы – 2 секунды
3. Поиск нужной строки – 0.5 секунды
4. Проверка соответствия введенных данных – 0.5 секунды

Информация не совсем верная :) Такое мы получаем в идеальном случае. В реальном приложении всё будет несколько медленной. Например есть веб-страница, на страничке есть AJAX запрос, так что иногда приходится ждать пока произойдет взаимодействие с сервером etc.
в этом случае ждать приходится и человеку тоже.
Ручному тестировщику тоже нужно будет сделать AJAX запрос к чашке кофе или в аську. :) Так что для него тоже приведен идеальный вариант. Автоматизация же не призвана ускорять приложение — для этого есть нагрузочное тестирование :)
Вы меня чуть чуть не поняли. Например, какой нибудь абстрактный «босс» прочитает ваш пост и подумает: «Круто! В разы уменьшает время тестирования!». Потом он дает команду QA сделать автотесты, но в приложении встречается пара таких палок в колёса по типу AJAX. QA справляется с ними, добавляя что-то типо waitForComplete(), но потом на это смотрит «Босс» и говорит: «Эй! Что это у вас так всё медленно! Я читал что на это тратится всего 4 секунды! А у вас целых 20! Что за фигня! Вы ничего не умеете!» etc. В конце концов достается QA отделу, и лично тому кто делал тесты.
Спасибо. Добавлю (не меняется) к времени открытия страницы. Надеюсь, что так боссам будет понятнее.
Есть очень много других средст тестирования как платных, так и бесплатных.
Из своего опыта могу поделиться такой программой как BadBoy — бесплатная программа для тестирования веб-сайтов. Мы ее активно используем для ежедневной проверки наших главный сайтов. Небольшая, простая в использовании, хорошо документированная, немногожко глюков конечно есть, но жить можно :).
Также большой список различных средств тестирования веб-сайтов доступен тут.
Могу еще порекомендовать TestComplete. Хоть он и платный, но очень хорошо подходит для тестирования как веб-сайтов, так и Win приложений.
На BadBoy посмотрю, спасибо.

Что касается TestComplete, то у него по сравнению с QTP есть один недостаток — «из коробки» он не интегрируется в HP (Mercury) Quality Center, который является практически отраслевым стандартом средств поддержки процесса тестирования в больших организациях. Сам по себе он, безусловно, хорош.
Нужен обзор средств автоматического тестирования. Плюсы-минусы.

Про указанных в списке могу сказать только про Selenium — удобный, но неразвитый продукт. В частности записанный тест кейс спотыкается на iframe и редакторах, которые их используют. И если для фрейма можно допилить напильником, то редактор победить не удалось, похоже не умеет генерировать события правильно.

Также напильник нужен для AJAX-а. И вообще тесты требуют напильника и знаний/опыта как это работает. Рекламируемая простота — только для банальных хомяков.

Иногда тесты с отслеживанием событий, проверками и действиями с ожиданием, почему-то может не работать на Fast. Может быть и на Slow что-то не работает.
Не умеет работать с запросам к серверу, то есть GETы можно прописать вручную, но это наиболее легкая для автоматизации часть полностью упущена. Что-то есть для

А вообще тулза супер! :) Простые вещи делаются быстро, сложные — по-разному, как и бывает обычно. Добавить автоматическое тестирование запросов к серверу с параметризацией — цены бы ему не было.
Открытые исходники дают возможность допилить самому.
Не проверял, но рекламируется возможность удаленного тестирования на сервере и организовывать кластеры.
Для небанальных хомяков существуют коммерческие средства автоматизации. Например, упомянутые уже Testcomplete и QTP от HP. В селениуме мне понравилось наличие рекордера, что его как-то сближает с коммерческими инструментами. Некоторые вещи, как справедливо было замечено, можно делать очень быстро.

Правда и в коммерческих тулзах простые вещи делаются очень быстро, а сложные — как обычно :) Особенно часто это проявляется, если на странице есть «нестандартные» элементы управления, например, набор дивов, который выглядит и ведет себя как combobox. Помучиться пришлось изрядно %(

> Причем стадия «Проведение тестирования» включает в себя тестирования всего объема функциональности – и старого, и нового.
Вот с этим не согласен. Я например смотрю, какие изменения выложил разработчик в SVN (обычно с пометками, что добавлено/исправлено/изменено) и уже этот функционал и гоняю, потом когда подходит время релиза или просто нечего делать — приступаю к тестированию всего функционала, т.е. одно и тоже проверять по несколько раз не стоит, всё должно подчинятся какой-то логике…
Об этом и речь. Вы не прогоняете regression tests руками — тесты, которые проверяют, а не отвалился ли существующий/старый функционал при добавлении нового. Это не делают по разным причинам, основная — по мере разработки слишком дофига функционала нужно перетестировать, ресурсов ручного тестирования просто не хватает.

В идеале же test automation позволяет записывать все ваши тесты: разработчик выполняет тест вручную 1 раз для каждого нового функционала; тест записывается; и затем на каждый коммит можно в автоматическом режиме проверить, не ломает ли он что-либо уже существующего.
>>разработчик выполняет тест вручную
простите, тестер, конечно же
В теории, должен существовать набор smoke-тестов, то есть таких тестов, который покрывают минимальный общий функционал, без которых дальнейшее тестировании бессмысленно. Обычно это небольшой тест, который прогоняется после каждой сборки приложения
Apache Maven создавался для управления полным жизненным циклом приложений — от создания до внедрения, с модульными и интеграционными тестами.
>>Автотесты же не нужно переписывать, нужно только создавать новые
Это грубая ошибка. Я бы сказал даже так, что автотесты при большинстве случаев приходится переписывать под новую бизнес логику, а писать автотесты на уже законченный и более не разрабатываемый продукт смысла не имеет.
Вы как то упускаете автоматизацию функционального тестирования десктоп приложений. А при этом типе автоматизации тоже очень много инструментария.
Формулировка не совсем точная, согласен. Поправлю.

Автотесты нужны для регрессионного тестирования. Регрессионное тестирование — тестирование неизменного для данного релиза/патча/исправления функционала. Если меняется бизнес-логика — это значит изменился и функционал. В этом случае, естественно, что старые автотесты для данного участка не подойдут. Но полное изменение бизнес-логики бывает достаточно редко, согласитесь.

Возьмем пример: толстый клиент управления складом. Текущее количество бизнес-процессов, скажем 10. Заказчик хочет внедрить еще один процесс и изменить 2 существующих. В этом случае мы оставляем 8 автотестов в неизменном виде. Изменяем 2 (обычно изменения незначительные) и создаем один новый.

Для автоматизации десктоп приложений существует множество инструментов, в этом я с Вами согласен: и silktest, и testcomplete, и Ranorex и т.д. Но профессионально использовал только QTP и White. А я как-то не привык рекомендовать что-то о чем мало знаю :)
я и не имел в виду полное изменение автотестов.
Я специально цитировал высказывание которое считал ошибочным. По остальным пунктам и не собирался даже :)
10 Причин провала автоматизации

Сорри, вот линк sqadotby.blogspot.com/2009/06/10.html

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории