5. Состав и содержание работ по созданию подсистемы

Таблица 1 – Наименование и сроки выполнения работ

№ п/п	Наименование этапов дипломного проекта (работы)	Срок выполнения этапов проекта (работы)
1.	Выбор темы проекта. Выработка целей и задач проекта. Определение основных результатов проекта	10.02.2014
2.	Формирование требований к подсистеме. Разработка концепции подсистемы.	20.02.2014
3.	Разработка технического задания	10.03.2014
4.	Проектирование архитектуры решения.	10.04.2014
5.	Разработка алгоритмов. Проектирование пользовательского графического интерфейса.	01.05.2014
6.	Разработка структуры программных классов.	10.05.2014
7.	Завершение разработки проекта. Тестирование и приемосдаточные испытания решения. Оформление работы. Разработка демонстрационных материалов	26.06.2014
8.	Предзащита проекта	По приказу
9.	Защита проекта	По приказу

6. Порядок контроля и приемки подсистемы

Порядок контроля и приемки подсистемы указан в календарном плане.

АИП должна быть спроектирована до 06.06.2014г. При этом должны быть составлены техническое задание, технический проект, рабочий проект и окончательный вариант готовой подсистемы. В течение этого срока необходима периодическая сдача проектной документации и демонстрация прототипов программы.

Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии. Все создаваемые в рамках настоящей работы программные изделия (за исключением покупных) передаются Заказчику, как в виде готовых модулей, так и в виде исходных кодов, представляемых в электронной форме на стандартном машинном носителе (например, на компакт-диске).

4. ТЕХНИЧЕСКИЙ ПРОЕКТ

   1. Общесистемные решения

Схема функциональной структуры

С подсистемой взаимодействуют следующие действующие лица:

• Тест-аналитик. Пользуется отчетами «Динамика выполнения работ» и «Непроходимость». На основании первого он делает выводы о дополнении тестового плана новыми тестовыми сценариями. Данные второго отчета помогают тест аналитику сделать выводы о полезности имеющихся тестов.

• Тест-программист. Ему интересны отчеты «Время прохождения» и «Непроходимость». Отчет «Время прохождения тестов» необходим для принятия решения о доработке скриптов тестов или тестовых сценариев, а также о правильности тестового плана. Отчет «Непроходимость» предоставляет тест-программисту информацию о плодотворности разбора логов, о тестах, на которые нужно обратить особое внимание.

• Тест-менеджер. Он пользуется отчетами: «Непроходимость», «Время прохождения», «Динамика выполнения работ» – которые позволяют ему контролировать работу команды специалистов тестирования и следить за актуальностью тестового покрытия.

• Начальник отдела анализа и развития. Он использует отчеты «Непроходимость», «Время прохождения», отчет «Состояние релиза», с помощью которых он следит за работой отдела тестирования и рекомендацией релиза.

• Менеджер проекта. Его главным образом интересуют отчеты «Состояние релиза» и «Ошибки с массовыми падениями», на основании данных которых он делает выводы о состоянии проекта.

Для иллюстрации способов взаимодействия пользователей с подсистемой ниже приведена диаграмма вариантов использования на (Рисунок 3):

Рисунок 3 - Диаграмма вариантов использования

Подробное описание каждого варианта использования будет приведено далее.

Описание автоматизируемых функций

Построить отчет «Состояние релиза»

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

Алгоритм построения данного отчета описан на диаграмме деятельности (Рисунок 4):

Рисунок 4 - Диаграмма деятельности построения отчета «Состояние релиза»

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

Построить отчет «Динамика выполнения работ»

Отчет «Динамика выполнения работ» представляет информацию о количестве работ выполненных в указанном периоде, об ответственных за эти работы, о приоритетности этих работ и для наглядности представляет на диаграмме продолжительность выполнения работ.

Алгоритм построения данного отчета описан на диаграмме деятельности (Рисунок 5):

Рисунок 5 - Диаграмма деятельности построения отчета «Динамика выполнения работ»

При запуске отчета подсистема предлагает пользователю ввести параметры построения отчета: период, за который будет строиться отчет, релиз и/или тест, продолжительность, приоритеты и состояния. После проверки корректности введенных значений параметров подсистема обращается к базе данных для получения списка работ по выбранным значениям параметров. Затем данные объединяются в сводную таблицу и строится диаграмма Продолжительность работ.

Построить отчет «Ошибки с массовыми падениями»

Отчет об ошибках с массовыми падениями представляет собой список работ, по которым было обнаружено падение тестов. В этом списке отображается количество работ, дата создания работы, ее состояние, приоритет и само количество падений тестов.

Алгоритм построения данного отчета описан на диаграмме деятельности (Рисунок 6):

Рисунок 6 - Диаграмма деятельности построения отчета «Ошибки с массовыми падениями»

При запуске отчета подсистема предлагает пользователю ввести период, за который будут искаться работы, минимальное количество падений тестов (по умолчанию оно = 0) и параметры работ: автора, исполнителя, менеджера, состояние, приоритет, которые не обязательны для заполнения, но помогут отсеять лишние результаты при поиске необходимых работ. Подсистема проверяет корректность введенного периода, запрашивает из базы данных указанные параметры и строит по ним отчет.

Построить отчет «Время прохождения»

Отчет «Время прохождения» имеет 2 режима:

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

• сравнивает время прохождения тестов двух выбранных релизов за разные даты и строит график, на котором отображается разница во времени в положительную сторону и отрицательную (в зависимости от того быстрее или медленнее стали проходить тесты).

Алгоритм построения данного отчета описан на диаграмме деятельности (Рисунок 7):

Рисунок 7 - Диаграмма деятельности построения отчета «Время прохождения»

В зависимости от выбранного режима работы подсистема предлагает пользователю ввести данные для первого релиза или и для первого, и для второго (в случае с режимом сравнения). Затем она проверяет наличие логов с указанными параметрами и также в зависимости от выбранного режима выводит список тестов, их продолжительность, разницу между временем прохождения (в случае с режимом сравнения) и строит диаграмму, наглядно отображающую продолжительность прохождения каждого теста.

Построить отчет «Непроходимость»

Отчет «Непроходимость» предоставляет информацию о результатах прохождения и разбора тестов выбранного релиза за определенный период, а также общее количество падений и состояния проверки для отдельного теста, отдельного релиза или отдельного теста отдельного релиза. Он также предлагает возможность отсеять количество падений тестов режимами Больше\равно или Меньше\равно.

Алгоритм построения данного отчета описан на диаграмме деятельности (Рисунок 8):

Рисунок 8 - Диаграмма деятельности построения отчета «Непроходимость»

Программа и методика испытаний

Объект испытаний

Предварительные испытания проводятся для всей разработанной информационной подсистемы согласно ГОСТ 34.603-92 и являются комплексными.

Цель испытаний

Целью проведения испытаний является проверка работоспособности подсистемы в целом и ее отдельных задач.

Объем испытаний

Перечень функций системы, подлежащих испытаниям, приведён в таблице 1:

Таблица 2 - Перечень функций системы, подлежащих испытаниям

№ п/п	Функция	Контролируемый объект	Контроль выходных данных
11	Построить отчет «Состояние релиза»	Подсистема EasyAnalitic	отчет «Состояние релиза»
22	Построить отчет «Динамика выполнения работ»	Подсистема EasyAnalitic	отчет «Динамика выполнения работ»
33	Построить отчет «Ошибки с массовыми падениями»	Подсистема EasyAnalitic	отчет «Ошибки с массовыми падениями»
4	Построить отчет «Время прохождения»	Подсистема EasyAnalitic	отчет «Время прохождения» в двух режимах: для одного релиза и для режима сравнения двух релизов
5	Построить отчет «Непроходимость»	Подсистема EasyAnalitic	отчет «Непроходимость»

Условия и порядок проведения испытаний

Для проведения испытаний создается контрольный пример.

Описание контрольного примера

Оценить работоспособность подсистемы можно с помощью описанного ниже контрольного примера.

Запуская подсистему из основной системы Центр управления тестированием, выбрать пункт Отчеты (Рисунок 9):

Рисунок 9 – Меню основного приложения

Для построения отчета «Состояние релиза» выбрать соответствующий пункт, после чего появится окно с настройкой необходимых параметров (Рисунок 10):

Рисунок 10 – Настройки отчета «Состояние Релиза»

Дата, указанная в будущем вызовет ошибку, значения параметров Релиз и состояния тестов подчиняются правилу: если для параметра можно выбрать несколько значений, то отсутствие выбранных значений параметра приравнивается к тому, что выбраны все значения параметра. Если подсистема не найдет логи по выбранным параметрам, то появится ошибка, сообщающая об отсутствии логов. Иначе строится отчет (Рисунок 11):

Рисунок 11– Отчет «Состояние релиза»

Для просмотра результатов ночного прогона нужно открыть соответствующую вкладку на графике (Рисунок 12):

Рисунок 12 – Диаграмма состояния релиза за ночной прогон

Для построения отчета «Динамика выполнения работ» выбрать соответствующий пункт, после чего появится окно с настройкой необходимых параметров (Рисунок 13)

Рисунок 13 – Настройка отчета «Динамика выполнения работ»

Указание даты окончания периода меньше даты начала периода вызовет ошибку. Параметры Релиз/Тест могут быть указаны по отдельности, могут вместе, но оба пустыми быть не могут, подсистема на это также реагирует сообщением об ошибке. Поле указания диапазона также не принимает отрицательных чисел, и минимальная граница диапазона больше максимальной вызовет сообщение об ошибке. Параметры Состояния и Приоритеты не являются обязательными и подчиняются правилу: если для параметра можно выбрать несколько значений, то отсутствие выбранных значений параметра приравнивается к тому, что выбраны все значения параметра.

При успешном вводе параметров выводится отчет (Рисунок 14):

Рисунок 14 – Отчет «Динамика выполнения работ»

Для построения отчета «Ошибки с массовыми падениями» выбрать соответствующий пункт, после чего появится окно с настройкой необходимых параметров (Рисунок 15)

Рисунок 15 – Настройка отчета «Ошибки с массовыми падениями»

Указание даты окончания периода меньше даты начала периода вызовет ошибку. Параметры: Менеджер, Автор, Исполнитель, Приоритет, Состояние - не являются обязательными и подчиняются правилу: если для параметра можно выбрать несколько значений, то отсутствие выбранных значений параметра приравнивается к тому, что выбраны все значения параметра.

Будет выведена таблица с результатами (Рисунок 16) :

Рисунок 16 – Отчет «Ошибки с массовыми падениями»

Для построения отчета «Время прохождения» выбрать соответствующий пункт, после чего появится окно с настройкой необходимых параметров (Рисунок 17):

Рисунок 17 - Настройки отчета «Время прохождения» в режиме просмотра времени прохождения для одного релиза

Флаг Сравнить с результатом на другую дату позволяет ввести дополнительные параметры (Рисунок 18):

Рисунок 18 - Настройки отчета «Время прохождения» в режиме сравнения двух релизов

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

При наличии логов с указанными настройками параметров для первого релиза в режиме показа времени прохождения для одного релиза появится отчет (Рисунок 19):

Рисунок 19 - Отчет «Время прохождения» в режиме просмотра времени прохождения для одного релиза

И для режима сравнения (Рисунок 20):

Рисунок 20 - Отчет «Время прохождения» в режиме сравнения двух релизов

На графике отклонения влево показывают замедление прохождения тестов, отклонения вправо – ускорение прохождения тестов. В сводной таблице отчета замедление выделено красным, ускорение – зеленым.

Для построения отчета «Непроходимость» выбрать соответствующий пункт, после чего появится окно с настройкой необходимых параметров (Рисунок 21):

Рисунок 21 - Настройки отчета «Непроходимость»

Указание даты окончания периода меньше даты начала периода вызовет ошибку. Поле Релиз является обязательным для построения отчета, и его незаполненность вызовет ошибку. Параметр Количество падений ( по умолчанию режим Больше/Равно 5) так же является обязательным.

После проверки на наличие логов с заданными параметрами строится отчет (Рисунок 22):

Рисунок 22 - Отчет «Непроходимость»