Последние несколько лет мы использовали Mercury Quick Test Pro (QTP) для выполнения скриптов автоматизированного тестирования наших web-приложений.
В настоящий момент мы осуществляем переход к Selenium. Именно Selenium будет использоваться для выполнения скриптов регрессионного контроля.
Для нас Selenium имеет целый ряд преимуществ по сравнению с QTP:
1. Selenium бесплатный. QTP стоит очень дорого.
2. Selenium позволяет разрабатывать скрипты на том же языке программирования, на котором ведется основная разработка – C#, Java и пр. Это избавляет от необходимости изучать еще один язык программирования для разработки тестовых сценариев. Благодаря этому, разработчики могут при случае легко вносить изменения в тестовые сценарии, а тестировщики избавлены от необходимости переучиваться, при переходе в разработчики.
3. Так как разработка тестовых скриптов ведется в той же среде, что и основная разработка, скрипты Selenium могут использовать библиотеки тестируемого приложения в своих тестах – например, библиотеки бизнес-логики и пр.
4. Тестовые скрипты Selenium можно включать в наборы unit-тестов тестируемого приложения.
5. Разрабатывая тестовые скрипты на Selenium можно создавать дополнительную функциональность, которая требуется в данном конкретном случае – свой логгинг, свою отчетность, замеры времени тестирования и т.п.
Есть, конечно, и некоторые сложности во внедрении Selenium (куда же без них?):
1. Очень бедная документация.
2. Более высокие требования к опыту тестировщиков в плане умений программировать.
3. Полное отсутствие инструментария разработки.
4. Отсутствие возможности тестировать Windows-приложения.
Selenium продукт не новый, но поскольку мы его только осваиваем, в ближайшее время я планирую написать также заметку о том, как вести разработку тестовых скриптов для Selenium на C#.
В настоящий момент мы осуществляем переход к Selenium. Именно Selenium будет использоваться для выполнения скриптов регрессионного контроля.
Для нас Selenium имеет целый ряд преимуществ по сравнению с QTP:
1. Selenium бесплатный. QTP стоит очень дорого.
2. Selenium позволяет разрабатывать скрипты на том же языке программирования, на котором ведется основная разработка – C#, Java и пр. Это избавляет от необходимости изучать еще один язык программирования для разработки тестовых сценариев. Благодаря этому, разработчики могут при случае легко вносить изменения в тестовые сценарии, а тестировщики избавлены от необходимости переучиваться, при переходе в разработчики.
3. Так как разработка тестовых скриптов ведется в той же среде, что и основная разработка, скрипты Selenium могут использовать библиотеки тестируемого приложения в своих тестах – например, библиотеки бизнес-логики и пр.
4. Тестовые скрипты Selenium можно включать в наборы unit-тестов тестируемого приложения.
5. Разрабатывая тестовые скрипты на Selenium можно создавать дополнительную функциональность, которая требуется в данном конкретном случае – свой логгинг, свою отчетность, замеры времени тестирования и т.п.
Есть, конечно, и некоторые сложности во внедрении Selenium (куда же без них?):
1. Очень бедная документация.
2. Более высокие требования к опыту тестировщиков в плане умений программировать.
3. Полное отсутствие инструментария разработки.
4. Отсутствие возможности тестировать Windows-приложения.
Selenium продукт не новый, но поскольку мы его только осваиваем, в ближайшее время я планирую написать также заметку о том, как вести разработку тестовых скриптов для Selenium на C#.
P.S.
Другие мои посты на тему Selenium:
1. От QTP к Selenium
2. Создание тестов для Selenium на C# для web-приложений на ASP.NET
>Полное отсутствие инструментария разработки.
ОтветитьУдалитьЕсть плагин для Eclipse.
А у нас тестеры отказались от Селениума в силу убогости оного.
ОтветитьУдалитьЯ уже не помню точно, чего на него плевались (много всего было), но как раз один из минусов был в том, что требовалось какие-то скрипты править когда UI поменялся, визуально этого сделать нельзя, а в скриптах какие-то ID каких-то контролов и прочая байда.
Было ещё много претезний, в общем, их вердикт был - годится для маленьких проектов на Руби, не более.
А тестеры у нас - именно тестеры, странных метаморфоз из тестера в программеры не происходит :)
По поводу ID - там поиск не только по ID, но и по классу, XPath, имени и пр.
ОтветитьУдалитьИ если правильно скрипты писать - т.е. не хардкодить ID-шники в тест-кейсах, то проблем нет.
Хотя, может они смотрели первую версию Selenium.
Леш, тестеры у вас, я уверен, самые лучше, как впрочем и процессе и продукт и вообще все остальное.
ОтветитьУдалитьAlexey Raga Что вы используете вместо Selenium?
ОтветитьУдалитьMichael Smirnov Не, у нас, к сожалению, с тестерами полный напряг.
ОтветитьУдалитьПоэтому, наверное, все тестеры ушли (или их ушли, я не очень в курсе) и на их место наняли ребят из специальной конторы, которая занимается только тестированием и эти услуги и продаёт. Говорят, это очень дорого обходится.
Так что у нас тестеров нет вообще, можно сказать, своих.
Sergey Konyshev Спрошу, если не забуду. Я в эти дела вообще не суюсь :)
ОтветитьУдалитьAlexey Raga DevTest чтоли? :)
ОтветитьУдалитьMichael Nemtsev Что такое DevTest? Продукт, который вместо Selenium? Я не знаю, говорю же.. Узнаю завтра, если не забуду.
ОтветитьУдалитьAlexey Raga devtest это одна из лидирующих контор в австралии по тестированию. я имел в виду вы с ней работаете?
ОтветитьУдалитьMichael Nemtsev А... Я не знаю :) Мне говорили название, но я не запомнил.
ОтветитьУдалитьSergey Konyshev Они решили использовать Test Complete: http://www.automatedqa.com/products/testcomplete/
ОтветитьУдалитьМы использовали Test Complete несколько лет назад, но в итоге отказались от него в пользу QTP. Может сейчас Test Complete стал и лучше, но тогда он работал очень нестабильно - даже не мог толком дождаться конца PostBack'а - и предоставлял намного меньшую функциональность, чем QTP.
ОтветитьУдалитьНо, правда, то была версия Test Complete 3. Может сейчас они доработали его.