понедельник, 23 мая 2011 г. - www.msmirnov.ru

От QTP к Selenium

Последние несколько лет мы использовали 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#.

P.S.
Другие мои посты на тему Selenium:
1. От QTP к Selenium
2. Создание тестов для Selenium на C# для web-приложений на ASP.NET
Мой сайт - www.msmirnov.ru

13 комментариев:

  1. >Полное отсутствие инструментария разработки.
    Есть плагин для Eclipse.

    ОтветитьУдалить
  2. А у нас тестеры отказались от Селениума в силу убогости оного.
    Я уже не помню точно, чего на него плевались (много всего было), но как раз один из минусов был в том, что требовалось какие-то скрипты править когда UI поменялся, визуально этого сделать нельзя, а в скриптах какие-то ID каких-то контролов и прочая байда.
    Было ещё много претезний, в общем, их вердикт был - годится для маленьких проектов на Руби, не более.

    А тестеры у нас - именно тестеры, странных метаморфоз из тестера в программеры не происходит :)

    ОтветитьУдалить
  3. По поводу ID - там поиск не только по ID, но и по классу, XPath, имени и пр.
    И если правильно скрипты писать - т.е. не хардкодить ID-шники в тест-кейсах, то проблем нет.
    Хотя, может они смотрели первую версию Selenium.

    ОтветитьУдалить
  4. Леш, тестеры у вас, я уверен, самые лучше, как впрочем и процессе и продукт и вообще все остальное.

    ОтветитьУдалить
  5. Alexey Raga Что вы используете вместо Selenium?

    ОтветитьУдалить
  6. Michael Smirnov Не, у нас, к сожалению, с тестерами полный напряг.
    Поэтому, наверное, все тестеры ушли (или их ушли, я не очень в курсе) и на их место наняли ребят из специальной конторы, которая занимается только тестированием и эти услуги и продаёт. Говорят, это очень дорого обходится.
    Так что у нас тестеров нет вообще, можно сказать, своих.

    ОтветитьУдалить
  7. Sergey Konyshev Спрошу, если не забуду. Я в эти дела вообще не суюсь :)

    ОтветитьУдалить
  8. Michael Nemtsev Что такое DevTest? Продукт, который вместо Selenium? Я не знаю, говорю же.. Узнаю завтра, если не забуду.

    ОтветитьУдалить
  9. Alexey Raga devtest это одна из лидирующих контор в австралии по тестированию. я имел в виду вы с ней работаете?

    ОтветитьУдалить
  10. Michael Nemtsev А... Я не знаю :) Мне говорили название, но я не запомнил.

    ОтветитьУдалить
  11. Мы использовали Test Complete несколько лет назад, но в итоге отказались от него в пользу QTP. Может сейчас Test Complete стал и лучше, но тогда он работал очень нестабильно - даже не мог толком дождаться конца PostBack'а - и предоставлял намного меньшую функциональность, чем QTP.

    Но, правда, то была версия Test Complete 3. Может сейчас они доработали его.

    ОтветитьУдалить