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

86

•

Даже

для

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

простого

случая

—

использо-

вания

целочисленных

данных

—

существуют

трудно-

сти.

Например,

все

ЭВМ

используют

слова

фиксиро-

ванной

длины

для

записи

целых

чисел.

Возможно

пе-

реполнение

разрядной

сетки,

и

аксиомы

должны

учи-

тывать

эти

условия.

•

Реальные

языки

программирования

имеют

встроенные

структуры,

которые

нелегко

поддаются

проверке

на

правильность.

Несмотря

на

отмеченные

недостатки,

доказательства

пра-

вильности

программ

достаточно

широко

применяются.

Спосо-

бы

проверки

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

программ

можно

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

при

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

реальных

программ.

Для

разрабатываемой

про-

граммы

должны

быть

определены

предусловия

работы.

Даже

если

условия

не

доказаны

формально,

а

просто

установлены,

они

оказывают

неоценимую

помощь

в

понимании

структуры

разрабатываемой

программы.

Добавление

предусловий

тесно

связано

с

элементарными

программами.

Кроме

того,

предусловия

являются

базой

для

раз-

работки

тестов

программ.

Все

предусловия

могут

быть

закоди-

рованы

как

операторы

if

и

выполняться

как

часть

теста.

Контрольные

вопросы

1.

Правильность

программ.

2.

Правила

следствия.

3.

Аксиома

присвоения.

4.

Аксиома

следования.

5.

Аксиома

цикла.

6.

Аксиома

выбора.

7.

Правила

целочисленной

арифметики

—

коммутатив-

ность,

ассоциативность,

дистрибутивность,

вычитание,

обработка

констант.

8.

Доказательство

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

программ.

87

6 

ТЕСТИРОВАНИЕ

6.1 

Психология

и

экономика

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

программ

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

как

объект

изучения

может

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

ся

с

различных,

чисто

технических,

точек

зрения.

Однако

наи-

более

важными

при

изучении

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

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

во-

просы

его

экономики

и

психологии

разработчика.

Иными

сло-

вами,

достоверность

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

программы,

в

первую

оче-

редь,

определяется

тем,

кто

будет

ее

тестировать

и

каков

его

образ

мышления,

и

уже

затем

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

технологически-

ми

аспектами.

Поэтому,

прежде

чем

перейти

к  техническим

проблемам,

мы

остановимся

на

этих

вопросах.

Поначалу

может

показаться

тривиальным

жизненно

важ-

ный

вопрос

определения

термина

«тестирование».

Необходи-

мость

обсуждения

этого

термина

связана

с

тем,

что

большинст-

во

специалистов

используют

его

неверно,

а

это,

в

свою

очередь,

приводит

к

плохому

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

Таковы,

например,

сле-

дующие

определения:

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

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

собой

про-

цесс,

демонстрирующий

отсутствие

ошибок

в

программе»,

«цель

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

—

показать,

что

программа

корректно

ис-

полняет

предусмотренные

функции»,

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

—

это

про-

цесс,

позволяющий

убедиться

в

том,

что

программа

выполняет

свое

назначение».

Эти

определения

описывают

нечто

противоположное

то-

му,

что

следует

понимать

под

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

поэтому

они

не-

верны.

Оставив

на

время

определения,

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

что

если

мы

тестируем

программу,

то

нам

нужно

добавить

к

ней

некото-

рую

новую

стоимость

(т.е.

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

стоит

денег

и

нам

же-

лательно

возвратить

затраченную

сумму

путем

увеличения

стоимости

программы).

Увеличение

стоимости

означает

повы-

шение

качества

или

возрастание

надежности

программы.

Пос

-

леднее

связано

с

обнаружением

и

удалением

из

нее

ошибок.

Следовательно,

программа

тестируется

не

для

того,

чтобы

пока-

зать,

что

она

работает,

а

скорее

наоборот

—

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

начи-

нается

с

предположения,

что

в

ней

есть

ошибки

(это

предполо-

жение

справедливо

практически

для

любой

программы),

а

затем

88

уже

обнаруживается

их

максимально

возможное

число.

Таким

образом,

сформулируем

наиболее

приемлемое

определение:

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

—

это

процесс

исполнения

программы

с

целью

обнаружения

ошибок.

Пока

все

наши

рассуждения

могут

показаться

тонкой

иг-

рой

семантики,

однако

практикой

установлено,

что

именно

ими

в

значительной

мере

определяется

успех

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

Дело

в

том,

что

верный

выбор

цели

дает

важный

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

эф-

фект,

поскольку

для

человеческого

сознания

характерна

целевая

направленность.

Если

поставить

целью

демонстрацию

отсутст-

вия

ошибок,

то

мы

подсознательно

будем

стремиться

к

этой

цели,

выбирая

тестовые

данные,

на

которых

вероятность

появ-

ления

ошибки

мала.

В

то

же

время,

если

нашей

задачей

станет

обнаружение

ошибок,

то

создаваемый

нами

тест

будет

обладать

большей

вероятностью

обнаружения

ошибки.

Такой

подход

за-

метнее

повысит

качество

программы,

чем

первый.

Из

приведенного

определения

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

вытекает

не-

сколько

следствий.

Например,

одно

из

них

состоит

в

том,

что

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

—

процесс

деструктивный

(т.е.

обратный

созида

-

тельному,

конструктивному).

Именно

этим

и

объясняется,

по-

чему

многие

считают

его

трудным.

Большинство

людей

склон-

ны

к

конструктивному

процессу

созидания

объектов

и

в

мень-

шей

степени

—

к

деструктивному

процессу

разделения

на

час-

ти.

Из

определения

следует

также

то,

как

нужно

строить

набор

тестовых

данных

и

кто

должен

(а

кто

не

должен)

тестировать

данную

программу.

Для

усиления

определения

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

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

два

понятия

«удачный»

и

«неудачный»

и,

в

частности,

их

ис-

пользование

руководителями

проектов

при

оценке

результатов

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

Большинство

руководителей

проектов

называют

тестовый

прогон

неудачным,

если

обнаружена

ошибка,

и,

на-

оборот,

удачным,

если

он

прошел

без

ошибок.

Чаще

всего

это

является

следствием

ошибочного

понимания

термина

«тестиро-

вание»,

так

как,

по

существу,

слово

«удачный»

означает

«ре-

зультативный»,

а

слово

«неудачный»

—

«нежелательный»,

«не-

результативный».

Но

если

тест

не

обнаружил

ошибки,

его

вы-

89

полнение

связано

с

потерей

времени

и

денег,

и

термин

«удач-

ный»

никак

не

может

быть

применен

к

нему.

Тестовый

прогон,

приведший

к

обнаружению

ошибки,

нельзя

назвать

неудачным

хотя

бы

потому,

что,

как

отмечалось

выше,

это

целесообразное

вложение

капитала.

Отсюда

следует,

что

в

слова

«удачный»

и

«неудачный»

необходимо

вкладывать

смысл,

обратный

общепринятому.

Поэтому

в

дальнейшем

бу-

дем

называть

тестовый

прогон

удачным,

если

в

процессе

его

выполнения

обнаружена

ошибка,

и

«неудачным»,

если

—  кор-

ректный

результат.

Проведем

аналогию

с

посещением

больным

врача.

Если

рекомендованное

врачом

лабораторное

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

не

обна-

ружило

причины

болезни,

не

назовем

же

мы

такое

исследова-

ние

удачным

—

оно

неудачно:

ведь

деньги

пациент

заплатил,

а

он

все

так

же

болен.

Если

же

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

показало,

что

у

больного

язва

желудка,

то

оно

является

удачным,

поскольку

врач

может

прописать

необходимый

курс

лечения.

Следова-

тельно,

медики

используют

эти

термины

в

нужном

нам

смысле

(аналогия

здесь,

конечно,

заключается

в

том,

что

программа,

которую

предстоит

тестировать,

подобна

больному

пациенту).

Определения

типа

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

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

собой

процесс

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

отсутствия

ошибок»

порождают

еще

од-

ну

проблему:

они

ставят

цель,

которая

не

может

быть

достигну-

та

ни

для

одной

программы,

даже

весьма

тривиальной.

Резуль-

таты

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

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

показывают,

что

если

пе-

ред

человеком

ставится

невыполнимая

задача,

то

он

работает

хуже.

Иными

словами,

определение

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

как

процесса

обнаружения

ошибок

переводит

его

в

разряд

решаемых

задач

и,

таким

образом,

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

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

трудность.

Другая

проблема

возникает

в

том

случае,

когда

для

тес-

тирования

используется

следующее

определение:

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

—

это

процесс,

позволяющий

убедиться

в

том,

что

программа

выполняет

свое

назначение»,

поскольку

про-

грамма,

удовлетворяющая

данному

определению,

может

содер-

жать

ошибки.

Если

программа

не

делает

того,

что

от

нее

требу-

ется,

то

ясно,

что

она

содержит

ошибки.

Однако

ошибки

могут

быть

и

тогда,

когда

она

делает,

и

что

от

нее

не

требуется.

90

Подводя

итог,

можно

сказать,

что

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

представ-

ляется

деструктивным

процессом

попыток

обнаружения

оши-

бок

в

программе

(наличие

которых

предполагается).

Набор

тес-

тов,

способствующий

обнаружению

ошибки,

считается

удач-

ным.

Естественно,

в

конечном

счете,

каждый

с

помощью

тести-

рования

хочет

добиться

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

степени

уверенности

в

том,

что

его

программа

соответствует

своему

назначению

и

не

делает

того,

для

чего

она

не

предназначена,

но

лучшим

средст-

вом

для

достижения

этой

цели

является

непосредственный

по-

иск

ошибок.

Допустим,

кто-то

обращается

к

вам

с

заявлением:

«Моя

программа

великолепна»

(т.е.

не

содержит

ошибок).

Лучший

способ

доказать

справедливость

подобного

утвержде-

ния

—

попытаться

его

опровергнуть,

обнаружить

неточности,

нежели

просто

согласиться

с

тем,

что

программа

на

определен-

ном

наборе

входных

данных

работает

корректно.

6.2 

Экономика

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

Дав

такое

определение

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

необходимо

на

следующем

шаге

рассмотреть

возможность

создания

теста,

об-

наруживающего

все

ошибки

программы.

Покажем,

что

ответ

будет

отрицательным

даже

для

самых

тривиальных

программ.

В

общем

случае,

невозможно

обнаружить

все

ошибки

програм-

мы.

А

это,

в

свою

очередь,

порождает

экономические

пробле-

мы,

задачи,

связанные

с

функциями

человека

в

процессе

отлад-

ки,

способы

построения

тестов.

6.2.1 Тестирование программы как черного ящика 

Одним

из

способов

изучения

поставленного

вопроса

яв-

ляется

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

стратегии

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

называемой

стра-

тегией

черного

ящика,

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

с

управлением

по

дан-

ным

или

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

с

управлением

по

входу-выходу.

При

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

этой

стратегии

программа

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

как

черный

ящик.

Иными

словами,

такое

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

имеет

целью

выяснение

обстоятельств,

в

которых

поведение

программы

не

соответствует

ее

спецификации.