Что такое веб тестирование
Функциональное тестирование современных web-приложений
Для своевременного обнаружения таких ситуаций и выполнения непрерывной интеграции необходимо функциональное тестирование web-приложения. В статье пойдет речь о двух бесплатных open-source решениях:
Рассматриваемые решения обеспечивают похожий, на первый взгляд, ряд возможностей.
Пример функционального теста
Примером для тестирования будет web-приложение вида TodoMVC, с сервером на node.js и клиентской SPA-страницей на React+Redux-е. Для приближения условий тестирования к реальным, во все redux-овские action-ы добавлены случайные задержки, эмулирующие сетевое взаимодействие с backend-ом (за основу взято это).
В дальнейшем будет предполагаться, что тестовое web-приложение запущено по адресу http://localhost:4000/. Функциональный тест будет простым и включать в себя добавление todo-элемента, правку его содержимого, отметку как выполненное/невыполненное задание и удаление.
Языком для написания тестов в обоих фреймворках является JS (ES2016 и ES5 соответственно для TestCafe и Nightwatch), однако это прекрасно подходит для web-приложений, написанных на любом языке. Если Вы давно не разрабатывали на JS, то необходимо учитывать, что современные редакции ушли очень далеко от старого ES3, и включают удобные средства для написания кода, объектно-ориентированного и функционального программирования и многое другое.
Исходный код функционального теста, проверяющего изложенный выше use-case-сценарий, может быть таким:
Адрес тестируемой web-страницы определяется в fixture-части, за которыми следуют функциональные тесты, по завершении каждого из которых web-страница автоматически восстанавливается в исходное состояние. Для поиска DOM-элементов на странице используются testcafe-специфические Selector-ы, использующиеся в качестве обертки для функции, которая будет выполнять запрос к DOM-модели, возможно используя аргументы.
В этом примере первый селектор представляет обертку над document.querySelector, а второй — над document.querySelectorAll с callback-функцией, помогающей выбрать нужный элемент из списка. Обертка Selector принимает опции, здесь в частности устанавливается максимальное время, в течении которого testcafe будет ожидает появление элемента с заданными характеристиками в DOM-модели.
Сам функциональный тест представляет собой набор асинхронных вызовов Selector-ов, между которыми производятся действия посредством test controller-а, инстанцированного переменной t. Назначение большинства его методов очевидно из названий (click, typeText и т.д.), а t.setNativeDialogHandler используется для предотвращения генерации alert-подобных окон, которые могут “подвесить” тест — что очень удобно.
Для запуска тестов сначала надо создать конфигурационный файл nightwatch.json, описывающий расположение тестов, пути и настройки для selenium-server и webdriver-ов, а далее использовать простую команду nightwatch в текущей директории.
Если использовать Microsoft Web Driver (Edge), то nightwatch.json может выглядеть примерно так:
Исходный код функционального теста, проверяющий аналогичный рассмотренному выше use-case-сценарий, может выглядеть так:
Среди особенностей кода легко заметить, что Nightwatch не поддерживает эмуляцию двойного щелчка по элементу — вместо этого приходится реализовывать обходной путь с inject-функцией на клиенте, выполняющую dispatchEvent на целевом элементе управления.
Удобной возможностью Nightwatch является поддержка XPath, который предоставляет значительно более широкие возможности по селекции элементов DOM-модели, по сравнению с CSS-селекторами — взять хотя бы извлечение элемента по его текстовому наполнению, что довольно часто встречается в функциональном тесте.
Сравнение функциональности TestCafe и Nightwatch
Язык написания тестов:
T: Из коробки предоставляется возможность написания тестов непосредственно на языке ES2016, что позволяет писать простой и читабельный код тестов на том же языке, что и само web-приложение Это также удобно в случаях, когда требуется импортировать определенный модуль из тестируемого проекта.
N: Устаревший ES5-синтаксис и exports-конструкции в исходном коде функционального теста (Возможность прикрутить ES6 все-таки есть, но на костылях)
Поддержка асинхронных операций:
T: Все API-функции основаны на Promise-ах, что позволяет описывать произвольную асинхронную логику работы теста, и при этом интегрировать собственные функции со стороны node.js. Благодаря поддержке ES2016, этот код можно записывать при помощи async и await конструкций в последовательном стиле.
N: В тесте можно реализовать последовательность команд по анализу и управлению содержимым web-страницы, однако они складываются во внутреннюю очередь событий, и интегрировать собственные асинхронные функции с ними проблематично.
Вставка клиентского кода на лету:
T: Легко осуществляется при помощи соответствующего API, поддерживается создание и последующее выполнение клиентских функций, однократное исполнение injected-кода, замена существующих функций в исходной web-странице, а также исполнение клиентских функций в callback-ах node.js-функций с привязкой к тестовому контроллеру.
N: Есть функциональность для выполнение JS-кода на клиентской стороне, или даже вставки целого script-блока, но средств интеграции с тест-контроллером не предоставляется. Подходит для простого синхронного интегрируемого JS-кода, но в более общем случае интеграция проблематична.
Работа с курсором мыши:
T: Предоставляется виртуальный курсор, посредством которого осуществляются hover, click и drag-события для целевым визуальных элементов страницы. В процессе выполнения теста можно наблюдать за перемещением курсора и выполняемыми действиями.
N: Средства для работы с курсором вообще есть — это функции из webdriver api, однако работать с действиями, сложнее одиночного левого клика, довольно проблематично — взять хотя бы двойной щелчок.
Реализация взаимодействия с браузером в TestCafe и NightWatch
Фреймворк NightWatch основывается на известной, в некоторой мере уже традиционной, библиотеке Selenium webdriver, преимущества которой включают устоявшееся API, высокую степень документированности и обширное Q&A в интернете, а также универсальный и достаточно низкоуровневый доступ к браузеру… Взаимодействие с браузерами организуется посредством webdriver-ов, по одному на каждый обозреватель.
Основной недостаток — webdriver-ы существуют далеко не для всех браузеров, а также требуют отдельного обновления при смене версии самого браузера, а еще для работы необходимо наличие внешней зависимости от Java. Более подробно о технологии webdriver можно прочесть в http://www.w3.org/TR/webdriver/
Фреймворк TestCafe основан на подходе, в котором взаимодействие с приложением браузера сведено к минимуму — используются только функции открытия окна/вкладки, изменения размера окна, перехода по URL-адресу и некоторые другие.
Взаимодействие с web-страницей производится посредством web-proxy сервера testcafe-hammerhead, осуществляющего загрузку удаленной web-страницы и модификацию исходного JS-кода таким образом, чтобы выполнить шаги функционального теста, посредством интеграции с DOM-моделью, поиска и управления визуальными элементами, выполнение произвольного JS-кода и так далее. (https://github.com/DevExpress/testcafe-hammerhead/)
Метод TestCafe более универсален, поскольку может потенциально работать с любым браузером, поддерживающим HTML5 и ES 5+, в то время как NightWatch требует соответствующий webdriver. Кроме того, это позволяет прогонять тесты не только на локальном браузере, но на любом браузере в сети, включая любые мобильные — без установки какого-либо ПО на телефоне.
Пример тестирования вышерассмотренного web-приложения в браузере на Android показан в следующем видео: https://youtu.be/2na5jkqvUx0
Однако testcafe-hammerhead имеет и потенциальные недостатки: накладные расходы на анализ и модификацию исходного JS-кода тестируемой страницы, производимые в свою очередь JS-коде ядра Testcafe, а также теоретически некорректная работа тестируемой web-страницы или интеграции теста, если исходный код был проксирован неверно. (К примеру, замещение alert-окна в testcafe можно обойти таким примером http://pastebin.com/p6gLWA75 — и неумешленно или специально “подвесить” его выполнение)
Выводы
Конечно, selenium-webdriver, на котором основан Nightwatch, является популярным и широко известным решением, имеющем стандартный API-интерфейс, что несомненно является его достоинством. Кроме того, в смежных областях задач, например автоматизации целевого web-ресурса в заданном браузере — фактически написании бота для удаленного web-сайта — selenium-webdriver подходит лучше.
Однако для функционального тестирования разрабатываемого или поддерживаемого web-приложения TestCafe несомненно впереди по широкому ряду причин:
1) Запуск тестов в любом браузере, в том числе мобильных телефонах и планшетах, причем это может производиться пакетным образом для всех интересуемых браузеров и не требует установки никакого дополнительного ПО.
2) Удобство написания теста на ES2016, включающее async/await-конструкции для последовательной записи кода, импорт программных элементов из самого проекта, передачу функций в клиент и обратно и так далее — широкие возможности по интеграции и управлению клиентским web-приложением.
3) Широкая поддержка selector-ов для визуальных элементов, легкое взаимодействие с DOM-моделью, виртуальный курсор мыши, эмуляция разнообразных и сложных взаимодействий пользователя со страницей.
Таким образом, среди существующих open-source решений для функционального тестирования web-приложений, TestCafe выглядит очень привлекательным вариантом, к тому же при сочетании легковесности и функциональности.
Веб-тестирование
Прежде чем перейти к более подробным сведениям о типе веб-тестирования, давайте быстро определим веб-тестирование.
Что такое веб-тестирование?
На этом этапе проверяются такие вопросы, как безопасность веб-приложения, функционирование сайта, его доступ как для инвалидов, так и для обычных пользователей, а также его способность обрабатывать трафик.
Как протестировать веб-приложение
В программной инженерии могут быть выполнены следующие типы / техника тестирования в зависимости от ваших требований к веб-тестированию.
1. Проверка работоспособности:
Это используется для проверки того, соответствует ли ваш продукт спецификациям, которые вы для него предназначали, а также функциональным требованиям, которые вы наметили для него в документации по разработке. Веб-тестирование включает в себя:
Проверьте, что все ссылки на ваших веб-страницах работают правильно и убедитесь, что нет битых ссылок. Ссылки для проверки будут включать —
Тестовые формы работают как положено. Это будет включать в себя
Тестовые куки работают как положено. Файлы cookie — это небольшие файлы, используемые веб-сайтами для запоминания активных пользовательских сессий, поэтому вам не нужно входить в систему каждый раз, когда вы посещаете веб-сайт. Тестирование файлов cookie будет включать
Протестируйте HTML и CSS, чтобы поисковые системы могли легко сканировать ваш сайт. Это будет включать
Тест бизнес-процесса — это будет включать в себя
2. Юзабилити-тестирование :
Юзабилити-тестирование стало важной частью любого веб-проекта. Это могут сделать такие тестеры, как вы, или небольшая фокус-группа, похожая на целевую аудиторию веб-приложения.
Тестирование сайта Навигация :
Тест на содержание :
Тестирование сайта или как не зафакапиться
Почему тестирование сайта так важно
Мы все можем согласиться с тем, что в сегодняшнем постоянно меняющемся и конкурентном мире, интернет стал неотъемлемой частью нашей жизни. В наши дни, большинство из нас принимают решения, просматривая информацию в Интернете, поэтому хостинг веб-сайта является не столько обязательной, а сколько необходимой опцией для всех видов бизнеса. Это первый шаг к тому, чтобы стать и оставаться актуальным на рынке.
Просто иметь сайт недостаточно. Организации нужно разработать информативный, доступный и удобный веб-сайт. Для сохранения всех этих качеств, веб-сайт должен быть протестирован, и этот процесс называется веб-тестированием или тестированием сайта.
Веб-тестирование — это тщательная проверка сайта на наличие потенциальных ошибок. Это полное тестирование веб-приложений перед запуском. Веб-система должна быть полностью проверена от начала до конца, прежде чем она будет запущена для конечных пользователей.Также, в ходе тестирования определяется удобство и привлекательность сайта для пользователя, быстрота получения и доступность нужной информации, надежность и безопасность использования. И, самое главное, помогает ли он достичь тех бизнес-целей, которые были поставлены в начале проекта. Общая цель веб-тестирования — найти проблемы, также известные как ошибки, проблемы или дефекты, которые могут оказать негативное влияние на веб-сайт или приложение. Веб-тестирование также можно использовать для выявления определенных областей или аспектов веб-сайта, которые можно улучшить и получить лучшие результаты, будь то больше запросов, больше продаж, больше постоянных посетителей, более счастливые пользователи или что-то еще.
Как тестировать сайт?
До того, как начать тестирование, очень важно определить стратегию тестирования. Для чего? В первую очередь — для организации процесса тестирования в условиях, которые есть на данный момент или для определения потребности в привлечении других ресурсов. Во-вторых, не менее важно понимание всех участников процесса тестирования что происходит, равные ожидания и выявление проблем, которые могут возникнуть в процессе тестирования.
Стратегии тестирования также описывают, как риски снижаются на уровне тестирования, какие типы тестирования должны выполняться, и какие критерии входа и выхода применяются. Они создаются на основе разработки проектной документации. Проектные документы описывают функциональные возможности программного обеспечения, которое будет включено в следующем выпуске. Для каждого этапа разработки проекта должна быть создана соответствующая стратегия тестирования для тестирования новых наборов функций.
Продуманная стратегия тестирования становится основой для разработки более подробной документации, в частности, тест-плана. В первую очередь в построении стратегии принимают участие менеджер проекта и специалист контроля качества разработки, т. е. QA (quality assurance) или QC (quality control) специалисты.
Если говорить об основных правилах тестирования веб-сайтов, то можно сказать, что речь идет об обязательном прохождении нескольких этапов тестирования, которые обеспечивают полную работоспособность приложения, его бесперебойную и безопасную работу. Это важная часть веб-разработки, которая обеспечивает правильную работу приложения до его выпуска.
На определенных этапах тестирования веб-сайтов используются такие виды или типы тестирования, позволяющие в полной мере достичь поставленных целей тестирования. Цели могут быть разные, такие как проверка важных элементов: удобство использования безопасность, надежность, системы в общем, так и на проверку этих элементов после изменений, например, повторное тестирование.
Виды тестирования сайта
В настоящее время специалисты выделяют следующие основные виды тестирования сайта:
• Функциональное тестирование (Functionality testing)
• Тестирования удобства пользования (Usability testing)
• Тестирование интерфейса пользователя (UI testing)
• Тестирование производительности (Performance testing)
• Тестирование безопасности (Security testing)
Функциональное тестирование (Functionality testing)
Функциональное тестирование определяется как тип тестирования, который проверяет, что каждая функция П.О. работает в соответствии со спецификацией требования. Это тип тестирования «черного ящика», т. е. этот тип тестирования не требует внутренних знаний о структуре программного обеспечения. Оно проверяет различные аспекты, описанные в документе спецификации требований и спецификации функций.
Функциональное тестирование включает в себя:
· проверка работы всех ссылок: корректны ли они и не «биты»;
· проверка пользовательских форм. Например, при не заполнении обязательных полей пользователем в форме выводится сообщение об ошибке; поля заполняются по умолчанию и т.д.
· проверка кода HTML и CSS для облегчения сканирования сайта поисковыми системами;
· Тестирование workflow — точно ли каждый рабочий процесс отражает бизнес-процессы.
А также обязательна проверка отрицательных сценариев —при вводе пользователем некорректных данных должно отображаться сообщение об ошибке или справка.
Тестирование удобства пользования (Usability testing)
С помощью этого вида тестирования проверяются характеристики взаимодействия человека с компьютером с целью выявления недостатков для исправления. Основными характеристиками являются:
• Простота обучения.
• Навигация.
• Субъективное удовлетворение пользователя.
• Общий вид.
Другими словами можно сказать, что сайт должен быть прост в использовании и достаточно последователен; инструкции должны быть очень четкими; главное меню должно быть предоставлено на каждой странице; содержание должно быть логичным и простым для понимания.
Тестирование интерфейса пользователя (UI testing)
Оно определяется как процесс тестирования графического интерфейса пользователя тестируемого приложения. Тестирование UI включает проверку экранов с помощью элементов управления, таких как меню, кнопки, значки и все типы панелей — панель инструментов, строка меню, диалоговые окна, окна и т. д. Оно помогает ответить на такие вопросы:
• Как выглядит интерфейс?
• Удобно ли пользователю нажимать на кнопки?
• Понятны ли иконки, читабелен ли текст, формат, шрифт?
• Какие акценты в каких местах будут располагаться и к чему привлекать внимание?
Также при прохождении этого вида тестирования осуществляются проверки на совместимость с разными интернет браузерами и их версиями; как выглядит сайт при разных разрешениях экрана и на различных устройствах (смартфоны, планшеты).
Тестирование производительности (Performance testing)
Веб-приложение должно выдерживать большие нагрузки, поэтому тестирование производительности обычно включает в себя нагрузочное тестирование, стресс-тестирование и тестирование производительности сайта на разной скорости интернет-соединения.
При нагрузочном тестировании проверяется насколько много пользователей могут обращаться к одной странице или запрашивать ее. Может ли система выдерживать пиковые нагрузки? Насколько сайт может обрабатывать множество одновременных пользовательских запросов, большие входные данные от пользователей, одновременное подключение к базе данных, большую нагрузку на определенные страницы и так далее.
Cтресс-тестирование тестирует за пределами нормальной рабочей точки и оценивает, как система работает в таких экстремальных условиях. Оно проводится, чтобы убедиться, что система не будет аварийно завершать работу в критических ситуациях.
Тестирование производительности сайта на разной скорости интернет-соединения проверяет на сколько быстро откликается сайт при разных скоростях соединения.
Тестирование безопасности (Security testing)
Тестирование безопасности определяется как тип тестирования программного обеспечения, обеспечивающий защиту программных систем и приложений от любых уязвимостей, угроз и рисков, которые могут привести к большим потерям. Тестирование безопасности любой системы заключается в обнаружении всех возможных лазеек и слабых сторон системы, которые могут привести к потере информации, доходов, репутации со стороны сотрудников или посторонних лиц Организации.
Цель тестирования безопасности — выявить угрозы в системе и измерить ее потенциальные уязвимости, чтобы система не перестала функционировать или использовалась. Это также помогает в обнаружении всех возможных угроз безопасности в системе и помогает разработчикам в устранении этих проблем посредством кодирования.
Во время работы над всеми этапами тестирования сайта обязательно должен быть создан документ, где отражены все ошибки, и который далее передается разработчикам для исправления этих ошибок и, после этого проводится повторное тестирование.
Заключение
При создании веб-сайта важно не просто убедиться, что дизайн красивый, а сборка комплексная. Должна присутствовать полная уверенность, что сайт работает отлично, прежде чем его выпустят для широкой публики. Именно для этого на веб-сайте проводится ряд тестов, специально предназначенных для ознакомления со всеми функциональными возможностями сайта, чтобы попытаться найти любую проблему, большую или маленькую, которая может заставить пользователей испытать какие-либо неудобства.
Что такое веб тестирование
При взгляде на эти баснословные цифры становится понятным, почему в мире разрабатывается так много новых веб-приложений. Этот процесс приводит к необходимости привлечения большого количества специалистов. То, что веб (в широком смысле) будет продолжать наращивать темпы своего развития, подтверждается и набирающим силу «мейнстримом»: всё «переезжает» в облака. Облачные технологии становятся новой реальностью современного Интернета: даже некогда привычные нам десктопные Word и Excel сегодня представлены в виде веб-альтернатив от Microsoft. Исходя из сказанного, можно утверждать, что потребность в хороших инженерах по обеспечению качества, специализирующихся на веб-продуктах, будет только расти.
Представленная вниманию читателей статья посвящена вопросам особенностей тестирования веб-приложений. Будет правильным начать повествование с основ и определиться, что именно мы подразумеваем под понятием «веб-приложение» и какие нюансы в реализации этих приложений добавляют работу тестировщикам.
Клиент, сервер и база данных
Веб-приложение – это клиент-серверное приложение, в котором клиентом выступает браузер, а сервером – веб-сервер (в широком смысле). Основная часть приложения, как правило, находится на стороне веб-сервера, который обрабатывает полученные запросы в соответствии с бизнес-логикой продукта и формирует ответ, отправляемый пользователю. На этом этапе в работу включается браузер, именно он преобразовывает полученный ответ от сервера в графический интерфейс, понятный рядовому пользователю.
Итак, первой и одной из ключевых особенностей веб-приложений является их архитектура. Давайте более детально рассмотрим этот вопрос, так как он представляет особую ценность для тестирования.
Веб-приложение представлено следующими составляющими («сторонами»):
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.
Теперь, собрав в голове определенный архитектурный пазл, предлагаю рассмотреть его с точки зрения тестирования ПО. Несколько позже мы рассмотрим и то, как все составляющие «общаются» между собой.
Особенности архитектуры: «под прицелом» клиент
Мы упомянули клиента как первую составляющую архитектуры. В классической ситуации клиент представлен браузером, а потому вопрос тестирования кроссбраузерности (ввиду многообразия браузеров) весьма актуален. Мы также рассмотрим тестирование заполняемых форм и текста как основного источника информации, получаемой через клиента.
Кроссбраузерность: разнообразие клиентов 
Что мы понимаем под тестированием на кроссбраузерность? Это проверка на правильность (соответствие требованиям и стандартам) отображения и функционирования веб-приложения в разных браузерах и на разных операционных системах. В современном мире стандартизация принимает глобальные масштабы, а потому большинство популярных браузеров одинаково обрабатывают код. При этом необходимость в кроссбраузерном тестировании не исчезает, так как далеко не все проблемы решаются стандартизацией.
Перед началом работ я рекомендую выяснять у ответственных лиц необходимый для тестируемого ПО набор браузеров. Можно самим собрать статистику по целевой аудитории вашего продукта и ограничить кроссбраузерное тестирование набором наиболее популярных в этой аудитории браузеров. В условиях регрессионного тестирования, когда ограничены временные и человеческие ресурсы, также можно применять практику распределения браузеров: закрепляя за каждым тестировщиком определенный браузер, вы сможете «покрыть» большой процент кроссбраузерных дефектов. Этот метод имеет и свои минусы: он наиболее результативен в большой команде тестирования, но становится практически неприменимым при наличии одного тестировщика.
В тестировании нуждаются все основные (среди пользовательской аудитории) браузеры, но особое внимание необходимо уделить IE, если он входит в их число. Именно в нем очень часто возникают проблемы, которые отсутствуют в других браузерах: так, в IE дополнительно рекомендуется обращать особое внимание на масштабируемость, фокус полей и работу JS.
Отдельно рекомендую не забывать о всякого рода валидаторах верстки, например https://validator.w3.org/. Даже если у вас недостаточно знаний, чтобы оценить соответствие верстки стандартам, можно использовать для этого автоматические средства и, проанализировав результат, указать разработчикам на самые серьезные «оплошности». Не стоит забывать, что иногда валидаторы обращают внимание на самые «мелочные мелочи», которые никто и никогда исправлять не будет. Если вы и заводите баг-репорты на подобного рода замечания, то удобнее будет собрать их в единый документ и прикрепить к репорту. К такого рода «мелочам» можно отнести всевозможные рекомендации, которые не имеют своего влияния на отображение и функционирование контента.
Веб-формы на стороне клиента 
Одной из важных составляющих интернет-приложений являются формы для заполнения, взаимодействие с которыми пользователь осуществляет с помощью все того же пристально рассмотренного нами клиента. Однако, данные формы очень часто служат источником дефектов, которые, обосновавшись в «продакшене», могут принести большие финансовые и репутационные убытки компании.
Как же не пропустить дефекты в формах на продакшен? Рассмотрим несколько простых шагов:
1. Тщательно проверяем обязательность заполнения полей и наличие соответствующей маркировки у них.
2. Заполнив и отправив форму, убеждаемся в том, что с данными происходит именно то, что запланировано. Если данные должны быть внесены в базу данных, проверяем, корректно ли завершился процесс (в конце концов, об этом можно попросить разработчика, если не хватает своих знаний SQL или прав доступа к БД).
3. Используем чит-листы для тестирования форм, например чит-лист регистрации от Алексея Лупана или чит-лист по Web UI контролам от Игоря Любина.
4. Проверяем, выводятся ли понятные пользователю информационные сообщения о необходимости заполнения пустых полей после попытки отправить форму.
5. Обращаем пристальное внимание на реализацию экранирования символов в полях форм, являющихся потенциальным источником уязвимостей для приложения и пользователей. Экранирование должно осуществляться на уровне не только клиента, но и сервера, отключить который в клиенте довольно просто (например, с помощью специальных плагинов, снимающих все возможные ограничения в несколько кликов, таких как Web Developer Toolbar – Forms).
6. Убеждаемся, что после заполнения формы пользователю приходит подтверждающее письмо с указанием соответствующего отправителя, а само тело письма соответствует требованиям (в том числе и на работоспособность ссылок).
7. Используем вспомогательные специальные инструменты для тестирования форм (например, Web Developer Toolbar).
Текст, как основной источник информации при работе через клиент
Как не крути, но особая ценность сети Интернет заключается в том, что она является практически безграничным источником информации. Часть этой информации представлена в виде текстов, с которыми, опять же, пользователь взаимодействует посредством клиента. Большинство веб-ресурсов в том или ином объеме требуют проверки текстов на предмет отсутствия грамматических ошибок и опечаток.
Конечно, значимость этого тестирования не так велика по сравнению с функциональным направлением, но пренебрегать им не стоит. На практике мне довелось встретиться с очень серьезной опечаткой: на продакшене одного из крупнейших интернет-гипермаркетов России была допущена ошибка, изменившая гордое название величественного города Ярославль на прискорбное оскорбительное слово. Название служило частью суб-меню, а потому было заметно всем жителям города с полумиллионным населением.
Да, мы не всегда имеем достаточно времени для вычитывания всех текстов, но в таких ситуациях на помощь приходят «SpellCheker-ы» (программы для проверки орфографии, онлайн или в виде плагинов для браузеров), например, Яндекс.Спеллер.
Веб-сервер: «долой клиент, тестим без него»
Тестирование части веб-приложения, размещенной на веб-сервере, можно провести и минуя графический (клиентский) интерфейс, однако это требует от специалиста определенного уровня знаний и навыков технического характера, а также применения дополнительных инструментов. Рассмотрим веб-сервер с точки зрения нагрузочного и инсталляционного тестирования.
Инсталляция на веб-сервер 
Итак, прежде чем приступить к тестированию, мы должны установить (инсталлировать) веб-приложение на веб-сервер. Собственно, в этом есть сходство с проверкой десктоп-приложений, но существует и различие в нюансах, которые необходимо учесть и протестировать, особенно если это касается ПО, распространяемого для локальной инсталляции на веб-серверы пользователей.
1. Большая часть веб-приложений требует для инсталляции специфических знаний в администрировании ОС. Попробуйте установить приложение на нескольких веб-серверах. В оптимальном случае это будут самые популярные технологии среди ваших пользователей, для установления списка которых потребуется предварительное исследование.
2. Инсталлируя веб-приложение, обращайте внимание на то, действительно ли приложение устанавливается в указанную вами директорию, базу данных, использует выбранный вами префикс и соблюдает прочие конфигурационные моменты.
3. Убедитесь, что приложение можно установить как из localhost, так и удаленно.
4. Если процесс инсталляции является интерактивным, и каждый выбор пользователя на определенном шаге влияет на последующие действия, то необходимо будет пройти все ветви, так как именно инсталляция является первым шагом пользователя в работе с вашим приложением.
5. Не забывайте о негативных тестах: проверки в условиях недостаточности ресурсов (места на диске, оперативной памяти) или привилегий, прерывание процесса установки во время активной его фазы (например, отправляя сервер в перезагрузку).
Нагрузочное тестирование 
Нагрузочное тестирование имитирует работу с приложением определенного количества пользователей. Этот вид тестирования осуществляется при помощи специальных инструментов (например, jMeter), главная цель которых – определить профили нагрузки и искусственно создать для них нагрузку, выявляющую граничные возможности приложения (или сервера) в условиях работы с ним того или иного количества пользователей.
Полученная информация подвергается тщательному анализу с последующим выявлением «узких горлышек» и граничных программных и аппаратных возможностей, которые в дальнейшем используются для обеспечения стабильности веб-сервера и самого приложения, работающего на нем.
Приведем пример из практики функционирования большого коммерческого продукта, который долгое время работал с разнообразными типами договоров. Однажды в релиз выпустили очередной особо ожидаемый тип договора, и на следующий день система полностью перестала работать, а служба поддержки была завалена огромным количеством обращений. Всему виной стал просчет в тестировании: команда проверяла одновременную работу с десятками тысяч договоров, но никто не смог предугадать, что на практике речь пойдет о сотнях тысяч, а иногда и о миллионах договоров. Нагрузочное тестирование позволяет обнаружить потенциальные проблемы такого характера еще на этапе тестирования.
База данных: «хранить нельзя удалить»
Еще одной ранее рассмотренной составляющей веб-приложений является база данных, в которой приложение хранит всю необходимую информацию. Для того, чтобы база данных служила достойным хранилищем информации для вашего приложения, при тестировании необходимо обращать внимание на следующие основные моменты:
1. Вносимая через интерфейс информация должна быть сохранена в базе данных в неизменном (первоначальном) виде.
2. Сохраненная в базе данных информация должна отображаться в любой части приложения одинаково (если иного не требует бизнес-логика приложения).
3. Названия таблиц и структура БД должны соответствовать проектной документации.
4. Нужно следить за тем, чтобы запросы не обрабатывались слишком долго, а количество соединений было достаточным. Мониторинг состояния БД – один из важных моментов тестирования.
5. Стоит учитывать, что удаление записи в БД не всегда сопровождается полным удалением сущности. Иногда используется так называемое «псевдоудаление», и нужно проверить, правильно ли оно выполняется.
6. Пустую БД на тестовом стенде рекомендуется либо заполнять сгенерированными случайными данными, либо снимать дамп с продакшена и после обфускации данных «заливать» их в тестируемую БД. Иногда квалификация тестировщика (или иная причина) не позволяет выполнить этот процесс самостоятельно: в таком случае рекомендуется обратиться за помощью к специалистам инфраструктуры или разработчикам.
Запросы: do you speak computish?
Все составляющие веб-приложения должны взаимодействовать между собой, и происходит это благодаря HTTP(s). Без HTTP наша многосторонняя система не функционировала бы в принципе, так как HTTP – это протокол передачи данных, занимающий одно из основных мест в нашей клиент-серверной архитектуре.
При работе с ответами специалист по тестированию в первую очередь должен обращать внимание на методы и коды состояния, которые присутствуют в стартовой строке.
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, можно с легкостью отслеживать все запросы от клиента и ответы, просматривать их детали, а также вносить свои изменения и отправлять модифицированные запросы на сервер, оценивая поведение системы в таком случае.
На что обращать внимание в запросах?
1. Правильный ли метод используется для того или иного запроса? Если вы отправляете сообщение, а на сервер уходит только GET-запрос, то что-то здесь явно не так.
2. Казалось бы, клик по одной и той же функциональной клавише генерирует один и тот же запрос. Но есть прецеденты, когда клик по кнопке приводил к ситуации, в которой JavaScript переписывал запрос рядом находящейся кнопки, таким образом меняя ее предназначение.
3. Вникайте в отправляемые запросы. В них довольно легко разобраться, особенно если это GET – они логически понятны даже рядовому пользователю. Анализ запросов – это возможность обнаружить спрятавшийся дефект гораздо быстрее, чем осуществляя его поиск в интерфейсе.
4. Мониторьте трафик на предмет запросов на другие (не ваши) сервера. Пример из жизни: фронтэнд сайта делал фриланс-разработчик, по завершению работы которого мы принялись за тестирование. Я имею привычку мониторить весь трафик тестируемого приложения: это позволило обнаружить, что вышеупомянутый разработчик без зазрения совести спрятал в «фронт» сайта запросы, которые работали на благо его личного интернет-магазина.
5. Мониторя трафик, внимательно следите за кодами состояний. Мы подробнее остановимся на этом пункте.
Коды состояния глазами адепта качества
Каждый ответ на любой запрос несет в себе массу полезной для разработчиков и специалистов по тестированию ПО информации. Одним из источников такой информации может стать код состояния: по этому коду клиент узнаёт о результатах его запроса и определяет, какие действия ему предпринять дальше. Набор кодов состояния является стандартом, он описан в соответствующих документах RFC. Каждый раз, когда вы создаете баг-репорт о неработающих ссылках, иных элементах веб-страницы или системных ошибках, обязательно указывайте ответы сервера: они сэкономят время разработчику при определении причин дефекта.
Все коды можно поделить на группы (сотые, двухсотые, трехсотые, четырехсотые и пятисотые) каждая группа-«сотня» несет свой тип информации.
По клику на картинку откроется полная версия.
Более детально с кодами состояния можно ознакомиться на Wikipedia.
На практике, используя при тестировании специальные приложения (тот же Fiddler), вы без труда сможете отсортировать свои запросы и ответы по коду состояния и отобрать, например, все 400-е и 500-е с последующим их анализом. Таким образом очень быстро «отлавливаются» дефекты с «отвалившимися» стилями, скриптами, файлами, функциями приложения и т.п.
Чем еще отличается веб-приложение от десктопного: больше особенностей – больше проблем!
Многопользовательская сущность веб-приложений
Широта аудитории приложений накладывает свой отпечаток на специфику работы.
1. Одно приложение одновременно может использоваться огромным количеством людей. Мы уже рассматривали вопрос нагрузочного тестирования, но также следует обратить внимание на то, что в число пользователей могут входить представители разных культур, языков и религий. Нам необходимо помнить об этом, особенно если речь идет о тестировании международного приложения.
2. Каждый пользователь может иметь свои уровни доступа. В идеальном варианте тестировщик создает для себя матрицу уровней доступа и тестирует каждый доступ в отдельности.
По клику на картинку откроется полная версия.
3. Пользователи с одним уровнем доступа могут обращаться к одним и тем же сущностям, что приводит к конкурентному доступу. Тестируется это довольно просто. Для примера рассмотрим систему, имеющую дело с договорами, которые можно создавать, публиковать, редактировать, аннулировать. Алгоритм работы таков: под несколькими окнами в режиме инкогнито авторизуемся в приложении под пользователями с разными уровнями доступа; далее выбранную для теста сущность открываем на редактирование, а под второй учетной записью эту же сущность пробуем перевести в статус «Аннулировано» – на этом этапе должен сработать контроль на конкурентный доступ. Операция аннулирования блокируется, а пользователю выдается сообщение о том, что сущность редактируется другим пользователем (поведение и приоритет действий определяются в соответствии с требованиями и особенностями продукта, но логика не меняется).
4. Широта аудитории говорит о том, что за монитором может находиться человек, имеющий злой умысел в отношении вашего ПО.
Сетевые страсти: веб-приложение в разных условиях передачи данных
Веб-приложения активно используют сеть, и это является источником возможных проблем. Таковой, например, является использование приложения в условиях низкой скорости передачи данных (в браузер Google Chrome, например, встроена функция Throttling, которая позволяет сильно занижать скорость передачи данных), в условиях потери пакетов или при отключении сети во время активной фазы работы приложения (способ имитации: сначала делаем скорость передачи данных с помощью Throttling минимальной, а потом прерываем сетевое соединение во время обработки запроса).
В любом из описанных выше случаев приложение должно работать корректно. При «падении» запроса (time out) или иной проблеме мы должны, перезагрузив страницу, снова получить полностью работающее веб-приложение без какого-либо намека на только что пережитый «урон». Для всех ли функций приложения необходимо подобные тесты? Ни в коем случае! В будущем можете ориентироваться на свой опыт, а на первых этапах в этих вопросах лучше проконсультироваться с разработчиками.
Тестирование безопасности веб-приложения: спаси, сохрани, защити 
Тестирование безопасности – отдельное направление тестирования, которое требует от специалиста фундаментальных знаний технического характера и хорошей профильной квалификации. Я отмечу ряд общих моментов, которые могут помочь любому тестировщику находить классические уязвимости, не допуская их выход на продакшен. Вопросы безопасности приложений регламентируются OWASP Guide, CHECK, ISACA, NIST Guideline, OSSTMM.
Существует ряд принципов безопасности, к которым относятся конфиденциальность, целостность и доступность:
1) Конфиденциальность – ограничение доступа к той или иной информации для определенной категории пользователей (или наоборот предоставление доступа только ограниченной категории).
2) Целостность включает в себя:
а) возможность восстановить данные в полном объеме при их повреждении;
б) доступ на изменение информации только определенной категории пользователей.
3) Доступность – иерархия уровней доступа и четкое их соблюдение.
Перечислим классические уязвимости современных веб-приложений:
1. XSS – генерация на странице продукта скриптов, представляющих опасность для пользователей продукта;
2. XSRF – уязвимость, при которой пользователь переходит с доверенной страницы на вредоносную, где воруются представляющие ценность пользовательские данные;
3. сode injection (PHP, SQL) – инъекция части исполнительного кода, которая делает возможным получить несанкционированный доступ к программному коду или базе данных и вносить в них изменения;
4. authorization bypass – это вид уязвимости, при котором можно получить несанкционированный доступ к учетной записи или документам другого пользователя;
5. переполнение буфера – явление, которого можно достичь во вредоносных целях, по своей сути представляет использование места для записи данных далеко за пределами выделенного буфера памяти.
При тестировании рекомендую использовать чит-листы уязвимостей XSS Filter Evasion Cheat Sheet и MySQL SQL Injection Cheat Sheet.
Практические советы: еще раз о насущном
Начинаем тестировать не с тестирования: с чего начать? 
Получив ответы на эти вопросы, о которых часто забывают новички, вы сэкономите свое время. Дальше переходите к непосредственной подготовке окружения и формированию стратегии тестирования.
Некогда думать, нужно тестировать! 
Любое тестирование требует содержательного подхода с применением техник тест-анализа и тест-дизайна. В противном случае вы рискуете навсегда остаться «monkey-тестером», ценность труда которого будет мизерна. В целом, ключевые положения тест-анализа и тест-дизайна применимы как к тестированию десктоп-приложений, так и к веб-у, но с существенной оговоркой: вы должны учитывать все упомянутые в статье нюансы. Отдельно хочу акцентировать внимание на том, что без стойкого понимания методик и способов применения тест-анализа и тест-дизайна тестировать качественно ПО практически невозможно.
Подай ключ «на 13»
В настоящее время существует огромное множество разнообразных инструментов, которые упрощают жизнь всем участникам разработки нового ПО. Следовательно, не стоит забывать о том, что помимо развития личных качеств, технических знаний и навыков, мы должны уметь хорошо пользоваться вспомогательными инструментами, каждый раз испытывая все новые и новые.
Выводы и напутствия
Подводя итоги, я хочу еще раз акцентировать внимание читателя на том, что «веб» развивался, развивается и будет развиваться, а количество используемых технологий, как и разнообразие дефектов, – увеличиваться. Возможно, когда-то придет закат эры «веб-а», но это не случится в ближайшие 5-10 лет, поэтому знание основ и понимание сути веб-приложений поистине бесценно. Любой тестировщик рано или поздно прикоснется к «веб-у» своей профессиональной «разрушительной» рукой, но только хороший специалист получит из этого максимально приближенный к требуемому результат.
Важно помнить, что тестирование ПО ставит перед каждым вступившим в стройные ряды сферы обеспечения качества ПО такие задачи, которые практически невозможно решать однозначно и по четкому алгоритму. Тестирование – это философия, творчество, полет мысли, основанный на четких и безоговорочных технических аспектах. Пожалуй, только тестировщикам приходится одновременно быть разработчиком, системным аналитиком, пользователем, заказчиком (для которого первоочередной интерес – финансовый или иной успех продукта), специалистом в предметной области и даже DBA.
Каждый из этих навыков QA Engineer должен развивать постоянно, и тогда он сможет избежать многих возможных проблем и остаться востребованным высококвалифицированным профессионалом. Остановка в развитии для специалиста из сферы обеспечения качества фактически приравнивается к профессиональной смерти (как минимум, «клинической» в том случае, если стремление к новым знаниям со временем возвращается). Движение – это жизнь. Всем добра!