Тестирование информационных систем (стр. 5 из 9)
ГЛАВА 2. МЕТОДЫ ТЕСТИРОВАНИЯ.
2.1. Тестирование «белого ящика»
Известна: внутренняя структура программы.
Исследуются: внутренние элементы программы и связи между ними.
Объектом тестирования здесь является не внешнее, а внутреннее поведение программы. Проверяется корректность построения всех элементов программы и правильность их взаимодействия друг с другом. Обычно анализируются управляющие связи элементов, реже – информационные связи. Тестирование по принципу «белого ящика» характеризуется степенью, в которой тесты выполняют или покрывают логику (исходный текст) программы. Исчерпывающее тестирование затруднительно.
Особенности тестирования «белого ящика».
Обычно тестирование «белого ящика» основано на анализе управляющей структуры программы. Программа считается полностью проверенной, если проведено исчерпывающее тестирование маршрутов (путей) ее графа управления.
В этом случае формируются тестовые варианты, в которых:
· Гарантируется проверка всех независимых маршрутов программы.
· Находятся ветви True, False для всех логических решений.
· Выполняются все циклы (в пределах их границ и диапазонов).
· Анализируется правильность внутренних структур данных.
Недостатки тестирования «белого ящика»:
· Количество независимых маршрутов может быть очень велико. Например, если цикл в программе выполняется k раз, а внутри цикла имеется n ветвлений, то количество маршрутов вычисляется по формуле
.При n=5 и k=20 количество маршрутов m=1014. Примем, что на разработку, выполнение и оценку теста по одному маршруту расходуется 1 мс. Тогда при работе 24 часа в сутки 365 дней в году на тестирование уйдет 3170 лет.
· Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.
· В программе могут быть пропущены некоторые маршруты.
· Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных.
Достоинства тестирования «белого ящика» связаны с тем, что принцип «белого ящика» позволяет учесть особенности программных ошибок:
· Количество ошибок минимально в «центре» и максимально на «периферии» программы.
· Предварительные предположения о вероятности потока управления или данных в программе часто бывают некорректны. В результате типовым может стать маршрут, модель вычислений по которому проработана слабо.
· При записи алгоритма программного обеспечения в виде текста на языке программирования возможно внесение типовых ошибок трансляции (синтаксических и семантических).
· Некоторые результаты в программе зависят не от исходных данных, а от внутренних состояний программы.
Каждая из этих причин является аргументом для проведения тестирования по принципу «белого ящика». Тесты «черного ящика» не смогут реагировать на ошибки таких типов.
Способ тестирования базового пути.
Тестирование базового пути – это способ, который основан на принципе «белого ящика». Автор этого способа – Том МакКейб (1976).
Способ тестирования базового пути дает возможность:
· Получить оценку комплексной сложности программы.
· Использовать эту оценку для определения необходимого количества тестовых вариантов.
Тестовые варианты разрабатываются для проверки базового множества путей (маршрутов) в программе. Они гарантируют однократное выполнение каждого оператора программы при тестировании.
Потоковый граф.
Для представления программы используется потоковый граф. Перечислим его особенности.
· Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов рассматриваются как отдельные (фиктивные) операторы.
· Узлы (вершины) потокового графа соответствуют линейным участкам программы, включают один или несколько операторов программы.
· Дуги потокового графа отображают поток управления в программе (передачи управления между операторами). Дуга – это ориентированное ребро.
· Различают операторные и предикатные узла. Из операторного узла выходит одна дуга, а из предикатного – две дуги.
· Предикатные узлы соответствуют простым условиям в программе. Составное условие программы отображается в несколько предикатных узлов. Составным называют условие, в котором используется одна или несколько булевых операций.
· Замкнутые области, образованные дугами и узлами, называют регионами.
· Окружающая граф среда рассматривается как дополнительный регион.
Цикломатическая сложность.
Цикломатическая сложность – метрика программного обеспечения, которая обеспечивает количественную оценку логической сложности программы. В способе тестирования базового пути цикломатическая сложность определяет:
· Количество независимых путей в базовом множестве программы.
· Верхнюю оценку количества тестов, которое гарантирует однократное выполнение всех операторов.
Независимым называется любой путь, который вводит новый оператор обработки или новое условие. В терминах потокового графа независимый путь должен содержать дугу, не входящую в ранее определенные пути.
Все независимые пути графа образуют базовое множество.
Свойства базового множества:
· Тесты, обеспечивающие его проверку гарантируют:
1. однократное выполнение каждого оператора;
2. выполнение каждого условия по True-ветви и по False-ветви.
· Мощность базового множества равна цикломатической сложности потокового графа.
Значение второго свойства трудно переоценить – оно дает априорную оценку количества независимых путей, которое имеет смысл искать в графе.
Цикломатическая сложность вычисляется одним из трех способов:
· Цикломатическая сложность равна количеству регионов потокового графа.
· Цикломатическая сложность определяется по формуле
V(G)=E – N + 2, где E – количество дуг, N – количество узлов потокового графа.
· Цикломатическая сложность формируется по выражению V(G)=p+1, где p - количество предикатных узлов в потоковом графе G.
Шаги способа тестирования базового пути.
· На основе текста программы формируется потоковый граф:
1. нумеруются операторы текста.
2. производится отображение пронумерованного текста программы в узлы и вершины потокового графа.
· Определяется цикломатическая сложность потокового графа – по каждой из трех формул.
· Определяется базовое множество независимых линейных путей.
· Подготавливаются тестовые варианты, инициирующие выполнение каждого пути.
Каждый тестовый вариант формируется в следующем виде:
Исходные данные (ИД):
Ожидаемые результаты (ОЖ.РЕЗ.):
Исходные данные должны выбираться так, чтобы предикатные вершины обеспечивали нужные переключения – запуск только тех операторов, которые перечислены в конкретном пути, причем в требуемом порядке.
Реальные результаты каждого тестового варианта сравниваются с ожидаемыми результатами. После выполнения всех тестовых вариантов гарантируется, что все операторы программы выполнены по меньшей мере один раз.
Важно отметить, что некоторые независимые пути не могут проверяться изолированно. Такие пути должны проверяться при тестировании другого пути (как часть другого тестового варианта).
Способы тестирования условий.
Цель этого семейства способов тестирования – строить тестовые варианты для проверки логических условий программы. При этом желательно обеспечить охват операторов из всех ветвей программы.
Рассмотрим используемую здесь терминологию.
Простое условие – булева переменная или выражение отношения.
Выражение отношения имеет вид
E1<оператор отношения>E2,
Где E1, E2 – арифметические выражения, а в качестве оператора отношения используется один из следующих операторов:
Составное условие состоит из нескольких простых условий, булевых операторов и круглых скобок. Будем применять булевы операторы OR, AND (&), NOT. Условия, не содержащие выражений отношения, называют булевыми выражениями.
Таким образом, элементами условия являются: булев оператор, булева переменная, пара скобок (заключающая простое или составное условие), оператор отношения, арифметическое выражение. Эти элементы определяют типы ошибок в условиях.
Если условие некорректно, то некорректен по меньшей мере один из элементов условия. Следовательно, в условии возможны следующие типы ошибок:
· Ошибка булева оператора (наличие некорректных/ отсутствующих/ избыточных булевых операторов).
· Ошибка булевой переменной.
· Ошибка оператора отношения.
· Ошибка арифметического выражения.
Способ тестирования условий ориентирован на тестирование каждого условия в программе. Методика тестирования условий имеют два достоинства. Во-первых, достаточно просто выполнить измерение тестового покрытия условия. Во-вторых, тестовое покрытие условий в программе – это фундамент для генерации дополнительных тестов программы.
Целью тестирования условий является определение не только ошибок в условиях, но и других ошибок в программах. Если набор тестов для программы A эффективен для обнаружения ошибок в условиях, содержащихся в A, то вероятно, что это набор также эффективен для обнаружения других ошибок в A. Кроме того, если методика тестирования эффективна для обнаружения ошибок в условиях, то вероятно, что эта методика будет эффективна для обнаружения ошибок в программе.
Существует несколько методик тестирования условий.
Простейшая методика – тестирование ветвей. Здесь для составного условия С проверяется:
· каждое простое условие;