низации процессов в этом случае не будут проверены, но код, реализующий их, также может содержать ошибку. Тоже самое можно сказать о ряде нештатных ситуаций, которые разработчик решил парировать и внес в код, но которые конкретно отсутствуют в функциональных требованиях. Если же в основу функциональной отладки положить варианты, связанные с варьированием входных данных таким образом, чтобы однократно попасть на все выходы программ, то такой подход близок к методологии «черного ящика» и не фиксирует и не проверяет все внутренние ветвления.
С другой стороны все функции, для выполнения которых создано ПО должны быть проверены при отладке. Но варианты, выбранные при структурной отладки обязательно будут включать в себя и варианты функциональной отладки. Таким образом, проверка при отладке полного перечня функциональных требований выступает ,как необходимое , но недостаточное условие.
57. Принцип «белого» и «черного» ящика при динамической отладке ПО.
Таким образом, отладка программ связана с проверкой их работы на некоторой исчерпывающей совокупности исходных данных - тестов. При проведении динамической отладки программ возможны два подхода при реализации этих совокупностей: программа или программный комплекс рассматриваются как «черный ящик» или как «белый ящик».
При отладке программы по методологии "черного ящика" внутреннее устройство программы, ее структура предполагаются неизвестными и отладка ведется путем исчерпывающих вариаций входных данных, что в конечном итоге при определенной длительности, а точнее полноты процесса вариаций должно привести к накрытию всех ветвей графа программы по управлению и по информации т.е. к проверке всех вариантов исполнения программы.
Для программ реального времени, кроме того, требуется не только вариация значений каждой входной переменной и просмотр каждой комбинации входных данных, но и проверка их задания по различным временным последовательностям.
Для непрерывных входных переменных обязательна проверка их «граничных значений» на границах области возможных изменений, а также перебор их значений в диапазонах изменения или случайная их выборка (сочетание детерминированного и статистического тестирования). В случае больших программных комплексов с большим количеством входных данных подход "черного ящика" приводит к огромной трудоемкости отладки для достижения приемлемой ее достоверности.
При втором подходе (программа - "белый ящик") анализируются логические маршруты исполнения программы по ее графу, который в этом случае должен быть известным.
Исследование логических маршрутов исполнения программы должно сопровождаться исследованиями на граничные значения исходных данных и поиском «особых точек». Эти два приёма – использование информации о структуре ПО и использование информации об особых точках позволяет варьировать входными данными для целей «накрытия» всех маршрутов на графе и ограничить шаг изменения непрерывных входных данных в области их определения, что существенно уменьшает количество отладочных вариантов работы ПО.
[Введите текст]
Такой подход позволяет целенаправленно исследовать внутреннюю структуру программы и является по своей сути детерминированным. Данный подход чаще применяется при разработке ПО, как гарантирующий более высокую отлаженность программ ПО при фиксированных сроках проведения отладки.
После проведения отладки ПО по принципу «белого ящика» целесообразно хотя бы для ряда программ проведение отладки по принципу «черного ящика» со статистическим перебором всех входных данных программы, что должно устранить возможные субъективные ошибки в оценке числа маршрутов на графе программы и оценке числа «особых точек» программы.
58. Структурная динамическая отладка
Полная динамическая отладка сложной программы на всех возможных наборах исходных данных по принципу "черного ящика" не реальна из-за огромного числа вариантов этих наборов. . Привлечение дополнительной информации по структуре ПО позволяет сократить объем работ по отладке.
Для проведения динамической отладки комплекса программ ПО необходимо задать входные данные, определяющие необходимые с точки зрения целей и плана отладки варианты функционирования ПО – тесты ПО.
Каждому набору исходных данных (тесту) соответствует графическое представление – один путь(маршрут) на графе программы по управлению.
Данный подход справедлив, как для ПО в целом, так и для каждой структурной единицы ПО. В первом случае в узлах графа ПК - программы, дуги графа - направления передачи управления - управляющие связи между программами. Для отдельно взятой программы в узлах графа находятся блоки программы, а дуги - передачи управления между блоками.
Правильная работа программы по одному пути, например, (а2, в2 на рис 15) еще не говорит ничего о правильности работы программы по другим путям на графе ( при другом наборе исходных данных),
например, а1, в1 с1; а1 в1 с2.
Для полной проверки правильности работы программы, таким образом, необходимо проверить правиль-
ность ее работы по всем путям на графе передач управления, но и этого недостаточно: надо убедиться,
что программа работает правильно во всем диапазоне исходных данных, возможных по условиям задачи.
Проверка по всем путям – маршрутам иногда заменяется накрытием всех межпрограммных связей, что несколько менее трудоемко, но дает меньшую уверенность в полноте отладки.
Считается, что программа отлажена полностью, если с помощью тестов получены результаты, которые, будучи сравнены с эталонными, свидетельствуют о правильном функционировании программы во всех возможных вариантах ее работы, то есть исполнены все возможные маршруты ее структурной логической схемы (маршруты графа по управлению) во всем диапазоне исходных данных, а также проверена правильность взаимодействия программы с ее программным и аппаратным окружением.
86
Рис.15 Пути на графе программы по управлению.
«Особые точки» при работе программ
Пусть F = A/(B-C) функция, реализуемая в узле 3. При этом часто В и С функции вычисляемые в программе и значения В и С и в частности их равенство не очевидны для программиста.
Правильное исполнение при каком-то наборе исходных данных приведенной функции F не гарантирует от ошибочного результата и остановки программы. Например, случай В = С приводит к неверному машинному результату. Квалифицированный программист сразу учтет особенность подобной функции и предусмотрит в программе алгоритмическую защиту - будет анализировать возможные значения В и С на величину
В - С 0
Данные В = С – данные в «особой точке» либо не должны задаваться, либо в этой точке вычисление F не должно производиться и F присваивается какое-либо значение, вытекающее из смысла задачи. К особым точкам программы надо относить все точки разрывов имеющиеся в вычисляемых функциях.
Надо специально анализировать программы на наличие особых точек – точек разрыва вычисляемых функций и т.п. Данный анализ должен проводиться на этапе автономной отладки каждой программы.
[Введите текст]
Анализ программы на особые точки и введение в них алгоритмической защиты позволяет сократить число вариантов отладки при варьировании данных на диапазоне изменения , увеличивая шаг изменения данных.
59. Автономная отладка (АО) и комплексная отладка (КО) ПО
Структурирование ПО упрощает не только понимание ПО и сложность его проектирования, но и позволяет общую задачу отладки ПО разделить на автономную отладку - отладку структурных единиц ПО – частей общей программы и на комплексную отладку - отладку взаимодействия между этими частями, которое реализуется путем информационных и управляющих связей. При этом для комплексной отладки проверка правильности внутренней работы каждой структурной единицы ПО уже не производится.
Например, для исчерпывающей полной отладки программы, имеющей 10 входов и три выхода (с булевыми переменными) необходимо исполнить N = 210 = 1024 проверок.
Действительно, в данном случае каждый тест – последовательность исходных данных из 10 членов.
Каждый член может принимать значение либо 1, либо 0. Число таких различных последовательностей 210.
В то же самое время, если удается представить эту программу (структурировать) в виде двух, связанных четырьмя связями модулей «блок 1» и «блок 2»( рис.16), на вход первого из которых поступает 6 внешних переменных, а на вход 2-го - 4 внешних переменных, то это дает всего 26 + 28 = 64 + 256 = 320 автономных проверок и 24 = 16 проверок взаимодействия между фрагментами, то есть всего 336 проверок, что в 3 раза меньше, чем в исходном случае.
Таким образом, свойственный человеческому интеллекту прием разбиения сложного на части, изучение независимо этих частей, а затем объединение уже освоенного (познанного) в единое целое, базируется на видимой из данного примера нелинейности роста сложности проверок от "объема" связей проверяемого или изучаемого объекта.
С другой стороны реально комплексные проверки обладают большей трудоемкостью при исполнении и существует некоторый оптимум в размере частей, на которые следует разбивать общую программу системной ЦВМ.
Т.е., если сравнение вести по критерию трудоемкости, то
Тр1 = N CPTPавт
Тр2 = NА CPTPавт. + NК CPTPкомп
Здесь NА - число вариантов АО, CPTPавт – средняя трудоемкость подготовки варианта исполнения АО соответственно NК - число вариантов КО, CPTPкомп – средняя трудоемкость подготовки и реализации варианта КО.
88