- •Качество и надежность программного обеспечения
- •Лекция 1. Введение. Основные стандарты и термины по качеству программного обеспечения. Метрики и критерии качества программных продуктов. Составляющие качества программных продуктов.
- •Цели и задачи курса, его связь с другими дисциплинами учебного плана.
- •ГосТы . Основные понятия и ключевые слова по качеству и надежности пп.
- •Общие термины
- •Общие характеристики качества программного средства
- •Лекция 2. Классификация видов сложности программных продуктов. Метрические характеристики программ по м.Холстеду
- •Оценивание качества разработки программ на основе метрик Холстеда. Измеримые свойства алгоритмов
- •Длина программы
- •4. Объем программы
- •Потенциальный объем V*
- •Лекция 3. Уровень программ. Интеллектуальное содержание программы.
- •1. Уровень программы
- •2. Вывод уравнения уровня программы
- •3. Определение интеллектуального содержания программ
- •Лекция 4. Работа в программировании. Уровни языков программирования. Метрика числа ошибок в программе.
- •Значение уровня языка
- •Лекция 5. Метрики структурной сложности программ.
- •Лекция 6. Методы и средства измерения характеристик программ. Аппаратные измерительные мониторы.
- •Лекция 7. Программные измерительные мониторы.
- •Лекция 8. Понятие корректности программ.
- •II. Эталоны и методы проверки корректности.
- •Лекция 9. Аналитическая проверка корректности программ. Верификация программ.
- •Лекция 10. Тестирование программных продуктов
- •1. Основные понятия процесса тестирования
- •2. Объекты тестирования
- •3. Категории тестов для различных объектов тестирования
- •Лекция 11. Виды, критерии и методы тестирования. Методы структурного тестирования программ
- •1. Тестирование на основе потока управления
- •Покрытие операторов
- •Покрытие ветвей
- •Покрытие условий
- •Комбинаторное покрытие условий
- •2. Тестирование на основе потока данных
- •Лекция 12. Методы функционального тестирование программных продуктов
- •1. Метод эквивалентного разбиения
- •1.1. Выделение классов эквивалентности
- •1.2. Построение теста
- •2. Анализ граничных значений
- •3. Метод функциональных диаграмм
- •Столбцы таблицы решений преобразуются в тесты.
- •4. Метод, основанный на предположении об ошибке
- •Лекция 13. Основные показатели надежности программного обеспечения (по). Математические модели оценки надежности по.
- •13.1. Основные показатели надежности программного обеспечения (по).
- •13.2. Математические модели оценки надежности по.
- •Модель Джелинского-Моранды.
- •Модель Шика-Уолвертона.
- •Лекция 14. Модели, основанные на методе "посева" и разметки ошибок, и модели на основе учета структуры входных данных
- •Модель Нельсона. Применение последовательного анализа Вальда для снижения количества прогонов программы.
- •Лекция 15. Методы повышения надежности программ и оценка эффективности их применения.
- •15.1 Влияние избыточности на повышение надежности программ
- •Эффективность применения избыточности для повышения надежности комплексов программ
- •Влияние оперативного контроля и восстановления на производительность эвм.
- •Методы программного восстановления
- •Методы обеспечения надежности комплексов программ при сопровождении
- •Литература
4. Метод, основанный на предположении об ошибке
Человек, обладающий богатым практическим опытом, часто подсознательно применяет метод проектирования тестов, называемый предположением об ошибке. Процедуру для метода предположения об ошибке невозможно описать формально, так как он во многом является интуитивным. Основная идея метода заключается в том, чтобы перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка написать тесты.
В качестве примера рассмотрим тестирование подпрограммы сортировки. Необходимо предусмотреть следующие специальные случаи, которые могут быть не учтены при проектировании программы:
Сортируемый список пуст.
Сортируемый список содержит только одно значение.
Все записи в сортируемом списке имеют одно и то же значение.
Список уже отсортирован.
Общая стратегия разработки тестов
Поскольку каждый из рассмотренных методов проектирования тестов обеспечивает создание некоторого набора тестов, но ни один из них сам по себе не может дать полный набор тестов, рассмотренные методы могут быть объединены в общую стратегию.
Предлагается следующая стратегия разработки тестов, которая хотя и не гарантирует, что все ошибки будут найдены, но обеспечивает приемлемый компромисс между методами.
Если спецификация содержит комбинации входных условий, то рекомендуется начать с применения метода функциональных диаграмм.
Использовать анализ граничных значений.
Определить правильные и неправильные классы эквивалентности для входных и выходных данных и дополнить, если это необходимо, тесты, построенные ранее.
Использовать метод предположения об ошибке.
Проверить логику программы, воспользовавшись критериями покрытия решений, покрытия условий, покрытия решений/условий либо комбинаторного покрытия условий. Если необходимость выполнения критерия покрытия приводит к построению новых тестов и если этот критерий не является нереализуемым (определенные комбинации условий невозможно создать вследствие природы программы), то следует дополнить уже построенный набор тестов тестами, число которых достаточно для удовлетворения критерию покрытия.
Критерии завершения тестирования
Одним из наиболее трудных в процессе тестирования является вопрос о том, когда следует закончить тестирование программы, поскольку не представляется возможным определить, сколько еще ошибок осталось в программе. В практике тестирования используются три группы критериев для завершения тестирования.
Критерии, основанные на использовании определенной методологии проектирования тестов. Тестирование завершается, когда по критерию тестирования достигается заранее заданный процент покрытия и тесты для определенного критерия заканчиваются без нахождения ошибок в программе.
Критерии, в основу которых положен принцип завершения тестирования при нахождении определенного экспертами до начала работ числа ошибок (например, исходя из данных о разработке других программ соответствующего класса).
Критерии, основанные на построении временной диаграммы тестирования. На каждой фазе проектирования программного продукта решение о продолжении тестирования принимается на основе анализа этой диаграммы. Как видно из приведенной ниже временной диаграммы, для первой фазы тестирования оказывается достаточно временного интервала в шесть недель, а для второй фазы необходимо продлить работы на неопределенный в данный момент срок.