Автоматическое тестирование на веб-проекты

У Selenium есть хорошая среда для веб-тестирования

http://seleniumhq.org/

Telerik также разрабатывает платформу для тестирования веб-приложений.

http: //www.telerik.com/products/web-ui-test-studio.aspx

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

Меня укусила довольно очевидная ошибка, которую можно было бы легко обнаружить, если бы у меня были интеграционные тесты.

If you're writing a lot of Javascript, there have been a lot of JS testing frameworks that have come around the block recently for unit testing your Javascript.

Other than that, testing the web tier using something like Canoo, HtmlUnit, Selenium, etc. is more a functional or integration test than a unit test. These can be hard to maintain if you have the UI change a lot, but they can really come in handy. Recording Selenium tests is easy and something you could probably get other people (testers) to help you create and maintain. Just know that there is a cost associated with maintaining tests, and it needs to be balanced out.

There are other types of testing that are great for the web tier - fuzz testing especially, but a lot of the good options are commercial tools. One that is open source and plugs into Rails is called Tarantula. Having something like that at the web tier is a nice to have run in a continuous integration process and doesn't require much in the form of maintenance.

Это действительно зависит от структуры и архитектуры вашего веб-приложения. Если он содержит уровень логики приложения, то этот уровень должно быть легко модульно тестировать с помощью таких средств автоматизации, как Visual Studio. Кроме того, очень помогает использование инфраструктуры, которая была разработана для обеспечения возможности модульного тестирования, такой как ASP.NET MVC.

Модульные тесты имеют смысл в процессе TDD. Они не имеют особой ценности, если вы не занимаетесь разработкой сначала тестированием. Однако приемочные испытания имеют большое значение для качества программного обеспечения. Я бы сказал, что приемочные испытания - это святой Грааль разработки. Приемочные испытания показывают, удовлетворяет ли приложение требованиям. Как мне узнать, когда следует прекратить разработку этой функции - только когда все мои приемочные испытания пройдут. Автоматизация приемочного тестирования - важная вещь, потому что мне не нужно делать все вручную каждый раз, когда я вношу изменения в приложение. После месяцев разработки могут быть сотни тестов, и становится невозможным (а иногда и невозможным) запускать все тесты вручную. Тогда как мне узнать, работает ли мое приложение?

Автоматизация приемочных испытаний может быть реализована с использованием тестовых фреймворков xUnit, что вносит здесь путаницу. Если я создаю приемочный тест с использованием phpUnit или httpUnit, будет ли это модульный тест? Мой ответ - нет. Неважно, какой инструмент я использую для создания и запуска теста. Приемочный тест - это тот, который показывает, соответствуют ли функции требованиям IAW. Модульный тест показывает, соответствует ли класс (или функция) идее реализации разработчика. Модульный тест не имеет значения для клиента (пользователя). Приемочное тестирование имеет большую ценность для клиента (и, следовательно, для разработчика, помните Привязанность к клиенту )

Поэтому я настоятельно рекомендую создавать автоматические приемочные тесты для веб-приложения.

Хорошими фреймворками для приемочного теста являются:

• Sahi (sahi.co.in)
• Silenium
• Simpletest (я не фреймворк модульного тестирования для php, но включает объект браузера, который может использоваться для приемочных испытаний).

Однако

Вы упомянули, что веб-сайт полностью посвящен взаимодействию с пользователем, и поэтому автоматизация тестирования не решит всей проблемы удобства использования. Например: структура тестирования показывает, что все тесты проходят, однако пользователь не может видеть форму, ссылку или другой элемент страницы из-за случайного style = "display: none" в div . Автоматические тесты проходят, потому что в документе присутствует div , и среда тестирования может его «видеть». Но пользователь не может. И ручное тестирование не пройдет.

Таким образом, все веб-приложения нуждаются в ручном тестировании. Автоматическое тестирование может значительно снизить нагрузку на тестирование (80%), но ручное тестирование также важно для качества конечного программного обеспечения.

Что касается модульного тестирования и TDD - это делает код качественным. Это выгодно для разработчиков и для будущего проекта (т.е. для проектов продолжительностью более пары месяцев). Однако TDD требует навыков. Если есть навык - используйте его. Если вы не думаете о приобретении навыка, но помните о времени, которое потребуется для его приобретения. Обычно создание хороших модульных тестов и кода занимает от 3 до 6 месяцев. Если ваш проект продлится больше года, я рекомендую изучить TDD и потратить время на правильную среду разработки.