Какой смысл селена? - PullRequest
       11

Какой смысл селена?

28 голосов
/ 06 марта 2009

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

Я не понимаю ...

Ответы [ 15 ]

44 голосов
/ 06 марта 2009

Это позволяет вам писать функциональные тесты в вашей "модульной" среде тестирования (проблема заключается в названии более поздней версии).

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

Что-то действительно приятное, это то, что вы можете автоматизировать свои тесты на дым, и QA может увеличить их. Довольно эффективно, так как уменьшает дублирование усилий и сближает всю команду.

Ps, как и любая практика, которую вы используете в первый раз, она имеет кривую обучения, поэтому обычно она занимает больше времени в первый раз. Я также предлагаю вам взглянуть на шаблон Page Object , это помогает поддерживать чистоту тестов.

Обновление 1: Обратите внимание, что тесты также будут запускать javascript на страницах, что помогает тестировать высокодинамичные страницы. Также обратите внимание, что вы можете запускать его в разных браузерах, чтобы вы могли проверять кроссбраузерные проблемы (по крайней мере, на функциональной стороне, так как вам все еще нужно проверять визуальный интерфейс).

Также обратите внимание, что по мере увеличения количества страниц, охватываемых тестами, вы можете быстро создавать тесты с полным циклом взаимодействий. Используя шаблон объекта Page они выглядят так:

   LastPage aPage = somePage
      .SomeAction()
      .AnotherActionWithParams("somevalue")
      //... other actions
      .AnotherOneThatKeepsYouOnthePage(); 
  // add some asserts using methods that give you info
  // on LastPage (or that check the info is there).
  // you can of course break the statements to add additional 
  // asserts on the multi-steps story.

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

21 голосов
/ 06 марта 2009

Это обычное явление, которое говорится о модульном тестировании в целом. «Мне нужно написать вдвое больше кода для тестирования?» Те же принципы применяются здесь. Выгода - это возможность изменить свой код и знать, что вы ничего не нарушаете.

15 голосов
/ 06 марта 2009

Поскольку вы можете повторять тест ЖЕ снова и снова.

9 голосов
/ 06 марта 2009

Если ваше приложение содержит более 50 страниц, и вам нужно делать частые сборки и тестировать его на X основных браузеров, это имеет большой смысл.

5 голосов
/ 06 марта 2009

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

Это практически невозможно проверить вручную. Он становится настолько подверженным человеческим ошибкам, что вы не можете гарантировать, что тестирование было выполнено правильно, не говоря уже о том, что тестирование подтвердило тестируемый объект.

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

На любом приличном размере веб-сайта тесты должны быть автоматизированы.

3 голосов
/ 06 марта 2009

Суть та же, что и для любого вида автоматического тестирования: написание кода может занять больше времени, чем «просто щелкать мышью и визуально проверять работоспособность», может быть, в 10 или даже в 50 раз больше.

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

2 голосов
/ 09 марта 2009

Selenium запишет и повторно запустит все ручные нажатия и ввод текста, которые вы делаете, чтобы протестировать ваше веб-приложение. Снова и снова.

Со временем изучение себя показало мне, что я склонен делать меньше тестов и начинаю пропускать некоторые или забывать о них.

Вместо этого Selenium будет проходить каждый тест, запускать его, если он не вернет то, что вы ожидаете, он может сообщить вам.

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

2 голосов
/ 09 марта 2009

Selenium (наряду с аналогичными инструментами, такими как Watir) позволяет запускать тесты с пользовательским интерфейсом веб-приложения таким образом, чтобы компьютеры были хорошими: тысячи раз за ночь или в течение нескольких секунд после каждой проверки источника. (Обратите внимание, что существует множество других тестируемых элементов пользовательского интерфейса, в которых люди намного лучше, например, замечают, что какая-то странная вещь, не имеющая прямого отношения к тесту, не подходит.)

Существуют и другие способы задействовать весь стек вашего приложения, глядя на сгенерированный HTML, а не запускать браузер для его рендеринга, например Webrat и Mechanize . Большинство из них не имеют способа взаимодействия с JavaScript-насыщенными пользовательскими интерфейсами; Селен уже кое-что рассказал.

1 голос
/ 06 марта 2009

Зачем тебе Селен? Потому что тестеры - это люди. Они идут домой каждый день, не всегда могут работать по выходным, болеть, устраивать праздничные дни, время от времени ездить в отпуск, им скучно выполнять повторяющиеся задания, и они не всегда могут полагаться на то, что они рядом, когда они вам нужны.

Я не говорю, что вам следует избавляться от тестеров, но инструмент автоматического тестирования пользовательского интерфейса дополняет системных тестеров.

1 голос
/ 06 марта 2009

На прошлой работе мы обычно тестировали наше веб-приложение. Если веб-приложение изменит свой внешний вид, тесты не нужно переписывать. Все тесты типа «запись и воспроизведение» необходимо будет заново выполнить.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...