Тестирование веб сервисов что это
Чек-лист тестирования WEB приложений
Привет! После публикации статьи «Чек-лист тестирования мобильных приложений», поступило большое количество сообщений про такой же чек-лист, только для WEB приложений. Чтобы ответить на этот вопрос была подготовлена универсальная шпаргалка, которую можно использовать при тестировании практически любого WEB приложения.
В данный чек-лист вошли только общие характеристики. Естественно, в тестируемом приложении может быть функциональность, для которой нужно применять отдельный подход и создать отдельные сценарии. То же самое верно для производительности, удобства использования, безопасности и прочего тестирования, которое необходимо вашему приложению.
Чек-лист для тестирования WEB приложений состоит из шести разделов:
Функциональное тестирование
В данном пункте нам важно убедиться, что наш продукт соответствует нужной функциональной спецификации, упомянутой в документации по разработке.
Что проверяем?
Интеграционное тестирование
Интеграционное тестирование проводится для того, чтобы убедиться, что ваше приложение совместимо со сторонними сервисами.
Что проверяем?
Тестирование безопасности
Данная проверка нацелена на поиск недостатков и пробелов с точки зрения безопасности нашего приложения.
Что проверяем?
Тестирование локализации и глобализации
Тестирование интернационализации/глобализации WEB приложения включает тестирование приложения для различных местоположений, форматов дат, чисел и валют. Тестирование локализации включает тестирование WEB приложения с локализованными строками, изображениями и рабочими процессами для определенного региона.
Что проверяем?
Тестирование удобства использования
Тестирование удобства использования подразумевает проверку навигации, контента, другая информация для пользователя.
Что проверяем?
Кросс-платформенное тестирование
Кросс-платформенное тестирование проводится, чтобы убедиться, что ваше приложение совместимо с другими браузерами, различными оболочками, аппаратным обеспечением устройства.
Тестирование веб сервисов или как пользоваться SoapUI
Допустим, вы интегрируете системы, используя веб-сервисы, или ваши клиентские приложения взаимодействуют с сервером посредством веб-сервисов, в этом случае вам просто необходимо использовать инструмент SoapUI для тестирования веб-сервисов и клиентов. Работа с программой SoapUI очень проста и позволяет воочию увидеть передаваемые и получаемые данные. Кроме того вы сможете провести нагрузочное тестирование вашего веб-сервиса и симулировать работу веб-сервиса.
О SoapUI
Итак, что же такое SoapUI? Это кроссплатформенное клиентское оконное приложение, написанное на языке Java. Использовать основной функционал приложения можно бесплатно. В платной версии программы, которая называется SoapUI Pro, вы сможете делать чуть больше, например, устанавливать плагины с помощью менеджера плагинов, проводить тесты драйверов данных, перехватывать трафик, оценивать покрытие ваших веб-сервисов тестами и создавать отчёты. Официальная страничка проекта находится здесь, скачать дистрибутив бесплатной версии программы можно здесь. Если бесплатной версии вам не хватает, вы можете скачать пробную версию SoapUI Pro здесь.
Если для разработки вы используете IDE IntelliJ, NetBeans или Eclipse, то вы можете интегрировать SoapUI прямо в IDE используя плагины. Как это сделать написано здесь. Я не буду останавливаться на этом варианте. Здесь я опишу лишь вариант использования SoapUI, как самостоятельного приложения. Установка на компьютер под управлением Windows проходит быстро и не вызывает вопросов, поэтому на этом этапе я тоже не буду заострять внимание.
Тестирование веб-сервиса
Прежде чем продолжить изучать программу SoapUI сделаем тестовый веб-сервис. Я сделаю это в Visual Studio, у моего сервиса будет только две функции GetSum1 и GetSum2, которые работают одинаково, но принимают и отдают результат по-разному.
После этого мы увидим, что для нашего тестового веб-сервиса создались запросы, причём для версий протокола SOAP 1.1 и 1.2. Дважды щёлкните на запрос «Request 1» и справа откроется дочернее окошко «Request 1», в котором вы увидите сформированный запрос.
Чтобы теперь проверить, как работает наш тестовый веб-сервис, замените вопросительные знаки значениями и нажмите на зелёный треугольник (сверху слева в этом же дочернем окне), чтобы отправить запрос. Когда запрос выполнится, в правой части отобразится ответ сервера (на картинке веб-служба вернула число 7), а снизу слева время выполнения (на картинке 3 миллисекунды) и количество полученных байт (на картинке 358 байт).
Теперь вычислим сумму с отрицательным числом. Как видно на картинки, функция GetSum1 с отрицательными числами работает дольше. Это ожидаемый результат, т.к. в функции GetSum1 специально стоит задержка 100мс, если хотя бы одно из полученных чисел отрицательное.
Если вместо числа передать строку, то вы увидите ошибку.
Третий параметр у нас необязательный. Проверим, что будет, если мы его уберём из запроса. После выполнения мы увидим, что сумма посчиталась, ошибок нет.
Как видите, проверить работу веб-сервиса можно очень просто и быстро.
Тесты
Теперь попробуем создать тесты для сервиса. Сначала добавьте в проект набор тестов (TestSuite).
Затем в набор тестов добавьте тестовый случай (TestCase).
Теперь в новый тестовый случай можно добавить шаги для теста. Добавим тестовый запрос «Test Request».
В диалоге «New TestRequest» выбираем тестируемую функцию «GetSum1».
На следующем диалоге можно выбрать дополнительные утверждения, которые будут проверяться при проведении тестов: Add SOAP Response Assertion (добавляет утверждение, что ответ является SOAP-сообщением), Add Schema Assertion (добавляет утверждение, что ответ соответствует схеме), Add NOT SOAP Fault Assertion (добавляет утверждение, что ответ не является SOAP-ошибкой). Также здесь можно указать, нужно ли создать шаблон для необязательных элементов в запросе. Поставьте первую и третью галочку.
После добавления шага теста можно задать параметры и выполнить тест. Для выполнения теста также нажимаем зелёный треугольник.
Теперь сделаем тестирование диапазона значений. Будем подставлять в параметр «a» значения от 1 до 5 и проверять сумму. Для этого сначала нужно добавить свойство, которое будет хранить текущее значение параметра «a», например, в тестовый случай «TestCase 1». Для этого дважды щёлкните по нему на панели «Navigator». Затем в открывшемся дочернем окне «TestCase 1» откройте вкладку «Properties», щёлкните на кнопку с плюсом и задайте новому свойству имя «aValue» и значение 1.
После выполнения запроса вы можно посмотреть, что было передано веб-сервису, в частности, какое значение параметра «a» было передано на сервер, на закладке «Raw» (сырые данные). Здесь вы увидите HTTP-запрос полностью вместе с заголовочной частью. Аналогично можно посмотреть HTTP-ответ от веб-сервиса.
Кстати, для более удобного доступа к свойствам вы можете включить режим отображения свойств на панели навигатора (маленькая кнопка слева сверху на панели). Тогда свойства можно просматривать прямо на панели «Navigator». После этого дважды щёлкнув на свойство в навигаторе, вы можете поменять его значение.
Как видите из картинки, свойства могут быть заданы для проекта в целом, для отдельного набора тестов (TestSuite) или для отдельной тестовой ситуации (TestCase).
Теперь сделаем установку свойству «aValue» значения 1 в начале тестирования. Для этого откройте тестовый случай «TestCase 1», откройте вкладку «Setup Script» (скрипт инициализации вызывается перед выполнением тестового случая) и добавьте сюда следующий код:
Здесь же сразу можно проверить, как выполняется скрипт. Для этого нажмите на зелёный треугольник. Если при выполнении возникнут ошибки, то появится диалоговое окно с их описанием. В нашем случае всё отработало нормально. Откройте вкладку «script log», чтобы увидеть наше сообщение.
Здесь нужно сразу заметить, что все скрипты в SoapUI по умолчанию пишутся на языке Groovy, и в статье я буду использовать этот скрипт. Справку по языку можно получить здесь. По желанию вы можете использовать JavaScript для написания скриптов, тогда для правильной интерпретации ваших скриптов нужно установить в свойстве проекта «Script Language» значение «Javascript». В этом случае для интерпретации скриптов будет использоваться движок Rhino.
Также обратите внимание, что над каждым окошком для написания скрипта перечислены доступные глобальные переменные. На картинке сверху – это переменные log, testCase, context и testRunner.
После добавления шага напишите следующий скрипт для изменения значения свойства:
Здесь вы сразу можете выполнить скрипт и увидеть на панели навигатора изменённое значение свойства «aValue», а на вкладке «Log Output» увидите наш лог.
Теперь попробуем циклично выполнять шаги «Test Requset» и «Groovy Script». Для того чтобы это сделать добавьте к скрипту следующие строчки:
Как видите, цикл будет выполняться пока значение свойства «aValue» меньше 10. Теперь откройте тестовый случай «TestCase 1» и выполните его. Как видите на вкладке «TestCase Log», всего выполнилось 18 шагов (9 «Test Request» и 9 «Groovy Script»).
И в диалоге «Script Assertion» пропишите скрипт проверки результата.
Здесь же сразу можно проверить результат, выполнив скрипт. На картинке видно, что скрипт выполнился успешно – утверждение истинно.
Теперь поменяем в качестве эксперимента параметр «aValue» – установим значение 5 и выполним тест «Test Request». После выполнения вы увидите, что тест провален (красная иконка в навигаторе) и увидите, какое утверждение не выполнено. В нашем случае – это утверждение «Script Assertion».
Теперь выполним всю ситуацию «TestCase 1». После выполнения на вкладке «TestCase Log» мы видим, что тестирование прошло с ошибкой. Выполнение было прервано на шаге 9. Предыдущие шаги были выполнены без ошибок. Дважды щёлкнув на шаг 9 в логе, мы можем узнать, какой запрос был передан веб-сервису и что было возвращено (в нашем случае сумма посчиталась неправильно).
Аналогичным образом вы можете добавлять любое количество тестов любой сложности. А затем при каждом обновлении вашего сервиса выполнять все тесты сразу, чтобы проверять его работоспособность.
Нагрузочное тестирование
Чтобы проверить, выдерживает ли сервер требуемую нагрузку, или понять, какие функции выполняются медленно, мы можем провести нагрузочное тестирование. В нашем примере умышленно сделана большая задержка в функции «GetSum2». Давайте обнаружим эту задержку с помощью нагрузочного тестирования.
для функции «GetSum1» и для функции «GetSum2»:
Теперь добавьте нагрузочный тест (пункт контекстного меню «New LoadTest»).
После добавления нагрузочного теста сразу всё готово к его запуску. Здесь вы можете задать количество потоков, стратегию выполнения и параметры для каждой стратегии (вы можете параллельно выполнять несколько тестов, используя разную стратегию). Выполните тест.
После выполнения в таблице вы увидите минимальное и максимальное время выполнения теста, среднее значение, количество ошибок и пр. На вкладке «LoadTest Log» будет указано время начала и окончания теста. Также вы можете посмотреть статистику и историю на графиках.
По таблице вы можете заметить, что тест «Test Request 2» выполняется дольше. В среднем 203,55 мс, а тест «Test Request 1» выполняется быстрее примерно в 2 раза. Вот мы и обнаружили, что в функции «GetSum2» есть задержка при выполнении.
Тестирование клиента
Теперь давайте попробуем создать имитацию веб-сервиса с помощью программы SoapUI. Это может пригодиться для тестирования клиента веб-сервиса. Ведь с помощью такого имитатора веб-сервиса вы сможете протестировать все возможные ситуации на клиенте.
Чтобы создать веб-сервис, щёлкните по SOAP-интерфейсу и в контекстном меню выберите пункт «Generate SOAP Mock Service».
В поднявшемся диалоге вы можете выбрать функции, для которых нужно создать операции сервиса, путь к сервису и порт. Нажмите «OK».
После того как сервис создан, дважды щёлкните по запросу, который хотите поправить, например, по «Response 1» и задайте параметр, который должна вернуть функция GetSum1. Вы можете здесь задать статическое значение, которое будет получать клиент или вычислять его в зависимости от входных параметров. Также здесь вы можете задать ответ-ошибку и протестировать, как клиент будет обрабатывать сообщение с ошибкой.
Мы здесь сделаем расчёт суммы и возврат результата с помощью скрипта. Откройте вкладку «Script» и напишите следующий код:
Вот так это выглядит в программе:
Теперь, можете запустить сервис. Для этого переключитесь в навигаторе на сервис, у меня это «Service1Soap MockService» и щёлкните по зелёному треугольнику. После запуска сверху будет двигаться бегунок показывающий, что сервис работает.
Теперь можно тестировать клиента. Я для примера сделал консольное приложение в Visual Studio, добавил в проект ссылку, указав ссылку на WSDL (WSDL можно получить, щёлкнув по кнопке с изображением зелёной фигуры, на картинке сверху она обведена зелёным кружком). Далее можно вызывать функцию сервиса «GetSum1». Вот код консольного приложения:
После выполнения приведённого кода программы в консоль будет выведен результат 7.
Также при создании сервиса вы можете тестировать его здесь же прямо из программы SoapUI.
Заключение
SoapUI – это мощный инструмент, который постоянно развивается, и при разработке веб-сервисов – это незаменимый инструмент для тестирования. Полное описание программы сделать в одной статье невозможно, да и не имеет смысла, ведь у каждого разные задачи. Но на сайте разработчика есть хорошее описание программы с примерами и справка по всем классам, которые можно использовать в скриптах.
В этой статье мы рассмотрим тестирование веб приложений и сайтов. Она довольно длинная, поэтому усаживайтесь по удобнее.
Основные виды тестирования сайта (веб-приложения)
Тестирование функциональности
Проверьте все ссылки, присутствующие на веб-странице, а также ссылки на базы данных, формы, используемые для подтверждения действий и получения информации от пользователей, файлы Cookie и т.д.
Проверьте все ссылки
Проверьте формы
Формы используются для получения информации от пользователей и взаимодействия с ними.
Что нужно проверить в формах:
Рассмотрим пример проекта поисковой системы, над которым я сейчас работаю. В проекте есть этапы регистрации рекламодателей и партнеров. Каждый шаг регистрации отличается от других, но зависит от остальных этапов. Поэтому весь процесс регистрации должен проходить правильно.
Есть различные виды валидации, например, проверка электронной почты, финансовой информации пользователя и т.д. Все поля с валидацией нужно протестировать в ручном или автоматическом режиме.
Тестирование файлов cookie
Cookie — это небольшие файлы, хранящиеся на компьютере пользователя. Чаще всего они используются для поддержки сеансов с авторизацией. Проверьте приложение, выключая и включая cookies в опциях браузера.
Проверьте HTML/CSS
Тестирование базы данных
Взаимодействие веб-приложения с базой данных является очень важным моментом. Проверьте целостность данных и проведите тестирование сайта на наличие ошибок при редактировании, удалении, изменении форм или других действиях, имеющих отношение к базе данных.
Проверьте, все ли запросы к базе данных выполняются правильно, данные извлекаются и обновляются должным образом.
При тестировании функциональности сайтов нужно проверить:
Ссылки
Формы
База данных
Следует проверить целостность базы данных.
Тестирование удобства использования (юзабилити сайта)
Тестирование юзабилити — это анализ взаимодействия пользователя и сайта, поиск ошибок и их устранение.
При этом проверяется:
Проверка навигации
Под навигацией подразумеваются средства для просмотра страниц пользователем. Это кнопки, блоки. А также то, как посетитель сайта использует ссылки на другие страницы.
Проверка контента
Контент должен быть логичным и простым для понимания. Проверьте текст на наличие ошибок. Применение темных цветов раздражает пользователей, не нужно использовать их в теме оформления.
Для контента и фона страницы лучше применять общепринятые стандарты, чтобы цвет шрифта, рамок и т.д. не раздражал пользователей.
Контент должен быть содержательным, ссылки работать надлежащим образом, изображения соответствующего размера. Это основные стандарты, соблюдаемые при веб-разработке. Ваша задача — проверить все в рамках тестирования пользовательского интерфейса.
Другая информация для пользователей
Варианты поиска, карта сайта, справочные материалы и т.д. Проверьте работу всех ссылок в карте сайта. Функция « Поиск по сайту » должна помогать легко находить нужный контент.
Тестирование пользовательского интерфейса
Нужно проверить, правильно ли осуществляется связь с сервером. Следует проверить совместимость сервера с используемым программным обеспечением, аппаратными средствами, сетью и базой данных.
Если база данных или веб-сервер для какого-либо запроса, исходящего от сервера приложения, возвращает сообщение об ошибке, сервер приложения должен фиксировать его и отображать пользователю.
Проверьте, что происходит, когда пользователь прерывает какое-либо действие. А также, что происходит при повторном подключении к серверу в ходе выполнения какой-либо операции.
Проверка совместимости
Совместимость с браузерами
Работа некоторых веб-приложений зависит от типа браузера. Сайт должен быть совместим с различной конфигурацией и параметрами разнообразных браузеров.
Совместимость с операционными системами
Просмотр на мобильных устройствах
Проведите тестирование сайта на мобильных устройствах и проверьте, как просматриваются веб-страницы с помощью мобильных браузеров. Проблемы с совместимостью также могут возникнуть из-за мобильных устройств. Также не стоит забывать о тестировании сайта на разных разрешениях.
Параметры печати
Если вы предусматриваете возможность печати страницы, удостоверьтесь, что шрифты, выравнивание, графика и т. д. отображаются на бумаге должным образом. Страницы должны подходить под размеры, которые устанавливаются в опциях печати.
Тестирование производительности сайта
Тестирование производительности сайта или веб-приложения должно включать в себя:
Проверьте производительность приложения на различной скорости интернета.
Нагрузочное тестирование сайта ( веб-приложения ) — это тестирование, при котором большое количество пользователей одновременно выполняют запрос к одной и той же странице. Выдерживает ли система пиковые нагрузки?
Стрессовое тестирование — нагрузка системы, выходящая за пределы установленных лимитов. Стрессовое тестирование выполняется с целью достичь сбоя в работе сайта или веб-приложения путем увеличения нагрузки. А также проверить, как система реагирует на стресс, и как она восстанавливается после сбоев. Стрессовой нагрузке подвергают поля для ввода информации, входа и регистрации.
ab тестирование функциональности также включает в себя проверку на ошибки, связанные с оперативной памяти.
Тест производительности можно применять для проверки масштабируемости сайта или оценки продуктивности при использовании стороннего программного обеспечения.
Скорость соединения
Сплит тестирование сайта при использовании различных вариантов интернет-соединения: через модем, ISDN и т.д.
Нагрузка
Стрессовая нагрузка
Тестирование безопасности
Ниже приведены некоторые наборы для тестирования веб-безопасности:
Основной причиной тестирования безопасности сайта является поиск потенциальных уязвимостей и их последующее устранение.
Моменты, которые следует учитывать при тестировании сайта
Есть множество типов серверов и браузеров различных версий. Между ними есть небольшие, но значимые различия.
Пример сценариев тестирования сайта
Дополнительные факторы, которые следует учесть при тестировании сайта:
Пожалуйста, опубликуйте ваши отзывы по текущей теме статьи. За комментарии, отклики, дизлайки, лайки, подписки огромное вам спасибо!
Дайте знать, что вы думаете по этой теме материала в комментариях. За комментарии, подписки, дизлайки, отклики, лайки огромное вам спасибо!