Учебное пособие: Технология раработки програмного обеспечения УП
86
•
Даже
для
относительно
простого
случая
—
использо-
вания
целочисленных
данных
—
существуют
трудно-
сти.
Например,
все
ЭВМ
используют
слова
фиксиро-
ванной
длины
для
записи
целых
чисел.
Возможно
пе-
реполнение
разрядной
сетки,
и
аксиомы
должны
учи-
тывать
эти
условия.
•
Реальные
языки
программирования
имеют
встроенные
структуры,
которые
нелегко
поддаются
проверке
на
правильность.
Несмотря
на
отмеченные
недостатки,
доказательства
пра-
вильности
программ
достаточно
широко
применяются.
Спосо-
бы
проверки
правильности
программ
можно
использовать
при
проектировании
реальных
программ.
Для
разрабатываемой
про-
граммы
должны
быть
определены
предусловия
работы.
Даже
если
условия
не
доказаны
формально,
а
просто
установлены,
они
оказывают
неоценимую
помощь
в
понимании
структуры
разрабатываемой
программы.
Добавление
предусловий
тесно
связано
с
элементарными
программами.
Кроме
того,
предусловия
являются
базой
для
раз-
работки
тестов
программ.
Все
предусловия
могут
быть
закоди-
рованы
как
операторы
if
и
выполняться
как
часть
теста.
Контрольные
вопросы
1.
Правильность
программ.
2.
Правила
следствия.
3.
Аксиома
присвоения.
4.
Аксиома
следования.
5.
Аксиома
цикла.
6.
Аксиома
выбора.
7.
Правила
целочисленной
арифметики
—
коммутатив-
ность,
ассоциативность,
дистрибутивность,
вычитание,
обработка
констант.
8.
Доказательство
правильности
программ.
87
6
ТЕСТИРОВАНИЕ
6.1
Психология
и
экономика
тестирования
программ
Тестирование
как
объект
изучения
может
рассматривать-
ся
с
различных,
чисто
технических,
точек
зрения.
Однако
наи-
более
важными
при
изучении
тестирования
представляются
во-
просы
его
экономики
и
психологии
разработчика.
Иными
сло-
вами,
достоверность
тестирования
программы,
в
первую
оче-
редь,
определяется
тем,
кто
будет
ее
тестировать
и
каков
его
образ
мышления,
и
уже
затем
определенными
технологически-
ми
аспектами.
Поэтому,
прежде
чем
перейти
к техническим
проблемам,
мы
остановимся
на
этих
вопросах.
Поначалу
может
показаться
тривиальным
жизненно
важ-
ный
вопрос
определения
термина
«тестирование».
Необходи-
мость
обсуждения
этого
термина
связана
с
тем,
что
большинст-
во
специалистов
используют
его
неверно,
а
это,
в
свою
очередь,
приводит
к
плохому
тестированию.
Таковы,
например,
сле-
дующие
определения:
«Тестирование
представляет
собой
про-
цесс,
демонстрирующий
отсутствие
ошибок
в
программе»,
«цель
тестирования
—
показать,
что
программа
корректно
ис-
полняет
предусмотренные
функции»,
«тестирование
—
это
про-
цесс,
позволяющий
убедиться
в
том,
что
программа
выполняет
свое
назначение».
Эти
определения
описывают
нечто
противоположное
то-
му,
что
следует
понимать
под
тестированием,
поэтому
они
не-
верны.
Оставив
на
время
определения,
предположим,
что
если
мы
тестируем
программу,
то
нам
нужно
добавить
к
ней
некото-
рую
новую
стоимость
(т.е.
тестирование
стоит
денег
и
нам
же-
лательно
возвратить
затраченную
сумму
путем
увеличения
стоимости
программы).
Увеличение
стоимости
означает
повы-
шение
качества
или
возрастание
надежности
программы.
Пос
-
леднее
связано
с
обнаружением
и
удалением
из
нее
ошибок.
Следовательно,
программа
тестируется
не
для
того,
чтобы
пока-
зать,
что
она
работает,
а
скорее
наоборот
—
тестирование
начи-
нается
с
предположения,
что
в
ней
есть
ошибки
(это
предполо-
жение
справедливо
практически
для
любой
программы),
а
затем
88
уже
обнаруживается
их
максимально
возможное
число.
Таким
образом,
сформулируем
наиболее
приемлемое
определение:
Тестирование
—
это
процесс
исполнения
программы
с
целью
обнаружения
ошибок.
Пока
все
наши
рассуждения
могут
показаться
тонкой
иг-
рой
семантики,
однако
практикой
установлено,
что
именно
ими
в
значительной
мере
определяется
успех
тестирования.
Дело
в
том,
что
верный
выбор
цели
дает
важный
психологический
эф-
фект,
поскольку
для
человеческого
сознания
характерна
целевая
направленность.
Если
поставить
целью
демонстрацию
отсутст-
вия
ошибок,
то
мы
подсознательно
будем
стремиться
к
этой
цели,
выбирая
тестовые
данные,
на
которых
вероятность
появ-
ления
ошибки
мала.
В
то
же
время,
если
нашей
задачей
станет
обнаружение
ошибок,
то
создаваемый
нами
тест
будет
обладать
большей
вероятностью
обнаружения
ошибки.
Такой
подход
за-
метнее
повысит
качество
программы,
чем
первый.
Из
приведенного
определения
тестирования
вытекает
не-
сколько
следствий.
Например,
одно
из
них
состоит
в
том,
что
тестирование
—
процесс
деструктивный
(т.е.
обратный
созида
-
тельному,
конструктивному).
Именно
этим
и
объясняется,
по-
чему
многие
считают
его
трудным.
Большинство
людей
склон-
ны
к
конструктивному
процессу
созидания
объектов
и
в
мень-
шей
степени
—
к
деструктивному
процессу
разделения
на
час-
ти.
Из
определения
следует
также
то,
как
нужно
строить
набор
тестовых
данных
и
кто
должен
(а
кто
не
должен)
тестировать
данную
программу.
Для
усиления
определения
тестирования
проанализируем
два
понятия
«удачный»
и
«неудачный»
и,
в
частности,
их
ис-
пользование
руководителями
проектов
при
оценке
результатов
тестирования.
Большинство
руководителей
проектов
называют
тестовый
прогон
неудачным,
если
обнаружена
ошибка,
и,
на-
оборот,
удачным,
если
он
прошел
без
ошибок.
Чаще
всего
это
является
следствием
ошибочного
понимания
термина
«тестиро-
вание»,
так
как,
по
существу,
слово
«удачный»
означает
«ре-
зультативный»,
а
слово
«неудачный»
—
«нежелательный»,
«не-
результативный».
Но
если
тест
не
обнаружил
ошибки,
его
вы-
89
полнение
связано
с
потерей
времени
и
денег,
и
термин
«удач-
ный»
никак
не
может
быть
применен
к
нему.
Тестовый
прогон,
приведший
к
обнаружению
ошибки,
нельзя
назвать
неудачным
хотя
бы
потому,
что,
как
отмечалось
выше,
это
целесообразное
вложение
капитала.
Отсюда
следует,
что
в
слова
«удачный»
и
«неудачный»
необходимо
вкладывать
смысл,
обратный
общепринятому.
Поэтому
в
дальнейшем
бу-
дем
называть
тестовый
прогон
удачным,
если
в
процессе
его
выполнения
обнаружена
ошибка,
и
«неудачным»,
если
— кор-
ректный
результат.
Проведем
аналогию
с
посещением
больным
врача.
Если
рекомендованное
врачом
лабораторное
исследование
не
обна-
ружило
причины
болезни,
не
назовем
же
мы
такое
исследова-
ние
удачным
—
оно
неудачно:
ведь
деньги
пациент
заплатил,
а
он
все
так
же
болен.
Если
же
исследование
показало,
что
у
больного
язва
желудка,
то
оно
является
удачным,
поскольку
врач
может
прописать
необходимый
курс
лечения.
Следова-
тельно,
медики
используют
эти
термины
в
нужном
нам
смысле
(аналогия
здесь,
конечно,
заключается
в
том,
что
программа,
которую
предстоит
тестировать,
подобна
больному
пациенту).
Определения
типа
«тестирование
представляет
собой
процесс
демонстрации
отсутствия
ошибок»
порождают
еще
од-
ну
проблему:
они
ставят
цель,
которая
не
может
быть
достигну-
та
ни
для
одной
программы,
даже
весьма
тривиальной.
Резуль-
таты
психологических
исследований
показывают,
что
если
пе-
ред
человеком
ставится
невыполнимая
задача,
то
он
работает
хуже.
Иными
словами,
определение
тестирования
как
процесса
обнаружения
ошибок
переводит
его
в
разряд
решаемых
задач
и,
таким
образом,
преодолевается
психологическая
трудность.
Другая
проблема
возникает
в
том
случае,
когда
для
тес-
тирования
используется
следующее
определение:
«Тестирование
—
это
процесс,
позволяющий
убедиться
в
том,
что
программа
выполняет
свое
назначение»,
поскольку
про-
грамма,
удовлетворяющая
данному
определению,
может
содер-
жать
ошибки.
Если
программа
не
делает
того,
что
от
нее
требу-
ется,
то
ясно,
что
она
содержит
ошибки.
Однако
ошибки
могут
быть
и
тогда,
когда
она
делает,
и
что
от
нее
не
требуется.
90
Подводя
итог,
можно
сказать,
что
тестирование
представ-
ляется
деструктивным
процессом
попыток
обнаружения
оши-
бок
в
программе
(наличие
которых
предполагается).
Набор
тес-
тов,
способствующий
обнаружению
ошибки,
считается
удач-
ным.
Естественно,
в
конечном
счете,
каждый
с
помощью
тести-
рования
хочет
добиться
определенной
степени
уверенности
в
том,
что
его
программа
соответствует
своему
назначению
и
не
делает
того,
для
чего
она
не
предназначена,
но
лучшим
средст-
вом
для
достижения
этой
цели
является
непосредственный
по-
иск
ошибок.
Допустим,
кто-то
обращается
к
вам
с
заявлением:
«Моя
программа
великолепна»
(т.е.
не
содержит
ошибок).
Лучший
способ
доказать
справедливость
подобного
утвержде-
ния
—
попытаться
его
опровергнуть,
обнаружить
неточности,
нежели
просто
согласиться
с
тем,
что
программа
на
определен-
ном
наборе
входных
данных
работает
корректно.
6.2
Экономика
тестирования
Дав
такое
определение
тестированию,
необходимо
на
следующем
шаге
рассмотреть
возможность
создания
теста,
об-
наруживающего
все
ошибки
программы.
Покажем,
что
ответ
будет
отрицательным
даже
для
самых
тривиальных
программ.
В
общем
случае,
невозможно
обнаружить
все
ошибки
програм-
мы.
А
это,
в
свою
очередь,
порождает
экономические
пробле-
мы,
задачи,
связанные
с
функциями
человека
в
процессе
отлад-
ки,
способы
построения
тестов.
6.2.1 Тестирование программы как черного ящика
Одним
из
способов
изучения
поставленного
вопроса
яв-
ляется
исследование
стратегии
тестирования,
называемой
стра-
тегией
черного
ящика,
тестированием
с
управлением
по
дан-
ным
или
тестированием
с
управлением
по
входу-выходу.
При
использовании
этой
стратегии
программа
рассматривается
как
черный
ящик.
Иными
словами,
такое
тестирование
имеет
целью
выяснение
обстоятельств,
в
которых
поведение
программы
не
соответствует
ее
спецификации.