ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 10791
Скачиваний: 8
101
хология
программистов,
по-видимому,
изменяется,
когда
начи-
нается
тестирование
на
ЭВМ.
Возрастает
внутреннее
напряже-
ние,
и
появляется
тенденция
«исправлять
ошибки
так
быстро,
как
только
это
возможно».
В
результате
программисты
допус-
кают
больше
промахов
при
корректировке
ошибок,
уже
най-
денных
во
время
тестирования
на
ЭВМ,
чем
при
корректировке
ошибок,
найденных
на
более
ранних
этапах.
6.3.1 Инспекции и сквозные просмотры
Инспекции
исходного
текста
и
сквозные
просмотры
яв-
ляются
основными
методами
ручного
тестирования.
Так
как
эти
два
метода
имеют
много
общего,
они
рассматриваются
здесь
совместно.
Различия
между
ними
обсуждаются
в
последующих
разделах.
Инспекции
и
сквозные
просмотры
включают
в
себя
чте-
ние
или
визуальную
проверку
программы
группой
лиц.
Эти
ме-
тоды
развиты
из
идей
Вейнберга.
Оба
метода
предполагают
не-
которую
подготовительную
работу.
Завершающим
этапом
явля-
ется
«обмен
мнениями»
—
собрание,
проводимое
участниками
проверки.
Цель
такого
собрания
—
нахождение
ошибок,
но
не
их
устранение
(т.е.
тестирование,
а
не
отладка).
Инспекции
и
сквозные
просмотры
широко
практикуются
в
настоящее
время,
но
причины
их
успеха
до
сих
пор
еще
не-
достаточно
выяснены.
Не
удивительно,
что
они
связаны
с
неко-
торыми
принципами
(
п.
6.2).
Заметим,
что
данный
процесс
вы-
полняется
группой
лиц
(оптимально
—
три-четыре
человека),
лишь
один
из
которых
является
автором
программы.
Следова-
тельно,
программа,
по
существу,
тестируется
не
автором,
а
дру-
гими
людьми,
которые
руководствуются
изложенными
выше
принципами,
обычно
не
эффективными
при
тестировании
соб-
ственной
программы.
Фактически,
«инспекция»
и
«сквозной
просмотр»
—
просто
новые
названия
старого
метода
«проверки
за
столом»
(состоящего
в
том,
что
программист
просматривает
свою
программу
перед
ее
тестированием),
однако
они
гораздо
более
эффективны
опять-таки
по
той
же
причине:
в
процессе
участвует
не
только
автор
программы,
но
и
другие
лица.
Ре-
зультатом
использования
этих
методов,
по-видимому,
также
102
является
более
низкая
стоимость
отладки
(исправления
оши-
бок),
так
как
во
время
поиска
ошибок
обычно
точно
определя-
ют
их
природу.
Кроме
того,
с
помощью
данных
методов
обна-
руживают
группы
ошибок,
что
позволяет
в
дальнейшем
коррек-
тировать
несколько
ошибок
сразу.
С
другой
стороны,
при
тес-
тировании
на
ЭВМ
обычно
выявляют
только
симптомы
оши-
бок
(например,
программа
не
закончилась
или
напечатала
бес-
смысленный
результат),
а
сами
они
определяются
поодиночке.
Эксперименты
по
применению
этих
методов
показали,
что
с
их
помощью
для
типичных
программ
можно
находить
от
30
до
70 %
ошибок
логического
проектирования
и
кодирования
(однако
эти
методы
не
эффективны
при
определении
ошибок
проектирования
«высокого
уровня»,
например
сделанных
в
процессе
анализа
требований).
Так,
экспериментально
установ-
лено,
что
при
проведении
инспекций
и
сквозных
просмотров
определяются
в
среднем
38 %
общего
числа
ошибок
в
учебных
программах.
При
использовании
инспекций
исходного
текста
в
фирме
IBM
эффективность
обнаружения
ошибок
составляет
80 %
(в
данном
случае
имеется
в
виду
не
80 %
общего
числа
ошибок,
поскольку,
как
отмечалось
в
п.
6.2,
общее
число
оши-
бок
в
программе
никогда
не
известно,
а
80 %
всех
ошибок,
най-
денных
к
моменту
окончания
процесса
тестирования).
Конечно,
можно
критиковать
эту
статистику
в
предположении,
что
руч-
ные
методы
тестирования
позволяют
находить
только
«легкие»
ошибки
(те,
которые
можно
просто
найти
при
тестировании
на
ЭВМ),
а
трудные,
незаметные
или
необычные
ошибки
можно
обнаружить
только
при
тестировании
на
машине.
Однако
про-
веденные
исследования
показали,
что
подобная
критика
являет-
ся
необоснованной.
Исследователи
сделали
также
вывод
о
том,
что
при
нахождении
определенных
типов
ошибок
ручное
тес-
тирование
более
эффективно,
чем
тестирование
на
ЭВМ,
в
то
время
как
для
других
типов
ошибок
верно
противоположное
утверждение.
Подразумевается,
что
инспекции,
сквозные
про-
смотры
и
тестирование,
основанное
на
использовании
ЭВМ,
дополняют
друг
друга;
эффективность
обнаружения
ошибок
уменьшится,
если
тот
или
иной
из
этих
подходов
не
будет
ис-
пользован.
103
Наконец,
хотя
эти
методы
весьма
важны
при
тестирова-
нии
новых
программ,
они
представляют
не
меньшую
ценность
при
тестировании
модифицированных
программ.
Опыт
показал,
что
в
случае
модификации
существующих
программ
вносится
большее
число
ошибок
(измеряемое
числом
ошибок
на
вновь
написанные
операторы),
чем
при
написании
новой
программы.
Следовательно,
модифицированные
программы
также
должны
быть
подвергнуты
тестированию
с
применением
данных
методов.
6.3.2 Инспекции исходного текста
Инспекции
исходного
текста
представляют
собой
набор
процедур
и
приемов
обнаружения
ошибок
при
изучении
(чте-
нии)
текста
группой
специалистов.
При
рассмотрении
инспек-
ций
исходного
текста
внимание
будет
сосредоточено
в
основ-
ных
процедурах,
формах
выполнения
и
т.д.;
после
краткого
из-
ложения
основной
процедуры
мы
изучим
существующие
мето-
ды
обнаружения
ошибок.
Инспектирующая
группа
включает
обычно
четыре
чело-
века,
один
из
которых
выполняет
функции
председателя.
Пред-
седатель
должен
быть
компетентным
программистом,
но
не
ав-
тором
программы;
он
не
должен
быть
знаком
с
ее
деталями.
В
обязанности
председателя
входят
подготовка
материалов
для
заседаний
инспектирующей
группы
и
составление
графика
их
проведения,
ведение
заседаний,
регистрация
всех
найденных
ошибок
и
принятие
мер
по
их
последующему
исправлению.
Председателя
можно
сравнить
с
инженером
отдела
техническо-
го
контроля.
Членами
группы
являются
автор
программы,
про-
ектировщик
(если
он
не
программист)
и
специалист
по
тестиро-
ванию.
Общая
процедура
заключается
в
следующем.
Председа-
тель
заранее
(например,
за
несколько
дней)
раздает
листинг
программы
и
проектную
спецификацию
остальным
членам
группы.
Они
знакомятся
с
материалами,
предшествующими
за-
седанию.
Инспекционное
заседание
разбивается
на
две
части:
1.
Программиста
просят
рассказать
о
логике
работы
про-
граммы.
Во
время
беседы
возникают
вопросы,
пресле-
дующие
цель
обнаружения
ошибки.
Практика
показа-
104
ла,
что
даже
только
чтение
своей
программы
слушате-
лям
представляется
эффективным
методом
обнаруже-
ния
ошибок
и
многие
ошибки
находит
сам
програм-
мист,
а
не
другие
члены
группы.
2.
Программа
анализируется
по
списку
вопросов
для
вы-
явления
исторически
сложившихся
общих
ошибок
программирования
(такой
список
будет
рассмотрен
в
следующем
разделе).
Председатель
является
ответственным
за
обеспечение
ре-
зультативности
дискуссии.
Ее
участники
должны
сосредоточить
свое
внимание
на
нахождении
ошибок,
а
не
на
их
корректиров-
ке
(корректировка
ошибок
выполняется
программистом
после
инспекционного
заседания).
По
окончании
заседания
программисту
передается
список
найденных
ошибок.
Если
список
включает
много
ошибок
или
если
эти
ошибки
требуют
внесения
значительных
изменений,
председателем
может
быть
принято
решение
о
проведении
по-
сле
корректировки
повторной
инспекции
программы.
Список
анализируется,
и
ошибки
распределяются
по
категориям,
что
позволяет
совершенствовать
его
с
целью
повышения
эффектив-
ности
будущих
инспекций.
В
большинстве
примеров
описания
процесса
инспектиро-
вания
утверждается,
что
во
время
инспекционного
заседания
ошибки
не
должны
корректироваться.
Однако
существует
и
другая
точка
зрения:
вместо
того,
чтобы
сначала
сосредото-
читься
на
основных
проблемах
проектирования,
необходимо
решить
второстепенные
вопросы.
Два
или
три
человека,
вклю-
чая
разработчика
программы,
должны
внести
очевидные
ис-
правления
в
проект
с
тем,
чтобы
впоследствии
решить
главные
задачи.
Однако
обсуждение
второстепенных
вопросов
сконцен-
трирует
внимание
группы
на
частной
области
проектирования.
Во
время
обсуждения
наилучшего
способа
внесения
изменений
в
проект
кто-либо
из
членов
группы
может
заметить
еще
одну
проблему.
Теперь
группе
придется
рассматривать
две
проблемы
по
отношению
к
одним
и
тем
же
аспектам
проектирования,
объяснения
будут
полными
и
быстрыми.
В
течение
нескольких
минут
целая
область
проекта
может
быть
полностью
исследо-
105
вана,
и
любые
проблемы
станут
очевидными.
Как
упоминалось
выше,
многие
важные
проблемы,
возникавшие
во
время
обзо-
ров
блок-схем,
были
решены
в
результате
многократных
безус-
пешных
попыток
решить
вопросы,
которые
на
первый
взгляд
казались
«тривиальными».
Время
и
место
проведения
инспекции
должны
быть
спла-
нированы
так,
чтобы
избежать
любых
прерываний
инспекцион-
ного
заседания.
Его
оптимальная
продолжительность,
по-види
-
мому,
лежит
в
пределах
от
90
до
120
мин.
Так
как
это
заседание
является
экспериментом,
требующим
умственного
напряжения,
увеличение
его
продолжительности
ведет
к
снижению
продук-
тивности.
Большинство
инспекций
происходит
при
скорости,
равной
приблизительно
150
операторам
в
час.
При
этом
подра-
зумевается,
что
большие
программы
должны
рассматриваться
за
несколько
инспекций,
каждая
из
которых
может
быть
связана
с
одним
или
несколькими
модулями
или
подпрограммами.
Для
того
чтобы
инспекция
была
эффективной,
должны
быть
установлены
соответствующие
отношения.
Если
програм-
мист
воспринимает
инспекцию
как
акт,
направленный
лично
против
него,
и,
следовательно,
занимает
оборонительную
пози-
цию,
процесс
инспектирования
не
будет
эффективным.
Про-
граммист
должен
подходить
к
нему
с
менее
эгоистической
по-
зиции;
он
должен
рассматривать
инспекцию
в
позитивном
и
конструктивном
свете.
Объективно
инспекция
является
процес-
сом
нахождения
ошибок
в
программе
и,
таким
образом,
улуч-
шает
качество
его
работы.
По
этой
причине,
как
правило,
реко-
мендуется
результаты
инспекции
считать
конфиденциальными
материалами,
доступными
только
участникам
заседания.
В
ча-
стности,
использование
результатов
инспекции
руководством
может
нанести
ущерб
целям
этого
процесса.
Процесс
инспектирования,
в
дополнение
к
своему
основ-
ному
назначению,
заключающемуся
в
нахождении
ошибок,
вы-
полняет
еще
ряд
полезных
функций.
Кроме
того,
что
результа-
ты
инспекции
позволяют
программисту
увидеть
сделанные
им
ошибки
и
способствуют
его
обучению
на
собственных
ошиб-
ках,
он
обычно
получает
возможность
оценить
свой
стиль
про-
граммирования
и
выбор
алгоритмов
и
методов
тестирования.