Надежное тестирование GUI веб-приложений

Question

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

Я посмотрел на http://sikuli.csail.mit.edu/ и мне это очень понравилось, но опять же, это не очень надежно, так как очень часто он не может определить правильные кнопки / ссылки.

Каков хороший подход для тестирования веб-приложений?

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

Answer 1

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

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

Инструменты записи / воспроизведения должны называться Record / Tweak / Replay, чтобы они могли правильно обрабатывать тесты.

Написание ваших тестов для Selenium RC или WebDriver (в настоящее время они объединяются для создания Selenium 2) позволяет вам решать проблемы, которые вы можете увидеть в Selenium IDE. Это заставляет вас писать тесты, используя языки программирования, такие как Java, Python, C # и многие другие. Так как вы можете добавлять условные выражения в свои тесты.

Чтобы у меня было меньше технических специалистов, чтобы использовать Selenium, нужно создать DSL , чтобы они были более естественными при написании тестов.

Answer 2

Посмотрите на Сахи .

1. Не нужно ждать Ajax или загрузки страницы.

2. Он не использует XPath, вместо него используются DOM отношения (_near, _in).

3. Он автоматически пересекает фреймы / фреймы

4. Рекордер работает для фреймов, фреймов и всплывающих окон

5. Хорошо обрабатывает автоматически сгенерированные идентификаторы

6. Устройство записи и воспроизведения работает практически во всех браузерах и операционных системах.

7. Он не использует специальные привилегии для запуска тестов.

За последний год у Sahi было семь открытых выпусков, и поддержка на форумах была быстрой.

Отказ от ответственности: я автор Sahi.

Answer 3

Может быть, посмотрите на iMacros для Firefox , он работает довольно хорошо и может делать много безумных вещей (полная поддержка AJAX, Flash, Flex, Silverlight, поддержка Applets, диалоги веб-страниц поддержка и т. Д.). Вы найдете (возможно, необъективное) сравнение с Selenium здесь .

Другой вариант - использовать WebDriver (который будет объединен с Selenium для создания Selenium 2, как упомянуто в другом ответе, но, тем не менее, он использует другой подход). См. Представление WebDriver , чтобы узнать больше об этом (и чем он отличается).

Но я бы попробовал iMacros.

Answer 4

Вместо использования selenium.waitForPageToLoad("30000"); используйте вот так

selenium.waitForPageToLoad (Тайм-аут);

и не забудьте установить время ожидания с помощью опции settimeout

selenium.setTimeout (Тайм-аут);

Я тоже столкнулся с такими же проблемами с таймаутом. После установки времени ожидания все работало хорошо.