Оптимизация, отладка и тестирование программ

Министерство образования и науки

российской федерации

ФГБОУ ВПО «ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

ФАКУЛЬТЕТ ВЕЧЕРНЕГО И ЗАОЧНОГО ОБУЧЕНИЯ

Кафедра высшей математики

И физико-математического моделирования

КУРСОВАЯ РАБОТА

По дисциплине «Информатика»

Тема: Оптимизация, отладка и тестирование программ

Выполнил студент ЛП-111              Р.С. Головенько

              группа              подпись              инициалы, фамилия

Руководитель              В.В. Пешков             

              подпись              инициалы, фамилия

Нормконтроль                           

              подпись              инициалы, фамилия

Защищена              Оценка              

Воронеж 2012

ЗАДАНИЕ

На курсовую работу по информатике

Специальность «Металлургия»

Тема: Оптимизация, отладка и тестирование программ.

Задачи:

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

2. В новой рабочей книге MS Excel создать таблицу результатов сессии для некоторой группы (внести 10-15 чел). Найти следующие показатели сессии: средний балл по итогам сессии для каждого студента; средний балл группы по каждому предмету; количество пятерок, четверок, троек, двоек по каждому предмету  (использовать функцию СЧЁТЕСЛИ); процент успеваемости группы по каждому предмету  (т.е. процент удовл. оценок и выше), процент качества  (т.е. процент хороших и отличных оценок). Построить диаграммы, отражающие относительное число отличных, хороших и т.д. оценок для группы по каждому предмету.

Содержание

Введение…………………………………………………………………………4

1. Оптимизация программ………………………………………………………5

2. Отладка и тестирование  программ …………………………………………8

3. Классификация ошибок в программах …..………………………………...22

4. Способы обнаружения ошибок..……………………………………………25

Заключение……………………………………………………………….……..26

Список используемых источников……………………………….………....…27

3

Введение

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

Отладка – специальный этап в разработке программы, состоящий

в выявлении и устранении программных ошибок, факт существования которых уже установлен.

Тестирование – процесс выполнения программы (или части программы) с намереньем (или целью) найти ошибки

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

4

1.  Оптимизация программ

Всегда желательно иметь компилятор, который создает эффективно работающие объектные программы. Как правило, программа в кодах машины, полученная в результате трансляции, будет занимать больший объем памяти и работать медленнее, чем такая же программа, написанная опытным программистом. Термин "оптимизация" применяется к попыткам сделать выходные программы более "эффективными", т.е. быстрее работающими или более компактными. Таким образом, оптимизацией называется улучшение выходной программы, а часть транслятора, выполняющая эту функцию
- оптимизирующей частью транслятора.
Оптимизирующая часть транслятора выполняет следующие
действия:
1. Устраняет недостатки программы, вызванные небрежностью или низкой квалификацией программиста. Примером может служить вынесение из цикла операторов, не зависящих от управляющих переменных цикла, что приведет к сокращению времени выполнения программы, поскольку вынесенные операторы будут выполняться только один раз, а не многократно.
2. Устраняет излишние вычисления, неизбежно возникающие в процессе трансляции даже при самом тщательном написании программы на языке высокого уровня. Например, устранение повторного вычисления индексных выражений для элементов массива сокращает время выполнения программы и ее длину. 
              Промежуточный язык.
Для повышения эффективности программы можно произвести над ней последовательность преобразований в различные моменты процесса компиляции. Например, можно оперировать с входной программой, со структурами, порождаемыми на стадии синтаксического анализа, с кодом, порождаемым в качестве выхода фазы генерации кода. Однако оптимизировать программу, уже протранслированную в коды машины, трудно по следующим причинам:
во-первых, единицы действия программы в кодах команд слишком мелки, что уже само по себе затрудняет анализ,
во-вторых, при трансляции входной программы в коды машины возможна потеря имеющейся в ней информации. Например, засылка промежуточных результатов в разные рабочие ячейки памяти делает практически невозможной идентификацию одинаковых частей программы;
 

5

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

6

              Помимо программы на промежуточном языке, состоящей из последовательности операторов, для проведения оптимизации формируются следующие таблицы:
1. Таблицы идентификаторов и констант с обычной информацией о переменных и константах.
2. Таблица блоков, определяющая номера блоков (блоки нуме-
руются в произвольном порядке), их границы, непосредственно предшествующие и следующие блоки, а также любую информацию о частоте повторения блока.
3. Таблица последовательности операторов, определяющая линейную последовательность операторов в блоке. Она содержит последовательность указателей операторов mi. Эта таблица необходима, поскольку один указатель может принадлежать нескольким операторам. 
3.Элементы топологии программы .

Вопросы оптимизации обычно связаны с топологией программы, т.е. со способом ее построения. Для того, чтобы локализовать процессы оптимизации и не связывать их с конкретным входным языком, они проводятся внутри отдельных участков программы, называемых блоками и сильно связанными областями.
              Блок (линейный участок) - выполняемая по порядку последовательность операторов, имеющая единственную точку входа - первый оператор с меткой, на который может быть передано управление, и единственную точку выхода - последний оператор.
Формально модель линейного участка может быть представлена следующим образом:
блок B - это тройка вида (P,I,U),где
(1) P - список операторов S1,S2,...Sn (n>=0),
(2) I - множество входных переменных,
(3) U - множество выходных переменных.
При этом оператором называется цепочка (в общем случае) вида
A 
где A,B1,...,Br - переменные,Q - операция.
Здесь оператор присваивает значение переменной А и ссылается на B1,...,Br.
Если оператор Sj ссылается на А, то либо А - входная переменная, либо осуществлено присваивание ей значения некоторым оператором до Sj, (т. е. некоторым оператором Si.
Оператор S в программе называется входом в линейный участок, если он либо первый оператор в программе, либо помечен идентификатором, появляющимся в операторе перехода, либо непосредственно следует за условным оператором.
Линейный участок, относящийся к входу в участок S, состоит из S и всех операторов, следующих за ним вплоть до оператора останова, включая его, или вплоть до входа в следующий блок. 

7

2. Отладка и тестирование  программ

1. Отладка программы

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

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

2. Локализация ошибок

Локализация - это нахождение места ошибки в программе.

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

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

Оба способа по-своему удобны и обычно используются совместно.

8

3. Принципы отладки

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

Принципы исправления ошибок еще больше похожи на законы Мерфи:
Там, где найдена одна ошибка, возможно, есть и другие.
Вероятность, что ошибка найдена правильно, никогда не равна ста процентам.
Наша задача - найти саму ошибку, а не ее симптом.
Это утверждение хочется пояснить. Если программа упорно выдает результат 0,1 вместо эталонного нуля, простым округлением вопрос не решить. Если результат получается отрицательным вместо эталонного положительного, бесполезно брать его по модулю - мы получим вместо решения задачи ерунду с подгонкой.
Исправляя одну ошибку, очень легко внести в программу еще парочку. "Наведенные" ошибки - настоящий бич отладки.
Исправление ошибок зачастую вынуждает нас возвращаться на этап составления программы. Это неприятно, но порой неизбежно.

9

4. Методы отладки

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

С точки зрения "правильного" программирования силовые методы плохи тем, что не поощряют анализ задачи.

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

10

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

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

var
a, b, c: real;
begin
writeln('Программа находит значение максимального из трех введенных чисел');
write('Введите первое число '); readln(a);
write('Введите второе число '); readln(b);
write('Введите третье число '); readln(c);
if (a>b)and(a>c) then
writeln('Наибольшим оказалось первое число ',a:8:2)
else if (b>a)and(<strong>a</strong>>c) then
writeln('Наибольшим оказалось второе число ',b:8:2)
else
writeln('Наибольшим оказалось третье число ',<strong>b</strong>:8:2);
end.

11

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

Тестовые наборы данных должны учитывать все варианты решения, поэтому выберем следующие наборы чисел:

Данные                    Ожидаемый результат
a=10; b=-4; c=1       max=a=10
a=-2; b=8; c=4         max=b=8
a=90; b=0; c=90.4  max=c=90.4

В результате выполнения программы мы, однако, получим следующие результаты:
Для a=10; b=-4; c=1:

Наибольшим оказалось первое число 10.00

Для a=-2; b=8; c=4: < pre class=list>Наибольшим оказалось третье число 8.00Для a=90; b=0; c=90.4:

Наибольшим оказалось третье число 0.00

Вывод во втором и третьем случаях явно неверен. Будем разбираться.

1. Трассировка и промежуточная печать

Добавляем промежуточную печать:
- вывод a, b, c после ввода (проверяем, правильно ли получили данные)
- вывод значения каждого из условий (проверяем, правильно ли записали условия)

12

Листинг программы существенно увеличился и стал вот таким:

var
a, b, c: real;
begin
writeln('Программа находит значение максимального из трех введенных чисел');
write('Введите первое число '); readln(a);
writeln('Вы ввели число ',a:8:2); {отл.печать}
write('Введите второе число '); readln(b);
writeln('Вы ввели число ',b:8:2); {отл.печать}
write('Введите третье число '); readln(c);
writeln('Вы ввели число ',c:8:2); {отл.печать}
writeln('a>b=',a>b,', a>c=',a>c,', (a>b)and(a>c)=',(a>b)and(a>c)); {отл.печать}
if (a>b)and(a>c) then
writeln('Наибольшим оказалось первое число ',a:8:2)
else begin
writeln('b>a=',b>a,', b>c=',b>c,', (b>a)and(b>c)=',(b>a)and(b>c)); {отл.печать}
if (b>a)and(a>c) then
writeln('Наибольшим оказалось второе число ',b:8:2)
else
writeln('Наибольшим оказалось третье число ',b:8:2);
end;
end.

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

Но давайте считать, что глаз "замылен" совершенно, и найти ошибку не удалось.

Вывод для второго случая получается следующим:

13

Программа находит значение максимального из трех введенных чисел
Введите первое число -2
Вы ввели число -2.00
Введите второе число 8
Вы ввели число 8.00
Введите третье число 4
Вы ввели число 4.00
a>b=FALSE, a>c=FALSE, (a>b)and(a>c)=FALSE
b>a=TRUE, b>c=TRUE, (b>a)and(b>c)=TRUE
Наибольшим оказалось третье число 8.00

Со вводом все в порядке. Впрочем, в этом сомнений и так было немного. А вот что касается второй группы операторов печати, то картина вышла интересная: в результате выводится верное число (8.00), но неправильное слово ("третье", а не "второе").

Вероятно, проблемы в выводе результатов. Тщательно проверяем текст и обнаруживаем, что действительно в последнем случае выводится не c, а b. Однако к решению текущей проблемы это не относится: исправив ошибку, мы получаем для чисел -2.0, 8.0, 4.0 следующий результат.

Наибольшим оказалось третье число 4.00

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

2. Метод индукции

Судя по результатам, ошибка возникает, когда максимальное число - второе или третье (если максимальное - первое, то определяется оно правильно, для доказательства можно програть еще два-три теста).

Просматриваем все, относящееся к переменным b и с. Со вводом никаких проблем не замечено, а что касается вывода - то мы быстро натыкаемся на замену b на с. Исправляем.

Как видно, невыявленные ошибки в программе остаются. Просматриваем расчетный блок: все, что относится к максимальному b (максимум с получается "в противном случае"), и обнаруживаем пресловутую проблему "a>c" вместо "b>c". Программа отлажена.

14

3. Метод дедукции

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

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

4. Обратное движение по алгоритму

Зная, что ошибка возникает при выводе результатов, рассматриваем код, начиная с операторов вывода. Сразу же находим лишнюю b в операторе writeln.

Далее, смотрим по конкретной ветке условного оператора, откуда взялся результат. Для значений -2.0, 8.0, 4.0 расчет идет по ветке с условием if (b>a)and(a>c) then... где мы тут же обнаруживаем искомую ошибку.

5. Тестирование

В нашей задаче для самого полного набора данных нужно выбрать такие переменные, что
a > b > c
a > c > b
b > a > c
b > c > a
c > a > b
c > b > a

Анализируя получившиеся в каждом из этих случаев результаты, мы приходим к тому, что проблемы возникают при b>c>a и с - максимальном. Зная эти подробности, мы можем заострить внимание на конкретных участках программы.

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

15

5. Средства отладки

Помимо методик, хорошо бы иметь представление о средствах, которые помогают нам выявлять ошибки. Это:

1) Аварийная печать - вывод сообщений о ненормальном завершении отдельных блоков и всей программы в целом.

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

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

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

16

6. Классификация ошибок

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

7. Советы отладчику

1) Проверяйте тщательнее: ошибка скорее всего находится не в том месте, в котором кажется.

2) Часто оказывается легче выделить те места программы, ошибок в которых нет, а затем уже искать в остальных.

3) Тщательнее следить за объявлениями констант, типов и переменных, входными данными.

4) При последовательной разработке приходится особенно аккуратно писать драйверы и заглушки - они сами могут быть источником ошибок.

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

17

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

7) Ошибка, скорее всего окажется вашей и будет находиться в тексте программы. Гораздо реже она оказывается:
в компиляторе,
операционной системе,
аппаратной части,
электропроводке в здании и т.д.

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

8) Убедитесь, что исходный текст программы соответствует скомпилированному объектному коду (текст может быть изменен, а запускаемый модуль, который вы тестируете - скомпилирован еще из старого варианта).

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

10) Старайтесь не жалеть времени, чтобы уясненить причину ошибки. Это поможет вам:
исправить программу,
обнаружить другие ошибки того же типа,
не делать их в дальнейшем.

11) Если вы уже знаете симптомы ошибки, иногда полезно не исправлять ее сразу, а на фоне известного поведения программы поискать другие ляпы.

12) Самые труднообнаруживаемые ошибки - наведенные, то есть те, что были внесены в код при исправлении других.

18

8. Тестирование

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

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

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

2) При прогоне программы по тестовым начальным данным, полученные результаты нужно сверить с эталонными и проанализировать разницу, если она есть.

3) При разработке тестов нужно учитывать не только правильные, но и неверные исходные данные.

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

5) Тестирование нужно планировать: заранее выбрать, что мы контролируем и как это сделать лучше. Обычно тесты планируются на этапе алгоритмизации или выбора численного метода решения. Причем, составляя тесты, мы предполагаем, что ошибки в программе есть.

6) Чем больше ошибок в коде мы уже нашли, тем больше вероятность, что мы обнаружим еще не найденные.
Хорошим называют тест, который с большой вероятностью должен обнаруживать ошибки, а удачным - тот, который их обнаружил.

19

9. Проектирование тестов

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

Давайте рассмотрим задачу: нужно проверить, попадает ли введенное число в заданный пользователем диапазон.

program Example;
(******************************************************
* Задача: проверить, попадает ли введенное число в *
* заданный пользователем диапазон *
******************************************************)

var
min, max, A, tmp: real;
begin
writeln('Программа проверяет, попадают ли введенные пользователем');
writeln('значения в заданный диапазон');
writeln;
writeln('Введите нижнюю границу диапазона '); readln(min);
writeln('Введите верхнюю границу диапазона '); readln(max);
if min>max then begin
writeln('Вы перепутали диапазоны, и я их поменяю');
tmp:=min;
min:=max;
max:=tmp;
end;
repeat