📄Работа №80189
Тема: Разработка системы интеграционного тестирования в многозвенных приложениях
Характеристики работы
Тип работы
Дипломные работы, ВКР
Предмет
Автоматика и управление
Объем:
50 листов
Год:
2018
Просмотров:
104
4315
руб.
🛒 Купить работу
Не подходит эта работа?
Закажите новую по вашим требованиям
Узнать цену на написание
Закажите новую по вашим требованиям
Представленный материал является образцом учебного исследования, примером структуры и содержания учебного исследования по заявленной теме. Размещён исключительно в информационных и ознакомительных целях.
Workspay.ru оказывает информационные услуги по сбору, обработке и структурированию материалов в соответствии с требованиями заказчика.
Размещение материала не означает публикацию произведения впервые и не предполагает передачу исключительных авторских прав третьим лицам.
Материал не предназначен для дословной сдачи в образовательные организации и требует самостоятельной переработки с соблюдением законодательства Российской Федерации об авторском праве и принципов академической добросовестности.
Авторские права на исходные материалы принадлежат их законным правообладателям. В случае возникновения вопросов, связанных с размещённым материалом, просим направить обращение через форму обратной связи.
Настоящий учебно-методический информационный материал размещён в ознакомительных и исследовательских целях и представляет собой пример учебного исследования. Не является готовым научным трудом и требует самостоятельной переработки.
📋 Содержание
ВВЕДЕНИЕ 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. Конструкторская часть 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, а также создание системы уведомлений о результатах автоматизированного тестирования.
Часто исправление проблемы в одной части программного кода непреднамеренно вызывает ошибку программного обеспечения в другой области. Может случиться так, что, когда какой-либо функционал будет перепроектирован, некоторые из ошибок, которые были сделаны в первоначальной реализации, могут возникнуть и в новой версии.
В современной архитектуре, представленной в виде клиента и сервера, таким функционалом, который подвергается частому перепроектированию, является серверная сторона приложения.
В таком приложении взаимодействие между компонентами происходит с помощью общедоступных интерфейсов. Тестирование этого взаимодействия называется интеграционным тестированием. В этом случае нет необходимости рассматривать внутреннюю структуру компонентов, важен только результат взаимодействия клиента и сервера. Таким образом, тестирование выполняется методом «черного ящика», когда описываются входные параметры запросов и ожидаемый результат [1].
Для упрощения интеграционного тестирования следует разработать систему, в которой тесты представлены в виде декларативного описания входных и выходных данных. Такой формат представления, кроме тестирования, позволит описать спецификацию интерфейса компонента.
В большинстве случаев разработки программного обеспечения считается хорошей практикой написание тестовых сценариев на уже готовую функциональную часть, которые регулярно запускаются после последующих изменений в программе. Хотя это может быть сделано вручную, но чаще это делается с использованием средств автоматического тестирования. Кроме того, возможна также настройка системы повторного запуска всех тестов через определенные промежутки времени. Общей стратегией автоматического тестирования является запуск системы интеграционного тестирования после успешной компиляции, каждую ночь или раз в неделю. Такая стратегия может быть автоматизирована с помощью внешнего инструмента, например, TeamCity.
Целью данной работы является разработка системы интеграционного тестирования в многозвенных приложениях, автоматизация данного процесса с помощью сервера непрерывной интеграции TeamCity, а также создание системы уведомлений о результатах автоматизированного тестирования.
✅ Заключение
В результате проделанной работы был разработана система интеграционного тестирования в многозвенных приложениях. Произведена автоматизация процесса тестирования с помощью сервера непрерывной интеграции TeamCity.Создана система уведомлений о результатах автоматизированного тестирования.
В рамках проекта решены следующие задачи:
• Разработан функционал отправки HTTPзапросов на сервер и тестирования корректности структур данных, приходящих в ответе;
• Создана поддержка тестирования WebSocketсоединений;
• Реализована процедура наследования шаблонных типов;
• Реализована поддержка построения многошаговых тестовых сценариев.
В качестве дальнейшего развития планируется усовершенствовать систему тестирования уведомлений - реализовать возможность тестирования при участии нескольких одновременно открытых WebSocketсоединений с выборочной подпиской на уведомления разных сущностей системы. Также предполагается добавить возможность создавать параметризованные тесты. Параметризация предполагает, что один и тот же тест можно использовать для однотипных запросов, но с отправкой разных структур данных на сервер.
В рамках проекта решены следующие задачи:
• Разработан функционал отправки HTTPзапросов на сервер и тестирования корректности структур данных, приходящих в ответе;
• Создана поддержка тестирования WebSocketсоединений;
• Реализована процедура наследования шаблонных типов;
• Реализована поддержка построения многошаговых тестовых сценариев.
В качестве дальнейшего развития планируется усовершенствовать систему тестирования уведомлений - реализовать возможность тестирования при участии нескольких одновременно открытых WebSocketсоединений с выборочной подпиской на уведомления разных сущностей системы. Также предполагается добавить возможность создавать параметризованные тесты. Параметризация предполагает, что один и тот же тест можно использовать для однотипных запросов, но с отправкой разных структур данных на сервер.
ИЛИ
Поиск аналога
📕 Список литературы
🛒 Оформить заказ
⚡ Работу высылаем в течении 5 минут после оплаты.