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

Question

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

Answer 1

Selenium имеет хорошую среду для веб-тестирования

http://seleniumhq.org/

Telerik также находится в процессе разработки для тестирования веб-приложений.

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

Answer 2

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

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

Взаимодействие с пользователем ничем не отличается. Есть определенные вещи, которые пользователи попытаются сделать, патологические или нет, и вы можете ожидать их. Пользователи просто вводят особенно творческие данные. Вы обнаружите, что программисты, как правило, пропускают одни и те же условия снова и снова. Я держу контрольный список. Например: качать Unicode во все; поставить дату начала после даты окончания; введите бредовые данные; положить теги во всем; пропустить завершающий перевод строки; попробуйте ввести одни и те же данные дважды; отправьте форму, вернитесь и отправьте ее снова; возьмите текстовый файл, назовите его foo.jpg и попробуйте загрузить его как изображение. Вы даже можете написать программу для случайного переключения переключателей и кнопок, плохая обезьяна, которая найдет все виды забавных ошибок.

Часто это так же просто, как сесть на кого-то, кто не знаком с программным обеспечением, и наблюдать, как они его используют. Боритесь с желанием исправить их, просто наблюдайте за их камбалой. Это очень познавательно. Стив Круг называет это «Продвинутый здравый смысл» и имеет отличную книгу под названием «Не заставляй меня думать», в которой рассматриваются дешевые и простые тесты взаимодействия с пользователем. Я очень рекомендую это. Это очень короткое и открывающее глаза чтение.

Наконец, сам клиент, если его ожидания должным образом подготовлены, может стать фантастическим набором тестов. Убедитесь, что они понимают, что он находится в стадии разработки, что в нем есть ошибки, что они помогают улучшить свой продукт, и что его абсолютно не следует использовать для производственных данных, и пусть они возятся с предварительными версиями ваш продукт. Они будут делать все, о чем вы никогда не думали! Они будут лучшим и самым реалистичным тестированием, которое вы когда-либо проходили, БЕСПЛАТНО! Дайте им очень простой способ сообщать об ошибках, желательно всего в одной кнопке прямо в приложении, которая автоматически передает их среду и историю; окно обратной связи на Hiveminder является отличным примером. Отвечайте на их ошибки быстро и вежливо (даже если это просто «спасибо за информацию»), и вы обнаружите, что они будут рады, что вы так отзывчивы к их потребностям!

Answer 3

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

Answer 4

Если вы пишете много Javascript, в последнее время появилось много фреймворков JS для блочного тестирования вашего Javascript.

Кроме этого, тестирование веб-уровня с использованием чего-то вроде Canoo, HtmlUnit, Selenium и т. Д. Является скорее функциональным или интеграционным тестом, чем модульным тестом. Их может быть сложно поддерживать, если у вас сильно изменился пользовательский интерфейс, но они действительно могут пригодиться. Записывать тесты Selenium легко, и вы, вероятно, могли бы попросить других людей (тестеров) помочь вам создать и поддерживать их. Просто знайте, что поддержание тестов сопряжено с расходами, и их необходимо сбалансировать.

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

Answer 5

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

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

Answer 6

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

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

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

Хорошие рамки для приемочного испытания:

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

Однако

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

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

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

Answer 7

Я создал решение для веб-тестирования (Docker + Cucumber); это очень простой и простой, так что легко понять и изменить / улучшить. Он лежит в веб-каталоге;

мое решение: https://github.com/gyulaweber/hosting_tests