Что вы используете для модульного тестирования своего веб-интерфейса?

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

Ответов (15)

Решение

Мы используем Watin по месту работы, мы являемся магазином .net, поэтому это решение имело большой смысл. На самом деле мы начали с Watir (исходной реализации Ruby), а потом переключились. До сих пор это было довольно хорошее решение для нас

В настоящее время мы используем Silk4J - ориентированный на Java подход к тестированию веб-интерфейса. Он может тестировать Flash, Flex, AIR, Silver Light, Win32, HTML и некоторые другие приложения.

Поскольку Silk4J может управлять приложениями Win32, он может напрямую управлять диалогами браузера, что на шаг выше того, что может контролировать Selenium, и особенно полезно для запросов на загрузку.

Мы используем Selenium Core, но постепенно переключаемся на Selenium RC, который намного приятнее и проще в управлении. Мы написали много специального кода, чтобы тесты запускались на наших серверах непрерывной интеграции, некоторые из них - в параллельных наборах, чтобы работать быстрее.

Вы обнаружите, что Selenium, похоже, перезапускает браузер для каждого теста (вы можете настроить его так, чтобы он не делал этого, но у нас возникли проблемы с памятью, когда мы это сделали). Это может быть медленным в Firefox, но не так уж плохо в IE (однажды я благодарен Биллу Гейтсу за интеграцию с ОС).

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

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

Если вы это сделаете, то единственным кодом в пользовательском интерфейсе будет код, вызывающий бэкэнд, поэтому достаточно просто протестировать бэкэнд.

Я использовал NUnit ASP в прошлом (на своей работе), и если вы настаиваете на модульном тестировании своего пользовательского интерфейса, я настоятельно рекомендую вам использовать ВСЕ, кроме NUnit ASP. С этим сложно работать, и тесты, как правило, становятся недействительными (нуждаются в пересмотре) даже после самых незначительных изменений пользовательского интерфейса (даже если субъекты тестов фактически не меняются).

Некоторое время мы использовали JSunit для выполнения модульных тестов ... возможно, это не те тесты, о которых вы говорите, но он отлично подходит для обеспечения того, чтобы ваш JavaScript работал так, как вы ожидаете.

Вы запускаете его в браузере, и его можно настроить в сборке Ant для автоматического запуска в группе браузеров на нескольких платформах удаленно (чтобы вы могли обеспечить кроссбраузерность вашего кода, а также убедиться, что логика верна. ).

Я не думаю, что он заменяет Selenium, но он хорошо его дополняет.

Я использовал WATIR , и это неплохо. Мне он понравился, потому что это Ruby и позволяет тестировать интерактивность, доступные элементы и анализ исходного кода. Я не пользовался им какое-то время, но полагаю, что стало лучше.

Предположительно он переносится на Firefox и Safari, но это уже давно происходит.

Проверьте Canoo Web Test . Он имеет открытый исходный код и построен на платформе ANT.

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

В основном я использую CubicTest , плагин eclipse, который позволяет определять тесты графически. Он может экспортировать / запускать тесты через несколько библиотек, включая watir и selenium. Однако большинство людей просто используют Selenium runner.

Полное раскрытие: я один из разработчиков, поэтому я предвзято :)

Взгляните сюда поближе: cubictest.openqa.org

-Эрленд

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

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

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

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

Хороший способ начать - использовать Selenium IDE как часть вашей разработки. То есть, просто откройте IDE, пока вы разрабатываете, и напишите свой тест, когда вы идете, чтобы сократить время разработки. (Вместо того, чтобы вручную просматривать пользовательский интерфейс, чтобы добраться до точки, где вы можете протестировать все, над чем вы работаете, просто нажмите кнопку, и Selenium IDE позаботится об этом за вас. Это потрясающая экономия времени!)

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

Я думаю, как и все остальное, если вы приложите усилия для правильного изучения инструмента тестирования (например, Selenium), ваши усилия окупятся в огромной степени. Вы упомянули, что ваша компания уже использует Selenium для тестирования пользовательского интерфейса. Отлично. Работай с этим. Если вы находите Selenium трудным или запутанным в использовании, придерживайтесь его. Кривая обучения действительно не такая уж и крутая, если вы немного изучите API.

Если я работаю над веб-приложением, мне редко приходится писать значительный объем кода без тестов Selenium RC для его резервного копирования. Вот насколько я считаю Selenium эффективным. :) (Надеюсь, это ответит на ваш вопрос ..)

Мы используем Visual Studio 2008 Tester Edition.

Плюсы: очень хорошо фиксирует взаимодействие с пользователем.

Захватывает вызовы Ajax

Очень легко сопоставить вводимые пользователем данные с базой данных, файлом XML или CSV.

Захваченный тест можно преобразовать в C# для большего контроля.

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

Минусы:

VS2008 Tester Edition - это отдельный SKU от обычного Developer Edition, что требует дополнительных затрат.

Вы можете быть обеспокоены Microsoft ;-)

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

Мы стараемся делать тесты короткими и четкими, делаем что-то одно и уходим вместо того, чтобы записывать 10 минут щелчков в одном тесте.

У нас есть несколько стандартных типов тестов пользовательского интерфейса:

Тест меню: войдите в систему как конкретный пользователь (или тип / роль пользователя) и убедитесь, что все необходимые пункты меню доступны.

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

Тест поиска: выполните поиск с использованием данных из вашей базы данных или файла данных и убедитесь, что поиск возвращает правильные данные.

Тест ввода данных: создание новых записей из файла данных, очистка базы данных, чтобы тесты можно было запускать несколько раз.

Тестирование пользовательского интерфейса занимает довольно много времени, но ощущение комфорта, которое вы испытываете, когда проходит несколько сотен тестов перед выпуском новой версии, бесценно.

Мы используем WatiN для тестирования системы и QUnit для модульного тестирования JavaScript.

Молибден построен на селене и имеет некоторые дополнительные функции.