ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 10805
Скачиваний: 8
96
Отсюда
вовсе
не
следует,
что
программист
не
может
тестировать
свою
программу.
Здесь
лишь
делается
вывод
о
том,
что
тестирование
является
более
эффективным,
если
оно
вы-
полняется
кем-либо
другим.
Заметим,
что
все
наши
рассужде-
ния
не
относятся
к
отладке,
т.е.
к
исправлению
уже
известных
ошибок.
Эта
работа
эффективнее
выполняется
самим
автором
программы.
Программирующая
организация
не
должна
сама
тести-
ровать
разработанные
ею
программы.
Здесь
можно
привести
те
же
аргументы,
что
и
в
преды-
дущем
случае.
Во
многих
смыслах
проектирующая
или
про-
граммирующая
организация
подобна
живому
организму
с
его
психологическими
проблемами.
Работа
программирующей
ор-
ганизации
или
ее
руководителя
оценивается
по
их
способности
производить
программы
в
течение
заданного
времени
и
опреде-
ленной
стоимости.
Одна
из
причин
такой
системы
оценок
со-
стоит
в
том,
что
временные
и
стоимостные
показатели
легко
измерить,
но
в
то
же
время
чрезвычайно
трудно
количественно
оценить
надежность
программы.
Именно
поэтому
в
процессе
тестирования
программирующей
организации
трудно
быть
объ-
ективной,
поскольку
тестирование
в
соответствии
с
данным
оп-
ределением
может
быть
рассмотрено
как
средство
уменьшения
вероятности
соответствия
программы
заданным
временным
и
стоимостным
параметрам.
Как
и
ранее,
из
изложенного
не
следует,
что
программи-
рующая
организация
не
может
найти
свои
ошибки;
тестирова-
ние
в
определенной
степени
может
пройти
успешно.
Мы
ут-
верждаем
здесь
лишь
то,
что
экономически
более
целесообраз-
но
выполнение
тестирования
каким-либо
объективным,
незави-
симым
подразделением.
Необходимо
досконально
изучать
результаты
примене-
ния
каждого
теста.
По
всей
вероятности,
это
наиболее
очевидный
принцип,
но
и
ему
часто
не
уделяется
должное
внимание.
В
проведенных
экспериментах
многие
испытуемые
не
смогли
обнаружить
оп-
ределенные
ошибки,
хотя
их
признаки
были
совершенно
явны-
ми
в
выходных
листингах.
Представляется
достоверным,
что
97
значительная
часть
всех
обнаруженных
в
конечном
итоге
оши-
бок
могла
быть
выявлена
в
результате
самых
первых
тестовых
прогонов,
но
они
были
пропущены
вследствие
недостаточно
тщательного
анализа
результатов
первого
тестового
прогона.
Тесты
для
неправильных
и
непредусмотренных
входных
данных
следует
разрабатывать
так
же
тщательно,
как
для
правильных
и
предусмотренных.
При
тестировании
программ
имеется
естественная
тен-
денция
концентрировать
внимание
на
правильных
и
предусмот-
ренных
входных
условиях,
а
неправильным
и
непредусмотрен-
ным
входным
данным
не
придавать
значения.
Например,
при
тестировании
задачи
о
треугольниках,
приведенной
в
п.
6.2.1,
лишь
немногие
смогут
привести
в
качестве
теста
длины
сторон
1,
2
и
5,
чтобы
убедиться
в
том,
что
треугольник
не
будет
оши-
бочно
интерпретирован
как
неравносторонний.
Множество
ошибок
можно
также
обнаружить,
если
использовать
програм-
му
новым,
не
предусмотренным
ранее
способом.
Вполне
веро-
ятно,
что
тесты,
представляющие
неверные
и
неправильные
входные
данные,
обладают
большей
обнаруживающей
способ-
ностью,
чем
тесты,
соответствующие
корректным
входным
данным.
Необходимо
проверять
не
только,
делает
ли
программа
то,
для
чего
она
предназначена,
но
и
не
делает
ли
она
то,
что
не
должна
делать.
Это
логически
просто
вытекает
из
предыдущего
принци-
па.
Необходимо
проверить
программу
на
нежелательные
по-
бочные
эффекты.
Например,
программа
расчета
зарплаты,
кото-
рая
производит
правильные
платежные
чеки,
окажется
невер-
ной,
если
она
произведет
лишние
чеки
для
работающих
или
дважды
запишет
первую
запись
в
список
личного
состава.
Не
следует
выбрасывать
тесты,
даже
если
программа
уже
не
нужна.
Эта
проблема
наиболее
часто
возникает
при
использова-
нии
интерактивных
систем
отладки.
Обычно
тестирующий
си-
дит
за
терминалом,
на
лету
придумывает
тесты
и
запускает
про-
грамму
на
выполнение.
При
такой
практике
работы
после
при-
менения
тесты
пропадают.
После
внесения
изменений
или
ис-
98
правления
ошибок
необходимо
повторять
тестирование,
тогда
приходится
заново
изобретать
тесты.
Как
правило,
этого
стара-
ются
избегать,
поскольку
повторное
создание
тестов
требует
значительной
работы.
В
результате
повторное
тестирование
бы-
вает
менее
тщательным,
чем
первоначальное,
т.е.
если
модифи-
кация
затронула
функциональную
часть
программы
и
при
этом
была
допущена
ошибка,
то
она
зачастую
может
остаться
необ-
наруженной.
Нельзя
планировать
тестирование
в
предположении,
что
ошибки
не
будут
обнаружены.
Такую
ошибку
обычно
допускают
руководители
проекта,
использующие
неверное
определение
тестирования
как
процес-
са
демонстрации
отсутствия
ошибок
в
программе,
корректного
функционирования
программы.
Вероятность
наличия
необнаруженных
ошибок
в
части
программы
пропорциональна
числу
ошибок,
уже
обнаруженных
в
этой
части.
Этот
принцип,
не
согласующийся
с
интуитивным
пред-
ставлением,
иллюстрируется
рис.
6.2.
Рис.
6.2
—
Неожиданное
соотношение
числа
оставшихся
и
числа
обнаруженных
ошибок
Число
обнаруженных
ошибок
Ве
ро
ят
но
ст
ь
на
ли
чи
я
нео
бна
ру
ж
ен
ных
ош
иб
ок
99
На
первый
взгляд
он
лишен
смысла,
но
тем
не
менее
под-
тверждается
многими
программами.
Например,
допустим,
что
некоторая
программа
состоит
из
модулей
A
и
B.
К
определен-
ному
сроку
в
модуле
A
обнаружено
пять
ошибок,
а
в
модуле
B
—
только
одна,
причем
модуль
A
не
подвергался
более
тща-
тельному
тестированию.
Тогда
из
рассматриваемого
принципа
следует,
что
веро-
ятность
необнаруженных
ошибок
в
модуле
A
больше,
чем
в
мо-
дуле
B.
Справедливость
этого
принципа
подтверждается
еще
и
тем,
что
для
ошибок
свойственно
располагаться
в
программе
в
виде
неких
скоплений,
хотя
данное
явление
пока
никем
еще
не
объяснено.
В
качестве
примера
можно
рассмотреть
операцион-
ные
системы
IBM
S/370.
В
одной
из
версий
операционной
сис-
темы
47 %
ошибок,
обнаруженных
пользователями,
приходи-
лось
на
4 %
модулей
системы.
Преимущество
рассматриваемого
принципа
заключается
в
том,
что
он
позволяет
ввести
обратную
связь
в
процесс
тести-
рования.
Если
в
какой-нибудь
части
программы
обнаружено
больше
ошибок,
чем
в
других,
то
на
ее
тестирование
должны
быть
направлены
дополнительные
усилия.
Тестирование
—
процесс
творческий.
Вполне
вероятно,
что
для
тестирования
большой
про-
граммы
требуется
больший
творческий
потенциал,
чем
для
ее
проектирования.
Выше
было
показано,
что
нельзя
дать
гаран-
тию
построения
теста,
обнаруживающего
все
ошибки.
В
даль-
нейшем
здесь
будут
обсуждаться
методы
построения
хороших
наборов
тестов,
но
применение
этих
методов
должно
быть
творческим.
Чтобы
подчеркнуть
некоторые
мысли,
высказанные
в
на-
стоящем
разделе,
приведем
еще
раз
три
наиболее
важных
прин-
ципа
тестирования.
Тестирование
—
это
процесс
выполнения
программ
с
це-
лью
обнаружения
ошибок.
Хорошим
считается
тест,
который
имеет
высокую
ве-
роятность
обнаружения
еще
не
выявленной
ошибки.
Удачным
считается
тест,
который
обнаруживает
еще
не
выявленную
ошибку.
100
6.3
Ручное
тестирование
В
течение
многих
лет
большинство
программистов
были
убеждены
в
том,
что
программы
пишутся
исключительно
для
выполнения
их
на
машине
и
не
предназначены
для
чтения
че-
ловеком,
а
единственным
способом
тестирования
программы
является
ее
исполнение
на
ЭВМ.
Это
мнение
стало
изменяться
в
начале
70-х
годов,
а
значительной
степени
—
благодаря
книге
Вейнберга
«Психология
программирования
для
ЭВМ».
Вейн
-
берг
доказал,
что
программы
должны
быть
удобочитаемыми
и
что
их
просмотр
должен
быть
эффективным
процессом
обна-
ружения
ошибок.
По
этой
причине,
прежде
чем
перейти
к
обсуждению
тра-
диционных
методов
тестирования,
основанных
на
применении
ЭВМ,
рассмотрим
процесс
тестирования
без
применения
ЭВМ
(«ручного
тестирования»),
являющейся
темой
настоящего
раз-
дела.
Эксперименты
показали,
что
методы
ручного
тестирова-
ния
достаточно
эффективны
с
точки
зрения
нахождения
оши-
бок,
так
что
один
или
несколько
из
них
должны
использоваться
в
каждом
программном
проекте.
Описанные
здесь
методы
предназначены
для
периода
разработки,
когда
программа
зако-
дирована,
но
тестирование
на
ЭВМ
еще
не
началось.
Аналогич-
ные
методы
могут
быть
получены
и
применены
на
более
ран-
них
этапах
процесса
создания
программ
(т.е.
в
конце
каждого
этапа
проектирования),
но
рассмотрение
этого
вопроса
выходит
за
рамки
данного
пособия.
Следует
заметить,
что
из-за
неформальной
природы
мето-
дов
ручного
тестирования
(неформальной
с
точки
зрения
дру-
гих,
более
формальных
методов,
таких,
как
математическое
до-
казательство
корректности
программ)
первой
реакцией
часто
является
скептицизм,
ощущение
того,
что
простые
и
нефор-
мальные
методы
не
могут
быть
полезными.
Однако
их
исполь-
зование
показало,
что
они
не
«уводят
в
сторону».
Скорее
эти
методы
способствуют
существенному
увеличению
производи
-
тельности
и
повышению
надежности
программы.
Во-первых,
они
обычно
позволяют
раньше
обнаружить
ошибки,
уменьшить
стоимость
исправления
последних
и
увеличить
вероятность
то-
го,
что
корректировка
произведена
правильно.
Во-вторых,
пси-