ГЛАВА 22 Тестирование, выполняемое разработчиками
517
Символические отладчики
Символический отладчик — это технологическое дополне- ние анализа и инспекций кода. Отладчик может выполнять код строка за строкой, позволяет следить за значениями переменных и всегда интерпретирует код так же, как ком- пьютер. Возможность пошагового выполнения кода и наблю- дения за его работой трудно переоценить.
Анализ кода при помощи отладчика во многом напоминает процесс обзора ва- шего кода другими программистами. Ни ваши коллеги, ни отладчик не имеют тех же слабых сторон, которые имеете вы. Дополнительное преимущество отладчика в том, что анализ кода с его помощью менее трудоемок, чем групповой обзор.
Наблюдение за выполнением кода при разных комбинациях входных данных позволяет убедиться в том, что вы написали то, что хотели.
Кроме того, использование хорошего отладчика является эффективным способом изучения языка, поскольку вы можете получить точную информацию о выполне- нии кода. Переключаясь между высокоуровневым языком и ассемблером, вы мо- жете изучить соответствие высокоуровневых и низкоуровневых конструкций.
Наблюдение за регистрами и стеком позволяет лучше разобраться в передаче аргументов в методы. Вы можете увидеть, как компилятор оптимизирует код. Ни- какое из этих преимуществ не имеет прямого отношения к главной роли отлад- чика — диагностике уже обнаруженных ошибок, но при творческом подходе из отладчика можно извлечь гораздо большую выгоду.
Инструменты возмущения состояния системы
Другой класс инструментов тестирования предназначен для приведения системы в возмущенное состояние. Многие программисты могут рассказать истории о программах, ко- торые работают 99 раз из 100, но при сотом запуске с теми же данными терпят крах. Почти всегда причиной этого является невыполнение инициализации ка- кой-то переменной, и обычно эту ошибку очень трудно воспроизвести, потому что в 99 случаях из 100 неинициализированная переменная получает нулевое значение.
Инструменты тестирования из этого класса могут иметь самые разнообразные возможности.
쐽
Заполнение памяти Эта функция помогает находить неинициализирован- ные переменные. Некоторые инструменты перед запуском программы запол- няют память произвольными значениями, чтобы неинициализированные пе- ременные не получили случайно значение 0. Иногда память целесообразно за- полнять конкретным значением. Например, в случае процессоров с архитек- турой x86 значение 0xCC соответствует машинному коду команды прерыва- ния. Если вы заполните память значением 0xCC и программа попробует вы- полнить что-то, чего выполнять не следует, вы натолкнетесь в отладчике на точку прерывания и обнаружите ошибку.
쐽
«Встряхивание» памяти В многозадачных средах некоторые инструменты могут переупорядочивать выделенную программе память, что позволяет гаран-
Перекрестная ссылка Наличие отладчиков зависит от зрелос- ти технологической среды (см.
раздел 4.3).
http://cc2e.com/2289
518
ЧАСТЬ V Усовершенствование кода тировать отсутствие кода, требующего, чтобы данные находились по абсолют- ным, а не относительным адресам.
쐽
Селективный сбой памяти Драйвер памяти позволяет имитировать недо- статок или неудачный запрос памяти, может отказывать в запросе памяти после произвольного числа успешных запросов или предоставлять запрошенную память после произвольного числа неудовлетворенных запросов. Это особен- но полезно при тестирования сложных программ, выделяющих память дина- мически.
쐽
Проверка доступа к памяти (проверка границ) Инструменты проверки границ следят за операциями над указателями, гарантируя их корректность.
Такие инструменты полезны при поиске неинициализированных или «вися- чих» указателей.
Базы данных для хранения информации об ошибках
БД, содержащая информацию об обнаруженных ошибках,
— тоже мощный инструмент тестирования. Такую базу мож- но рассматривать и как инструмент управления, и как тех- нический инструмент. Она позволяет узнавать о появлении старых ошибок, сле- дить за частотой обнаружения и исправления новых ошибок, а также за статусом и тяжестью исправленных и неисправленных ошибок. О том, какую информацию об ошибках следует хранить в БД, вы узнаете в разделе 22.7.
22.6. Оптимизация процесса тестирования
Способы улучшения тестирования аналогичны способам улучшения любого дру- гого процесса. Опираясь на точные знания о процессе, вы немного изменяете его и смотрите, к каким результатам это приводит. Если результат изменения поло- жителен, значит, процесс стал несколько лучше. В следующих подразделах опти- мизация процессов рассматривается в контексте тестирования.
Планирование тестирования
Эффективность тестирования заметно повышается, если его спланировать в самом начале работы над проектом. При- своение тестированию той же степени важности, что и про- ектированию с кодированием, подразумевает, что на тес- тирование будет выделено время, что оно будет считаться не менее важным и что процесс тестирования будет высо- кокачественным. Планирование тестирования нужно и для обеспечения
повторяемости процесса тестирования. Если процесс нельзя повторить, его нельзя улучшить.
Повторное (регрессивное) тестирование
Допустим, вы тщательно протестировали систему и не обнаружили ошибок. Пред- положим далее, что вы изменяете какой-то фрагмент системы и хотите убедить- ся в том, что она по-прежнему успешно проходит все тесты, т. е. что изменение
Перекрестная ссылка Одним из элементов планирования тести- рования является формализа- ция планов в письменной фор- ме. О документировании тести- рования см. работы, указанных в разделе «Дополнительные ресурсы» главы 32.
http://cc2e.com/2296
1 ... 59 60 61 62 63 64 65 66 ... 104
ГЛАВА 22 Тестирование, выполняемое разработчиками
519
не привело к появлению новых дефектов. Тестирование, призванное гарантиро- вать, что программа не сделала шаг назад, или не «регрессировала», называется
«регрессивным».
Почти невозможно создать высококачественную программу, если вы не можете си- стематично проводить ее повторного тестирования после внесения изменений. Если после каждого изменения выполнять другие тесты, вы не сможете с уверенностью сказать, что в программу не были внесены новые дефекты. Так что при регрессив- ном тестировании нужно каждый раз выполнять одни и те же тесты. По мере разви- тия системы можно добавлять новые тесты, но сохранять при этом и старые.
Автоматизированное тестирование
Единственный практичный способ управления регрессивным тестиро- ванием — его автоматизация. Многократное выполнение одних и тех же тестов, приводящих к тем же результатам, вводит людей в транс. Они утрачивают концентрацию и начинают упускать ошибки, что сводит на нет эф- фективность регрессивного тестирования. Гуру тестирования Борис Бейзер сооб- щает, что уровень ошибок, допускаемых при тестировании вручную, сравним с уровнем ошибок в самом тестируемом коде. По его оценкам, при тестировании,
проводимом вручную, должным образом выполняется лишь около половины всех тестов (Johnson, 1994).
Преимущества автоматизированного тестирования таковы.
쐽
При автоматизированном тестировании вероятность допустить ошибку ниже,
чем при тестировании вручную.
쐽
Автоматизировав тестирование, вы сможете легко адаптировать его к другим компонентам системы.
쐽
Автоматизация тестирования позволяет выполнять тесты гораздо чаще. Авто- матизация тестирования — один из базовых элементов интенсивных методик тестирования, таких как ежедневная сборка программы, дымовое тестирова- ние и экстремальное программирование.
쐽
Автоматизированное тестирование способствует максимально раннему обна- ружению проблем, что обычно минимизирует объем работы, нужной для ди- агностики и исправления проблемы.
쐽
Способствуя более быстрому обнаружению дефектов, внесенных в код при его изменении, автоматизированное тестирование снижает вероятность того
, что вам придется позднее заняться крупномасштабным исправлением кода.
쐽
Автоматизированное тестирование особенно полезно в новых изменчивых технологических средах, поскольку оно позволяет быстрее узнавать об изменениях среды.
Многие инструменты, используемые для автоматизации тестирования, позволяют создавать тестовые леса, генери- ровать входные и регистрировать выходные данные и сравнивать действитель- ные выходные данные с ожидаемыми. Для выполнения этих функций можно ис- пользовать инструменты, обсуждавшиеся в предыдущем разделе.
Перекрестная ссылка О связи между зрелостью технологий и методами разработки см. раз- дел 4.3.
520
ЧАСТЬ V Усовершенствование кода
22.7. Протоколы тестирования
Обеспечить повторяемость процесса тестирования недостаточно — вы должны оценивать и проект, чтобы можно было точно сказать, улучша- ется он в результате изменений или ухудшается. Вот некоторые катего- рии данных, которые можно собирать с целью оценки проекта:
쐽
административное описание дефекта (дата обнаружения, сотрудник, сообщив- ший о дефекте, номер сборки программы, дата исправления);
쐽
полное описание проблемы;
쐽
действия, предпринятые для воспроизведения проблемы;
쐽
предложенные способы решения проблемы;
쐽
родственные дефекты;
쐽
тяжесть проблемы (например, критическая проблема, «неприятная» или кос- метическая);
쐽
источник дефекта: выработка требований, проектирование, кодирование или тестирование;
쐽
вид дефекта кодирования: ошибка занижения или завышения на 1, ошибка при- сваивания, недопустимый индекс массива, неправильный вызов метода и т. д.;
쐽
классы и методы, измененные при исправлении дефекта;
쐽
число строк, затронутых дефектом;
쐽
время, ушедшее на нахождение дефекта;
쐽
время, ушедшее на исправление дефекта.
Собирая эти данные, вы сможете подсчитывать некоторые показатели, позволя- ющие сделать вывод об изменении качества проекта:
쐽
число дефектов в каждом классе; все числа целесообразно отсортировать в порядке от худшего класса к лучшему и, возможно, нормализовать по размеру класса;
쐽
число дефектов в каждом методе, все числа целесообразно отсортировать в порядке от худшего метода к лучшему и, возможно, нормализовать по разме- ру метода;
쐽
среднее время тестирования в расчете на один обнаруженный дефект;
쐽
среднее число обнаруженных дефектов в расчете на один тест;
쐽
среднее время программирования в расчете на один исправленный дефект;
쐽
процент кода, покрытого тестами;
쐽
число дефектов, относящихся к каждой категории тяжести.
Личные протоколы тестирования
Кроме протоколов тестирования уровня проекта, вы можете хранить и личные протоколы тестирования. Можете включать в них контрольные списки ошибок,
которые вы допускаете чаще всего, и указывать время, затрачиваемое вами на написание кода, его тестирование и исправление ошибок.