Файл: Отладка и тестирование программ: основные подходы и ограничени.pdf

Отладка программ заключается в проверке правильности работы программы и аппаратуры [3].

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

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

Для отладки программы можно воспользоваться одним из методов:

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

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

1. Пошаговая отладка программ с заходом в подпрограммы;
2. Пошаговая отладка программ с выполнением подпрограммы как одного оператора;
3. Выполнение программы до точки останова.

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

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

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

---

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

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

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

В свою очередь, весь спектр возможных ошибок в программных продуктах можно условно разделить на три категории [4]:

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

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

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

1. Стратегия тестирования и отладки

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

---

На данный момент, существует две основные стратегии тестирования:

• «черного ящика», при котором программа рассматривается как объект, внутрення структура которого неизвестна;
• «прозрачного (белого) ящика» предусматривает знание исходного кода программы и полный доступ к нему.

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

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

Основными методами тестирования ПО являются:

1. Метод Сандвича
2. Метод «белого ящика»
3. Метод «черного ящика»
4. Метод отладки программ

Перейдем подробнее к изучению методов тестирования.

• 1. Метод Сандвича

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

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

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

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

---

• 1. Метод «белого ящика»

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

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

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

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

2. Проверяют все логические решения на предмет того, истины они или ложны.

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

4. Исследуют структуры внутренних данных с целыо проверки их достоверности.

Тестирование посредством белого ящика [6], как правило, включает в себя стратегию модульного тестирования, при котором тестирование ведется на модульном или функциональном уровне и работы по тестированию направлены на исследование внутреннего устройства модуля. Данный тип тестирования называют также модульным тестированием, тестированием прозрачного ящика (clear box) или прозрачным (translucent) тестированием, поскольку сотрудники, проводящие тестирование, имеют доступ к программному коду и могут видеть работу программы изнутри. Данный подход к тестированию известен также как структурный подход.

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

Методы тестирования на основе стратегии белого ящика:

• Ввод неверных значений

При вводе неверных значений тестировщик заставляет коды возврата показывать ошибки и смотрит на реакцию кода. Это хороший способ моделирования определенных событий, например переполнения диска, нехватки памяти и т.д. Популярным методом является замена alloc() функцией, которая возвращает значение NULL в 10% случаев с целью выяснения, сколько сбоев будет в результате. Такой подход еще называют тестированием ошибочных входных данных. При таком тестировании проверяется обработка как верных, так и неверных входных данных. Тестировщики могут выбрать значения, которые проверяют диапазон входных/выходных параметров, а также значения, выходящие за границу диапазона.

---

• Модульное тестирование

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

• Тестирование обработки ошибок

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

• Утечка памяти

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

• Комплексное тестирование

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

---