Автоматизация процесса обработки результатов тестирования

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

Ивановский государственный химико-технологический университет

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

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К ДИПЛОМНОМУ ПРОЕКТУ НА ТЕМУ:

Автоматизация процесса обработки результатов тестирования

СтудентСтанкова Н.М.

Руководитель: Ястребцев О.Н.

Зав.кафедрой:Бобков С.П.

Иваново 2014



Реферат

Пояснительная записка 75 с., 23 рис., 9 табл., 5 частей, 11 источников.

Перечень ключевых слов: тест, тестирование, прохождение, релиз, отчет..

Целью разработки АИП являлись:

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

- повышение качества принятия управленческих решений за счет оперативности представления, полноты, достоверности и удобства форматов отображения информации;

- повышение информационной открытости и прозрачности деятельности отдела тестирования, повышение удобства и комфорта руководящих лиц при получении информации о деятельности отдела.

Процесс разработки описан с помощью методологии UML объектно-ориентированного подхода.

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

Приложение реализовано в среде программирования Microsoft Visual Studio 2010 на языке C++, база данных - с помощью СУБД MongoDB 2.4.

связь информационный база файл



Содержание

• Определения
• Обозначения и сокращения
• Введение
• 1. Формирование требований к ИС
• 1.1 Обследование объекта автоматизации
• 1.2 Формирование требований пользователя к ИС
• 2. Разработка концепции подсистемы
• 3. Техническое задание
• 3.1 Общие положения
• 3.1.1 Полное наименование подсистемы и ее условное обозначение
• 3.1.2 Наименование организации заказчика и участников работ
• 3.1.3 Перечень документов, на основании которых создается подсистема
• 3.1.4 Плановые сроки начала и окончания работы по созданию подсистемы
• 3.1.5 Источники и порядок финансирования работ
• 3.1.6 Порядок оформления и предъявления заказчику результатов работ по созданию подсистемы
• 3.2 Назначение и цели создания подсистемы
• 3.2.1 Назначение подсистемы
• 3.2.2 Цели подсистемы
• 3.3 Характеристика объекта автоматизации
• 3.4 Требования к подсистеме
• 3.4.1 Требования к подсистеме в целом
• 3.4.1.1 Требования к структуре и функционированию подсистемы
• 3.4.1.1.1 Перечень модулей, их назначение и основные характеристики
• 3.4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы
• 3.4.1.1.3 Требования к режимам функционирования подсистемы
• 3.4.1.1.4 Перспективы развития, модернизации подсистемы
• 3.4.1.2 Требования к численности и квалификации персонала подсистемы
• 3.4.1.2 Показатели назначения
• 3.4.1.3 Требования к надежности
• 3.4.1.4 Требования к безопасности
• 3.4.1.5 Требования к эргономике и технической эстетике
• 3.4.1.6 Требования к транспортабельности для подвижных ИС
• 3.4.1.7 Требования к защите информации от несанкционированного доступа
• 3.4.1.8 Требования по сохранности информации при авариях
• 3.4.1.9 Требования к патентной чистоте
• 3.4.1.10 Требования к защите от внешних влияний
• 3.4.2 Требования к функциям подсистемы
• 3.4.3 Требования к видам обеспечения
• 3.4.3.1 Требования к математическому обеспечению подсистемы
• 3.4.3.2 Требования к информационному обеспечению подсистемы
• 3.5 Требования к лингвистическому обеспечению подсистемы
• 3.6 Требования к программному обеспечению подсистемы
• 3.7 Требования к техническому обеспечению
• 3.8 Требования к организационному обеспечению
• 3.9 Требования к методическому обеспечению
• 3.10 Состав и содержание работ по созданию подсистемы
• 3.11 Порядок контроля и приемки подсистемы
• 4. Технический проект
• 4.1 Общесистемные решения
• 4.1.1 Схема функциональной структуры
• 4.1.2 Описание автоматизируемых функций
• 4.1.3 Программа и методика испытаний
• 4.2 Решения по организационному обеспечению
• 4.2.1 Организация информационного обеспечения
• 4.2.2 Организация сбора и передачи информации
• 4.2.3 Описание организационной структуры
• 4.3 Решения по техническому обеспечению
• 4.4 Решения по информационному обеспечению
• 4.4.1 Описание информационного обеспечения системы
• 4.4.2 Описание организации информационной базы
• 4.3 Решения по программному обеспечению
• 4.3.1 Структура программного обеспечения
• 4.3.2 Методы и средства разработки программного обеспечения
• 4.3.3 Операционная система
• 5. Рабочий проект
• 5.1 Руководство администратора
• 5.1.1 Назначение и условия применения
• 5.1.2 Подготовка к работе
• 5.1.3 Авторизация
• 5.1.4 Интеграция файла с данными в базу данных системы
• 5.2 Руководство пользователя
• 5.2.1 Назначение и условия применения
• 5.2.2 Подготовка к работе
• 5.2.3 Авторизация
• 5.2.4 Просмотр данных
• 5.2.5 Создание отчета
• Заключение
• Список использованных источников

• Определения
• В настоящем отчете применяют следующие термины с соответствующими определениями:

Отказоустойчивость -- это свойство технической системы сохранять свою работоспособность после отказа одного или нескольких составных компонентов. Отказоустойчивость определяется количеством любых последовательных единичных отказов компонентов, после которого сохраняется работоспособность системы в целом. Базовый уровень отказоустойчивости подразумевает защиту от отказа одного любого элемента - исключение единой точки отказа. [6]

Профилирование -- сбор характеристик работы программы, таких как время выполнения отдельных фрагментов (обычно подпрограмм), число верно предсказанных условных переходов, число кэш промахов и т. д. [4]

Репликация (англ. replication) -- механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). Репликация -- это процесс, под которым понимается копирование данных из одного источника на другой (или на множество других) и наоборот. [5]

Тестимрование программмного обеспемчемния -- процесс исследования, испытания программного продукта, имеющий две различные цели:

- продемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

- выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации[9].

Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части[10].

План Тестирования (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения[10].

Утилита (англ. utility или tool) -- вспомогательная компьютерная программа в составе общего программного обеспечения для выполнения специализированных типовых задач, связанных с работой оборудования и операционной системы (ОС)[11].

Тест-аналитик - специалист тестирования, разрабатывающий тестовые сценарии на основе тестовых случаев.

Тест-программист - специалист тестирования, который на основе тестового сценария разрабатывает автоматизированный тест - скрипт.

Релиз - версия программы с определенными параметрами и особенностями.



Обозначения и сокращения

ПО - программное обеспечение.

КИС - корпоративная информационная система

JSON - JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. [7]

BSON - (англ. Binary JavaScript Object Notation) это компьютерный формат обмена данными. Это бинарная форма представления простых структур данных и ассоциативных массивов (которые называют объектами или документами). Имя «BSON» основано на определении JSON и значит «Binary JSON» (бинарный JSON). Формат является надмножеством JSON, включая дополнительно регулярные выражения, двоичные данные и даты[8].

АИП - автоматизированная информационная подсистема.

БД - база данных.

ПК - персональный компьютер.

СУБД - система управления базой данных.

ТЗ - техническое задание.

ОС - операционная система



Введение

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

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

- Функциональные

- Нефункциональные

- Связанные с изменениями

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

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

Автоматизированное тестирование программного обеспечения (Software Automation Testing) - это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования.

Преимущества автоматизации тестирования:

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

- Быстрое выполнение - автоматизированному скрипту не нужно сверяться с инструкциями и документациями, это сильно экономит время выполнения.

- Меньшие затраты на поддержку - когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную.

- Отчеты - автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.

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

Недостатки автоматизации тестирования:

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

- Затраты на поддержку - несмотря на то, что в случае автоматизированных тестов они меньше, чем затраты на ручное тестирование того же функционала - они все же есть. Чем чаще изменяется приложение, тем они выше.

- Большие затраты на разработку - разработка автоматизированных тестов это сложный процесс, так как фактически идет разработка приложения, которое тестирует другое приложение. В сложных автоматизированных тестах также есть фреймворки, утилиты, библиотеки и прочее. Естественно, все это нужно тестировать и отлаживать, а это требует времени.

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

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

Автоматизированное тестирование подразумевает большой объем покрытия (тестирования функционала), а значит - большое количество информации. Результаты тестирования затем обрабатываются специалистами по автоматизированному тестированию программного обеспечения и передаются руководству. Автоматизация процесса обработки результатов тестирования необходима для того, чтобы уменьшить затраты времени сотрудников на анализ результатов каждого теста, а так же для обеспечения быстрого и удобного доступа руководства к наглядным результатам тестирования.



1. Формирование требований к ИС

1.1 Обследование объекта автоматизации

На предприятии ООО «Восточный Экспресс» используются методы ночного тестирования, позволяющего проводить непосредственный запуск автоматизированных тестов в свободное машинное время. Таким образом, автоматическое тестирование проходит без участия специалистов тестирования. Весь тестовый план разбивается на части и пропускается на разных машинах, чтобы обеспечить независимость результатов одних тестов от других. В начале рабочего дня результаты тестирования поступают от всех машин в базу данных и оттуда они доступны в системе регрессионного анализа результатов тестирования для последующего их анализа сотрудниками (Рисунок 1).

Рисунок 1 Организация процесса тестирования и обработки результатов на предприятии

Сложная система предполагает большой объем тестирования, следовательно, у предприятия существуют следующие проблемы:

- Слишком большое время, затрачиваемое на обработку результатов, которое могло бы быть потрачено на создание тест-кейсов и скриптов их выполнения.

- Человеческий фактор, то есть предоставление результатов анализа специалистом тестирования непосредственно руководству, вероятность допущения ошибок.

- Необходимость использования дополнительных инструментов для представления результатов анализа тестирования в наглядном виде для руководства, а значит, дополнительные затраты на лицензионное обеспечение.

- Повышенные требования к специалистам тестирования.

1.2 Формирование требований пользователя к ИС

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



2. Разработка концепции подсистемы

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

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

Используемое при разработке программное обеспечение и библиотеки программных кодов должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах. Базовой программной платформой должны являться операционные системы семейства Windows XP, Windows 7, Windows 8.

Для хранения данных необходимо использовать СУБД: MongoDB.

MongoDB -- документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++.

СУБД управляет наборами JSON-подобных документов, хранимых в двоичном виде в формате BSON. Подобно другим документо-ориентированным СУБД, MongoDB не является реляционной СУБД.

Основные возможности данной СУБД:

- Документо-ориентированное хранилище (простая и мощная JSON-подобная схема данных).

- Динамические запросы.

- Полная поддержка индексов.

- Профилирование запросов.

- Быстрые обновления «на месте».

- Эффективное хранение двоичных данных больших объёмов, напр., фото и видео.

- Репликация и поддержка отказоустойчивости.

3. Техническое задание

3.1 Общие положения

3.1.1 Полное наименование подсистемы и ее условное обозначение

Полное наименование подсистемы: EasyAnalitic.

Краткое наименование подсистемы: EA.

3.1.2 Наименование организации заказчика и участников работ

Заказчиком подсистемы является ООО «Восточный экспресс»

Адрес заказчика: г. Иваново, ул. Палехская, д. 10

Разработчиком подсистемы является Станкова Н.М., студентка кафедры информационных технологий ИГХТУ.

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

При разработке автоматизированной подсистемы и создании проектно-эксплуатационной документации Исполнитель должен руководствоваться требованиями следующих нормативных документов:

- ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания;

- ГОСТ 34.201-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплексность и обозначение документов при создании автоматизированных систем.

3.1.4 Плановые сроки начала и окончания работы по созданию подсистемы

Плановый срок начала работы - 10.02.2014.

Плановый срок окончания работы - 06.06.2014.



3.1.5 Источники и порядок финансирования работ

Источником финансирования является ООО «Восточный экспресс».

3.1.6 Порядок оформления и предъявления заказчику результатов работ по созданию подсистемы

По завершению работ по разработке и созданию подсистемы исполнитель обязан:

- предоставить разработанную в соответствии с Настоящим Техническим Заданием нормативно-техническую и программную документацию в двух видах: электронном на оптическом диске с подсистемой и в бумажном виде на формате А4;

- подсистема передается в виде функционирующего комплекса на базе средств вычислительной техники Заказчика и Исполнителя в сроки, установленные в п.3.1.4.

- Приемка подсистемы осуществляется комиссией в составе уполномоченных представителей Заказчика и Исполнителя. Порядок предъявления подсистемы, ее испытаний и окончательной приемки определен в п.6 настоящего ТЗ. Совместно с предъявлением подсистемы производится сдача разработанного Исполнителем комплекта документации согласно п.8 настоящего ТЗ.

По завершению работ по разработке и созданию подсистемы заказчик обязан:

- предоставить разработчику, удовлетворяющее требованиям, указанным в настоящем техническом задании программное и аппаратное обеспечение для проведения работ по внедрению подсистемы.



3.2 Назначение и цели создания подсистемы

3.2.1 Назначение подсистемы

АИП «EasyAnalitic» предназначена для комплексного информационно-аналитического обеспечения процесса тестирования:

- получение информации о рекомендации релизов на разные периоды времени;

- получение информации о результатах прохождения конкретного теста;

- получение информации о результатах прохождения группы тестов, релизов;

- получение информации о времени прохождения теста, группы тестов;

- получение информации о времени прохождения тестов на разных релизах;

- получение информации о динамике выявления ошибок;

- получение информации о времени устранения ошибок;

- получение информации о количестве выявленных ошибок в группах тестов;

- получение информации о рекомендованных релизах и их параметрах;

- сопоставление логов с целью получения информации о производительности и стабильности прохождения тестов.

Пользователями подсистемы являются, как специалисты по качеству программного обеспечения (это тест-аналитики, тест-программисты), так и для начальников подразделений вплоть до начальника проекта.

АИП «EasyAnalitic» предполагается использовать в системе «Система управления тестированием», задействованной в исполнении вышеперечисленных процессов.

3.2.2 Цели подсистемы

Основными целями создания АИП «EasyAnalitic» являются:

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

- повышение качества принятия управленческих решений за счет оперативности представления, полноты, достоверности и удобства форматов отображения информации;

- повышение информационной открытости и прозрачности деятельности отдела тестирования, повышение удобства и комфорта руководящих лиц при получении информации о деятельности отдела.

Данные цели будут достигнуты:

- в случае уменьшении времени на получение сведений о состоянии тестирования до 0,5 часа;

- при понимании результатов тестирования руководителями среднего и высшего звена без специального обучения и без присутствия специалистов по тестированию;

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

Для реализации поставленных целей подсистема должна решать следующие задачи:

- Анализ результатов тестирования.

- Построение разноцелевых отчетов.

- Отображение аналитической информации по результатам прохождения тестов в простом и понятном виде.

- Интеграция с существующими источниками данных о прохождении тестов.



3.3 Характеристика объекта автоматизации

Объектом автоматизации является процесс анализа результатов тестирования, а именно, получение информации:

- о рекомендации релизов на разные периоды времени;

- о результатах прохождения конкретного теста;

- о результатах прохождения группы тестов, релизов;

- о времени прохождения теста, группы тестов;

- о времени прохождения тестов на разных релизах;

- о динамике выявления ошибок;

- о времени устранения ошибок;

- о количестве выявленных ошибок в группах тестов;

- о рекомендованных релизах.

Данные процессы осуществляются при помощи программ автоматизированного тестирования и специалистами по контролю качества программного обеспечения.

3.4 Требования к подсистеме

3.4.1 Требования к подсистеме в целом

3.4.1.1 Требования к структуре и функционированию подсистемы

3.4.1.1.1 Перечень модулей, их назначение и основные характеристики

В состав «EasyAnalitic» должны входить следующие модули:

- Отчет «Состояние релиза».

- Отчет «Динамика выполнения работ».

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

- Отчет «Время прохождения».

- Отчет «Непроходимость».

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

В отчете отображается:

- Общая информация по ошибкам в системе.

- Итоговая таблица, в которой отображаются результаты о состоянии выбранных релизов.

- Графики состояния выбранных релизов, на текущий момент времени и на время ночного прогона.

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

- Общую информацию по выявленным ошибкам: дату обнаружения, дату исправления, автора, исполнителя и пр.

- График, на котором отображается, какое количество ошибок было по данному тесту/релизу за период времени и время, которое потребовалось на их устранение.

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

Отчет «Время прохождения» содержит информацию о времени выполнения тестов за выбранное число. Данный отчет имеет 2 режима работы:

- Отображение времени прохождения тестов определенного релиза за определенное число.

- Сравнение времени прохождения тестов различных релизов на различную дату.

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

3.4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы

Входящие в состав «EasyAnalitic» модули в процессе функционирования должны обмениваться информацией с Системой Управления Тестирования. Форматы данных будут разработаны и утверждены на этапе технического проектирования.

3.4.1.1.3 Требования к режимам функционирования подсистемы

«EasyAnalitic» определены следующие режимы функционирования:

- Нормальный режим функционирования.

- Аварийный режим функционирования.

Основным режимом функционирования EA является нормальный режим.
В нормальном режиме функционирования подсистемы:

- клиентское программное обеспечение и технические средства пользователей и администратора подсистемы обеспечивают возможность функционирования в течение рабочего дня (с 09:00 до 18:00) пять дней в неделю;

- серверное программное обеспечение и технические средства северов обеспечивают возможность круглосуточного функционирования, с перерывами на обслуживание;

- исправно работает оборудование, составляющее комплекс технических средств;

- исправно функционирует системное, базовое и прикладное программное обеспечение подсистемы.

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

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

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

3.4.1.1.4 Перспективы развития, модернизации подсистемы

EA должна реализовывать возможность дальнейшей модернизации, как программного обеспечения, так и комплекса технических средств.

Также необходимо предусмотреть возможность увеличения производительности подсистемы путем её масштабирования.

3.4.1.2 Требования к численности и квалификации персонала подсистемы

Требования не предъявляются.

3.4.1.2 Показатели назначения

Требования не предъявляются.



3.4.1.3 Требования к надежности

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

- при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла подсистемы;

- при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции подсистемы возлагается на ОС;

- при ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.

Для защиты аппаратуры от бросков напряжения и коммутационных помех должны применяться сетевые фильтры.

3.4.1.4 Требования к безопасности

Все внешние элементы технических средств подсистемы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.

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

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

Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов подсистемы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003 г.).

3.4.1.5 Требования к эргономике и технической эстетике

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

Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление подсистемой должно осуществляться с помощью набора экранных меню, кнопок, значков и т. п. элементов. Клавиатурный режим ввода должен используется главным образом при заполнении и/или редактировании текстовых и числовых полей экранных форм.

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

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

Экранные формы должны проектироваться с учетом требований унификации:

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

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

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

3.4.1.6 Требования к транспортабельности для подвижных ИС

Требования не предъявляются.

3.4.1.7 Требования к защите информации от несанкционированного доступа

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

3.4.1.8 Требования по сохранности информации при авариях

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

3.4.1.9 Требования к патентной чистоте

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

3.4.1.10 Требования к защите от внешних влияний

Защита от влияния внешних воздействий должна обеспечиваться средствами программно-технического комплекса Заказчика.

3.4.2 Требования к функциям подсистемы

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



3.4.3 Требования к видам обеспечения

3.4.3.1 Требования к математическому обеспечению подсистемы

Требования не предъявляются.

3.4.3.2 Требования к информационному обеспечению подсистемы

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

Средства СУБД, а также средства используемых операционных систем должны обеспечивать документирование и протоколирование обрабатываемой в подсистеме информации.

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

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

Технические средства, обеспечивающие хранение информации, должны использовать современные технологии, позволяющие обеспечить повышенную надежность хранения данных и оперативную замену оборудования

Для хранения данных необходимо использовать СУБД: MongoDB

MongoDB -- документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц.



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

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

3.6 Требования к программному обеспечению подсистемы

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

Используемое при разработке программное обеспечение и библиотеки программных кодов должны иметь широкое распространение, быть общедоступными и использоваться в промышленных масштабах. Базовой программной платформой должны являться операционные системы семейства Windows XP, Windows 7, Windows 8.

Обязательное ПО на сервере: ОС Windows XP, Windows 7, Windows 8 .net framework 3.5 и выше, СУБД MongoDB 2.4.

Обязательное ПО на Клиенте: ОС Windows XP, Windows 7, Windows 8

.net framework 3.5 и выше.

3.7 Требования к техническому обеспечению

Техническое обеспечение подсистемы должно максимально и наиболее эффективным образом использовать существующие в компании технические средства.

В состав комплекса (Рисунок 2) должны входить следующие технические средства:

- Сервер БД.

- Серверы приложения.

- ПК пользователей.

- ПК администраторов.

Рисунок 2 - Состав комплекса

Серверы БД и серверы приложений должны быть объединены одной локальной сетью, с пропускной способностью не менее 10 Мбит.

Требования к техническим характеристикам сервера:

- Процессор - наличие как минимум 1 процессора с частотой ядра 2,0 ГГц.

- Объем оперативной памяти - не менее 2 Гб.

- Дисковая подсистема - не менее 50Гб свободного места.

- Сетевой адаптер - не менее 10 Мбит.

Требования к техническим характеристикам ПК пользователя и ПК администратора:

- Процессор - наличие как минимум 1 процессора с частотой ядра 2,0 ГГц.

- Объем оперативной памяти - не менее 100 Мб свободной оперативной памяти.

- Дисковая подсистема - 40 Гб.

- Сетевой адаптер - 10 Мбит.



3.8 Требования к организационному обеспечению

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

Заказчиком должны быть определены должностные лица, ответственные за:

- обработку информации EA;

- администрирование EA;

- обеспечение безопасности информации EA;

- управление работой персонала по обслуживанию EA.

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

3.9 Требования к методическому обеспечению

Нормативно-техническая документация подсистемы должна содержать:

- Техническое задание на разработку информационной подсистемы;

- Технический проект подсистемы;

- Руководство пользователя подсистемы.

Техническое задание, технический проект и рабочий проект подсистемы должны соответствовать ГОСТ 34.



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

Таблица 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.	Защита проекта	По приказу

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

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

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

Сдача-приемка осуществляется комиссией, в состав которой входят представители Заказчика и Исполнителя. По результатам приемки подписывается акт приемочной комиссии.

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



4. Технический проект

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

Предварительные испытания проводятся для всей разработанной информационной подсистемы согласно ГОСТ 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 - Отчет «Ошибки с массовыми падениями»

...