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

- на практике они используются чаще, т.к. процедура обычно задает обобщенную (типовую) схему обработки для различных значений исходных данных;

- смысл процедуры легче понять, если в заголовке собрана вся информация об интерфейсе процедуры. Нет необходимости просматривать текст с алгоритмом процедуры;

- если в процедуре нет глобальных параметров, то процедура является независимой от вызывающей программы, т.к. связь осуществляется только через формальные параметры. Такую процедуру легче тестировать;

- чистая процедура является более надежной, т.к. контроль параметров осуществляется Паскаль-системой.

2. Глобальные переменные в процедуре целесообразно использовать в след. Основных случаях:

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

- когда абстракция раскрывается в виде сегмент-блока, то этот блок можно выделить в виде процедуры без параметров, а не подставлять на место абстракции как фрагмент программы.

_____________________________________________________________________________________

Билет №36

Цель и содержание отладки программы. Классификация ошибок. Уровни корректности программы в процессе отладки.

_____________________________________________________________________________________

Билет №37

Основные действия при отладке. Контроль программы.Фазы контроля.

Действия при отладке:

Отладка состоит из 3-х взаимосвязанных действий:

- контроль правильности программы;

- локализация ошибок, обнаруженных в процессе контроля;

- исправление ошибок.

Перечисленные действия могут многократно повторяться.

Контроль программы - важнейший этап отладки; цель его – обнаружение ошибок. Методика отладки отражает последовательность применения различных методов контроля и состоит из следующих фаз:

1) визуальный контроль текста программы;

2) синтаксический контроль;

3) контроль ограничений структурного программирования;

4) статический семантический контроль;

5) тестирование программы на специально подбираемых тестах.

С точки зрения использования ЭВМ, первая и четвертая фазы относятся к ручному контролю (без ЭВМ), вторая и пятая - к автоматическому (с использованием ЭВМ), а третья - к ручному контролю, если специальных инструментальных средств нет, и к автоматическому - в противном случае. Важно, что приблизительно 55% ошибок выявляется без применения ЭВМ в результате отладки "за столом".

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

ВИЗУАЛЬНЫЙ КОНТРОЛЬ:

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

1) Обращение к данным.

2) Описание данных.

3) Вычисления.

4) Операции сравнения.

5) Передачи управления.

6) Межмодульный интерфейс.

7) Инструкция ввода-вывода.

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

СИНТАКСИЧЕСКИЙ КОНТРОЛЬ:

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

КОНТРОЛЬ ОГРАНИЧЕНИЙ СТРУКТУРНОГО ПРОГРАММИРОВАНИЯ :

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

СЕМАНТИЧЕСКИЙ КОНТРОЛЬ:

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

- недостижимая инструкция, т.е. инструкция, к которой не ведет ни один путь в программе;

- неправильный порядок инструкций ввода-вывода;

- неинициированная переменная, т.е. переменная, которой не было присвоено значение хотя бы на одном пути;

- наличие переменных, которые были описаны, но не используются ни в одной инструкции;

- отсутствие изменения переменных, которые определяют условие завершения цикла.

Статический семантический контроль может быть совмещен с визуальным контролем, если нет специальных инструментальных средств для его автоматизации.

_____________________________________________________________________________________

Билет №38

Характеристика восходящего и нисходящего способов отладки.

Тест - совокупность специально подобранных входных данных и соответствующих им выходных данных, используемых для контроля правильности работы программы.

Тестовые результаты лучше получать путем, отличным от реализованного в программе.

Тестирование - испытание программы на множестве тестовых ситуаций с целью обнаружения ошибок.

Подготовка тестирования включает два шага:

- проектирование тестов;

- подготовка программы для тестирования (вставка дополнитель¬ных печатей, специальных операторов и т.д.).

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

Содержание теста определяется спецификацией задачи и логикой ее решения. Поэтому разработка тестов должна предшествовать этапу кодирования алгоритма и осуществляться параллельно с проектированием алгоритма.

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

Способы тестирования:

В основе различных методов тестирования лежат два способа: восходящее и нисходящее тестирование.

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

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

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

- сообщение о том, что она вызвана;

- полученные входные данные;

- выдаваемые выходные данные.

После окончания отладки головного модуля проводится проектирование и отладка сегментов первого уровня, а заглушки заменяются текстами соответствующих построенных алгоритмов. При этом драйвером для сегментов является головной модуль.

Процесс тестирования так же, как и процесс проектирования, продолжается до тех пор, пока не будут раскрыты все абстракции (устранены все заглушки).

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

При проведении тестирования рекомендуется выполнять следующие общие правила.

1. В первую очередь лучше тестировать сегменты, осуществляющие ввод и вывод данных.

2. Рекомендуется одновременно раскрывать те абстракции, которые целесообразно тестировать совместно: ввод-вывод, обработка-вывод, ввод-обработка-вывод и др. В то же время раскрывать такую пару, как ввод-обработка, нецелесообразно, так как потребуются дополнительные инструкции вывода только для целей отладки.

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

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

_____________________________________________________________________________________

Билет №39

Локализация и исправление ошибок в процессе отладки в Турбо-среде.

Ошибки в программе могут проявиться двумя способами:

1) во время выполнения программы в виде исключительных ситуаций,

2) после выполнения программы в виде неправильного решения.

Отладка - это процесс поиска и исправления ошибок в программе

Цель отладки - получение правильной программы, т.е. программы, в которой отсутствуют ошибки проекта. Ошибки проекта включают ошибки, которые могут возникнуть на всех этапах разработки программы.

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

Процесс отладки состоит из трех этапов:

- контроль правильности программы,

- локализация ошибок, обнаруженных в процессе контроля,

- исправление ошибок.

МЕТОД ТРАССИРОВКИ:

Цель метода - локализация ошибки, т.е. обнаружение точного места в программе, где находится источник ошибки. Суть этого метода состоит в пошаговом выполнении всех действий, которые предписаны программой.

Трассировка может являться способом визуального контроля и выполняться без помощи компьютера, а также может выполняться с помощью компьютера.

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

В качестве примера рассмотрим фрагмент программы: нахождение максимального значения в последовательности, которая вводится из файла fin.

fin

3 7 4

xmax:= -99;

while not eof (fin) do

begin read (fin,x);

if x>xmax then

xmax:= x;

end;

Табличка:

xmax -> x

-99 -> 3

3 -> 7

7 -> 4

7 -> -

Для того, чтобы локализовать методом трассировки ошибку, найденную при тестировании, можно сравнить результаты ручного просчета со значениями, получаемыми с помощью компьютера. Это можно сделать двумя способами:

1. Вставка в программу отладочной печати промежуточных данных.

2. Использование средств отладки Турбо Паскаля.

Рассмотрим способ 2. Для того, чтобы провести трассировку программы, надо:

- открыть отладочное окно Watch с помощью опции Debug/Watch;

- записать в отладочное окно имена интересующих переменных: для добавления каждой переменной надо установить опцию Debug/Add Watch (или Ctrl-F7), открывающую окно Add Watch, записать имя переменной и выполнить ОК.

Теперь можно выполнять трассировку, продвигаясь по программе с использованием функциональных клавиш F7, F8, F4 и следя за изменением значений переменных в окне Watch. При каждом нажатии F7 и F8 выполняется одна строка программы, но F8 обходит процедуры. При F4 начинается или продолжается выполнение программы до той строки, на которой стоит курсор.

Для тестирования логики программы используются методы структурного тестирования. Качество структурного тестирования определяется тем, насколько полно проверена логика программы. (метод тестовых счетчиков)

_____________________________________________________________________________________

Билет №40

Функциональное и структурное тестирование.

Метод тестовых счетчиков.

Способы тестирования:

Существуют два основных подхода к тестированию отдельного модуля: функциональное и структурное тестирование.

При функциональном тестировании программный модуль рассматривается как черный ящик, его внутренняя структура не учитывается. При структурном тестировании выбор тестовых ситуаций определяется структурой программы.

ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ:

Цель функционального тестирования - найти расхождение между программой и ее внешними спецификациями. Необходимым условием успешного функционального тестирования является наличие четких и точных внешних спецификаций. При функциональном подходе исчерпывающее тестирование реальных задач невозможно из-за огромного числа комбинаций входных и выходных данных. Задачей тестирования является выделение наиболее реальных ситуаций и пренебрежение малозначительными ситуациями.

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

При проектировании функциональных тестов, надлежит выполнить следующие рекомендации

1) Просматривая разделы "Входные данные". "Аномалии" принимать во внимание область определения входных данных. Тесты рекомендуется строить для допустимых, граничных и недопустимых значений входных данных.

2) Просматривая раздел "Выходные данные", установить функциональные границы, которые будут определяться областью значений результатов. Построить тесты, учитывая эти функциональные границы.

СТРУКТУРНОЕ ТЕСТИРОВАНИЕ:

Качество структурного тестирования определяется степенью, в какой тесты покрывают логику программы. Критерий исчерпывающего тестирования - это выполнение каждого пути программы (т.е. последовательности инструкций от начала до конца программы). Реально тестирование всех путей программы практически неосуществимо, так как число путей при наличии циклов может быть бесконечно большим. Поэтому вместо полного тестирования реализуемый и достаточно надежный критерий тестирования ветвей: каждая ветвь алгоритма должна быть пройдена хотя бы один раз.

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

Тестовые наборы данных готовятся, как правило, вручную. Подготовка программы для тестирования зависит от метода тестирования.

МЕТОД ТЕСТОВЫХ СЧЕТЧИКОВ:

Суть метода состоит в том, что в начало и конец алгоритма, в начало и конец циклов, а также в каждую ветвь алгоритма вставляется "счетчик" - некоторая переменная. В начале алгоритма все счетчики обнуляются.

При выполнении алгоритма на некотором тестовом наборе значение счетчика увеличивается на единицу при каждом прохождении участка куда вставлен этот счетчик.

Набор тестов должен быть таким, чтобы при выполнении всей совокупности тестов этого набора каждый из счетчиков хотя бы один раз изменял свое значение.

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

_____________________________________________________________________________________

Билет №41

Документирование программ в процессе разработки. Состав документации.

Документирование программы:

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

Документация на разработанную программу включает следующие части: