Шпаргалка по "Информатике"

 
 

3. Тестирование, отладка программ.

1. ОСНОВНЫЕ ПОНЯТИЯ 

    Отладка ПС - деятельность по обнаружению и исправлению ошибок в ПС с использованием процессов выполнения его программ.

    Тестирование ПС - процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Этот набор данных называется тестовым или просто тестом.

    Отладка = Тестирование + Поиск ошибок + Редактирование.

2. ВИДЫ ОТЛАДКИ ПРОГРАММНОГО  СРЕДСТВА 

Задачи  отладки программных  средств.

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

2.   Определить момент окончания  отладки ПС (или отдельной его компоненты).

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

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

    * на каждую используемую функцию  или возможность - хотя бы один  тест,

    * на каждую область и на каждую  границу изменения какой-либо  входной величины - хотя бы один тест,

    * на каждую особую (исключительную) ситуацию, указанную в спецификациях, - хотя бы один тест.

    Во  втором случае эта стратегия базируется на принципе: каждая команда каждой программы ПС должна проработать  хотя бы на одном тесте.

    В нашей стране различаются два  основных вида отладки (включая тестирование):

    Автономная  отладка ПС - последовательное раздельное тестирование различных частей программ с поиском и исправлением в  них фиксируемых при тестировании ошибок. Комплексная отладка - тестирование ПС в целом с поиском и исправлением фиксируемых при тестировании ошибок во всех документах.

3. ПРИНЦИПЫ ОТЛАДКИ  ПРОГРАММНОГО СРЕДСТВА.

    Отметим феномен - по мере роста числа обнаруженных и исправленных ошибок в ПС растет также относительная вероятность существования в нем необнаруженных ошибок.

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

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

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

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

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

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

    4. АВТОНОМНАЯ ОТЛАДКА  ПРОГРАММНОГО СРЕДСТВА.

    При автономной отладке тестируется всегда некоторая программа (тестируемая программа), построенная специально для тестирования отлаживаемого модуля. В процессе автономной отладки ПС производится наращивание тестируемой программы отлаженными модулями (интеграция программы).

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

    При нисходящем тестировании окружение в качестве отладочных содержит отладочные имитаторы (заглушки) некоторых еще не отлаженных модулей. Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных тестов.

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

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

1. простота подготовки тестов,

2) возможность  полной реализации плана тестирования  модуля.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    5. КОМПЛЕКСНАЯ ОТЛАДКА ПРОГРАММНОГО СРЕДСТВА

    Тестирование  при комплексной  отладке - применение ПС к конкретным данным, которые могут возникнуть у пользователя, но, возможно, в моделируемой (а не в реальной) среде.

    Тестирование  архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и совокупностью программ ПС. К моменту начала тестирования архитектуры ПС должна быть уже закончена автономная отладка каждой подсистемы.

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

    Тестирование  качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Завершенность ПС проверяется уже при тестировании внешних функций.

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

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

4. Структурный подход к проектированию и разработке программ.

    Создателем  структурного подхода к программированию считается Э. Дейкстра (60-е годы).

    Фактически  это первый законченный метод  программирования, предлагающий путь от задачи до ее воплощения в программе.

    Структурное проектирование – это последовательная декомпозиция, целенаправленное разбиение на отдельные составляющие.

    Структурное проектирование включает в себя:

•    нисходящее проектирование ("сверху вниз"),
•    модульное программирование,
•    структурное программирование (кодирование).

    Метод нисходящего проектирования предполагает последовательное разложение общей функции обработки данных на простые функциональные элементы ("сверху вниз").

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

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

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

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