Дипломная (вкр): Реализация и аттестация информационной системы

.3 Тестирование приложения

Тестирование - процесс выполнения программы с целью обнаружения ошибок. Тестирование обеспечивает:

–       обнаружение ошибок;

–       демонстрацию соответствия функций программы ее назначению;

–       демонстрацию реализации требований к характеристикам программы;

–       отображение надежности как индикатора качества программы.

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

Существуют 2 принципа тестирования программы:

функциональное тестирование (тестирование «черного ящика»);

структурное тестирование (тестирование «белого ящика»).

При тестировании методом «белого ящика» известна внутренняя структура программы. Объектом тестирования здесь является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом.

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

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

Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:

–       некорректных или отсутствующих функций;

–       ошибок интерфейса;

–       ошибок во внешних структурах данных или в доступе к внешней базе данных;

–       ошибок характеристик (необходимая емкость памяти и т. д.);

–       шибок инициализации и завершения.

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

Тестирование ИС проводилось функциональным методом «черного ящика».

Этот тип тестирования основан на тестировании путем взаимодействия с приложением через графический интерфейс пользователя и анализа выводимых результатов. Метод предполагает обработку системы как «неизвестного объекта», таким образом, знание внутренней структуры в явном виде не используется. Тестирование этим методом обычно подразумевает проверку функциональных возможностей. При таком тестировании тестировщик знает только набор вводимых параметров и ожидаемые на выходе результаты, каким образом программа достигает этих результатов, ему не известно. Тестировщик никогда не проверяет программный код и не нуждается в дополнительном знании программы, кроме как ее технического описания. [5]

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

–       при использовании верных данных имеет место ожидаемый результат или сообщение об успехе;

–       при использовании неверных данных отображается соответствующее предупреждение/сообщение об ошибке.

Рассмотрим работу документа «Акт приема-передачи ТС».

При корректном заполнении реквизитов документа (Рисунок 3.7) нажатие на кнопку ОК позволяет записать и провести документ. А по кнопке выбора формы для печати выводится печатная форма акта (Рисунок 3.8).

Рисунок 3.7 - Заполнение документа «Акт приема-передачи ТС»

Рисунок 3.8 - Печатная форма квитанции на оплату

В случае выполнения заведомо ошибочных действий с документом, например, попытка записать и провести документ по кнопке ОК, если не заполнены требуемые реквизиты по документу, будет высвечено предупреждение об ошибке с указанием не заполненного поля и проведение документа выполнено не будет. Пример окна формы с ошибкой заполнения приведён на рисунке 3.9.

Рисунок 3.9 - Сообщение об ошибке при заполнении документа

3.4 Методика развертывания приложения

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

Цели этапа развертывания:

–       перенести решение в промышленную среду;

–       признание заказчиком факта завершения проекта.

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

Таблица 3.1 - План развертывания приложения

Выводы к разделу

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

4. Управление информационным проектом

.1 Выбор жизненного цикла разработки ПО

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

К. Вигерс в своей книге «Разработка требований к программному обеспечению описал обоснование модели выбора жизненного цикла на основе характеристик требований, участников команды разработчиков, типа проектов и рисков, характеристик пользователей. Таблицы приведены в Приложении Д.

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

Таблица 4.1 - Определение оптимальной модели жизненного цикла

Результатом проведенных исследований наиболее подходящей моделью жизненного цикла для разработки системы учета заказов такси модель быстрой разработки приложений (RAD).Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях - обследование организации, выработка требований к системе. Причины популярности RAD вытекают из тех преимуществ, которые обеспечивает эта технология (рисунок 4.1).

Рисунок 4.1 - RAD технология

Наиболее существенными из них являются:

–       высокая скорость разработки;

–       низкая стоимость;

–       высокое качество.

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

Применение технологии RAD целесообразно, когда:

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

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

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

–       интерфейс пользователя (GUI) есть главный фактор. Нет смысла заставлять пользователя рисовать картинки. RAD технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта.

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

–       ПО не обладает большой вычислительной сложностью.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

–    фаза анализа и планирования требований;

–       фаза проектирования;

–       фаза построения;

–       фаза внедрения.

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

–  общая информационная модель системы;

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

–       точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

–       построенные прототипы экранов, отчетов, диалогов.

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

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

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