
- •Проблемы надежности по
- •Направления исследований в вопросе надежности по
- •Основные типы комплексов программ
- •Факторы, позволяющие анализировать показатели надежности программ 2-го и 3-го типов
- •Взаимосвязь надежностных характеристик по и аппаратуры
- •Факторы надежности аппаратных средств
- •Проблемы эталонов
- •Основные этапы разработки по
- •Модель перевода входной информации в выходную
- •Количественные характеристики надежности
- •Критерии надежности
- •Характеристики по
- •Испытания
- •Основные параметры персонала
- •Цель анализа программных ошибок при сертификации и оценке надежности по
- •Извещения об ошибке
- •Основные задачи в области надежности по
- •Количественные характеристики надежности по
- •Классификация ошибок по
- •Где произошла ошибка?
- •На что похожа ошибка?
- •Как была сделана ошибка?
- •Когда была сделана ошибка?
- •Почему произошла ошибка?
- •Модели надежности по Классификация моделей надежности по
- •Экспоненциальная модель (модель Шумана)
- •Модель Джелинского-Моранда
- •Статистическая модель Миллса
- •Простейшие интуитивные (эвристические) модели
- •Методы тестирования
- •Восходящее тестирование
- •Нисходящее тестирование (нисходящая разработка)
- •Модифицированный нисходящий метод
- •Метод большого скачка
- •Метод «сэндвича»
- •М одифицированные метод «сэндвича»
Методы тестирования
Восходящее тестирование
Программа собирается и тестируется снизу вверх, только модули самого нижнего уровня тестируются изолированно или автономно. После их тестирования вызов их должен быть также надёжен, как вызов встроенной функции языка. Затем тестируются модули, вызывающие уже проверенные. Эти модули тестируются не автономно, а вместе с уже протестированными.
При восходящем тестировании для каждого модуля нужен драйвер. Нужно подавать тесты в соответствии с сопряжением модуля. Одно из возможных решений – написать для каждого модуля небольшую ведущую программу, тестовые данные представляются как встроенные в эту программу переменные. Другое решение – использовать программу тестирования модулей, тесты написать на специальном языке и избавится от необходимости писать драйвер.
Нисходящее тестирование (нисходящая разработка)
Изолированно тестируется только головной модуль. После завершения тестирования этого модуля с ним соединяются модули, непосредственно вызываемые им, и тестируется полученная комбинация. Процесс повторяется до тех пор, пока не будет собраны все модули.
Возникают 2 проблемы
Что делать, когда тестируемый модуль вызывает модуль более низкого уровня, которого в данный момент еще не существует?
Для имитации функций недостающих модулей программируются модули-заглушки, которые моделируют функции отсутствующих модулей.
Как подаются тестовые данные?
Плюсы метода
Метод совмещает тестирование модулей, тестирование сопряжений и частично тестирование внешних функций.
Когда модули ввода/вывода уже подключены, тесты можно готовить в удобном виде.
Минусы метода
Модуль редко тестируется досконально сразу после его подключения. Это связано с тем, что тестирование некоторых модулей требуют крайне сложных заглушек и пишутся простые заглушки, проверяя часть работоспособности модуля.
Этот подход может породить веру в возможность начать программирование и тестирование верхнего уровня программы до того как вся программа будет полностью спроектирована.
Нисходящий подход выгоден в тех случаях, когда есть сомнения в осуществлении программы в целом.
Нормальный стиль проектирования структуры программы предполагает при окончании проектирования нижних уровней вернуться назад и поправить верхний уровень, внося в него усовершенствования и исправляя ошибки. Если головная часть программы запрограммирована и оттестирована, разработчик с трудом идет на его модификацию.
Модифицированный нисходящий метод
Еще один недостаток нисходящего метода – полнота тестирования. В методе также сложно проверять исключительные ситуации.
Модифицированный метод требует, чтобы каждый модуль прошел автономное тестирование перед подключением к программе. Этот метод решает перечисленные проблемы, но все равно нужны как драйверы, так и заглушки.
Метод большого скачка
Это самый распространенный подход в интеграции модулей. Каждый модуль тестируется автономно. По окончанию тестирования модулей они интегрируются в систему все сразу.
Метод имеет несколько недостатков и мало достоинств. Для каждого модуля необходима заглушка и драйверы, модули не интегрируются до самого последнего момента, а это означает, что в течение долгого времени серьезные ошибки в сопряжениях могут оставаться не обнаруженными.