• Тестирование и отладка по. Отладка программ. Методы отладки программного обеспечения

    Отладка программы

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

    • узнавать текущие значения переменных ;
    • выяснять, по какому пути выполнялась программа.

    Существуют две взаимодополняющие технологии отладки.

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

    Место отладки в цикле разработки программы

    Типичный цикл разработки, за время жизни программы многократно повторяющийся, выглядит примерно так:

    1. Программирование - внесение в программу новой функциональности, исправление ошибок в имеющейся.
    2. Тестирование (ручное или автоматизированное; программистом, тестером или пользователем; «дымовое», в режиме чёрного ящика или модульное …) - обнаружение факта ошибки.
    3. Воспроизведение ошибки - выяснение условий, при которых ошибка случается. Это может оказаться непростой задачей при программировании параллельных процессов и при некоторых необычных ошибках, известных как гейзенбаги .
    4. Отладка - обнаружение причины ошибки.

    Инструменты

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

    Инструменты отладки

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

    Также полезными инструментами в руках программиста могут оказаться:

    • Профилировщики . Они позволят определить сколько времени выполняется тот или иной участок кода, а анализ покрытия позволит выявить неисполняемые участки кода.
    • API логгеры позволяют программисту отследить взаимодействие программы и Windows API при помощи записи сообщений Windows в лог.
    • Дизассемблеры позволят программисту посмотреть ассемблерный код исполняемого файла
    • Снифферы помогут программисту проследить сетевой трафик генерируемой программой
    • Снифферы аппаратных интерфейсов позволят увидеть данные которыми обменивается система и устройство.
    • Логи системы.

    Инструменты, снижающие потребность в отладке

    Другое направление - сделать, чтобы отладка нужна была как можно реже. Для этого применяются:

    • Контрактное программирование - чтобы программист подтверждал другим путём, что ему на выходе нужно именно такое поведение программы. В языках, в которых контрактного программирования нет, используется самопроверка программы в ключевых точках.
    • Модульное тестирование - проверка поведения программы по частям.
    • Статический анализ кода - проверка кода на стандартные ошибки «по недосмотру».
    • Высокая культура программирования, в частности, паттерны проектирования , соглашения об именовании и прозрачное поведение отдельных блоков кода - чтобы объявить себе и другим, каким образом должна вести себя та или иная функция.
    • Широкое использование проверенных внешних библиотек.

    Безопасность программного кода и отладка

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

    • Выявление недокументированного поведения системы
    • Устранение небезопасного кода

    Выделяют такие методы:

    • статический анализ кода. На этой фазе программа сканер ищет последовательности в исходном тексте, соответствующие небезопасным вызовам функций и т. д. Фактически идет сканирование исходного текста программы на основе специальной базы правил, которая содержит описание небезопасных образцов кода.
    • фаззинг. Это процесс подачи на вход программы случайных или некорректных данных и анализ реакции программы.
    • Reverse engineering (Обратная инженерия). Этот случай возникает, когда независимые исследователи ищут уязвимости и недокументированные возможности программы.

    Литература

    • Стив Магьюир, «Создание надёжного кода» (Steve Maguire. Writing Solid Code . Microsoft Press, 1993)
    • Стив Мак-Коннел, «Совершенный код» (Steve McConnel. Code Complete . Microsoft Press, 1993)

    См. также

    Ссылки

    • Отладка AMD64 на уровне машинного кода с помощью отладчика dbx (рус.)

    Wikimedia Foundation . 2010 .

    Смотреть что такое "Отладка программы" в других словарях:

      Этап разработки компьютерной программы, в процессе которого происходят обнаружение, локализация и устранение явных ошибок в программе. Обычно отладка выполняется на контрольных примерах с известными результатами. По английски: Program debugging… … Финансовый словарь

      отладка программы - контроль программы проверка программы программный контроль — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом Синонимы контроль программыпроверка… …

      отладка программы - отладка программы; отладка Процесс обнаружения и исправления ошибок в программе, а также установления факта ее правильного функционирования в машине …

      отладка (программы) - — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN debugging … Справочник технического переводчика

      На ЭВМ обнаружение и исправление ошибок в программе для ЭВМ с помощью самой машины. Производится в 2 этапа: 1) автономная проверка отд. участков программы; 2) комплексная проверка путём решения по отлаживаемой программе неск. примеров, результаты … Большой энциклопедический политехнический словарь

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

      отладка машинной программы - — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN code refinement … Справочник технического переводчика

      ОТЛАДКА - (1) программы систематический процесс поиска и устранения (см.) в (см.), производимый по результатам её прогона на ЭВМ или с помощью специальной вспомогательной программы (отладчика), обеспечивающей заданный режим её отладки и выдающей… … Большая политехническая энциклопедия

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

    Книги

    • Android для пользователя. Полезные программы и советы , Колисниченко Денис Николаевич , Рассмотрены самые интересные, полезные и наиболее популярные среди отечественных пользователей Android-приложения. Даны советы, как превратить Android-устройство в пульт дистанционного… Категория: Операционные системы Издатель:

    Определение и принципы тестирования

    Тестирование программного средства (ПС) - это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом . Тестирование программ является одной из составных частей более общего понятия - «отладка программ». Под отладкой по-нимается процесс, позволяющий получить программу, функциони-рующую с требующимися характеристиками в заданной области изменения входных данных.

    Процесс отладки включает:

     действия, направленные на выявление ошибок (тестирование);

     диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);

     внесение исправлений в программу с целью устранения ошибок.

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

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

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

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

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

     отсутствие эталона (программы), которому должна соответ-ствовать тестируемая программа;

     высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;

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

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

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

    1. Процесс тестирования более эффективен, если проводится не автором программы. По своей сути тестирование - это процесс деструктивный (разрушительный). Именно этим и объясняется, поче-му многие считают его трудным. Особенно трудным и малоэффек-тивным он является для самого автора программы, так как после выполнения конструктивной части при проектировании и написания программы, ему трудно перестроиться на деструктивный образ мышления и, создав программу, тут же приступить к пристрастному выявлению в ней ошибок. Поэтому для проведения тестирования создаются специальные группы тестирования. Это не означает, что программист не может тестировать свою программу. Речь идет о повышении эффективности тестирования.

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

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

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

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

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

    Основные определения

    Тестирование (testing) - процесс выполнения программы или ее части с целью найти ошибки.

    Доказательство (proof) - попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предпола-гают прямого выполнения программы.

    Контроль (verification) - попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

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

    Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, но под ними подразумеваются разные виды деятельности.

    Тестирование - это деятельность, направленная на обнаружение ошибок.

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

    Тестирование модуля, или автономное тестирование (module testing, unit testing) - контроль отдельного программного модуля, обычно в изолированной среде (изолированно от всех остальных модулей).

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

    Тестирование сопряжений (integration testing) - контроль сопряжений между частями системы (модулями, компонентами, подсистемами).

    Тестирование внешних функций (external function testing) - контроль внешнего поведения, определенного внешними спецификациями.

    Комплексное тестирование (system testing) - контроль и/или испытание системы по отношению к исходным целям.

    Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в реальной среде.

    Тестирование приемлемости (acceptance testing) - проверка соответствия программы требованиям пользователя.

    Тестирование настройки (installation testing) - проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.

    Отношения между этими типами тестов и процессами проектирования показаны на рис. 15.

    Стратегия проектирования тестов

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

    1. Тестирование по отношению к спецификациям (не заботясь о тексте программы).

    2. Тестирование по отношению к тексту программы (не заботясь о спецификациях).

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

    Сторонники первого подхода проектирует тесты, исследуя внешние спецификации или спецификации сопряжения программы или модуля, которые он тестирует. Программа рассматривается как черный ящик. Логика их такова: «Меня не интересует, как выглядит эта программа, и выполнил ли я все команды. Я удовлетворен, если программа будет вести себя так, как указано в спецификациях». То есть в идеале проверить все возможные комбинации и значения на входе.

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

    Ни одна из этих крайностей не является хорошей стратегией.

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

    Интеграция модулей

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

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

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

    Статическое тестирование - проводится без использова-ния ЭВМ путем просмотра текста программы после трансляции, проверки правил структурного построения программ и обработки данных. В качестве эталонов используются, во-первых, внутренние спецификации, а, во-вторых, коллективный опыт специалистов-тестировщиков. Применение статического тестирования достаточ-но эффективно. Для типичных программ, по данным фирмы IBM, можно находить от 30 % до 80 % ошибок логического проектирования и кодирования. Этот метод способствует существенному повыше-нию производительности и надежности программ, позволяет раньше обнаружить ошибки, а значит уменьшить стоимость ис-правления.

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

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

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

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

    Восходящее тестирование

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

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

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

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

    При этом подходе возникают два вопроса: что делать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует), и как подаются тестовые данные. Ответ на первый вопрос состоит в том, что для имитации функций недостающих модулей программируются модули-заглушки, которые моделируют функции отсутствующих модулей. Фраза «напишите заглушку» часто встречается в описании этого подхода, но она способна ввести в заблуждение, поскольку задача написания «заглушки» может оказаться трудной. Ведь заглушка редко сводится просто к оператору RETURN, поскольку вызывающий модуль обычно ожидает от нее выходных параметров. В таких случаях в заглушку встраивают фиксированные выходные данные, которые она всегда и возвращает. Иногда это оказывается неприемлемым, так как вызывающий модуль может рассчитывать, что результат вызова зависит от входных данных. Поэтому в некоторых случаях заглушка должна быть довольно изощ-ренной, приближаясь по сложности к модулю, который она пытается моделировать.

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

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

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

    Преимуществом нисходящего подхода часто считают отсутствие необходимости в драйверах; вместо драйверов следует написать «заглушки». Однако это преимущество спорно.

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

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

    Модифицированный нисходящий метод

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

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

    Метод большого скачка

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

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

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

    Метод большого скачка значительно усложняет отладку.

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

    Метод сандвича

    Тестирование методом сандвича - это компромисс между восходящим и нисходящим подходами; попытка воспользоваться достоинствами обоих методов, избежав их недостатков.

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

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

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

    Модифицированный метод сандвича

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

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

    Сравнение методов тестирования

    С точки зрения надежности ПО стратегии тестирования можно оценить по семи критериям (табл. 9).

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

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

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

    Пятый критерий - мера параллелизма, который возможен в начале или на ранних стадиях тестирования (но не концу цикла тестирования).

    Шестой критерий связан с ответом на вопрос: возможно ли проверить любой конкретный путь и любое условие в программе?

    Седьмой критерий характеризует сложность планирования, надзора и управления в процессе тестирования.

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

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

    Сложность подготовки заглушек, планирования и управления последовательностью тестов также важны, они получают вес 2.

    Третий критерий, необходимость драйверов - вес 1 ввиду доступности общих инструментов тестирования.

    Критерий, связанный с параллелизмом работы, имеет вес 1 (он может быть важен по другим причинам, но на надежность сильно не влияет).

    Шестой критерий - вес 3.

    Седьмой критерий получает вес 2.

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

    Этапы тестирования

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

    Тестирование программных модулей - наиболее форма-лизованный и автоматизированный процесс тестирования.

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

    Проверяется корректность структуры модулей и их конструктивных основных компонентов: процедур, циклов, блоков, условий и т.д.

    Тестирование планируется с учетом структуры модулей и особенностей обработки информации и осуществляется преиму-щественно детерминировано.

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

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

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

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

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

    Сборка модулей в программный комплекс может осуществляться двумя методами: монолитным и пошаговым.

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

    В качестве примера рассмотрим программный пакет, состоя-щий из девяти модулей (рис. 16).

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

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

    Рис. 16. Структура пакета из 9 модулей

    Для рассматриваемого примера модули-драйверы нужны для всех модулей, кроме модуля М1, а модули-заглушки нужны для всех модулей, кроме М5, М6, М7, М8, М9 (т.е. модулей самого низ-шего уровня).

    Таким образом, при монолитной сборке необходимо разрабо-тать восемь модулей-драйверов и минимум девять модулей-заглушек.

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

    Предположим, что тестируем сверху-вниз. Тогда для модуля М1 нужно разработать три заглушки. Далее подключается модуль М2, для которого нужно предварительно разработать две заглушки, и тес-тируются модули М1-М2. Затем заглушка М5 заменяется модулем М5 и тестируется цепочка М1-М2-М5.

    Процесс продолжается до тех пор, пока не будет собран весь комплекс. Есть возможность неко-торого распараллеливания работ и автономного тестирования це-почек М1-М2-М5 (М6), М1-М3-М7, М1-М4-М8 (М9).

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

    При тестировании снизу-вверх процесс организуется следую-щим образом: тестируются модули низшего уровня - М5, М6, М7, М8, М9. Для каждого из них нужен драйвер.

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

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

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

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

    Системное тестирование (или испытание программного комплекса) предназначено в основном для проверки соответствия пакета прикладных программ техническому заданию и для оценки его пригодности к регулярной эксплуатации и сопровождению.

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

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

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

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

    Для таких коммерческих прикладных программ принято проводить испытания в два последовательных этапа, на-зываемых альфа- и бета-тестированием.

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

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

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

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

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

    Лишь та ошибка, что не исправляется.

    Конфуций

    Отладка программного средства (ПС) - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами: Отладка = Тестирование + Поиск ошибок + Редактирование.

    Иногда тестирование и отладку считают синонимами.

    Принципы и виды отладки программного средства

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

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

    Рис. 17. Подходы к проектированию тестов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Автономная отладка программного средства

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

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

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

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

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

     простота подготовки тестов;

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

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

    Недостатками восходящего тестирования являются следующие его особенности:

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

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

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

    К достоинствам нисходящего тестирования относятся следующие его особенности:

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

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

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

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

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

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

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

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

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

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

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

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

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

    Комплексная отладка программного средства

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

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

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

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

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

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

    Испытание программных продуктов Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования.

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

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

    В соответствии с ГОСТ 19.004-80 под испытанием программ понимают установление соответствия программы заданным требованиям и программным документам. Это определение построено на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обеспечение которых гарантирует пригодность программы к исполь-зованию по своему назначению.

    При отсутствии технического задания (ТЗ) на разработку программного средства (ПС) или полного и обоснованного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и неконструктивной.

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

    Основными видами испытания программных продуктов (ПП) являются:

     предварительные;

     приемочные;

     эксплуатационные испытания, включая опытную эксплуатацию.

    В зависимости от места проведения различают стендовые и полигонные испытания.

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

    Если в основу стендовых испытаний положен принцип моделирования, то соответствующие испытательные стенды называют моделирующими .

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

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

    По степени зависимости испытателей от разработчиков различают зависимые и независимые испытания.

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

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

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

    Технологическая схема испытания

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

     знание назначения испытываемого ПС, условий его функционирования и требований к нему со стороны пользователей;

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

     ясное представление цели и последовательности испытания;

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

     систематический контроль, регулярное ведение протокола и журнала испытания;

     последовательное определение и выполнение плана испытания;

     сопоставление имеющихся ресурсов с предполагаемым объемом испытания;

     возможность обеспечения объективной количественной оценки полноты и достоверности результатов испытания на всех этапах.

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

    В подготовку испытаний ПС входят следующие мероприятия:

     составление и согласование плана-графика проведения испытания;

     разработка, комплектование, испытание и паспортизация программно-технических средств, используемых при испытаниях;

     анализ пригодности испытательных средств, используемых во время предварительных испытаний, для проведения приемочных испытаний;

     анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС;

     проверка и согласование с представителем заказчика конструкторской документации на ПС, предъявляемой при испытаниях;

     разработка, согласование и утверждение программ и методик испытаний;

     аттестация специалистов на допуск к проведению испытаний;

     приемка испытываемого опытного образца ПС на носителе данных и документации;

     проведение мероприятий, направленных на обеспечение достоверности испытаний.

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

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

    На основании изложенного можно определить следующие пять этапов испытания:

    1. Обследование проектируемого ПС, анализ проектной документации.

    2. Определение наиболее важных подсистем и функций проектируемого ПС, подлежащих испытанию.

    3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания.

    4. Разработка (освоение) испытательных программно-техничес-ких средств, библиотек тестов и баз данных (если они требуются).

    5. Непосредственное проведение испытаний, анализ результатов, принятие решения.

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

    На рис. 18 изображена технологическая схема в виде этапов подготовки и проведения испытания и их связи с этапами разработки ПС.

    Планирование и оценка испытаний

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

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

    Рис. 18. Технологическая схема испытания ПС

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

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

    4) ПС испытывают в реальной среде функционирования;

    5) ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде.

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

    Методика решения задачи планирования испытания включает в себя следующие этапы:

     нахождение всех путей реализации;

     выделение минимального подмножества путей, обеспечивающих проверку всех участков программы;

     разработка тестов для проверки выделенных путей.

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

    N = 1 - n /К ,

    С возрастанием количества экспериментов критерий интенсивности обнаружения ошибок будет асимптотически стремиться к единице.

    Тогда в качестве критерия прекращения испытаний можно принять, например, следующее условие: N  > 0,95 при обнаружении в последних двухстах экспериментах не более трех несуще-ственных ошибок. Идея выбора такого критерия основана на том, что частота обнаружения ошибок, выраженная отношением n /К , по мере увеличения количества экспериментов должна уменьшаться и к моменту завершения испытаний принять значение, близкое к нулю. Следует иметь в виду, что оценка уровня завершенности испытаний будет достоверной лишь в случае, если каждый эксперимент проводится в новых условиях и испытатели стремятся обнаружить ошибки, а не доказать их отсутствие.

    Критерий заданного значения средней наработки на отказ (критерий Дж.Д. Муса). Предположим, что суммарное количество обнаруженных и устраненных дефектов в программе n (под дефектом понимается любая причина неудовлетворенности свойствами программы) описывается показательной функцией времени функционирования t

    Коэффициент С  1 тогда, когда абсолютная реактивность программы при прогоне тестов или статистических испытаниях отличается от абсолютной реактивности при работе программы в реальных условиях.

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

    Коэффициент пропорциональности В  = n /m называется коэффициентом уменьшения дефектов.

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

    В качестве критерия завершенности испытания можно принять достижение требуемого (заданного) значения средней наработки на отказ Т 0 .

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

     скорость выявления дефектов;

     скорость устранения дефектов;

     удовлетворенность машинным временем.

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

    Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

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

    Искусство тестера состоит в том, чтобы создать по возможности полную систему тестов, проверяющую все возможные ветви вычислений. Поясним это на самом простом примере. Пусть программа находит сумму первых N элементов массива X , содержащего M элементов. Кроме "нормального" теста, проверяющего ситуацию, в которой 1M . Но это простой случай, а циклы обычно вложенные, и внутри них производится разбор случаев, внутри которых свои циклы.

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

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

    Средства отладки

    Часть ошибок программы ловится автоматически еще на этапе компиляции. Сюда относятся все синтаксические ошибки, ошибки несоответствия типов и некоторые другие. Однако синтаксически корректная программа нуждается в отладке, поскольку, хотя результаты вычислений и получены, но они не соответствуют требуемым спецификациям. Чаще всего, еще не отлаженная программа на одних исходных данных работает правильно, на других - дает ошибочный результат. Искусство отладки состоит в том, чтобы обнаружить все ситуации, в которых работа программы приводит к ошибочным вычислениям. VBA обладает весьма изощренными средствами, предназначенными для отладки программ, т.е. для обнаружения ошибок в программах (тестирования) и их исправления. Есть две группы средств VBA, помогающие программисту выявить и исправить ошибки:

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

    Прежде, чем приступить к подробному рассмотрению этих средств, напомним, что в ходе отладки программа может находиться в одном из трех состояний: проектирования, вычисления и прерывания. Закончив проектирование, можно запустить программу на исполнение. Прервав исполнение программы в заданной точке, перейдя в состояние прерывания, можно проконтролировать значения переменных и свойств объектов в данной точке и, если требуется, изменить эти значения "вручную". При этом можно изменить порядок выполняемых операторов, задавать следующий исполняемый оператор, можно редактировать программный текст перед продолжением вычисления. Переход из состояния вычисления в состояние прерывания может происходить по самым разным причинам, например, по достижении точки прерывания, при выполнении одного из многочисленных условий прерывания, из-за пошагового выполнения программы. Все эти возможности мы еще обсудим, а сейчас рассмотрим один особый случай. Иногда программа "зацикливается" и необходимо принудительно перевести ее в с остояние прерывания. Как остановить работающую программу? Просто нажмите знакомую еще по работе в DOS пару клавиш Ctrl+Break. На экране появится следующее диалоговое окно с сообщением об остановке.

    Отладка (debug, debugging) - этап разработки компьютерной программы, на котором обнаруживают, локализуют и устраняют ошибки. Чтобы понять, где возникла ошибка, приходится: узнавать текущие значения переменных; выяснять, по какому пути выполнялась программа.

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

    Технологии отладки.

    1) Использование отладчиков - программ, которые включают в себя пользовательский интерфейс для пошагового выполнения программы: оператор за оператором, функция за функцией, с остановками на некоторых строках исходного кода или при достижении определённого условия.

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

    Инструменты отладки.

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

    2. Профилировщики – позволяют определить сколько времени выполняется тот или иной участок кода, а анализ покрытия позволит выявить неисполняемые участки кода.

    3. API логгеры – позволяют программисту отследить взаимодействие программы и Windows API при помощи записи сообщений Windows в лог.

    4. Дизассемблеры позволят программисту посмотреть ассемблерный код исполняемого файла

    5. Сниферы помогут программисту проследить сетевой трафик генерируемой программой

    6. Сниферы аппаратных интерфейсов позволят увидеть данные которыми обменивается система и устройство.

    7. Логи системы .

    Использование языков программирования высокого уровня , таких как Java, обычно упрощает отладку, поскольку содержат такие средства как обработка исключений , сильно облегчающие поиск источника проблемы. В некоторых низкоуровневых языках, таких как Ассемблер , ошибки могут приводить к незаметным проблемам - например, повреждениям памяти или утечкам памяти, и бывает довольно трудно определить, что стало первоначальной причиной ошибки. В этих случаях, могут потребоваться изощрённые приёмы и средства отладки.

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

    Виды отладки ПО, включая тестирование (в нашей стране).

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



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

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

    2.2. Семантическая (смысловая ) отладка. Ее время наступает тогда, когда синтаксических ошибок не осталось, но результаты программа выдает неверные. Здесь компилятор сам ничего выявить не сможет, хотя в среде программирования обычно существуют вспомогательные средства отладки, о которых мы еще поговорим.

    Взаимосвязь процессов тестирования и отладки через алгоритм отладки.

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

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

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

    Средства автоматического тестирования исходного кода программ.

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

    Примерами таких систем могут быть: встроенный модуль doctest в Python и мультиязыковая библиотека тестирования xUnit, распространяемая на условиях GNU/GPL и LGPL. Основа применения всех этих средств и техник это разбиение одной большой задачи на ряд четких и более маленьких задач.


    23. Основные принципы объектно-ориентированного программирования: инкапсуляция, наследование, полиморфизм. Отличие объектно-ориентированного подхода от модульного при разработке программ

    Объектно-ориентированное программирование (ООП) - парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием, - прототипов).

    Прототип - это объект-образец, по образу и подобию которого создаются другие объекты.

    Класс

    Поля , описанные в классе, используют для хранения составляющих состояния объекта, т.е. поля определяют состояние объектов.

    Методы , описанные в классе, определяют поведение объектов. Каждый метод определяет реакцию объекта на некоторое внешнее или внутреннее сообщение.

    Объект - переменная типа класс

    Принципы объектно-ориентированного программирования.

    1. Абстракция. Абстрагирование - это способ выделить набор значимых характеристик объекта, исключая из рассмотрения незначимые. Соответственно, абстракция – это набор всех таких характеристик.

    2. Инкапсуляция.

    Инкапсуляция - принцип ООП, согласно которому в классе объединяются поля и методы.

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

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

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

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

    4. Полиморфизм. Полиморфизм - это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

    Полиморфизм (“многообразие”) в программировании - возможность изменения кода программы в соответствии со значением некоторых параметров.

    4.1. Чистый полиморфизм - возможность различной интерпретации кода функции в зависимости от типа аргументов.

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

    4.3. Переопределение методов - в ООП - возможность различных определений методов в классе-потомке и классе-родителе; конкретный метод определяется классом объекта, для которого он вызывается. При переопределении методов различают простой и сложный полиморфизм.

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

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

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

    Отличие объектно-ориентированного подхода от модульного.

    1) Объектно-ориентированный подход к проектированию прогр. продуктов основан на:

    − выделении классов объектов;

    − установлении характерных свойств объектов и методов их обработки;

    − создании иерархии классов, наследовании свойств объектов и методов их обработки.

    2) Модульное программирование - это организация программы как совокупности небольших независимых блоков, модулей, структура и поведение которых подчиняется определенным правилам.

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

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


    24. Классы и объекты: их определение, соотношение между ними. Роль составляющих класса – полей, свойств, методов. Спецификаторы доступа published, public, private, protected. Конструкторы и деструкторы, их роль. События и их использование в управлении программой

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

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

    Соотношение класса и объекта:

    Понятие класса является более общим, чем понятие объекта. Объект является экземпляром класса . Класс может рассматриваться как совокупность объектов (подобно тому, как множество есть совокупность элементов). Класс может быть элементарным или подразделяться на подклассы (подобно тому как множество подразделяется на подмножества). Например, класс PERSON содержит подкласс STUDENT, который, в свою очередь, содержит объект John_Smith.

    Классы имеют (например, в Delphi):

    − Поле класса (атрибут ) в ООП - переменная, связанная с классом или объектом. Поля , описанные в классе, используются для хранения составляющих состояния объекта, т.е. поля определяют состояние объектов. Доступ к полям осуществляется по их имени.

    − Методы , описанные в классе (подпрограммы, которые обрабатывают поля и свойства класса), определяют поведение объектов. Каждый метод определяет реакцию объекта на некоторое внешнее или внутреннее сообщение.

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

    Поля, свойства и методы класса называются членами класса .

    Переменная, описанная как класс, фактически является указателем на экземпляр класса. В объектно-ориентированной программе с применением классов каждый объект является «экземпляром» некоторого конкретного класса, и других объектов не предусмотрено.

    Спецификаторы доступа published, public, private, protected.

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

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

    Уровни инкапсуляции (доступность любых членов класса):

    1) Public . Члены класса, находящиеся в данном разделе, доступны из любой точки программы.

    2) Private . Члены класса доступны только в том модуле, где данный класс описан. По умолчанию считается, что все поля класса расположены в разделе private .

    3) Protected . Члены класса доступны в том модуле, где данный класс описан, а также внутри методов классов, являющихся наследниками данного класса и описанных в других модулях.

    4) Published . Члены класса, находящиеся в данном разделе, доступны из любой точки программы. В этом разделе располагаются свойства класса: поля, доступные для редактирования и изменения значений во время проектирования и из Инспектора объектов .

    5) Automated . Члены класса, находящиеся в данном разделе, доступны из любой точки программы. Описания разрешается размещать в этом разделе, только если класс является наследником стандартного класса TAutoObject (в Delphi), предназначенного для создания так называемых серверов автоматизации при использовании технологии СОМ (Competent Object Model).

    Конструкторы и деструкторы.

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

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

    События и их использование в управлении программой.

    Событие в ООП - это сообщение, которое возникает в различных точках исполняемого кода при выполнении определённых условий.

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

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


    25. Основные отличия языка Object Pascal (Delphi) от Turbo Pascal. Динамические массивы в Delphi: описание, особенности, применение

    Turbo Pascal - интегрированная среда разработки для языка программирования Pascal и язык программирования в этой среде, диалект языка Паскаль от фирмы Borland.

    Delphi - среда программирования, в которой используется язык программирования Object Pascal.

    Object Pascal - результат развития языка Turbo Pascal , который, в свою очередь, развился из языка Pascal . Pascal был полностью процедурным языком.

    Turbo Pascal , начиная с версии 5.5, добавил в Pascal объектно-ориентированные свойства, а в Object Pascal - динамическую идентификацию типа данных с возможностью доступа к метаданным классов (то есть к описанию классов и их членов) в компилируемом коде, также называемом интроспекцией - данная технология получила обозначение RTTI.

    Так как все классы наследуют функции базового класса TObject, то любой указатель на объект можно преобразовать к нему, после чего воспользоваться методом ClassType и функцией TypeInfo, которые и обеспечат интроспекцию.

    Object Pascal (Delphi ) является результатом функционального расширения Turbo Pascal.

    Объектная модель Delphi Pascal по сравнению с моделью, использованной Borland Pascal 7.0, является более полной:

    − ограничение доступа к полям и методам за счет определения собственного интерфейса к каждому полю класса (пять типов секций при объявлении класса, использование свойств);

    − более развитые механизмы реализации полиморфных методов (абстрактные, динамические методы)",

    − средства работы с метаклассами (переменные метаклассов, методы классов, механизм RTTI).

    Динамические массивы в Delphi.

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

    Объявление массива: var My_Array: array of BaseType;

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

    Установка размера массива: SetLength(My_Array,100);

    Получение числа элементов массива: n:=Length(My_Array);

    Обращение к первому элементу массива: My_Array:=10; x:=My_Array;

    Объявление двумерного массива: var A: array of array of BaseType;

    Если присвоить переменной динамический массив, то его содержимое не копируется, присваивается только указатель на массив. А вот если применить к новому массиву SetLength , то тогда и произойдет копирование.


    26. Структура модулей в Delphi. Интерфейсная, исполняемая части, инициирующая и завершающая части. Процедуры и функции: особенности в Delphi

    Проект в Delphi представляет собой набор программных единиц – модулей.

    Delphi позволяет поместить свои функции и процедуры в отдельный модуль (Unit ), а затем использовать процедуры и функции модуля в своих программах, указав имя модуля в списке модулей, необходимых программе (инструкция uses ). Модуль – это файл с расширением *.pas.

    Начинается модуль заголовком - инструкцией unit , в которой указано имя модуля.

    Модуль состоит из последовательности разделов . Каждый раздел начинается ключевым словом и продолжается до начала следующего раздела. В раздел implementation (реализация) нужно поместить процедуры и функции, объявленные в разделе interface .

    Структура модулей в Delphi.

    Unit <имя>;

    Interface <интерфейсная часть>

    Implementation <исполняемая часть>

    initialization <инициирующая часть>

    finalization <завершающая часть>

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

    unit ИмяМодуля;

    interface // раздел интерфейса

    { Описания процедур и функций модуля, которые могут использоваться другими модулями. }

    const // раздел объявления констант

    { Объявления глобальных констант модуля, которые могут использоваться процедурами и функциями модуля.}

    type // раздал объявления типов

    { Объявления глобальных типов модуля, которые могут использоваться процедурами и функциями модуля }

    var // раздел объявления переменных

    { Объявления глобальных переменных модуля, которые могут использоваться процедурами и функциями модуля}

    implementation // раздел реализации

    { Описания (текст) процедур и функций модуля!}

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

    Процедуры и функции в Delphi.

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

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

    − когда подпрограмма не возвращает в основную программу никаких данных;

    − когда подпрограмма возвращает в вызвавшую ее программу больше чем одно значение.

    Параметры – это входные данные.

    Объявление процедуры

    procedure ИмяПроцедуры {var параметр1: тип1; … var параметр К: тип К);

    Типичный цикл разработки, за время жизни программы многократно повторяющийся, выглядит примерно так:

    1Программирование - внесение в программу новой функциональности, исправление ошибок в имеющейся.

    2Тестирование (ручное или автоматизированное; программистом, тестером или пользователем; «дымовое», в режиме чёрного ящика или модульное…) - обнаружение факта ошибки.

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

    4Отладка - обнаружение причины ошибки.

    Отладка программы. При построении сложных программ могут возникать ошибки. Их принято делить на 3 группы:

      синтаксические;

      ошибки времени выполнения;

      алгоритмические.

    Наиболее простые из них синтаксические – ошибки набора текста – они исправляются в процессе компиляции программы. Ошибки времени выполнения – ошибки, возникающие при несоответствии типов введенных параметров типам используемых переменных, или ошибки вычислений (например, деление на 0) – отслеживаются также легко уже при первых запусках программы.

    После возникновения такой ошибки необходимо нажать «Ok» в окне сообщения об ошибке, а затем завершить выполнение программы – пункт меню « Run / Program reset » или нажать комбинацию клавиш <Ctrl ><F 2 >. При возникновении такой ошибки курсор в программе будет указывать на строку, вызвавшую ошибку. Наиболее сложно обнаружить алгоритмические ошибки. Программа компилируется без ошибок, не дает ошибок при пробных запусках, но при анализе результатов выясняется, что результат неправильный. Необходимо вручную «прокрутить» алгоритм – требуется отладка программы .

    Для трассировки программы (проверка «логики алгоритма»), т. е. выполнения программы по шагам, необходимо выполнить следующие действия. В пункте меню выбрать пункт «Run / Step over » или «Run / Trace in to » (клавиши <F 8 > и <F 7 > соответственно), команда «Run / Trace in to » отличаются более детальной трассировкой. Для прекращения трассировки и продолжения выполнения программы в автоматическом режиме необходимо выбрать пункт «Run / Run » или нажать <F 9 >. Остановить программу можно с помощью команды «Run / Program reset » или нажать комбинацию клавиш <Ctrl ><F 2 >. Иногда необходимо выполнить трассировку с определенной строки программы. Для этого курсор подводят к интересующей строке и выполняют команду «Run / Run to cursor » или нажимают <F 4 >. Часто известно возможное место ошибки в алгоритме – тогда используют точку останова . Программист устанавливает на нужной строке курсор и ставит там точку останова с помощью команды «Run / Add Breakpoint » или нажав <F 5 >. Выбранная строка будет отмечена. Для снятия точки останова необходимо на этой строке снова нажать <F 5 >. При выполнении программа дойдёт до точки останова, затем программист сможет трассировать программу с помощью <F 7 > и <F 8 >. При необходимости можно указать условие остановки на точке останова (эта настройка осуществляется в окне «Breakpoints », пункт меню «Run / Add breakpoints »).

    При выполнении программы по шагам часто необходимо не только проверять правильность «логики алгоритма», но и знать значения некоторых переменных. Для этого выполняют команду «View / Watch / Add watch » и вводят имя интересующей переменной либо подводят курсор к переменной, значение которой необходимо просмотреть, и нажимают <Ctrl ><F 5 >. При трассировке программы в этом случае в окне «Watch list » можно наблюдать изменение значений интересующих переменных.

    10. Создание и описание новых типов данных.

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

    Имя = Описание типа;

    Имя – имя нового типа;

    Описание типа – описание возможных значений переменных созданного типа.

    Замечание. При описании нового типа после имени типа ставится знак «равно», затем следует описание типа.

    Примеры

    DayOfWeek = (Monday, Wednesday, Friday);

    Day =1..31;

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

    Примеры

    Пусть объявлены переменные W: DayOfWeek и D: Day. Тогда:

    Succ (W); {Оператор вернет значение ‘Monday’}

    Pred (D); {Оператор вернет значение ‘4’}

    Замечания:

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

      Обращение с помощью оператора Succ или Pred к последнему (для оператора Succ ) или первому (для оператора Pred ) элементу приведет к ошибке.

    Читать еще: