Linux программирование в примерах
Шрифт:
Комплексные тесты (Integration tests)
Это тесты, которые применяются, когда все функциональные компоненты были написаны, протестированы и отлажены по отдельности. Идея в том, что все затем помешается на свое место в каркасе и тестируется все в целом, чтобы убедиться, что взаимодействия между компонентами работают.
Возвратные тесты (Regression tests)
Неизбежно вы (или ваши пользователи!) обнаружат проблемы. Это могут быть действительные ошибки, или ограничения дизайна, или неизбежные отказы в «пограничных случаях». Когда вы смогли воспроизвести и исправить проблему, сохраните первоначальные условия отказа в качестве возвратного теста.
Возвратный тест позволяет вам убедиться, что при проведении
Тестирование следует по возможности автоматизировать. Это особенно легко сделать для программ, не содержащих графического пользовательского интерфейса (GUI), написанных в стиле инструментов Linux/Unix: читающих стандартный ввод или указанные файлы и записывающих в стандартный вывод и стандартную ошибку. По меньшей мере, тестирование можно осуществить с помощью простых сценариев оболочки. Более сложное тестирование осуществляется обычно с помощью отдельного подкаталога
Тестирование программного обеспечения само по себе является отдельной областью, и мы не предполагаем отдавать ей здесь должное; скорее, наше намерение дать вам знание, что тестирование является неотъемлемой частью разработки и часто движущей силой для использования ваших навыков в отладке! Вот очень короткий резюмирующий список.
• Проектируйте тест вместе с функциональностью
• Тестируйте пограничные условия: убедитесь, что функция работает внутри и на действительных границах и что она корректно выдает ошибку за их пределами. (Например, функция
• Используйте в своем коде операторы проверки (см. раздел 12.1 «Операторы проверки
• Создайте и используйте повторно тестовое окружение.
• Сохраняйте условия сбоев для возвратного тестирования
• Как можно больше автоматизируйте тестирование.
• Печатайте число потерпевших неудачу тестов, чтобы легко можно было определить успех или неудачу, а также степень неудачи.
• Используйте инструменты обзора кода, такие, как
• Тестируйте с самого начала и тестируйте часто.
• Изучите литературу по тестированию программного обеспечения, чтобы совершенствовать свою способность разрабатывать и тестировать программное обеспечение.
15.7. Правила отладки
Отладка не является «черной магией». Ее принципы и методики могут быть изучены и последовательно применены каждым. С этой целью мы рекомендуем книгу Debugging Дэвида Эганса (David J. Agans; ISBN: 0-8144-7168-4). У книги есть веб-сайт [187] , на котором обобщены правила и представлен плакат для загрузки, чтобы вы могли его распечатать и повесить на стену в своем офисе.
187
Чтобы завершить наше обсуждение, мы представляем следующий материал. Он был адаптирован Дэвидом Эгансом по разрешению из Debugging, Copyright © 2002 David J. Agans, опубликованной AMACOM [188] , отделением American Management Association, New York. Мы благодарим его.
1. Поймите систему. Когда ничто не помогает, прочтите руководство. Вам необходимо узнать, что должна делать проблемная система и все ее части, если хотите выяснить, почему
188
Знание того, где находятся функциональные блоки и размещаются данные, и как они взаимодействуют, дает вам схему для изоляции ошибки. Конечно, вам нужно знать также соответствующую область (язык, операционную систему, приложение) и свои инструменты (компилятор, отладчик исходного кода).
2. Вызовите сбой. Для того, чтобы увидеть ошибку, вы должны быть способны постоянно воспроизводить сбой. Задокументируйте свои процедуры и начните с известного состояния, чтобы вы всегда могли снова вызвать сбой. Ищите ошибку в системе, которая дает сбой, не старайтесь имитировать проблему на другой системе. Не доверяйте статистике непостоянных проблем; они скорее скроют ошибку, чем проявят ее. Вместо этого постарайтесь сделать ее устойчивой, изменяя вводимые данные, начальные условия и координацию действий.
Если ошибка все еще непостоянна, вам придется сделать так, чтобы она выглядела постоянной. При каждом запуске фиксируйте в журнале каждый бит информации, какой только сможете; затем, когда есть успешные запуски и сбои, сравните их друг с другом. Если вы собрали достаточно данных, вы сможете нацелиться на проблему, как если бы смогли вызывать ошибку все время. Способность вызывать каждый раз ошибку означает также, что вы сможете сказать, когда вы ее исправили.
3. Прекратите думать и смотрите. Имеется больше способов появления ошибок, чем вы можете себе представить. Поэтому не представляйте, что могло бы случиться, смотрите на это — оснастите систему инструментарием, чтобы вы действительно смогли увидеть механизм ошибки. Используйте любой инструментарий, который можете — отладчики,
Если вы все же догадались, используйте догадку, чтобы сфокусировать поиск — не старайтесь исправить, пока вы ее не увидите. Если вам приходится добавлять код инструментария, сделайте это, но убедитесь, что начинаете с той же самой базы кода, как на проблемной системе, и убедитесь, что ошибка все еще возникает при работе вашего добавленного кода. Часто добавление отладчика вызывает исчезновение ошибки (вот почему его называют отладчиком).
4. Разделяй и властвуй. Каждый это знает. Вы делаете последовательное приближение — начинаете с одного конца, перескакиваете полпути, смотрите, с какой стороны ошибка, затем перескакиваете оставшиеся полпути в направлении ошибки. Бинарный поиск, вы оказываетесь так за несколько прыжков. Трудной частью является определение того, прошли вы ошибку или нет. Одной из полезных уловок является помещение в систему известных, простых данных, так чтобы можно было легче узнать мусор. Начните также с плохого конца и работайте по направлению к хорошему: если вы начнете с хорошего конца, имеется слишком много хороших путей для исследования. Известные ошибки исправляйте сразу, поскольку иногда две ошибки взаимодействуют (хотя вы могли бы поклясться, что они не должны этого делать), и последовательное приближение не работает с двумя целевыми значениями.
5. Каждый раз изменяйте лишь что-то одно. Если вы стараетесь усовершенствовать модуль обработки потоков и одновременно переходите на следующую версию операционной системы, не имеет значения, видите ли вы улучшение, ухудшение или отсутствие изменений — у вас не будет мыслей по поводу того, каким был результат ваших отдельных изменений. Взаимодействие нескольких изменений может быть непредсказуемым и сбивающим с толку. Не делайте этого. Изменяйте за один раз только что-то одно, чтобы вы могли поручиться, что любое отличие, которые вы видите, возникло из-за этого изменения.