Visual Studio и автоматизация тестирования.

общие вопросы
#1

Visual Studio и автоматизация тестирования.

Уважаемые друзья тестеры, помогите со следующими вопросами -

Наша компания работает с Visual Studio 2012, но отдел тестирование это не как не касается.

Так как мне стало скучно и я решил предложить начальству автоматизировать часть рутинных тестов, но в итоге от меня отбрехались, так как было много работы.
Начальство говорит, что если хотите то автоматизируйте средствами Visual Studio.
Команда тестеров из 6 человек, навыками программирования никто не обладает.

Отсюда вопросы:
1) Я предлагаю использовать что-нибудь на подобии QTP или TestComplete (просто в освоении).
Насколько  инструменты в Visual Studio 2012 могут конкурировать с данными продуктами в простоте и удобстве автоматизации? Какой потенциал имеет Visual Studio 2012  автоматизации?

2) Я только начал разбираться с Visual Studio 2012, но на первый взгляд о  больше заточен под юнит тестирование. Перед нами же стоит задача автоматизация GUI тестов.
Наскольоко оправдает себя использование Visual Studio 2012 для автоматизации GUI тестов?

3) Вообще требуется простой и удобный инструмент, для написания (на начальных этапах рекордером) автоматических GUI тестов. Что бы Вы выбрали из перечисленных инструментов? Или посоветуйте какой нибудь другой  инструмент?

 

#2

Привет!

1. Visual Studio  - это не инструмент автоматизации. Нельзя сказать - "Я автоматизирую с помощью студии". В студии просто идет работа с кодом.

2."Так как мне стало скучно и я решил предложить начальству автоматизировать часть рутинных тестов" отличный мотиватор, я бы тоже отбрехался. Нужно реально понять для чего и как вам поможет автоматизация. И начальству выгодно "продать" идею. Например, у нас есть такие то проблемы, но если автоматизировать это и это, то проблемы исчезнут и мы сможем получить выгоду. (читайте про ROI))

3. После понимания выбирайте инструмент для автоматизации (Например если веб приложение - можно выбрать webdriver, если десктоп - можно выбрать Coded UI (он уже встроен в студию))

Желаю вам удачи!

#3

1. Студия - комплексный инструмент, с кучей бесплатных плагинов. Coded UI вполне может записывать тесты (но разбираться в коде придётся, иначе он вам половину кликов запишет по смещению. Да и вообще генерённого кода обычно мало для хорошего теста).

Под студию начали прогибаться производители, к примеру Infragistics (очень упёртая контора, ранее не желавшая поддерживать UI Automaiton) выпустила аддын/плагин под студию для своих WPF и новее наборов контролов.

Если вы о keyword-driven testing, как это принято в "тулах для тестирования" (накликал, клики выглядят как иконки, подвигал иконки шагов теста мышкой), так ведь есть и бесплатные аналоги.

Преимущество платных тулов для тестирования: под тулы с долей на рынке охотно прогибаются производители контролов (за какие-то $3k вы можете прикупить плагин для QTP или RFT, а это ведь одна-две зарплаты инженера. А с контролами типа Infragistics далеко не всякий инженер за два месяца своими руками справится). Производителм тулов с малой долей на рынке (тесткомплит, ранорекс и подобные) сами активно ищут возможности автоматизировать всё, что только кликается/набирается.

2. Да! Бизнес-выгода надо уметь найти/придумать и "продать". Ищите белую бумагу. Например, вот так: "smartbear.com: white paper". Сможете найти что-нибудь вроде: http://support.smartbear.com/pdf/6_Tips_for_Automated_Test.pdf

#4

дубль

#5

По поводу второго пункта)))

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


Как я объяснил начальству -

1) Мы можем автоматизировать до 40 процентов тест кейсов, что приведет, к повышению качества продукта и высвобождению времени для других задач. (у нас то тишина неделю, то аврал целый месяц)
2) Повышение квалификации специалистов (многие тестеры в нашей компании реально хотят научится чему то новому).
3) Экономия денег компании, т.к. хотят еще набрать двух тестеров, но если мы начнем автоматизировать, то они буду не нужны.

Объективные причины отказа -

Нашему КЮЭЙ менеджеру 60 лет, ему не нужно ничего нового.

#6

Так же доступа к коду у нас не будет, а бес исходного кода программы тесты не запишешь, насколько я понял?

#7

Для написания тестов используем связку Visual Studio + TestComplete. Из TestComlete используем возможность Connected Application. Для запуска таких тестов нужен только пустой проект с NameMapping.

Для написания тестов используем BDDFy. По сути тесты выглядят как обычные модульные тесты, но только работают через GUI.

Python использеум для запуска тестов через планировщик.

#8

Можно без исходников - Coded UI работает через UIA COM wrapper и какие-то свои ещё наработки (первое - тоже майкрософт, но команда именно самой студии выпускает ещё фичепаки, они где-то на кодеплексе. Для 2012-й, наверное, фичепаки пока не нужны, новый релиз).

Мы тоже автоматизируем без исходников - а смысл в них, всё равно никто open/connected application не будет собирать.

#9

Обязательно читать перед тем как начинать автоматизацию 

http://blog.shumoos.com/archives/272

 

Если есть огромное желание автоматизировать, а начальство не хочет (классическая ситуация, низы хотят а верхи уже не могут), почитайте, в интернете полно похожих тем, вы не одиноки.

И помните, автоматизация это не серебряная пуля. Иногда она даже противопоказана.

 

P.S.

Тестирование - это сервис. 

#10

Тестирование GUI тоже развивается. 

И средней руки тестировщики могут ходить по XPath в Ranorex, или по точечной нотации в тулах, которые тестят "изнутри" (сидят в этом же или соседнем треде): frmMain.lvwOrders.lviJohnSmith.Click();

Подобной нотации можно обучить не-программистов. Кстати говоря, в тестировщики всё-таки идут сейчас с комрьютерными специальностями или все подряд? Большинство техвузы дают небольшой опыт точечной нотации, и обучают отличать проперти от методов.

Т.е. можно попытаться поработать с вещами верхнего уровня (через XPath, точечную нотацию или ещё как). Иными словами, выпускать народ на огариченную полянку, где надо быстро описать окно или несколько контролов.

К примеру, я недавно решил повернуться ближе к народу и выражается это в начатой и обещанной поддержке Keyword-driven testing. Перетаскивания мышкой кликов ещё нет (но будет), пока что можно автоматизировать таким "кодом":

 

Get-Window -n calc* | Get-Button -n 1 | Click-Button
 
 
или даже таким ( и powershell.exe, и powershell_ISE.exe это поддерживают)
 
Получить-Окно -Name calc* | Взять-Кнопку -Name 1 | Кликнуть-ПоКнопке
# -Name тоже надо будет переименовывать в -Имя
http://softwaretestingusingpowershell.com/2012/10/17/powershell-3-0-with-excellent-support-of-localized-cmdlets/
 
Понятен ли такой "код" не-программистам или даже самому боссу? (конечно, русский язык - это может быть неудобством во многих отношениях, но, на удивление, работает)
 
На всякий случай, я о вашем приложении ничего не знаю, может, на нём ещё и не работает...