- •Основные понятия надежности. Классификация отказов. Составляющие надежности Основные понятия
- •Классификация и характеристики отказов
- •Составляющие надежности
- •Основные показатели надежности
- •Количественные показатели безотказности: общие понятия. Основные сведения из теории вероятностей Общие понятия
- •Показатели безотказности: вероятность безотказной работы, плотность распределения отказов, интенсивность отказов
- •3. Интенсивность отказов (ио)
- •Уравнение связи показателей надежности числовые характеристики безотказности
- •Математические модели теории надежности. Статистическая обработка результатов испытаний
- •Нормальный закон распределения наработки до отказа
- •Законы распределения наработки до отказа: экспоненциальный, логнормальный и гамма-распределение
- •Надежность систем. Общие понятия и определения
- •Надежность основной системы
- •Надежность систем с нагруженным резервированием
- •Надежность системы с ненагруженным резервированием
- •Надежность систем с облегченным и со скользящим резервом
- •1. Надежность систем с облегченным резервом
- •2. Скользящее резервирование
- •Надежность восстанавливаемых объектов и систем
- •1. Постановка задачи. Общая расчетная модель
- •2. Показатели надежности восстанавливаемых систем
- •3. Связь логической схемы надежности с графом состояний
- •Надежность объектов при постепенных отказах. Основные расчетные модели
- •1. Постановка задачи. Основные понятия и определения
- •2. Анализ случайных процессов изменения оп объектов
- •3. Модели процессов приближения объекта к отказам
- •3.1. Основные классы моделей
- •3.2. Основные типы моделей
- •Надежность объектов при постепенных отказах. Определение времени сохранения работоспособности
- •1. Состав рассчитываемых показателей
- •2. Общие модели расчета плотности распределения наработки до отказа
- •3. Определение времени сохранения работоспособности
- •4. Частные вопросы оценки параметрической надежности объектов
- •4.1. Оценка надежности объектов при разрегулировании
- •Качество асоиу Стандарты качества программных средств
- •Показатели качества при использовании
- •Модель характеристик качества
- •Характеристики качества
- •Основы эргономики
- •Оптимальные задачи эргономики
- •Место оператора пэвм в эргономической системе
- •Этапы операторской деятельности
- •Эргономическое обеспечение
- •Эргономическая экспертиза
- •Тестирование, верификация и валидация Место верификации среди процессов разработки программного обеспечения
- •Жизненный цикл разработки программного обеспечения
- •Модели жизненного цикла
- •Каскадный жизненный цикл
- •Спиральный жизненный цикл
- •Экстремальное программирование
- •Сравнение различных типов жизненного цикла и вспомогательные процессы
- •Современные технологии разработки программного обеспечения:
- •Сравнение технологий msf, rup и xp
- •Ролевой состав коллектива разработчиков, взаимодействие между ролями в различных технологических процессах
- •Задачи и цели процесса верификации
- •Тестирование, верификация и валидация – различия в понятиях
- •Документация, создаваемая на различных этапах жизненного цикла
- •Типы процессов тестирования и верификации и их место в различных моделях жизненного цикла Модульное тестирование
- •Интеграционное тестирование
- •Системное тестирование
- •Нагрузочное тестирование
- •Формальные инспекции
- •Верификация сертифицируемого программного обеспечения
- •Задачи и цели тестирования программного кода
- •Методы тестирования Черный ящик
- •Стеклянный (белый) ящик
- •Тестирование моделей
- •Анализ программного кода (инспекции)
- •Тестовое окружение
- •Тестирование удобства использования пользовательских интерфейсов
Методы тестирования Черный ящик
Основная идея в тестировании системы, как черного ящика состоит в том, что все материалы, которые доступны тестировщику – требования на систему, описывающие ее поведение и сама система, работать с которой он может только подавая на ее входы некоторые внешние воздействия и наблюдая на выходах некоторый результат. Все внутренние особенности реализации системы скрыты от тестировщика, таким образом, система и представляет собой «черный ящик», правильность поведения которого по отношению к требованиям и предстоит проверить.
С точки зрения программного кода черный ящик может представлять с собой набор классов (или модулей) с известными внешними интерфейсами, но недоступными исходными текстами.
Основная задача тестировщика для данного метода тестирования состоит в последовательной проверке соответствия поведения системы требованиям. Кроме того, тестировщик должен проверить работу системы в критических ситуациях – что происходит в случае подачи неверных входных значений. В идеальной ситуации все варианты критических ситуаций должны быть описаны в требованиях на систему и тестировщику остается только придумывать конкретные проверки этих требований. Однако в реальности в результате тестирования обычно выявляется два типа проблем системы:
Несоответствие поведения системы требованиям
Неадекватное поведение системы в ситуациях, не предусмотренных требованиями.
Отчеты об обоих типах проблем документируются и передаются разработчикам. При этом проблемы первого типа обычно вызывают изменение программного кода, гораздо реже – изменение требований. Изменение требований в данном случае может потребоваться ввиду их противоречивости (несколько разных требований описывают разные модели поведения системы в одной и той же самой ситуации) или некорректности (требования не соответствуют действительности).
Проблемы второго типа однозначно требуют изменения требований ввиду их неполноты – в требованиях явно пропущена ситуация, приводящая к неадекватному поведению системы. При этом под неадекватным поведением может пониматься как полный крах системы, так и вообще любое поведение, не описанное в требованиях.
Тестирование черного ящика называют также тестированием по требованиям, т.к. это единственный источник информации для построения тест-плана.
Стеклянный (белый) ящик
При тестировании системы, как стеклянного ящика, тестировщик имеет доступ не только к требованиям на систему, ее входам и выходам, но и к ее внутренней структуре – видит ее программный код.
Доступность программного кода расширяет возможности тестировщика тем, что он может видеть соответствие требований участкам программного кода и видеть тем самым – на весь ли программный код существуют требования. Программный код, для которого отсутствуют требования называют кодом, непокрытым требованиями. Такой код является потенциальным источником неадекватного поведения системы. Кроме того, прозрачность системы позволяет углубить анализ ее участков, вызывающих проблемы – часто одна проблема нейтрализует другую и они никогда не возникают одновременно.