Методы и средства генерации данных для тестирования встроенного бортового программного обеспечения

• Автор: Батаев, Алексей Владимирович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2008
• Место защиты: Москва
• Количество страниц: 177 с. : ил.

ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ.

ГЛАВА 1. МЕТОДЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. МЕТОДЫ И СРЕДСТВА ВЕРИФИКАЦИИ

1.1. Модели процесса создания программного обеспечения.

1.2. Критические системы.

1.2.1. Жизненный цикл разработки встроенного бортового программного обеспечения.

1.3. Методы и средства автоматического доказательства корректности программ.

1.3.1. Метод индуктивных утверждений

1.3.2. Аксиоматический метод доказательства частичной корректности программ

1.4. Методы автоматической генерации тестовых данных.

1.4.1. Проблемы систем генерации тестовых данных

1.4.2. Применение методов генерации тестовых данных для тестирования встроенного бортового программного обеспечения
1.5. Методы и средства тестирования программного обеспечения
1.5.1. Статическое тестирование.
1.5.2. Динамическое тестирование
1.5.3. Методы тестирования программного обеспечения.
1.5.3.1. Функциональное тестирование.
1.5.3.2. Тестирование встроенного бортового программного обеспечения.
1.6. Обзор существующих систем тестирования
1.6.1. V.
1.6.2.
1.6.3. .
1.6.4. i i2.
1.6.5. .
1.6.6. i
1.7. Средства разработки системы генерации тестов
1.8. Проблемы тестирования встроенного бортового программного обеспечения
1.9. Постановка задачи
1 Выводы
ГЛАВА 2. МЕТОД ГЕНЕРАЦИИ ТЕСТОВЫХ ДАННЫХ НА ОСНОВЕ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ
2.1. Описание метода генерации тестовых данных
2.1.1. Суть подхода.
2.1.2. Выделение областей эквивалентностей
2.1.3. Метод решения логических ограничений.
2.2. Модификация метода генерации тестовых данных для определения достижимости заданной точки в программе.
2.3. Автоматизация процесса тестирования встроенного бортового программного обеспечения.
2.4. Метод генерации тестовых данных и иодоопределенная математика
2.5. Выводы.
ГЛАВА 3. ПРОТОТИП СИСТЕМЫ ПОДДЕРЖКИ МОДЕЛИРОВАНИЯ И ТЕСТИРОВАНИЯ ВСТРОЕННОГО БОРТОВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ АОАС8
3.1. Проект системы моделирования и помощи разработки.
3.1.1. Подсистема разбора исходного кода целевого языка.
3.1.2. Подсистема хранения и анализа семантической информации
3.1.3. Подсистема моделирования исполнения исходного кода.3
3.1.4. Интерфейс взаимодействия пользователя с системой
3.1.5. Подсистема сбора и анализа степени покрытия кода
3.1.6. Подсистема решения логических уравнений.
3.2. Тестирование на основе моделирования
3.3. Выводы
ГЛАВА 4. ПРИМЕНЕНИЕ ПРОТОТИПА СИСТЕМЫ МОДЕЛИРОВАНИЯ И ТЕСТИРОВАНИЯ И МЕТОДА ГЕНЕРАЦИИ
ТЕСТОВЫХ ДАННЫХ.
4.1. Анализ и практика применения разработанных методов генерации тестовых
4.2. Использование метода генерации тестовых данных в системе генерации тестов

4.3. Выводы.
ЗАКЛЮЧЕНИЕ
ЛИТЕРАТУРА


Они являются полезными абстракциями, помогающими приложить различные подходы и технологии к процессу разработки. Кроме того, процесс создания больших систем не является единым, а состоит из множества различных процессов, ведущих к созданию отдельных частей большой системы. Каскадная модель. Основные базовые виды деятельности, выполняемые в процессе создания ПО, представляются как отдельные этапы этого процесса [; ; ]. Эволюционная модель разработки ПО. Здесь последовательно перемежаются этапы формирования требований, разработки Г и его верификации. Первоначальная программная система быстро разрабатывается на основе некоторых абстрактных общих требований. Затем они уточняются и детализируются в соответствии с требованиями заказчика. Далее система дорабатывается и проверяется в соответствии с новыми уточненными требованиями [1]. Модель формальной разработки систем. Основана на разработке формальной математической спецификации программной системы и преобразовании этой спецификации посредством специальных математических методов в исполняемые про1раммы. Проверка соответствия спецификации и системных компонент также выполняется математическими методами []. Модель разработки ПО па основе ранее созданных компонент. Предполагает, что отдельные составные части программной системы уже существуют, т. В этом случае технологический процесс создания ПО основное внимание уделяет интеграции отдельных компонент в общее целое, а не их созданию []. Модель пошаговой разработки. Является промежуточной между эволюционной и каскадной моделями. В соответствии с данной моделью, в самом начале разработки определяются наиболее важные сервисы, на основе этой информации определяются основные шаги и их последовательность. На первых шагах детализируются требования для сервисов, а для их реализации используют один из подходящих методов разработки программного обеспечения [4]. Спиральная модель разработки. Каждый виток спирали соответствует одной стадии процесса создания ПО. Эта модель может включать в себя любые другие модели разработки систем []. На практике могут применяться и гибридные модели, позволяющие выполнить отдельные процессы разработки подсистем и весь процесс создания ПО итеративно. Примерами подобных подходов являются модель пошаговой разработки и спиральная модель разработки. Большую популярность приобрел метод экстремального программирования, основанный на модели пошаговой разработки. Он основан на пошаговой разработке малых программных компонент, реализующих простые функциональные требования, постоянном вовлечении заказчика в процесс разработки и обезличенном программировании []. Также в последнее время все большую популярность приобретает предлагаемый фирмой Rational Унифицированный Процесс Разработки программного обеспечения. Данная модель управляется вариантами использования, ориентирована на архитектуру, и является инкрементной и итеративной []. Обычно отказы систем, управляемых с помощью программного обеспечения общего назначения, вызывают неудобства, но не приводят к существенным последствиям. Однако имеются системы, отказы которых могут приводить к значительным экономическим потерям, физическим повреждениям или создавать угрозу человеческой жизни. Такие системы обычно называют критическими. Функциональная надежность - необходимое требование к критическим системам, и все ее составляющие (работоспособность, безотказность, безопасность и защищенность) очень важны. Существует три основных типа критических систем. Системы, критические по обеспечению безопасности, т. Системы, критические для целевого назначения, т. Системы, критические для бизнеса. Для критических систем необходимо гарантировать высокое качество разработки спецификации и точность отражения в ней реальных потребностей пользователей. Условия надежности критических систем порождают как функциональные, так и нефункциональные требования. Процесс определения требований безопасности и обеспечения их выполнения - часть общего «безопасного» жизненного цикла ПО [0], в упрощенном виде представленного на рис. Рис. Безопасный» жизненный цикл ПО (но стандарту ІЕС 8) [, с.