МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ
РОССИЙСКОЙ ФЕДЕРАЦИИ
ФГБОУ ВО «Брянский государственный технический университет»
Факультет отраслевой и цифровой экономики
Кафедра «Цифровая экономика»
Направление 09.04.03 «Прикладная информатика»
Профиль «Информационная аналитика в цифровой экономике»
КУРСОВОЙ ПРОЕКТ
Разработка автоматизированных тестов API https://the-one-api.dev/ с
помощью SoapUI
Студент
Д.А. Бубало
(подпись)
Группа
О-22-ПИ-иацэ-М
Преподаватель
к.т.н., доцент
учёная степень, звание
.
(ИО Фамилия)
Я.С. Прозоров я
(подпись)
(ИО Фамилия)
«___» __________ 2022 г.
Брянск
БГТУ
2022
СОДЕРЖАНИЕ
Введение......................................................................................................... 3
1. Понятие тестирования .............................................................................. 4
1.1. Автоматизированное тестирование и его значение для разработки
программного обеспечения ........................................................................ 4
1.2. Анализ процесса тестирования ............................................................. 5
2. Изучение Rest API и SoapUI .................................................................... 7
2.1. Rest API ................................................................................................... 7
2.2. SoapUI.................................................................................................... 11
3. Создание и настройка автоматизированных тестов ............................ 20
3.1. Создание запроса.................................................................................. 22
3.2. Проведение тестирования ................................................................... 23
Заключение .................................................................................................. 24
Список используемых источников ............................................................ 26
2
ВВЕДЕНИЕ
В современном мире программное обеспечение используется практически
во всех сферах нашей жизни, огромные средства тратятся на разработку
разнообразных программ, востребованных в промышленности и бизнесе, в
индустрии развлечений, в образовании и медицине. Задачи снижения стоимости
разработки программного обеспечения и улучшения качества выпускаемой
продукции
являются
одними
из
наиболее
актуальных
в
индустрии
информационных технологий.
Автоматизация тестирования позволяет значительно сократить расходы
компаний-разработчиков, сэкономить время и ресурсы, затрачиваемые на
тестирование, снизить риск выпуска на рынок некачественного продукта.
Поэтому технологии автоматизации тестирования набирают все большую
популярность среди компаний, связанных с разработкой программных
продуктов. Это и определяет актуальность темы, выбранной для курсовой
работы.
Рынок
веб
приложений
–
один
из
самых
перспективных
и
быстрорастущих. При этом автоматизация тестирования именно мобильных
приложений является относительно молодой областью. Инструменты и
технологии, использующиеся в этой области, относительно мало изучены и
только завоевывают рынок и доверие разработчиков. При этом именно
мобильные программные приложения, как никакие другие, нуждаются в
автоматизированном
тестировании
в
силу
разнообразия
линейки
поддерживаемых устройств и версий операционных систем мобильных
устройств, необходимости тестирования в портретном и альбомном режиме, при
3
различных соединениях с интернетом и прочее. Это определяет практическую
новизну проекта.
1. Понятие тестирование
Тестирование
является
важной
частью
процесса
разработки
программных продуктов и входит в число наиболее эффективных способов
обеспечения их качества. Причем под качеством в сфере разработки
программных средств подразумевается не только надежность программы или
удобство пользования. В соответствии с ГОСТ 28806–90, качеством
программного
средства
обуславливающих
его
считается
пригодность
совокупность
удовлетворять
его
свойств,
заданные
и
подразумеваемые потребности в соответствии с его назначением [1]. Таким
образом, качественным считается тот продукт, который удовлетворяет
критериям качества, предъявляемым к нему заинтересованными лицами,
заказчиками либо пользователями данного продукта. Программный продукт
должен соответствовать определенным стандартам и ожиданиям для того,
чтобы его можно было считать качественным. Согласно определению
Гленфорд Майерс, тестированием называется процесс исследования
программы с целью нахождения в ней ошибок [2]. И здесь, опять же, под
ошибками, или дефектами программы, понимаются изъяны в разработке
программного продукта, следствием которых становится несоответствие
ожидаемых результатов выполнения программного продукта и фактически
полученных результатов [3]. То есть по сути задачей процесса тестирования
является выявление фактов расхождения реального поведения приложения с
требованиями, предъявляемыми к нему.
1.1.
Автоматизированное тестирование и его значение для
разработки программного обеспечения
4
На
практике
тестирование
осуществляется
путем
выполнения
определенного набора действий в тестируемом приложении, получении
результатов выполнения этих действий и дальнейшей сверки их с данными,
которые определены как эталонные. Выполняться этот процесс может как
вручную, специалистами по тестированию, так и автоматически, с
использованием различных 16 программных средств. Именно такой процесс
верификации программного обеспечения, в ходе которого основные функции
и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача
результата, выполняются автоматически при помощи инструментов для
автоматизированного тестирования, и называется автоматизированным
тестированием программного обеспечения [4]. У автоматизированного
тестирования есть как свои преимущества, так и недостатки. К сильным
сторонам автоматизированного тестирования относят:

быстрая
скорость выполнения,
намного
превосходящая
возможности человека;

отсутствие
влияние
«человеческого
фактора»
(невнимательность, усталость);

возможность многократного выполнения тестов и снижение
затрат через это;

выполнение тест-кейсов особенной сложности, недоступных
человеку;

способность хранить, анализировать в удобной форме
колоссальные объемы данных;

способность
приложением,
с
выполнять
операционной
низкоуровневые
системой
и
т.д.
действия
К
с
недостаткам
автоматизированного тестирования относятся:

персонала
необходимость
для
привлечения
автоматизации
взамен
высококвалифицированного
возможности
низкоквалифицированный труд тестировщиков;
5
использовать

затраты
на средства автоматизации, на разработку и
сопровождение тестов;

финансовые затраты и риски, связанные с наличием большого
количества средств автоматизации и сложностью выбора;

устаревание
тестов
в
случаях
изменений
требований,
переработки интерфейсов тестируемых продуктов и т.п.
1.2 . Анализ процесса тестирования
Автоматизация тестирования не позволяет полностью исключить ручное
тестирование из процесса разработки, но значительно снижает его долю,
помогает убрать рутину из процесса тестирования, снизить стоимость и
значительно улучшить качество разрабатываемых программных продуктов.
Тестирование является одной из наиболее трудоемких фаз разработки
программного обеспечения, занимающей большое количество времени. При
этом цена исправления ошибки, как правило, напрямую зависит от времени,
которое проходит с момента ее возникновения до момента обнаружения. В своей
книге «A Practitioner’s Guide to Software Test Design» Ли Копланд приводит
ответы, которые дают специалисты по тестированию на вопрос о том, с какими
наиболее распространенными проблемами им приходится сталкиваться в их
работе: «недостаточно времени, чтобы тестировать тщательно», «слишком
много
комбинаций
входных
данных»,
«недостаточно
времени,
чтобы
протестировать хорошо», «слишком мало времени выделено на тестирование»
[5]. Почти все называли проблемы, связанные с объемом работы, которую
необходимо выполнить, и количеством времени, которое необходимо затратить
для того, чтобы качественно протестировать программный продукт. Поэтому
естественно, что идея об автоматизации процесса тестирования, позволяющей
решить вопрос с недостатком времени для осуществления качественного
тестирования, становилась все более актуальной по мере увеличения сложности
разрабатываемых программных продуктов и роста требований к их качеству.
Попытки автоматизировать процесс тестирования совершались еще в 80-ых
6
годах. В 90-ых появились первые инструментальные средства автоматизации
тестирования. А в нулевые годы автоматизация тестирования воспринималась
уже как неотъемлемая часть большинства проектов. 18 Сегодня сложно
представить себе разработку крупного программного проекта без использования
в процессе разработки автоматизированного тестирования. Современный этап
развития тестирования характеризуется глубокой интеграцией тестирования с
процессом разработки в целом, а также широчайшим использованием
автоматизации, колоссальным набором технологий и инструментальных средств
для автоматизации [6].
2 ИЗУЧЕНИЕ REST API И SOAPUI
2.1. REST API
API (Application Programming Interface) обеспечивает взаимодействие
между двумя системами. Это как винтик, связывающий две детали, или как
шестеренка, при помощи которой приводятся в движение две соседние
шестеренки (как на картинке ниже). API - как шестеренка, приводящая в
движение две соседние шестеренки
API часто получают данные из пользовательских интерфейсов. Джим
Биссо, опытный технический писатель API в области Силиконовой долины,
описал API, используя аналогию калькулятора компьютера. Когда нажимаем
кнопки, скрытые функции взаимодействуют с другими компонентами для
получения информации. Как только информация возвращается, калькулятор
представляет данные обратно в графический интерфейс.
Когда нажимаем кнопки, скрытые функции взаимодействуют с другими
компонентами и выдают информацию
API работают аналогичным образом. При нажатии на кнопку в интерфейсе,
запускаются внутренние функции, чтобы передать и получить информацию. Но
вместо того, чтобы получать информацию из одной и той же системы, веб-API
вызывают удаленные сервисы в сети, чтобы получить их информацию.
7
В конечном счете, разработчики вызывают API незримо для пользователя
для извлечения информации в свои приложения. Кнопка в графическом
интерфейсе пользователя программно подключена для вызова внешних служб.
Например, кнопки Twitter или Facebook, которые взаимодействуют с
социальными сетями, или видео Youtube, которые извлекают видео с
youtube.com, работают под управлением веб-API.
API, использующие протокол HTTP = веб-сервисы
«Веб-сервис» - это веб-приложение, предоставляющее ресурсы в формате,
используемом другими компьютерами. Веб-сервисы включают в себя различные
типы API, в том числе REST и SOAP API. Веб-сервисы - это, в основном, запросы
и ответы между клиентами и серверами (компьютер запрашивает ресурс, а вебсервис отвечает на запрос).
API, использующие протокол HTTP для передачи запросов и ответов,
рассматриваются как «веб-сервисы». В случае веб-сервисов клиент, делающий
запрос на ресурс, и сервер API, предоставляющий ответ, могут использовать
любой язык программирования или платформу. Не имеет значения, какой ЯП
или платформа будут использоваться, потому что запрос сообщения и ответ
сделаны через общий веб-протокол HTTP.
Веб-протокол является частью прекрасного веб-сервисов: они независимы
от языка и поэтому совместимы между различными платформами и системами.
При документировании REST API не имеет значения, строят ли инженеры API с
помощью Java, Ruby, Python или какого-либо другого языка. Запросы
выполняются через HTTP, и ответы возвращаются через HTTP.
Когда вы разрабатываете RESTful сервисы, вы должны сосредоточить свое
внимание на ресурсах приложения. Способ, которым мы идентифицируем
ресурс для предоставления, состоит в том, чтобы назначить ему URI —
универсальный
идентификатор
ресурса:
 Создать пользователя: POST /users
8
 Удалить пользователя: DELETE /users/1
 Получить всех пользователей: GET /users
 Получить одного пользователя: GET /users/1
Важно отметить, что с REST вам нужно думать о приложении с точки зрения
ресурсов:
Определите, какие ресурсы
вы
хотите
открыть для
внешнего
мира
Используйте глаголы, уже определенные протоколом HTTP, для
выполнения
Вот

как
операций
с
обычно
этими
реализуется
служба
ресурсами.
REST:
Формат обмена данными: здесь нет никаких ограничений. JSON — очень
популярный формат, хотя можно использовать и другие, такие как XML

Транспорт: всегда HTTP. REST полностью построен на основе HTTP.

Определение сервиса: не существует стандарта для этого, а REST является
гибким. Это может быть недостатком в некоторых сценариях, поскольку
потребляющему приложению может быть необходимо понимать форматы
запросов и ответов. Однако широко используются такие языки
определения веб-приложений, как WADL (Web Application Definition
Language) и Swagger.
REST фокусируется на ресурсах и на том, насколько эффективно вы
выполняете
операции
с
ними,
используя
HTTP.
HTTP определяет следующую структуру запроса:

строка запроса (request line) — определяет тип сообщения

заголовки запроса (header fields) — характеризуют тело сообщения,
параметры передачи и прочие сведения

тело сообщения (body)
9
HTTP определяет следующую структуру ответного сообщения (response):

строка состояния (status line), включающая код состояния и
сообщение о причине

поля заголовка ответа (header fields)

дополнительное тело сообщения (body)
Методы HTTP-запроса.
Метод, используемый в HTTP-запросе, указывает, какое действие вы
хотите выполнить с этим запросом. Важные примеры:

GET: получить подробную информацию о ресурсе

POST: создать новый ресурс

PUT: обновить существующий ресурс

DELETE: Удалить ресурс
Код статуса ответа HTTP.
Код состояния всегда присутствует в ответе HTTP. Типичные примеры:
 200 — успех
 404 — cтраница не найдена
В статье приведен на верхнем уровне обзор архитектурного стиля REST.
Подчеркивается тот факт, что HTTP является основным строительным блоком
REST сервисов. HTTP — это протокол, который используется для определения
структуры запросов и ответов браузера. Мы видели, что HTTP имеет дело
главным образом с ресурсами, доступными на веб-серверах. Ресурсы
идентифицируются с помощью URI, а операции над этими ресурсами
выполняются с использованием глаголов, определенных протоколом HTTP.
Наконец, мы рассмотрели, как службы REST наилучшим образом
используют функции, предлагаемые HTTP, для предоставления ресурсов
10
внешнему миру. REST не накладывает никаких ограничений на форматы
представления ресурсов или на определение сервиса.
Диаграмма ниже показывает общую модель REST API:
Рисунок 1 – REST API model
Как видно, между клиентом и сервером API существует запрос и ответ.
Клиент и сервер могут быть основаны на любом языке, но HTTP - это протокол,
используемый для передачи сообщения. Этот шаблон запроса и ответа, по сути,
является принципом работы API REST.
Любой язык программирования, создающий запрос, будет по-своему
отправлять веб-запрос и анализировать ответ на своем языке. Эти специфичные
для языка функции отправки запросов и анализа ответов не являются частью
11
REST API (хотя они могут быть предоставлены в прилагаемом SDK). REST API
не зависит от языка и обрабатывает входящую и исходящую информацию по
HTTP.
2.2. ИЗУЧЕНИЕ SOAPUI
SOAP
–
это
легкий
протокол
для
обмена
информацией
в
децентрализованной распределенной среде. Это протокол на основе XML,
который состоит из трех частей: конверт, который определяет структуру для
описания того, что находится в сообщении и как его обрабатывать; набор
правил кодирования для выражения экземпляров определяемых приложением
типов данных; и соглашение для представления удаленных вызовов процедур и
ответов.
SOAP – Важные функции. Ниже приведены некоторые важные функции
SOAP.

Это коммуникационный протокол, предназначенный для общения через
Интернет.

Это может расширить HTTP для обмена сообщениями XML.

Он обеспечивает передачу данных для веб-сервисов.

Он может обмениваться полными документами или вызывать удаленную
процедуру.

Может использоваться для трансляции сообщения.

Он не зависит от платформы и языка.

Это XML-способ определения, какая информация отправляется и как.

Это позволяет клиентским приложениям легко подключаться к
удаленным службам и вызывать удаленные методы.

Это коммуникационный протокол, предназначенный для общения через
Интернет.

Это может расширить HTTP для обмена сообщениями XML.

Он обеспечивает передачу данных для веб-сервисов.
12

Он может обмениваться полными документами или вызывать удаленную
процедуру.

Может использоваться для трансляции сообщения.

Он не зависит от платформы и языка.

Это XML-способ определения, какая информация отправляется и как.

Это позволяет клиентским приложениям легко подключаться к
удаленным службам и вызывать удаленные методы.
Хотя SOAP может использоваться в различных системах обмена
сообщениями и может доставляться через различные транспортные протоколы,
первоначальная цель SOAP – удаленные вызовы процедур, транспортируемые
через HTTP. Другие платформы, такие как CORBA, DCOM и Java RMI,
предоставляют функциональность, аналогичную SOAP, но сообщения SOAP
написаны полностью в XML и поэтому уникально независимы от платформы и
языка.
SOAP-сообщение
–
это
обычный
XML-документ,
содержащий
следующие элементы:

Конверт – определяет начало и конец сообщения. Это обязательный
элемент.

Заголовок – содержит любые необязательные атрибуты сообщения,
используемые при обработке сообщения, либо в промежуточной точке,
либо в конечной конечной точке. Это необязательный элемент.

Тело –
содержит
данные
XML,
сообщение. Это обязательный элемент.
13
содержащие
отправляемое

Неисправность – необязательный элемент неисправности, который
предоставляет информацию об ошибках, возникающих при обработке
сообщения.
Следующий блок отображает общую структуру сообщения SOAP
<?xml version = "1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">
<SOAP-ENV:Header>
...
...
</SOAP-ENV:Header>
<SOAP-ENV:Body>
...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP_ENV:Envelope>
14
Рисунок 2 – SOAP API интерфейс
3 СОЗДАНИЕ И НАСТРОЙКА АВТОМАТИЗИРОВАННЫХ ТЕСТОВ
3.1 НАСТРОЙКА АВТОМАТИЗИРОВАННЫХ ТЕСТОВ
предлагаю пример решения, которое позволило достаточно просто
встроить его в регрессионную инфраструктуру, а также имеющее запас для
масштабирования, в случае увеличения покрытия диапазона сценариев и их
сложности.
Для начала создаем Mock-service в SoapUI. Это делается в несколько кликов:
15
Рисунок 3 - Создание Mock-service в SoapUI
Теперь перейдем к созданию заглушек для запросов. Так как в
поставленной задаче вход в сценарий один, у нас есть варианты:
1.
использовать идентификатор сценария и передавать его в
каждом запросе, а в каждой заглушке определять ответ в зависимости от
этого идентификатора;
2.
заранее указать список ответов для каждой заглушки и хранить
их в глобальных переменных перед прогоном теста.
Первый вариант может использоваться в случае, когда необходимо
получать ответ от заглушки одновременно для нескольких запросов. Реализация
16
требует от клиентского приложения способности передавать определенный
идентификатор в каждом запросе к АПИ. В нашем случае это было практически
невозможно, а одновременное тестирования нескольких сценариев не
требовалось,
поэтому
был
выбран
второй
вариант.
Итак, для назначения списка ответов заглушек выполняем следующий
запрос
перед
запуском
теста:
Post: http://mockserver:8080/setscenario
Body:
ScenarioId=0&Authentication=200_OK&AutoSystemHome=400_TokenIsMis
sing…
В Mock-сервисе добавляем обработку запроса «SetScenario». Он имеет всего
два ответа: «200_OK» в случае корректной обработки входящего запроса, и
«400_BadRequest» если запрос был составлен неверно:
Рисунок 4 - Добавление обработки запроса «SetScenario»
В скрипте мы распределяем в глобальные переменные значения ответов для
каждой заглушки:
17
def reqBody = mockRequest.getRequestContent() //считываем тело запроса
def reqBodyParams = [:]
reqBody.tokenize("&").each //собираем входные параметры, переданные в
запросе
{
param->
def keyAndValue = param.split("=")
reqBodyParams[keyAndValue[0]]=keyAndValue[1]
}
if
(reqBodyParams.containsKey('ScenarioId'))
//
ID
сценария
как
обязательный параметр (необходим для упрощения разбора логов); сюда
можно добавить проверки на прочие обязательные для вас параметры
запроса
{
// назначаем глобальные переменные, в которых будем хранить
переданные значения ответов для заглушек, “?:” – означает какое
дефолтное значение будет назначено в случае отсутствия переданного:
context.mockService.setPropertyValue("ScenarioId",
reqBodyParams["ScenarioId"] ?: "0")
context.mockService.setPropertyValue("Authentication",
reqBodyParams["Authentication"] ?: "200_OK")
context.mockService.setPropertyValue("AutoSystemHome",
reqBodyParams["AutoSystemHome"] ?: "200_OK")
// и так далее для каждого метода …
return "200_OK"
}
else
{
return "400_BadRequest"
18
}
Назначенные переменные можно увидеть в окне настроек сервиса:
Рисунок 5 – Назначенные переменные
Таким образом, мы описываем всю логику работы Mock-сервиса именно
в этом методе, а в заглушках для методов АПИ достаточно написать
скрипт, считывающий значение ответа из глобальной переменной:
Рисунок 6 - Считывание значений ответа из глобальной переменной
19
Authentication = context.mockService.getPropertyValue("Authentication")
return "${Authentication}"
Рисунок 7 – Окно AutoSystemHome
AutoSystemHome
=
context.mockService.getPropertyValue("AutoSystemHome")
return "${AutoSystemHome}"
Если необходимо добавить сценарии таймаутов, задержки в ответах, то
добавляем
переменную
delay,
к
примеру:
Post: http://mockserver:8080/setscenario
Body:
ScenarioId=0&Delay=600&Authentication=200_OK
&AutoSystemHome=400_TokenIsMissing…
А в скрипт заглушки добавляем:
20
…
Authentication = context.mockService.getPropertyValue("Authentication")
Delay = context.mockService.getPropertyValue("Delay").toInteger()
sleep(Delay)
return "${Authentication}"
Если необходимо поддержать повторный запрос, то передаем список ответов:
Body:
Authentication:400_MissingParametersClientId;400_MissingParametersClientId;200
_OK
А в скрипте обработки добавляем tokenize и удаление уже отправленного
ответа, в случае если он не последний:
def Authentication = []
Authentication
=
context.mockService.getPropertyValue("Authentication").tokenize("%3B")
if (Authentication.size() > 1)
{
Authentication.remove(0)
Authentication = Authentication.join("%3B")
context.mockService.setPropertyValue("Authentication", Authentication)
}
21
Как итог мы получили простой Mock-сервис, который легко перемещать
между тестовыми стендами и средами, ведь файл проекта – это xml-файл. Сервис
запускается сразу после импортирования, без дополнительных настроек (за
исключением изменения адреса сервера и порта, конечно). В данный момент он
помогает нам тестировать приложение независимо от стабильности АПИ сервера
и
возможных
временных
периодов
его
недоступности.
Что планируем добавить: интегрировать это решение для тестирования
приложений до и во время разработки самого АПИ. Например, когда уже готово
его описание в виде swagger-файла, но сервер в процессе настройки. Циклы
разработки АПИ и клиентских приложений не всегда совпадают. В этот момент
полезно на чем-то тестировать разрабатываемое клиентское приложение, и
Mock-сервис может сильно помочь.
3.2. ПРОВЕДЕНИЕ ТЕСТИРОВАНИЯ
Assertions добавляются в TestSuits поэтому, чтобы добавлять Assertions
нужно создать хотя бы один TestSuit и затем кликнуть на зелёную+ иконку.
Рисунок 8 – SOAP вызовы
Затем Вы можете выбрать одни из многих доступных в SOAP UI типов
assertion.
22
Рисунок 9 – SOAP API интерфейс
Выберите Contains. С помощью этого подтверждения (assertion) можно
искать присутствует ли в ответе заранее определённое ключевое слово. Оно
поддерживает регулярные выражения и применимо ко всем ответам.
Выберите Not Contains. С помощью этого подтверждения (assertion) можно
проверить отсутствие в ответе заранее определённого ключевого слова. Оно
поддерживает регулярные выражения и применимо ко всем ответам.
Выберите SOAP Response. В этим assertion Вы можете проверить что
последний полученные ответ является валидным SOAP ответом. Это можно
применять только к SOAP TestRequest Steps. Не пытайтесь применять этот
assertion к REST запросам.
Двойной клик на Assertion. Никакие дополнительные параметры не нужны
этот шаг можно добавить только один раз.
23
Рисунок 10 – Тестирование SOAP API
24
ЗАКЛЮЧЕНИЕ
В ходе выполнения работы были изучены существующие на сегодня
методы автоматизации тестирования и на основании этих данных, а также
проведенного анализа тестируемого приложения, был выбран подход,
использованный при реализации работы. Были написаны сценарии тестов, и на
их основе создано около 20 пакетов с наборами тестов для автоматизированного
тестирования пользовательского интерфейса, функционального тестирования, а
также тестирования производительности. Разработанные тесты покрывают
основные случаи использования тестируемого приложения и отвечают всем
нуждам заказчика. Также в ходе выполнения работы был проведен
сравнительный анализ возможных решений поставленной задачи, выявлены
сильные
и
слабые
стороны
выбранного
решения,
проведена
оценка
трудоемкости и материальных затрат. В настоящее время весь комплект
разработанных тестов используется в процессе тестирования веб приложения,
часть тестов включена в процесс непрерывной интеграции. Внедрение
автоматизации помогло значительно сократить время, затрачиваемое на процесс
тестирования, улучшило качество выпускаемого продукта, сократило расходы
на осуществление ручного тестирования.
Все сказанное выше позволяет сделать следующий вывод: умение
тестировщиков работать с API может принести пользу практически любому
проекту. Например, это дает возможность в считанные минуты провести смоук
(и убедиться, что ничего важного не сломалось), выполнить одни и те же тесты
с разнообразными наборами входных данных или быстро проделать какие-либо
вспомогательные действия по созданию тестовых данных и ситуаций.
Наконец, еще раз хочу напомнить, что тестирование API становится
особенно востребованным в свете растущей популярности микросервисной
архитектуры. Следовательно, даже в том случае, если на вашем проекте пока не
используется тестирование на уровне API, вам имеет смысл присмотреться к
возможностям, которые оно предоставляет.
25
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. ГОСТ 28806–90. Качество программных средств. Термины и определения.
[Электронный ресурс] URL: http://docs.cntd.ru/document/5200224, свободный. Загл. С экрана. – Яз. рус. Дата обращения: 05.05.2017.
2. The Art of Software Testing / Glenford J. Myers, Revised and Updated by Tom
Badgett, Todd M.Thomas, Corey Sandler. - 2nd ed. - Hoboken, New Jersey.: John
Wiley & Sons, Inc., 2004 - 234 p.
3. Р. Калбертсон, К. Браун, Г. Кобб. Быстрое тестирование. - Вильямс, 2004. –
379 с.
4. Автоматизированное тестирование программного обеспечения - основные
понятия.
//
ПроТестинг.RU.
-
[Электронный
ресурс
URL:
http://www.protesting.ru/automation/, свободный. - Загл. С экрана. – Яз. рус. Дата
обращения: 12.04.2017.
5. L. Copland. A Practitioner’s Guide to Software Test Design. - London: STQE
Publishing, 2004. - 270 с.
6. С. Куликов. Тестирование программного обеспечения. Базовый курс. - Минск:
Четыре четверти, 2015. - 293 с.
7. Пирамида автоматизации и другие геометрические фигуры // AT.Info
[Электронный ресурс URL: http://automated-testing.info/t/piramida-avtomatizacz..,
свободный. - Загл. С экрана. – Яз. рус. Дата обращения: 13.05.2017.
8. Д. Химион. Анализ инструментов автоматизации мобильного тестирования. //
SQA Days-21 [Электронный ресурс] URL: http://sqadays.com/ru/talk/43383,
свободный. - Загл. С экрана. – Яз. рус. Дата обращения: 12.05.2017.
9. Автоматизация тестирования: выбор инструмента. // OpenQuality.ru. Качество
программного
обеспечения.
[Электронный
26
ресурс]
URL:
http://blog.openquality.ru/tool-choice/, свободный. - Загл. С экрана. – Яз. рус. Дата
обращения: 12.05.2017.27 101
10. Использование фреймворков // Учебник по TestComplete. - [Электронный
ресурс] URL: http://tctutorial.ru/frameworks/, свободный. - Загл. С экрана. – Яз.
рус. Дата обращения: 12.04.2017.
11. Linda G. Hayes. Automated Testing Handbook. – Software Testing Inst; 2nd
edition, 2004. – 182 p.
12. Mark Fewster. Software Test Automation: Effective Use of Test Execution Tools /
Mark Fewster, Dorothy Graham. – Addison-Wesley & Son, Ltd, 2000. – 574 p.
13. Test Design Considerations // Selenium HQ. Browser automation. [Электронный
ресурс]
URL:
http://www.seleniumhq.org/docs/06_test_design_conside..,
свободный. - Загл. С экрана. – Яз. рус. Дата обращения: 12.05.2017.
14.
Page
Object
//
martinfowler.com
[Электронный
ресурс]
URL:
https://martinfowler.com/bliki/PageObject.html, свободный. - Загл. С экрана. – Яз.
рус. Дата обращения: 12.05.2017.
15. Machining Cloud. Smart Manufacturing. [Электронный ресурс] URL:
https://www.machiningcloud.com, свободный. - Загл. С экрана. – Яз. рус. Дата
обращения: 12.05.2017.
27