Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

Web-тестирование, особенности, виды, последовательность

Лекция



Привет, сегодня поговорим про web-тестирование, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое web-тестирование, web тестирование, вебтестирование , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

web-тестирование , web тестирование , вебтестирование это тип тестирования программного обеспечения ориентированный на веб приложения а так же это процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранных определенным образом (ISO/IEC TR 19759:2005)

Веб приложение, виды и типы веб-продуктов.

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

типы веб-продуктов

  • Landing Page
  • Multi Landing
  • Промо-сайт (презентация)
  • Сайт-визитка
  • Сайт-галерея (портфолио)
  • Сайт-витрина (каталог)
  • Интернет-магазин
  • Корпоративный сайт
  • Блог или Влог

Это далеко не полный список. Какие еще виды веб сайтов существуют: доски объявлений, новостные, форумы, файлообменники, порталы и многие другие. Есть еще и специфические типы, такие как дорвеи, сателлиты, MFA и MFS-сайты, но не будем забивать вам голову лишней информацией.

Теперь подробнее рассмотрим список основных видов сайтов и их назначение.

Landing Page

Лендинг пейдж, еще называют целевая или посадочная страница. Это одностраничный сайт с формой заявки. Может быть коротким или достаточно длинным. Подходит для акций, спец.предложений или 1 - 4 товаров/услуг.

Multi Landing

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

Промо-сайт (презентация)

Создается для рекламы и продвижения одного или группы товаров и услуг. Всегда делается с индивидуальным неповторимым дизайном, который должен привлечь внимание и отложиться в памяти. Объем сайта от 3 до максимум 10 страниц (о компании, услуги, товары, контакты).

Сайт-визитка

Четкая и самая важная информация о компании и ее товарах/услугах. Обязательное наличие всех контактных данных. Сайт имеет примерно из 3-5 страниц.

Сайт-галерея (портфолио)

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

Сайт-витрина (каталог)

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

Интернет-магазин

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

Корпоративный сайт

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

Блог , форум, чат

Web-сайт состоящий из регулярно добавляющихся статей (блог) или видео записей (влог). Может быть на одну узкую тематику или иметь разные разделы. Обычно имеют возможность комментирования для обсуждения каждой записи (поста). Может существовать отдельно или быть частью других типов сайтов (визитка, портфолио, каталог или Интернет-магазин).

Интернет веб сервис

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

Архитектура веб-продуктов.

Web-тестирование, особенности, виды, последовательность

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

Веб-приложение представлено следующими составляющими («сторонами»):
1. Клиент.
Как правило, клиент – это браузер, но встречаются и исключения (в тех случаях, когда один веб-сервер (ВС1) выполняет запрос к другому (ВС2), роль клиента играет веб-сервер ВС1). В классической ситуации (когда роль клиента выполняет браузер) для того, чтобы пользователь увидел графический интерфейс приложения в окне браузера, последний должен обработать полученный ответ веб-сервера, в котором будет содержаться информация, реализованная с применением HTML, CSS, JS (самые используемые технологии). Именно эти технологии «дают понять» браузеру, как именно необходимо «отрисовать» все, что он получил в ответе.

2. Сервер.
Веб-сервер – это сервер, принимающий HTTP-запросы от клиентов и выдающий им HTTP-ответы. Дабы избежать возможной путаницы, отметим, что веб-сервером называют как программное обеспечение, выполняющее функции веб-сервера, так и непосредственно компьютер, на котором это программное обеспечение работает. Наиболее распространенными видами ПО веб-серверов являются Apache, IIS и NGINX. На веб-сервере функционирует тестируемое приложение, которое может быть реализовано с применением самых разнообразных языков программирования: PHP, Python, Ruby, Java, Perl и пр.

3. База данных.
В классической теории речь идет о двух «сторонах» веб-приложения, однако, если внимательно посмотреть на весь процесс работы приложений, мы можем отметить, что в алгоритме работы веб-а незримо, но довольно активно принимает участие еще одна «сторона» – база данных. Фактически, она не является частью веб-сервера, но большинство приложений просто не могут выполнять все возложенные на них функции без нее, так как именно в базе данных хранится вся динамическая информация приложения (учетные, пользовательские данные и пр).

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

База данных – довольно широкое понятие, которое используется не только в сфере информационных технологий. В контексте моей статьи это – информационная модель, позволяющая упорядоченно хранить данные об объекте или группе объектов, обладающих набором свойств, которые можно категоризировать. Базы данных функционируют под управлением так называемых систем управления базами данных (далее – СУБД). Самыми популярными СУБД являются MySQL, MS SQL Server, PostgreSQL, Oracle (все – клиент-серверные).

Также существуют встраиваемые и файл-серверные СУБД. Для общего развития отмечу лишь одну популярную встраиваемую СУБД – SQLite, которая используется в некоторых браузерах, Android API, Skype и других известных приложениях. Взаимодействие с перечисленными СУБД основано на специальном языке структурированных запросов – SQL.

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

Протоколы и запросы

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

Сигнальный протокол используется для управления соединением — например, установки, переадресации, разрыва связи. Примеры протоколов: RTSP, SIP. Для передачи данных используются такие протоколы как RTP.

Сетево́й протоко́л — набор правил и действий (очередности действий), позволяющий осуществлять соединение и обмен данными между двумя и более включенными в сеть устройствами.

Разные протоколы зачастую описывают лишь разные стороны одного типа связи. Названия «протокол» и «стек протоколов» также указывают на программное обеспечение, которым реализуется протокол.

Новые протоколы для Интернета определяются IETF, а прочие протоколы — IEEE или ISO. ITU-T занимается телекоммуникационными протоколами и форматами.

Наиболее распространенной системой классификации сетевых протоколов является так называемая модель OSI, в соответствии с которой протоколы делятся на 7 уровней по своему назначению — от физического (формирование и распознавание электрических или других сигналов) до прикладного (интерфейс программирования приложений для передачи информации приложениями).

Сетевые протоколы предписывают правила работы компьютерам, которые подключены к сети. Они строятся по многоуровневому принципу. Протокол некоторого уровня определяет одно из технических правил связи. В настоящее время для сетевых протоколов используется сетевая модель OSI (Open System Interconnection — взаимодействие открытых систем, ВОС).

Модель OSI — 7-уровневая логическая модель работы сети. Реализуется группой протоколов и правил связи, организованных в несколько уровней:

  • на физическом уровне определяются физические (механические, электрические, оптические) характеристики линий связи;
  • на канальном уровне определяются правила использования физического уровня узлами сети;
  • сетевой уровень отвечает за адресацию и доставку сообщений;
  • транспортный уровень контролирует очередность прохождения компонентов сообщения;
  • сеансовый уровень координирует связь между двумя прикладными программами, работающими на разных рабочих станциях;
  • уровень представления служит для преобразования данных из внутреннего формата компьютера в формат передачи;
  • прикладной уровень является пограничным между прикладной программой и другими уровнями, обеспечивая удобный интерфейс связи для сетевых программ пользователя.

Web-тестирование, особенности, виды, последовательность

Рис Протоколы интернет

Web-тестирование, особенности, виды, последовательность

Рисунок 2.1. Структура запроса клиента

Для однозначной идентификации ресурсов в сети Веб используются уникальные идентификаторы URL.

Единообразный идентификатор ресурса URI (Uniform Resource Identifier) представляет собой короткую последовательность символов, идентифицирующую абстрактный или физический ресурс. URI не указывает на то, как получить ресурс, а только идентифицирует его. Это дает возможность описывать с помощью RDF (Resource Description Framework) ресурсы, которые не могут быть получены через Интернет (имена, названия и т.п.). Самые известные примеры URI - это URL и URN.

URL (Uniform Resource Locator) - это URI, который, помимо идентификации ресурса, предоставляет еще и информацию о местонахождении этого ресурса.

URN (Uniform Resource Name) - это URI, который идентифицирует ресурс в определенном пространстве имен, но, в отличие от URL, URN не указывает на местонахождение этого ресурса.

URL имеет следующую структуру:

Web-тестирование, особенности, виды, последовательность

где:

схема - схема обращения к ресурсу (обычно сетевой протокол);

логин - имя пользователя, используемое для доступа к ресурсу;

пароль - пароль, ассоциированный с указанным именем пользователя;

хост - полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста;

порт - порт хоста для подключения;

URL-путь - уточняющая информация о месте нахождения ресурса.

Общепринятые схемы (протоколы) URL включают протоколы: ftp, http, https, telnet, а также:

gopher — протокол Gopher;

mailto — адрес электронной почты;

news — новости Usenet;

nntp — новости Usenet через протокол NNTP;

irc — протокол IRC;

prospero — служба каталогов Prospero Directory Service;

wais — база данных системы WAIS;

xmpp — протокол XMPP (часть Jabber);

file — имя локального файла;

data — непосредственные данные (Data: URL);

Специфические особенности тестирования веб-продуктов

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

1. Кроссбраузерность: разнообразие клиентов


Что мы понимаем под тестированием на кроссбраузерность? Это проверка на правильность (соответствие требованиям и стандартам) отображения и функционирования веб-приложения в разных браузерах и на разных операционных системах. В современном мире стандартизация принимает глобальные масштабы, а потому большинство популярных браузеров одинаково обрабатывают код. При этом необходимость в кроссбраузерном тестировании не исчезает, так как далеко не все проблемы решаются стандартизацией.

Web-тестирование, особенности, виды, последовательность

Перед началом работ я рекомендую выяснять у ответственных лиц необходимый для тестируемого ПО набор браузеров. Можно самим собрать статистику по целевой аудитории вашего продукта и ограничить кроссбраузерное тестирование набором наиболее популярных в этой аудитории браузеров. В условиях регрессионного тестирования, когда ограничены временные и человеческие ресурсы, также можно применять практику распределения браузеров: закрепляя за каждым тестировщиком определенный браузер, вы сможете «покрыть» большой процент кроссбраузерных дефектов. Этот метод имеет и свои минусы: он наиболее результативен в большой команде тестирования, но становится практически неприменимым при наличии одного тестировщика.

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

В тестировании нуждаются все основные (среди пользовательской аудитории) браузеры, но особое внимание необходимо уделить IE, если он входит в их число. Именно в нем очень часто возникают проблемы, которые отсутствуют в других браузерах: так, в IE дополнительно рекомендуется обращать особое внимание на масштабируемость, фокус полей и работу JS.

Отдельно рекомендую не забывать о всякого рода валидаторах верстки, например https://validator.w3.org/. Даже если у вас недостаточно знаний, чтобы оценить соответствие верстки стандартам, можно использовать для этого автоматические средства и, проанализировав результат, указать разработчикам на самые серьезные «оплошности». Не стоит забывать, что иногда валидаторы обращают внимание на самые «мелочные мелочи», которые никто и никогда исправлять не будет. Если вы и заводите баг-репорты на подобного рода замечания, то удобнее будет собрать их в единый документ и прикрепить к репорту. К такого рода «мелочам» можно отнести всевозможные рекомендации, которые не имеют своего влияния на отображение и функционирование контента.

2. Веб-формы на стороне клиента
Web-тестирование, особенности, виды, последовательность

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

Как же не пропустить дефекты в формах на продакшен? Рассмотрим несколько простых шагов:
1. Тщательно проверяем обязательность заполнения полей и наличие соответствующей маркировки у них.
2. Заполнив и отправив форму, убеждаемся в том, что с данными происходит именно то, что запланировано. Если данные должны быть внесены в базу данных, проверяем, корректно ли завершился процесс (в конце концов, об этом можно попросить разработчика, если не хватает своих знаний SQL или прав доступа к БД).
3. Используем чит-листы для тестирования форм, например чит-лист регистрации от Алексея Лупана или чит-лист по Web UI контролам от Игоря Любина.
4. Проверяем, выводятся ли понятные пользователю информационные сообщения о необходимости заполнения пустых полей после попытки отправить форму.
5. Обращаем пристальное внимание на реализацию экранирования символов в полях форм, являющихся потенциальным источником уязвимостей для приложения и пользователей. Экранирование должно осуществляться на уровне не только клиента, но и сервера, отключить который в клиенте довольно просто (например, с помощью специальных плагинов, снимающих все возможные ограничения в несколько кликов, таких как Web Developer Toolbar – Forms).
6. Убеждаемся, что после заполнения формы пользователю приходит подтверждающее письмо с указанием соответствующего отправителя, а само тело письма соответствует требованиям (в том числе и на работоспособность ссылок).
7. Используем вспомогательные специальные инструменты для тестирования форм (например, Web Developer Toolbar).

3. Проверка орфографии

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

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

Да, мы не всегда имеем достаточно времени для вычитывания всех текстов, но в таких ситуациях на помощь приходят «SpellCheker-ы» (программы для проверки орфографии, онлайн или в виде плагинов для браузеров),

4. учет состояних, сессий и т.п.

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

какое поведение будет при многократном сабмите форм

5. учет того что сторонне апи может быть не работоспособным, как при этом будет жизнеспособность и обработка нестандарных систуаций?

например, если не оплачено или не работоспобен сервер смс уведомлений, емейл рассылок, гео-апи по ип, апи платежных систем,и тп.

Как при этом будет выполняться регистрация, серфинг по сайту, будут ли доступны и работоспособны основные страницы?

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

какое поведение приложения будет при нестандартных ситуациях сложившихся на сервере, например

  • тайм аут соединения
  • медленная загрузка(низкая пропускная способность)
  • загрузка большого по объему файла- при этом валидация по размеру файла интепритатором скорее всего будет не возможно т к не будет пропускать тело файла веб сервер (например нжин)
  • ответ от сервера 500 при аякс сохранении, валидациии формы и т.п.

7. учет настроек браузера, языковая версия, локальное время или гео данных по ИП

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

8. учет увстановленных расширениях в браузере или в системе пользователя

например расшщирения блокировщика рекламы может ошибочно блокировать некоторых блоки на сайте

или расширения или антивирусы от якобы блокировки нежелательных сайтов- может ошибочно блокироватьчать или все ваше веб приложение

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

Веб-сервер: « тестирование без клиента»

Тестирование части веб-приложения, размещенной на веб-сервере, можно провести и минуя графический (клиентский) интерфейс, однако это требует от специалиста определенного уровня знаний и навыков технического характера, а также применения дополнительных инструментов. Рассмотрим веб-сервер с точки зрения нагрузочного и инсталляционного тестирования.

Инсталляция (деплой, deploy, upload) на веб-сервер
Итак, прежде чем приступить к тестированию, мы должны установить (инсталлировать) веб-приложение на веб-сервер. Собственно, в этом есть сходство с проверкой десктоп-приложений, но существует и различие в нюансах, которые необходимо учесть и протестировать, особенно если это касается ПО, распространяемого для локальной инсталляции на веб-серверы пользователей.

В чем же заключаются эти особенности?

1. Большая часть веб-приложений требует для инсталляции специфических знаний в администрировании ОС. Попробуйте установить приложение на нескольких веб-серверах. В оптимальном случае это будут самые популярные технологии среди ваших пользователей, для установления списка которых потребуется предварительное исследование.
2. Инсталлируя веб-приложение, обращайте внимание на то, действительно ли приложение устанавливается в указанную вами директорию, базу данных, использует выбранный вами префикс и соблюдает прочие конфигурационные моменты.
3. Убедитесь, что приложение можно установить как из localhost, так и удаленно.
4. Если процесс инсталляции является интерактивным, и каждый выбор пользователя на определенном шаге влияет на последующие действия, то необходимо будет пройти все ветви, так как именно инсталляция является первым шагом пользователя в работе с вашим приложением.
5. Не забывайте о негативных тестах: проверки в условиях недостаточности ресурсов (места на диске, оперативной памяти) или привилегий, прерывание процесса установки во время активной его фазы (например, отправляя сервер в перезагрузку).

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

При этом обязательно учитывать -

  • конфигурациюю сервера и характеристики ресурсов- размер ОЗУ, Жеских дисков, число ядер и т.п
  • размер базы данных при большом заполении фиктивными или реальными данными - большим количествои пользователей, заказов, сообщений, и т.п.
  • учет не равномейрной нагрузки на специфические страницы или время
  • учет запущенных фоновых процессов- сервера очвередей, серверов баз данных, крон задач, бекаппирования

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

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

База данных: «хранить нельзя удалить»

Еще одной ранее рассмотренной составляющей веб-приложений является база данных, в которой приложение хранит всю необходимую информацию. Для того, чтобы база данных служила достойным хранилищем информации для вашего приложения, при тестировании необходимо обращать внимание на следующие основные моменты:
1. Вносимая через интерфейс информация должна быть сохранена в базе данных в неизменном (первоначальном) виде.
2. Сохраненная в базе данных информация должна отображаться в любой части приложения одинаково (если иного не требует бизнес-логика приложения).
3. Названия таблиц и структура БД должны соответствовать проектной документации.
4. Об этом говорит сайт https://intellect.icu . Нужно следить за тем, чтобы запросы не обрабатывались слишком долго, а количество соединений было достаточным. Мониторинг состояния БД – один из важных моментов тестирования.
5. Стоит учитывать, что удаление записи в БД не всегда сопровождается полным удалением сущности. Иногда используется так называемое «псевдоудаление», и нужно проверить, правильно ли оно выполняется.
6. Пустую БД на тестовом стенде рекомендуется либо заполнять сгенерированными случайными данными, либо снимать дамп с продакшена и после обфускации данных «заливать» их в тестируемую БД. Иногда квалификация тестировщика (или иная причина) не позволяет выполнить этот процесс самостоятельно: в таком случае рекомендуется обратиться за помощью к специалистам инфраструктуры или разработчикам.

Запросы: do you speak computish?
Все составляющие веб-приложения должны взаимодействовать между собой, и происходит это благодаря HTTP(s). Без HTTP наша многосторонняя система не функционировала бы в принципе, так как HTTP – это протокол передачи данных, занимающий одно из основных мест в нашей клиент-серверной архитектуре.

Взаимодействие осуществляется через сообщения (запросы и ответы): на отправленный запрос от клиента должен прийти ответ сервера. Классический запрос/ответ состоит из 3 составляющих:
  • стартовая строка;
  • заголовок;
  • тело сообщения.

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

Самыми популярными методами являются GET, HEAD и POST:

1. Метод GET. Используется для запроса содержимого, размещенного на сервере (например, GET /path/resource?param1=value1¶m2=value2 HTTP/1.1).
2. Метод HEAD. По своей сути не отличается от вышеупомянутого метода, однако ответ сервера на такой запрос лишен «тела», а практическое применение ориентировано на облегченное использование с целью получения минимальной информации о сервере/продукте или его статусе.
3. Метод POST. Данный метод используется для передачи данных на сервер, однако его основа «прячется» в тело, что отличает его от GET. Во время публикации этой статьи, например весь текст будет помещен в тело POST-запроса; после обработки его сервером на сайт будет добавлена статья.

Существуют и другие методы: PUT, DELETE, CONNECT, TRACE, PATCH и т. д.

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

Классическими приложениями, которые можно использовать для генерации запросов, является Fiddler или Postman. Используя Fiddler, можно с легкостью отслеживать все запросы от клиента и ответы, просматривать их детали, а также вносить свои изменения и отправлять модифицированные запросы на сервер, оценивая поведение системы в таком случае.

На что обращать внимание в HTTP запросах при тестировании веб-приложения?

Web-тестирование, особенности, виды, последовательность

1. Правильный ли метод используется для того или иного запроса? Если вы отправляете сообщение, а на сервер уходит только GET-запрос, то что-то здесь явно не так.
2. Казалось бы, клик по одной и той же функциональной клавише генерирует один и тот же запрос. Но есть прецеденты, когда клик по кнопке приводил к ситуации, в которой JavaScript переписывал запрос рядом находящейся кнопки, таким образом меняя ее предназначение.
3. Вникайте в отправляемые запросы. В них довольно легко разобраться, особенно если это GET – они логически понятны даже рядовому пользователю. Анализ запросов – это возможность обнаружить спрятавшийся дефект гораздо быстрее, чем осуществляя его поиск в интерфейсе.
4. Мониторьте трафик на предмет запросов на другие (не ваши) сервера. Пример из жизни: фронтэнд сайта делал фриланс-разработчик, по завершению работы которого мы принялись за тестирование. Я имею привычку мониторить весь трафик тестируемого приложения: это позволило обнаружить, что вышеупомянутый разработчик без зазрения совести спрятал в «фронт» сайта запросы, которые работали на благо его личного интернет-магазина.
5. Мониторя трафик, внимательно следите за кодами состояний. Мы подробнее остановимся на этом пункте.

Коды состояния глазами адепта качества
Каждый ответ на любой запрос несет в себе массу полезной для разработчиков и специалистов по тестированию ПО информации. Одним из источников такой информации может стать код состояния: по этому коду клиент узнает о результатах его запроса и определяет, какие действия ему предпринять дальше. Набор кодов состояния является стандартом, он описан в соответствующих документах RFC. Каждый раз, когда вы создаете баг-репорт о неработающих ссылках, иных элементах веб-страницы или системных ошибках, обязательно указывайте ответы сервера: они сэкономят время разработчику при определении причин дефекта.

Все коды можно поделить на группы (сотые, двухсотые, трехсотые, четырехсотые и пятисотые) каждая группа-«сотня» несет свой тип информации.

Web-тестирование, особенности, виды, последовательность

Рис. коды HTTP состояния

На практике, используя при тестировании специальные приложения (тот же Fiddler), вы без труда сможете отсортировать свои запросы и ответы по коду состояния и отобрать, например, все 400-е и 500-е с последующим их анализом. Таким образом

продолжение следует...

Продолжение:


Часть 1 Web-тестирование, особенности, виды, последовательность
Часть 2 Основные подходы Практические советы - Web-тестирование, особенности, виды, последовательность
Часть 3 Вау!! 😲 Ты еще не читал? Это зря! - Web-тестирование, особенности, виды, последовательность

См.также

Надеюсь, эта статья об увлекательном мире web-тестирование, была вам интересна и не так сложна для восприятия как могло показаться. Желаю вам бесконечной удачи в ваших начинаниях, будьте свободными от ограничений восприятия и позвольте себе делать больше активности в изученном направлени . Надеюсь, что теперь ты понял что такое web-тестирование, web тестирование, вебтестирование и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Качество и тестирование программного обеспечения. Quality Assurance.

создано: 2015-11-03
обновлено: 2022-11-09
132448



Рейтиг 3 of 10. count vote: 2
Вы довольны ?:


Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии


Оставить комментарий
Если у вас есть какое-либо предложение, идея, благодарность или комментарий, не стесняйтесь писать. Мы очень ценим отзывы и рады услышать ваше мнение.
To reply

Качество и тестирование программного обеспечения. Quality Assurance.

Термины: Качество и тестирование программного обеспечения. Quality Assurance.