Comments 24
Мало :) Еще давайте )
+1
О чем? :) об автоматизации в общем или о чем-то конкретном с примерами?
+1
Если будет и о том, и о другом, будет отлично. А если примеры применения бесплатных тулов из жизни приведете, да еще и с рекордерами, да еще и для Win32 — вообще цены не будет.
А то мы, например, самописьками на AutoIt пользуемся, стыдно признаться.
А то мы, например, самописьками на AutoIt пользуемся, стыдно признаться.
0
Лично от себя могу порекомендовать WatiN для .NET или WatiJ для Java(последний как-то не очень развивается). В селениуме одновременно плюсом и минусом является запуск тестов через прокси, то есть через сам селениум, который является Java приложением. Минусом является то, что требуется запускать его(прокси) помимо основного теста, тогда как в WatiN можно тест скомпилировать в один exe файл и давать людям как раз из разряда «тестировщиков низкой квалификации по n-денег». Давно хочу написать про WatiN\WatiJ, но вот как то с кармой в прошлом накосячил(Данное предложение ни в коем случае не является просьбой поднять карму :), лучше скажите как в песочницу написать)
+1
Автотест:
1. Ввод данных — ~10*0.1 = 1 секунда
2. Отображение таблицы – 2 секунды
3. Поиск нужной строки – 0.5 секунды
4. Проверка соответствия введенных данных – 0.5 секунды
Информация не совсем верная :) Такое мы получаем в идеальном случае. В реальном приложении всё будет несколько медленной. Например есть веб-страница, на страничке есть AJAX запрос, так что иногда приходится ждать пока произойдет взаимодействие с сервером etc.
1. Ввод данных — ~10*0.1 = 1 секунда
2. Отображение таблицы – 2 секунды
3. Поиск нужной строки – 0.5 секунды
4. Проверка соответствия введенных данных – 0.5 секунды
Информация не совсем верная :) Такое мы получаем в идеальном случае. В реальном приложении всё будет несколько медленной. Например есть веб-страница, на страничке есть AJAX запрос, так что иногда приходится ждать пока произойдет взаимодействие с сервером etc.
0
в этом случае ждать приходится и человеку тоже.
0
Ручному тестировщику тоже нужно будет сделать AJAX запрос к чашке кофе или в аську. :) Так что для него тоже приведен идеальный вариант. Автоматизация же не призвана ускорять приложение — для этого есть нагрузочное тестирование :)
0
Вы меня чуть чуть не поняли. Например, какой нибудь абстрактный «босс» прочитает ваш пост и подумает: «Круто! В разы уменьшает время тестирования!». Потом он дает команду QA сделать автотесты, но в приложении встречается пара таких палок в колёса по типу AJAX. QA справляется с ними, добавляя что-то типо waitForComplete(), но потом на это смотрит «Босс» и говорит: «Эй! Что это у вас так всё медленно! Я читал что на это тратится всего 4 секунды! А у вас целых 20! Что за фигня! Вы ничего не умеете!» etc. В конце концов достается QA отделу, и лично тому кто делал тесты.
+1
Есть очень много других средст тестирования как платных, так и бесплатных.
Из своего опыта могу поделиться такой программой как BadBoy — бесплатная программа для тестирования веб-сайтов. Мы ее активно используем для ежедневной проверки наших главный сайтов. Небольшая, простая в использовании, хорошо документированная, немногожко глюков конечно есть, но жить можно :).
Также большой список различных средств тестирования веб-сайтов доступен тут.
Могу еще порекомендовать TestComplete. Хоть он и платный, но очень хорошо подходит для тестирования как веб-сайтов, так и Win приложений.
Из своего опыта могу поделиться такой программой как BadBoy — бесплатная программа для тестирования веб-сайтов. Мы ее активно используем для ежедневной проверки наших главный сайтов. Небольшая, простая в использовании, хорошо документированная, немногожко глюков конечно есть, но жить можно :).
Также большой список различных средств тестирования веб-сайтов доступен тут.
Могу еще порекомендовать TestComplete. Хоть он и платный, но очень хорошо подходит для тестирования как веб-сайтов, так и Win приложений.
+1
На BadBoy посмотрю, спасибо.
Что касается TestComplete, то у него по сравнению с QTP есть один недостаток — «из коробки» он не интегрируется в HP (Mercury) Quality Center, который является практически отраслевым стандартом средств поддержки процесса тестирования в больших организациях. Сам по себе он, безусловно, хорош.
Что касается TestComplete, то у него по сравнению с QTP есть один недостаток — «из коробки» он не интегрируется в HP (Mercury) Quality Center, который является практически отраслевым стандартом средств поддержки процесса тестирования в больших организациях. Сам по себе он, безусловно, хорош.
+1
Нужен обзор средств автоматического тестирования. Плюсы-минусы.
Про указанных в списке могу сказать только про Selenium — удобный, но неразвитый продукт. В частности записанный тест кейс спотыкается на iframe и редакторах, которые их используют. И если для фрейма можно допилить напильником, то редактор победить не удалось, похоже не умеет генерировать события правильно.
Также напильник нужен для AJAX-а. И вообще тесты требуют напильника и знаний/опыта как это работает. Рекламируемая простота — только для банальных хомяков.
Иногда тесты с отслеживанием событий, проверками и действиями с ожиданием, почему-то может не работать на Fast. Может быть и на Slow что-то не работает.
Не умеет работать с запросам к серверу, то есть GETы можно прописать вручную, но это наиболее легкая для автоматизации часть полностью упущена. Что-то есть для
А вообще тулза супер! :) Простые вещи делаются быстро, сложные — по-разному, как и бывает обычно. Добавить автоматическое тестирование запросов к серверу с параметризацией — цены бы ему не было.
Открытые исходники дают возможность допилить самому.
Не проверял, но рекламируется возможность удаленного тестирования на сервере и организовывать кластеры.
Про указанных в списке могу сказать только про Selenium — удобный, но неразвитый продукт. В частности записанный тест кейс спотыкается на iframe и редакторах, которые их используют. И если для фрейма можно допилить напильником, то редактор победить не удалось, похоже не умеет генерировать события правильно.
Также напильник нужен для AJAX-а. И вообще тесты требуют напильника и знаний/опыта как это работает. Рекламируемая простота — только для банальных хомяков.
Иногда тесты с отслеживанием событий, проверками и действиями с ожиданием, почему-то может не работать на Fast. Может быть и на Slow что-то не работает.
Не умеет работать с запросам к серверу, то есть GETы можно прописать вручную, но это наиболее легкая для автоматизации часть полностью упущена. Что-то есть для
А вообще тулза супер! :) Простые вещи делаются быстро, сложные — по-разному, как и бывает обычно. Добавить автоматическое тестирование запросов к серверу с параметризацией — цены бы ему не было.
Открытые исходники дают возможность допилить самому.
Не проверял, но рекламируется возможность удаленного тестирования на сервере и организовывать кластеры.
+1
Для небанальных хомяков существуют коммерческие средства автоматизации. Например, упомянутые уже Testcomplete и QTP от HP. В селениуме мне понравилось наличие рекордера, что его как-то сближает с коммерческими инструментами. Некоторые вещи, как справедливо было замечено, можно делать очень быстро.
Правда и в коммерческих тулзах простые вещи делаются очень быстро, а сложные — как обычно :) Особенно часто это проявляется, если на странице есть «нестандартные» элементы управления, например, набор дивов, который выглядит и ведет себя как combobox. Помучиться пришлось изрядно %(
Правда и в коммерческих тулзах простые вещи делаются очень быстро, а сложные — как обычно :) Особенно часто это проявляется, если на странице есть «нестандартные» элементы управления, например, набор дивов, который выглядит и ведет себя как combobox. Помучиться пришлось изрядно %(
0
> Причем стадия «Проведение тестирования» включает в себя тестирования всего объема функциональности – и старого, и нового.
Вот с этим не согласен. Я например смотрю, какие изменения выложил разработчик в SVN (обычно с пометками, что добавлено/исправлено/изменено) и уже этот функционал и гоняю, потом когда подходит время релиза или просто нечего делать — приступаю к тестированию всего функционала, т.е. одно и тоже проверять по несколько раз не стоит, всё должно подчинятся какой-то логике…
Вот с этим не согласен. Я например смотрю, какие изменения выложил разработчик в SVN (обычно с пометками, что добавлено/исправлено/изменено) и уже этот функционал и гоняю, потом когда подходит время релиза или просто нечего делать — приступаю к тестированию всего функционала, т.е. одно и тоже проверять по несколько раз не стоит, всё должно подчинятся какой-то логике…
0
Об этом и речь. Вы не прогоняете regression tests руками — тесты, которые проверяют, а не отвалился ли существующий/старый функционал при добавлении нового. Это не делают по разным причинам, основная — по мере разработки слишком дофига функционала нужно перетестировать, ресурсов ручного тестирования просто не хватает.
В идеале же test automation позволяет записывать все ваши тесты: разработчик выполняет тест вручную 1 раз для каждого нового функционала; тест записывается; и затем на каждый коммит можно в автоматическом режиме проверить, не ломает ли он что-либо уже существующего.
В идеале же test automation позволяет записывать все ваши тесты: разработчик выполняет тест вручную 1 раз для каждого нового функционала; тест записывается; и затем на каждый коммит можно в автоматическом режиме проверить, не ломает ли он что-либо уже существующего.
+1
В теории, должен существовать набор smoke-тестов, то есть таких тестов, который покрывают минимальный общий функционал, без которых дальнейшее тестировании бессмысленно. Обычно это небольшой тест, который прогоняется после каждой сборки приложения
0
Apache Maven создавался для управления полным жизненным циклом приложений — от создания до внедрения, с модульными и интеграционными тестами.
0
>>Автотесты же не нужно переписывать, нужно только создавать новые
Это грубая ошибка. Я бы сказал даже так, что автотесты при большинстве случаев приходится переписывать под новую бизнес логику, а писать автотесты на уже законченный и более не разрабатываемый продукт смысла не имеет.
Вы как то упускаете автоматизацию функционального тестирования десктоп приложений. А при этом типе автоматизации тоже очень много инструментария.
Это грубая ошибка. Я бы сказал даже так, что автотесты при большинстве случаев приходится переписывать под новую бизнес логику, а писать автотесты на уже законченный и более не разрабатываемый продукт смысла не имеет.
Вы как то упускаете автоматизацию функционального тестирования десктоп приложений. А при этом типе автоматизации тоже очень много инструментария.
+2
Формулировка не совсем точная, согласен. Поправлю.
Автотесты нужны для регрессионного тестирования. Регрессионное тестирование — тестирование неизменного для данного релиза/патча/исправления функционала. Если меняется бизнес-логика — это значит изменился и функционал. В этом случае, естественно, что старые автотесты для данного участка не подойдут. Но полное изменение бизнес-логики бывает достаточно редко, согласитесь.
Возьмем пример: толстый клиент управления складом. Текущее количество бизнес-процессов, скажем 10. Заказчик хочет внедрить еще один процесс и изменить 2 существующих. В этом случае мы оставляем 8 автотестов в неизменном виде. Изменяем 2 (обычно изменения незначительные) и создаем один новый.
Для автоматизации десктоп приложений существует множество инструментов, в этом я с Вами согласен: и silktest, и testcomplete, и Ranorex и т.д. Но профессионально использовал только QTP и White. А я как-то не привык рекомендовать что-то о чем мало знаю :)
Автотесты нужны для регрессионного тестирования. Регрессионное тестирование — тестирование неизменного для данного релиза/патча/исправления функционала. Если меняется бизнес-логика — это значит изменился и функционал. В этом случае, естественно, что старые автотесты для данного участка не подойдут. Но полное изменение бизнес-логики бывает достаточно редко, согласитесь.
Возьмем пример: толстый клиент управления складом. Текущее количество бизнес-процессов, скажем 10. Заказчик хочет внедрить еще один процесс и изменить 2 существующих. В этом случае мы оставляем 8 автотестов в неизменном виде. Изменяем 2 (обычно изменения незначительные) и создаем один новый.
Для автоматизации десктоп приложений существует множество инструментов, в этом я с Вами согласен: и silktest, и testcomplete, и Ranorex и т.д. Но профессионально использовал только QTP и White. А я как-то не привык рекомендовать что-то о чем мало знаю :)
0
10 Причин провала автоматизации
0
Сорри, вот линк sqadotby.blogspot.com/2009/06/10.html
0
Sign up to leave a comment.
Articles
Change theme settings
Автоматизация функционального тестирования: что это такое и как это может быть полезно