АСОУ Отченашенко итог

Оглавление
Введение .................................................................................................................. 3
Область применения системы: ....................................................................... 3
Техническое задание на проектирование и разработку АСОиУ ................. 4
1. Назначение и цели создания АСОиУ....................................................... 4
1.1. Назначение АСОиУ .............................................................................. 4
1.2. Цели создания АСОиУ ......................................................................... 4
2. Характеристика объекта автоматизации. .............................................. 5
3. Требования к АСОиУ ................................................................................. 9
3.1. Требования к АСОиУ в целом ............................................................ 9
3.2. Требования к функциям выполняемым АСОиУ ......................... 11
3.3. Требования к обработке и хранению данных................................ 17
3.4. Требования к пользовательскому интерфейсу ................................ 20
4. Требования к видам обеспечения ........................................................... 24
5
4.1
Требования к информационному обеспечению ............................ 24
4.2
Требования к программному обеспечению.................................... 24
4.3
Требования к техническому обеспечению ..................................... 24
4.4
Требования к лингвистическому обеспечению............................. 25
4.5
Требования к эргономике и технической эстетике ...................... 25
Требования к приемке-сдаче проекта ................................................... 26
5.1
Требования к наполнению информацией ...................................... 26
5.2
Требования к персоналу .................................................................... 26
5.3
Порядок предоставления дистрибутива ......................................... 26
5.4
Порядок переноса сайта на технические средства заказчика .... 26
Протокол испытаний АСОиУ .......................................................................... 27
Стратегия тестирования................................................................................. 28
Протокол испытаний АСОиУ ....................................................................... 29
Unit-testing ...................................................................................................... 30
Integration-testing........................................................................................... 39
Acceptance-testing .......................................................................................... 41
Ручное тестирование ....................................................................................... 46
Введение
Полное наименование системы:
«Автоматизированная система туристического агентства»
Область применения системы:
Разработанная система должна использоваться в туристическом агентстве
для автоматизации и ускорения покупки интересного туристического тура
для клиента.
3
Техническое задание на проектирование и разработку
АСОиУ
1. Назначение и цели создания АСОиУ
1.1. Назначение АСОиУ
Данная программа предназначена для электронного управления и учета
туристической фирмой.
Для этого должны быть автоматизированы следующие процессы:
 Внесение информации о купленных путевках;
 Формирование списка свободных путевок
1.2.
Цели создания АСОиУ
Целями создания программы являются:
 Упрощение и конечно ускорение процесса покупки путевки
 Возможность сокращение штата и более разумное использование
текущих человеческих ресурсов
 Привлечение новых клиентов за счет предоставления качественного
сервиса текущим.
4
2. Характеристика объекта автоматизации.
Компания, которую представляет заказчик оказывает услуги, связанные с
туризмом. Для обеспечения выхода на новый уровень бизнеса и привлечения
новых КЛ существующий подход затрудняет данный процесс с точки зрения
того что КЛ: предлагаются в первую очередь туры наиболее выгодные
туристическому агенству нежили клиенту, процесс обработки запроса
Клиента с целью проверки свободных путевок занимает слишком много
времени так как данная информация находится в бумажном виде (в данном
случае место имеет быть еще и человеческий фактор, то есть ошибки),
политику компанию по отношению к своим Клиентам трудно назвать клиент
ориентированной так как информация о предыдущих поездках клиента
просто не ведется.
Для осуществления перехода о котором написано выше, при обращении
Клиента или потенциального клиента в туристическое агенство,
администратор агенства должен: предоставить информацию о всех
свободных турах в интересующую дату клиента, проверить информацию о
том является ли он действующим клиентом туристического агенства, в
случае неудовлетворения запроса клиента в указанные им даты для отдыха
проверить информацию о ближайших датах в течении 3 дней ( в большую
или меньшую сторону)
После выбора даты клиентом, администратор должен занести запись о
выборе клиента конкретной путевки, страны вылета и общей стоимости
Убедиться в трудоемкости необходимых процессов можно взглянув на
диаграммы: убедиться (рис. 1 – 5).
5
Рисунок 1. IDEF0 - процесс формирование записи клиента на покупку тура
Рисунок 2. IDEF1 – полный перечень необходимых действий для осуществления услуги « продажа тура»
6
Рисунок 3. Деятельность менеджера по продаже туров
Стоит отметить, ведение информации вне автоматизированной системы
замедляет поиск информации, что в свою очередь значительно замедляет
процесс сбора и анализа статистики
В связи с отсутствием клиентоориентированности компания начинает терять
клиентскую базу, а следовательно нести убытки.
Следовательно аспектом автоматизации бизнес процесса будет являться
следующее::
 Возможность просмотреть базу данных
 Предоставление клиенту списка возможных для курорта стран
 Сохранение возможности бронирования тура
 Предоставление возможности выбора дат для осуществления курорта
 Реализация текстового поля при первом обращении Клиента в
тур.агенства для более полной информации о нем
 Сохранение всех данных в БД
 Возможность построения отчетности и анализа данных
7
Следовательно, решение по автоматизации хранения БД и ведение
информации о клиентах в определенных формах будет предстаылтяь собой
собой ресурс позволяющий сотрудникам тур.агенства оперативно
отслеживать информацию о возможных турах в удобные даты для клиента, и
обобщенную информацию о турах, предоставляющую возможность
клиентам самостоятельно бронировать туры, и способствующий накоплению
информации для дальнейшего анализа.
Проблему долго поиска и анализа данных решит отказ от фиксироания
информации на бумажных носителях, ориентировочное время ускорения
работы – более 60% , что в свою очередь так же будет способствовать более
детальному сбору статистики . Наприме: можно отследить наиболее
популярные для курорта страны и приоритизировать это направление
Внедряя описанный выше подход, лояльность клиента значительно выростет
так как его вопрос будет решен в максимально короткое время, а у
внутреннего персонала высвободится достаточно времени, для того чтобы в
большей степени сконцентрироваться на клиенте.
8
3. Требования к АСОиУ
3.1.
Требования к АСОиУ в целом
Разрабатываемое приложение должно иметь два уровня иерархии:
 Уровень централизованной базы данных
 Уровень пользователей приложения
Приложение должно в первую очередь производить сбор желаний клиента
относительно разных параметров тура, делать анализ имеющийся базы туров
чтобы определить наиболее подходящий и выводить его описание. Для Этого
автоматизирования система должна подразумевать:





Регистрацию в системе
Выход из системы
Просмотр списка допустимых туров
Доступ к деталям тура ( дата ,страна, отель, стоимость)
Информацию о предыдущих турах
Менеджеру должны быть доступны следующие роли

Регистрация в системе. Менеджер перед началом работы должен
авторизоваться в системе

Выход из системы. После окончания работы с клиентом менджер
должен выйти из системы с целью безопасности

Просмотр списка допустимых туров. Менеджер должен
проссматривать список доступных туров на основании ключевых
запросов (Дата вылета, сумма, страна)

Доступ к деталям тура. Менеджер должен иметь детальную
информацию по выбранному туру (отель, питания)

Информация о предыдущих турах. Менеджер перед началом работы
с клиентом введя его данные должен получить историю о предыдущих
взаимодействия клиента с туристической фирмой.
Менеджеру туристического агенства перед использованием
автоматизированной системы необходимо пройти аутентификацию, если
9
конкретный менеджер делает это впервые - предоставляется возможность
регистрации.
Рисунок 4. Требование к АСОиУ
10
3.2.
Требования к функциям выполняемым АСОиУ
Данные требования составлены с учетом реализации управления доступа на
основе ролей
Рисунок 6. Варианты использования для аутентифицированного пользователя
Специалист должен иметь следующие варианты использования:
1. Выход из системы
2. Просмотр своей истории посещений. Специалист должен иметь
возможность выбрать промежуток времени и просмотреть список своих
посещений в этот временной промежуток.
11
Рисунок 7. Просмотри своей истории посещений
3. Информация о тура. Специалист должен иметь возможность
просматривать созданные им или турагенством туры. В данном разделе
так же можно посмотреть все проданные туры агенством. При просмотре
туров, должна быть возможность добавлять новый тур запрашивать
детальную информацию о туре, редактировать и удалять отмененные
туры.
Рисунок 8. Информация о туре
3.1. Добавление нового тура. Менеджер должен иметь возможность
добавлять новый тур указав время дату и страну. В данном случае
необходимо так же реализовать возможность комментариев.
3.2. Детальный просмотр тура. При детальном просмотре тура
отображаться вся имеющаяся в системе информация об этом туре
12
(время и дата начала, конца, страна, отель, стоимость, данные
клиента). Дополнительно необходимо реализовать возможность
удаления тура
3.3. Редактирование выбранного тура. При редактировании выбранного
тура м должен иметь возможность изменять дату и время начала и
конца посещения, а так же редактировать свой комментарий.
3.4. Удаление выбранного тура. Менеджер должен иметь возможность
удалить выбранный тур, если Клиент от него отказывается.
Забронированный тур должен попадать в список вновь доступных для
покупки
4. Доступ к аналитике. Менеджер должен получать:
4.1. Страны пользующиеся наибольшей популярность для туризма.
Представлено должно быть в виде графике, где на шкале Х отражена
страна, а на шкале Y количество проданных туров.
4.2. Список постоянных клиентов. Должно отображать клиентов
регулярно планирующих свой отдых с выбранным тур. Агенстовом.
Рисунок 9. Доступ к аналитике
13
Основной бизнес-процес покупки клиентом путевки в виде UML
диаграмм последовательности
Возможность покупки клиентом интересующего его тура появляется только в
том случае если у туристичего агенства есть свобондные туры в
интересующую клиента страну и в подходящие даты. Пример приема можно
рассмотреть в виде диграммы последовательности:
Рисунок 7. Диаграмма последовательности создания тура менеджером
1. Менеджер с ролью «Администратор» переходит в интерфейс который
называется «создание нового тура»
2. Web-приложение в свою очередь отправляет запрос на отображение
страницы «Создание нового тура» к серверу.
3. Сервер в свою очередь возвращает страницу «Создание нового тура»
4. Web-приложение отображает страницу пользователю
5. Менеджер заполняет форму следующими данными(все поля должны
быть обязательно заполнены):
 Дата и время начала тура (в формате d.m.y H:i)
 Дата и время конца тура (в формате d.m.y H:i)
14
 Страна
 Комментарий (не более 350 символов)
6. Менеджер нажимает на кнопку «Забронировать тур»
7. Web-приложение в свою очередь отправляет на сервер данные с
заполненной формы
8. Сервер в свою очередь проверяет корректность данных:
 В случае если данные не корректны – возвращает список ошибок
 В случае если данные корректны – возвращает список доступных
туров
9. В случае если сервер вернул список ошибок ( ошибка в выбранной дате
или отсутствие туров в указанные даты) – менеджеру предоставляется
возможность исправить введенные данные и отправить запрос на
вывод туров повторно.
15
Если у туристического агентства в наличии свободные туры в запрошенных
клиентом датах клиент может забронировать любой наиболее подходящий
для себя. Рассмотрим процедуру в виде диаграммы последовательности:
Рисунок 8. Диаграмма последовательности для выбора свободного тура.
1. Аутентифицированный менеджер предварительно обсудив с клиентом
удобность предложенных туров и выбрав конкретный нажимает на
кнопку «Записаться» на соответствующем туре.
2. Web-приложение посылает запрос на отображение страницы «Тур
забранирован» к серверу.
3. Сервер в свою очередь возвращает страницу «Тур забронирован»
4. Менеджер предоставляется возможность ввести комментарий к
пожеланиям и ожиданиям клиента, длина записи: не более 350
символов.
5. Менеджер нажимает на кнопку «Подтвердить данные»
6. Web-приложение отправляет на сервер данные с заполненной формы
7. Сервер проверяет корректность данных:
 В случае если данные не корректны – возвращает список ошибок
 В случае если данные корректны – возвращает сообщение о том,
клиентом успешно забронирован выбранный тур
8. В случае если сервер вернул список ошибок – менеджеру
предоставляется возможность исправить введенные данные и отправить
форму повторно.
16
3.3.
Требования к обработке и хранению данных
Требования к обработке и хранению данных отражены в виде диаграммы
базы данных
Рисунок 9.. Логическая схема базы данных
База данных представлена в виде сущностей, их атрибутов и связей между
ними. Каждая сущность представляет множество подобных объектов,
называемых экземплярами. Каждый экземпляр индивидуален и должен
отличаться от всех остальных. Атрибут выражает определенное свойство
объекта. С точки зрения физической модели базы данных сущности
соответствует таблица (например, «Клиент», «Сотрудник»), экземпляру
сущности – строка в таблице, а атрибуту – колонка таблицы. В результате
проектирования было выделено шесть сущностей.
Связь на диаграмме отображает логическую зависимость одной сущности от
другой. В IDEF1X различают зависимые и независимые сущности. Тип
17
сущности определяется ее связью с другими сущностями.
Идентифицирующая связь устанавливается между независимой
(родительский конец связи) и зависимой (дочерний конец связи)
сущностями. Экземпляр зависимой сущности определяется только через
отношение к родительской сущности. Зависимая сущность изображается на
диаграмме прямоугольником со скругленными углами.
При установлении не идентифицирующей связи дочерняя сущность остается
независимой, а атрибуты первичного ключа родительской сущности
мигрируют в состав неключевых компонентов родительской сущности. Не
идентифицирующая связь служит для связывания независимых сущностей.
Для того, чтобы однозначно идентифицировать экземпляр сущности
используется первичный ключ (атрибут или группа атрибутов). Атрибуты
первичного ключа на диаграмме не требуют специального обозначения - это
те атрибуты, которые находятся в списке атрибутов выше горизонтальной
линии.
При установлении идентифицирующей связи атрибуты первичного ключа
родительской сущности автоматически переносятся в состав первичного
ключа дочерней сущности. Эта операция дополнения атрибутов дочерней
сущности при создании связи называется миграцией атрибутов. В дочерней
сущности новые атрибуты помечаются как внешний ключ
18
3.4.
Требования к пользовательскому интерфейсу
В подавляющем большинстве при разработке стоит использовать светлые
тона и интуитивно понятный дизайн.
Основной функционал должен быть доступен менеджеру при первом
переходе на главный сайт, дополнительный функционал может
располагаться внутри основных разделов.
Первая страница не должна быть переполнена текстовой частью, которая
будет отвлекать внимание.
При создании дизайна стоит учитывать, что в нем не должны присутствовать:
мелькающие баннеры, много сливающегося текста, картинки большого
размера.
Дизайн сайта должен быть адаптивен условиям отображения.
Главная страница приложения должна содержать верхнюю навигационную
панель, боковое навигационное меню, а также контентную область для того,
чтобы посетитель с первой страницы мог воспользоваться функционалом
системы.
Структура страниц должна делиться на следующие разделы:
 Верхняя навигационная панель позволяющая зарегистрироваться или
пройти аутентификацию, в случае если пользователь еще не вошел в
систему. А так же выйти из ситемы, в случае если пользователь
аутентифицировался.
 Боковая навигационная панель - содержит основные пункты меню
навигации по сайту.
 Контентная область – основной контент выбранного раздела сайта
Боковое меню должно содержать следующие страницы с учетом
иерархической вложенности.
19
Для менеджера должен быть доступен следующий функционал:

График посещений

История посещений

Статистика
o
Наиболее популярное время
o
Самые активные посетители
В качестве примера был взят сайт туристического агенства « Пегас
Туристик», описанные требования представлены на скриншотах ниже:
Пример дизайна интерфейсов системы:
Рисунок 10. Выбор тура
20
Рисунок 41. Выбор страны
Рисунок 12.5 Учет заявки на выбранный тур
21
Рисунок 13.6 Общее отображение информации о всех заполненных заявках
22
4. Требования к видам обеспечения
4.1 Требования к информационному обеспечению
Все данные сайта должны храниться в структурированном виде под
управлением реляционной СУБД. Исключения составляют файлы данных,
предназначенные для просмотра и скачивания (изображения, видео,
документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД
размещаются ссылки на них.
4.2 Требования к программному обеспечению
4.2.1 Требования к программному обеспечению серверной части
Для функционирования сайта необходимо следующее программное
обеспечение:

Веб-сервер – Apache версии не ниже 2.0;

СУБД – MySQL версии не ниже 5.5;

Поддержка PHP версии не ниже 7.0

Круглосуточный режим функционирования
4.2.2 Требования к клиентскому программному обеспечению
Приложение должно быть доступно для полнофункционального просмотра с
помощью следующих браузеров:

Opera;

Mozilla Firefox;

Google Chrome;
Информация должна быть доступна при отключении в браузере поддержки
flash и JavaScript.
4.3 Требования к техническому обеспечению
Для функционирования сайта необходимо следующее техническое
обеспечение со следующими минимальными характеристиками:
23

Компьютер с процессором Pentium IV 2 ГГц (рекомендуется от 3 ГГц);

Оперативная память 2 Гб (рекомендуется от 3 Гб);
Точные технически характеристики сервера будут уточнены после
завершения системы и обширного тестирования всех модулей портала.
4.4 Требования к лингвистическому обеспечению
Приложение должно представлять контент на русском языкe.
4.5 Требования к эргономике и технической эстетике
Приложение должно быть адаптивно устройству отображения, обеспечивая
просмотр контента без горизонтальной прокрутки. Элементы управления
должны быть сгруппированы однотипно – горизонтально либо вертикально
на всех страницах.
На каждой странице должны отображаться логотип компании и контактная
информация.
24
5 Требования к приемке-сдаче проекта
5.1 Требования к наполнению информацией
Исполнитель обеспечивает первичное наполнение страниц контентом,
представленным заказчиком. После сдачи системы в эксплуатацию
информационное наполнение разделов, осуществляется Заказчиком или
Исполнителем на основании договора на поддержку сайта.
5.2 Требования к персоналу
Пользовательский интерфейс сайта должен быть интуитивно понятным, не
требующим от персонала специальных технических навыков, знания
технологий или программных продуктов, за исключением общих навыков
работы с персональным компьютером и стандартным веб-браузером.
5.3 Порядок предоставления дистрибутива
По окончании разработки Исполнитель должен предоставить Заказчику
дистрибутив системы в составе:

архив с исходными кодами всех программных модулей и разделов
сайта;

дамп проектной базы данных с актуальной информацией.
Дистрибутив предоставляется в виде файлового архива, факт его передачи
подтверждается подписанием Актом сдачи-приемки работ.
5.4 Порядок переноса сайта на технические средства заказчика
После завершения сдачи-приемки сайта, в рамках гарантийной поддержки
Исполнителем производится однократный перенос разработанного
программного обеспечения на аппаратные средства Заказчика. Соответствие
программно-аппаратной платформы требованиям настоящего ТЗ
обеспечивает Заказчик. Перед осуществлением переноса Заказчик
обеспечивает Исполнителю удаленный shell-доступ к веб-серверу и доступ к
базе данных сайта
25
Протокол испытаний АСОиУ
Стратегия тестирования.
Для тестирования приложения были выбраны следующие виды
тестирования:
 Модульное тестирование (Unit-test)
 Интеграционное тестирование (Integration Testing)
 Приемочное тестирование (Accepptance testing).
Все виды тестирования выполняются в автоматическом режиме, что
значительно экономит время, и облегчает поддержку и модификацию
системы в дальнейшем.
В рамках модульного тестирования – должна быть протестирована основная
бизнес-логика моделей, на наборах тестовых данных. Модульные тесты
должны предусматривать все возможные варианты входных данных, и
выполнятся достаточно быстро. Особое внимание стоит уделить соблюдению
правил валидации.
В рамках интеграционного тестирования должна быть протестированна
основная бизнес логика моделей с учетом связи с базой данных. Основная
цель данного этапа тестирования – убедится в том, что разработанная
система корректно работает совместно с базой данных
Цель приёмочного тестирования – рассмотреть основные варианты
использования системы, и убедиться в корректности их работы для
конечного пользователя.
26
Протокол испытаний АСОиУ
Объект испытаний
Объектом испытаний является «Автоматизированная информационная
система управления туристической фирмой»
Цель испытаний
Проверка надежности функционирования программы
Требования к программе
1. Функционирование программы не должно приводить к сбою
2. Организация диалога должна предусматривать защиту от ввода
некорректных данных
3. Все варианты использования должны корректно выполнятся
4. Должен корректно соблюдаться контроль доступа основаный на
системе ролей
Средства и порядок испытаний
Для разработки тестов используется тестовый фреймворк codeception.
Codeception является достаточно мощной средой тестирования содержащий в
себе все необходимые виды тестирования.
Порядок проведения испытаний:
Unit-testing
 Проверка правил валидации модели «Бронирование тура»
 Проверка методов модели «Посещения» затрагивающих основную
бизнес-логику приложения
 Проверка правил валидации модели «Менеджер»
27
Integration testing
 Проверка интеграции моделей с базой данных
Acceptance testing
 Проверка варианта использования «Регистрация»
 Проверка варианта использования «Аутентификация»
 Проверка варианта использования «Выход из системы»
 Проверка варианта использования «Бронирование тура»
 Проверка варианта использования «Детальный обзор выбранного тура»
Ручное функциональное тестирование
1. Тест кейс №1: Создание бронирования с корректными данными
2. Тест кейс №2: Создание бронирования с некорректными данными
3. Тест кейс №3: Изменения параметров тура
4. Тест кейс №4: Проверка работоспособности поля комментарии
28
Unit-testing
Для упрощения Unit-тестирования моделей, и избежания дублирования кода
был разработан модуль – помощник. Ниже приведен исходный код модуля.
class YiiModelHelper extends \Codeception\Module
{
/**
* Проверяет, заполнены ли в Yii2 модели все AttributeLabels
*
* @param string $className Имя класса
* @param array $attributes
* @throws \ReflectionException
*/
public function seeAllAttributeLabels(string $className, array $attributes = [])
{
/** @var ActiveRecord $class */
$class = (new \ReflectionClass($className))->newInstance();
$attributeLabels = $class->attributeLabels();
if (empty($attributes)) {
$columns = $class->attributes();
} else {
29
$columns = $attributes;
}
foreach ($columns as $columnName) {
expect('Attribute label exists for ' . $columnName, $attributeLabels)
->hasKey($columnName);
}
}
/**
* Проверяет правило валидации 'required' у всех перечисленных
аттрибутов класса
*
* @param string $className Имя класса
* @param array $requiredFields Массив полей для проверки
* @throws \Exception
*/
public function seeAllRequiredRules(string $className, array $requiredFields)
{
$stub = Stub::make($className, ['attributes' => $requiredFields]);
$stub->validate($requiredFields);
foreach ($requiredFields as $field) {
30
expect($field . ' has error', $stub->getErrors())->hasKey($field);
}
}
/**
* Проверяет правило валидации 'integer' у всех перечисленных аттрибутов
класса
*
* @param string $className Имя класса
* @param array $integerFields Массив полей для проверки
* @throws \yii\base\Exception
*/
public function seeFieldIsInteger(string $className, array $integerFields)
{
$security = new Security();
$stub = Stub::make($className, ['attributes' => $integerFields]);
foreach ($integerFields as $field) {
$stub->$field = $security->generateRandomString();
}
$stub->validate($integerFields);
foreach ($integerFields as $field) {
31
expect($field . ' has error', $stub->getErrors())->hasKey($field);
}
}
public function seeFieldIsString(string $className, array $stringFields)
{
$stub = Stub::make($className, ['attributes' => $stringFields]);
foreach ($stringFields as $field) {
$stub->$field = '1';
expect($field . ' is valid', $stub->validate($field))->true();
$stub->$field = 1;
expect($field . ' is invalid', $stub->validate($field))->false();
}
}
/**
* Проверяет успешное сохранение модели в базу.
* Реализовано для искллючения неожиданных поведений при
использовании
* метода beforeSave
*
* @param string $className Имя класса
32
* @param array $attributes Массив полей для проверки
* @throws \ReflectionException
*/
public function saveIntoDatabase(string $className, array $attributes)
{
//@TODO Поискать вариант проверки beforeSave через stub
/** @var ActiveRecord $class */
$class = (new \ReflectionClass($className))->newInstance($attributes);
expect('Model is saved', $class->save())->true();
}
/**
* Проверяет правило валидации 'max' у всех перечисленных 'string'
аттрибутов класса
*
* @param string $className Имя класса
* @param array $stringFields Массив полей для проверки
* @param int $max Необходимое значение атрибута max
* @throws \yii\base\Exception
*/
public function seeMaxStringLength(string $className, array $stringFields, int
$max)
{
33
$security = new Security();
$stub = Stub::make($className, ['attributes' => $stringFields]);
foreach ($stringFields as $field) {
$stub->$field = $security->generateRandomString($max+1);
expect($field . ' has error', $stub->validate($field))->false();
$stub->$field = $security->generateRandomString($max);
expect($field . ' has not error', $stub->validate($field))->true();
}
}
public function seeSafeAttributes(string $className, array $safeAttributes)
{
$stub = Stub::make($className, ['attributes' => $safeAttributes]);
foreach ($safeAttributes as $attribute) {
expect('Attribute ' . $attribute . ' is safe', $stub->isAttributeSafe($attribute))
->true();
}
}
}
34
С использованием этого модуля, написание Unit-тестов становится гораздо
проще, и размер тестов, как правило не превышает 5-10 строк кода.
Ниже представлено тестирование правил валидации для модели
«Посещение» с использованием модуля – помощника.
public function testRequiredFields()
{
$requiredFields = [
'BEGIN_VISIT', 'END_VISIT'
];
$this->tester->canSeeAllRequiredRules(Appointment::class,
$requiredFields);
}
public function testIntegerRules()
{
$integerFields = [
'FID_SPECIALIST', 'FID_USER', 'FID_STATUS'
];
$this->tester->seeFieldIsInteger(Appointment::class, $integerFields);
}
public function testMaxStringLength()
{
$stringFields = [
'SPECIALIST_COMMENT', 'USER_COMMENT'
];
$this->tester->canSeeMaxStringLength(Appointment::class, $stringFields,
255);
}
35
Бизнес логика приложения напрямую связана с базой – данных, по этому
методы модели «Посещения» будут протестированы интеграционными
тестами.
Тестирование правил валидации для модели «Пользователь»
public function testRequiredFields()
{
$requiredFields = [
'FIRST_NAME', 'LAST_NAME'
];
$this->tester->canSeeAllRequiredRules(Profile::class, $requiredFields);
}
public function testIntegerRules()
{
$integerFields = [
'FID_USER'
];
$this->tester->seeFieldIsInteger(Profile::class, $integerFields);
}
public function testMaxStringLength()
{
$stringFields = [
36
'USER_AVATAR'
];
$this->tester->canSeeMaxStringLength(Profile::class, $stringFields, 255);
$stringFields = [
'USER_ROLE'
];
$this->tester->canSeeMaxStringLength(Profile::class, $stringFields, 64);
$stringFields = [
'FIRST_NAME', 'LAST_NAME', 'PATRONYMIC'
];
$this->tester->canSeeMaxStringLength(Profile::class, $stringFields, 100);
}
37
Integration-testing
Тестирование методов моделей связанных с базой данных
public function testAttributeLabels()
{
$this->tester->seeAllAttributeLabels(Profile::class);
}
public function testAttributeLabels()
{
$this->tester->seeAllAttributeLabels(Appointment::class);
}
public function testDurationValidatorIsTrue()
{
$appointment = new Appointment([
'BEGIN_VISIT' => '2018-12-09 12:00',
'END_VISIT' => '2018-12-09 18:00',
]);
$appointment->durationValidator('END_VISIT',['compareAttribute' =>
'BEGIN_VISIT']);
expect('Appointment model has not errors', $appointment>hasErrors('END_VISIT'))
->false();
38
}
public function testDurationValidatorIsFalse()
{
$appointment = new Appointment([
'BEGIN_VISIT' => '2018-12-09 12:00',
'END_VISIT' => '2018-12-09 23:00',
]);
$appointment->durationValidator('END_VISIT',['compareAttribute' =>
'BEGIN_VISIT']);
expect('Appointment model has error', $appointment>hasErrors('END_VISIT'))
->true();
}
39
Acceptance-testing
 Проверка варианта использования «Регистрация»
class RegistrationCest
{
public function _before(AcceptanceTester $I)
{
$I->amOnPage(Url::toRoute('/site/sign-up'));
}
// tests
public function ensureThatPageWorksCorrectly(AcceptanceTester $I)
{
$I->see('Регистрация', 'h1');
}
public function registrationFormCanBeSubmitted(AcceptanceTester $I)
{
$I->amGoingTo('submit registration form with correct data');
$I->fillField('#user-user_login', 'tester');
$I->fillField('#user-password', 'test');
$I->fillField('#user-user_email', 'email@tester.email');
$I->fillField('#profile-first_name', 'Тестовый');
$I->fillField('#profile-last_name', 'Пользователь');
$I->click('//*[@id="signUp-form"]/div[7]/div/button');
}
}
40
 Проверка варианта использования «Аутентификация»
class AuthCest
{
public function _before(AcceptanceTester $I)
{
$I->amOnPage(Url::toRoute('/site/login'));
}
// tests
public function ensureThatPageWorksCorreclty(AcceptanceTester $I)
{
$I->see('Вход в систему', 'h1');
}
public function authFormCanBeSubmitted(AcceptanceTester $I)
{
$I->amGoingTo('submit auth form with correct data');
$I->fillField('#loginform-username', 'user1');
$I->fillField('#loginform-password', 'user');
$I->click('//*[@id="login-form"]/div[4]/div/button');
$I->dontSee('Error!');
}
}
41
 Проверка варианта использования «Выход из системы»
class LogOutCest
{
public function _before(AcceptanceTester $I)
{
$I->amOnPage(Url::toRoute('/site/login'));
$I->fillField('#loginform-username', 'user1');
$I->fillField('#loginform-password', 'user');
$I->click('//*[@id="login-form"]/div[4]/div/button');
$I->dontSee('Error!');
}
// tests
public function ensureThatLogOutWorks(AcceptanceTester $I)
{
$I->click('//*[@id="w1"]/li/form/button');
$I->dontSee('Error!');
}
}
42
 Проверка варианта использования «Просмотр списка текущих
посещений»
class AppointmentListCest
{
public function _before(AcceptanceTester $I)
{
$I->amOnPage(Url::toRoute('/site/login'));
$I->fillField('#loginform-username', 'user1');
$I->fillField('#loginform-password', 'user');
$I->click('//*[@id="login-form"]/div[4]/div/button');
$I->dontSee('Error!');
}
// tests
public function ensureThatAppointmentListPageWorks(AcceptanceTester
$I)
{
$I->click('/html/body/div[1]/div/div/div[1]/div/div[2]/ul/li[1]/a');
$I->dontSee('Error!');
}
}
43
 Проверка варианта использования «Детальный просмотр выбранного
посещения»
class AppointmentDetailViewCest
{
public function _before(AcceptanceTester $I)
{
$I->amOnPage(Url::toRoute('/site/login'));
$I->fillField('#loginform-username', 'user1');
$I->fillField('#loginform-password', 'user');
$I->click('//*[@id="login-form"]/div[4]/div/button');
sleep(2);
}
// tests
public function ensureThatAppointmentListPageWorks(AcceptanceTester
$I)
{
sleep(2);
$I->amOnPage(Url::toRoute(['/appointment/view', 'id' => 15]));
sleep(2);
$I->see('Просмотр приёма: #15', 'h1');
$I->dontSee('Error!');
}
}
44
Ручное тестирование
Тест кейс №1: Создание бронирования с корректными данными
Шаги:
1. Аутентифицироваться в приложении как пользователь с ролью
«Менеджер» (учетные данные “specialist1”, “specialist”)
2. Пройти в пункт создание «нового тура»
3. Необходимо заполнить форму используя следующие данные
 Дата и время начала тура – 22.02.2020 10:00
 Дата и время конца посещения - 29.02.2020 12:00
 Выбрать необходимо страну
 Выбрать отель
4. Нажать на кнопку «Забронировать тур»
Ожидаемый результат:
Отображается сообщение: «Тур успешно забронирован»
Тест кейс №2: Создание бронирования с некорректными данными
Шаги:
1. Аутентифицироваться в приложении как пользователь с ролью
«Менеджер»
2. Пройти в пункт создание «нового тура»
3. Необходимо заполнить форму используя следующие данные
 Дата и время начала тура – 22.02.2020 10:00
 Дата и время конца посещения - 21.02.2020 12:00
 Выбрать необходимо страну
 Выбрать отель
4. Нажать на кнопку «Забронировать тур»
Ожидаемый результат:
Отображается список ошибки поля дата и время конца посещения.
45
Тест кейс №3: Изменения параметров тура
Шаги:
1. Аутентифицироваться в приложении как пользователь с ролью
«Менеджер»
2. Перейти в интерфейс «Просмотр забронированных туров»
3. Выбрать конкретный тур:
4. Изменить дату начала тура и нажать сохранить изменения
Ожидаемый результат:
Отображается сообщение: «Посещение успешно добавлено»
Тест кейс №4: Проверка работоспособности поля комментарии
Шаги:
1. Аутентифицироваться в приложении как пользователь с ролью
«Менеджер»
2. Перейти в интерфейс «Просмотр забронированных туров»
3. Выбрать конкретный тур:
4. Заполнить поле «Комментарием в 300 символов»
Ожидаемый результат:
Поле комментарии заполнены
46