Автономная отладка модуля. - Лекция, раздел Программирование, НАДЕЖНОЕ ПРОГРАММНОЕ СРЕДСТВО КАК ПРОДУКТ ТЕХНОЛОГИИ ПРОГРАММИРОВАНИЯ. ИСТОРИЧЕСКИЙ И СОЦИАЛЬНЫЙ КОНТЕКСТ ПРОГРАММИРОВАНИЯ. ИСТОЧНИКИ ОШИБОК В ПРОГРАММНОМ СРЕДСТВЕ При Автономной Отладке Каждый Модуль На Самом Деле Тестируется В Некотором Пр...
При автономной отладке каждый модуль на самом деле тестируется в некотором программном окружении, кроме случая, когда отлаживаемая программа состоит только из одного модуля. Это окружение состоит [10.8] из других модулей, часть которых является модулями отлаживаемой программы, которые уже отлажены, а часть - модулями, управляющими отладкой (отладочными модулями, см. ниже). Таким образом, при автономной отладке тестируется всегда некоторая программа, построенная специально для тестирования отлаживаемого модуля. Эта программа лишь частично совпадает с отлаживаемой программой, кроме случая, когда отлаживается последний модуль отлаживаемой программы. По мере продвижения отладки программы все большую часть окружения очередного отлаживаемого модуля будут составлять уже отлаженные модули этой программы, а при отладке последнего модуля этой программы окружение отлаживаемого модуля будет целиком состоять из всех остальных (уже отлаженных) модулей отлаживаемой программы (без каких-либо) отладочных модулей, т.е. в этом случае тестироваться будет сама отлаживаемая программа. Такой процесс наращивания отлаживаемой программы отлаженными и отлаживаемыми модулями называется интеграцией программы [10.1].
Отладочные модули, входящие в окружение отлаживаемого модуля, зависят от порядка, в каком отлаживаются модули этой программы, от того, какой модуль отлаживается и, возможно, от того, какой тест будет пропускаться.
При восходящем тестировании (см. лекцию 7) это окружение всегда будет содержать только один отладочный модуль (кроме случая, когда отлаживается последний модуль отлаживаемой программы), который будет головным в тестируемой программе и который называют ведущим (или драйвером [10.1]). Ведущий отладочный модуль подготавливает информационную среду для тестирования отлаживаемого модуля (т. е. формирует ее состояние, требуемое для тестирования этого модуля, в частности, может осуществлять ввод некоторых тестовых данных), осуществляет обращение к отлаживаемому модулю и после окончания его работы выдает необходимые сообщения. При отладке одного модуля для разных тестов могут составляться разные ведущие отладочные модули.
При нисходящем тестировании (см. лекцию 7) окружение отлаживаемого модуля в качестве отладочных модулей содержит имитаторы всех модулей, к которым может обращаться отлаживаемый модуль, а также имитаторы тех модулей, к которым могут обращаться отлаженные модули отлаживаемой программы (включенные в это окружение), но которые еще не отлажены. Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных тестов.
На самом деле в окружении отлаживаемого модуля во многих случаях могут содержаться отладочные модули обоих типов по ниже следующим соображениям. Как восходящее, так и нисходящее тестирование имеет свои достоинства и свои недостатки.
К достоинствам восходящего тестирования относятся
· простота подготовки тестов и
· возможность полной реализации плана тестирования модуля.
Это связано с тем, что тестовое состояние информационной среды готовится непосредственно перед обращением к отлаживаемому модулю (ведущим отладочным модулем). Недостатками восходящего тестирования являются следующие его особенности:
· тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя (кроме случая, когда отлаживается последний, головной, модуль отлаживаемой программ);
· большой объем отладочного программирования (при отладке одного модуля часто приходится составлять для разных тестов много ведущих отладочных модулей);
· необходимость специального тестирования сопряжения модулей.
К достоинствам нисходящего тестирования относятся следующие его особенности:
· большинство тестов готовится в форме, рассчитанной на пользователя;
· во многих случаях относительно небольшой объем отладочного программирования (имитаторы модулей, как правило, весьма просты и каждый пригоден для большого числа, нередко - для всех, тестов);
· отпадает необходимость тестирования сопряжения модулей.
Недостатком нисходящего тестирования является то, что тестовое состояние информационной среды перед обращением к отлаживаемому модулю готовится косвенно - оно является результатом применения уже отлаженных модулей к тестовым данным или данным, выдаваемым имитаторами. Это, во-первых, затрудняет подготовку тестов, требует высокой квалификации исполнителя-тестовика, а во-вторых, делает затруднительным или даже невозможным реализацию полного плана тестирования отлаживаемого модуля. Указанный недостаток иногда вынуждает разработчиков применять восходящее тестирование даже в случае нисходящей разработки. Однако чаще применяют некоторые модификации нисходящего тестирования, либо некоторую комбинацию нисходящего и восходящего тестирования.
Исходя из того, что нисходящее тестирование, в принципе, является предпочтительным, остановимся на приемах, позволяющих в какой-то мере преодолеть указанные трудности. Прежде всего необходимо организовать отладку программы таким образом, чтобы как можно раньше были отлажены модули, осуществляющие ввод данных, - тогда тестовые данные можно готовить в форме, рассчитанной на пользователя, что существенно упростит подготовку последующих тестов. Далеко не всегда этот ввод осуществляется в головном модуле, поэтому приходится в первую очередь отлаживать цепочки модулей, ведущие к модулям, осуществляющим указанный ввод (ср. с методом целенаправленной конструктивной реализации в лекции 7). Пока модули, осуществляющие ввод данных, не отлажены, тестовые данные поставляются некоторыми имитаторами: они либо включаются в имитатор как его часть, либо вводятся этим имитатором.
При нисходящем тестировании некоторые состояния информационной среды, при которых требуется тестировать отлаживаемый модуль, могут не возникать при выполнении отлаживаемой программы ни при каких входных данных. В этих случаях можно было бы вообще не тестировать отлаживаемый модуль, так как обнаруживаемые при этом ошибки не будут проявляться при выполнении отлаживаемой программы ни при каких входных данных. Однако так поступать не рекомендуется, так как при изменениях отлаживаемой программы (например, при сопровождении ПС) не использованные для тестирования отлаживаемого модуля состояния информационной среды могут уже возникать, что требует дополнительного тестирования этого модуля (а этого при рациональной организации отладки можно было бы не делать, если сам данный модуль не изменялся). Для осуществления тестирования отлаживаемого модуля в указанных ситуациях иногда используют подходящие имитаторы, чтобы создать требуемое состояние информационной среды. Чаще же пользуются модифицированным вариантом нисходящего тестирования, при котором отлаживаемые модули перед их интеграцией предварительно тестируются отдельно (в этом случае в окружении отлаживаемого модуля появляется ведущий отладочный модуль, наряду с имитаторами модулей, к которым может обращаться отлаживаемый модуль). Однако, представляется более целесообразной другая модификация нисходящего тестирования: после завершения нисходящего тестирования отлаживаемого модуля для достижимых тестовых состояний информационной среды следует его отдельно протестировать для остальных требуемых состояний информационной среды.
Часто применяют также комбинацию восходящего и нисходящего тестирования, которую называют методом сандвича [10.1]. Сущность этого метода заключается в одновременном осуществлении как восходящего, так и нисходящего тестирования, пока эти два процесса тестирования не встретятся на каком-либо модуле где-то в середине структуры отлаживаемой программы. Этот метод позволяет при разумном подходе воспользоваться достоинствами как восходящего, так и нисходящего тестирования и в значительной степени нейтрализовать их недостатки. Этот эффект является проявлением более общего принципа: наибольшего технологического эффекта можно добиться, сочетая нисходящие и восходящие методы разработки программ ПС. Именно для поддержки этого метода и предназначен архитектурный подход к разработке программ (см. лекцию 7): слой квалифицированно разработанных и тщательно оттестированных модулей существенно облегчает реализацию семейства программ в соответствующей предметной области и их последующую модернизацию.
Весьма важным при автономной отладке является тестирование
сопряжения модулей. Дело в том, что спецификация каждого модуля программы, кроме головного, используется в этой программы в двух ситуациях: во-первых, при разработке текста (иногда говорят: тела) этого модуля и, во-вторых, при написании обращения к этому модулю в других модулях программы. И в том, и в другом случае в результате ошибки может быть нарушено требуемое соответствие заданной спецификации модуля. Такие ошибки требуется обнаруживать и устранять. Для этого и предназначено тестирование сопряжения модулей. При нисходящем тестировании тестирование сопряжения осуществляется попутно каждым пропускаемым тестом, что считают самым сильным достоинством нисходящего тестирования. При восходящем тестировании обращение к отлаживаемому модулю производится не из модулей отлаживаемой программы, а из ведущего отладочного модуля. В связи с этим существует опасность, что последний модуль может приспособиться к некоторым "заблуждениям" отлаживаемого модуля. Поэтому приступая (в процессе интеграции программы) к отладке нового модуля приходится тестировать каждое обращение к ранее отлаженному модулю с целью обнаружения несогласованности этого обращения с телом соответствующего модуля (и не исключено, что виноват в этом ранее отлаженный модуль). Таким образом, приходится частично повторять в новых условиях тестирование ранее отлаженного модуля, при этом возникают те же трудности, что и при нисходящем тестировании.
Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага [10.1].
Шаг 1. На основании спецификации отлаживаемого модуля подготовьте тест для каждой возможности и каждой ситуации, для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для каждой области недопустимых значений всех входных данных и каждого недопустимого условия.
Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавьте недостающие тесты.
Шаг 3. Убедитесь по тексту модуля, что для каждого цикла существует тест, для которого тело цикла не выполняется, тест, для которого тело цикла выполняется один раз, и тест, для которого тело цикла выполняется максимальное число раз. Добавьте недостающие тесты.
Шаг 4. Проверьте по тексту модуля его чувствительность к отдельным особым значениям входных данных - все такие значения должны входить в тесты. Добавьте недостающие тесты.
Все темы данного раздела:
Программа как формализованное описание процесса обработки данных. Программное средство.
Целью программирования является описание процессов обработки данных (в дальнейшем - просто процессов). Согласно ИФИПа [1.1]: данные - это представление фактов и идей в формализованном
Неконструктивность понятия правильной программы.
Таким образом, можно считать, что продуктом технологии программирования является ПС, содержащее программы, выполняющие требуемые функции. Здесь под "программой" часто понимают правильную
Надежность программного средства.
Альтернативой правильного ПС является надежное ПС. Надежность ПС - это его способность безотказно выполнять определенные функции при заданных условиях в течение заданного периода врем
Технология программирования как технология разработки надежных программных средств.
В соответствии с обычным значением слова "технология" [1.6] под технологией программирования будем понимать совокупность производственных процессов, приводящую к созданию требуемог
Технология программирования и информатизация общества.
Технологии программирования играло разную роль на разных этапах развития программирования. По мере повышения мощности компьютеров и развития средств и методологии программирования росла и сложность
Интеллектуальные возможности человека.
Дейкстра [2.1] выделяет три интеллектуальные возможности человека, используемые при разработке ПС:
· способность к перебору,
· способность к абстракции,
· способность к м
Неправильный перевод как причина ошибок в программных средствах.
При разработке и использовании ПС мы многократно имеем дело [2.3] с преобразованием (переводом) информации из одной формы в другую (см.рис.2.1). Заказчик формулирует свои потребности в ПС в виде не
Модель перевода.
Чтобы понять природу ошибок при переводе рассмотрим модель [2.3], изображенную на рис.2.2. На ней человек осуществляет перевод информации из представления A в представление B. При этом он совершает
Специфика разработки программных средств.
Разработке программных средств присущ ряд специфических особенностей [3.1].
· Прежде всего, следует отметить некоторое противостояние: неформальный характер требований к ПС (постано
Жизненный цикл программного средства.
Под жизненным циклом ПС понимают весь период его разработки и эксплуатации (использования), начиная от момента возникновения замысла ПС и кончая прекращением всех видов его использования [3.
Понятие качества программного средства.
Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода
Обеспечение надежности - основной мотив разработки программных средств.
Рассмотрим теперь общие принципы обеспечения надежности ПС, что, как мы уже подчеркивали, является основным мотивом разработки ПС, задающим специфическую окраску всем технологическим процессам разр
Методы борьбы со сложностью.
Мы уже обсуждали в лекции 2 сущность вопроса борьбы со сложностью при разработке ПС. Известны два общих метода борьбы со сложностью систем:
· обеспечения независимости компонент системы;
Обеспечение точности перевода.
Обеспечение точности перевода направлено на достижение однозначности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует придерживаться при переводе определен
Контроль принимаемых решений.
Обязательным шагом в каждом процессе (этапе) разработки ПС должна быть проверка правильности принятых решений. Это позволит обнаруживать и исправлять ошибки на самой ранней стадии после ее возникно
Назначение внешнего описания программного средства и его роль в обеспечении качества программного средства.
Разработчикам больших программных средств приходится решать весьма специфические и трудные проблемы, особенно, если это ПС должно представлять собой программную систему нового типа, в плохо компьют
Определение требований к программному средству.
Определение требования к ПС являются исходным документом разработки ПС - заданием, выражающем в абстрактной форме потребности пользователя. Они в общих чертах определяют замысел ПС, характеризуют у
Спецификация качества программного средства.
Разработка спецификации качества сводится, по-существу, к построению своеобразной модели качества разрабатываемой ПС [4.2, 4.3]. В этой модели должен быть перечень всех тех достаточно элементарных
Функциональная спецификация программного средства.
С учетом назначения функциональной спецификации ПС и тяжелых последствий неточностей и ошибок в этом документе, функциональная спецификация должна быть математически точной. Это не означает, что он
Методы контроля внешнего описания программного средства.
Разработка внешнего описания обязательно должна завершаться проведением тщательного и разнообразного контроля правильности внешнего описания. Целью этого процесса является найти как можно больше ош
Основные подходы к спецификации семантики функций.
Для спецификации семантики функций используются следующие подходы: табличный, алгебраический и логический [5.1], а также графический [5.2].
Табличный подход для определения функций хорошо
Метод таблиц решений.
0
Операционная семантика.
В операционной семантике алгебраического подхода к описанию семантики функций рассматривается следующий частный случай системы равенств (5.1):
f1(x1, x2, ... , xk)= E1,
f2(x1, x2,
Денотационная семантика.
В денотационной семантике алгебраического подхода рассматривается также система равенств вида (5.3), которая интерпретируется как система функциональных уравнений, а определяемые функции являются н
Аксиоматическая семантика.
В аксиоматической семантике алгебраического подхода система (5.1) интерпретируется как набор аксиом в рамках некоторой формальной логической системы, в которой есть правила вывода и/или интерпретац
Языки спецификаций.
Как уже отмечалось, функциональная спецификация представляет собой математически точное, но, как правило, не формальное описание поведения ПС. Однако, формализованное представление функциональной с
Понятие архитектуры программного средства.
Архитектура ПС - это его строение как оно видно (или должно быть видно) из-вне его, т.е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем. В каче
Архитектурные функции.
Для обеспечения взаимодействия между подсистемами в ряде случаев не требуется создавать какие-либо дополнительные программные компоненты (помимо реализации внешних функций) - для этого может быть д
Контроль архитектуры программных средств.
Для контроля архитектуры ПС используется смежный контроль иручная имитация.
Смежный контроль архитектуры ПС сверху - это ее контроль разработчиками внешнего описания: разработчиками специф
Цель модульного программирования.
Приступая к разработке каждой программы ПС, следует иметь в виду, что она, как правило, является большой системой, поэтому мы должны принять меры для ее упрощения. Для этого такую программу разраба
Основные характеристики программного модуля.
Не всякий программный модуль способствует упрощению программы [7.2]. Выделить хороший с этой точки зрения модуль является серьезной творческой задачей. Для оценки приемлемости выделенного модуля ис
Методы разработки структуры программы.
Как уже отмечалось выше, в качестве модульной структуры программы принято использовать древовидную структуру, включая деревья со сросшимися ветвями. В узлах такого дерева размещаются программные мо
Контроль структуры программы.
Для контроля структуры программы можно использовать три метода [7.5]:
· статический контроль,
· смежный контроль,
· сквозной контроль.
Статический контроль состо
Порядок разработки программного модуля.
При разработке программного модуля целесообразно придерживаться следующего порядка [8.1]:
· изучение и проверка спецификации модуля, выбор языка
программирования;
· выбор
Структурное программирование.
При программировании модуля следует иметь ввиду, что программа должна быть понятной не только компьютеру, но и человеку: и разработчик модуля, и лица, проверяющие модуль, и тестовики, готовящие тес
Пошаговая детализация и понятие о псевдокоде.
Структурное программирование дает рекомендации о том, каким должен быть текст модуля. Возникает вопрос, как должен действовать программист, чтобы построить такой текст. Иногда программирование моду
Контроль программного модуля.
Применяются следующие методы контроля программного модуля:
· статическая проверка текста модуля;
· сквозное прослеживание;
· доказательство свойств программного модуля.
Обоснования программ. Формализация свойств программ.
Для повышения надежности программных средств весьма полезно снабжать программы дополнительной информацией, с использованием которой можно существенно повысить уровень контроля ПС. Такую информацию
Свойства основных конструкций структурного программирования.
Рассмотрим теперь свойства основных конструкций структурного программирования: следования, разветвления и повторения.
Свойства следования выражает следующая
Теорема 9.3. Пусть
Завершимость выполнения программы.
Одно из свойств программы, которое нас может интересовать, чтобы избежать возможных ошибок в ПС, является ее завершимость, т.е. отсутствие в ней зацикливания при тех или иных исходных данных
Принципы и виды отладки.
Успех отладки в значительной степени предопределяет рациональная организация тестирования. При отладке отыскиваются и устраняются, в основном, те ошибки, наличие которых в ПС устанавливается при те
Заповеди отладки.
В данном разделе даются общие рекомендации по организации
отладки. Но сначала следует отметить некоторый феномен [10.1], который подтверждает важность предупреждения ошибок на предыдущих э
Комплексная отладка программного средства.
Как уже было сказано выше, при комплексной отладке тестируется ПС в целом, причем тесты готовятся по каждому из документов ПС [10.8]. Тестирование этих документов производится, как правило, в поряд
Функциональность и надежность как обязательные критерии качества программного средства.
На предыдущих лекция мы рассмотрели все этапы разработки ПС, кроме его аттестации. При этом мы не касались вопросов обеспечения качества ПС в соответствии с его спецификацией качества (см. лекцию 4
Обеспечение завершенности программного средства.
Завершенность ПС является общим примитивом качества ПС для выражения и функциональности и надежности ПС, причем для функциональности она является единственным примитивом (см. лекцию 4).
Фу
Обеспечение точности программного средства.
Обеспечение этого примитива связано с действиями над значениями вещественных типов (точнее говоря, со значениями, представляемыми с некоторой погрешностью). Обеспечить требуемую точность при вычисл
Обеспечение автономности программного средства.
Этот примитив качества обеспечивается на этапе спецификации качества принятием решения об использовании в разрабатываемом ПС какого-либо подходящего базового программного обеспечения или не использ
Обеспечение устойчивости программного средства.
Этот примитив качества обеспечивается с помощью так называемого защитного программирования. Вообще говоря, защитное программирование применяется для повышения надежности ПС при программировании мод
Обеспечение защищенности программных средств.
Различают следующие виды защиты ПС от искажения информации:
· защита от сбоев аппаратуры;
· защита от влияния "чужой" программы;
· защита от отказов "своей
Общая характеристика процесса обеспечения качества программного средства.
Как уже отмечалось в лекции 4, спецификация качества определяет основные ориентиры (цели), которые на всех этапах разработки ПС так или иначе влияют при принятии различных решений на выбор подходящ
Обеспечение легкости применения программного средства.
П-документированость ПС определяет состав пользовательской документации
В предыдущей лекции было уже рассмотрено обеспечение двух из пяти примитивов качества (устойчивость и защищен
Обеспечение эффективности программного средства.
Эффективность ПС обеспечивается принятием подходящих решений на разных этапах его разработки, начиная с разработки его архитектуры. Особенно сильно на эффективность ПС (особенно по памяти) влияет в
Обеспечение сопровождаемости.
С-документированность, информативность и понятность определяют состав и качество документации по сопровождению (см. следующую лекцию). Кроме того, относительно текстов программ (модулей) можно сдел
Документация, создаваемая в процессе разработки программных средств.
При разработке ПС создается большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство
Пользовательская документация программных средств.
Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС. Она необходима, если ПС предполагает какое-либо взаимоде
Документация по сопровождению программных средств.
Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконстру
Назначение аттестации программного средства.
Аттестация ПС - это авторитетное подтверждение качества ПС [14.1]. Обычно для аттестации ПС создается представительная (аттестационная) комиссия из экспертов, представителей заказчика и пред
Виды испытаний программного средства.
Известны следующие виды испытаний ПС [14.2,14.3], проводимых с целью аттестации ПС:
· испытания компонент ПС;
· системные испытания;
· приемо-сдаточные испытания;
Методы оценки качества программного средства.
Оценка качества ПС по каждому из критериев сводится к оценке каждого из примитивов, связанных с этим критерием качества ПС, в соответствии с их конкретизацией, произведенной в спецификации качества
Объекты и отношения в программировании. Сущность объектного подхода к разработке программных средств.
Окружающий нас мир состоит из объектов и отношений между ними [15.1]. Согласно В. Далю [15.2] объект (предмет) это все, что представляется чувствам (объект вещественный) или уму (объект ум
Особенности объектного подхода к разработке внешнего описания программного средства.
При объектном подходе этап внешнего описания ПС оказывается существенно более емким и содержательным по сравнению с реляционным подходом [15.3, 15.4, 15.5, 15.6].
Определение требований за
Особенности объектного подхода на этапе конструирования программного средства.
На этапе конструирования при объектном подходе продолжается процесс объектного моделирования: уточняются модели, построенные на этапе внешнего описания, в терминах описания программных систем и про
Особенности объектного подхода на этапе кодирования программного средства.
На этапе кодирования при объектном подходе используются языки программирования уже другого типа – объектно-ориентированные [15.7, 15.8]. Считается, что язык программирования поддерживает объ
Инструменты разработки программных средств.
В процессе разработки программных средств в той или иной мере используется компьютерная поддержка процессов разработки ПС. Это достигается путем представления хотя бы некоторых программных документ
Инструментальные среды разработки и сопровождения программных средств.
В настоящее время с каждой системой программирования связываются не отдельные инструменты (например, компилятор), а некоторая логически связанная совокупность программных и аппаратных инструментов
Инструментальные среды программирования.
Инструментальные среды программирования содержат прежде всего текстовый редактор, позволяющий конструировать программы на заданном языке программирования, инструменты, позволяющие компилировать или
Понятие компьютерной технологии разработки программных средств и ее рабочие места.
Имеются некоторые трудности в выработке строгого определения CASE-технологии (компьютерной технологии разработки ПС). CASE - это абревиатура от английского Computer-Aided Software Engineering (Комп
Инструментальные системы технологии программирования.
Для компьютерной поддержки разработки и сопровождения больших ПС с продолжительным жизненным циклом используются инструментальные системы технологии программирования. Инструментальная система те
Новости и инфо для студентов