Сообщений в теме: 16

[Legend]

Здраствуйте!
Возникла такая необходимость у компании автоматизировать тестирования с помощью Microsoft Team System. Сам я узнал об Team System неделю назад, сейчас вот изучаю её, пока не успешно. Многое не понимаю.
Раньше (когда я работал в другой компании) автоматизировал тесты с помощью mercury quick test professional и достаточно удобная программулина для автоматизации.
Поэтому появились вопросы:
1. Расскажите пожалуйста как можно автоматизировать тесты с помощью Microsoft Team System?Может какие отдлельные утилиты нужно установить или ещё что-то?
2. Возможно ли там так же как в mercury quick test записывать сценарии, потом их редактировать?
По возможности расскажите подробно.

[Troubleshooter]

1. Читайте документацию к продукту.
2. Есть возможность записывать сценарии и потом их редактировать, но это не есть решение для хорошей автоматизации.
Использование Microsoft Team System (а конкретнее Team Test) подразумевает знание одного из языков поддерживаемого студией для написания тестов.

[Plut]

Legend, как продвигается изучение вижалСтудии для тестеров ? чего удалось достич к этому времени??

[ashamray]

Всем привет!

Недавно также задумался об автоматизация функционального тестирования с помощью visual studio и в результате написал небольшой труд по этому делу, прошу посмотреть. В статье описаны подходы с помощью продуктов IBM Rational, но можно попробовать использовать и другие....... пробуйте :)
Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational

Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования и уже в visual studio 2010 будет свой тестменеджер и рекордер функциональных тестов. Так что можно или еще годик подождать или пробовать использовать описанное выше :). Инфа по тестированию в visual studio 2010:
http://blogs.msdn.com/amit_chatterjee/

[Green]

...
Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования ...

Team System Developer Center имеет блок по автоматизации тестирования (функционального и нагрузочного) - Test Edition.
http://msdn.microsof...m/dd408381.aspx

[ashamray]

Да, имеет. Но этот блок относится к Web-тестам.

...
Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования ...

Team System Developer Center имеет блок по автоматизации тестирования (функционального и нагрузочного) - Test Edition.
http://msdn.microsof...m/dd408381.aspx

[Troubleshooter]

Всем привет!

Недавно также задумался об автоматизация функционального тестирования с помощью visual studio и в результате написал небольшой руд по этому делу, прошу посмотреть. В статье описаны подходы с помощью продуктов IBM Rational, но можно попробовать использовать и другие....... пробуйте :)
Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational

Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования и уже в visual studio 2010 будет свой тестменеджер и рекордер функциональных тестов. Так что можно или еще годик подождать или пробовать использовать описанное выше :). Инфа по тестированию в visual studio 2010:
http://blogs.msdn.com/amit_chatterjee/

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

[Green]

Александр,

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

Вы эти данные где-то почерпнули или это Ваши собственные наблюдения?

[ashamray]

IBM Rational используется в качестве примера, показана в общем технология связывания.
Студия дорого - может быть и смотря для кого . Однако взглянем на проблему с другой стороны, со стороны командной разработки на базе TFS:

• Один инструмент для тестировщика:
  • Написание тестов - модульные тесты, ручные тесты, функциональные тесты (rft)
  • Выполнение тестов
  • Документирование результатов тестирования и дефектов
• Автоматизация процессов:
  • Сборка
  • Выполнение всех автоматических тестов после сборки
  • Автоматическое документирование дефектов

Всем привет!

Недавно также задумался об автоматизация функционального тестирования с помощью visual studio и в результате написал небольшой руд по этому делу, прошу посмотреть. В статье описаны подходы с помощью продуктов IBM Rational, но можно попробовать использовать и другие....... пробуйте :)
Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational

Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования и уже в visual studio 2010 будет свой тестменеджер и рекордер функциональных тестов. Так что можно или еще годик подождать или пробовать использовать описанное выше :). Инфа по тестированию в visual studio 2010:
http://blogs.msdn.com/amit_chatterjee/

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

[ashamray]

Почерпнул из практики нашей компании

Александр,

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

Вы эти данные где-то почерпнули или это Ваши собственные наблюдения?

[Troubleshooter]

IBM Rational используется в качестве примера, показана в общем технология связывания.
Студия дорого - может быть и смотря для кого . Однако взглянем на проблему с другой стороны, со стороны командной разработки на базе TFS:

• Один инструмент для тестировщика:
  • Написание тестов - модульные тесты, ручные тесты, функциональные тесты (rft)
  • Выполнение тестов
  • Документирование результатов тестирования и дефектов
• Автоматизация процессов:
  • Сборка
  • Выполнение всех автоматических тестов после сборки
  • Автоматическое документирование дефектов

Всем привет!

Недавно также задумался об автоматизация функционального тестирования с помощью visual studio и в результате написал небольшой руд по этому делу, прошу посмотреть. В статье описаны подходы с помощью продуктов IBM Rational, но можно попробовать использовать и другие....... пробуйте :)
Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational

Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования и уже в visual studio 2010 будет свой тестменеджер и рекордер функциональных тестов. Так что можно или еще годик подождать или пробовать использовать описанное выше :). Инфа по тестированию в visual studio 2010:
http://blogs.msdn.com/amit_chatterjee/

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

Зачем показывать нереалистические сценарии связывания? Или вы хотитие сказать, что у вас построен процесс на студии + Robot?

[ashamray]

В статье студия, робот, рфт и тестменеджер и показана возможность использования, что там нереального на ваш взгляд? :)

IBM Rational используется в качестве примера, показана в общем технология связывания.
Студия дорого - может быть и смотря для кого . Однако взглянем на проблему с другой стороны, со стороны командной разработки на базе TFS:

• Один инструмент для тестировщика:
  • Написание тестов - модульные тесты, ручные тесты, функциональные тесты (rft)
  • Выполнение тестов
  • Документирование результатов тестирования и дефектов
• Автоматизация процессов:
  • Сборка
  • Выполнение всех автоматических тестов после сборки
  • Автоматическое документирование дефектов

Всем привет!

Недавно также задумался об автоматизация функционального тестирования с помощью visual studio и в результате написал небольшой руд по этому делу, прошу посмотреть. В статье описаны подходы с помощью продуктов IBM Rational, но можно попробовать использовать и другие....... пробуйте :)
Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational

Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования и уже в visual studio 2010 будет свой тестменеджер и рекордер функциональных тестов. Так что можно или еще годик подождать или пробовать использовать описанное выше :). Инфа по тестированию в visual studio 2010:
http://blogs.msdn.com/amit_chatterjee/

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

Зачем показывать нереалистические сценарии связывания? Или вы хотитие сказать, что у вас построен процесс на студии + Robot?

[Green]

Почерпнул из практики нашей компании

Александр,

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

Вы эти данные где-то почерпнули или это Ваши собственные наблюдения?

Александр,

на мой субъективный взгляд, Ваши графики соответствуют действительности только на стадии прогонки тестов. Тогда ручное выполнение действительно "берет" больше времени чем автоматизированное. И, действительно, чем больше тестов, тем выигрыш во времени больше.

Но!

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

В итоге, автоматизированное тестирование дает выигрышь только в среднесрочной или долгосрочно перспективе.

Но и в ней (перспективе) тоже не все так однозначно.

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

Так что я бы не стал приводить столь спорные графики без должного статистического анализа.

[SALar]

Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational

Н-да. Как бы это помягче сказать...

- Что я не попал?
- Не то, чтобы ты совсем не попал. Но ты не попал в шарик.

Уж не подрабатываете ли вы случайно "толкачами" этих тулов?

[ashamray]

Я занимаюсь проблемами командной разработки, а тулы - это уже средство достижения цели . Здесь же решил поделиться своим опытом, не более

Практика применения автоматического функционального тестирования в Microsoft Visual Studio с использованием средств IBM Rational

Н-да. Как бы это помягче сказать...

- Что я не попал?
- Не то, чтобы ты совсем не попал. Но ты не попал в шарик.

Уж не подрабатываете ли вы случайно "толкачами" этих тулов?

[barancev]

Уж не подрабатываете ли вы случайно "толкачами" этих тулов?

Сергей, это нечестный ход :)
Не секрет, что CM Consult распространяет и внедряет как TFS, так и продукты IBM Rational.
Но разве это имеет какое-то отношение к делу, если статья хороша сама по себе? А если не хороша -- тогда статью и критикуй.

[ashamray]

Трудно не согласиться с Вашим примером, КПД у одного специалиста будет вначале очень мал . Да и по этому вопросу можно вести много дискуссий. Скажу лишь, что пример взят с одной большой компании, в которой присутствует полноценный отдел тестирования и ведется разработка долгосрочного проекта.

Почерпнул из практики нашей компании

Александр,

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

Вы эти данные где-то почерпнули или это Ваши собственные наблюдения?

Александр,

на мой субъективный взгляд, Ваши графики соответствуют действительности только на стадии прогонки тестов. Тогда ручное выполнение действительно "берет" больше времени чем автоматизированное. И, действительно, чем больше тестов, тем выигрыш во времени больше.

Но!

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

В итоге, автоматизированное тестирование дает выигрышь только в среднесрочной или долгосрочно перспективе.

Но и в ней (перспективе) тоже не все так однозначно.

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

Так что я бы не стал приводить столь спорные графики без должного статистического анализа.