Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. ФОРМИРОВАНИЕ ТРЕБОВАНИЙ К ИС

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

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

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

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

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

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

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

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

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

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

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

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

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

Для хранения данных необходимо использовать СУБД: MongoDB. MongoDB — документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++. СУБД управляет наборами JSON-подобных документов, хранимых в двоичном виде в формате BSON. Подобно другим документо-ориентированным СУБД, MongoDB не является реляционной СУБД. Основные возможности данной СУБД:

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

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

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

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

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

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

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

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

1. Общие положения

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

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

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

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

Заказчиком подсистемы является ООО «Восточный экспресс» Адрес заказчика: г. Иваново, ул. Палехская, д. 10 Разработчиком подсистемы является Станкова Н.М., студентка кафедры информационных технологий ИГХТУ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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