тестирование веб приложений пример
В этой статье мы рассмотрим тестирование веб приложений и сайтов. Она довольно длинная, поэтому усаживайтесь по удобнее.
Основные виды тестирования сайта (веб-приложения)
Тестирование функциональности
Проверьте все ссылки, присутствующие на веб-странице, а также ссылки на базы данных, формы, используемые для подтверждения действий и получения информации от пользователей, файлы Cookie и т.д.
Проверьте все ссылки
Проверьте формы
Формы используются для получения информации от пользователей и взаимодействия с ними.
Что нужно проверить в формах:
Рассмотрим пример проекта поисковой системы, над которым я сейчас работаю. В проекте есть этапы регистрации рекламодателей и партнеров. Каждый шаг регистрации отличается от других, но зависит от остальных этапов. Поэтому весь процесс регистрации должен проходить правильно.
Есть различные виды валидации, например, проверка электронной почты, финансовой информации пользователя и т.д. Все поля с валидацией нужно протестировать в ручном или автоматическом режиме.
Тестирование файлов cookie
Cookie — это небольшие файлы, хранящиеся на компьютере пользователя. Чаще всего они используются для поддержки сеансов с авторизацией. Проверьте приложение, выключая и включая cookies в опциях браузера.
Проверьте HTML/CSS
Тестирование базы данных
Взаимодействие веб-приложения с базой данных является очень важным моментом. Проверьте целостность данных и проведите тестирование сайта на наличие ошибок при редактировании, удалении, изменении форм или других действиях, имеющих отношение к базе данных.
Проверьте, все ли запросы к базе данных выполняются правильно, данные извлекаются и обновляются должным образом.
При тестировании функциональности сайтов нужно проверить:
Ссылки
Формы
База данных
Следует проверить целостность базы данных.
Тестирование удобства использования (юзабилити сайта)
Тестирование юзабилити — это анализ взаимодействия пользователя и сайта, поиск ошибок и их устранение.
При этом проверяется:
Проверка навигации
Под навигацией подразумеваются средства для просмотра страниц пользователем. Это кнопки, блоки. А также то, как посетитель сайта использует ссылки на другие страницы.
Проверка контента
Контент должен быть логичным и простым для понимания. Проверьте текст на наличие ошибок. Применение темных цветов раздражает пользователей, не нужно использовать их в теме оформления.
Для контента и фона страницы лучше применять общепринятые стандарты, чтобы цвет шрифта, рамок и т.д. не раздражал пользователей.
Контент должен быть содержательным, ссылки работать надлежащим образом, изображения соответствующего размера. Это основные стандарты, соблюдаемые при веб-разработке. Ваша задача — проверить все в рамках тестирования пользовательского интерфейса.
Другая информация для пользователей
Варианты поиска, карта сайта, справочные материалы и т.д. Проверьте работу всех ссылок в карте сайта. Функция « Поиск по сайту » должна помогать легко находить нужный контент.
Тестирование пользовательского интерфейса
Нужно проверить, правильно ли осуществляется связь с сервером. Следует проверить совместимость сервера с используемым программным обеспечением, аппаратными средствами, сетью и базой данных.
Если база данных или веб-сервер для какого-либо запроса, исходящего от сервера приложения, возвращает сообщение об ошибке, сервер приложения должен фиксировать его и отображать пользователю.
Проверьте, что происходит, когда пользователь прерывает какое-либо действие. А также, что происходит при повторном подключении к серверу в ходе выполнения какой-либо операции.
Проверка совместимости
Совместимость с браузерами
Работа некоторых веб-приложений зависит от типа браузера. Сайт должен быть совместим с различной конфигурацией и параметрами разнообразных браузеров.
Совместимость с операционными системами
Просмотр на мобильных устройствах
Проведите тестирование сайта на мобильных устройствах и проверьте, как просматриваются веб-страницы с помощью мобильных браузеров. Проблемы с совместимостью также могут возникнуть из-за мобильных устройств. Также не стоит забывать о тестировании сайта на разных разрешениях.
Параметры печати
Если вы предусматриваете возможность печати страницы, удостоверьтесь, что шрифты, выравнивание, графика и т. д. отображаются на бумаге должным образом. Страницы должны подходить под размеры, которые устанавливаются в опциях печати.
Тестирование производительности сайта
Тестирование производительности сайта или веб-приложения должно включать в себя:
Проверьте производительность приложения на различной скорости интернета.
Нагрузочное тестирование сайта ( веб-приложения ) — это тестирование, при котором большое количество пользователей одновременно выполняют запрос к одной и той же странице. Выдерживает ли система пиковые нагрузки?
Стрессовое тестирование — нагрузка системы, выходящая за пределы установленных лимитов. Стрессовое тестирование выполняется с целью достичь сбоя в работе сайта или веб-приложения путем увеличения нагрузки. А также проверить, как система реагирует на стресс, и как она восстанавливается после сбоев. Стрессовой нагрузке подвергают поля для ввода информации, входа и регистрации.
ab тестирование функциональности также включает в себя проверку на ошибки, связанные с оперативной памяти.
Тест производительности можно применять для проверки масштабируемости сайта или оценки продуктивности при использовании стороннего программного обеспечения.
Скорость соединения
Сплит тестирование сайта при использовании различных вариантов интернет-соединения: через модем, ISDN и т.д.
Нагрузка
Стрессовая нагрузка
Тестирование безопасности
Ниже приведены некоторые наборы для тестирования веб-безопасности:
Основной причиной тестирования безопасности сайта является поиск потенциальных уязвимостей и их последующее устранение.
Моменты, которые следует учитывать при тестировании сайта
Есть множество типов серверов и браузеров различных версий. Между ними есть небольшие, но значимые различия.
Пример сценариев тестирования сайта
Дополнительные факторы, которые следует учесть при тестировании сайта:
Пожалуйста, опубликуйте ваши отзывы по текущей теме статьи. За комментарии, отклики, дизлайки, лайки, подписки огромное вам спасибо!
Дайте знать, что вы думаете по этой теме материала в комментариях. За комментарии, подписки, дизлайки, отклики, лайки огромное вам спасибо!
Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA
Продолжу хвастаться статусом книги.
• Почему хуки – это лучшее что произошло в развиии Октябрьская лента: лучшее за месяц
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Перевод: Ольга Алифанова
Во время тестирования веб-приложения нужно обращать внимание на нижеперечисленные пункты. Этот чеклист применим практически к любому типу веб-приложений в зависимости от бизнес-требований.
Чек-лист для тестирования веб-приложений состоит из:
Теперь давайте рассмотрим каждый пункт по отдельности.
Тестирование удобства использования
Какова цель этого тестирования?
Тест удобства использования удостоверяется в простоте и эффективности использования продукта при использовании стандартных практик тестирования удобства использования.
Сценарии тестирования удобства использования:
Какова цель функционального тестирования?
Цель функционального тестирования – убедиться, что ваш продукт соответствует нужной функциональной спецификации, упомянутой в вашей документации по разработке.
Сценарии функционального тестирования:
Какова цель тестирования совместимости?
Сценарии тестирования совместимости:
Инструмент для тестирования совместимости
Spoon.net: Spoon.net предоставляет доступ к тысячам приложений (браузеров), не требующих установки. Этот инструмент помогает вам тестировать приложение в разных браузерах на одной и той же машине.
Тестирование баз данных
Чтобы тестировать базы данных, тестировщик должен знать следующее:
Понимая вышеперечисленные пункты, тестировщик может легко написать сценарии для тестирования баз данных.
Сценарии тестирования баз данных:
Что такое тестирование безопасности?
Тестирование безопасности нацелено на поиск недостатков и пробелов с точки зрения безопасности приложения.
Сценарии тестирования безопасности:
Что такое тестирование производительности?
Тестирование производительности проводится для оценки соответствия системы или компонента специфичным требованиям к производительности.
Общие тестовые сценарии:
Как проводится тестирование производительности? Вручную или автоматически?
В целом невозможно проводить тестирование производительности вручную по ряду причин:
Чтобы справиться с вышеперечисленными проблемами, используются специальные инструменты тестирования производительности. Ниже перечислены некоторые из них:.
Автоматизация тестирования Web-приложений
Автоматизация тестирования – место встречи двух дисциплин: разработки и тестирования. Наверное поэтому, я отношу эту практику к сложным, но интересным.
Зачем так сложно?
Слои приложения в автоматизированном тестировании
Технический драйвер
Создадим отдельный класс, который возьмет на себя логику чтения конфига, создания и уничтожения веб-драйвера.
Стало немного лучше. Теперь мы уверены, что всегда-будет использоваться только один веб-драйвер. Все настройки в конфиге, поэтому мы можем менять драйвер и другие настройки без перекомпиляции.
Контекст тестирования
Page Objects
Паттерн Page Objects хорошо зарекомендовал себя в автоматизации тестирования.
Основная идея – инкапсулировать логику поведения страницы в классе страницы. Таким образом, тесты будут работать не с низкоуровневым кодом технического драйвера, а с высокоуровневой абстракцией.
Чего не хватает в Page Objects
И «виджет» с результатами
В NuGet есть пакет WebDriver.Support с прекрасным методом PageFactory.InitElements.
Метод хорош, но имеет побочные эффекты. PageFactory из пакета WebDriver.Support возвращает прокси и не дожидается загрузки элемента. При этом, если все методы синхронизации работают с классом By, который пока не умеет работать с атрибутом FindsBy.
Эта проблема решается созданием базового класса Page.
Для того, чтобы реализовать метод WaitUntilLoaded достаточно собрать все публичные свойства с атрибутами FindBy и воспользоваться классом WebDriverWait. Я опущу техническую реализацию этих методов. Важно, что на выходе мы получим простой и изящный код:
Остался последний неудобный случай. Существуют некоторые виджеты, которые скрывают/показывают часть элементов в зависимости от состояния. Разбивать такой виджет на несколько с одним свойством каждый – нецелесообразно.
Решение тоже нашлось.
Не буду утомлять технической реализаций этих методов. Давайте посмотрим, как будет выглядеть код после рефакторинга.
Тесты
Перепишем тест еще раз
Уже почти идеально. Вынесем магические строки в атрибут TestCase и добавим комментарий к Assert’у
Гайдлайн автоматизатора
Функциональное тестирование веб-приложений без боли
Иногда в жизни бывает так — вот ждёшь, ждёшь чего-то, изучаешь теорию по данному вопросу, рассматриваешь разные подходы к решению, дискутируешь с такими же ищущими как ты, внимаешь гласу признанных гуру, но не продвигаешься дальше ни на дюйм. Потом бросаешь, забываешь вообще об этом вопросе, занимаешься другими делами, и вдруг — на тебе, всё встало на свои места, из разрозненных элементов сложилась чудесная мозаика, нагрянуло просветление, а волосы вдруг стали густыми и шелковистыми.
Вот примерно такая же история с автоматическим функциональным(приёмочным) тестированием. О такой классной штуке как автоматические тесты писал ещё Сам Кент Бек. Ну, а автоматические функциональные тесты — это вообще лакомый кусок для современных agile методик разработки ПО. Например, тот же Scrum — включает в себя практику «Демо», в ходе которой заказчику нужно показать развитие продукта, осуществлённое в ходе итерации.
Я, конечно, не спец agile-практик, и не изучал рынок инструментов для функционального тестирование веб проектов — возможно, и раньше в этом сегменте всё было зашибись. Но за те 5 лет, что я работаю программистом — я всего лишь пару раз слыхал такие слова автоматическое функциональное тестирование, Selenium и ни разу не видел применения на практике.
Так вот, возвращаясь к лирическому вступлению, мне кажется, что то колоссальное качественное изменение как раз и произошло недавно. И есть ощущение, что в ближайшее время только ленивый пренебрежет функциональным тестированием своего веб проекта.
Что же собственно произошло? Я подписан на RSS-ку блога Springsource, и однажды обнаружил статью с вот таким интригующим названием — The future of functional web testing?.
Инструменты Geb и Spock, описанные в данной статье, меня зацепили, и я решил попробовать.
Собственно далее, я постараюсь наступить на горло песне прервать приступ графоманства и описать простой пример с использованием данных инструментов.
Установка инфраструктуры
Первый функциональный тест
В данном параграфе будет приведён пример автоматизации простого, но несомненно полезного функционального теста.
Суть функционального теста будет состоять в том, чтобы:
— войти на сайт Википедии
— набрать в поиске «Функциональное тестирование»
— убедиться в том, мы действительно попали на желаемую страницу
(например, мы поищем вхождение в текст страницы строки «это тестирование ПО в целях проверки реализуемости функциональных требований»)
Структура каталога проекта
Структура каталога проекта для тестирования выглядит следующим образом:
pom.xml — файл с описанием проекта в Maven
simplefunctest — пакет, в котором будут храниться классы для описания тестов
Собственно Тест
class MyFirstSpec extends GebSpec <
def «test search functional testing wiki page» () <
given: «we are at main wiki page»
to MainWikiPage
when : «try to search functional testing page»
searchField.value( «Функциональное тестирование» )
searchButton.click()
class MyFirstSpec extends GebSpec
def «test search functional testing wiki page» ()
given: «we are at main wiki page»
to MainWikiPage
when : «try to search functional testing page»
searchField.value( «Функциональное тестирование» )
searchButton.click()
then : «check we are on functional testing page»
at FunctionalTestingWikiPage
Описание главной страницы Википедии
class MainWikiPage extends Page
Описание страницы результата поиска
class FunctionalTestingWikiPage extends Page <
Собственно старт теста
Бинго! У вас должен стартовать FireFox(он настроен как браузер по умолчанию для тестов) и выполнить(без вашего участия(. )) то, что мы задумали.
Возможно, Firefox вам будет недостаточно и вы заходите прогнать тест в IE(для этого настроен специальный профиль):
Заключение
Я не буду обременять ни себя, ни вас описанием библиотек-их есть у него в достаточном количестве на сайтах этих библиотек, а просто порекомендую забрать из репозитория проект и попробовать самостоятельно.
Функциональное тестирование современных 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 выглядит очень привлекательным вариантом, к тому же при сочетании легковесности и функциональности.