Файл: Технология раработки програмного обеспечения УП.pdf

121 

выполнять

обязанности

администратора

процесса.

Администра-

тор,

в

свою

очередь,

отбирает

приблизительно

6—20

участников

(6

—

минимальное

число

для

сохранения

анонимности).

Пред-

полагается,

что

участники

должны

быть

одного

профиля

(на-

пример,

в

одну

группу

не

следует

объединять

программистов,

использующих

Кобол,

и

системных

программистов,

пишущих

на

Ассемблере).

Каждого

участника

просят

представить

для

рассмотрения

две

свои

программы

—

наилучшую

(с

его

точки

зрения)

и

низкого

качества.

Отобранные

программы

случайным

образом

«распреде-

ляются

между

участниками.

Им

дается

на

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

по

че-

тыре

программы.

Две

из

них

являются

«наилучшими»,

а

две

—

«наихудшими»,

но

рецензенту

не

сообщают

о

том,

какая

про

-

грамма

к

какой

группе

относится.

Каждый

участник

тратит

на

просмотр

одной

программы

30

мин

и

заполняет

анкету

для

ее

оценки.

После

просмотра

всех

четырех

программ

оценивается

их

относительное

качество.

В

анкете

для

оценки

проверяющему

предлагается

оценить

программу

по

семибалльной

шкале

(1

означает

определенное

«да»,

7

—

определенное

«нет»)

при

ответе,

например,

на

следующие

вопросы:

•

Легко

ли

было

понять

программу?

•

Оказались

ли

результаты

проектирования

высокого

уровня

очевидными

и

приемлемыми?

•

Оказались

ли

результаты

проектирования

низкого

уровня

очевидными

и

приемлемыми?

•

Легко

ли

для

вас

модифицировать

эту

программу?

•

Испытывали

бы

вы

чувство

удовлетворения,

написав

такую

программу?

Проверяющего

просят

также

дать

общий

комментарий

и

рекомендации

по

улучшению

программы.

После

просмотра

ка-

ждому

участнику

передают

анонимную

анкету

с

оценкой

двух

его

программ.

Участники

получают

статистическую

сводку,

которая

содержит

общую

и

детальную

классификацию

их

соб-

ственных

программ

в

сравнении

с

полным

набором

программ,

и

анализ

того,

насколько

оценки

чужих

программ

совпадают

с

оценками

тех

же

самых

программ,

данными

другими

прове-

ряющими.

Цель

такого

просмотра

—

дать

возможность

про-

122 

граммистам

самим

оценить

свою

квалификацию.

Этот

способ

представляется

полезным

как

для

промышленного,

так

и

для

учебного

применения.

6.4 

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

теста

Результаты

психологических

исследований,

обсуждав-

шиеся

в

п.

6.2,

показывают,

что

наибольшее

внимание

при

тес-

тировании

программ

уделяется

проектированию

или

созданию

эффективных

тестов.

Это

связано

с

невозможностью

«полного»

тестирования

программы,

т.е.

тест

для

любой

программы

будет

обязательно

неполным

(иными

словами,

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

не

может

гарантировать

отсутствия

всех

ошибок).

Стратегия

проектиро-

вания

заключается

в

том,

чтобы

попытаться

уменьшить

эту

«не-

полноту»

настолько,

насколько

это

возможно.

Если

ввести

ограничения

на

время,

стоимость,

машинное

время

и

т.п.,

то

ключевым

вопросом

тестирования

становится

следующий:

Какое

подмножество

всех

возможных

тестов

имеет

наивысшую

вероятность

обнаружения

большинства

ошибок?

Изучение

методологий

проектирования

тестов

дает

ответ

на

этот

вопрос.

По-видимому,

наихудшей

из

всех

методологий

является

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

со

случайными

входными

значениями

(стохасти-

ческое)

—

процесс

тестирования

программы

путем

случайного

выбора

некоторого

подмножества

из

всех

возможных

входных

величин.

В

терминах

вероятности

обнаружения

большинства

ошибок

случайно

выбранный

набор

тестов

имеет

малую

веро-

ятность

быть

оптимальным

или

близким

к

оптимальному

под-

множеством.

В

настоящем

разделе

рассматривается

несколько

подходов,

которые

позволяют

более

разумно

выбирать

тестовые

данные.

В

п.

6.2

было

показано,

что

исчерпывающее

тестирова-

ние

по

принципу

черного

или

белого

ящика

в

общем

случае

невозможно.

Однако

при

этом

отмечалось,

что

приемлемая

стратегия

тестирования

может

обладать

элементами

обоих

под-

ходов.

Таковой

является

стратегия,

излагаемая

в

этом

разделе.

Можно

разработать

довольно

полный

тест,

используя

опреде-

ленную

методологию

проектирования,

основанную

на

принци-

123 

пе

черного

ящика,

а

затем

дополнить

его

проверкой

логики

про-

граммы

(т.е.

с

привлечением

методов

белого

ящика).

Методологии,

обсуждаемые

в

настоящем

разделе,

пред-

ставлены

ниже:

Черный

ящик

Эквивалентное

разбиение

Анализ

граничных

значений

Применение

функциональных

диаграмм

Предположение

об

ошибке

Белый

ящик

Покрытие

операторов

Покрытие

решений

Покрытие

условий

Покрытие

решений/условий

Комбинаторное

покрытие

условий

Хотя

перечисленные

методы

будут

рассматриваться

здесь

по

отдельности,

при

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

эффективного

теста

про-

граммы

рекомендуется

использовать

если

не

все

эти,

то,

по

крайней

мере,

большинство

из

них,

так

как

каждый

из

них

име-

ет

определенные

достоинства

и

недостатки

(например,

возмож-

ность

обнаруживать

и

пропускать

различные

типы

ошибок).

Правда,

эти

методы

весьма

трудоемки,

поэтому

некоторые

спе-

циалисты,

ознакомившись

с

ними,

могут

не

согласиться

с

дан-

ной

рекомендацией.

Однако

следует

представлять

себе,

что

тес-

тирование

программы

—

чрезвычайно

сложная

задача.

Для

ил-

люстрации

этого

приведем

известное

изречение:

«Если

вы

ду-

маете,

что

разработка

и

кодирование

программы

—

вещь

труд-

ная,

то

вы

еще

ничего

не

видели».

Рекомендуемая

процедура

заключается

в

том,

чтобы

раз-

рабатывать

тесты,

используя

методы

черного

ящика,

а

затем

как

необходимое

условие

—

дополнительные

тесты,

используя

ме-

тоды

белого

ящика.

Методы

белого

ящика,

получившие

более

широкое

распространение,

обсуждаются

первыми.

6.4.1 Тестирование путем покрытия логики 

программы 

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

по

принципу

белого

ящика

характеризуется

степенью,

в

какой

тесты

выполняют

или

покрывают

логику

(ис-

ходный

текст)

программы.

Как

показано

в

п.

6.2,

исчерпываю-

щее

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

по

принципу

белого

ящика

предполагает

вы-

полнение

каждого

пути

в

программе;

но

поскольку

в

программе

с

циклами

выполнение

каждого

пути

обычно

нереализуемо,

то

тес-

тирование

всех

путей

не

рассматривается

как

перспективное.

124 

6.4.1.1 Покрытие операторов 

Если

отказаться

полностью

от

тестирования

всех

путей,

то

можно

показать,

что

критерием

покрытия

является

выполне-

ние

каждого

оператора

программы,

по

крайней

мере,

один

раз.

К

сожалению,

это

слабый

критерий,

так

как

выполнение

каждо-

го

оператора,

по

крайней

мере,

один

раз

есть

необходимое,

но

недостаточное

условие

для

приемлемого

тестирования

по

прин-

ципу

белого

ящика

(рис.

6.5).

Рис.

6.5

—

Алгоритм

тестируемой

программы

Предположим,

что

на

рис.

6.5

представлена

небольшая

программа,

которая

должна

быть

протестирована.

Эквивалент-

ная

программа,

написанная

на

языке

PL/1,

имеет

вид:

М: PROCEDURE (A,В,Х); 
   IF ((

А>1) & (В=0)) THEN DO; 

Х=Х/А; 

   END; 
   IF ((A=2) | (

Х>1)) THEN DO; 

A

 > 

1

AND

B

 = 

0

A

 = 

2

OR

X

 > 

1

X

 = 

X/A

X

 = 

X

 + 

1

No

No

Yes

Yes

a 

b 

c 

d 

e 

125 

Х=Х+1; 

   END; 
END; 

 
Можно

выполнить

каждый

оператор,

записав

один-един

-

ственный

тест,

который

реализовал

бы

путь

асе.

Иными

слова-

ми,

если

бы

в

точке

a

были

установлены

значения

A

=

2,

B

=

0

и

X

=

3,

каждый

оператор

выполнялся

бы

один

раз

(в

действи-

тельности

X

может

принимать

любое

значение).

К

сожалению,

этот

критерий

хуже,

чем

он

кажется

на

первый

взгляд.

Например,

пусть

первое

решение

записано

как

или,

а

не

как

и.

При

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

по

данному

критерию

эта

ошибка

не

будет

обнаружена.

Пусть

второе

решение

записано

в

программе

как

X

>

0;

эта

ошибка

также

не

будет

обнаружена.

Кроме

того,

существует

путь,

в

котором

Х

не

изменяется

(путь

abd).

Если

здесь

ошибка,

то

и

она

не

будет

обнаружена.

Таким

образом,

критерий

покрытия

операторов

является

настолько

слабым,

что

его

обычно

не

используют.

6.4.1.2 Покрытие решений 

Более

сильный

критерий

покрытия

логики

программы

из-

вестен

как

покрытие

решений,

или

покрытие

переходов.

Согласно

данному

критерию

должно

быть

записано

дос-

таточное

число

тестов,

такое,

что

каждое

решение

на

этих

тес-

тах

примет

значение

истина

и

ложь,

по

крайней

мере,

один

раз.

Иными

словами,

каждое

направление

перехода

должно

быть

реализовано,

по

крайней

мере,

один

раз.

Примерами

операторов

перехода,

или

решений,

являются

операторы

DO

(или

PERFORM

UNTIL

в

Коболе,

REPEAT

UNTIL,

WHILE

в

Паскале,

WHILE

и

DO

WHILE

в

Си),

IF,

многовыходные

операторы

GO

TO.

Можно

показать,

что

покрытие

решений

обычно

удовле-

творяет

критерию

покрытия

операторов.

Поскольку

каждый

оператор

лежит

на

некотором

пути,

исходящем

либо

из

опера-

тора

перехода,

либо

из

точки

входа

программы,

при

выполне-

нии

каждого

направления

перехода

каждый

оператор

должен

быть

выполнен.

Однако

существует,

по

крайней

мере,

два

ис-