Книжная полка Сохранить
Размер шрифта:
А
А
А
|  Шрифт:
Arial
Times
|  Интервал:
Стандартный
Средний
Большой
|  Цвет сайта:
Ц
Ц
Ц
Ц
Ц

Тестирование и отладка программ для профессионалов будущих и настоящих

Покупка
Артикул: 801910.01.99
Изложена теория тестирования и отладки программ, причем рассматриваются как вопросы, интересные начинающим программистам, так и вопросы, полезные профессионалам, например вероятностные модели оценки количества ошибок в программе и количества необходимых тестов. Описание простой в использовании высокотехнологичной методики тестирования учебных программ подкрепляется примерами создания программ, в которых тестирование выступает как неотъемлемый аспект разработки программы. Отдельная глава посвящена подробному описанию отладочных средств системы Турбо Паскаль, широко используемой в школах и вузах для обучения программированию. Для тех, кто изучает и учит программированию: старшеклассников, студентов, преподавателей вузов, учителей; также полезна и для профессиональных программистов.
Плаксин, М. А. Тестирование и отладка программ для профессионалов будущих и настоящих : учебное пособие / М. А. Плаксин. - 4-е изд. - Москва : Лаборатория знаний, 2020. - 170 с. - ISBN 978-5-00101-810-0. - Текст : электронный. - URL: https://znanium.com/catalog/product/1987457 (дата обращения: 29.03.2024). – Режим доступа: по подписке.
Фрагмент текстового слоя документа размещен для индексирующих роботов. Для полноценной работы с документом, пожалуйста, перейдите в ридер.
М. ПЛАКСИН
ТЕСТИРОВАНИЕ

И ОТЛАДКА ПРОГРАММ

ДЛЯ ПРОФЕССИОНАЛОВ БУДУЩИХ И НАСТОЯЩИХ

Москва
Лаборатория знаний
2020

4-е издание, электронное

УДК 004.42
ББК 32.973-018

П37

Плаксин М. А.

П37
Тестирование и отладка программ для профессионалов 
будущих и настоящих / М. А. Плаксин. — 4-е изд.,
электрон. — М. : Лаборатория знаний, 2020. — 170 с. —
Систем. требования: Adobe Reader XI ; экран 10".—
Загл. с титул. экрана. — Текст : электронный.
ISBN 978-5-00101-810-0
Изложена теория тестирования и отладки программ, причем 
рассматриваются как вопросы, интересные начинающим
программистам, так и вопросы, полезные профессионалам,
например вероятностные модели оценки количества ошибок
в программе и количества необходимых тестов. Описание
простой
в
использовании
высокотехнологичной
методики
тестирования учебных программ подкрепляется примерами
создания программ, в которых тестирование выступает как
неотъемлемый
аспект
разработки
программы.
Отдельная
глава посвящена подробному описанию отладочных средств
системы
Турбо
Паскаль, широко
используемой
в
школах
и вузах для обучения программированию.
Для тех, кто изучает и учит программированию: стар-
шеклассников, студентов, преподавателей вузов, учителей;
также полезна и для профессиональных программистов.
УДК 004.42
ББК 32.973-018

Деривативное издание на основе печатного аналога: Тестирование 
и отладка программ для профессионалов будущих
и настоящих / М. А. Плаксин. — М. : БИНОМ. Лаборатория
знаний, 2007. — 167 с. : ил. — ISBN 978-5-94774-458-3.

В
соответствии
со
ст. 1299
и
1301
ГК
РФ
при
устранении
ограничений, установленных техническими средствами защиты
авторских прав, правообладатель вправе требовать от нарушителя
возмещения убытков или выплаты компенсации

ISBN 978-5-00101-810-0
c○ Лаборатория знаний, 2015

Оглавление

Введение .................................................
5

Глава 1. В каком случае программа содержит ошибку? ..
7

Глава 2. Минимальные требования к программе: функциональность 
и удобство использования .......
9

Глава 3. Понятия тестирования и отладки .............. 10
Глава 4. Принципы тестирования....................... 11
Глава 5. Понятие полноты тестирования ................ 15
Глава 6. Критерии черного ящика....................... 18
Глава 7. Критерии белого ящика ........................ 22
Глава 8. Минимально грубое тестирование .............. 27
Глава 9. Ошибкоопасные ситуации...................... 32

9.1. Обращение к данным ........................... 32
9.2. Вычисления.................................... 36
9.3. Передача управления........................... 45
9.4. Подпрограммы ................................. 47
9.5. Файлы ......................................... 50

Глава 10. Безмашинное тестирование .................... 53
Глава 11. Пример тестирования несложной программы .. 56
Глава 12. Порядок работы над программой .............. 67
Глава 13. Нисходящее тестирование ..................... 68
Глава 14. *Оценка количества ошибок в программе ...... 71

14.1. Модель Миллса ................................ 71
14.2. «Парная» оценка............................... 78
14.3. Исторический опыт ............................ 79

Глава 15. *Оценка количества необходимых тестов ...... 81
Глава 16. Отладка ....................................... 84

16.1. Место проявления ошибки и место нахождения
ошибки ........................................ 84

16.2. Отладочные операторы ......................... 85
16.3. Индуктивный и дедуктивный методы поиска
ошибки. Ретроанализ .......................... 89

16.4. Принципы отладки ............................ 92
16.5. Анализ обнаруженной ошибки ................. 93

Оглавление

Глава 17. Отладочные средства системы Турбо Паскаль .. 94

17.1. Перечень отладочных средств Турбо Паскаля ... 94
17.2. Пошаговое выполнение программы............. 96
17.3. Контрольные точки ............................ 98
17.4. Просмотр и вычисление значений переменных
и выражений...................................103

17.5. Наблюдение за стеком вызванных подпрограмм 107
17.6. Локальное
меню
окна
редактирования
программы ........................................
109

Глава 18. Еще один пример тестирования программы ....110

18.1. Построение
тестов
для
критериев
черного
ящика .........................................110

18.2. Написание текста программы ..................118
18.3. Подготовка к тестированию по критериям белого 
ящика ....................................122

18.4. «Сухая прокрутка» ............................123
18.5. Отладка на компьютере ........................150
18.6. Уроки данного примера ........................160

Глава 19. Что еще можно проверить в программе?........162
Заключение ..............................................165
Что читать дальше?.......................................167

Учебные планы программистских факультетов большинства
вузов подразумевают, что студенты-первокурсники уже умеют
программировать. Однако тот курс программирования, который 
входит в школьную программу, недостаточен. В частности,
в нем почти не уделяется внимания таким важным вопросам,
как тестирование и отладка. Профессионалы знают, что затраты 
на тестирование и отладку оцениваются в 50–60% всех
затрат на разработку программы. Но для подавляющего боль-
шинства школьников, да и многих студентов «написать про-
грамму» означает написать некий текст на языке программиро-
вания и, в лучшем случае, добиться того, чтобы в нем не было
ошибок трансляции. О проверке соответствия программы по-
ставленной задаче, поиске и исправлении смысловых ошибок,
как правило, речь даже не заходит. Причиной этого в большой
степени является отсутствие наглядной и доходчивой методики
тестирования и отладки программ.
В данной книге изложена методика тестирования учебных
программ, основанная на классических научных исследовани-
ях и опыте преподавания начального курса программирования в
старших классах средней школы и младших курсах университе-
та. Подробно рассматриваются отладочные средства популярной
системы Турбо Паскаль. В главах 14 и 15 описываются стати-
стические модели оценки количества ошибок в программе и ко-
личества тестов, необходимых для их обнаружения. Изучение
этого материала требует определенной математической подго-
товки. Данные главы отмечены звездочкой.

Классик жанра Гленфорд Майерс свою легендарную книгу
«Искусство тестирования программ» начал с того, что предло-
жил читателям сформировать набор тестов для проверки прос-
тенькой программы. Программа читала 3 целых числа (у Май-
ерса — с перфокарт, мы скажем — из файла; впрочем, кто не
умеет вводить числа из файла, может вводить их с терминала),
рассматривала их как длины сторон треугольника и печатала
сообщение о том, является ли этот треугольник разносторон-
ним, равносторонним или равнобедренным. Далее набор тестов,
предложенный читателем, надо было сравнить с набором, пред-
ложенным самим Майерсом.

Введение

Мы также используем майерсову задачу, но порядок работы
несколько изменим. Читателю предлагается составить набор
тестов для задачи про треугольники. Но обсуждать полученный
набор немедленно мы не будем. Вместо этого мы еще несколько
раз вернемся к этой задаче по ходу изучения темы с тем, чтобы
читатель мог на практике применить получаемые знания и оце-
нить свой прогресс в этой области. И только после этого мы об-
судим полученный результат.
Итак, перед дальнейшим чтением вам предлагается самостоя-
тельно составить набор тестов для вышеуказанной программы.
Готово? Тогда — продолжим.

6
Введение

Понятия тестирования и отладки связаны с процессом поис-
ка и исправления ошибок в программе. Поэтому первый во-
прос, на который надо ответить, будет звучать так: в каком
случае в программе есть ошибка?

Программа содержит ошибку, если она ведет себя неразумно
с точки зрения пользователя.

Это утверждение повергает новичков в замешательство: от-
куда же я знаю, какое поведение программы пользователь со-
чтет разумным? Но если вы не знаете, какое поведение про-
граммы разумно с точки зрения вашего заказчика, значит, вы
не понимаете, какую задачу решаете. Как можно писать про-
грамму, не понимая, что она должна делать?
Как определить разумность поведения программы?
Во-первых, естественно, программа должна быть верна син-
таксически, т. е. при ее трансляции не должно быть ошибок.
Текст, содержащий синтаксические ошибки, вообще не имеет
права называться программой. Такая «программа» вообще ни-
как себя не ведет.
Во-вторых, программа должна правильно решать поставлен-
ную перед ней задачу. То есть при вводе в нее корректных ис-
ходных данных она должна выдавать правильный результат.
Какой именно результат считать правильным, надо уточнить у
заказчика. Например, если вам заказывают программу для вы-
числения квадратного корня, то должна ли она выдавать оба
корня (положительный и отрицательный) или только арифме-
тический? Корень из нуля — это 0 или просто 0? Какова тре-
буемая точность? Она всегда должна быть одна и та же или мо-
жет меняться? Если меняться, то каким образом и по чьей
инициативе? Надо ли выявлять периодические дроби? Как про-
грамма должна реагировать на отрицательное подкоренное вы-
ражение? А на предложение извлечь корень из a 2? Вы можете
предложить свои ответы на все эти вопросы. Но в данном слу-
чае важно не то, что думаете по этому поводу вы, а то, что ду-
мает по этому поводу ваш заказчик. Ваша задача — выявить и
сформулировать все эти вопросы, а не придумывать на них
свои собственные ответы. Для выявления и формулировки во-
просов полезно не хвататься за клавиатуру сразу же, как толь-

Глава 1

Вкакомслучаепрограмма
содержитошибку?

ко вам дадут задание на разработку программы, а сначала не-
ко вам дадут задание на разработку программы, а сначала немножко 
подумать. Все эти вопросы все равно возникнут в процессе 
разработки программы. Но если их не оговорить заранее,
ответы на них вы будете придумывать сами, и нет никакой гарантии, 
что они покажутся заказчику разумными.
В-третьих, программа не должна делать ничего лишнего.
При вычислении квадратного корня не надо менять настройки
операционной системы и исполнять вашу любимую мелодию.
В-четвертых, результат должен быть получен через разумное 
время при разумных затратах других ресурсов. Если программа 
при вычислении квадратного корня из числа выдает де-
сятистраничную распечатку, в ней, наверное, что-то не так.
И наконец, в-пятых, программа должна разумно реагировать 
на ввод некорректных входных данных и на непредусмотренные 
заранее ситуации. Например, если программа вычисляет 
квадратный корень, а пользователь вместо подкоренного
выражения ввел свою фамилию, то программа должна распознать, 
что введенная строка — не число1, и сообщить об этом
пользователю на его родном языке, а не заканчивать работу
аварийно. Если вы разработали программу для управления аэропортом, 
рассчитанную на то, что в небе могут быть одновременно 
не более 20 самолетов, а в какой-то момент их оказалось 21,
ваша программа должна отреагировать на это неким разумным
образом. Например, сообщить о чрезвычайной ситуации диспетчеру 
и экипажу и передать этот борт диспетчеру для ручного ведения. 
Вариант, когда появление 21-го самолета приведет к
тому, что программа потеряет один из ранее ведомых самолетов
или просто отключится, совершенно недопустим.
В поддержку данного выше утверждения об ошибках в программе 
в [2] упоминается следующая история. При разработке
системы противоракетной обороны США военные заказчики
потребовали от программистов, чтобы система подавала сигнал
тревоги, если обнаружит в небе враждебный летательный объект. 
Программисты спросили, какой объект считать враждебным. 
Военные ответили: любой, который не будет опознан как
дружественный. Программисты добросовестно заложили в систему 
полученные от военных правила распознавания дружественных 
летательных объектов. В ночь испытания системы над
горизонтом взошла Луна... Была ли в данном случае выдача
сигнала к началу III Мировой войны верным поведением про-
граммы, или в ней все-таки была ошибка?

8
Глава1

1
В Турбо Паскале для преобразования последовательности литер, представля-
ющей собой изображение числа, в число (и проверки правильности записи
числа) используется процедура Val. Для организации собственной диагнос-
тики любое значение следует вводить как строковое и преобразовывать в чис-
ло с помощью процедуры Val.

Минимальные требования к любой программе — это обес-
печение требуемой функциональности (реализация требуемых
функций) и удобство эксплуатации. Именно они должны быть
проверены в первую очередь.
Почти вся оставшаяся часть книги будет посвящена тестиро-
ванию функциональности. Удобство взаимодействия человека
с программой останется вне нашего внимания. Относительно
него ограничимся только одним замечанием. Лозунг современ-
ного интерфейса: «Не пользователь должен приспосабливаться
к программе, а программа к пользователю». Даже самая про-
стая программа должна обеспечить пользователю некоторый
уровень комфорта. Например, совершенно недопустима ситуа-
ция, когда после запуска программы перед пользователем воз-
никает пустой экран с мигающим курсором и больше ничего.
Пользователю предлагается самому догадаться, что за програм-
му он запустил и что он должен делать дальше. Как минимум,
программа должна сообщить о своей функциональности и объ-
яснить свое поведение (выдать осмысленное приглашение к
вводу или сообщить, почему возникла пауза).

Глава 2

Минимальныетребования
кпрограмме:функциональность
иудобствоиспользования

Тестирование — это выполнение программы с целью обна-
ружения факта наличия в программе ошибки.
Отладка — определение места ошибки и внесение исправле-
ний в программу.
В русском языке словосочетание «обнаружить ошибку» мо-
жет иметь, по крайней мере, два смысла: «обнаружить факт на-
личия ошибки» и «обнаружить место, где допущена ошибка».
Под тестированием понимается обнаружение ошибки в первом
смысле, под отладкой — во втором.
Как правило, эти два процесса тесно взаимосвязаны, но мо-
гут быть и разделены. Например, в процессе приемки системы
заказчик занимается только тестированием — поиском несоот-
ветствий между заданием на разработку программы (специфи-
кацией программы) и разработанной программой. Если его по-
иски увенчаются успехом, программисту придется заниматься
отладкой (определением места допущенных ошибок и исправ-
лением программы).

Цель тестирования — обнаружение ошибок в программе.

Отметим важный психологический момент: цель тестирова-
ния — не доказать правильность программы, а обнаружить
в ней ошибки! Если вы ставите себе задачей показать, что про-
грамма правильная и ошибок не содержит, то (на подсознатель-
ном уровне) и тесты будете подбирать такие, которые ошибок
в программе не обнаружат.
Отсюда следующее неожиданное рассуждение. Зададим во-
прос: какой тест считать удачным? Если цель тестирования —
найти в программе ошибку, то удачным должен считаться тест,
который обнаруживает наличие в ней ошибки. Это положение
противоречит интуитивному представлению о тестировании и
требует сознательного психологического настроя.

Глава 3

Понятиятестирования
иотладки

1. Ошибки в программе есть.

Необходимо исходить из того, что ошибки в программе есть.
Иначе тестирование не будет иметь для вас никакого смысла,
и отношение к нему будет соответственное.

2. Тест — это совокупность исходных данных и ожидаемых
результатов.

Очень частая ошибка заключается в том, что на вход про-
грамме подаются данные, для которых заранее не известны
правильные результаты. Здесь в дело опять вступает психоло-
гия. Человеческая психика устроена так, что наши глаза очень
часто видят не то, что есть на самом деле, а то, что нам хочется
видеть. Если заранее не зафиксировать ожидаемый результат,
то всегда возникает искус объявить, что полученные результа-
ты — это и есть то, что должно было получиться.

3. Тестовые данные должны быть достаточно просты для про-
верки.

Прямое следствие предыдущего принципа.

4. Тесты готовятся заранее, до выхода на машину.

Это касается как исходных данных, так и ожидаемых ре-
зультатов. Реально в подавляющем большинстве случаев тесты
придумываются на ходу, причем только исходные данные.

5. Первые тесты разрабатываются после получения задания
на разработку программы до написания программного кода.

Самые первые тесты следует продумать сразу же после по-
становки задачи до того, как начали писать программный код.
Ранняя разработка тестов позволяет правильно понять постав-
ленную задачу. Даже в самых простых и, на первый взгляд,
очевидных заданиях часто встречаются тонкости, которые сра-
зу не видны, но становятся заметны, когда вы пытаетесь опре-
делить результат, соответствующий конкретным входным дан-
ным. (Пример уточнений, которых потребовала программа для
извлечения квадратного корня, приведен в главе 1 «В каком

Глава 4

Принципытестирования

случае программа содержит ошибку?».) Цель ранней разработки
тестов — уточнить постановку задачи, выявить тонкие места.
Без этого вы рискуете написать программу, которая будет ре-
шать какую-то иную задачу, а не ту, которая была перед вами
поставлена. О методике разработки тестов до написания про-
граммы речь пойдет ниже в главе 6 «Критерии черного ящика».

6. Перед началом тестирования следует сформулировать цели,
которые должны быть достигнуты в ходе тестирования.

В частности, набор тестов должен быть полон с точки зре-
ния выбранных критериев полноты тестирования. О критери-
ях полноты тестирования речь пойдет в главе 6 «Критерии чер-
ного ящика», седьмой главе «Критерии белого ящика», главе 8
«Минимально грубое тестирование». Независимо от применяе-
мых критериев разработка тестов должна вестись систематиче-
ски, по определенной методике.

7. В процессе тестирования необходимо фиксировать выполнен-
ные тесты и реально полученные результаты.

К сожалению, обычной является ситуация, когда студент,
получив задание, сразу же садится за компьютер, вводит неко-
торый программный текст, после нескольких перетрансляций
избавляется от синтаксических ошибок, после чего запускает
полученную программу, на ходу придумывает и подает на вход
программы некие исходные данные, получает результаты, вво-
дит новые данные, опять получает результаты и т. д. Тестовые
данные и результаты нигде не фиксируются. Для любых нетри-
виальных программ подобное тестирование почти бесполезно,
поскольку не позволяет отделить проверенные участки от не-
проверенных, не позволяет оценить количество ошибок в про-
грамме, не дает информации для принятия решения об оконча-
нии тестирования.

8. Тесты должны быть одинаково тщательны как для пра-
вильных, так и для неправильных входных данных.

На практике часто ограничиваются тестированием правиль-
ных входных данных, забывая о неправильных.

9. Необходимо проверить два момента: программа делает то,
что должна делать; программа не делает того, чего делать
не должна.

Особенно это важно для изменений в глобальной среде. Если
программа выдает правильные результаты, но при этом затирает
половину винчестера, то едва ли ее можно признать правильной.

12
Глава4