ВВЕДЕНИЕ 9
1. Конструкторская часть 11
1.1. Организация информационного обмена между слоями приложения 11
1.2. Задачи тестирования 12
1.2.1. Реакция сервера на входящие запросы 13
1.2.2. Контроль типов данных 13
1.3. Поддержка многошаговых тестовых сценариев 15
1.4. Постановка задачи 15
1.5. Регрессионное тестирование 16
1.6. Использование инструмента в TDD 17
1.7. Программная реализация преобразования формата тестов к
исполняемому виду 20
1.7.1. Описание разработанного формата данных 21
1.7.2. Модуль преобразования формата тестов 23
1.7.2.1. Реализация процесса преобразования YAML в JavaScript 24
1.7.2.2. Реализация процесса контроля типов данных 28
1.7.2.3. Реализация сценариев тестирования подписок на события с
использованием WebSocket 32
1.7.2.4. Процесс аутентификации перед запуском тестов 33
1.7.2.5. Реализация многошаговых тестовых сценариев 34
1.7.2.6. Реализация процесса наследования шаблонных типов 34
1.7.2.7. Результат работы модуля преобразования формата тестов 36
1.7.3. Модуль для работы с HTTP запросами и WebSocket 38
1.7.3.1. Класс HTTPBackend 38
1.7.З.2. Класс SocketBackend 38
1.8. Автоматизация процесса тестирования 40
1.9. Интеграция в инфраструктуру разработки 42
2. Технологическая часть 43
2.1. Описание протоколов передачи данных 43
2.1.1. HTTP 43
2.1.2. WebSocket 44
2.2. Выбор языка программирования 45
2.3. Выбор формата описания файлов тестов 45
2.3.1. XML 45
2.3.2. JSON 46
2.3.3. YAML 46
2.4. Выбор фреймворка тестирования 47
2.4.1. Mocha 48
2.4.2. Jasmine 49
2.4.3. Jest 49
2.5. Используемые библиотеки 50
ЗАКЛЮЧЕНИЕ 51
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 52
ПРИЛОЖЕНИЕ А 54
На сегодняшний день разработка программного обеспечения непосредственно связана с обновлением или изменением прежде реализованного функционала. В таком случае возникновение новых сбоев или повторное появление старых неисправностей довольно распространено.
Часто исправление проблемы в одной части программного кода непреднамеренно вызывает ошибку программного обеспечения в другой области. Может случиться так, что, когда какой-либо функционал будет перепроектирован, некоторые из ошибок, которые были сделаны в первоначальной реализации, могут возникнуть и в новой версии.
В современной архитектуре, представленной в виде клиента и сервера, таким функционалом, который подвергается частому перепроектированию, является серверная сторона приложения.
В таком приложении взаимодействие между компонентами происходит с помощью общедоступных интерфейсов. Тестирование этого взаимодействия называется интеграционным тестированием. В этом случае нет необходимости рассматривать внутреннюю структуру компонентов, важен только результат взаимодействия клиента и сервера. Таким образом, тестирование выполняется методом «черного ящика», когда описываются входные параметры запросов и ожидаемый результат [1].
Для упрощения интеграционного тестирования следует разработать систему, в которой тесты представлены в виде декларативного описания входных и выходных данных. Такой формат представления, кроме тестирования, позволит описать спецификацию интерфейса компонента.
В большинстве случаев разработки программного обеспечения считается хорошей практикой написание тестовых сценариев на уже готовую функциональную часть, которые регулярно запускаются после последующих изменений в программе. Хотя это может быть сделано вручную, но чаще это делается с использованием средств автоматического тестирования. Кроме того, возможна также настройка системы повторного запуска всех тестов через определенные промежутки времени. Общей стратегией автоматического тестирования является запуск системы интеграционного тестирования после успешной компиляции, каждую ночь или раз в неделю. Такая стратегия может быть автоматизирована с помощью внешнего инструмента, например, TeamCity.
Целью данной работы является разработка системы интеграционного тестирования в многозвенных приложениях, автоматизация данного процесса с помощью сервера непрерывной интеграции TeamCity, а также создание системы уведомлений о результатах автоматизированного тестирования.
В результате проделанной работы был разработана система интеграционного тестирования в многозвенных приложениях. Произведена автоматизация процесса тестирования с помощью сервера непрерывной интеграции TeamCity.Создана система уведомлений о результатах автоматизированного тестирования.
В рамках проекта решены следующие задачи:
• Разработан функционал отправки HTTPзапросов на сервер и тестирования корректности структур данных, приходящих в ответе;
• Создана поддержка тестирования WebSocketсоединений;
• Реализована процедура наследования шаблонных типов;
• Реализована поддержка построения многошаговых тестовых сценариев.
В качестве дальнейшего развития планируется усовершенствовать систему тестирования уведомлений - реализовать возможность тестирования при участии нескольких одновременно открытых WebSocketсоединений с выборочной подпиской на уведомления разных сущностей системы. Также предполагается добавить возможность создавать параметризованные тесты. Параметризация предполагает, что один и тот же тест можно использовать для однотипных запросов, но с отправкой разных структур данных на сервер.
