Методы (юнит) тестирования интерфейса сайта - PullRequest
3 голосов
/ 04 марта 2011

Мне интересно, каковы лучшие практики для проверки "функциональности интерфейса" веб-сайта.

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

Я попробую привести несколько примеров:

  1. на SO, когда вы вводите заголовок вашего нового вопроса, появляются некоторые «связанные вопросы». Очевидно, что вы можете реализовать своего рода тест, который скажет вам, что вы получили правильное количество связанных вопросов и что они отображаются, но как вы проверяете «правильность» ссылок? Вы бы установили фиктивный набор вопросов (всегда один и тот же) и проверили бы, чтобы возвращенные вопросы были заранее заданными? Это бы сработало, конечно, но вряд ли это проверяет надежность вашего алгоритма поиска. Что происходит, когда в пул добавляются другие вопросы? Возвращенные результаты все еще "связаны"?

  2. Нажав на определенную кнопку, вызывается JS, который генерирует «всплывающий элемент div», который пользователь может перемещать. Опять же, как вы автоматически тестируете этот вид интерфейса? Вы можете проверить на внешний вид, но как вы проверяете на движение?

  3. У вас есть интерфейс для загрузки файлов на сайт для встраивания в ваше сообщение (например, значок изображения здесь на SO). Таким образом, пользователь должен: 1) нажать кнопку 2) найти файл 3) дождаться загрузки 4) нажать OK и, наконец, он / она увидит изображение в сообщении. Опять же, я вижу, как можно автоматизировать тест для загрузки (например, попробуйте загрузить «обычный» файл, затем слишком большой, неподдерживаемого формата и т. Д.). Но как насчет использования интерфейса? Если кнопки OK или Browse не работают по какой-либо причине, бесполезно, чтобы загрузка работала, так как в конце дня вы все равно не можете загрузить свой файл и увидеть его в своем сообщении.

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

Ответы [ 2 ]

3 голосов
/ 04 марта 2011

То, что мы используем у нас, это Селен .У него есть несколько изюминок, но в целом это позволило нам значительно увеличить охват тестами, и я думаю, что несколько тысяч новых системных тестов появятся.Обратите внимание, что можно поспорить, если это действительно «модульное» тестирование.Это зависит от вашего стека, я думаю.Для этого нам нужно запустить нашу систему, так что это больше интеграционное тестирование.

Для чистого модульного тестирования JS мы используем QUnit , и HTMLUnit также оказался несколько популярным для тестов "на середине пути", которые не используютнастоящий браузер, но все равно дает вам DOM и еще много чего.

1 голос
/ 04 марта 2011

Некоторые из вас могут получить ответы на визуальные тесты, и для них есть отличная структура: http://sikuli.csail.mit.edu/

Это позволяет вам ожидать визуальных результатов и программно управлять веб-страницей.

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