Глава 15. Комплексное тестирование. Отладка

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

Методика комплексного тестирования ПС

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

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

Охарактеризуем каждый шаг процесса тестирования.

1. Тестирование элементов. Цель – индивидуальная проверка каждого модуля. Используются способы тестирования «белого ящика».

2. Тестирование интеграции. Цель – тестирование сборки модулей в программную систему. В основном применяют способы тестирования «чёрного ящика».

3. Тестирование правильности. Цель –проверить реализацию в программной системе всех функциональных и поведенческих требований, а также требования эффективности. Используются исключительно способы тестирования «чёрного ящика».

4. Системное тестирование. Цель – проверка правильности объединения и взаимодействия всех элементов компьютерной системы, реализации всех системных функций.

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

Ответ практика обычно основан на статистическом критерии: «Можно с 95% уверенностью сказать, что провели достаточное тестирование, если вероятность безотказной работы ЦП с программным изделием в течение 1000 часов составляет, по меньшей мере, 0,995».

Научный подход при ответе на этот вопрос состоит в применении математической модели отказов. Например, для логарифмической модели Пуассона формула расчёта текущей интенсивности отказов имеет вид:

где λ(t) – текущая интенсивность программных отказов (количество отказов в единицу времени); λ0 – начальная интенсивность отказов (в начале тестирования); p – экспоненциальное уменьшение интенсивности отказов за счёт обнаруживаемых и устраняемых ошибок; t – время тестирования. С помощью управления можно предсказать снижение ошибок в ходе тестирования, а также время, требующееся для достижения допустимо низкой интенсивности отказов.

Системный анализ

Анализ требований

Проектирование

Кодирование

Тестирование элементов

Тестирование интеграции и

Тестирование правильности

Системное тестирование

Рис.1.Спираль процесса тестирования ПС

Тестирование элементов

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

Тестирования подвергаются:

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

Интерфейс модуля тестируется для проверки правильности ввода-вывода тестовой информации. Если нет уверенности в правильном вводе-выводе данных, нет смысла проводить другие тесты.

Исследование внутренних структур данных гарантирует целостность сохраняемых данных.

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

Наиболее общими ошибками вычисления являются:

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

2) смешанная форма операций;

3) некорректная инициализация;

4) несогласованность в представлении точности;

5) некорректное символическое представление выражений.

Источниками ошибок сравнения и неправильных потоков управленияявляются:

1) сравнение различных типов данных;

2) некорректные логические операции и приоритетность;

3) ожидание эквивалентности в условиях, когда ошибки точности делают эквивалентность невозможной;

4) некорректное сравнение переменных;

5) неправильное прекращение цикла;

6) отказ в выходе при отклонении итерации;

7) неправильное изменение переменных цикла.

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

1) донесение об ошибке не вразумительно;

2) текст донесения не соответствует обнаруженной ошибке;

3) вмешательство системных средств регистрации аварии произошло до обработки ошибке в модуле;

4) обработка исключительного условия некорректна;

5) описание ошибки не позволяет определить её причину.

Граничное тестирование. Модули часто отказывают на «границах». Это означает, что ошибки часто происходят:

1) при обработке n-го элемента n-элементного массива;

2) при появлении минимального (максимального) значения.

Тестовые ситуации, ориентированные на данные ситуации, имеют высокую вероятность обнаружения ошибок.

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

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

(In Data) и ожидаемые результаты (ExpRes) тестовых вариантов, запускает в работу тестируемый модуль, получает из модуля реальные результаты (OutData) и формирует донесения о тестировании. Алгоритм работы тестового драйвера приведен на рис. 3.

Рис. 2. Программная среда для тестирования модуля

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

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

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

Рис. 3.Алгоритм работы драйвера тестирования

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

Тестирование интеграции

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

Тесты проводятся для обнаружения ошибок интерфейса. Перечислим некоторые категории ошибок интерфейса:

· потеря данных при прохождении через интерфейс;

· отсутствие в модуле необходимой ссылки;

· неблагоприятное влияние одного модуля на другой;

· подфункции при объединении не образуют требуемую главную функцию;

· отдельные (допустимые) неточности при интеграции выходят за допустимый уровень;

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

Существует два варианта тестирования, поддерживающих процесс интеграции: нисходящее тестирование и восходящее тестирование. Рассмотрим каждый из них.