Файл: Тесты для Catalog Controller 15 Реализованные тесты для Service Instance Controller.pdf

Санкт-Петербургский государственный университет
Направление Математическое обеспечение и администрирование информационных систем
Кафедра Информационно-аналитических систем
Шавкунова Дарья Дмитриевна
Разработка библиотеки тестирования облачного сервиса для баз данных
Бакалаврская работа
Научный руководитель:
канд. физ-мат наук Михайлова Е. Г.
Рецензент:
Егоров П. Б.
Санкт-Петербург
2016
brought to you by
CORE
View metadata, citation and similar papers at core.ac.uk
provided by Saint Petersburg State University

SAINT-PETERSBURG STATE UNIVERSITY
Software and Administration of Information Systems
Sub-Department of Analytical Information Systems
Daria Shavkunova
Development of cloud service test library for databases
Graduation Thesis
Scientific supervisor:
PhD Elena Mikhailova
Reviewer:
Pavel Egorov
Saint-Petersburg
2016

Оглавление
Введение
4
1. Постановка задачи
5
1.1. Пути решения . . . . . . . . . . . . . . . . . . . . . . . . .
5
2. Обзор
6
2.1. Платформа Cloud Foundary . . . . . . . . . . . . . . . . .
6 2.2. Что такое тестирование . . . . . . . . . . . . . . . . . . . .
7 2.3. Mock-объекты . . . . . . . . . . . . . . . . . . . . . . . . .
10 2.4. Класс MockMvc . . . . . . . . . . . . . . . . . . . . . . . .
11 2.5. Что используется сейчас . . . . . . . . . . . . . . . . . . .
12
3. Выбор инструментов
13
3.1. Выбор библиотеки тестирования . . . . . . . . . . . . . .
13
4. Реализация
15
4.1. Реализованные тесты для Catalog Controller
15 4.2. Реализованные тесты для Service Instance Controller . . .
15 4.3. Реализованные тесты для Service Binding Controlle . . . .
16 4.4. Реализованные тесты для Broker API Version . . . . . . .
16 4.5. Тестирование . . . . . . . . . . . . . . . . . . . . . . . . . .
16
5. Заключение
17
Список литературы
18
3

Введение
В настоящее время набирают популярность облачные платформы.
Cloud Foundry - одна из таких платформ, помогающая разработчикам различного программного обеспечения (ПО). Но прежде чем облачные платформы использовать, нужно написать ПО для этих платформ.
Cloud Foundry - платформа с открытым кодом, поэтому разработчи- ков много. Хочется, чтобы ПО разных разработчиков вместе работало правильно и без сбоев. Для этого у платформы Cloud Foundry есть об- щие правила, которые обязаны учитывать все разработчики. Для про- верки корректности ПО используют тестирование.
Разные разработчики проверяют свою работу по разному. Некото- рые пытаются писать тесты на все возможные случаи. Другие вруч- ную вводят тестовые данные и сверяют результат. Иногда разработчи- ки смотрят только, чтобы запускалось ПО и считают, что все хорошо.
Но у нас есть общие правила, которые обязаны выполняться. Значит можно сделать библиотеку с тестами на проверку этих правил, чтобы разработчики вносили параметры своего ПО и смотрели все ли работа- ет. Это сократит время и силы на тестирование.
Формированию такой библиотеки и посвящена данная работа.
4

1. Постановка задачи
Конечная цель работы - это создание библиотеки тестов на проверку общих правил
1.1. Пути решения
• Изучить облачную платформу Cloud Foundry
• Изучить методы тестирования
• Выбрать инструменты разработки
• Разработать библиотеку
5

2. Обзор
2.1. Платформа Cloud Foundary
Cloud Foundary - это облачная платформа с открытым исходным ко- дом, которая позволяет разрабатывать приложения без сложности на- стройки инфраструктуры для них. Часть инфраструктуры платформа предоставляет(сеть, управления памятью и т.д.), а другие нужно под- ключать отдельно: базы данных, хранилища памяти.
Чтобы пользоваться внешними ресурсами, нужен специальный сер- вис, который состоит из ПО, предоставляющего этот ресурс, и Service
Broker‘а, приложения обеспечивающего интеграцию сервиса внешнего ресурса в Cloud Foundary[4]. Service Broker должен содержать API[5].
API состоит из 5 методов:
• Список предоставляемых сервисов
• Создание Service Instance
• Удаление Service Instance
• Создание Service Binding
• Удаление Service Binding
Service Instance - это экземпляр ресурса, предоставляемого сервисом, а
Service Binding отражает связь между приложением Cloud Foundary и
Service Instance.
Эти методы и состовляют общие правила, которые обязаны учиты- вать разработчики при создании сервисов.
6

Рис. 1: Схема интеграции сервиса в Cloud Foundry.
Рис. 2: Пример работы.
2.2. Что такое тестирование
Прежде чем тестировать, нужно определить что это такое с научной точки зрения. Определений существует несколько:
• Тестирование программного обеспечения - проверка соответствия между реальным и ожидаемым поведением программы, осуществ- ляемая на конечном наборе тестов,выбранном определенным об- разом. [2]
• Тестирование - это одна из техник контроля качества, включаю- щая в себя активности по планированию работ, проектированию тестов, выполнению тестирования и анализу полученных резуль- татов. [1]
• Тестирование — это проверка соответствия программы требова- ниям, осуществляемая путем наблюдения за ее работой в специ- альных, искусственно созданных ситуациях, выбранных опреде- ленным образом. [11]
Интуитивно понятно, что они похожи между собой.
7

В тестировании выделяют и комбинируют между собой уровни и виды тестирования.
Уровни тестирования:
• Модульное - тестирование отдельных операций, методов, функ- ций.
• Интеграционное - тестирование предназначено для проверки свя- зи между компонентами, а также взаимодействия с различными частями системы.
• Системное - тестирование на уровне пользовательского интерфей- са.
Иногда еще выделяют приемочное тестирование, которое определяет соответствует ли программное обеспечение указанным требованиям.
Виды тестирования:
• Функциональности
• Надежности
• Эффективности
• Практичности
• Сопровождаемости
• Мобильности
8

Так же есть еще одна классификация - разделение тестирования на два больших класса: тестирование методом черного ящика и тестиро- вание методом белого ящика.
• При тестировании методом черного ящика мы не видим, что внут- ри ящика, мы не принимаем во внимание внутреннее устройство программы. При данном тестировании должны быть полностью покрыты все входные данные, комбинации входных данных и по- следовательности комбинаций входных данных.
• При тестировании методом белого ящика мы смотрим, как про- грамма устроена внутри, и эту информацию используем при вы- полнении и, особенно, при проектировании тестов. При данном тестировании должны быть полностью покрыты все строки кода программы, ветви в коде программы и пути в коде программы.
В работе, в основном, будет рассмотрено модульное тестирование функциональности методом черного ящика.
9

2.3. Mock-объекты
В объектно-ориентированном программировании мы оперируем по- нятием класс - это описание объектов определенного типа.[13] Одни классы очень часто используют другие классы в своей работе. Иногда вызов одного метода может повлечь за собой цепочку классов вплоть до базы данных. Если в таких случаях произошла ошибка, то понять где именно - нетривиальная задача. В этом случае используются mock- объекты, предназначенные для симуляции поведения реальных объек- тов во время тестирования. Термин mock-объект может использовать- ся в двух смыслах: обозначает любые тест-дублеры (Test Doubles) или конкретный вид этих дублеров – mock-объекты. В работе термин ис- пользуется во втором смысле. Тест-дублеры делятся на 4 группы:
• Dummy - пустые объекты, которые передаются в вызываемые внут- ренние методы, но не используются. Предназначены лишь для за- полнения параметров методов.
• Fake - объекты, имеющие работающие реализации, но в таком ви- де, который делает их неподходящими для разработки в крупных компаниях.
• Stub-объекты, которые предоставляют заранее заготовленные от- веты на вызовы во время выполнения теста и обычно не отвеча- ющие ни на какие другие вызовы, которые не требуются в тесте.
Также могут запоминать какую-то дополнительную информацию о количестве вызовов, параметрах и возвращать их потом тесту для проверки.
• Mock-объекты, которые заменяют реальный объект в условиях те- ста и позволяют проверять вызовы своих членов как часть систе- мы или unit-теста. Содержат заранее запрограммированные ожи- дания вызовов, которые они ожидают получить. Применяются в основном для т.н. interaction (behavioral) testing.[10]
В данной работе использовались 2 вида тест-дублеров: stub-объекты и mock-объекты.
10

2.4. Класс MockMvc
Данная работа в большей степени ориентирована на проверку кон- троллеров, поэтому основной инструмент, использующийся при тести- ровании, это один из классов Spring Framework‘а MockMvc[12]. Работа с ним состоит из трех этапов:
• Построение mock - объекта
• Отправка HTTP-запроса контроллеру
• Анализ результатов
Чтобы сформировать MockMvc есть два пути:
• MockMvcBuilders.webAppContextSetup(webApplicationContext)
.build() - автоматически вставляет конфигурацию Spring и встав- ляет WebApplicationContext в тест.
• MockMvcBuilders.standaloneSetup(controller).build() - не подгружа- ет конфигурацию Spring[7].
Второй путь подходит для тестирования с помощью mock‘ов, в первом их использовать не стоит, так как Spring автоматически подгружает все классы. А если заменять их на дублеры, то нужно следить, чтобы он не обращался к уже загруженным, что сильно усложняет тесты. Поэтому в данной работе использовался второй подход.
Для отправки запроса требуется метод perform. У этого метода есть только один параметр - RequestBuilder, который и строит HTTP-запрос[3].
Анализ результата осуществляется с помощью метода andExpect,
который предоставляет большие возможность для проверки полученно- го результата: проверка статуса(status.isOk()), корректность возвраща- емого запроса в виде Json(jsonPath(”$.person.name”).equalTo(”Jason”)) и т.д.
11

2.5. Что используется сейчас
На данный момент существует уже несколько Service Broker‘ов для работы с определенной базой данных. Все тесты были написаны для каждого сервиса с нуля. При этом некоторая часть тестов совпадает.
Например, корректно ли создан Service Instance или корректно ли он удален. Поэтому решено было создать библиотеку, в которой часть те- стов будет уже реализована, а для их запуска требуется ввести только параметры спроектированного сервиса.
12

3. Выбор инструментов
Прежде чем создавать библиотеку, нужно выбрать инструменты.
Так как проводилось тестирование проекта, в котором основными сред- ствами были выбраны язык java и фреймворк (каркас) Spring Framework[9],
то и в работе будут использоваться они же.
3.1. Выбор библиотеки тестирования
Самые популярные библиотеки mock-объектов - это Mockito[8] и
EasyMock.
Рис. 3: Пример работы.
Рис. 4: Число вызовов и про- верка аргументов.
13

Рис. 5: Порядок вызова.
Рис. 6: Void метод.
Общих библиотек тестирования тоже достаточно много. Одни из самых популярных: JUnit[6] и TestNG.
Рис. 7: TestNG в стиле JUnit.
Рис. 8: TestNG.
В результате для проведения тестирования была выбрана библио- тека Mockito (библиотека mock-объектов) и JUnit-4 (общая библиотека тестирования).
14

4. Реализация
4.1. Реализованные тесты для Catalog Controller
• catalogIsRetrievedCorrectly - правильно ли извлекается каталог
4.2. Реализованные тесты для Service Instance Controller
• serviceInstanceIsCreatedCorrectly - Service Instance создается кор- ректно
• unknownServiceDefinitionInstanceCreationFails - неизвестен Service
Definition
• duplicateServiceInstanceCreationFails - создание еще одного Service
Instance
• badJsonServiceInstanceCreationFails - неправильная структура Json
• badJsonServiceInstanceCreationFailsMissingFields - в Json пропуще- ны поля, обязательные к заполнению
• serviceInstanceIsDeletedSuccessfully - Service Instance удаляется кор- ректно
• deleteUnknownServiceInstanceFailsWithA410 - удаление неизвест- ного Service Instance
• serviceInstanceIsUpdatedSuccessfully - Service Instance изменился успешно
• updateUnsupportedPlanFailsWithA422 - изменение неподдержива- емого плана
15

4.3. Реализованные тесты для Service Binding Controlle
• serviceInstanceBindingIsCreatedCorrectly - Service Binding создает- ся корректно
• unknownServiceInstanceFailsBinding - неизвестен Service Instance
• duplicateBindingRequestFailsBinding - создание еще одного Service
Binding
• invalidBindingRequestJson - неправильная структура Json
• invalidBindingRequestMissingFields - в Json пропущены поля, обя- зательные к заполнению
• serviceInstanceBindingIsDeletedSuccessfully - Service Binding удаля- ется корректно
• unknownServiceInstanceBindingNotDeletedAndA410IsReturned - уда- ление неизвестного Service Binding
• whenAnUnknownServiceInstanceIsProvidedOnABindingDeleteAnHttp-
422IsReturned - удаление связи с неизвестным Service Instance
4.4. Реализованные тесты для Broker API Version
• noHeaderSent - нет начала запроса
• incorrectHeaderSent - неправильное начало запроса
• correctHeaderSent - корректное начало запроса
• BrokerApiVersionIsCorrectly - версия Broker API корректна
4.5. Тестирование
Тестирование библиотеки проводилось на готовом проекте. При несо- ответствии шаблона и работы сервиса, выдает невыполнение теста, в каком месте произошла ошибка и несовпадающие значения.
16

5. Заключение
• Разработана библиотека тестов
• Проведено тестирование на готовом проекте
• В библиотеке собраны не все возможные тесты, поэтому оставшу- юся часть нужно писать разработчику для конкретного проекта
17

Список литературы
[1] URL: http://www.protesting.ru/testing/.
[2] Abran
Alain.
Guide to the software engineering body of knowledge. ––
IEEE Computer Society, 2004. ––
Google Books :
https://books.google.ru/books?id=IKZQAAAAMAAJ.
[3] Class MockMvc. Документация. ––
URL: http://docs.spring.
io/spring/docs/3.2.0.RC2/javadoc-api/org/springframework/
test/web/servlet/MockMvc.html.
[4] Cloud Foundry. Overview. –– URL: https://docs.cloudfoundry.
org/services/overview.html.
[5] Cloud Foundry. Service Broker API. ––
URL: https://docs.
cloudfoundry.org/services/api.html.
[6] JUnit. Официальный сайт. –– URL: http://junit.org/junit4/.
[7] MockMvc + Mockito = Epic Tests. –– 2014. –– URL: https://
myshittycode.com/2014/01/16/mockmvc-mockito-epic-tests/.
[8] Mockito. Официальный сайт. –– URL: http://site.mockito.org/.
[9] Spring Framework. Официальный сайт. –– URL: https://spring.
io/projects.
[10] А. Кондуфоров. Введение в mock-объекты. Классификация. ––
2008. ––
URL: http://merle-amber.blogspot.ru/2008/09/mock.
html.
[11] Лупан
Алексей.
Основные положения тестирования. ––
2010. ––
URL:
https://testitquickly.com/2010/03/09/
testing-basics-by-barancev/.
[12] Тестирование контроллеров с помощью MockMvc. –– 2013. –– URL:
http://www.pvsm.ru/java/29182.
18