Вы находитесь на странице: 1из 102

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ

ФЕДЕРАЦИИ
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Уральский государственный экономический университет»
(УрГЭУ)

Направление подготовки 09.03.03 Прикладная информатика


Направленность (профиль) Прикладная информатика в экономике

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА


(БАКАЛАВРИАТ)

Тем Проектирование и разработка системы по информатизации


а тестирования программного обеспечения

Обучающийся Вартик Иван Анатольевич


Группа ЗЭИ-17
Руководитель Сурнина Надежда Матвеевна
профессор, доктор экономических наук
Консультант Чиркина Наталья Георгиевна
(при наличии) Старший преподаватель

Кафедра Информационных технологий и статистики


Институт Непрерывного и дистанционного образования

Нормоконтролер Панова Марина Валерьевна


Старший преподаватель

Дата защиты 19.06.2020


Оценка

Екатеринбург
2020 г.
СОДЕРЖАНИЕ
Введение 4
1 Аналитическая часть 6
1.1 Анализ предметной области 6
1.1.1 Экономический анализ деятельности организации 6
1.1.2 Организационная структура и система управления 9
1.1.3 Состояние и стратегия развития информационных технологий 12
1.2 Анализ организации прикладных и информационных процессов 14
1.2.1 Описание существующей организации прикладных процессов 14
1.2.2 Анализ недостатков организации прикладных процессов 26
1.2.3 Предложения по информатизации прикладных процессов 27
1.3 Постановка задачи информатизации 29
1.3.1 Цель и задачи проекта информатизации 29
1.3.2 Построение и обоснование модели новой организации прикладных
процессов 30
1.3.3 Спецификация функциональных требований к информационной
системе 32
1.3.4 Спецификация нефункциональных требований к информационной
системе 32
1.4 Календарно-ресурсное планирование проекта 33
1.4.1 План график проекта 33
2 Проектная часть 35
2.1 Информационное обеспечение 35
2.1.1 Инфологическая модель и схема данных 35
2.1.2 Входная информация 36
2.1.3 Классификаторы и нормативно-справочная информация 43
2.1.4 Выходная информация 45
2.2 Программное обеспечение 47
2.2.1 Структура программного обеспечения 47
2.2.2 Интерфейс пользователя 51
2.2.3 Тестирование комплекса задач 52
2.3 Техническое обеспечение 53
2.4 Обеспечение информационной безопасности 56
2.5 Оценка эффективности проекта 56
Заключение 64
Список использованных источников 65
Приложение А 70
Приложение Б 77
Приложение В 79
Приложение Г 80
Приложение Д 81
Приложение Е 82
Приложение Ж 83
Приложение И 84
Приложение К 85
Приложение Л 86
Приложение М 87
Приложение Н 88
Приложение О 89
Приложение П 90
Приложение Р 91
Приложение С 92
ВВЕДЕНИЕ
ООО «Такском» – крупная российская компания, занимающаяся
разработкой программного обеспечения и его реализацией на внутреннем
российском рынке.
У сотрудников компании многолетний опыт проектирования, разработки
и поддержки информационных систем, который позволяет в сжатые сроки
максимально быстро реализовывать крупные ИТ-проекты и большое
количество доработок к ним.
При разработке программного продукта как правило все члены команды
используют одну информационную систему. Подобная система называется
системой управления проектами и содержит в себе всю исчерпывающую
информацию о разрабатываемом продукте. Она содержит специальные доски
для создания, декомпозирования, отслеживания исполнения и завершения задач
для сотрудников, занимающихся разработкой. Также система управления
проектами содержит базу знаний, похожую на электронную энциклопедию
внутри компании. Однако имеются и недостатки у подобных систем.
Современные системы управления проектами предоставляют удобные
инструменты для мониторинга и контроля ручного тестирования, но
совершенно не предоставляют инструментов для отслеживания состояния
процесса автоматизированного тестирования. В связи с этим возникла
потребность в разработке информационной системы, которая удовлетворит
подобные потребности.
Тема выпускной квалификационной работы является актуальной, т.к.
автоматизированное тестирование программного обеспечения с каждым годом
вытесняет ручное всё больше и больше. Использование комплекса задач для
систематизирования и хранения информации о разработанных и ещё
разрабатываемых автоматизированных тестах позволит сократить время на
выяснение того, какой функционал покрыт автоматизированными тестами, а
какой ещё нет и это сэкономит время всех участников разработки. Выходная

4
информация из комплекса задач представлена в удобном для её дальнейшего
анализа виде.
Целью работы является сначала проектирование, а затем разработка
комплекса задач для обеспечения участников разработки актуальной
информацией о степени покрытия автоматизированными тестами
разрабатываемого программного обеспечения.
Достигаемая цель реализует следующие задачи:
 Разработка комплекса задач для хранения и обработки информации;
 Разработка руководства пользователя;
 Расчёт экономической эффективность внедрения данного комплекса
задач.

5
1 АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

1.1.1 ИСТОРИЯ И ЭКОНОМИЧЕСКИЙ АНАЛИЗ ДЕЯТЕЛЬНОСТИ

ОРГАНИЗАЦИИ

Компания ООО «Такском» основана в 2000-ом году в Москве. История


компании тесно переплетается с развитием электронной отчётности в России.
Два крупнейших офиса компании располагаются в Москве на Цветном
бульваре и на станции метро Нагатинская. Также компания представлена на
территории России сетью филиалов.
2000 год. Компания «Такском» реализует первый в России пилотный
проект по сдаче отчетности в электронном виде в налоговых инспекциях города
Москвы. Эта технология положила начало возникновению электронной
отчетности в России, а компания «Такском» стала создателем первой в России
массовой системы сдачи отчетности через Интернет – «Такском-Спринтер».
2002-2005 годы. «Такском» запускает безбумажную технологию в
промышленную эксплуатацию и становится первым специализированным
оператором связи. Расширяется география присутствия компании на
российском рынке при помощи развития региональной агентской сети в
России.
2007-2008 годы. К системе сдачи электронной отчетности подключаются
все Управления ПФР по г. Москве и Московской области. Начинается
эксплуатация системы представления статистической отчетности в
электронном виде в Мосгорстат.
2009 год. Компания «Такском» реализует пилотный проект по
организации системы электронного оборота счетов фактур для
налогоплательщиков. Проект проводится Минфином России и ФНС России по
г. Москве по поручению Правительства РФ от 11.11.2008 № КА-П13-6752.

6
2010-2011 годы. Работа по развитию системы электронного оборота
счетов-фактур. Создание системы представления отчетности в электронном
виде в ФСС. Система «Такском-Файлер» по обмену электронными счетами-
фактурами перешла в стадию массовой эксплуатации. Разработан «Такском
Визор» – программный комплекс для кредитных организаций.
2012 год. Компания «Такском» организовала Рабочую группу по
вопросам электронного документооборота при Экспертном совете Торгово
промышленной палаты России. Начинается совместная работа бизнеса по
совершенствованию налогового законодательства и правоприменительной
практики по ЭДО. Компания «Такском» получила статус Оператора
электронного документооборота и вошла в Сеть доверенных операторов ЭДО
ФНС России.
2013-2015 годы. «Такском» участвует в проекте по организации
международного электронного документооборота для транснациональных
компаний в разных странах. Запущено новое направление отчетности в
Росприроднадзор. Продукт компании «Такском-Файлер» стал лауреатом
премии «Время инноваций». Компания «Такском» становится победителем
российского конкурса партнерских ИТ-решений компании Microsoft. Решение
«Моя электронная подпись» было признано лучшим в номинации «Cloud
Application Developer», подтвердив тем самым высочайшую экспертизу в
области программных решений для бизнеса. Разработаны новые программные
продукты и сервисы: «Такском Конвертер», «Сверься!», «Картотека
документов».
2016 год. Компании «Такском» одной из первых присвоен статус
Оператора фискальных данных. Разработаны сервисы для передачи данных с
контрольно-кассовой техники в ФНС России. Подписаны соглашения с
ведущими операторами ЭДО о межоператорском взаимодействии (роуминге).
2017-2018 годы. Компания «Такском» участвует в проекте внедрения
системы электронного документооборота по маркировке и прослеживанию
табачной продукции. «Такском» запускает EDI для ритейлеров и поставщиков.
7
Запущено новое программное решение на базе 1С для автоматизации работы в
условиях маркировки и прослеживания товаров – «Станция сканирования».
«Такском» присоединяется к проекту по электронной ветеринарной
сертификации. Выпущена линейка IT-продуктов – «Такском-Ветис» для
интеграции с системой «Меркурий», входящей в состав Федеральной
государственной информационной системы в области ветеринарии
(Россельхознадзор).
2019 год. Компания «Такском» продолжает развивать новые продукты и
сервисы для Клиентов. Разработан новый сервис «Такском - управление
сертификатами» (ТУС), который позволяет Клиентам «Такском» упростить
процедуру выпуска сертификатов и сократить сроки их получения за счет
создания собственного центра управления сертификатами. Разработан и
тестируется в режиме пилотного проекта прототип создания электронного
документа посредством плагина, установленного в редактор Microsoft Word.
Список программных продуктов компании:
 Отчётность через интернет;
 Электронная подпись;
 Оператор фискальных данных: отправка электронных чеков;
 Онлайн-кассы и обслуживание;
 Маркировка остатков;
 Электронный документооборот;
 Автоматизированный обмен электронными заказами;
 Проверка контрагентов;
 Решения 1С;
 Ветеринарные сертификаты;
 ЕГАИС: продажа алкоголя.
Компания «Такском» сотрудничает с крупнейшими государственными
структурами: Управление делами Президента РФ, Аппарат Государственной
думы РФ, Аппарат Совета Федерации РФ, МИД России, Минэкономразвития
8
России, ФНС России, Верховный суд РФ, Счетная палата РФ, ЦБ РФ (Банк
России), Генеральная прокуратура РФ и компаниями: Связной, HeadHunter,
Johnson&Johnson, TEZ Tour, Сбербанк России, Почта России, Мерседес-Бенц
Банк Рус, HP, МГТС, Гайский горно-обогатительный комбинат и др.

1.1.2 ОРГАНИЗАЦИОННАЯ СТРУКТУРА И СИСТЕМА УПРАВЛЕНИЯ

Компания ООО «Такском» имеет классическую вертикальную


древовидную структуру управления. Во главе организации стоит генеральный
директор. Ему подчиняются руководители, которые отвечают за свои
департаменты и управления:
 Коммерческий департамент;
 Департамент маркетинга и рекламы;
 Финансовый департамент;
 Департамент развития бизнеса;
 Департамент технического развития и разработки;
 Департамент по работе с персоналом;
 Департамент по работе с ключевыми клиентами;
 Департамент контроля и безопасности;
 Юридическое управление;
 Управление регионального развития
Департаменты состоят из управлений, управления из отделов, отделы из
групп.

9
Рисунок 11 – Организационная структура ООО «Такском»
Коммерческий департамент занимается созданием и обновлением
структуры продажи новых и действующих продуктов компании. Также
коммерческий департамент отвечает за развитие сети агентов, которые за
процент вознаграждений занимаются продажей продуктов компании.
Департамент маркетинга и рекламы прорабатывает маркетинговую
стратегию позиционирования программных продуктов компании. Также
департамент через рекламные агентства размещает рекламу продуктов
компании в метро и на баннерах, придумывает промо-акции для привлечения
новых клиентов и удержания старых.
Финансовый департамент занимается расчётом выплат зарплат
сотрудникам, планированием на среднесрочную и долгосрочную перспективу
финансовой стратегии предприятия, балансировкой дебета и кредита
задолженности.
Департамент развития бизнеса занимается стратегией развития компании,
анализирует конкурентов на региональных рынках и просчитывает какой
процент рынка сможет занять ООО «Такском» в том или ином регионе в случае
открытия нового офиса.
Департамент технического развития и разработки занимается разработкой
программного обеспечения и обслуживанием действующей инфраструктуры
информационных технологий предприятия. Именно этот департамент является
в компании ключевым звеном по зарабатыванию денег, т.к. здесь с нуля
создаются программные продукты и многочисленные доработки к ним.
Помимо разработки департамент занимается и системным администрированием
всех тестовых и боевых серверов, а также компьютеров организации. На
рисунке 2 изображена организационная структура отдела перспективных
разработок департамента технического развития ООО «Такском».

1
Все рисунки составлены автором
10
Рисунок 2 – Организационная структура отдела перспективных
разработок департамента технического развития и разработки ООО «Такском»
11
Департамент по работе с персоналом занимается поиском на рынке труда
новых сотрудников на вакантные места, оформлением документов при
трудоустройстве и увольнении. Также департамент занимается планированием
и оформлением документально отпусков сотрудников, отвечает за развитие
корпоративной культуры, организовывает профессиональные праздники,
поздравляет сотрудников-именинников с днём рождения.
Департамент по работе с ключевыми клиентами поддерживает
постоянную коммуникацию с самыми крупными клиентами компании. От
лояльности крупных клиентов во многом зависит финансовое благополучие
ООО «Такском», т.к. потеря даже одного такого клиента приведёт к
существенным финансовым потерям.
Департамент контроля и безопасности отвечает за охрану офисов
компании, за контроль доступа в помещения компании, за информирование
сотрудников о неразглашении коммерческой тайны, а также за предотвращение
несанкционированного доступа к информационным ресурсам компании.
Юридическое управление занимается соблюдением законности
оформления документов, заключением договоров и регистрацией торговых
марок компании, а также отстаиванием интересов компании в судах.
Управление регионального развития занимается контролем за
функционированием бизнес-процессов в офисах компании, расположенных в
регионах.

1.1.3 СОСТОЯНИЕ И СТРАТЕГИЯ РАЗВИТИЯ ИНФОРМАЦИОННЫХ

ТЕХНОЛОГИЙ

В компании имеется несколько серверов, предназначенных под разные


нужды. На всех серверах ВЕБ-приложения развёрнуты на Windows Server в
Internet Information Services (IIS) от Microsoft. Некоторые из серверов
развёрнуты в виде виртуальных машин.

12
Сервер тестовой среды предназначен для разработки. Именно на этот
сервер в первую очередь поступают свежие доработки разработчиков и в
первую очередь эти новейшие доработки тестируются именно на этом сервере.
Сервер предпромышленной среды предназначен для полного
приёмочного тестирования доработок. На этот сервер разработанный
функционал попадает только после успешного прохождения тестирования на
сервере тестовой среды. Также именно на этом сервере раз в неделю
производится демонстрация доработок заказчику.
Сервер промышленной среды предназначен для функционирования
боевых версий продуктов компании, то есть для предоставления клиентам
доступа к купленным у ООО «Такском» продуктам.
В настоящий момент основной платформой разработки программных
продуктов компании ООО «Такском» является «.Net Framework» от
«Microsoft», а основным языком программирования является «C#». Не смотря
на то, что корпорация Microsoft постепенно прекращает поддержку «.Net
Framework» и всё больше развивает кроссплатформенную технологию «.Net
Core», в ООО «Такском» большинство продуктов, разработанные на «.Net
Framework», ещё будут долгое время поддерживаться и их миграция на «.Net
Core» не планируется, т.к это нецелесообразно из-за трудоёмкости процесса.
Компания ООО «Такском» разрабатывает проекты, основанные на ВЕБ-
технологиях таких как: Single Page Application (SPA), Model View Controller
(MVC), Blazer, React и др. Мобильные приложения разрабатываются под две
платформы: «Android» на языке программирования «Kotlin» и «iOS» на языке
программирования «Swift».
В подавляющем большинстве проектов компании используются
реляционные базы данных «Microsoft SQL Server», а в качестве системы
управления базами данных используется «Microsoft SQL Server Management
Studio».

13
1.2 АНАЛИЗ ОРГАНИЗАЦИИ ПРИКЛАДНЫХ И ИНФОРМАЦИОННЫХ

ПРОЦЕССОВ

1.2.1 ОПИСАНИЕ СУЩЕСТВУЮЩЕЙ ОРГАНИЗАЦИИ ПРИКЛАДНЫХ

ПРОЦЕССОВ

ООО «Такском» использует несколько информационных систем, но по


большей части задействована система управления проектами «Atlassian JIRA
Confluence», которая содержит ссылки на все остальные системы. Эту систему
принято называть просто «JIRA».
Процесс разработки во всех компаниях-разработчиках программного
обеспечения всегда начинается с идеи, и, ООО «Такском» - не исключение.
ООО «Такском» – продуктовая компания-разработчик программного
обеспечения, поэтому идеи разработки рождаются внутри компании.
Соответственно заказчик внутренний, а не внешний. Чаще всего к группам
разработки задачи поступают от руководства.
ООО «Такском» использует гибкую Agile-методологию разработки. Цикл
разработки называется спринтом и длится одну неделю. Формирование плана
разработки на неделю начинается в пятницу, когда системные аналитики и
руководители групп разработки собираются на совещание со своими
предложениями о том, что планируется разрабатывать в следующую неделю.
По понедельникам производится демонстрация заказчикам всего
разработанного за неделю функционала.
Первым звеном разработки задачи на разработку или доработку является
системный аналитик. Системный аналитик регистрирует новую задачу в
информационной системе «JIRA», после чего приступает к её анализу и
декомпозированию (делению на части) на подзадачи всё в той же
информационной системе. Созданная системным аналитиком задача поступает
на панель задач «Kanban» в столбец «To Do», изображённый на рисунке 3.

14
Рисунок 3 – Пользовательский интерфейс ИС «JIRA»

15
Системный аналитик строит схемы и макеты, а затем отдаёт их на
отрисовку ВЕБ-дизайнеру. ВЕБ-дизайнер рисует формы, кнопки и иконки и
после того, как закончит, демонстрирует их системному аналитику. ВЕБ-
дизайнер получает обратную связь от системного аналитика и исправляет
замечания. Системный аналитик прикрепляет уже готовые формы, кнопки и
иконки к задаче в «JIRA».
После системного аналитика в работу над задачей вступает разработчик.
Первое, что он делает, это передвигает из столбца «To Do» в столбец «In
Progress» ту задачу, над которой планирует работать. Разработчик приступает к
кодированию. Если ему непонятны какие-то моменты, описанные в задаче, он
выясняет подробности у системного аналитика и просит его дополнить задачу.
После того, как разработчик завершает работу над задачей, то есть
заканчивает кодирование, внесённые им изменения в файлах разрабатываемой
программы он сохраняет через систему контроля версий «SVN». «SVN»
интегрируется в проводник Windows. Для сохранения изменений в коде
разрабатываемой программы в «SVN» сначала требуется добавить
разработанные файлы командой «Add», которая добавит файлы и отметит
значком синего плюса, означающий, что файл подготовлен к отправке на
сервер (рисунок 4).

Рисунок 4 – Команда «Add» в «SVN»


16
Таким образом разработчик может легко контролировать то, какие файлы
он подготовил к отправке в репозиторий и не отправит ненужные файлы. Затем
выполняется команда «Commit» (рисунок 5), которая отправит файлы на
репозиторий разработки в еженедельную ветку «branch».

Рисунок 5 – Команда «Commit» в «SVN»


Перед отправкой разработанных новых файлов на сервер, в окне
«Message» разработчик указывает номер задачи из «JIRA» и комментарий
(рисунок 6).

17
Рисунок 6 – Команда «Commit» в «SVN» с полем комментария
После отправки разработанных файлов на сервер-репозиторий,
разработчик в «JIRA» на «Kanban» панели перемещает задачу в столбец
«Waiting Review». Другой разработчик двигает задачу из столбца «Waiting
Review» в столбец «Reviewing» и начинает проводить ревью, то есть искать
ошибки или несоответствия в коде своего коллеги-разработчика.
Если найдены какие-либо несоответствия в коде, то разработчик-ревьюер
пишет соответствующий комментарий к задаче с перечислением
несоответствий и после того, как закончит, сообщает об этом разработчику,
который кодировал. Разработчик, который кодировал, возвращает задачу в
столбец «In Progress» и исправляет недочёты, после чего перемещает задачу в
«Waiting Review» и так до тех пор, пока разработчик полностью не пройдёт
ревью кода.
После успешного и окончательного прохождения разработчиком ревью
кода и получения положительной обратной связи от разработчика-ревьюера в
виде комментария к задаче, в котором сказано, что код проверен, задачу
перемещают в столбец «Waiting».
Ручной тестировщик перемещает задачу из столбца «Waiting» в столбец
«Testing» и приступает к её тестированию на тестовом контуре, выясняя
подробности разработанного кода и нюансы по задаче как у разработчика, так и
у системного аналитика. После выяснения всех нюансов по задаче и окончания
тестирования ручной тестировщик передвигает её из столбца «Testing» в
столбец «For merge».
Как правило в конце рабочей недели разработчик, который занимался
кодированием задачи, через «SVN» командой «Merge» осуществляет слияние
своих файлов из еженедельной рабочей ветки разработки с веткой релиза
(рисунок 7). Такую операцию разработчик производит поочерёдно со всеми
задачами, разработкой которых он занимался на текущей неделе.

18
Рисунок 7 – Команда «Merge» в «SVN»
Довольно часто при слиянии возникает множество конфликтов, которые
невозможно предусмотреть при написании кода, поэтому разработчику
приходится разрешать каждый конфликт вручную и только после того, как он
разрешит все конфликты и произведёт полное слияние в релизную ветку
«trunk», он передвигает задачу из «For merge» в столбец «To deploy».
Задачу в столбце «To deploy» ещё раз проверяет ручной тестировщик, но
в этот раз уже на предпромышленном контуре и после того, как убедится в том,
что она выполнена полностью в соответствии с описанием, передвигает эту
задачу в столбец «Done».
После тестирования всех запланированных на неделю новых задач на
предпромышленном контуре, ручной тестировщик приступает к
регрессионному тестированию, то есть проверяет на работоспособность весь
тот функционал, который был разработан ещё до внесения изменений в код.
После того как проверен и новый и старый функционал, ручной тестировщик в
«JIRA» создаёт задачу на обновление с перечислением технических изменений
конфигураций (если таковые имели место) и назначает её на DevOps-
специалиста. Также ручной тестировщик вносит новый функционал в чек-лист
регрессионного тестирования, представляющий из себя таблицу, или
формирует смарт-карту в «XMind» (рисунок 8).
19
Рисунок 8 – Смарт-карта для ручного тестирования в «XMind»

20
DevOps-специалист в соответствии с описанием задачи по развёртыванию
приступает к внедрению нового функционала на промышленном контуре.
Ручное регрессионное тестирование с каждым новым релизом
программных продуктов отнимает у ручного тестировщика всё больше и
больше времени, т.к. количество функционала увеличивается. Поэтому
автоматизацией регрессионного ручного тестирования занимается
тестировщик-автоматизатор.
Тестировщик-автоматизатор занимается покрытием
автоматизированными тестами уже разработанного и внедрённого в
промышленную эксплуатацию функционала. Тестировщик-автоматизатор
начинает свою работу с того, что выясняет у ручного тестировщика какой
именно функционал следует покрыть автоматизированными тестами, то есть
автоматизировать. После любых изменений в коде программы (не имеет
значения каких именно изменений, т.к. это может быть как внесение нового
функционала, так и исправление дефектов в старом), высока вероятность того,
что перестанет работать то, что ранее функционировало исправно. Поэтому в
первую очередь необходимо автоматизировать самый бизнес-критичный
устоявшийся функционал. Это позволит заблаговременно обнаружить дефект,
тем самым исключив его попадание на промышленный контур, что позволит
компании не понести издержки, к которым может привести поломка.
Выяснив у ручного тестировщика то, какой именно функционал
необходимо покрыть автоматизированными тестами и то, как вручную его
тестировать, тестировщик-автоматизатор приступает к подбору тестовых
данных для данного функционала. Тестовые данные представляют из себя как
входные данные для конкретного функционала, так и выходные. Входные
данные обычно представляют из себя то, что отправляется на сервер клиентом.
Чаще всего роль клиента выполняет браузер компьютера, но иногда при
тестировании приходится использовать перехватчик трафика «Fiddler», для
анализа как запросов, так и ответов. «Fiddler» представлен на рисунке 9.

21
Рисунок 9 – перехватчик трафика «Fiddler»
Содержимое ответа от ВЕБ-сервера будет являться выходными данными.
Тестировщику-автоматизатору требуется подобрать не только входные и
выходные данные для автоматизированного теста, но и выяснить в какую
именно таблицу базы данных приложения они будут записаны.
После того как тестировщик-автоматизатор подобрал требующиеся для
автоматизированного теста тестовые данные, он приступает к кодированию
интеграционного автоматизированного теста.
Тестировщик-автоматизатор разрабатывает автоматизированные
интеграционные тесты, придерживаясь концепции методологии Behavior-driven
development (BDD).
BDD методология является расширением другой методологии - Test-
Driven Development (TDD) в том смысле, что перед тем, как написать какой-
либо тест, необходимо сначала описать желаемый результат от добавляемой
функциональности на предметно-ориентированном языке. После того как это

22
будет проделано, конструкции этого языка переводятся тестировщиком-
автоматизатором в описание теста.
BDD фокусируется на следующих вопросах:
 С чего начинается процесс;
 Что нужно тестировать, а что нет;
 Сколько проверок должно быть совершено за один раз;
 Что можно назвать проверкой;
 Как понять, почему тест не прошёл.
Тесты для некоторой единицы программного обеспечения должны быть
описаны с точки зрения желаемого поведения программируемого устройства.
Под желаемым поведением понимается такое, которое имеет ценность для
бизнеса. Описание желаемого поведения даётся с помощью спецификации
поведения. Спецификация поведения строится в полуформальной форме.
В настоящее время в практике BDD устоялась следующая структура:
а) Заголовок (англ. Title). В сослагательной форме должно быть дано
описание бизнес-цели.
б) Описание (англ. Narrative). В краткой и свободной форме должны быть
раскрыты следующие вопросы:
1) Кто является заинтересованным лицом данной истории;
2) Что входит в состав данной истории;
3) Какую ценность данная история предоставляет для бизнеса.
в) Сценарии (англ. Scenarios). В одной спецификации может быть один и
более сценариев, каждый из которых раскрывает одну из ситуаций
поведения пользователя, тем самым конкретизируя описание
спецификации. Каждый сценарий обычно строится по одной и той же
схеме:
1) Начальные условия (одно или несколько);
2) Событие, которое инициирует начало этого сценария;
3) Ожидаемый результат или результаты.

23
BDD не предоставляет каких-либо формальных правил, но настаивает на
том, чтобы использовался ограниченный стандартный набор фраз, который
включал бы все элементы спецификации поведения. В 2007 году Дэном Нортом
был предложен шаблон для спецификации, который получил популярность и
впоследствии стал известен как язык «Gherkin».
Автоматизированный интеграционный тест пишется на языке «Gherkin» и
состоит из трёх этапов выполнения теста:
 «Given». На этом этапе задаются предусловия для выполнения
теста. Например, это может быть предварительная очистка отдельных таблиц
базы данных для дальнейшего заполнения их тестовыми данными или просто
заполнение таблиц БД тестовыми данными из таблицы автоматизированного
теста;
 «When». На этом этапе с уже подготовленными тестовыми данными
выполняется запрос к серверу;
 «Then». На этом этапе осуществляются проверки ответа сервера.
Проверяться может как код ответа сервера, так и заголовок или тело ответа.
Чаще всего проверки реализуются специальной командой «Assert», которая
выполняет сравнивание ожидаемого результата с фактическим и, если
обнаруживает несоответствие, то выводит об этом соответствующее
сообщение.
Существует и четвёртое ключевое слово – «And», но оно не является
столь важным и устанавливается только в случае повторения выполнения
каких-либо действий. Например, проверок может быть несколько и после
первой «Then» остальные проверки принято маркировать не «Then», а «And».
После завершения разработки интеграционного автоматизированного
теста, тестировщик-автоматизатор передаёт разработанное DevOps-
специалисту на развёртывание. На этом цикл разработки завершается.
Недельный спринт (цикл) разработки программного обеспечения в отделе
перспективных разработок ООО «Такском» представлен на рисунке 10.

24
Рисунок 10 – Недельный спринт (цикл) разработки программного обеспечения в отделе перспективных разработок
ООО «Такском»

25
1.2.2 АНАЛИЗ НЕДОСТАТКОВ ОРГАНИЗАЦИИ ПРИКЛАДНЫХ

ПРОЦЕССОВ

В ООО «Такском» в настоящий момент времени прикладные процессы


разработки программного обеспечения современны и отлажены и это
неудивительно, т.к. продажа программного обеспечения собственной
разработки – основная миссия бизнеса компании. Однако в том, что касается
тестирования, а если быть конкретнее, автоматизированного тестирования,
присутствуют серьёзные пробелы в понимании и во взаимодействии между
участниками разработки.
Ни один из участников разработки, кроме тестировщика-автоматизатора,
не знает какой именно функционал покрыт автоматизированными тестами. Из-
за этого у ручного тестировщика отсутствует понимание того, какой
функционал при проведении регрессионного тестирования ему можно не
проверять, т.к. данных функционал может быть покрыт автоматизированными
тестами. Из-за этого перед релизом новой версии программного продукта
ручному тестировщику приходится проверять абсолютно весь и старый и
новый функционал, что занимает много времени и дублирует работу
тестировщика-автоматизатора.
Отсутствие понимания участников разработки о том, что покрыто
автоматизируемыми тестами, а что не покрыто, влечёт за собой постоянное
выяснение у тестировщика-автоматизатора на что уже разработаны
автоматизированные тесты, а на что нет.
Информационные системы, которые используются в ООО «Такском», не
предназначены для удовлетворения информационных нужд автоматизации
тестирования. Например, основная используемая в компании информационная
система «JIRA» имеет раздел «WiKi», предназначенный для хранения данных в

26
виде электронной энциклопедии, но функционал ограничен стандартными
функциями текстового редактора и не более того.

1.2.3 ПРЕДЛОЖЕНИЯ ПО ИНФОРМАТИЗАЦИИ ПРИКЛАДНЫХ

ПРОЦЕССОВ

Поскольку в действующей схеме прикладных процессов имеется


недостаток в виде отсутствия инструмента по контролю за состоянием
покрытия разработанного функционала автоматизированными тестами, то
имеет смысл оценить использующиеся на рынке инструменты, которые бы
могли удовлетворить данную потребность. Сразу же возникает проблема в том,
что таких систем просто не существует.
Чтобы устранить недостатки текущей организации прикладных
процессов тестирования, требуется разработать систему, которая бы
удовлетворяла информационные потребности всех участников разработки по
части автоматизированного тестирования. Такая система позволит
систематизировать информацию о том, какой функционал разработанного
программного обеспечения покрыт автоматизированными интеграционными
тестами, а какой нет.
Наилучшим вариантом решения проблемы является разработка
небольшого приложения, в котором появится возможность добавления
разработанных функций с соответствующими атрибутами о покрытии данного
функционала автоматизированными тестами или просто заполнением о том,
что на данный функционал в настоящий момент отсутствуют
автоматизированные тесты, что означает, что необходимо продолжать
тестировать эти методы вручную и в дальнейшем разработать под них
автоматизированные тесты.
Для разработки информационной системы лучше всего выбрать уже
использующиеся на предприятии информационные технологии. ООО
«Такском» является «золотым партнёром корпорации Microsoft в России» и
27
использует её продукты для разработки программного обеспечения. Именно на
технологиях разработок «Microsoft» основывается большая часть продуктов
ООО «Такском». Поэтому для разработки планируемой информационной
системы целесообразно использовать те же инструменты разработки.
Ключевым инструментом для разработки в ООО «Такском» является
продукт «Visual Studio 2019 Корпоративная». Это интегрированная среда
разработки, предоставляющая большой выбор технологий от настольных
приложений до ВЕБ-сервисов и соответствующий набор инструментов для их
разработки.
Поскольку наполнением комплекса задач будет заниматься тестировщик-
автоматизатор, то для разработки лучше всего использовать те же
инструменты, которые в своей работе использует он. Поскольку некоторые
ВЕБ-сервисы, к которым обращаются участники команды разработки, являются
внешними, то при разработке автоматизированного теста не представляется
возможность полностью повторить функционал тестируемого ВЕБ-сервиса, то
возникает необходимость в некоторой эмуляции функционала, например в
эмуляции авторизации. Для эмуляции используются так называемые
«заглушки». Чаще всего «заглушки» разрабатываются по технологии «Model
View Controller», т.к. это самая простая технология для разработки ВЕБ-
сервисов и отлично подходит под эти нужды.
Технология «Model View Controller» имеет корни ещё в 80-х, но для
проектирования несложных и при этом масштабируемых информационных
систем и по сей день сохраняется популярной. Технология состоит из трёх
ключевых компонентов: моделей, представлений и контроллеров.
Модель (Model) предоставляет данные и реагирует на команды
контроллера, изменяя своё состояние.
Представление (View) отвечает за отображение данных модели
пользователю, реагируя на изменения модели.
Контроллер (Controller) интерпретирует действия пользователя, оповещая
модель о необходимости изменений.
28
1.3 ПОСТАНОВКА ЗАДАЧИ ИНФОРМАТИЗАЦИИ

1.3.1 ЦЕЛЬ И ЗАДАЧИ ПРОЕКТА ИНФОРМАТИЗАЦИИ

Главной целью выпускной квалификационной работы является


разработка системы по информатизации тестирования программного
обеспечения, а именно - разработка комплекса задач, который позволяет
систематизировать информацию о покрытии нескольких программных
продуктов компании автоматизированными интеграционными тестами.
Необходимость вызвана отсутствием в информационных системах
компании инструмента, который бы позволял отслеживать текущее состояние
покрытия интеграционными автоматизированными тестами разработанного
функционала программных продуктов.
Ответственным за заполнение комплекса задач является тестировщик-
автоматизатор, т.к. он занимается автоматизацией тестирования и может
систематизировать информацию о наличии либо отсутствии
автоматизированных тестов на конкретный функционал конкретного ВЕБ-
сервиса.
Разработка комплекса задач «Система по информатизации тестирования
программного обеспечения» направлена на достижение следующих целей:
 Обеспечение поиска информации как о наличии, так и об отсутствии
автоматизированных тестов на конкретный функционал конкретного
программного продукта компании;
 Оперативное добавление и обновление недавно разработанных
программных методов продуктов компании;
 Оперативное добавление и обновление недавно разработанных
автоматизированных интеграционных тестов программных методов
продуктов компании;

29
1.3.2 ПОСТРОЕНИЕ И ОБОСНОВАНИЕ МОДЕЛИ НОВОЙ ОРГАНИЗАЦИИ

ПРИКЛАДНЫХ ПРОЦЕССОВ

Имеющиеся в действующей модели прикладных процессов недостатки


можно ликвидировать, создав новую модель прикладных процессов в
организации. Внедрение новой информационной системы несколько изменит
действующие процессы разработки программного обеспечения в компании, но
в дальнейшем окупится.
Функциональная модель ещё на стадии проектирования будущей
информационной системы позволяет определять изменения в структуре бизнес-
процесса разработки. Новая модель необходима для выявления лучших путей
решения задач в будущем.
Было принято решение о разработке новой функциональной модели с
использованием свободно распространяемого решения «XMind», которое уже
применяется в ООО «Такском» для других задач, например для упрощения
ручного тестирования. «XMind» позволяет быстро создавать схему в виде
смарт-карты древовидной структуры. Также смарт-карта позволяет быстро
указать взаимосвязь между элементами.
В соответствии с новой моделью прикладных процессов изменится
структура взаимодействия между ручным тестировщиком и тестировщиком-
автоматизатором. Ручному тестировщику больше не придётся обращаться к
тестировщику-автоматизатору, чтобы узнать, что ему необходимо тестировать.
Исчерпывающую информацию ему будет предоставлять разработанная
информационная система, доступ к которой осуществляется при переходе по
ссылке из системы управления проектами «JIRA».
Новая функциональная схема представлена на рисунке 11.

30
Рисунок 11 – Обновлённая схема смарт-карты «XMind» «Недельный спринт (цикл) разработки программного
обеспечения в отделе перспективных разработок ООО «Такском»

31
1.3.3 СПЕЦИФИКАЦИЯ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К

ИНФОРМАЦИОННОЙ СИСТЕМЕ

В офисе ООО «Такском» уже имеется развернутый рабочий сервер с


именем «Pluto» на операционной системе Windows Server, на котором
ежесуточно осуществляется прогон автоматизированных тестов, то имеет
смысл разрабатываемый комплекс задач развернуть на его ВЕБ-сервере IIS,
который и будет являться серверной частью приложения.
Таблица 1 – Характеристика сервера
Название Название Количество
Процессор Intel Xeon E5620 2 шт.
Оперативная память Crucial 1 шт.
[CT8G3ERSLD8160B] 4
ГБ

Жёсткие диски Seagate Exos 7E8 1 шт.


[ST160NM0045]

Для разрабатываемого комплекса задач набор фактических характеристик


является достаточным и увеличения характеристик не требуется.

1.3.4 СПЕЦИФИКАЦИЯ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К

ИНФОРМАЦИОННОЙ СИСТЕМЕ

Комплекс «Система по информатизации тестирования программного


обеспечения» должен быть отказоустойчивым. Под отказоустойчивостью
понимается как программная, так и аппаратная защищённость комплекса.
Сервер, на котором будет развёрнут комплекс, находится в серверной,
стойки которой подключены к источнику бесперебойного питания. Это

32
позволяет в случае отключения электрической энергии отключить сервер в
штатном режиме.
Автоматическое ежедневное ночное резервное копирование базы данных
на отдельный носитель, позволит оперативно восстановить базу данных в
случае её утраты.
Отказом «Системы по информатизации тестирования программного
обеспечения» будет считаться утрата базы данных, из-за чего комплекс будет
недоступен до восстановления. На восстановление понадобится некоторое
время.
Сбоем «Системы по информатизации тестирования программного
обеспечения» будет считаться некорректная работа программной части на
сервере – 500-ая, 501-ая или иная серверная ошибка в браузере. Для решения
данного сбоя необходимо будет переконфигурировать ВЕБ-сервер IIS.

1.4 КАЛЕНДАРНО-РЕСУРСНОЕ ПЛАНИРОВАНИЕ ПРОЕКТА

1.4.1 ПЛАН ГРАФИК ПРОЕКТА

Наиболее длительным этапом является разработка информационной


системы. После изучения можно выделить основные этапы проведения работ,
указанные в таблице 2.
Таблица 2 – Последовательность работ проекта2

Название Длительность (дней)

Анализ существующей системы 3


управления проектами

Постановка задачи автоматизации 10


процесса

Продолжение Таблицы 2 – Последовательность работ проекта

2
Таблицы с 1 по 10 составлены автором
33
Название Длительность (дней)
Проектирование информационной 15
системы
Установка программных средств 2
Обучение пользователей 2
информационной системы
Опытная эксплуатация 15

Для более наглядного представления, на рисунке 12 представлен график


выполнения поставленных задач. Временная шкала выполнения мероприятий
измеряется в неделях.

Длительность (дней)

Анализ существующей системы хранения и обновления регламентов


Постановка задачи автоматизации процесса
Проектирование информационной системы
Установка программных средств
Обучение пользователей информационной системы
Опытная эксплуатация

Рисунок 12 – План график проекта

График проекта даёт возможность не только контролировать рабочий


процесс, но и распланировать его. Контролируются все этапы, элементы и связи
процессов разработки и внедрения.

34
2 ПРОЕКТНАЯ ЧАСТЬ

2.1 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ

2.1.1 ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ И СХЕМА ДАННЫХ

На модели, указанной на рисунке 13 показаны основные этапы нового


принципа работы, в соответствии с источником, системы управления
проектами отдела перспективных разработок ООО «Такском».

Рисунок 13 – Инфологическая модель

35
2.1.2 СХЕМА ДАННЫХ

Выбранная для проекта СУБД Microsoft SQL Server позволяет на основе


существующей не сервере базы данных составить схему данных в разделе
«Диаграммы баз данных». Схема базы данных проекта разработанной системы
изображена на рисунке 14.

Рисунок 14 – Схема данных

2.1.3 ВХОДНАЯ ИНФОРМАЦИЯ

Для доступа к системе по информатизации тестирования программного


обеспечения необходимо в «JIRA» перейти по ссылке (рисунок 15).
36
Рисунок 15 – Информационный раздел Группы разработки сервисов в
«JIRA» с ссылками на другие сервисы
37
Входной информацией является нормативно-справочная. Источником
информации является SWAGGER – интегрированная во все ВЕБ-сервисы ООО
«Такском» система, предназначенная для ручного тестирования Back-End-
составляющей и Visual Studio, в которой и разрабатываются интеграционные
автоматизированные тесты.
Пустая форма ввода входной информации разработанной
информационной системы изображена на рисунке 16.

Рисунок 16 – Пустая форма ввода входной информации

В первую очередь пользователю предлагается выбрать из выпадающего


списка один из описываемых автоматизированными тестами сервисов.
Выпадающий список представлен на рисунке 17.

38
Рисунок 17 – Выпадающий список сервисов
Вторым параметром для ввода будет название автоматизированного
теста. Его тестировщик-автоматизатор копирует из строки сценария «Scenario»
в Feature-файле разработанного им ранее автоматизированного теста. Пример
Feature-файла представлен на рисунке 18. В случае отсутствия
автоматизированного теста, необходимо пропустить заполнение данного
параметра.

Рисунок 18 – Feature-файл
Третьим параметром для заполнения формы ввода входной информации
является флажок-чекбокс «Сценарий автоматизированного теста
ПОЗИТИВНЫЙ» и устанавливается в соответствующем случае. Если не
установить данный параметр, то описываемый автоматизированный тест
считается негативным.
Прежде чем заполнить четвёртый параметр тестировщик-автоматизатор
обязан удостовериться в работоспособности метода контроллера и в
работоспособности разработанного автоматизированного теста. Для проверки
работоспособности метода сначала необходимо авторизоваться в ВЕБ-сервисе
через SWAGGER, изображённый на рисунке 19.

39
Рисунок 19 – Авторизация в SWAGGER’е
40
Для авторизации и проверки метода в SWAGGER’е необходимо:
1. Ввести тестовые авторизационные данные (логин и пароль) в формате
JSON в поле ввода тестовых данных авторизационного метода. Для
формирования JSON-формата необходимо предварительно составить
его в текстовом редакторе, скопировать заготовленный из смарт-карты
или прямо в SWAGGER’е кликнуть на «Example Value» пункта «Data
Type», после чего отредактировать предложенный шаблон, внеся в
него требуемые тестовые данные;
2. Нажать на кнопку выполнения запроса. В этот момент браузер пошлёт
запрос на сервер и через несколько секунд отобразит ответ от сервера
в формате JSON, а также код ответа сервера, по которому зачастую
можно определить корректность отправленного запроса;
3. Скопировать из тела (Body) ответа сервера токен и вставить его в поле
ввода токена авторизации, после чего для его сохранения кликнуть в
любом свободном месте интерфейса SWAGGER’а;
4. Ввести тестовые данные для покрытого автоматизированным тестом
метода и выполнить запрос, тем самым проверив метод на
работоспособность (рисунок 20).

41
Рисунок 20 – Проверка метода «GetDepartment» в SWAGGER’е

42
После выполнения вышеуказанных действий необходимо запустить
автоматизированный тест из Visual Studio. Убедившись в работоспособности и
метода контроллера и в работоспособности разработанного
автоматизированного теста, тестировщик-автоматизатор копирует название
метода контроллера из SWAGGER’а и вставляет его в поле «Название метода
автоматизированного теста».
Пятым параметром для заполнения формы ввода входной информации
является флажок-чекбокс «Статус метода автоматизированного теста
ПОКРЫТ» и устанавливается в соответствующем случае. Если не установить
данный параметр, то описываемый метод считается не покрытым и это
означает, что на данный метод ещё не разработан автоматизированный
интеграционный тест. Наличие же данного флажка-чекбокса символизирует для
ручного тестировщика о том, что программный метод был протестирован
автоматизированным тестом и если автоматизированный тест выполнился
успешно, то нет необходимости вручную его тестировать.

2.1.3 КЛАССИФИКАТОРЫ И НОРМАТИВНО-СПРАВОЧНАЯ

ИНФОРМАЦИЯ

Структура базы данных состоит из 5 таблиц-справочников


(классификаторов) с нормативно-справочной информацией и 1 основной
таблицей содержащей коды, с которой реляционными связями соединяется
каждая из таблиц-справочников, а именно:
Таблица «Ввод» (InputModels) хранит коды, которые по реляционным
связям создаются в этой таблице при заполнении таблиц-справочников. Поля,
их типы, и размер представлены в таблице 3. Данная таблица не является
классификатором, однако представлена именно в данном разделе для
целостного понимания структуры реляционных связей между таблицами.

43
Таблица 3 – Структура таблицы «Ввод» (InputModels)
Поле Тип Размер
Id Счетчик Длинное целое
Сервис Счетчик Длинное целое
Название теста Счетчик Длинное целое
Сценарий Счетчик Длинное целое
Название метода Счетчик Длинное целое
Статус метода Счетчик Длинное целое
В таблице «Сервисы» предоставлен список ВЕБ-сервисов, к которым
тестировщиком-автоматизатором разработаны автоматизированные
интеграционные тесты. Поля, их типы, и размер представлены в таблице 4.
Таблица 4 – Структура таблицы «Сервисы» (ServiceModels)
Поле Тип Размер
Код Сервиса Счетчик Длинное целое
Наименование Сервиса Короткий текст 255
В таблице «Название теста» предоставлен список названий
интеграционныех тестов, разработанных тестировщиком-автоматизатором.
Поля, их типы, и размер представлены в таблице 5.
Таблица 5 – Структура таблицы «Название теста» (TestNameModels)
Поле Тип Размер
Код Названия теста Счетчик Длинное целое
Наименование Короткий текст 255
Названия теста
В таблице «Сценарии» предоставлен список параметров сценариев
автоматизированных тестов в булевом выражении. «1» свидетельствует о том,
что автоматизированный тест является позитивным, «0» - негативным. Поля, их
типы, и размер представлены в таблице 6.

Таблица 6 – Структура таблицы «Сценарии» (ScenarioModels)


Поле Тип Размер
Код Сценария Счетчик Длинное целое
Наименование Булевое значение (0, 1) 1
Сценария
44
В таблице «Название метода» предоставлен список названий методов
покрываемого функционала ВЕБ-сервисов. Поля, их типы, и размер
представлены в таблице 7.
Таблица 7 – Структура таблицы «Название метода» (MethodNameModels)
Поле Тип Размер
Код Названия метода Счетчик Длинное целое
Наименование Короткий текст 255
Названия метода
В таблице «Статус метода» предоставлен список параметров статусов
метода ВЕБ-сервиса, который покрывает автоматизированный тест в булевом
выражении. «1» свидетельствует о том, что метод является покрытым
автоматизированным тестом, «0» - не покрытым. Поля, их типы, и размер
представлены в таблице 8.
Таблица 8 – Структура таблицы «Статус метода» (MethodStatusModels)
Поле Тип Размер
Код Статуса метода Счетчик Длинное целое
Наименование Статуса Булевое значение (0, 1) 1
метода

2.1.4 ВЫХОДНАЯ ИНФОРМАЦИЯ

Выходная информация представлена в виде экранных форм на 2-х ВЕБ-


страницах. На домашней странице представлена выходная форма, которая
содержит список автоматизированных тестов или программных методов
(рисунок 21), которые занёс в информационную систему тестировщик-
автоматизатор.

45
Рисунок 21 – Страница отчёта
Ручному тестировщику для оценки ситуации с регрессионным
тестированием важно понимать, какой процент функционала в настоящий
момент покрыт автоматизированными тестами. Причём в первую очередь
автоматизированные тесты разрабатываются для самого бизнес-критичного
функционала.
На ВЕБ-странице «Отчёт» представлен отчёт в виде списка ВЕБ-сервисов
компании, для которых разработаны автоматизированные интеграционные
тесты. Отчёт строится на основании заполненных входных данных и
отображает процент покрытия ВЕБ-сервисов компании автоматизированными
тестами (рисунок 22).

46
Рисунок 22 – Страница отчёта

2.2 ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

2.2.1 СТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

«Система по информатизации тестирования программного обеспечения»


основана на паттерне программирования «MVC», структура которого
представлена на рисунке 23.

47
Рисунок 23 – Структура MVC
Программные файлы комплекса задач изображены на рисунке 24.

Рисунок 24 – Файловая структура комплекса задач

На рисунке 25 изображена структура комплекса задач в среде разработки


Visual Studio 2019. Хранение исполняемых файлов программы осуществляется
в виде древовидной структуры в папках. Корнем дерева является название
сборки проекта, ниже по дереву располагается сам проект, под проектом
располагаются папки, в папках – исполняемые файлы или вложенные папки.
Помимо исполняемых файлов, комплекс задач имеет также и
конфигурационные файлы (Web.config и Global.asax), в которых, например,
указывается строка подключения к базе данных SQL Server’а. Также в
конфигурационных файлах указываются дополнительно подключенные
библиотеки, например ORM «Entity Framework». Конфигурационные файлы
отвечают за инициализацию и запуск приложения.

48
Рисунок 25 – Структура комплекса задач в среде разработки Visual Studio 2019
Основой приложения являются классы моделей, состоящие из простых
методов не имеющих каких-либо атрибутов или наследований (Приложения: Г,
Д, Е, И, Л, М). Такие методы в C# называются «POCO» (Plain old CLR object) и
предназначены для формирования ORM-модели. Классы формируют таблицы в
базе данных, а методы - столбцы в таблице базы данных. Помимо простых

49
методов в моделях также присутствуют навигационные свойства, на основе
которых формируются реляционные связи базы данных.
Базу данных проекта формирует ORM «Entity Framework» разработки
Майкрософт. ORM – это Object-Relational Mapping, технология, которая
позволяет связать объектно-ориентированный язык программирования «C#» с
базой данных «Microsoft SQL Server». ORM – это некоторая прослойка между
средой разработки и между базой данных. Она позволяет вообще не
использовать язык программирования «Transact-SQL», т.к. сама формирует
требуемые запросы к базе данных и отправляет их на выполнение.
Entity Framework предоставляет 3 возможных варианта взаимодействия с
базой данных:
- «Code First». Создаётся база данных на основе написанного кода.
- «Model First». Создаётся база данных на основе графической модели.
- «DataBase First». Производится подключение к существующей базе
данных и на основе её таблиц формируется код программы для
дальнейшего взаимодействия с таблицами этой базы данных.
В проекте использован самый популярный вариант – «Code First». «Code
First» сам создаёт базу данных на основе созданных моделей. База данных
формируется на основе файла контекста данных (Приложение В), в котором
указываются модели.
Методы контроллера (Приложение А) отвечают за маршрутизацию
запросов от сервера к клиенту. Эти методы извлекают информацию из базы
данных, обрабатывают её и передают в представления (Приложения: Н, О, П,
Р), а представления преобразуют эту информацию в HTML-разметку, которую
отображает браузер клиента.
Помимо основных составляющих технологии MVC (моделей,
контроллеров и представлений) в коде программы также имеются
вспомогательные методы (Приложение Б) и модель перечисления (Приложение
К).

50
2.2.2 ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ

Интерфейс пользователя представлен в графическом виде и представляет


из себя ВЕБ-сайт. Это предполагает стандартное использование основных
элементов пользователем компьютера с использованием ВЕБ-браузера.
Графический интерфейс позволяет управлять приложением через визуальные
элементы управления:
 Страницы;
 Выпадающие списки;
 Поля ввода;
 Кнопки;
 Гиперссылки;
 Флажки-чекбоксы.
О предназначении каждого из перечисленных элементов более подробно
сказано в руководстве пользователя (Приложение С).
Для оформления стилей элементов на ВЕБ-страницах использована
свободно распространяемая CSS-библиотека «Bootstrap», которая
интегрирована в проект как дополнительная библиотека.
«Bootstrap» позволяет придать ВЕБ-элементам современный плоский
Material-дизайн без необходимости разработки отдельных CSS-библиотек для
оформления, что при разработке небольшого проекта существенно экономит
время на разработку.
Языком пользователя является Русский язык с элементами англицизмов,
но понятных пользователю. Интерфейс домашней страницы изображен на
рисунке 26.

51
Рисунок 26– Домашняя страница «Системы по информатизации
тестирования программного обеспечения»

2.2.3 ТЕСТИРОВАНИЕ КОМПЛЕКСА ЗАДАЧ

Тестирование разработанного комплекса задач производилось вручную с


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

52
позволяет записать более 255 символов в базу данных, что является
правильным поведением.
Использование автоматизированного тестирования применительно к
данному комплексу задач не применялось, т.к. при текущем масштабе проекта
является нецелесообразным.

2.3 ТЕХНИЧЕСКОЕ ОБЕСПЕЧЕНИЕ

Основные этапы создания комплекса задач «Система по информатизации


тестирования программного обеспечения» для ООО «Такском»:
1. Определение цели создания и её позиционирование.
На этом этапе необходимо определить, для чего нужна ИС, т.е. какие
задачи она должна решать: предоставить удобную запись обработку и хранение
информации по абитуриентам.
Цели ИС, в большинстве случаев должны ставиться заказчиком, а затем
вместе с исполнителем они уточняются и корректируются.
Это один из самых важных этапов не только создания ИС как таковой, но
и важнейший этап маркетинга.
Если заказчик не понимает, для чего ему нужна ИС, с 99% вероятностью
он будет недоволен работой исполнителя и будет считать, что деньги,
потраченные на создание ИС, просто потеряны. В итоге, компания не будет
использовать методы такого маркетинга, что негативно скажется на ее
конкурентных позициях на рынке.
2. Сбор требований.
Далее необходимо начинать собирать и утверждать требования к
будущей информационной системе. Представители исполнителя общаются с
будущими пользователями и администраторами системы, а также с их
руководством. В ходе обследования не только систематизируются требования и
пожелания к внедряемому решению, но и анализируется документация, которая

53
должна стать источником исходных данных системы, или формирование
которой должно быть в результате автоматизировано.
Результатом данного этапа должно стать появление технического задания
на разработку и внедрение информационной системы. Техническое задание
должно базироваться на условиях договора и требованиях, изложенных в
уставе проекта и содержать следующие разделы (для России структура
технического задания регламентируется ГОСТ 34.602 89):
 Назначение и цели создания системы.
 Описание объекта автоматизации и основных автоматизируемых
бизнес-процессов.
 Требования к системе: требования к структуре; функциям
(задачам), решаемым системой; требования к техническому и
организационному обеспечению; требования к надежности, безопасности и т.д.,
и т.п.
 Состав и содержание работ по созданию информационной системы.
 Порядок контроля и приемки результатов работ.
 Требования к составу работ по подготовке объекта автоматизации
для запуска информационной системы в эксплуатацию.
 Требования к составу проектной и пользовательской документации.
Завершение этапа сбора требований – это утверждение Заказчиком
Технического задания. В некоторых случаях у Заказчика до начала работ по
проекту уже существует техническое задание (входит в состав конкурсной
документации). В этом случае результаты обследования и сбора требований
фиксируются в частных технических заданиях, детализирующих и
конкретизирующих общие требования к информационной системе,
представленные в исходном техническом задании.
3. Реализация
Этап реализации всех требований к информационной системе,
изложенных в Техническом задании и Техническом проекте. В этот период

54
Исполнитель разрабатывает все необходимые программные компоненты,
создает структуры базы данных, производит установку, настройку и
тестирование всех компонентов информационной системы на своей
территории, имитирует сценарии интеграции и т.д. и т.п. Завершение этапа
реализации подтверждается появлением таких проектных документов, как
руководство по установке и настройке системы, программа и методика
испытаний системы, а также шаблон базы данных и реестр всех выполненных
программных разработок.
Изучив источники, принято решение что, для получения доступа к
приложению пользователю необходима рабочая станция, подключенная к
корпоративной сети с предустановленной программой, для подключения к
приложению и выводу информации по задачам [16].
Для стабильной работы рабочая станция пользователя должна отвечать
требованиям, указанным в таблице 9.
Таблица 9 – Системные требования к аппаратному обеспечению
Наименование Минимальные системные
требования
ЦП AMD Sempron 2 Gh
Оперативная память 2 Гб
Видеопамять 256 Мб
Сетевая карта 10 Мб
Разрешение монитора 1024x600

Кроме аппаратной составляющей рабочей станции компьютер


пользователя также должен отвечать программным системным требованиям
приложения. Все требования представлены в таблице 10.
Таблица 10 – Системные требования к программному обеспечению.
Наименование Версия
Windows 7, 8, 10
.Net Framework от 4.5
Для выполнения комплекса задач необходимо выдвинуть виртуальную
машину на текущем сервере с выделением минимальных системных

55
требований для ее ресурсов, устанавливать дополнительный сервер не
требуется.

2.4 ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Для обеспечения информационной безопасности планируется внедрить


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

2.5 ОЦЕНКА ЭФФЕКТИВНОСТИ ПРОЕКТА

Экономический эффект — это результат проведения мероприятий,


который может быть выражен как экономия от снижения себестоимости
валовой или чистой прибыли, прирост дохода и прибыли.
Экономическая эффективность - экономическая эффективность
приходится на один рубль капиталовложений, обеспечивший этот эффект.
Существует 3 вида экономического эффекта:
 Экономия общественного труда;
 Объемный эффект;
56
 Структурный экономический эффект.
Объемный экономический эффект связан с удовлетворением новых
общественных потребностей и возрастанием на этой основе объема реализации
(создание новых более производственных ЭВМ, способствует лучшему
удовлетворению объему производства).
Структурный экономический эффект — обусловлен сдвигами в
распределении ресурсов между отраслями, регионами и сферами приложения
труда.
Экономический эффект
Экономическая эффективность= (1)
Затраты

Экономический рост сопровождается повышением эффективности


производства, сокращением безработицы, стабильностью цен и финансов,
расширением внешнеэкономических связей и другими положительными
экономическими, и социальными процессами. Практический и технический
прогресс выражается во внедрении мероприятий. Внедрение любого
мероприятия технического прогресса требует затрат. Все затраты можно
разделить на две части: единовременные затраты и текущие затраты.
Единовременные затраты осуществляются сразу и в полном объеме.
Например, затраты на приобретение более прогрессивного станка с ЧПУ.
Текущие затраты предприятие несет постоянно в связи с внедрением
мероприятий технического прогресса (затраты на техническое обслуживание,
ремонт).
Капитальные вложения - это значительная сумма единовременных затрат
на научно-исследовательские, изыскательские, проектные работы:
строительство, реконструкцию, новую технику, автоматизацию и т.д., то есть
на внедрение мероприятий технического процесса.
Абсолютная (общая) экономическая эффективность капитальных
вложений определяется для вновь строящихся промышленных предприятий
или расширения действующих производственных мощностей и представляет

57
собой отношение экономического эффекта к капитальным затратам,
обеспечивающих этот эффект.
Расчет капитальных затрат.
Капитальные затраты ИС носят разовый характер и включают:
К = Ктс + Кпс + Кнеучт (2)

где Ктс - затраты на технические средства управления; (таблица 11)


Кпс - затраты на программные средства; (таблица 12)
Кнеучт - неучтенные затраты, обычно составляют 7 - 8% от общих затрат.
Капитальные затраты рассчитываются как для существующего (базового),
так и для проектируемого вариантов автоматизации.
Кб = 0руб.
Таблица 11 - Затраты на технические средства управления
Цена за Общая
Количеств
Наименование единицу, стоимость,
о единиц
руб. руб.
Память USB Flash 8 ГБ 1 550,00 руб. 550,00 руб.
Итого 550,00 руб.
Таблица 12 - Затраты на программные средства
Цена за Общая
Количеств
Наименование единицу, стоимость,
о единиц
руб. руб.
Среда разработки Visual 1 8200,00 8200,00
Studio Enterprise руб. руб.
Итого 8200,00
руб.
Кнеучт = 8750,00* 8% = 700,00 руб.
Кпр=550,00+8200,00+700,00=9450,00 руб.
Эффективность информационной системы определяют сопоставлением
результатов от функционирования информационной системы и затрат всех
видов ресурсов, необходимых для ее создания и развития.
На основе полученных данных практик необходимое количество человек,
работающих над созданием ИС, составило:
58
Чп=1
В таблице 13 и 14, представлено штатное расписание базового и
проектируемого варианта.
Таблица 13 – Штатное расписание для базового варианта
№п/ Оклад, руб. Сумма, руб
Должность Кол-во, чел.
п (месяц) (год).
1 Разработчик 1 60000,00 720000,00
Итого 1 60000,00 720000,00
Таблица 14 – Штатное расписание для проектируемого варианта
№п/ Оклад, руб. Сумма, руб
Должность Кол-во, чел.
п (месяц) (год).
1 Разработчик 1 60000,00 720000,00
Итого 1 60000,00 720000,00
Себестоимость разрабатываемой ИС складывается из текущих и
капитальных затрат.
Текущие затраты включают в себя: зарплату, амортизацию, затраты на
электроэнергию, материалы, затраты на ремонт и запасные части, накладные и
прочие расходы [31].
Подсчитаем затраты на разработку по элементам затрат.
Затраты на оплату труда работника, непосредственно занятым
разработкой и внедрением ИС, с использованием данных из табл., составляет за
срок разработки 720000,00 руб.
Затраты на страховые взносы во внебюджетные фонды составят:
 Пенсионные фонд РФ (22%): 158400,00 руб.;
 Фонд социального страхования (2,9%): 20880,00 руб.;
 Фонд обязательного медицинского страхования (5,1%):36720,00
руб.
Общая сумма затрат по страховым взносам составит 215920,00 рублей.
Расчет страховых взносов осуществлять от итоговой суммы за период
разработки.

59
Затраты на амортизацию основных средств представлены в таблице 15.
Амортизация основного средства равна отношению его общей стоимости к
сроку службы, умноженному на срок разработки.
Таблица 15- Затраты на амортизацию основных средств
Общая Срок
Модел Цена, Кол Амортизация
Наименование стоимост служб
ь руб. -во ., руб. (год)
ь, руб ы, мес.
Dell
20600,0 20600,00
Компьютер Vosto 1 48 мес. 5150,00 руб.
0 руб. руб.
3650
Компьютерная Logitec 370,00 370,00
1 - -
мышь h руб. руб.
3450,00 3450,00
Принтер HP 1 60 мес. 690,00 руб.
руб. руб.
Studio 6740,00 6740,00
Стол 1 -
WRX руб. руб.
20990,0 20990,00
Стул С-03 1 -
0 руб. руб.
Итого
амортизационн
5840,00 руб.
ых отчислений
Затраты на электроэнергию рассчитаем следующим образом:

A(k) = Wк * t (3)
где A(k) – затраты электроэнергии одного компьютера
Wк- мощность одного компьютера
t - время работы одного компьютера за месяц
A(k) = 140*132=18480Вт

A(л) = Wл * t (4)
где A(л)- затраты электроэнергии одной лампы освещения помещения
Wл- мощность лампочек, Вт/час
t - время освещения одной лампой за месяц
A(л) = 80*88=7040Вт

A(п) = Wп * t (5)
Wп – мощность одного принтера

60
t- время работы одного принтера за месяц
A(п) =100*22= 2200Вт
Потребляемая за день разработки ИС электроэнергия (W) составит:

W = Wк + Wл + Wп (6)
W = 140+80+100=320Вт
Следовательно, за год будет потреблено:

Wp = W * tp (7)
tp – за год
Wp = 320*2112=675840Вт
Затраты предприятия на электроэнергию ставят

Cэл = Tэ*Wp (8)


Tэ – тариф электроэнергии для данной организации
Cб эл = 3.71р *675.84кВт=2507,00 руб.
Cпр эл = 3.71р *675.84кВт=2507,00 руб.
Сравнительная характеристика затрат до и после внедрения
информационной системы представлена в таблице 16.
Таблица 16 – Сравнительная характеристика затрат до и после внедрения
информационной системы
№п\п Наименование величины Величина затрат до Внедрение затрат
затрат внедрения (руб.) после внедрения
(руб.)
1 Заработная плата 720000,00 руб. 720000,00 руб.
2 Страховые взносы 43200,00 43200,00
во внебюджетные руб. руб.
3 Амортизация техники и 5840,00 руб. 5840,00 руб.
4 Электроэнергия
мебели 2507,00 руб. 2507,00 руб.
6 Прочие затраты 129600,00 руб. 86400,00 руб.
Итого 325147,00 руб. 281947,00 руб.
Где прочие затраты до внедрения = 720000*90%=648000,00 руб.
Прочие затраты после внедрения = 720000*60%=432000,00 руб.
61
Расчет годовых приведенных затрат для базового и проектного вариантов
(ЗП) определяются по формуле:

ЗПi=Сi+Ен*Кi; (9)
ЗПб=Сб+Ен*Кб; (10)
ЗПб=325147+0,25*0=325147,00 руб.

ЗПпр=Спр+Ен*Кпр (11)
ЗПпр=281947+0,25*9450=284309,00
K2>K1
(12)
C2<C1
Э=+∆С-Ен*∆К (13)

Э=43200-0.25*43200=32400,00 руб.
∆С=325147-281947=43200,00 руб.
∆К=129600-86400=43200,00 руб.
Ен=0,25
Экономия на себестоимости +∆С погашается увеличением
капиталовложений - ∆К
Годовой экономический эффект (за период разработки, 2 месяца) Эг
находится как разница приведенных затрат по двум сравниваемым вариантам.

Эг=ЗПб-ЗПпр (14)
где ЗПб – годовые приведенные затраты по базовому варианту;
ЗПпр – годовые приведенные затраты по проектному варианту.
Эг=325147−284309=40838,00 руб.
Коэффициент эффективности по выбранному варианту определяется по
следующей формуле:
(С 1−С 2)
Ep= (15)
К 2−К 1
где К1, К2 – себестоимость вложения по первых и вторых вариантах (К2
больше К1)

62
С1, С2 – себестоимость единицы продукции по первому и второму
варианту
Рассчитаем сравнительную эффективность:
325147−284309
Ep= =4
9450−0

Срок окупаемости капитальных вложений характеризует период времени,


в течение которого капитальные возмещаются за счет снижения себестоимости.
Определяется по формуле:
1
T ok = (16)
Ep

где Ер – Экономическая эффективность.


1
T ok = =0,25=3 месяца
4

В результате проделанной работы, достигнуты следующие результаты:


 Повысилась производительность труда;
 Значительно сократилось время выполнения процесса;
 Облегчилось выполнение работы;
 Срок окупаемости данного продукта составляет 3 месяца.

63
ЗАКЛЮЧЕНИЕ

В ходе выполнения выпускной квалификационной работы было


проведено изучение источников на темы информационных технологий и
информационных систем и их проектирование.
Произведён подробный анализ деятельности крупной компании,
занимающейся разработкой программного обеспечения в современных реалиях.
Были поставлены и реализованы задачи по улучшению действующих бизнес-
процессов.
Был разработан комплекс задач «Система по информатизации
тестирования программного обеспечения», который позволил сэкономить
время сотрудников и обеспечил актуальной информацией о текущем состоянии
автоматизированного тестирования.
Все поставленные задачи были выполнены.

Расчет экономической эффективности показал, что повысилась


производительность труда, сократилось время выполнение процессов,
облегчилось выполнение работы, а также срок окупаемости разработанного
комплекса задач составил 3 месяца.
Реализованный комплекс задач уже внедрён и постепенно окупается.

64
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Алешин, Л.И. Информационные технологии: Учебное пособие /


Л.И. Алешин. - М.: Маркет ДС, 2011. Дата обращения: 30.03.2020.
2. Бабаева З.В. Автоматизированный офис DOC Учебно–
методический комплекс для студентов специальности 080801 «Прикладная
информатика (в экономике)». – М.: МИИТ, 2011. – 27 с. Дата обращения:
01.04.2020.
3. Булавина Е.А., Барзданис Ю.В., Булавин Ю.П. Компьютерные
информационные технологии в документационном обеспечении управления
PDF Учебное пособие. — Ростов н/Д.: Ростовский государственный
университет путей сообщения, 2008. — 88 с. Дата обращения: 05.04.2020.
4. Волкова В. Н. Информационные системы в экономике [Текст]:
Учебник для академического бакалавриата / [В. Н. Волкова [и др.]; под ред. В.
Н. Волковой, В. Н. Юрьева; С.-Петерб. политехн. ун-т Петра Великого. -
Москва: Юрайт, 2016. - 402 с. Дата обращения: 05.04.2020.
5. Гагарина Л.Г. Разработка и эксплуатация АИС. – М., Форум, 2007
6. Дубянский, В. 1С: Предприятие. Конфигурирование и
администрирование для начинающих [Текст] / В. Дубянский, СПб: «БХВ-
Петербург», 2010 г. - 170 с. Дата обращения: 05.05.2020.
7. Емельянова Н.З. Основы построения автоматизированных
информационных систем. – М., Форум, 2007. Дата обращения: 10.04.2020.
8. Ехлаков Ю.П., Ходжаев Г.А. Теоретические основы
автоматизированного управления. - Ставрополь, 1992г. Дата обращения:
29.03.2020.
9. Защита информации в персональных ЭВМ. / А.В. Спесивцев, В.А.
Вечнер, А.Ю. Крутяков, В.В. Серегин, В.А. Сидоров. - М.: Pадио и связь, 1993.
Дата обращения: 25.04.2020.

65
10. Илюшечкин, В.М. Основы использования и проектирования баз
данных [Текст] / В.М. Илюшечкин, М.: «Юрайт ИД Юрайт», 2011 г. 231 с. Дата
обращения: 23.04.2020.
11. Интегрированные системы проектирования и управления:SCADA-
системы : учебное пособие / И. А. Елизаров, А. А. Третьяков, А. Н. Пчелинцев
и др. – Тамбов : Изд-во ФГБОУ ВПО «ТГТУ», 2015. – 160 с. Дата обращения:
07.04.2020.
12. Козырев, Д.В. - 1С Предприятие v8 Методические материалы
[Текст] / Д.В. Козырев, М.: «1С-Учебный центр №3», 2010 г. - 92 с. Дата
обращения: 09.04.2020.
13. Макаренко С. И. Информационная безопасность: учебное пособие
для студентов вузов. – Ставрополь: СФ МГГУ им. М. А. Шолохова, 2014-372 с.
Дата обращения: 27.04.2020.
14. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0.-
М.:ДИАЛОГ-МИФИ, 2012. –224 с. Дата обращения: 01.04.2020.
15. Мамиконов А.Г. Функциональные подсистемы АСУ. - М.: Высшая
школа, 1987г. Дата обращения: 28.04.2020.
16. Михайлов, С. Е. 1С программирование как дважды два [Текст] / С.
Е. Михайлов, М.: «Издательство ПРИОР», 2009 г. - 214 с. Дата обращения:
03.05.2020.
17. Методика тестирования блоков питания О.Артамонов,
(электронный ресурс). Режим доступа:
[https://fcenter.ru/online/hardarticles/tower/22647] – свободный. Дата обращения:
26.02.2020.
18. Норенков, И.П. Автоматизированные информационные системы:
Учебное пособие / И.П. Норенков. - М.: МГТУ им. Баумана, 2011. Дата
обращения: 23.04.2020.
19. Олифер В.Г. Компьютерные сети. Принципы, технологии. - СПб.,
Питер, 2009. Дата обращения: 05.05.2020.

66
20. Попов А.И. Свободные инструменты проектирования
информационных систем. / САФУ им. М.В. Ломоносова. – Архангельск.:
САФУ, 2012. – 151 с.012. – 151 с. Дата обращения: 06.05.2020.
21. Плещёв В.В. Базы данных. Visuаl FoxPro, Access, SQL Server,
Oracle, MySQL с примерами и упражнениями [Текст]: Учебное пособие /
Плещёв В.В.; 4-е изд., испр. и доп. (реком. УМО Минобразования РФ) -
Екатеринбург: Издво Урал. гос. экон. ун-та, 2013. - 441 с. Дата обращения:
17.03.2019.
22. Радченко, М.Г. - Практическое пособие разработчика [Текст] / М.Г.
Радченко, М: OOO «1С-Паблишинг» 2009 г. - 169 с. Дата обращения:
16.04.2020.
23. Рязанцева, Н. 1С Предприятие 8.2. Управление торговлей. Секреты
работы [Текст] / Н. Рязанцева, СПб.: Питер, 2009 г. - 103 с. Дата обращения:
16.04.2020.
24. Стратегии интернационализации бизнеса [Текст]: методические
указания для студентов бакалавриата, обучающихся по направлению 080100.62
«Экономика» (профиль «Мировая экономика») / М-во образования и науки Рос.
Федерации, Урал. гос. экон. ун-т; [сост. Р. В. Кодачигов]. - Екатеринбург:
[Издательство УрГЭУ], 2013. - 19 с. Дата обращения: 17.04.2020.
25. Учебник по 1С, база знаний, форум [Электронный ресурс] // Режим
доступа к электрон. дан.: http://www.mista.ru. Дата обращения: 13.04.2020.
26. Харитонов, С.А. - Введение в конфигурирование в системе «1С -
Предприятие 8.2». Основные объекты [Текст]/ , С.А. Харитонов СПб.: Питер,
2010. - 89 с. Дата обращения: 17.04.2020.
27. Ходжаев Г.А. Принятие управленческих решений. - Старополь,
1991г. Дата обращения: 03.05.2020.
28. Советов Б. Я. Базы данных [Текст]: Учебник для прикладного
бакалавриата / Б. Я. Советов, В. В. Цехановский, В. Д. Чертовской; С.-Петерб.
гос. электротехн. ун-т «ЛЭТИ» им. В. И. Ульянова (Ленина). - 2-е изд. - Москва:
Юрайт, 2015. - 463 с. Дата обращения 29.05.2020.
67
29. Сурнина Н. М. Проектирование информационных систем [Текст]:
Учебное пособие / Н. М. Сурнина, Н. Г. Чиркина; М-во образования и науки
РФ, Урал.гос. экон. ун-т. – Екатеринбург: [Изд-во УрГЭУ], 2017. – 191 с. Дата
обращения 29.05.2020.
30. Фримен А. ASP.NET MVC 5 с примерами на C# 5.0 для
профессионалов. 5-ое издание [Текст] – СПб.: «Питер», – 2018. – 735 с. Дата
обращения: 01.03.2020.
31. Хохлов А. Е. Основы программирование в среде «1С:
Предприятие»: Учебное пособие [Текст]:/ А. Е. Хохлов, Е. М. Голобокова, Ю.В.
Терякова – Пенза: Изд-во Пенз. гос. ун-та, 2015. – 144 с. Дата обращения:
29.05.2020.
32. Хрусталева Е. Ю. Разработка сложных отчетов в 1С: Предприятии
8. Система компоновки данных. [Текст] – М.: «1С-Паблишинг», – 2015. – 485 с.
Дата обращения: 31.05.2020.
33. Хрусталева Е. Ю. Язык запросов 1С: Предприятия 8. Фирма «1С»
[Текст]: под редакцией Максима Радченко. – 2015. – 358 с. Дата обращения:
31.05.2020.
34. Хрусталева Е. Ю. 101 совет начинающим разработчикам в системе
1С. Предприятие 8 [Текст]: под редакцией Максима Радченко. – 2015. – 284 с.
Дата обращения: 16.05.2020.
35. Положение о требованиях к оформлению отчетов по практике,
контрольных, курсовых, выпускных квалификационных работ [Текст]: Учебное
пособие / П.7.5-14-2016. (соглас. С.А. Рогожин), – 2016. – 17 c. Дата обращения:
01.06.2020.
36. Единый государственный реестр юридических лиц [Электронный
ресурс]. – Режим доступа: https://egrul.nalog.ru/index.html, свободный. Дата
обращения: 19.03.2020.
37. Официальный сайт фирмы «1С» [Электронный ресурс]. – Режим
доступа: http://v8.1c.ru/info/about_1c.html, свободный. Дата обращения:
15.05.2020.
68
38. Сайт программного обеспечения «IT-Invent» [Электронный ресурс].
– Режим доступа: http://it-invent.ru/, свободный. Дата обращения: 22.03.2020.
39. Сайт программного обеспечения «Hardware Inspector»
[Электронный ресурс]. – Режим доступа: http://www.hwinspector.com/,
свободный. Дата обращения: 22.03.2020.
40. Сайт программного обеспечения «10-Страйк: Инвентаризация
Компьютеров» [Электронный ресурс]. – Режим доступа: https://www.10-
strike.ru/, свободный. Дата обращения: 22.03.2020.
41. Сайт программного обеспечения «Учет компьютеров»
[Электронный ресурс]. – Режим доступа:
https://http://www.prostoysoft.ru/CompCount.html, свободный. Дата обращения:
22.03.2020.
42. Сайт программного обеспечения «Управление IT-отделом 8»
[Электронный ресурс]. – Режим доступа: https://softonit.ru/catalog/products/it/,
свободный. Дата обращения: 22.03.2020.

69
ПРИЛОЖЕНИЕ А

Листинг кода Home-контроллера HomeController.cs


using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Data.Entity;
using System.Data.Entity.Migrations;
using SystemForTesting.Models;

namespace SystemForTesting.Controllers
{
//Любой контроллер всегда наследуется от Controller
public class HomeController : Controller
{
private InputContext db = new InputContext();

//Выводит все входные данные из бд и преобразует в отчёт в виде списка, который передаётся в
представление
public ActionResult Index()
{
var inputs = db.Inputs.Select(x => new
{
x.Id,
x.ServiceModel.Service,
x.TestNameModel.TestName,
x.ScenarioModel.Scenario,
x.MethodNameModel.MethodName,
x.MethodStatusModel.MethodStatus,
}
).ToList();
var inputsEnd = new List<InputModel>();

foreach (var input in inputs)


{
inputsEnd.Add(new InputModel()
{
Id = input.Id,
ServiceModel = new ServiceModel()
{
Service = input.Service
},
TestNameModel = new TestNameModel()
{
TestName = input.TestName
},
ScenarioModel = new ScenarioModel()
{
Scenario = input.Scenario
},
70
MethodNameModel = new MethodNameModel()
{
MethodName = input.MethodName
},
MethodStatusModel = new MethodStatusModel()
{
MethodStatus = input.MethodStatus
}
});
}
return View(inputsEnd);
}

//Получает список сервисов


[HttpGet]
public ActionResult Create()
{
// Формируем список сервисов для передачи в представление
SelectList inputs = new SelectList(db.Services, "ServiceModelId", "Service");
ViewBag.Services = inputs;
return View();
}

//Формирует список сервисов


[HttpPost]
public ActionResult Create(InputModel inputModel)
{
//Добавляет тест в таблицу
if (inputModel.ServiceModel.ServiceList == ServiceList.TaxcomScanner)
inputModel.ServiceModel.Service = "Такском Сканер";
else if (inputModel.ServiceModel.ServiceList == ServiceList.TaxcomInformationService)
inputModel.ServiceModel.Service = "Такском Система Информирования";
else if (inputModel.ServiceModel.ServiceList == ServiceList.TaxcomVetis)
inputModel.ServiceModel.Service = "Такском Ветис";
else
inputModel.ServiceModel.Service = "Такском Кассы";

db.Inputs.Add(inputModel);
db.SaveChanges();
// перенаправляет на главную страницу
return RedirectToAction("Index");
}

[HttpGet]
public ActionResult Edit(int? id)
{
if (id == null)
{
return HttpNotFound();
}
// Находим в бд автотест
InputModel inputModel = db.Inputs.Find(id);

71
var inputsEdit = db.Inputs.Where(x => x.Id == id).Select(x => new
{
x.Id,
x.ServiceModel.Service,
x.ServiceModel.ServiceModelId,
x.TestNameModel.TestName,
x.TestNameModel.TestNameModelId,
x.ScenarioModel.Scenario,
x.ScenarioModel.ScenarioModelId,
x.MethodNameModel.MethodName,
x.MethodNameModel.MethodNameModelId,
x.MethodStatusModel.MethodStatus,
x.MethodStatusModel.MethodStatusModelId,
}
).FirstOrDefault();

if (inputsEdit == null)
{
return HttpNotFound();
}

var inputEnd = new InputModel()


{
Id = inputsEdit.Id,
ServiceModel = new ServiceModel()
{
Service = inputsEdit.Service,
ServiceModelId = inputsEdit.ServiceModelId,
ServiceList = ServiceList.TaxcomCashdesk
},
TestNameModel = new TestNameModel()
{
TestName = inputsEdit.TestName,
TestNameModelId = inputsEdit.TestNameModelId
},
ScenarioModel = new ScenarioModel()
{
Scenario = inputsEdit.Scenario,
ScenarioModelId = inputsEdit.ScenarioModelId
},
MethodNameModel = new MethodNameModel()
{
MethodName = inputsEdit.MethodName,
MethodNameModelId = inputsEdit.MethodNameModelId
},
MethodStatusModel = new MethodStatusModel()
{
MethodStatus = inputsEdit.MethodStatus,
MethodStatusModelId = inputsEdit.MethodStatusModelId
}
};
72
if (inputsEdit.Service == "Такском Сканер")
{
inputEnd.ServiceModel.ServiceList = ServiceList.TaxcomScanner;
}
else if (inputsEdit.Service == "Такском Система Информирования")
{
inputEnd.ServiceModel.ServiceList = ServiceList.TaxcomInformationService;
}
else if (inputsEdit.Service == "Такском Ветис")
{
inputEnd.ServiceModel.ServiceList = ServiceList.TaxcomVetis;
}
else
{
inputEnd.ServiceModel.ServiceList = ServiceList.TaxcomCashdesk;
}

// Создаем список автотестов для передачи в представление


SelectList inputs = new SelectList(db.Inputs, "Id", "Service", inputModel.ServiceModelId);
ViewBag.Inputs = inputs;
return View(inputEnd);
}

[HttpPost]
public ActionResult Edit(InputModel inputModel)
{
if (inputModel.ServiceModel.ServiceList == ServiceList.TaxcomScanner )
{
inputModel.ServiceModel.Service = "Такском Сканер";
}
else if (inputModel.ServiceModel.ServiceList == ServiceList.TaxcomInformationService )
{
inputModel.ServiceModel.Service = "Такском Система Информирования";
}
else if (inputModel.ServiceModel.ServiceList == ServiceList.TaxcomVetis )
{
inputModel.ServiceModel.Service = "Такском Ветис";
}
else
{
inputModel.ServiceModel.Service = "Такском Кассы";
}

var service = db.Services.FirstOrDefault(x => x.ServiceModelId ==


inputModel.ServiceModel.ServiceModelId);

if (service != null)
{
service.Service = inputModel.ServiceModel.Service;
db.Set<ServiceModel>().AddOrUpdate(service);
db.SaveChanges();
}

73
var testName = db.TestNames.FirstOrDefault(x => x.TestNameModelId ==
inputModel.TestNameModel.TestNameModelId);

if (testName != null)
{
testName.TestName = inputModel.TestNameModel.TestName;
db.Set<TestNameModel>().AddOrUpdate(testName);
db.SaveChanges();
}

var scenario = db.Scenarios.FirstOrDefault(x => x.ScenarioModelId ==


inputModel.ScenarioModel.ScenarioModelId);

if (scenario != null)
{
scenario.Scenario = inputModel.ScenarioModel.Scenario;
db.Set<ScenarioModel>().AddOrUpdate(scenario);
db.SaveChanges();
}

var methodName = db.MethodNames.FirstOrDefault(x => x.MethodNameModelId ==


inputModel.MethodNameModel.MethodNameModelId);

if (methodName != null)
{
methodName.MethodName = inputModel.MethodNameModel.MethodName;
db.Set<MethodNameModel>().AddOrUpdate(methodName);
db.SaveChanges();
}

var methodStatus = db.MethodStatuses.FirstOrDefault(x => x.MethodStatusModelId ==


inputModel.MethodStatusModel.MethodStatusModelId);

if (methodStatus != null)
{
methodStatus.MethodStatus = inputModel.MethodStatusModel.MethodStatus;
db.Set<MethodStatusModel>().AddOrUpdate(methodStatus);
db.SaveChanges();
}

return RedirectToAction("Index");
}

// Метод удаления теста из БД


public ActionResult Delete(int? id)
{
if (id == null)
{
return HttpNotFound();
}
// Находим в БД тест
InputModel inputModel = db.Inputs.Find(id);
if (inputModel != null)
74
{
// Удаляем из БД тест
db.Inputs.Remove(inputModel);
// Сохраняем изменения удаления
db.SaveChanges();
}

return RedirectToAction("Index");
}

//Метод отчёта, который извлекает из БД данные и высчитывает процент покрытия автотестами


public ActionResult About()
{
//Извлекает из БД из каждой из таблиц данные
var inputs = db.Inputs.Select(x => new
{
x.Id,
x.ServiceModel.Service,
x.TestNameModel.TestName,
x.ScenarioModel.Scenario,
x.MethodNameModel.MethodName,
x.MethodStatusModel.MethodStatus,
}
).ToList(); //Извлечённые из БД данные передаются в коллекцию List
var inputsEnd = new List<InputModel>();
//Цикл "пробегает" по всем данным коллекции
foreach (var input in inputs)
{
var tempInput = new InputModel()
{
Id = input.Id,
ServiceModel = new ServiceModel()
{
Service = input.Service
},
TestNameModel = new TestNameModel()
{
TestName = input.TestName
},
ScenarioModel = new ScenarioModel()
{
Scenario = input.Scenario
},
MethodNameModel = new MethodNameModel()
{
MethodName = input.MethodName
},
MethodStatusModel = new MethodStatusModel()
{
MethodStatus = input.MethodStatus
}
};
inputsEnd.Add(tempInput);
75
if (input.Service == "Такском Сканер")
{
tempInput.ServiceModel.ServiceList = ServiceList.TaxcomScanner;
}
else if (input.Service == "Такском Система Информирования")
{
tempInput.ServiceModel.ServiceList = ServiceList.TaxcomInformationService;
}
else if (input.Service == "Такском Ветис")
{
tempInput.ServiceModel.ServiceList = ServiceList.TaxcomVetis;
}
else
{
tempInput.ServiceModel.ServiceList = ServiceList.TaxcomCashdesk;
}

int taxcomScannerTestCount = 0;
int taxcomInformationServiceTestCount = 0;
int taxcomVetisTestCount = 0;
int taxcomCashdeskTestCount = 0;

int taxcomScannerCoveredCount = 0;
int taxcomInformationCoveredCount = 0;
int taxcomVetisCoveredCount = 0;
int taxcomCashdeskCoveredCount = 0;

foreach (var input in inputsEnd)


{
switch (input.ServiceModel.ServiceList)
{
case ServiceList.TaxcomScanner:
taxcomScannerTestCount++;
if (input.ScenarioModel.Scenario)
{
taxcomScannerCoveredCount++;
}
break;
case ServiceList.TaxcomInformationService:
taxcomInformationServiceTestCount++;
if (input.ScenarioModel.Scenario)
{
taxcomInformationCoveredCount++;
}
break;
case ServiceList.TaxcomVetis:
taxcomVetisTestCount++;
if (input.ScenarioModel.Scenario)
{
taxcomVetisCoveredCount++;
76
}
break;
case ServiceList.TaxcomCashdesk:
taxcomCashdeskTestCount++;
if (input.ScenarioModel.Scenario)
{
taxcomCashdeskCoveredCount++;
}
break;
default:
throw new ArgumentOutOfRangeException();
}
}

//Тернарный оператор предназначен для высчитывания процента покрытия автотестами


var taxcomScannerCoverage = taxcomScannerTestCount == 0
?0
: (float) taxcomScannerCoveredCount / taxcomScannerTestCount * 100;
var taxcomInformationServiceCoverage = taxcomInformationServiceTestCount == 0
?0
: (float) taxcomInformationCoveredCount / taxcomInformationServiceTestCount * 100;
var taxcomVetisCoverage = taxcomVetisTestCount == 0
?0
: (float) taxcomVetisCoveredCount / taxcomVetisTestCount * 100;
var taxcomCashdeskCoverage = taxcomCashdeskTestCount == 0
?0
: (float) taxcomCashdeskCoveredCount / taxcomCashdeskTestCount * 100;

var reportModel = new List<ReportModel>();


reportModel.Add(new ReportModel()
{
Service = ServiceList.TaxcomScanner,
TestCoverage = $"{taxcomScannerCoverage} %"
});
reportModel.Add(new ReportModel()
{
Service = ServiceList.TaxcomInformationService,
TestCoverage = $"{taxcomInformationServiceCoverage} %"
});
reportModel.Add(new ReportModel()
{
Service = ServiceList.TaxcomVetis,
TestCoverage = $"{taxcomVetisCoverage} %"
});
reportModel.Add(new ReportModel()
{
Service = ServiceList.TaxcomCashdesk,
TestCoverage = $"{taxcomCashdeskCoverage} %"
});

return View(reportModel);
}

77
//Переопределённый метод Dispose уничтожает временные данные
protected override void Dispose(bool disposing)
{
db.Dispose();
base.Dispose(disposing);
}
}
}

78
ПРИЛОЖЕНИЕ Б

Листинг кода вспомогат. метода helper’a HtmlDropDownExtensions.cs


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;
using System.Web;
using System.Web.Mvc;
using System.Web.Mvc.Html;

namespace SystemForTesting.Helpers
{
public static class HtmlDropDownExtensions
{
public static MvcHtmlString DropdownForEnum<TModel>(this HtmlHelper<TModel> helper, Type type,
string name, string optionLabel, object htmlAttributes)
{
if (!type.IsEnum) throw new ArgumentException("type must be that of an enum", "type");

var dictionary = new Dictionary<string, string>();

var values = type.GetEnumValues();

foreach (var val in values)


{
dictionary.Add(
val.ToString(),
type.GetDescriptionForEnum(val)
);
}

return helper.DropDownList(name, dictionary.ToSelectList(string.Empty), optionLabel, htmlAttributes);


}

public static SelectList ToSelectList(this IDictionary<string, string> dictionary, object selectedValue)


{
return new SelectList(dictionary, "Key", "Value", selectedValue);
}

/// <summary>
/// Gets the DescriptionAttribute valud of an enum value, if none are found uses the string version of the specified value
/// </summary>
public static string GetDescription(this Enum value)
{
Type type = value.GetType();

return GetEnumDescription(value.ToString(), type);


}

public static string GetDescriptionForEnum(this Type type, object value)


79
{
return GetEnumDescription(value.ToString(), type);
}

private static string GetEnumDescription(string value, Type type)


{
MemberInfo[] memberInfo = type.GetMember(value);

if (memberInfo != null && memberInfo.Length > 0)


{
// default to the first member info, it's for the specific enum value
var info = memberInfo.First().GetCustomAttributes(typeof(DescriptionAttribute), false).FirstOrDefault();

if (info != null)
return ((DescriptionAttribute)info).Description;
}

// no description - return the string value of the enum


return value;
}
}
}

80
ПРИЛОЖЕНИЕ В

Листинг кода контекста базы данных InputContext.cs


using System;
using System.Collections.Generic;
using System.Data.Entity;
using System.Linq;
using System.Web;
using System.Web.Services.Description;

namespace SystemForTesting.Models
{
public class InputContext : DbContext
{
public DbSet<InputModel> Inputs { get; set; }

public DbSet<ServiceModel> Services { get; set; }

public DbSet<TestNameModel> TestNames { get; set; }

public DbSet<ScenarioModel> Scenarios { get; set; }

public DbSet<MethodNameModel> MethodNames { get; set; }

public DbSet<MethodStatusModel> MethodStatuses { get; set; }

}
}

81
ПРИЛОЖЕНИЕ Г

Листинг кода модели основной таблицы InputModel.cs


using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Linq;
using System.Web;

namespace SystemForTesting.Models
{
public class InputModel
{
public int Id { get; set; }

public int ServiceModelId { get; set; }


public ServiceModel ServiceModel { get; set; }

public int TestNameModelId { get; set; }


public TestNameModel TestNameModel { get; set; }

public int ScenarioModelId { get; set; }


public ScenarioModel ScenarioModel { get; set; }

public int MethodNameModelId { get; set; }


public MethodNameModel MethodNameModel { get; set; }

public int MethodStatusModelId { get; set; }


public MethodStatusModel MethodStatusModel { get; set; }
}
}

82
ПРИЛОЖЕНИЕ Д

Листинг кода таблицы-справочника MethodNameModel.cs


using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Linq;
using System.Web;

namespace SystemForTesting.Models
{
public class MethodNameModel
{
public int MethodNameModelId { get; set; }

[Required]
[MinLength(1)]
[Display(Name = "Название метода")]
[StringLength(255)]
public string MethodName { get; set; }

public ICollection<InputModel> InputModel { get; set; }


}
}

83
ПРИЛОЖЕНИЕ Е

Листинг кода таблицы-справочника MethodStatusModel.cs


using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Linq;
using System.Web;

namespace SystemForTesting.Models
{
public class MethodStatusModel
{

public int MethodStatusModelId { get; set; }

[Display(Name = "Статус метода ПОЗИТИВНЫЙ")]


public bool MethodStatus { get; set; }

public ICollection<InputModel> InputModel { get; set; }


}
}

84
ПРИЛОЖЕНИЕ Ж

Листинг кода модели отчёта ReportModel.cs


using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using System.Web;

namespace SystemForTesting.Models
{
public class ReportModel
{
[Display(Name = "Сервис")]
public ServiceList Service { get; set; }

[Display(Name = "Процент покрытия автоматизированными тестами")]


public string TestCoverage { get; set; }
}
}

85
ПРИЛОЖЕНИЕ И

Листинг кода таблицы-справочника ScenarioModel.cs


using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Linq;
using System.Web;

namespace SystemForTesting.Models
{
public class ScenarioModel
{

public int ScenarioModelId { get; set; }

[Display(Name = "Сценарий ПОКРЫТ")]


public bool Scenario { get; set; }

public ICollection<InputModel> InputModel { get; set; }


}
}

86
ПРИЛОЖЕНИЕ К

Листинг кода перечисления ВЕБ-сервисов ServiceList.cs

using System.ComponentModel;
using System.ComponentModel.DataAnnotations;

namespace SystemForTesting.Models
{
public enum ServiceList
{
[Display(Name = "Такском Сканер")]
TaxcomScanner,

[Display(Name = "Такском Система Информирования")]


TaxcomInformationService,

[Display(Name = "Такском Ветис")]


TaxcomVetis,

[Display(Name = "Такском Кассы")]


TaxcomCashdesk
}
}

87
ПРИЛОЖЕНИЕ Л

Листинг кода таблицы-справочника ServiceModel.cs


using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Linq;
using System.Web;

namespace SystemForTesting.Models
{
public class ServiceModel
{

public int ServiceModelId { get; set; }

[Display(Name = "Сервис")]
public string Service { get; set; }

public ICollection<InputModel> InputModels { get; set; }

public ServiceList ServiceList { get; set; }

}
}

88
ПРИЛОЖЕНИЕ М

Листинг кода таблицы-справочника TestNameModel.cs


using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using System.Linq;
using System.Web;

namespace SystemForTesting.Models
{
public class TestNameModel
{

public int TestNameModelId { get; set; }

[MinLength(1)]
[Display(Name = "Название теста")]
[StringLength(255)]
public string TestName { get; set; }

public ICollection<InputModel> InputModel { get; set; }


}
}

89
ПРИЛОЖЕНИЕ Н

Листинг кода представления отчёта About.cshtml


@model IEnumerable<SystemForTesting.Models.ReportModel>

@{
ViewBag.Title = "About";
}
<h2>@ViewBag.Title.</h2>
<h3>@ViewBag.Message</h3>

@*<p>
@Html.ActionLink("Create New", "Create")
</p>*@
<table class="table">
<tr>
<th>
@Html.DisplayNameFor(model => model.Service)
</th>
<th>
@Html.DisplayNameFor(model => model.TestCoverage)
</th>
<th></th>
</tr>

@foreach (var item in Model)


{
<tr>
<td>
@Html.DisplayFor(modelItem => item.Service)
</td>
<td>
@Html.DisplayFor(modelItem => item.TestCoverage)
</td>
</tr>
}

</table>
<p></p>

90
ПРИЛОЖЕНИЕ О

Листинг кода представления Create.cshtml


@using SystemForTesting.Helpers
@model SystemForTesting.Models.InputModel

@{
ViewBag.Title = "Create";
}

<h2>Добавление нового автоматизированного теста</h2>

@using (Html.BeginForm())
{
<fieldset>
<legend>Автоматизированный тест</legend>

<p>
Описываемый автоматизированными тестами сервис <br />
@Html.EnumDropDownListFor(model => model.ServiceModel.ServiceList)

</p>

<p>
Название автоматизированного теста <br />
@Html.TextBoxFor(model => model.TestNameModel.TestName, new { style = "width:1000px" })
</p>

<p>
Сценарий метода автоматизированного теста ПОКРЫТ<br />
@Html.EditorFor(model => model.ScenarioModel.Scenario)
</p>

<p>
Название метода автоматизированного теста <br />
@Html.TextBoxFor(model => model.MethodNameModel.MethodName, new { style = "width:1000px" })
</p>

<p>
Статус автоматизированного теста ПОЗИТИВНЫЙ <br />
@Html.EditorFor(model => model.MethodStatusModel.MethodStatus)
</p>

<p>
<input type="submit" value="Добавить автоматизированный тест" />
</p>
</fieldset>
}
<div>
@Html.ActionLink("К списку автоматизированных тестов", "Index")

91
</div>

92
ПРИЛОЖЕНИЕ П

Листинг кода представления Edit.cshtml


@model SystemForTesting.Models.InputModel

@{
ViewBag.Title = "Edit";
}

<h2>Редактирование автоматизированного теста</h2>

@using (Html.BeginForm())
{
<fieldset>
<legend>Автоматизированный тест</legend>
@Html.HiddenFor(model => model.Id)
@Html.HiddenFor(model => model.ServiceModel.ServiceModelId)
@Html.HiddenFor(model => model.TestNameModel.TestNameModelId)
@Html.HiddenFor(model => model.ScenarioModel.ScenarioModelId)
@Html.HiddenFor(model => model.MethodNameModel.MethodNameModelId)
@Html.HiddenFor(model => model.MethodStatusModel.MethodStatusModelId)
<p>
Описываемый автоматизированными тестами сервис <br />
@Html.EnumDropDownListFor(model => model.ServiceModel.ServiceList)
</p>

<p>
Название автоматизированного теста <br />
@Html.TextBoxFor(model => model.TestNameModel.TestName, new { style = "width:1000px" })
</p>

<p>
Сценарий автоматизированного теста ПОЗИТИВНЫЙ <br />
@Html.EditorFor(model => model.ScenarioModel.Scenario)
</p>

<p>
Название метода автоматизированного теста <br />
@Html.TextBoxFor(model => model.MethodNameModel.MethodName, new { style = "width:1000px" })
</p>

<p>
Статус метода автоматизированного теста ПОКРЫТ<br />
@Html.EditorFor(model => model.MethodStatusModel.MethodStatus)
</p>

<p>
<input type="submit" value="Сохранить изменения" />
</p>
</fieldset>
}
<div>
93
@Html.ActionLink("К списку автоматизированных тестов", "Index")
</div>

94
ПРИЛОЖЕНИЕ Р

Листинг кода представления Index.cshtml


@model IEnumerable<SystemForTesting.Models.InputModel>

@{
ViewBag.Title = "Index";
}

<h2>Index</h2>

<p>
@Html.ActionLink("Create New", "Create")
</p>
<table class="table">
<tr>
<th>
@Html.DisplayNameFor(model => model.ServiceModel.Service)
</th>
<th>
@Html.DisplayNameFor(model => model.TestNameModel.TestName)
</th>
<th>
@Html.DisplayNameFor(model => model.ScenarioModel.Scenario)
</th>
<th>
@Html.DisplayNameFor(model => model.MethodNameModel.MethodName)
</th>
<th>
@Html.DisplayNameFor(model => model.MethodStatusModel.MethodStatus)
</th>
<th></th>
</tr>

@foreach (var item in Model)


{
<tr>
<td>
@Html.DisplayFor(modelItem => item.ServiceModel.Service)
</td>
<td>
@Html.DisplayFor(modelItem => item.TestNameModel.TestName)
</td>
<td>
@Html.DisplayFor(modelItem => item.ScenarioModel.Scenario)
</td>
<td>
@Html.DisplayFor(modelItem => item.MethodNameModel.MethodName)
</td>
<td>
@Html.DisplayFor(modelItem => item.MethodStatusModel.MethodStatus)
</td>
95
<td>
@Html.ActionLink("Edit", "Edit", new { id = item.Id }) |
@Html.ActionLink("Delete", "Delete", new { id = item.Id })
</td>
</tr>
}

</table>
ПРИЛОЖЕНИЕ С

РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

Информационная система «Система по информатизации тестирования


программного обеспечения» предназначена для хранения информации о
разработанных автоматизированных интеграционных тестах.
Для работы с информационной системой «Система по информатизации
тестирования программного обеспечения» необходимо наличие компьютера,
подключение к корпоративной сети, так программа находится на сервере.
Для начала работы необходимо в адресной строке перейти по
соответствующей ссылке, ведущей на домашнюю страницу информационной
системы, как указано на рисунке 27.

Рисунок 27 – Домашняя страница

96
После открывается ВЕБ-страница, на которой присутствуют следующие
элементы:
 «Домашняя страница» – для возврата на домашнюю страницу из
других разделов информационной системы;
 «Отчёт» - ВЕБ-страница с информацией о проценте покрытия
автоматизированными интеграционными тестами ВЕБ-сервисов
компании;
 «Create New» - кнопка для добавления нового автоматизированного
теста или программного метода.
При нажатии на кнопку «Create New» откроется форма, изображенная на
рисунке 28.

Рисунок 28 – «Добавление нового автоматизированного теста»


Прежде всего необходимо выбрать из выпадающего списка ВЕБ-сервис,
изображенный на рисунке 29.

97
Рисунок 29 – «Выпадающий список»

В поле «Название автоматизированного теста» следует его вписать при


наличии, в противном случае оставить поле пустым.
Флажок-чекбокс «Сценарий метода автоматизированного теста
ПОКРЫТ» устанавливается в том случае, если на программный метод
существует разработанный автоматизированный интеграционный тест.
В поле «Название метода автоматизированного теста» следует вписать
программный метод вне зависимости от того, покрыт он автоматизированным
тестом или нет.
Флажок-чекбокс «Статус автоматизированного теста ПОЗИТИВНЫЙ»
устанавливается в том случае, если автоматизированный интеграционный тест
является позитивным и не устанавливается, если тест является негативным.
Кнопка «Добавить автоматизированный тест» нужна для сохранения.
На рисунке 30 представлена домашняя страница с заполненной
информацией по автоматизированным интеграционным тестам и программным
методам

98
Рисунок 30 – Домашняя страница заполненная
Для удаления записи необходимо нажать на кнопку «Delete»
Для редактирования записи необходимо нажать на кнопку «Edit», после
чего откроется страница редактирования, изображенная на рисунке 31.

99
Рисунок 31 – Редактирование автоматизированного теста
После редактирования выпадающего списка, текста полей или смены
параметра флажка-чекбокса, для сохранения внесённых изменений необходимо
нажать на кнопку «Сохранить изменения»
Для просмотра отчёта о проценте покрытия ВЕБ-сервисов
автоматизированными интеграционными тестами, необходимо открыть
«Отчёт» и отобразится ВЕБ-страница, изображённая на рисунке 32.

100
Рисунок 32 – «Отчёт»

101