Комментарии к экзаменационным вопросам / Комментарии к вопросам

Ясно, что , и, или

Интенсивность обнаружения ошибок (функция риска), вместе с вероятностью безотказной работы программы и количеством оставшихся в программе ошибок, являются важнейшими показателями надежности программ.

[18] Математические модели надёжности программ. Классификация и общие характеристики.

Тут главное носом не клюнуть… Зачем же нужны эти модели? Дело в том, что степень надёжности можно измерить с помощью метрик. Модели позволяют предсказывать значения этих метрик и оценивать надёжность на различных этапах тестирования программы. Основные метрики, предсказываемые моделями: количество ошибок в программе, полное время тестирования и т.д. Модели бывают: на основе функции риска /самые жопистые, используют статистические оценки при различных видах функции риска – Джелинского-Моранды, Шика-Уолвертона, Липова, Шнейдевинда/, на основе посева ошибок /в программу добавляют искусственные ошибки и проводят тестирование. Оценка производится на основе количества выявленных искусственных и естественных ошибок/, на основе структур входных данных /модели используют парадигму множества входных данных и реакции программы на входные данные/.

[19] Группа моделей надёжности программ на основе функции риска – временной структуры появления ошибок. Попался этот вопрос? Вам конец…

Всего шесть моделей: Джелинского-Моранды (Предполагаем, что R(t) ~ количеству ошибок в программе и R(t) = const в промежутках между обнаружением ошибок. Положим R(t) = K^.(B – i + 1), P(X_i) = exp{– K^.(B – i+1)^.X_i}, q(X_i) = -dP(X_i)/dX_i. Теперь можно написать функцию правдоподобия L = Пq(X_i), логарифмировать её и найти максимум, решив уравнения в частных производных по В и К. Удачи!!), Простая экспоненциальная (Хотим, чтобы R(t) не была кусочно-константной. Пусть N(t) – число ошибок к моменту времени t, тогда R(t)=K^.(B-N(t)). Продифференцировав получаем dR(t)/dt = -K^.dN(t)/dt. Зная dN(t)/dt = R(t), получаем тривиальную диффуру: dR(t)/dt + KR(t) = 0. Решение известно: R(t) = KB^.exp{-Kt}, отсёдова можете искать B), Шика-Уолвертона (Внесём зависимость R(t) от времени тестирования. Пусть R(t) = K^.(B-i+1)^.X_i, тогда P(X_i)=exp{-K^.(B-i+1)^.X_i² / 2}, а q(X_i) = -dP(X_i)/dX_i), Липова (Липов, падла, аж две модели выдал: в первой предполагается, что на каждом этапе обнаруживается f_i ошибок, из них n_i исправляется R(t) = K^.(B-F_i-1). Во второй добавляется влияние времени тестирования: R(t) = K^.(B-F_i-1)^.(SX_j + X_i / 2)), Геометрическая (Хотим, чтобы интенсивность менялась по закону геометрической прогрессии: R(t) = DK^i-1. q(X_i) = DK^i-1 exp{-DK^i-1X_i}. В модели определён уровень чистоты программы: r = 1 - Kⁿ), Шнейдевинда (ну его на хер, честное слово…).

[20] Группа моделей надёжности программ на основе методики посева и разметки ошибок.

Целых три методики: Милза (Перед тестированием засевается М известных ошибок. Происходит тестирование, в результате которого выявляются m засеянных и n естественных ошибок. В этом случае полагаем, что всего в программе N = n^.(M/m) ошибок), Бейзина (Положим, программа представляет собой набор из Nk команд. Из них случайно выбирается М команд, в которые вносится ошибка. Для тестирования случайно выбирается r команд. В результате выявляются m засеянных и n естественных ошибок. Тогда всего в программе было ошибок: B = trunc{n^.(Nk-M+1)/(r-m)}), Руднера (Пусть тестирование выполняется двумя группами программистов, причём одна находит m₁ ошибок, вторая – m₂ ошибок. Пусть m₁₂ – ошибки, найденные обеими группами одновременно, тогда всего ошибок в программе: B = m₁m₂ / m₁₂).

[21] Группа моделей надёжности программ на основе использования структур входных данных.

Мне не очень понятно при чём тут структуры входных данных. Модели две: Нельсона (Программе на вход подаётся какое-то значение E_i. Программа выдаёт значение F(E_i). Если F(Ei) лежит в заданных пределах – тест успешен, иначе – провален. Пусть f_i – индикатор проваленного теста. Если все тесты равновероятны, то вероятность отказа программы равна Q(m) = Sf_i / m. Если тесту E_i соответствует вероятность p_i, то Q(m) = S(p_if_i). Вероятность успешного прогона P = S(p_i(f_i-1)). Дальше начинается херня), модель IBM (Модель эмпирически получена при наблюдениях за процессом разработки OS360. Проект разрабатывается в несколько стадий. Обозначим М_i – количество модулей на стадии i, НМ_i – количество новых модулей, СИМ_i – количество старых изменяемых модулей, МИМ_i – многократно изменяемые модули, ИМ_i – слабо изменяемые модули. Тогда имеют место следующие соотношения: M_i = M_i-1 + НМ_i , ИМ_i = 0,9 НМ_i + 0,15 СИМ_i , МИМ_i = 0,15 НМ_i + 0,06 СИМ_i , а количество ошибок в программе равно В = 23 МИМ_i + 2 ИМ_i. Почему? Да какая разница…).

[22] Методы повышения надёжности программ. Виды избыточности и особенности их применения. Методы испытания программ на надёжность.

Идея заключается в том, что если мы будем включать в программы средства по самостоятельному восстановлению, они будут корректно работать даже после сбоев. Хотим сводить любые аномалии, возникающие в процессе работы программы, к приемлемому уровню. Решение задачи – использование избыточности. Избыточность бывает временной (затрачиваем дополнительное процессорное время на контроль за ходом вычислительного процесса и на восстановление в случае обнаружения сбоев), информационной (мы дублируем информацию с целью её возможного восстановления после искажений. Например: контроль чётности. Наше кодирование позволяет либо распознать ошибку, либо исправить её), программной (мы решаем одну и ту же задачу с помощью различных алгоритмов или программных реализаций. Необходимо реализовать также модуль контроля, распознающий ситуации когда разные программы выдают разные результаты). Методы испытания программ на надёжность, говорите? Откуда бы это взять…

[23] Структурный анализ качества ПП. Понятие маршрута. Сложность маршрута. Структурная сложность программы.

Структурная сложность программ определяется числом взаимодействующих компонент, числом связей между компонентами, сложностью взаимодействия компонент. Для анализа представим нашу программу в виде графа (что является вершинами, а что – дугами, – я не знаю). Под маршрутом будем понимать последовательность вершин в которой соседние вершины соединены дугой. Маршруты бывают вычислительными и логическими. Первые отражают ход вычислений для преобразования квазинепрерывных физических характеристик (!). Они тестируются на всех «крайних» значениях и на 2 – 3 значениях из середины. Сложность вычислительного маршрута равна количеству всевозможных значений входных данных в пределах этого маршрута. Вторые отражают принятие логических решений в программе. Сложность логического маршрута равна количеству проверяемых на нём условий (каждое условие соответствует одному ответвлению на графе).

[24] Критерий выбора маршрута по принципу минимального покрытия всего графа потока управления.

Для оценки структурной сложности программы мы выбираем рад маршрутов от начальной до конечной вершины и суммируем их сложность. Вопрос: какие маршруты выбирать для оценки? Предлагается критерий: выбрать минимальное множество маршрутов так, чтобы они покрыли весь граф потока управления. Под покрытием мы понимаем как покрытие всех вершин, так и покрытие всех дуг. Всё! Вот и растягивайте это на 15 минут ответа…

[25] Критерий выбора маршрута по принципу цикломатического числа графа потока управления.

Для оценки структурной сложности программы мы выбираем рад маршрутов от начальной до конечной вершины и суммируем их сложность. Вопрос: какие маршруты выбирать для оценки? Предлагается критерий: посчитаем цикломатическое число Z = количество дуг – количество вершин + 2^.число связных компонент. Z иногда можно посчитать как число вершин ветвления + 1. Надо сильно постараться, чтобы число связных компонент не равнялось единице. Теперь нам надо набрать Z маршрутов, выбрав все линейно-независимые ациклические маршруты и линейно-независимые циклы. Линейно-независимый маршрут – маршрут, который нельзя покрыть никакими другими маршрутами из уже имеющихся.

[26] Критерий выбора маршрута по принципу выделения базовых структур графа потока управления.

Для оценки структурной сложности программы мы выбираем рад маршрутов от начальной до конечной вершины и суммируем их сложность. Вопрос: какие маршруты выбирать для оценки? Предлагается критерий: выделить все базовые структуры графа. Сначала выберем все возможные ациклические маршруты. Затем, для каждого ациклического маршрута из которого достижим хотя бы один цикл, анализируется этот же маршрут, но с заходом во все достижимые циклы. Сделать это намного проще, чем описать словами.

[27] Тестирование программных изделий. Методы и критерии тестирования. Понятие теста. Основные принципы тестирования.

Тестирование – это контролируемое выполнение программы на конечном множестве наборов данных и анализ результатов этого выполнения с целью обнаружения ошибок (динамическое тестирование). Статическое тестирование не требует выполнения программы. Методы тестирования – это совокупность правил, регламентирующих последовательность шагов по тестированию. Критерии тестирования – соображения, позволяющие судить о достаточности проведенного тестирования. Ошибка – различие между вычисленным/обозреваемым/измеренным значением/условием и действительным/специфицированным/теоретически корректным значением/условием, т.е. в программе имеется ошибка, если ее выполнение не оправдывает ожиданий пользователя (Любой программный продукт, не свободен от ошибок). Удачный тест, если обнаружили ошибку. Тогда тестирование – процесс деструктивный (обратный созидательному, конструктивному). Тест – это набор входных значений, условий выполнения и ожидаемых значений на выходе, разработанных для проверки конкретного пути выполнения программы. Особенности тестирования ПП в отличие от аппаратного тестирования: 1. Отсутствие полностью определенного единого эталона, которому должны соответствовать все результаты тестирования проверяемой программы; 2. Высокая сложность программ и принципиальная невозможность построения тестовых наборов, достаточных для исчерпывающего тестирования; 3. Наличие в программах вычислительных и логических компонент, а также компонент, характеризующихся стохастическим и динамическим поведением; 4. Относительно невысокая степень формализации критериев завершения процесса тестирования и оценки качества тестирования.

Основные принципы тестирования: 1. Описание предполагаемых значений выходных данных или результатов; 2. Следует избегать тестирования программы ее автором. Авторы отлаживают; 3. Организация не должна сама тестировать разработанные ею программные продукты; 4. Необходиимо досконально изучать результаты применения каждого теста; 5. Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных данных; 6. Необходимо проверять программу на нежелательные побочные эффекты; 7. Не следует выбрасывать тесты, даже если программа уже не нужна; 8. Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены.

[28] Объекты тестирования. Категории тестов, для различных объектов тестирования.

Объекты тестирования: 1. Спецификации программных модулей, групп программ и программных комплексов; 2. Программные модули (код программных модулей); 3. Группы программ, решающие законченные функциональные задачи; 4. Комплексы программ, для которых завершены все виды отладки; 5. Программные средства, подлежащие испытаниям перед сдачей в эксплуатацию; 6. Сопровождаемый программный продукт до завершения его жизненного цикла. От 1 к 4 сложность тестирования возрастает. Трудоемкость тестирования всей совокупности программных модулей, может быть выше, чем сложность тестирования при испытаниях и сопровождении. Уровень разработки тестов зависит от объектов. Методы тестирования прогр-х модулей написанных на процедурных языках исследованы хорошо, на объектно-ориентированных плохо, а для комплексов ваще ни хера нет. Чес сложней объект тем больше затрат на его тестирование. Автоматизация тестирования есть только для процедурных языков программирования. Категории тестов для вышеописанных объектов тестирования (На этапе тестирования): 1) • полноты и согласованности функций программных компонент; • согласованности интерфейса в спецификациях программных компонент. 2) • структуры программного модуля; • вычислений и преобразований данных программным модулем; • полноты функций, выполняемых модулем. 3) • структуры группы программ; • межмодульного интерфейса в группе программ; • выполнения ограничений по использованию памяти и длительности исполнения группы программ; • полноты решения функциональных задач группой программ. 4) • полноты решения функциональных задач комплексом программ для типовых исходных данных; • функционирования программ в критических ситуациях по условиям и логике решения задач; • корректности использования ресурсов памяти и производительности вычислительной системы; • параллельного (одновременного) исполнения различных программ; • эффективности защиты от искажения входных данных; • определения надежности комплекса программ; • оценки эффективности защиты от сбоев аппаратуры и не выявленных ошибок программ. 5) • испытаний на соответствие комплекса программ техническому заданию; • удобства эксплуатации и взаимодействия человека с комплексом программ; • удобства установки и подготовки рабочей версии; • работы комплекса программ при конфигурациях оборудования; • корректности документации; • удобства сопровождения и модификации программ. 6) практически все вышеперечисленные. Сопровождение является процессом создания программ или его отдельных компонентов (редко применяем все категории тестов).

[29] Тестирование на основе потока управления. Критерий покрытия решений.

(Для саморазвития) 3 вида тестирования: 1. Модульное проверка корректности структуры модулей и их основных конструктивных компонент (циклов, блоков, разветвлений), функций и данных (входных и выходных); 2. Интеграционное – проверка корректности управляющих и информационных связей между модулями. При проведении интеграционного тестирования важным является порядок сбора модулей в единую программу. Существует два основных подхода к комбинированию модулей: пошаговое – каждый модуль подключается к набору ранее оттестированных модулей; монолитное – все модули одновременно объединяются в программу; 3. Системное – проверка соответствия интегрированной в единое целое программной системы спецификациям с учетом среды и режима выполнения.

Элементами, которые должны быть покрыты при прохождении тестов, являются вершины, дуги, маршруты, условия, комбинации условий управляющего графа программы. В настоящее время неплохо себя зарекомендовали критерии структурного тестирования, для которых требуемые элементы определяются на основе потока данных, т. е. информационного графа программы.

Критерий покрытие решений (ветвей) – при использовании этого критерия каждая дуга должна быть пройдена хотя бы один раз.

[30] Тестирование на основе потока управления. Критерий покрытия условий.

Критерий покрытие условий – каждое логическое условие в программе должно выполняться хотя бы один раз. Критерий покрытия условий обычно лучше критерия покрытия решений, поскольку оно может вызвать выполнение решений в условиях, не реализуемых при покрытии решений. С другой стороны, критерий покрытия условий может не удовлетворять критерию покрытия решений. Для рассмотренного примера предложенные тесты покрытия условий покрывают результаты всех решений, но это случайное совпадение. Например, два альтернативных теста: A=1, B= 0, X=3 и A=2, B=1, X=1 покрывают результаты всех условий, но только два из четырех результатов решений (оба они покрывают путь abe и, следовательно, не выполняют результат истина первого решения и результат ложь второго решения).

[31] Тестирование на основе потока управления. Критерий комбинаторного покрытия условий

Критерий комбинаторного покрытия условий – требует такого набора тестов, чтобы все возможные комбинации результатов условия в каждом решении выполнялись по крайней мере один раз. Слово возможные употреблено потому, что не все комбинации условий могут быть реализуемыми; например, в выражении (A>2) & (A<10) могут быть реализованы только три комбинации условий. Набор тестов, удовлетворяющий критерию комбинаторного покрытия условий, удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.

[32] Функциональное тестирование. Метод эквивалентного разбиения.

Функциональное тестирование – это тестирование, проводимое для проверки соответствия программной системы или программного модуля специфицированным функциональным требованиям. Здесь все внимание фокусируется только на выходных значениях, генерируемых в ответ на выбранные входные значения и условия выполнения. Метод эквивалентного тестирования. Цель – выбрать минимальное подмножество тестов, обеспечивающих наибольшую вероятность обнаружения ошибок. Правильно выбранный тест этого подмножества должен обладать двумя свойствами: 1) Включать как можно больше входных условий с тем, чтобы минимизировать общее число тестов; 2) Разбивать входные данные программы на конечное число классов эквивалентности так, чтобы можно было предположить, что если один тест класса эквивалентности обнаруживает ошибку, то следует ожидать, что и все другие тесты этого класса эквивалентности будут обнаруживать ту же самую ошибку и, наоборот. Разработка тестов методом эквивалентного разбиения осуществляется в два этапа: I. выделение классов эквивалентности; II. Построение тестов. I.Выделение классов эквивалентности Классы эквивалентности выделяются путем выбора каждого входного условия (предложение спецификации) и разбиения его на две или более групп. Различают два типа классов эквивалентности: 1. Правильные классы эквивалентности, представляющие правильные входные данные программы; 2. Неправильные классы эквивалентности, представляющие ошибочные входные данные.

Выделение классов эквивалентности по ряду правил, которые следует выполнять: 1. Если входное условие описывает область значений (1  I  100), то задается один правильный класс эквивалениности (1  I  100) и два неправильных ( X < 1 и X>100). 2. Если входное условие описывает число значений (число элементов последовательности N не должно превышать 10), то определяется 1 правильный класс (N  10) и 2 неправильных (N<1 и N>10). 3. Если входное условие описывает множество входных значений, то определяется правильный и один неправильный класс эквивалентности – значение, не принадлежащее множеству. 4. Если входное условие описывает ситуацию “должно быть”, то определяется один правильный и один неправильный класс эквивалентности (первый символ – не буква). 5. Если есть основание считать, что различные элементы класса эквивалентности трактуются программой неодинаково, то данный класс эквивалентности разбивается на меньшие классы эквивалентности. II. Построение теста: 1. Назначение каждому классу эквивалентности уникального номера; 2. Проектирование новых тестов, каждый из которых покрывает как можно большее число непокрытых правильных классов эквивалентности, до тех пор пока все правильные классы эквивалентности не будут покрыты; 3. Запись тестов, каждый из которых покрывает один и только один из непокрытых неправильных классов эквивалентности, до тех пор пока все неправильные классы эквивалентности не будут покрыты. Причина покрытия неправильных классов эквивалентности индивидуальными тестами заключается в том, что определенные проверки с ошибочными входами скрывают или заменяют другие проверки с ошибочными входами.

[33] Функциональное тестирование. Анализ граничных значений.

Граничные условия – это ситуации, возникающие непосредственно на, выше или ниже границ входных и выходных классов эквивалентности. Отличия от эквивалентного разбиения: 1. Выбор любого элемента в классе эквивалентности в качестве представительного при анализе граничных значений осуществляется таким образом, чтобы проверить тестом каждую границу этого класса (т.е. исследуются ситуации, возникающие на и вблизи границ эквивалентных разбиений); 2. Рассматриваем не только входные условия, но и выходные значения. Правила использования данного метода: 1) Построить тесты для границ области и тесты с неправильными входными данными для ситуаций незначительного выхода за границы области, если входное условие описывает область значений. Пример: правильное значение -1.0  X  +1.0, тесты для ситуаций: -1.0, 1.0, -1.001, 1.001. 2) Построить тесты для минимального и максимального значений условий и тесты, большие и меньшие этих значений, если входное условие принимает значения из некоторого дискретного диапазона. Например, если входной файл может содержать от 1 до 256 записей, то необходимо составить тесты для 0, 1, 255 и 256 записей. 3) Использовать правило 1) для каждого выходного условия. Например, если программа вычисляет ежемесячный расход и если минимум расхода составляет 0.00 руб., а максимум – 100000.00 руб, то нужно построить тесты, которые вызывают следующие расходы: -1.00, 0.00, 100000.00 и 100000.25. 4) Использовать правило 2) для каждого выходного условия. Например, если система информационного поиска отображает на экране терминала не более 8 наиболее подходящих рефератов для входного запроса, то следует составить тесты, которые могли бы вызвать выполнение программы с отображением 0, 1, 8, >8 рефератов. 5) Если вход или выход программы – упорядоченное множество (например, линейный список, таблица, последовательный файл), то следует разработать тесты для обработки первого и последнего элементов этого множества. [-] Они не исследуют комбинации входных условий. Например, если тестируется некоторая программа социологического опроса, то она может не обнаружить ошибку, связанную с превышением произведения числа вопросов и числа респондентов, хотя такая ошибка не обязательно будет обнаружена тестированием граничных значений. Тестирование комбинаций входных условий – сложная задача, поскольку даже при эквивалентном разбиении входных условий число комбинаций классов эквивалентности может быть очень большим. Если нет систематического способа выбора подмножества входных условий, то, как правило, выбирается произвольное подмножество, приводящее к неэффективному тесту.

[34] Метод тестирования на основе предположения об ошибке. Критерии завершения тестирования.

Человек, обладающий богатым практическим опытом, часто подсознательно применяет метод проектирования тестов, называемый предположением об ошибке. Процедуру для метода предположения об ошибке невозможно описать формально, так как он во многом является интуитивным. Основная идея метода заключается в том, чтобы перечислить в некотором списке возможные ошибки или ситуации, в которых они могут появиться, а затем на основе этого списка написать тесты. В качестве примера рассмотрим тестирование подпрограммы сортировки. Необходимо предусмотреть следующие специальные случаи, которые могут быть не учтены при проектировании программы: 1. Сортируемый список пуст; 2. Сортируемый список содержит только одно значение; 3. Все записи в сортируемом списке имеют одно и то же значение; 4. Список уже отсортирован. Критерии завершения тестирования (Когда же остановиться?) Три группы критериев для завершения тестирования: 1. Критерии, основанные на использовании определенной методологии проектирования тестов. Тестирование завершается, когда по критерию тестирования достигается заранее заданный процент покрытия и тесты для определенного критерия заканчиваются без нахождения ошибок в программе; 2. Критерии, в основу которых положен принцип завершения тестирования при нахождении определенного экспертами до начала работ числа ошибок; 3. Критерии, основанные на построении временной диаграммы тестирования. На каждой фазе проектирования программного продукта решение о продолжении тестирования принимается на основе анализа этой диаграммы.

16