3 понятие отладки отличия отладки от тестирования

Мы поможем в написании ваших работ! знаете ли вы? отладка имеет место тогда, когда программа работает неправильно, а тестирование служит



Мы поможем в написании ваших работ!

ЗНАЕТЕ ЛИ ВЫ?

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

Отладочный барьер

Компиляторы не в состоянии выявить логические ошибки.

Наиболее распространенные ошибки

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

Ошибки анализа — учтены не все возможные ситуации.

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

Ошибки физического характера — ошибки в результате неправильных действий в исходном коде (пропуск, дублирование, наличие лишних, перестановка строк программы; отсутствие данных, неверный формат, кодировка).

Бесхитростное программирование

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

Синтаксические ошибки

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

Ошибки не обнаруживаемые компилятором

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

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

Виды отладки

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

Общие рекомендации

Заботиться об возможностях отладки и тестирования на этапе программирования.

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

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

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

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

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

Программирование без ошибок

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

Псевдоотладка: Если обнаружено 95% ошибок, то для обнаружения последующих 1—2% может потребоваться вдвое больше времени.

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

Предотвращение ошибок

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

Тестирование программ.

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

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

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

Различают дефекты программного обеспечения и сбои. В случае сбоя программа ведет себя не так, как ожидает пользователь. Дефект — это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.

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

Уровни тестирования

1) Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция

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

3) Системное тестирование — тестируется интегрированная система на её соответствие исходным требованиям

a) Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на стороне разработчика. Применяется для законченного продукта в качестве внутреннего приемочного тестирования. Иногда выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

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

Методы тестирования

Поможем в ✍️ написании учебной работы


Введение

Понятия тестирования и отладки программного обеспечения

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

2 Этапы тестирования программного обеспечения

3 Цели и задачи тестирования программного обеспечения

4 Комплексное тестирование программного обеспечения

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

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

1 Метод Сандвича

2 Метод «белого ящика»

3 Метод «черного ящика»

4 Метод отладки программного обеспечения

Заключение

Глоссарий

Список использованных источников

Список сокращений

Введение

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

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

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

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

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

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

1. Понятия тестирования и отладки программного обеспечения

.1 Принципы тестирование и отладка программного обеспечения

Тестирование программного обеспечения (software testing)- это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов.

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

Согласно этому определению, тестирование предусматривает «анализ» или «эксплуатацию» программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программного обеспечения, называется статическим тестированием (static testing). Статическое тестирование предусматривает проверку программных кодов, сквозной контроль и проверку программы без запуска па машине, т.е. проверку за столом (desk checks). В отличие от этого, тестовая деятельность, предусматривающая эксплуатацию программного продукта, носит название динамического тестирования (dynamic testing). Статическое и динамическое тестирование дополняют друг друга, и каждый из этих типов тестирования реализует собственный подход к выявлению ошибок.

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

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

1.2 Этапы тестирования программного обеспечения

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

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

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

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

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

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

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

Определение объемов тестовых работ

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

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

Тестировать в первую очередь требования с наивысшим приоритетом.

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

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

Тестировать те участки, в которых наиболее вероятно присутствие проблем

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

Определение подхода к тестированию

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

Стадия формулирования требований

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

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

Системные испытания

Приемочные испытания

Регрессионное тестирование

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

Определение критериев тестирования и точек контроля качества

Существует пять типов критериев, которые могут определяться перед началом системного тестирования:

Критерий входа. Описывает, что нужно сделать перед началом тестирования.

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

Критерий приостановки/возобновления. Описывает, что произойдет, если по причине из-за дефектов продолжение тестирования окажется невозможным.

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

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

Определение стратегии автоматизации.

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

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

1.3 Цели и задачи тестирования программного обеспечения

Цели тестирования:

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

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

Задачи тестирования:

Проверить, что система работает в соответствии с определенными временами отклика клиента и сервера.

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

Проверить работу пользовательских интерфейсов

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

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

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

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

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

1.4 Комплексное тестирование программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.1 Метод Сандвича

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

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

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

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

2.2 Метод «белого ящика»

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

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

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

Дают гарантию того, что все независимые пути в модуле проверены по крайней мере один раз.

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

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

Исследуют структуры внутренних данных с целыо проверки их достоверности.

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

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

Методы тестирования на основе стратегии белого ящика:

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

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

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

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

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

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

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

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

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

2.3 Метод «черного ящика»

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

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

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

Неверная или пропущенная функциональность

Ошибки интерфейса

Проблемы удобства использования

Методы тестирования на основе Автоматизированные инструменты

Ошибки в структурах данных или ошибки доступа к внешним базам данных

Проблемы снижения производительности и другие ошибки производительности

Ошибки загрузки

Ошибки многопользовательского доступа

Ошибки инициализации и завершения

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

Проблемы безопасности

Методы тестирования на основе стратегии черного ящика

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

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

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

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

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

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

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

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

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

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

2.4 Методы отладки программного обеспечения

программный обеспечение тестирование отладка

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

Ручное тестирование;

Снижения;

Обратная трассировка.

Метод ручного тестирования.

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

Метод пролога.

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

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

Метод снижения.

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

Метод обратной трассировки.

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

Заключение

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

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

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

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

Каждая компания-производитель телевизионных программ знает, что является временем и шпигует листы при устранении неисправностей и тестировании программ. На этом этапе это — необходимые приблизительно 50 % общей стоимости программирования. Не каждый из разработчиков матобеспечения может истинно определить цель тестирования. Довольно часто возможно услышать, что тестирование — процесс производительности программы с целью укладки текста в этом ошибок. Но эта цель недосягаема: что самое тщательное тестирование не дает гарантии, что программа не содержит Ошибки.

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

Глоссарий

№ п/пПонятиеОпределение 1Тестирование программного обеспеченияэто процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов 2Отладкаэто процесс выявления источников отказов, т.е. ошибок, и внесение в программу соответствующих исправлений3Восходящее тестированиетестирование осуществляется снизу вверх4Нисходящее тестированиетестирование осуществляется сверзу вниз5Тестирование «белого ящика»это разработка тестовых случаев где используют любые доступные сведения о внутренней структуре или коде6Тестирование «черного ящика»это разработка тестовых случаев при наличии установленных открытых интерфейсов7Метод сандвичаэто подход к интеграции больших программ, таких, как операционная система или пакет прикладных программ.8Модульное тестированиепроцесс, позволяющий проверить на корректность отдельные модули исходного кода программы9Тестирование безопасностиэто проверка работы механизмов доступа к системе и к данным10Тестирование производительностиэто проверка, удовлетворяет ли системное приложение требованиям по производительности Список использованных источников

1.Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем [текст] / Б. Бейзер; — Питер, 2004, 320 с. ISBN 5-94723-698-2.

2.Брауде Э.Д. Технология разработки программного обеспечения [текст] / Э.Д. Брауде; — Питер, 2004, 656 с. ISBN 5-94723-663-X.

.Винниченко И.В. Автоматизация процессов тестирования [текст] / И. В. Винниченко; — Питер, 2005, 208 с. ISBN 5-469-00798-7.

.Канер С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений [текст] / С. Канер; — ДиаСофт, 2001, 544 с, ISBN 966-7393-87-9.

.Калбертсон Р. Быстрое тестирование [текст] / Р. Калбертсон, К. Браун, Г. Кобб; — Вильямс, 2002, 384 с. ISBN 5-8459-0336-X.

.Коликова Т.В. Основы тестирования программного обеспечения. Учебное пособие [текст] / Т.В. Коликова, В.П. Котляров; — Интуит, 2006, — 285 с. ISBN 5-85582-186-2.

.Касперски К. Техника отладки программ без исходных текстов [текст] / К. Касперски; — БХВ-Петербург, 2005, 832 с. ISBN 5-94157-229-8.

.Макгрегор Д. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие [текст] / Д. Макгрегор, Д. Сайкс; — ТИД «ДС», 2004, 432 с. ISBN 966-7992-12-8.

.Плаксин М. Тестирование и отладка программ — для профессионалов будущих и настоящих [текст] / М. Пласкин; — Бином. Лаборатория знаний, 2007, — 168 с. ISBN 978-5-94774-458-3.

.Роберт М. Быстрая разработка программ: принципы, примеры, практика [текст] / М. Роберт, Д. Ньюкирк; — Вильямс, 2004, 752 с. ISBN 5-8459-0558-3.

.Фолк Д. Тестирование программного обеспечения [текст] / Д. Фолк, Е. К. Нгуен, С. Канер; — Диасофт, 2003 , 400 с. ISBN 966-7393-87-9.

.Элфрид Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация [текст] / Элфрид Д., Джефф Р., Джон П.;- Лори, 2003, ISBN 5-85582-186-2.

Список сокращений

testing — тестирование программного обеспечения- процессtesting — статическое тестирование checks — проверка за столом testing — динамического тестирования — дефектdown — нисходящий- программный интерфейс приложения

еггог returns — возвращение ошибкиbox — прозрачный ящик — прозрачное тестирование

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

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

    )

    элементу
    приведет к ошибке.

Введение 2

Определение
программирования. Этапы создания
программы 3

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

Задача
2 и 3 9

Задача
4 и 5 12

Заключение 14

Список
используемой литературы 15

Введение

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

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

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

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

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

Определение
программирования. Этапы создания
программы

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

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

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

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

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

2 этап.
Анализ задачи и моделирования: целью
этого этапа является математическая
модель или математическая постановка.
На этом этапе выполняются следующие
пункты

1)
Определяются исходные данные и их типы.

2)
Решение задачи описывается в виде
аналитических зависимостей (уравнения,
функции).

3)
Определяются конечные данные и их типы.

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

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

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

5 этап.
Отладка и тестирование программы:
заключается в поиске и устранении
синтаксических и логических ошибок в
программе.

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

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

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

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

Отладка
– это деятельность, направленная на
обнаружение и исправление ошибок в
программе.

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

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

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

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

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

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

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

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

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

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

  • Паскаль Отладка
    программ

    Реферат >> Информатика

    Логические операторы и операторы цикла. Отладка
    программ
    . Укороченная форма оператора if В… if. Средства среды программирования
    для отладки
    программ
    Среда Borland Pascal … несколько встроенных инструментальных средств отладки
    программ
    . С некоторыми из них…

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

    Реферат >> Экономика

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

  • Выполнение и отладка
    программ
    в интегрированной среде программирования
    Turbo Pascal (MS-Dos)

    Лабораторная работа >> Информатика, программирование

    Практического использования интегрированных сред программирования
    с целью выполнения и отладки
    программ
    на языке Паскаль. ТЕОРЕТИЧЕСКИЕ… СВЕДЕНИЯ Базовыми компонентами системы программирования
    Турбо…

  • Цель и порядок работы

    Цель работы – изучить инструментальные средства и возможности отладки программ в интегрированной среде Microsoft Visual C++ 2008 (Visual Studio 2008).

    Порядок выполнения работы:

    Ознакомиться с описанием лабораторной работы;

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

    Написать программу и отладить ее на ЭВМ;

    Оформить отчет.

    Краткая теория

    Интегрированная интерактивная среда разработки программ Microsoft Visual C++ 2008 (IDE) включает в себя ряд средств, облегчающих процесс нахождения ошибок в программе, которые не позволяют ей корректно работать.

    Понятие отладки

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

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

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

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

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

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

    Разбивайте программу на части: модули, процедуры, функции. Избегайте построения функций, размер которых больше 25-30 строк, в противном случае разбивайте их на несколько меньших по размеру функций;

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

    Цель лекции:

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

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

    Тестирование


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

    тестирование компонентов ПО; комплексное

    тестирование разрабатываемого ПО;
    системное

    или оценочное

    тестирование на соответствие основным
    критериям качества. Для повышения
    качества тестирования рекомендуется
    соблюдать следу­ющие основные
    принципы:

      предполагаемые
      результаты должны быть известны до
      тестирования;

      следует избегать
      тестирования программы автором;

      необходимо
      досконально изучать результаты каждого
      теста;

      необходимо
      проверять действия программы на неверных
      данных;

      необходимо
      проверять программу на неожиданные
      побочные эффекты на неверных данных.

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

    Существуют
    два принципиально различных подхода к
    формированию тестовых наборов: структурный

    и функциональный
    .
    Структурный
    подход

    базируется
    на том, что известна
    структура
    тести­руемого
    ПО, в том числе его алгоритмы («стеклян­ный
    ящик
    »).
    Тесты строятся для проверки правильности
    реализации заданной логики в коде
    программы. Функциональный
    подход

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

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

    Ручной
    контроль

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

    и динамический

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

    выполняют ручное
    тестирование
    (вручную
    моделируют про­цесс выполнения
    программы на заданных исходных данных).
    Исходными данными для таких проверок
    являются: техническое зада­ние,
    спецификации, структурная и функциональная
    схемы программного продукта, схемы
    отдельных компонентов, а для более
    поздних этапов — алгоритмы и тексты
    программ, а также тестовые наборы.
    Доказано, что ручной контроль способствует
    существенному увеличе­нию
    производительности и повышению надежности
    программ и с его помо­щью можно находить
    от 30 до 70 % ошибок логического проектирования
    и кодирования. Основными методами
    ручного контроля являются: инспекции
    исходного текста
    ,
    сквозные
    просмотры
    ,
    проверка
    за столом
    ,
    оценки
    программ
    .

    В
    основе структурного
    тестирования

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

    Другим
    способом проверки программ является
    функциональное

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

    При
    комплексном

    тестирова­нии

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

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

    После завершения
    комплексного тестирования приступают
    к оценочному

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

    Отладка


    это процесс локализации

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

      синтаксические
      ошибки

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

      ошибки
      компоновки

      обнаруживаются компоновщиком (редакто­ром
      связей) при объединении модулей
      программы;

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

      ошибки
      определения исходных данных (ошибки
      передачи, ошибки преобразования, ошибки
      перезаписи и ошиб­ки данных);

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

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

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

        ручного
        тестирования

        (при обнаружении ошибки нужно выполнить
        те­стируемую программу вручную,
        используя тестовый набор, при работе
        с ко­торым была обнаружена ошибка);

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

        дедукции

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

        обратного
        прослеживания

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

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

    Общая
    методика отладки программных продуктов,
    написанных для выполнения в операционных
    системах MS
    DOS
    и Win32:

    1
    этап

    изучение проявления ошибки;

    2
    этап –
    определение
    локализации
    ошибки;

    3
    этап

    определение причины ошибки;

    4
    этап —
    исправление
    ошибки;

    5
    этап —
    повторное
    тестирование.

    Процесс
    отладки можно существенно упрос­тить,
    если следовать основным рекомендациям
    структурного подхода к про­граммированию:

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

      выводить пользователю
      вводимые им данные для контроля и
      прове­рять их на допустимость сразу
      после ввода;

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

    Дополнительную
    информацию по теме можно получить в .

    Обновлено: 12.01.2022

    103583

    Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter

    3.1. Основные цели и принципы отладки

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

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

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

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

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

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

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

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

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

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


    1. Внешние характеристики качества по (определение, отличие от внутренних, перечислить некоторые из них, охарактеризовать перечисленные).

    Корректность
    — отсутствие/наличие дефектов в
    спецификации, проекте и реализации
    системы.

    Практичность
    — легкость изучения и использования
    системы.

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

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

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

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

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

    Живучесть
    — способность системы продолжать работу
    при вводе недопустимых данных или в
    напряженных условиях.


    1. Внутренние характеристики качества по (определение, отличие от внешних, перечислить некоторые из них, охарактеризовать перечисленные).

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

    Гибкость
    — возможный масштаб изменения системы
    с целью использования ее в тех областях
    или средах, на которые она не была
    непосредственно ориентирована.

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

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

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

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

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

    Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

    • #
    • #
    • #
    • #
    • #
    • #
    • #
    • #
    • #
    • #
    • #

    Содержание:

    ВВЕДЕНИЕ

    Повышение интереса к тестированию программного обеспечения пришлось на 90-е годы XX века в США. Стремительный рост систем автоматизированной разработки программного обеспечения и компьютерных сетей привел к увеличению производства программного обеспечения и к разработке подходов к обеспечению качества и надёжности разрабатываемых приложений. Рост конкуренции между создателями программного обеспечения потребовал определенного внимания к качеству производимых приложений, так как у пользователей появился выбор: разработчики предоставляли свои программы по достаточно приемлемым ценам, что позволяло обращаться к тому, кто разработает необходимый продукт не только дёшево и быстро, но и качественно[3].

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

    Анализ актуальности обусловили выбор темы исследования: «Отладка и тестирование программ: основные подходы и ограничения».

    Объектом исследования является процесс тестирования программного обеспечения.

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

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

    Для достижения поставленной цели необходимо решить следующие задачи:

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

    1. ОСНОВНЫЕ АСПЕКТЫ ТЕСТИРОВАНИЯ И ОТЛАДКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

    1.1 Понятия тестирования и отладки программного обеспечения

    Тестированием программного обеспечения (software testing) является процесс эксплуатации или анализа программного обеспечения для выявления дефектов[1].

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

    Из определения следует, что тестирование подразумевает «эксплуатацию» или «анализ» программного обеспечения. Тестирование, при котором выполняется анализ результатов разработки программного продукта, называют статическим тестированием (static testing), в которое включается проверка кода программы, сквозной контроль и проверка «за столом» (desk checks) , т.е. проверка программного продукта без запуска на компьютере. В отличие от статического тестирования, тестовая деятельность, в которой предусмотрена эксплуатация программы, называется динамическим тестированием (dynamic testing). Эти два типа тестирования дополняют друг друга, реализуя в отдельности собственный подход к определению ошибок в программе.

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

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

    Отладка – это процесс поиска того оператора программы, который вызвал ошибку вычислительного процесса и исправления найденной ошибки, обнаруженной в процессе тестирования программного обеспечения. Чтобы исправить ошибку необходимо выявить ее причину [2]. Различают следующие типы ошибок:

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

    1.2 Цели и задачи тестирования программного обеспечения

    Целями тестирования программного обеспечения являются[8]:

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

    Задачами тестирования являются:

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

    1.3 Этапы тестирования программного обеспечения

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

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

    Существуют несколько подходов при формулировании стратегии тестирования[4]:

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

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

    3. Определение условий входа и выхода на каждом этапе тестирования, определение всех точек контроля качества.

    4. Определение стратегии автоматизации при использовании автоматизации определенного вида тестовых испытаний.

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

    Можно выделить несколько рекомендаций по разработке стратегии тестирования, использование которых могут обеспечить оптимальное тестовое покрытие[7]:

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

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

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

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

    Для определения критериев тестирования и точек контроля качества перед началом системного тестирования используют следующие пять типов[6]:

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

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

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

    1.4 Комплексное тестирование программного обеспечения

    Комплексное тестирование состоит в проверке корректного согласования каждого модуля приложения с остальными его модулями. При этом могут использоваться технологии обработки снизу вверх и сверху вниз, при которых каждый модуль, в виде листа в дереве системы, интегрируется с модулями более высокого или более низкого уровня, пока не будет сформировано дерево программного продукта. Такая технология тестирования необходима для проверки как параметров, передающихся между двумя модулями, так и для проверки глобальных параметров[10].

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

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

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

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

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

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

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

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

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

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

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

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

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

    Мнения разработчиков об эффективности этих двух инкрементальных подходов тестирования разнятся[4, 9, 11]. Практически выбор стратегии тестирования производится следующим образом: все модули по возможности тестируется сразу после их создания, поэтому тестирование одних частей программы может происходить в восходящей последовательности, а других – в нисходящей.

    2. РАЗЛИЧНЫЕ ПОДХОДЫ К ТЕСТИРОВАНИЮ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

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

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

    2.2 Метод «белого ящика»

    Метод «белый ящик» состоит в том, что при создании тестовых случаев программисты используют все данные о внутренней структуре программы и её или коде. Технологии, которые применяются при тестировании методом «белого ящика» представляют собой технологии статического тестирования[8].

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

    В тестовых испытаниях методом «белого ящика» применяют управляющую логику процедур. Они выполняют следующие функции:

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

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

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

    2.3 Методы тестирования на основе стратегии «белого ящика»

    2.3.1 Ввод неверных значений

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

    2.3.2 Модульное тестирование

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

    2.3.3 Тестирование обработки ошибок

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

    2.3.4 Утечка памяти

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

    2.3.5 Комплексное тестирование

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

    2.3.6 Тестирование цепочек

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

    2.3.7 Исследование покрытия

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

    2.3.8 Покрытие решений

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

    2.3.9 Покрытие условий

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

    2.4 Метод «черного ящика»

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

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

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

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

    2.5 Методы тестирования на основе стратегии «черного ящика»

    2.5.1 Эквивалентное разбиение

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

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

    2.5.2 Анализ граничных значений

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

    2.5.3 Диаграммы причинно-следственных связей

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

    2.5.4 Системное тестирование

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

    2.5.5 Функциональное тестирование

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

    2.5.6 Регрессионное тестирование.

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

    2.5.7 Тестирование безопасности

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

    2.5.8 Тестирование перегрузок

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

    2.5.9 Тестирование производительности

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

    2.5.10 Тестирование удобства использования

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

    3. ОТЛАДКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

    3.1 Методы отладки программного обеспечения

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

    — ручного тестирования;

    — индукции;

    — дедукции;

    — обратного прослеживания.

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

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

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

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

    Рисунок 1 — Схема процесса отладки методом индукции

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

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

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

    Рисунок 2 — Схема процесса отладки методом дедукции

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

    3.2 Общая методика отладки программного обеспечения

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

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

    Если ошибка не найдена или система просто «зависла», переходят ко второму этапу.

    2 этап — локализация ошибки — определение конкретного фрагмента, при выполнении которого произошло отклонение от предполагаемого вычислительного процесса. Локализация может выполняться:

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

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

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

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

    4этап — исправление ошибки — внесение соответствующих изменений во все операторы, совместное выполнение которых привело к ошибке.

    5 этап — повторное тестирование — повторение всех тестов с начала, так как при исправлении обнаруженных ошибок часто вносят в программу новые.

    Следует иметь в виду, что процесс отладки можно существенно упростить, если следовать основным рекомендациям структурного подхода к программированию[7]:

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

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

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

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

    ЗАКЛЮЧЕНИЕ

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

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

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

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

    СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

    1. Бейзер Б. Тестирование черного ящика. Технологии функционального тестирования программного обеспечения и систем [текст] / Б. Бейзер; — Питер, 2004, 320 с. ISBN 5-94723-698-2.
    2. Брауде Э.Д. Технология разработки программного обеспечения [текст] / Э.Д. Брауде; — Питер, 2004, 656 с. ISBN 5-94723-663-X.
    3. Винниченко И.В. Автоматизация процессов тестирования [текст] / И. В. Винниченко; — Питер, 2005, 208 с. ISBN 5-469-00798-7.
    4. Канер С. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений [текст] / С. Канер; — ДиаСофт, 2001, 544 с, ISBN 966-7393-87-9.
    5. Калбертсон Р. Быстрое тестирование [текст] / Р. Калбертсон, К. Браун, Г. Кобб; — Вильямс, 2002, 384 с. ISBN 5-8459-0336-X.
    6. Коликова Т.В. Основы тестирования программного обеспечения. Учебное пособие [текст] / Т.В. Коликова, В.П. Котляров; — Интуит, 2006, — 285 с. ISBN 5-85582-186-2.
    7. Касперски К. Техника отладки программ без исходных текстов [текст] / К. Касперски; — БХВ-Петербург, 2005, 832 с. ISBN 5-94157-229-8.
    8. Макгрегор Д. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие [текст] / Д. Макгрегор, Д. Сайкс; — ТИД «ДС», 2004, 432 с. ISBN 966-7992-12-8.
    9. Плаксин М. Тестирование и отладка программ — для профессионалов будущих и настоящих [текст] / М. Пласкин; — Бином. Лаборатория знаний, 2007, — 168 с. ISBN 978-5-94774-458-3.
    10. Роберт М. Быстрая разработка программ: принципы, примеры, практика [текст] / М. Роберт, Д. Ньюкирк; — Вильямс, 2004, 752 с. ISBN 5-8459-0558-3.
    11. Фолк Д. Тестирование программного обеспечения [текст] / Д. Фолк, Е. К. Нгуен, С. Канер; — Диасофт, 2003 , 400 с. ISBN 966-7393-87-9.
    12. Элфрид Д. Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация [текст] / Элфрид Д., Джефф Р., Джон П.;- Лори, 2003, ISBN 5-85582-186-2.

    Предложите, как улучшить StudyLib

    (Для жалоб на нарушения авторских прав, используйте

    другую форму
    )

    Заполните, если хотите получить ответ

    Оцените наш проект