СТРУКТУРНОЕ ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

Основные понятия и принципы тестирования ПО

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

Каждый тест определяет:

· свой набор исходных данных и условий для запуска программы;

· набор ожидаемых результатов работы программы.

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

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

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

Тестирование обеспечивает:

· обнаружение ошибок;

· демонстрацию соответствия функций программы ее назначению;

· демонстрацию реализации требований к характеристикам программы;

· отображение надежности как индикатора качества программы.

Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов)

Рассмотрим информационные потоки процесса тестирования. Они показаны на рис.1.

Рис. 1. Информационные потоки процесса тестирования

На входе процесса тестирования три потока:

· текст программы;

· исходные данные для запуска программы;

· ожидаемые результаты.

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

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

· качество и надежность ПО удовлетворительны;

· тесты не способны обнаруживать серьезные ошибки.

В конечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).

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

Существуют 2 принципа тестирования программы:

· функциональное тестирование (тестирование «черного ящика»);

· структурное тестирование (тестирование «белого ящика»).

Тестирование методом «белого ящика» и его использование в тестировании базового пути, условий, циклов

Тестирование «черного ящика»

Известны: функции программы.

Исследуется: работа каждой функции на всей области определения.

Как показано на рис.2, основное место приложения тестов «черного ящика» — интерфейс ПО.

Эти тесты демонстрируют:

· как выполняются функции программ;

· как принимаются исходные данные;

· как вырабатываются результаты;

· как сохраняется целостность внешней информации.

При тестировании «черного ящика» рассматриваются системные характеристики программ, игнорируется их внутренняя логическая структура. Исчерпывающее тестирование, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то потребуется 10¹⁰ тестовых вариантов. Отметим также, что тестирование «черного ящика» не реагирует на многие особенности программных ошибок.

Тестирование «белого ящика»

Известна: внутренняя структура программы.

Исследуются: внутренние элементы программы и связи между ними (рис. 3).

Рис. 3. Тестирование «белого ящика»

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

Особенности тестирования «белого ящика»

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

В этом случае формируются тестовые варианты, в которых:

· гарантируется проверка всех независимых маршрутов программы;

· проходятся ветви True, False для всех логических решений;

· выполняются все циклы (в пределах их границ и диапазонов);

· анализируется правильность внутренних структур данных.

Недостатки тестирования «белого ящика»:

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

При п = 5 и k = 20 количество маршрутов т = 10¹⁴. Примем, что на разработку, выполнение и оценку теста по одному маршруту расходуется 1 мс. Тогда при работе 24 часа в сутки 365 дней в году на тестирование уйдет 3170 лет.

2. Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней.

3. В программе могут быть пропущены некоторые маршруты.

4. Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных (это ошибки, обусловленные выражениями типа if abs (a-b) < eps...,

if (a+b+c)/3=a...).

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

1. Количество ошибок минимально в «центре» и максимально на «периферии» программы.

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

3. При записи алгоритма ПО в виде текста на языке программирования возможно внесение типовых ошибок трансляции (синтаксических и семантических).

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

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

Тестирование потоков данных

СПОСОБ ТЕСТИРОВАНИЯ БАЗОВОГО ПУТИ

Тестирование базового пути — это способ, который основан на принципе «белого ящика». Автор этого способа — Том МакКейб (1976) [49].

Способ тестирования базового пути дает возможность:

· получить оценку комплексной сложности программы;

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

Тестовые варианты разрабатываются для проверки базового множества путей (маршрутов) в программе. Они гарантируют однократное выполнение каждого опера тора программы при тестировании.

Потоковый граф

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

1. Граф строится отображением управляющей структуры программы. В ходе отображения закрывающие скобки условных операторов и операторов циклов (end if; end loop) рассматриваются как отдельные (фиктивные) опера
торы.

2. Узлы (вершины) потокового графа соответствуют линейным участкам программы, включают один или несколько операторов программы.

3. Дуги потокового графа отображают поток управления в программе (передачи управления между операторами). Дуга — это ориентированное ребро.

4. Различают операторные и предикатные узлы. Из операторного узла выходит одна дуга, а из предикатного — две дуги.

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

Например, фрагмент программы

If a OR b

then x

else у end If;

вместо прямого отображения в потоковый граф вида, показанного на рис. 4, отображается в преобразованный потоковый граф (рис..5).

рис.4. Рис. 5. Преобразованный потоковый граф.

Замкнутые области, образованные дугами и узлами, называют регионами.

Окружающая граф среда рассматривается как дополнительный регион. Например, показанный здесь граф имеет три региона — Rl, R2, R3,

Пример 1. Рассмотрим процедуру сжатия:

процедура сжатие

1 выполнять пока нет EOF

1 читать запись;

2 если запись пуста

3 то удалить запись;

4 иначе если поле а >= поля b

5 то удалить b;

6 иначе удалить а;
7а конец если;

7а конец если; 7Ь конец выполнять;

8 конец сжатие;

Рис. 6. Преобразованный потоковый граф процедуры сжатия

Она отображается в потоковый граф, представленный на рис. 6. Видим, что этот потоковый граф имеет четыре региона.

Цикломатическая сложность

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

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

· верхнюю оценку количества тестов, которое гарантирует однократное выполнение всех операторов.

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

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

Перечислим независимые пути для потокового графа из примера 1:

Путь1: 1-8.

Путь 2: 1-2-3-7а-7b-1-8.

ПутьЗ: 1-2-4-5-7а-7b-1-8.

Путь 4: 1-2-4-6-7а-7b-1-8.

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

Свойства базового множества:

1. Тесты, обеспечивающие его проверку, гарантируют:

· однократное выполнение каждого оператора;

· выполнение каждого условия по True-ветви и по False-ветви;

2) мощность базового множества равна цикломатической сложности потокового графа.

Значение 2-го свойства трудно переоценить — оно дает априорную оценку количества независимых путей, которое имеет смысл искать в графе.

Цикломатическая сложность вычисляется одним из трех способов:

1) цикломатическая сложность равна количеству регионов потокового графа;

2) цикломатическая сложность определяется по формуле

V ( G )= E - N +2, где Е — количество дуг, N — количество узлов потокового графа;

3) цикломатическая сложность формируется по выражению V ( G ) = p + 1, где р — количество предикатных узлов в потоковом графе G .

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

1) потоковый граф имеет 4 региона;

2) V(G) - 11 дуг - 9 узлов + 2 = 4;

3) V(G) - 3 предикатных узла +1=4.

Таким образом, цикломатическая сложность потокового графа из примера 1 равна четырем.

Шаги способа тестирования базового пути

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

Процедура сред:

1 i := 1:

1 введено :=0;

1 колич := 0;

1 сум := 0;

вып пока 2- вел( i ) <> stop и введено <= 500 -3

4 ведено:= веденo_+_ 1;

если 5 вел (i)>=мин и вел( i ) <= макс 6

7 то колич :=колич+ 1; 7 сум := сум + вел( i );

8 конец если;

8 i := i + 1;

9 конец вып;

10 если колич > О

11 то сред := сум / колич;

12 иначе сред := stop;

13 конец если;

13 конец сред;

Заметим, что процедура содержит составные условия (в заголовке цикла и условном операторе).

Шаг 1. На основе текста программы формируется потоковый граф:

· нумеруются операторы текста (номера операторов показаны в тексте процедуры);

· производится отображение пронумерованного текста программы в узлы и вершины потокового графа (рис. 7).

Рис. 7. Потоковый граф процедуры вычисления среднего значения

Шаг 2. Определяется цикломатическая сложность потокового графа — по каждой из трех формул:

1) V(G) = 6 регионов;

2) V(G) = 17 дуг - 13 узлов + 2 = 6;

3) V(G) = 5 предикатных узлов + 1 = 6.

Шаг 3. Определяется базовое множество независимых линейных путей:

Путь 1: 1-2-10-11-13; /вел=stор, колич>0.

Путь 2: 1-2-10-12-13; /вел=stop, колич=0.

Путь 3: 1-2-3-10-11-13; /попытка обработки 501-й величины.

Путь 4: 1-2-3-4-5-8-9-2-... /вел<мин.

Путь 5: 1-2-3-4-5-6-8-9-2-... /вел>макс.

Путь 6: 1-2-3-4-5-6-7-8-9-2-... /режим нормальной обработки.

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

Шаг 4. Подготавливаются тестовые варианты, инициирующие выполнение каждого пути.

Каждый тестовый вариант формируется в следующем виде: Исходные данные (ИД): Ожидаемые результаты (ОЖ.РЕЗ.):

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

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

Тестовый вариант для пути 1 ТВ1:

ИД: вел(k) = допустимое значение, где k < i ; вел(i) = stop, где 2 < i < 500.

ОЖ.РЕЗ.: корректное усреднение основывается на k величинах и правильном подсчете.

Путь не может тестироваться самостоятельно, а должен тестироваться как часть путей 4, 5, 6 (трудности проверки 11 -го оператора).

(Тестовый вариант для пути 2 ТВ2:

ИД:вел(1)=stор.

ОЖ.РЕЗ.: сред=stор, другие величины имеют начальные значения. Тестовый вариант для пути 3 ТВЗ:

ИД: попытка обработки 501-й величины, первые 500 величин должны быть правильными.

ОЖ.РЕЗ:. корректное усреднение основывается на k величинах и правильном подсчете.

Тестовый вариант для пути 4 ТВ4: ИД:вел(i)=допустимое значение, где i < 500; вел(&) < мин, где k < i .

ОЖ.РЕЗ.: корректное усреднение основывается на k величинах и правильном подсчете.

Тестовый вариант для пути 5 ТВ5:

ИД: вел(i)=допустимое значение, где i < 500; вел(£) > макс, где k < i .

ОЖ.РЕЗ.: корректное усреднение основывается на п величинах и правильном подсчете.

Тестовый вариант для пути 6 ТВ6:

ИД.вел(i)=допустимое значение, где i < 500.

ОЖ.РЕЗ.: корректное усреднение основывается на п величинах и правильном подсчете.

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

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

Способы тестирования условий

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

Рассмотрим используемую здесь терминологию.

Простое условие — булева переменная или выражение отношения.

Выражение отношения имеет вид

Е1 «оператор отношения> Е2,

где El, E2 — арифметические выражения, а в качестве оператора отношения используется один из следующих операторов: <, >, =, *, <, >.

Составное условие состоит из нескольких простых условий, булевых операторов и круглых скобок. Будем применять булевы операторы OR, AND (&), NOT. Условия, не содержащие выражений отношения, называют булевыми выражениями.

Таким образом, элементами условия являются: булев оператор, булева переменная, пара скобок (заключающая простое или составное условие), оператор отношения, арифметическое выражение. Эти элементы определяют типы ошибок в условиях.

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

· ошибка булева оператора (наличие некорректных / отсутствующих / избыточных булевых операторов);

· ошибка булевой переменной;

· ошибка булевой скобки;

· ошибка оператора отношения;

· ошибка арифметического выражения.

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

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

Существует несколько методик тестирования условий.

Простейшая методика — тестирование ветвей Здесь для составного условия С проверяется:

каждое простое условие (входящее в него); Тгие-ветвь; False-ветвь.

Другая методика — тестирование области определения. В ней для выражения отношения требуется генерация 3-4 тестов. Выражение вида

Е1 «оператор отношения> Е2

проверяется тремя тестами, которые формируют значение Е1 большим, чем Е2, равным Е2 и меньшим, чем Е2.

Если оператор отношения неправилен, а Е1 и Е2 корректны, то эти три теста гарантируют обнаружение ошибки оператора отношения.

Для определения ошибок в Е1 и Е2 тест должен сформировать значение Е1 большим или меньшим, чем Е2, причем обеспечить как можно меньшую разницу между этими значениями.

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

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

ТЕСТИРОВАНИЕ ВЕТВЕЙ И ОПЕРАТОРОВ ОТНОШЕНИЙ

Способ тестирования ветвей и операторов отношений (автор К. Таи, 1989) обнаруживает ошибки ветвления и операторов отношения в условии, для которого выполняются следующие ограничения [72]:

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

· в условии нет общих переменных.

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

ОУ_с =(d₁,d₂,...d_n),

где di — ограничение на результат i-ro простого условия. Ограничение на результат фиксирует возможные значения аргумента (перемен ной) простого условия (если он один) или соотношения между значениями аргументов (если их несколько).

Если i-e простое условие является булевой переменной, то его ограничение на результат состоит из двух значений и имеет вид

d_i =( true, false).

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

dj =(>,<,=).

Говорят, что ограничение условия ОУ_С (для условия С) покрывается выполнением С, если в ходе этого выполнения результат каждого простого условия в С удовлетворяет соответствующему ограничению в ОУ_С.

На основе ограничения условия ОУ создается ограничивающее множество ОМ, элементы которого являются сочетаниями всех возможных значений d ₁ _t d ₂ , d ₃ , ..., d_n .

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

b &(х>у)&а.

Условие принимает истинное значение, если все простые условия истинны. В тер минах значений простых условий это соответствует записи

(true, true, true),

а в терминах ограничений на значения аргументов простых условий — записи

(true, >, true).

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

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

Пример 1. В качестве примера рассмотрим два типовых составных условия:

С_& = а & b , С _or =а or b , где а и b — булевы переменные. Соответствующие ограничения условий принимают вид

OY_& = (d ₁ , d ₂ ) , OY_or= (d ₁ , d ₂ )

где d₁ = d₂ = (true, false).

Ограничивающие множества удобно строить с помощью таблицы истинности (табл. 6.1).

Таблица 1. Таблица истинности логических операций

Вариант	а	b	a&b	a or b
1	false	false	false	false
2	false	true	false	true
3	true	false	false	true
4	true	true	true	true

Видим, что таблица задает в ОМ четыре элемента (и соответственно, четыре тестовых варианта). Зададим вопрос — каковы возможности минимизации? Можно ли уменьшить количество элементов в ОМ?

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

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

для условия типа И (а & b) варианты 2 и 3 поглощают вариант 1. Поэтому ограничивающее множество имеет вид:

ОМ_& = {(false, true), (true, false), (true, true)};

для условия типа ИЛИ (a or b ) варианты 2 и 3 поглощают вариант 4. Поэтому ограничивающее множество имеет вид:

ОМor = {(false, false), (false, true), (true, false)}.

Рассмотрим шаги способа тестирования ветвей и операторов отношений.

ДЛЯ каждого условия в программе выполняются следующие действия:

· строится ограничение условий ОУ;

· выявляются ограничения результата по каждому простому условию;

· строится ограничивающее множество ОМ. Построение выполняется путем подстановки в константные формулы ОМ_& или ОМ_ОГ выявленных ограничений результата;

· Для каждого элемента ОМ разрабатывается тестовый вариант.

Примep 2. Рассмотрим составное условие С₁ вида:

B₁& (E₁=E₂)

Где В₁ булево выражение, Е₁,Е₂ — арифметические выражения.

Ограничение составного условия имеет вид

OY_c = (d ₁ , d ₂ )

где ограничения простых условий равны

d₁ = (true, false), d ₂ = (=, <, >) .

Проводя аналогию между С₁ и С_& (разница лишь в том, что в С₁ второе простое условие — это выражение отношения), мы можем построить ограничивающее множество для С, модификацией

ОМ_& - {(false, true), (true, false), (true, true)}.

Заметим, что true для ( E_l * E₂) означает «, a false для (E₁ - E₂) означает или <, или >. Заменяя (true, true) и (false, true), ограничениями (true, -) и (false, -) соответственно, a (true, false) — ограничениями (true, <) и (true, >), получаем ограничивающее множество для С₁,

OM_C1={(false,=),(true,<),(true,>),(true,=)}.

Покрытие этого множества гарантирует обнаружение ошибок булевых операторов и операторов отношения в С₁.

Пример 3. Рассмотрим составное условие С₂ вида

(E₃ >E₄)&(E₁ =E₂),

где E₁, E₂, E₃, E₄ — арифметические выражения.

Проводя аналогию между С₂ и С, (разница лишь в том, что в С₂ первое простое условие — это выражение отношения), мы можем построить ограничивающее множество для С₂ модификацией ОМ_С:

ОМ_С2 = {(=, =), (<, =), (>, <), (>, >), (>, =)}.

Покрытие этого ограничивающего множества гарантирует обнаружение ошибок операторов отношения в С₂.

Способ тестирования потоков данных

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

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

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

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

· в вершине 1 определяются значения переменных а, b

· значение переменной а используется в вершине 4;

· значение переменной b используется в вершинах 3, 6;

· в вершине 4 определяется значение переменной с, которая используется в вершине 6.

Рис. 6.8. Граф программы с управляющими и информационными связями

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

множество определений данных

DEF(i) - { х | i -я вершина содержит определение х};

множество использований данных:

USE (i) - { х | i -я вершина использует х}.

Под определением данных понимают действия, изменяющие элемент данных, Признак определения — имя элемента стоит в левой части оператора присваивания: x:= f(…)

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

ИМЯ:= f(х)

Здесь ИМЯ - место подстановки другого имени.

Назовем DU –цепочкой конструкцию[x,i,j], где i,j имена вершин; х определена в i - вершине и используется в j вершине.

В примере существуют следующие DU цепочки:

[a,1,4], [b,1,3],[b,1,6],[c,4,6].

Способ DU тестирования требует охвата всех DU-цепочек программы. Разработка теста проводится на основе анализа жизни всех данных программы.

Для подготовки тестов требуется выделение маршрутов – путей выполнения программы на управляющем графе. Критерий выбора пути – покрытие максимального количества DU – цепочек.

Шаги способа DU-тестирования:

1. построение управляющего графа программы;

2. Построение информационного графа;

3. Формирование полного набора DU- цепочек;

4. Формирование полного набора отрезков путей в управляющем графе

5. Построение маршрутов –полных путей на управляющем грае, покрывающих набор отрезков путей управляющего графа;

6. Подготовка тестовых вариантов.

Тестирование циклов

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

Различают 4 типа циклов: простые, вложенные, объединенные, неструктурированные. Типовые структуры циклов

Простые циклы

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

· прогон всего цикла;

· только один проход цикла;

· два прохода цикла;

· m проходов цикла, где т < п;

· п - 1, п, п + 1 проходов цикла.

Вложенные циклы

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

Порядок тестирования вложенных циклов иллюстрирует рис.12.

Рис.6.12. Шаги тестирования вложенных циклов

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

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

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

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

4. Работа продолжается до тех пор, пока не будут протестированы все циклы.

Объединенные циклы

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

Неструктурированные Циклы.

Неструктурированные циклы тестированию не подлежат. Этот тип циклов должен быть переделан.

Дата добавления: 2021-03-18; просмотров: 225; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 54 55 56 57 585960 61 62 63 Следующая ⇒

Мы поможем в написании ваших работ!