6.3. Заповеди отладки пс

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

Рассмотрим шесть заповедей по организации отладки.

1. Считай тестирование ключевой задачей разработки ПС, поручай его самым квалифицированным и одаренным программистам. Нежелательно тестировать собственную программу.

2. Хорош тот тест, для которого высока вероятность обнаружения ошибки, а не тот, который демонстрирует "правильную" работу программы.

3. Готовь тесты, как для "правильных", так и для "неправильных" данных.

4. Документируй пропуск тестов через компьютер. Детально изучай результаты каждого теста. Избегай тестов, пропуск которых нельзя повторить.

5. Каждый модуль подключай к программе только один раз. Никогда не изменяй программу, чтобы облегчить ее тестирование.

6. Пропускай заново все тесты, связанные с проверкой работы отдельной программы или ее взаимодействия с другими программами, если в нее были внесены изменения.

6.4. Автономная отладка пс

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

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

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

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

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

Недостатки восходящего тестирования:

1. тестовые данные, как правило, готовятся не в той форме, которая рассчитана на пользователя, кроме случая отладки последнего головного модуля программы;

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

3. необходимость специального тестирования сопряжений модулей.

Достоинствам нисходящего тестирования:

1. большинство тестов готовится в форме, рассчитанной на пользователя;

2. во многих случаях относительно невелик объем отладочного программирования - имитаторы модулей, как правило, просты и каждый пригоден для большого числа тестов;

3. нет необходимости в тестировании сопряжений модулей.

Недостаток нисходящего тестирования: состояние информационной среды перед обращением к отлаживаемому модулю  результат применения уже отлаженных модулей к тестовым данным или данным, выданными имитаторами. Это, во-первых, затрудняет подготовку тестов для вновь отлаживаемого модуля и требует высокой квалификации тестовика, а, во-вторых, осложняет реализацию полного плана тестирования модуля. Указанный недостаток вынуждает разработчиков иногда применять восходящее тестирование даже в случае нисходящей разработки. Однако чаще применяют некоторые модификации нисходящего тестирования, либо некоторую комбинацию нисходящего и восходящего тестирования. Исходя из того, что нисходящее тестирование является предпочтительным, рассмотрим некоторые приемы, позволяющие преодолеть указанные недостатки.

Прежде всего, необходимо организовать отладку программы так, чтобы первыми были отлажены модули, реализующие ввод данных,  тогда тестовые данные можно готовить в форме, рассчитанной на пользователя. Не всегда этот ввод осуществляется в головном модуле, поэтому, в первую очередь отлаживаются цепочки модулей, ведущие к модулям, осуществляющим указанный ввод. Пока модули, осуществляющие ввод данных, не отлажены, тестовые данные поставляются имитаторами, которые либо вводят эти данные извне либо уже содержат их в себе как часть.

При нисходящем тестировании отдельных модулей некоторые состояния информационной среды вообще не возникают ни при каких входных данных. Казалось бы, что в этих случаях можно не тестировать отлаживаемый модуль, так как даже наличие ошибок никак не скажется на выполнении программы. Однако это неверный подход. При внесении изменений в программы, например, при сопровождении ПС, ранее не использованные для тестирования модуля состояния информационной среды могут возникнуть, что потребует дополнительного тестирования модуля, хотя сам модуль не изменился, а этого при рациональной организации отладки можно было бы избежать. Для тестирования отлаживаемого модуля в указанных ситуациях иногда используют имитаторы для создания соответствующего состояния информационной среды. Чаще пользуются модифицированным вариантом нисходящего тестирования, при котором отлаживаемые модули перед их интеграцией тестируются отдельно. В этом случае в окружении отлаживаемого модуля появляется ведущий модуль, наряду с имитаторами модулей, к которым может обращаться отлаживаемый модуль. Более целесообразна другая модификация нисходящего тестирования. После завершения тестирования модуля на достигаемых состояниях информационной среды следует провести отдельное тестирование на остальных состояниях информационной среды.

Часто применяется комбинация восходящего и нисходящего тестирования, названная методом сандвича. Его суть заключается в одновременном осуществлении как восходящего, так и нисходящего тестирования, пока эти два процесса не столкнутся на каком-либо срединном модуле программы. Этот метод позволяет воспользоваться достоинствами и восходящего, и нисходящего тестирования, а также нейтрализовать их недостатки.

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

Автономное тестирование модуля целесообразно проводить в пошаговом порядке.

Шаг 1. На основании спецификации отлаживаемого модуля готовятся тесты для всех мыслимых ситуаций, границ областей допустимых и недопустимых значений входных данных, областей их изменения, и всех недопустимых условий.

Шаг 2. Проверяется текст модуля и устанавливается, что каждое направление разветвлений будет пройдено хотя бы на одном тесте. Добавляются недостающие тесты.

Шаг 3. Проверяется текст модуля и устанавливается, что тесты обеспечивают полноту отладки каждого цикла: тело цикла не выполняется ни разу, выполняется один раз и выполняется максимальное число раз. Добавляются недостающие тесты.

Шаг 4. Проверяется текст модуля и устанавливается, что имеются тесты, проверяющие чувствительность модуля к особым значениям входных данных. Добавляются недостающие тесты.