Веб-тестирование отличается от тестирования настольных приложений. При тестировании веб-приложений мы обычно используем браузер (клиент) для запроса веб-сайта с веб-сервера, связываясь с сервером через HTTP или HTTPS.
Когда мы, как тестировщики, участвуем в веб-тестировании, мы должны быть знакомы с основами HTTP, чтобы получить хорошее представление о том, как работают веб-приложения.
В веб-тестировании, помимо функционального тестирования отдельных и интегрированных компонентов, некоторые типы тестирования, такие как производительность, безопасность, кроссбраузерность и отзывчивость, которые не обязательно нужны при тестировании настольных приложений, приобретают большое значение в тестировании веб-приложений. Это связано с тем, что веб-приложения открыты для широкой аудитории, поэтому необходимо учитывать производительность.
Кроме того, веб-приложения более восприимчивы к атакам безопасности, таким как DDos и SQL-инъекции, и если веб-сайт является целью, время простоя может быть очень дорогостоящим, поэтому большое внимание следует уделять тестированию безопасности.
Все больше веб-сайтов создается с использованием веб-сервисов. Это дает возможность тестировщикам тестировать веб-приложение в изолированных компонентах, а не в полноценном интегрированном веб-приложении.
Преимущества изолированного тестирования веб-сервисов:
Браузер не задействован - Мы можем напрямую связываться с веб-службой, если знаем ее конечную точку и параметры для отправки.
Намного быстрее - Поскольку мы ориентируемся на изолированную веб-службу, не нужно загружать изображения, javascript или CSS, поэтому ответ будет намного быстрее.
Более легкая отладка - при тестировании веб-службы, если мы сталкиваемся с проблемой, гораздо проще определить причину проблемы, и поэтому отладка становится менее болезненной.
Больше контроля - у нас есть прямой контроль над тем, какой запрос мы отправляем веб-сервису, поэтому мы можем использовать все виды данных для сценариев ошибок веб-сервисов.
Мы можем использовать Инструмент SopaUI для тестирования веб-службы.
Тестирование производительности особенно важно при веб-тестировании, поскольку веб-приложение доступно для потенциально большого количества аудитории.
При тестировании веб-приложений мы должны не только обеспечить функциональную стабильность веб-сайта, но и убедиться, что приложение не дает сбоев при большой нагрузке на сервер.
К сожалению, большинство людей забывают о тестировании производительности веб-приложения или откладывают тестирование непосредственно перед выпуском, что уже слишком поздно. Если в дизайне или коде есть что-то принципиально неправильное, что может повлиять на производительность, мы не узнаем об этом, пока не станет слишком поздно.
Лучший подход - запускать проверку производительности так же часто, как и функциональные регрессионные тесты, чтобы мы были уверены, что производительность не снизилась в результате изменений в кодовой базе.
Jmeter - популярный инструмент нагрузочного тестирования с открытым исходным кодом, который можно использовать для проверки производительности сайта. Его также можно интегрировать в CI-сервер.
Поскольку существует разное количество браузеров, нам необходимо убедиться, что наше веб-приложение работает должным образом на всех из них (по крайней мере, в основных, например, в Google Chrome, Mozilla Firefox и Microsoft Internet Explorer), не говоря уже об Opera и Safari.
Как и при любом тестировании, нам нужно знать, какие браузеры и их версии поддерживает приложение, а затем соответствующим образом спланировать тестирование.
Тестирование всего в каждом браузере может занять очень много времени, поэтому мы можем использовать автоматизированные инструменты для проверки функциональности в разных браузерах.
Более того, существуют онлайн-инструменты кроссбраузерного тестирования, которые облегчают тестировщикам выполнение тестов в разных браузерах.
Судя по личному опыту, количество проблем, связанных с браузером, очень невелико и в основном связано с очень старыми версиями браузеров или с некорректным отображением CSS, что приводит к проблемам с макетом.
Следовательно, может не потребоваться запускать все тестовые примеры во всех браузерах, поскольку это может занять очень много времени (даже в автоматическом режиме) с очень небольшим выигрышем, а вероятность того, что что-то не работает, очень низка.
Наилучший подход - запустить все тестовые примеры в одном основном браузере, а затем выбрать несколько наиболее важных сценариев и запустить их в остальных браузерах.
Большинство компаний, разрабатывающих веб-приложения, используют гибкую модель разработки с частыми выпусками, поэтому необходимо частое тестирование. В веб-тестировании автоматизация тестирования может принести большую пользу, поскольку снимает бремя повторяющейся работы.
Помимо проверки функциональности, мы также можем использовать автоматизированные сценарии для создания тестовых данных, которые нам нужны во время веб-тестирования.
Еще один способ, которым автоматизация может помочь в ручном тестировании, - это такие инструменты, как Selenium WebDriver может делать скриншоты реальной страницы браузера. Если нам нужно визуально проверить большое количество страниц, например мы хотим знать, как локализованный текст отображается на разных веб-страницах, мы можем использовать этот инструмент, чтобы просматривать страницы и делать снимки экрана, а затем быстро проверять визуально.
Для получения дополнительной информации, пожалуйста, обратитесь к Советы и рекомендации по автоматизации тестирования
Довольно часто возникает необходимость проанализировать HTTP-трафик от браузера к нижестоящим серверам. Анализируя веб-трафик, мы можем углубиться в детали каждого запроса и ответа.
В веб-тестировании анализ HTTP-трафика особенно полезен при тестировании сторонних тегов отслеживания, таких как теги Google Analytics или универсальные теги на веб-страницах.
Мы не только можем проверить, что теги содержат правильные значения, мы можем фактически проверить, отправляются ли запросы соответствующим сторонним системам и что мы получаем действительный ответ, обычно код ответа 200 OK.
Чтобы иметь возможность визуализировать и записывать HTTP-трафик, мы должны использовать соответствующий инструмент, который действует как прокси и может прослушивать запросы и ответы между клиентом, обычно браузером, и серверами.
Вот некоторые из самых популярных инструментов, которые мы можем использовать для анализа HTTP-трафика:
Wireshark если вы хотите видеть все, что происходит в сети.
Скрипач если вы хотите просто отслеживать трафик HTTP / s.
Заголовки HTTP в реальном времени если вы работаете в Firefox и хотите быстро установить плагин для просмотра заголовков.
FireBug также может предоставить вам эту информацию и обеспечивает приятный интерфейс, когда вы работаете над одной страницей во время разработки. Я использовал его для отслеживания транзакций AJAX.
Все больше людей заходят на веб-сайты со своих мобильных телефонов. Это означает, что веб-тестирование больше не ограничивается браузерами на настольных компьютерах. Теперь нам нужно протестировать веб-приложения на мобильных платформах, а также на настольных компьютерах.
Существует два типа веб-приложений для мобильных устройств: те, которые специально разработаны для мобильных платформ, и те, которые являются «адаптивными», т. Е. Существует только одна версия веб-приложения, созданная для настольных и мобильных устройств, но приложение обрабатывается и обрабатывается. отображается по-разному в зависимости от размера устройства.
Оба типа требуют тестирования на мобильных устройствах и / или симуляторах.
Во время веб-тестирования, а также функционального тестирования, нам также необходимо проверять, помимо прочего: