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

• Автор: Малинин, Сергей Николаевич
• Шифр специальности: 05.13.01
• Научная степень: Кандидатская
• Год защиты: 2010
• Место защиты: Нижний Новгород
• Количество страниц: 156 с. : ил.

1.1 Жизненный цикл ПО.

1.2 Качество ПО

1.3 Структурная сложность

1.4 Тестирование .

1.5 Классификация ошибок.

1.6 Постановка задачи

ГЛАВА 2. БАЗОВАЯ МОДЕЛЬ ОБЪЕКТНООРИЕНТИРОВАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

2.1 Особенности ОО ПО по сравнению с траднциннмм ПО

2.2 Автоматная модель объектноориентированного программного обеспечения.

2.3 Автотрассировка

2.4 Выводы по главе

ГЛАВА 3. ДИАГНОСТИЧЕСКАЯ МОДЕЛЬ. МЕТОДЫ И АЛГОРИТМЫ ТЕСТИРОВАНИЯ ОБЪЕКТНООРИЕНТИРОВАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3.1 Модель и стратегия определения состояния объектноорпентироваиного программного обеспечения
3.2 Оптимизация выбора тестов по информационному критерию
3.3 Принятие решения о векторе состояний автомата но критерию максимума апостериорной вероятности .
3.4 Выводы по главе
ГЛАВА 4. ПРАКТИЧЕСКИЕ АСПЕКТЫ ТЕСТИРОВАНИЯ ОО НО.
ЗАКЛЮЧЕНИЕ
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
ПРИЛОЖЕНИЕ 1 КОД ПРОГРАММЫ, РЕАЛИЗУЮЩИЙ АЛГОРИТМ АВТОМАТИЧЕСКОГО ПОСТРОЕНИЯ ГРАФА ПЕРЕХОДОВ КОНЕЧНОГО АВТОМАТА
ПРИЛОЖЕНИЕ 2 ДИПЛОМЫ И СВИДЕТЕЛЬСТВА О РЕГИСТРАЦИИ ПРОГРАММЫ И ОТЧЕТА ПО НАУЧНОИССЛЕДОВАТЕЛЬСКОЙ РАБОТЕ
ВВЕДЕНИЕ


Исторически, в ходе эволюционного развития теории проектирования программного обеспечения и по мере его усложнения, сложились основные модели жизненного цикла 0. Эти модели выражают последовательность этапов жизненного цикла ПО. В таблице 1. ЖЦ ПО. Таблица 1. Характеристики моделей жизненного цикла программного обеспечения. Таблица 1. Критерии выбора моделей жизненного цикла программного обеспечения. Дли тельность приложений средн. Дискр. Качество результатов заново заново заново сохр. Нсоиределсн. Повт. Стоимость будущих высок. Стоимость приложений низкая низкая низкая средн. Функцлютребности конкр. Проект разработки программного обеспечения ПО должен осуществляться в соответствии с моделью жизненного цикла ЖЦ. Действия, связанные с обеспечением качества, должны планироваться и проводиться с учетом особенностей выбранной модели ЖЦ. В нашей стране жизненный цикл разработки ПО установлен стандартом ГОСТ и содержит следующие стадии и этапы табл. Таблица 1. ГОСТ . Эскизный проект разработка эскизного проекта утверждение эскизного проекта. Технический проект разработка технического проекта утверждение технического проекта. Рабочий проект разработка программ разработка программной документации испытание программы. Внедрение подготовка и передача программы. В работе используется понятие системное проектирование это период ЖЦ ПО начиная от формулирования первичного замысла на создание ПО до начала детального проектирования и разработки. Результатом должно являться согласованное и формализованное разработчиком и заказчиком представление о целях, назначении, функциональных задачах и качестве будущих ПО. Системный проект программного средства должен содержать достаточно полные требования к функциям и характеристикам качества комплекса программ, описание и графическое представление его архитектуры, базы данных и взаимодействия компонентов, предполагаемую модель жизненного цикла, предварительные планы последующих этапов и работ. Кроме того, в него должны входить проекты технического задания. В требованиях к ПО предлагается указывать, какие функции должны осуществляться, а не то, как они могут реализовываться. Они используются для задания функциональных и конструктивных требований, а так же ограничений проектирования. Построение корректных требований к системе во многом зависит от надлежащей обработки изменений требований. Управление изменениями дат уверенность в том, что создаваемая система является корректной, и будет правильной в дальнейшем. Фаза детального проектирования является решающей в создании программ. Она основывается на принципах структурного проектирования . Методология структурного анализа и структурного проектирования ПО начинается с общего обзора функций системы. Затем она должна детализироваться сверху вниз в виде иерархической структуры. Таким образом, процедуры сбора, хранения и переработки информации расчленяются на отдельные элементы данных и действия, совершаемые над этими данными. Структурный анализ позволяет разделить систему на функциональные части, выделить функциональные описания отдельных частей, исследовать в них информационные потоки и формализовать структуры данных. Структурное проектирование крупномасштабных ПО основано на модульном принципе . Проектирование модулей включает в себя разработку описания алгоритмов обработки данных, внутренних структур данных, межмодульных интерфейсов, структурных схем передач управления. С их помощью определяются функции, порядок следования отдельных шагов обработки, ситуации и типы данных, вызывающие изменения процесса обработки, а так же повторно используемые функции программы. В информационных модулях ИМ целесообразно использовать типовые структуры, ориентированные на эффективную обработку данных в конкретной проблемной области . Объединение ИМ позволяет создавать более сложные структуры данных определнного целевого назначения. Иерархия связей между этими компонентами в некоторой степени соответствует процессу обработки и потокам данных и относительно слабо связана со структурой программных компонентов в ПО. Структуры ИМ целесообразно координировать между собой с учетом цели и места их использования программными компонентами.