Структурное тестирование

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

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

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

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

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

Для примера рассмотрим тест для DP 3A с входными данными XBZA. Очевидно, что все выражения будут выполнены, единственные части которые могут быть пропущены – операторы внутри выражений WHILE, для которых условие на входе равно FALSE.

Тестовый запуск программы 3B со входными данными CEDAR# проанализировать несколько более сложно. Для всех выражений WHILE выполняются части DO, но не понятно выполняются ли части THEN и ELSE внутри DP 3.2.1.1 В любом случае символ записан в F2, но это не дает нам информации, каким путем шло выполнение внутри оператора IF.

Часть THEN выполняется когда меняется текущий минимум, это происходит при первом проходе для CEDAR#, когда С заменяется на A при четвертой итерации для 3.2.1.1. С другой стороны, часть ELSE выполняется когда текущий минимум не меняется и это случается на второй итерации, когда C меньше чем E. Таким образом, CEDAR является адекватным структурным тестом. Анализ также показывает, что XHB# не может быть адекватным структурным тестом, поскольку часть ELSE для 3.2.1.1 не может быть достигнута.