Тестирование и отладка локализация ошибок

Привет, Вы узнаете про виды ошибок программного обеспечения, Разберем основные ее виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое
виды ошибок программного обеспечения, принципы отладки , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

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

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

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

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

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

В процессе поиска ошибки мы обычно выполняем одни и те же действия:

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

Способы обнаружения ошибки:

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

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

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

Принципы локализации ошибок:

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

Принципы исправления ошибок еще больше похожи на законы Мерфи:

• Там, где найдена одна ошибка, возможно, есть и другие.
• Вероятность, что ошибка найдена правильно, никогда не равна ста процентам.
• Наша задача — найти саму ошибку, а не ее симптом.

Это утверждение хочется пояснить. Если программа упорно выдает результат 0,1 вместо эталонного нуля, простым округлением вопрос не решить. Если результат получается отрицательным вместо эталонного положительного, бесполезно брать его по модулю — мы получим вместо решения задачи ерунду с подгонкой.
Исправляя одну ошибку, очень легко внести в программу еще парочку. «Наведенные» ошибки — настоящий бич отладки.
Исправление ошибок зачастую вынуждает нас возвращаться на этап составления программы. Это неприятно, но порой неизбежно.

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

Силовые методы

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

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

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

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

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

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

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(a>c) then
writeln('Наибольшим оказалось второе число ',b:8:2)
else
writeln('Наибольшим оказалось третье число ',b:8:2);
end.

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

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

Данные Ожидаемый результат
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 после ввода (проверяем, правильно ли получили данные)
• — вывод значения каждого из условий (проверяем, правильно ли записали условия)

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

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.

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

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

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

Программа находит значение максимального из трех введенных чисел
Введите первое число -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

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

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

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

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

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

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

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

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

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 и с — максимальном. Зная эти подробности, мы можем заострить внимание на конкретных участках программы.

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

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

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

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

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

3) Непосредственное слежение:

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

Нынешние среды разработки часто предлагают нам реагировать на возникающую проблему в диалоговом режиме. При этом можно:

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

Рис Пример отладки приложения

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

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

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

• — ошибки обращения к данным,
• — ошибки описания данных,
• — ошибки вычислений,
• — ошибки при сравнении,
• — ошибки в передаче управления,
• — ошибки ввода-вывода,
• — ошибки интерфейса,
• и т д

Классификация ошибок по этапу обработки программы

рис Классификация ошибок этапа выполнения по возможным причинам

Синтаксические ошибки

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

Примеры синтаксических ошибок :

• отсутствие знака пунктуации;
• несоответствие количества открывающих и закрывающих скобок;
• неправильно сформированный оператор;
• неправильная запись имени переменной;
• ошибка в написании служебных слов;
• отсутствие условия окончания цикла;
• отсутствие описания массивов и т.п.

Ошибки, которые не обнаруживает транслятор

В случае правильного написания операторов в программе может присутствовать большое количество ошибок, которые транслятор не может обнаружить. Рассмотрим примеры таких ошибок:

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

Ошибки в циклах: неправильно указано начало цикла; неправильно указаны условия окончания цикла; неправильно указано количество повторений цикла; использование бесконечного цикла.

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

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

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

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

ошибки в архитектуре приложения пприводящие к увеличени технического долга

Методы (пути) снижение ошибок в программировании

• использование тестиования
• использование более простых решений
• использование систем с наименьшим числом составлящих
• использование ранее использованных и проверенных компонентов
• использование более квалифицрованных специалистов

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

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

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

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

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

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

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

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

• в компиляторе,
• операционной системе,
• аппаратной части,
• электропроводке в здании и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если исходить из алгоритма программы, мы должны составить следующие тесты:
ввод границ диапазона
— min< max
— min>max
ввод числа
— A < min (A<>0)
— A > max (A<>0)
— min <= A <= max (A<>0)
— A=0

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

10. Стратегии тестирования

1) Тестирование программы как «черного ящика».

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

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

«Черным ящиком» удобно тестировать небольшие подпрограммы.
2) Тестирование программы как «белого ящика».

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

На практике мы, как всегда, совместно используем оба принципа.
3) Тестирование программ модульной структуры.

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

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

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

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

Вау!! 😲 Ты еще не читал? Это зря!

• ошибки в приложениях , bugs , баг репорт , bug report ,
• Фича
• GIGO
• Патч
• тестирование
• цикломатическая сложность
• баг репорт
• качество программного обеспечения

К сожалению, в одной статье не просто дать все знания про виды ошибок программного обеспечения. Но я — старался.
Если ты проявишь интерес к раскрытию подробностей,я обязательно напишу продолжение! Надеюсь, что теперь ты понял что такое виды ошибок программного обеспечения, принципы отладки
и для чего все это нужно, а если не понял, или есть замечания,
то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории
Качество и тестирование программного обеспечения. Quality Assurance.

Содержание:

Введение

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

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

Разберем немного подробней каждый этап и немного определимся с терминологией:

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

Тестирование программного обеспечения — это процесс исследования программного обеспечения, в результате которого достигаются две цели:

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

Основным международным стандартом, определяющим качество программного обеспечения является стандарт ISO/IEC 25010:2011 (International Organization for Standardization ISO/IEC 25010:2011 [сайт] URL: https://www.iso.org/standard/35733.html ), в Российской Федерации эту функцию выполняет ГОСТ Р ИСО/МЭК 25010-2015, а функцию стандартизации тестирования программного обеспечения ГОСТ Р 56920-2016 (Федеральное агентство по техническому регулированию и метрологии ГОСТ Р 56920-2016 [сайт] URL: http://protect.gost.ru/document.aspx?control=7&id=203397).

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

1. Конечный поиск причин возникновения ошибки в программе
2. Устранение возникновения причин найденных ошибок

От надежного функционирования определенных типов программного обеспечения может зависеть успех бизнеса – работы финансовых и промышленных компаний – или даже… человеческая жизнь. Поэтому на его самое тщательное проектирование, разработку и тестирование не жалеют ни времени, ни денег. (Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Сэм Канер, Джек Фолк, Енг Кек Нгуен 2001. — 9с)

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

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

Теоретические аспекты отладки и тестирования ПО

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

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

Теория тестирования программного обеспечения

Критерии качества программного обеспечения

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

Так вот ответ на этот вопрос не так прост: качество программного обеспечения с точки зрения программиста и конечного пользователя сильно различается и несет в себе совсем различные критерии. Такие критерии делятся на два вида:

1. Внешние характеристики программного обеспечения — это такие характеристики, которые осознает, видит и воспринимает пользователь. Собственно говоря, это все, что волнует пользователя в программном продукте.
2. Внутренние характеристики программного обеспечения – это полная противоположность внешним характеристикам программного обеспечения, это то, что скрыто за занавесом и то, чего пользователь не видит, да, в общем то, видеть особенно не хочет. Эти характеристики в первую очередь волнуют программистов (внешние характеристики их тоже волнуют не меньше пользователя), так как это именно их среда деятельности и зона их ответственности.

Рассмотрим же теперь свойства, которые так или иначе подпадают под ту или другую характеристику.

К внешним характеристикам программного обеспечения относятся:

Корректность — отсутствие или наличие неточностей в спецификации, проекте и конечной реализации системы

Практичность — легкость обучения использованию системы и ее применение на практике

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

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

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

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

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

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

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

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

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

И так, к внутренним характеристикам программного обеспечения относятся:

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

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

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

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

Удобочитаемость — свойство, определяющее то, на сколько легко читать код программы и насколько легко понять его принцип действия, особенно это касается детального уровня чтения кода (на уровне операторов).

Тестируемость — потенциал программы к ее блочному и системному тестированию и проверки соответствия заявленным требованиям.

(Совершенный код / Стив Макконнелл 2010. – 456-458 с)

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

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

Таблица взята из книги Совершенный код / Стив Макконнелл 2010. – 458 с.

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

Методики проведения тестирования программного обеспечения

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

Первый метод тестирования, который мы рассмотрим, это Black-Box Testing (Functional) или же тестирование методом Черного Ящика (Функциональное тестирование). Основной принцип данного метода заключается в том, что тестирующий не имеет доступа к внутренним составляющим программы (коду и базам данных), к которым имеют доступ программисты и операторы баз данных, а имеет лишь доступ к тому функционалу управления, к которому имеет доступ обычный пользователь. Соответственно в таком режиме, тестирующий может лишь подавать какие-то данные на вход и анализировать информацию на выходе программы, в данной ситуации программа как будто и является тем самым магическим черным ящиком (с одной стороны в ящик что-то кладут, с другой забирают результат и анализируют принцип работы ящика). Такой метод тестирования хорош, когда надо проверить программу на соответствие заявленным функциональным требованиям, то есть способность программы решать поставленные пользователем задачи при определенных условиях.

Второй метод тестирования, это White-Box Testing (Structural) или же тестирование методом Белого Ящика (Структурное тестирование). Принцип этого метода полностью противоположен методу Черного Ящика и подразумевает, в первую очередь, анализ внутренних составляющих программного продукта. Данный метод может осуществляться только тестирующим со знанием используемого языка программирования и способного анализировать внутреннюю структуру программы. Тестирование методом Белого Ящика подразумевает, что тестирующий имеет полный доступ к коду и всем данным программы. Данная методика тестирования отлично подходит для внутреннего анализа и проверки и улучшения внутренних характеристик качества программного обеспечения.

Также существует смешанная методика проведения тестирования, называется она Gray-Box Testing (Functional and Structural), она же тестирование методом Серого Ящика. При использовании данного метода, предыдущие два метода объединяются в один. Часто такой метод осуществляется посредством коммуникаций между тестировщиками и разработчиками. Данный метод подразумевает комбинированный анализ внешних и внутренних характеристик качества программного продукта. (Software Testing and Continuous Quality Improvement, Second Edition – Уильям Е. Левис 2005. – 29-31 с)

1.2. Теория отладки программного обеспечения

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

1.2.1 Виды ошибок в программном обеспечении

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

1) противоречивые интерфейсы пользователя;

2) несоответствие ожиданиям;

3) низкая производительность;

4) аварийные завершения или искажение (разрушение) данных.

Разберемся с каждым видом отдельно. Первый вид это противоречивые интерфейсы пользователя, ошибки такого вида подразумевают наличие в программе элементов интерфейса или логики взаимодействия пользователя с программой, грубо нарушающие человеческую логику восприятия процессов, происходящих в программе, или же резкое отклонение от общепринятых стандартов построения интерфейса в программном обеспечении подобного типа. Ярким примером подобной ошибки является то, что в почтовой программе Microsoft Outlook нажатие сочетания горячих клавиш <Ctrl>+<F> открывает сообщение, в то время как пользователь ожидает увидеть открытие окна поиска, как это происходит в подавляющем количестве остального программного обеспечения, а особенно от компании Microsoft. Типичным способом избежать ошибок такого рода является своевременное изучение материалов и литературы, посвященных стандартизации пользовательских интерфейсов, например, издание «Microsoft Windows User Experience» (URL: https://www.microsoft.com/mspress/books/index/2466a.aspx) или «Интерфейс: новые направления в проектировании компьютерных систем» Автор Раскин Джефф.

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

Третий вид ошибок в программном обеспечении — это низкая производительность. Название говорит само за себя, никто не любит, когда новая программа на его компьютере начинает «виснуть» и «тормозить», хотя характеристики вычислительной машины соответствуют заявленным в системных требованиях программного продукта. В первую очередь такая проблема появляется в следствии халатности тестировщиков: тестирование продукта осуществляется на системе, характеристики которой далеки от заявленных или же от типичных характеристик систем, на которых данная программа обычно функционирует. Так же бывают ситуации, при которых тестирующие не имеют возможности или не хотят тестировать программу с реальным объемом данных, с которым ей предстоит работать в производственных условиях. Для профилактики и устранения данной проблемы применяется три основные методики:

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

Четвертый и последний вид ошибок, возникающих в процессе создания программного продукта, это аварийные завершения или искажение (разрушение) данных. Большинство пользователей вычислительных систем, говоря об ошибках, подразумевают в первую очередь как раз этот вид ошибок. Данный вид ошибок характеризуется полной остановкой выполнения программы и невозможностью дальнейшего ее использования. Также при возникновении такой ошибки возможны повреждения обрабатываемых данных. О причинах возникновения подобного рода ошибок судить сложно, это может быть и деление на ноль и запрос программой информации из того места памяти, где такой информации нет, в любом случае причины возникновения данных ошибок разнообразны и пути их решения, соответственно, тоже. Некоторые из них легко устранить, другие же практически не представляется возможным. Типичной ошибкой аварийного завершения является всем знакомый BSoD, он же Blue Screen of Death или в простонародье Синий Экран Смерти, возникающий в операционной системе Windows по ряду причин. Его вы можете видеть на рисунке ниже.

Синий экран смерти

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

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

Среди ошибок процесса разработки выделяют следующие категории:

1. Короткие или недопустимые предельные сроки разработки (возникновение данной ошибки связано с непониманием руководством реальных сроков разработки программного обеспечения и, как следствие, продукт выходит в производственную стадию «сырым», недоделанным)
2. Необдуманное программирование (целый комплекс ошибок, возникающий, когда программист вначале пишет код, а потом уже думает, как этот код работает. Решается составлением четкой структуры проекта до начала его реализации)
3. Неправильное понимание требований (та или иная ситуация, в которой требования заказчика к программному продукты были поняты исполнителем неправильно/не полностью/частично или как-то иначе, что в корне подорвало использование получившегося продукта)
4. Недостаточная подготовленность разработчика (подразумевается, что разработчик не до конца понимает все те технологии, которые будут использованы в процессе разработки конечного продукта. Но не спешите винить программиста, довольно часто это просто связано с появлением огромного количества новых систем, технологий, модулей и прочих нюансов разработки программного обеспечения в короткие промежутки времени и просто неуспеваемостью сотрудников догонять сразу все области, необходимые для качественной работы. Проблема может быть решена отправкой разработчиков на курсы повышения квалификации и выделение большего количества ресурсов на обучение и развитие их навыков)
5. Недостаточные обязательства по качеству (сюда включены все факторы, что не дают разработчикам производить действительно качественный программный продукт, будь то недостаточное финансирование технической части, неправильное распределение бюджета компании при выборе тех или иных инструментов для разработки и так далее)

(Отладка Windows приложений – Дж. Роббинс 2009. ДМК Пресс – 29-35 с)

1.2.2 Методики отладки программного обеспечения

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

1) Осуществление повторяющихся экспериментов с целью сбора данных и составления статистики

2) Выдвижение гипотезы, объясняющей собранные данные

3) Постановка ряда экспериментов, призванных подтвердить или опровергнуть сформировавшуюся гипотезу

4) На основе экспериментов вынести решение о подтверждении или опровержении гипотезы

5) Повторение предыдущих шагов в случае необходимости

(Совершенный код / Стив Макконнелл 2010. – 529 с)

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

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

2) Знание языка программирования, на котором выполнен проект.

3) Знание используемых в проекте технологий. Имеется ввиду COM, MFC, различные другие базовые технологии написания программ. Их знание и понимание принципов их работы значительно упростит отладку и сократив время, затрачиваемое на нее.

4) Знание операционной системы, на которой работает отлаживаемое приложение превратит блуждание в поисках ошибки в целенаправленный её поиск. Часто зная структуру и особенности той или иной операционной системы ошибки в приложениях найти значительно проще.

5) Знание работы центрального процессора. И последнее, что необходимо знать, это логика работы центрального процессора. Любое приложение можно отлаживать на языке программирования Assembler, что в некоторых ситуациях очень даже удобно. Не пожалейте немного своего времени и выучите этот язык, это не раз поможет вам быстро и легко что-то поправить в коде и устранить проблему в работе программы.

(Отладка Windows приложений / Джон Роббинс 2009. – 36-38 с)

Основываясь на вышесказанном, сделаем схему универсального алгоритма отладки приложений:

Схема алгоритма отладки программного обеспечения

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

Практические аспекты отладки и тестирования ПО

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

2.1. Практика тестирования программного обеспечения

На практике при тестировании программного обеспечения ошибка проходит 3 стадии:

1. Обнаружение ошибки
2. Описание ошибки
3. Передача описания ошибки для дальнейшего ее исправления

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

2.1.1 Отчеты об ошибках и системы их обработки

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

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

Раньше многие компании применяли различные примитивные методы обработки ошибок и их исправления – отчеты о проблемах передавались на бумажных носителях, а стадии их выполнения регистрировались в специальных журналах, но такие методы уже практически не используются в связи с быстрым ростом компьютеризации и появлением множества средств по автоматизации этого процесса. (Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Сэм Канер, Джек Фолк, Енг Кек Нгуен 2001. – 131-132с)

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

Одним из популярных багтрекеров на сегодняшний день является Bugzilla (URL: https://www.bugzilla.org/).

«Bugzilla — приложение для отслеживания ошибок. Приложения подобного рода позволяют разработчику или группам разработчиков отслеживать ошибки в приложениях и запросы на дополнение приложений новой функциональностью. Написанное на Perl, Bugzilla de-facto является стандартом для систем отслеживания ошибок в приложениях, служащая эталоном, с которой сравниваются другие системы со схожей функциональностью. Фактически, Bugzilla используется во многих корпорациях для разработки собственного программного обеспечения для корпоративных нужд.» пишут о Bugzilla ее разработчики. (Russian Mozilla Team URL: http://mozilla-russia.org/products/bugzilla/ )

Bugzilla используют многие крупные проекты, вот список самых известных из них:

Бесплатные проекты:

Веб-браузер Mozilla: https://bugzilla.mozilla.org/

Создатели ядра ОС Linux: http://bugzilla.kernel.org/

Рабочее окружение GNOME: http://bugzilla.gnome.org/

Рабочее окружение KDE: http://bugs.kde.org/

Веб-сервер Apache Project: https://bz.apache.org/bugzilla/

Офисный пакет LibreOffice: https://bugs.documentfoundation.org/

Офисный пакет Open Office: https://bz.apache.org/ooo/

Среда разработки Eclipse: http://bugs.eclipse.org/bugs/

Создатели следующих дистрибутивов ОС Linux:

Red Hat: https://bugzilla.redhat.com/

Gentoo: http://bugs.gentoo.org/

Novell: https://bugzilla.novell.com/

(Сайт Bugzilla URL: https://www.bugzilla.org/installation-list/ ).

Список отчетов об ошибках в Bugzilla

На рисунке выше вы можете видеть, как выглядит список обнаруженных ошибок в системе отслеживания ошибок Bugzilla. Каждой ошибке присвоен номер, также видно кто ее обнаружил, какой операционной системой он при этом пользовался и видно кратное описание самой ошибки. Например, под номером 457850 зафиксирована ошибка, при которой веб-браузер Firefox зависает при печати документа.

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

2.1.2 Основные инструменты тестировщика

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

1. Персональный компьютер, терминал или рабочая станция. В современном мире вообще что-либо редко делается без помощи компьютера, а у ж тем более разработка программного обеспечения. Для тестирования обязательно запаситесь одним таким, а лучше двумя, это резко повысит эффективность за счет того, что на одном будет запускаться тестируемая программа, а на втором система отслеживания ошибок, в которую вы будете прямо во время тестирования вносить информацию.
2. Текстовый редактор. Служит для вводы и редактирования руководств, планов тестирования, отчетов, записей, писем. Пользоваться текстовым редактором во время тестирования вы будете очень много, так что лучше позаботьтесь о выборе самого оптимального и удобного для вас варианта.
3. Процессор планов. Это программа, предназначенная для составления и редактирования информации в иерархическом структурированном виде с возможность сортировки, поиска и фильтрации. Удобна при составлении плана тестирования, списка функций, подробных отчетов и списков задач. Рекомендуется использовать отдельный специализированный процессор планов, а не те ограниченные версии, встроенные в текстовые редакторы.
4. Редактор электронных таблиц. Поможет вам составить необходимые таблицы для отчетов и прочей документации.
5. Утилиты для сравнения файлов. Выбор таких утилит достаточно богат. Их функция – сравнивать два файла и выводить список различий между ними, в случае обнаружения таковых. Самые лучшие образцы предлагают перечень действий, которые необходимо выполнить для получения из одного файла другого. Как правило такие программы поставляются вместе с операционными системами, например, в DOS это команда fc, а в Linux команда diff. Но функционал встроенных в операционную систему программ для сравнения файлов довольно скуден и если вы чувствуете его нехватку, то рекомендуется использовать программное обеспечение сторонних разработчиков. Также, стоит обратить внимание, что утилиты сравнения файлов бывают предназначены для сравнения разных типов файлов: двоичных файлов, изображений, текстовых файлов, архивов и других. От их назначения зависит формат вывода отчета после сравнения файлов, это нужно учитывать и использовать под каждую конкретную задачу утилиту, предназначенную для нее.
6. Просмотровики файлов. Это программы, предназначенные для просмотра информации внутри файлов самых разных форматов.
7. Конверторы файлов. Конверторы файлов предназначены для преобразования одного типа файлов в другой. Могут работать с различными видами файлов, будь то музыка, тексты, изображения, архивы и так далее. Например, можно с помощью такой программы конвертировать изображение из формата BMP в формат TIFF.
8. Утилиты для создания скриншотов. Это программы, предназначенные для создания копий экрана и сохранения их в файл на жесткий диск. Возможно на практике понадобится несколько таких программ, так как некоторые из них несовместимы с различными видами видеопотока. Эти средства очень удобны в работе, порой намного проще показать программисту снимок ошибки, нежели пытаться описать ее словами.
9. Утилиты поиска текста. Позволяют найти в исходном коде программы нужные строки. Простейшие варианты таких утилит встроены в текстовые редакторы.

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

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

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

13) Система отслеживания проблем. Да, это тоже считается инструментом для тестировщика, системы отслеживания проблем обсуждались в разделе «2.1.1 Отчеты об ошибках и системы их обработки».

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

(Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений / Сэм Канер, Джек Фолк, Енг Кек Нгуен 2001. – 265-266с)

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

2.1.3 Практические методы тестирования ПО

На практике, при тестировании программного обеспечения, необходимо понимать, что никакое разумное количество тестов не даст точной уверенности в том, что программа не имеет ошибок. Вызвано это тем, что тестирующий не в силах перебрать все возможные комбинации входных данных даже для маленькой программы. Например, для тестирования перебора всех входных данных для трех полей Фамилия (20 символов, 26 вариантов каждого символа), Адрес (20 символов, 26 вариантов каждого символа) и Номер телефона (10 символов, 10 вариантов каждой цифры) понадобится 10 в 66й степени тестов, что при переборе в триллион тестов в секунду с момента окончания Всемирного потопа, на данный было бы закончено на 1%. Поэтому стоит сконцентрировать свое внимание на самых эффективных тестах и самых слабых местах программы, куда скорее всего могли попасть ошибки. Для этого разработано и используются на практике несколько основных тестовых методик, каждая из которых применима в той или иной ситуации.

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

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

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

1. Стоит начать с единицы для последовательного пути выполнения метода
2. Необходимо прибавлять единицу для каждого из операторов if, while, repeat, for, and и or или их аналогов;

3) Необходимо прибавлять единицу для каждого блока case; если отсутствует блок по умолчанию, прибавляем еще единицу.

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

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

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

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

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

В заключение хочу сказать, что создавая тесты для программ, желательно придерживаться следующего правила: любой тест должен быть таким, чтобы его можно было проверить вручную и отбросить особенности работы ЭВМ, влияющие на качество выполнения теста в определенных условиях. (Совершенный код / Стив Макконнелл 2010. – 496-507 с)

2.2. Практика отладки программного обеспечения

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

2.2.1 Инструменты отладки программного обеспечения

Основным инструментом во время отладочного процесса является отладчик. Отладчик — это программа, позволяющая искать ошибки в других программах. К отладчикам, например, относится GNU Debugger, который позволяет отлаживать программы, написанные на языках программирования Ada, C, C++, Objective-C, Pascal и многих других языках. (URL: http://www.gnu.org/software/gdb/)

Но также, очень часто отладчики встроены непосредственно в среду разработки, например, в среды разработки Microsoft Visual Studio, Borland C++, Dev-C++, Android Studio, Atmel Studio и другие. Такой подход позволяет разработчикам не искать дополнительного отладочного программного обеспечения, а пользоваться уже встроенным.

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

(Отладка Windows приложений / Джон Роббинс 2009. – 102-103 с)

На рисунке изображено типичное окно отладчика

2.2.2 Практические методы отладки программного обеспечения

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

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

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

Определение источника ошибки может занять много времени, если не подходить к нему систематически. Например, если работа осуществляется со списком входных данных и некоторые элементы вызывают ошибку, а некоторые нет – необходимо попытаться сгруппировать их и отсеять в один вид те, что вызывают ошибку. Также необходимо обратить внимание на ту часть кода, которая обрабатывает те или иные входные данные. Что происходит с данными? Чем они связаны? Какой тип данных? Чем похожи? Каков объем данных, их содержание? Ответив на эти вопросы станет намного проще понять причину возникновения ошибки. Составляя гипотезу о возникновении ошибки, необходимо использовать все имеющиеся данные. Если текущая гипотеза проваливается при очередной попытке отладки, необходимо ее улучшить, добавив нюансы новых полученных данных.

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

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

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

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

Чтобы точнее определить происхождение ошибки, необходимо вызывать ее разными способами (рисунок взять из книги Совершенный код / Стив Макконнелл 2010. – 534с)

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

Результаты отрицательных тестов – это тоже результаты, ведь зная, что НЕ ВЫЗЫВАЕТ ошибку, остается больше вариантов что ее ВЫЗЫВАЕТ.

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

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

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

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

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

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

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

Осуществлять поиск распространенных ошибок – это очень хорошая практика. Для этого можно использовать контрольные списки качества кода.

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

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Сэм Канер, Джек Фолк, Енг Кек Нгуен Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений 2001

Стив Макконнелл Совершенный код 2010

Уильям Е. Левис Software Testing and Continuous Quality Improvement, Second Edition 2005

Дж. Роббинс Отладка Windows приложений 2009. ДМК Пресс

International Organization for Standardization ISO/IEC 25010:2011 [сайт] URL: https://www.iso.org/standard/35733.html

Федеральное агентство по техническому регулированию и метрологии ГОСТ Р 56920-2016 [сайт] URL: http://protect.gost.ru/document.aspx?control=7&id=203397

«Microsoft Windows User Experience» [сайт] URL: https://www.microsoft.com/mspress/books/index/2466a.aspx

Bugzilla [сайт] URL: https://www.bugzilla.org/

Russian Mozilla Team [сайт] URL: http://mozilla-russia.org/products/bugzilla/

GNU debugger homepage [сайт] URL: http://www.gnu.org/software/gdb/

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

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

В целом сложность отладки обусловлена следующими причинами:

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

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

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых.

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

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

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

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

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

•специфики управления используемыми техническими средствами,

•операционной системы,

•среды и языка программирования,

•реализуемых процессов,

•природы и специфики различных ошибок,

•методик отладки и соответствующих программных средств. 

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

Вцелом сложность отладки обусловлена следующими причинами:

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

•психологически дискомфортна, так как необходимо искать собственные ошибки и, как правило, в условиях ограниченного времени;

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

•отсутствуют четко сформулированные методики отладки.

Всоответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1):

    синтаксические ошибки — ошибки, фиксируемые компилятором (транслятором, интерпретатором) при выполнении синтаксического и частично семантического анализа программы; ошибки компоновки — ошибки, обнаруженные компоновщиком (редактором связей) при объединении модулей программы;

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

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

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

if (c = n) x = 0; /* в данном случае не проверятся равенство с и n, а выполняется присваивание с значения n, после чего результат операции сравнивается с нулем, если программист хотел выполнить не присваивание, а сравнение, то эта ошибка будет обнаружена только на этапе выполнения при получении результатов, отличающихся от ожидаемых */ 

Ошибки компоновки. Ошибки компоновки, как следует из названия, связаны с проблемами,

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

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

• появление сообщения об ошибке, зафиксированной схемами контроля выполнения машинных команд, например, переполнении разрядной сетки, ситуации «деление на ноль», нарушении адресации и т. п.;

•появление сообщения об ошибке, обнаруженной операционной системой, например, нарушении защиты памяти, попытке записи на устройства, защищенные от записи, отсутствии файла с заданным именем и т. п.;

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

•несовпадение полученных результатов с ожидаемыми.

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

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

•неверное определение исходных данных,

•логические ошибки,

•накопление погрешностей результатов вычислений (рис. 10.2).

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

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

Кпоследней группе относят:

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

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

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

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

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

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

опосредованного проявления ошибок;

возможности взаимовлияния ошибок;

возможности получения внешне одинаковых проявлений разных ошибок;

отсутствия повторяемости проявлений некоторых ошибок от запуска к запуску – так называемые стохастические ошибки;

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

написания отдельных частей программы разными программистами.

Методы отладки программного обеспечения

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

ручного тестирования;

индукции;

дедукции;

обратного прослеживания.

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

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

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

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

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

В процессе доказательства пытаются выяснить, все ли проявления ошибки объясняет данная гипотеза, если не все, то либо гипотеза не верна, либо ошибок несколько.

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

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