Средства отладки
Помимо методик, хорошо бы иметь представление о средствах, которые помогают нам выявлять ошибки. Это: 1) Аварийная печать - вывод сообщений о ненормальном завершении отдельных блоков и всей программы в целом. 2) Печать в узлах программы - вывод промежуточных значений параметров в местах, выбранных программистом. Обычно, это критичные участки алгоритма (например, значение, от которого зависит дальнейший ход выполнения) или составные части сложных формул (отдельно просчитать и вывести числитель и знаменатель большой дроби). 3) Непосредственное слежение: Ошибка, скорее всего окажется вашей и будет находиться в тексте программы. Гораздо реже она оказывается: Но если вы совершенно уверены, что в программе ошибок нет, просмотрите стандартные модули, к которым она обращается, выясните, не менялась ли версия среды разработки, в конце концов, просто перегрузите компьютер - некоторые проблемы (особенно в DOS-средах, запускаемых из-под Windows) возникают из-за некорректной работы с памятью.
21.01 Виды тестирования 1) Тестирование программы как "черного ящика". Мы знаем только о том, что делает программа, но даже не задумываемся о ее внутренней структуре. Задаем набор входных данных, получаем результаты, сверяем с эталонными. При этом обнаружить все ошибки мы можем только если составили тесты для всех возможных наборов данных. Естественно, это противоречит экономическим принципам, да и просто достаточно глупо. "Черным ящиком" удобно тестировать небольшие подпрограммы. Здесь перед составлением теста мы изучаем логику программы, ее внутреннюю структуру. Тестирование будет считаться удачным, если проверяет программу по всем направлениям. Однако, как мы уже говорили, это требует огромного количества тестов. На практике мы, как всегда, совместно используем оба принципа. Мы снова возвращаемся к вопросу о структурном программировании. Если вы помните, программы строятся из модулей не в последнюю очередь для того, чтобы их легко было отлаживать и тестировать. Действительно, структурированную программу мы будем тестировать частями. При этом нам нужно: Такое комбинирование может строиться двумя способами: Чтобы протестировать отдельный модуль, нужен модуль-драйвер (всегда один) и модул и-заглушки (этих может быть несколько). К сожалению, мы опять сталкиваемся с тем, что драйверы и заглушки сами могут оказаться источником ошибок. Поэтому создаваться они должны с большой осторожностью.
26.01 Разработка и выполнение тестов Требования к разработке тестов Тестирование ПС - это процесс выполнения его программ на некотором наборе данных,для которого заранее известен результат применения или известны правила поведения этих программ.Указанный набор данных называется тестовым или просто тестом. Таким образом,отладку можно представить в виде многократного повторения трех процессов: тестирования,в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами: Отладка =Тестирование+ Поиск ошибок+ Редактирование. Тестирование - это выполнение программы для набора проверочных входных значений и сравнение полученных результатов с ожидаемыми. Цель тестирования - проверка и доказательство правильности работы программы. В противном случае - выявление того, что в ней есть ошибки. Тестирование само не показывает местонахождение ошибки и не указывает на ее причины. 1) Тест - просчитанный вручную пример выполнения программы от исходных данных до ожидаемых результатов расчета. Эти результаты считаются эталонными. 2) При прогоне программы по тестовым начальным данным, полученные результаты нужно сверить с эталонными и проанализировать разницу, если она есть. 3) При разработке тестов нужно учитывать не только правильные, но и неверные исходные данные. 4) Мы должны проверить программу на нежелательные побочные эффекты при задании некоторых исходных данных (деление на ноль, попытка считывания из несуществующего файла и т.д.). 5) Тестирование нужно планировать: заранее выбрать, что мы контролируем и как это сделать лучше. Обычно тесты планируются на этапе алгоритмизации или выбора численного метода решения. Причем, составляя тесты, мы предполагаем, что ошибки в программе есть. 6) Чем больше ошибок в коде мы уже нашли, тем больше вероятность, что мы обнаружим еще не найденные.
|