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

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

Сложность отладки ПО.

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

Методы поиска и устранения ошибок.

1. С помощью средств среды разработки (все современные средства разработки, такие как Delphi, Builder или Visual Studio поддерживают механизмы точек остановки, просмотра промежуточных значений данных, пошаговое выполнение, замер производительности).

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

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

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

44. Понятие качества программного обеспечения. Составляющие и критерии качества. Обеспечение качества как процесс, а не этап. Международный стандарт ISO 9000/9001.

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

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

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

Задачи тестирования программного обеспечения. Тестирование как процесс, а не этап. Тестирование модулей, интерфейсов, сборки. Нисходящее и восходящее тестирование. Метрики тестирования и окончание тестирования.

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

Каждый тест определяет: 1). свой набор исходных данных и условий для запуска, программы; 2). набор ожидаемых результатов работы программы.

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

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

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

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

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

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

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

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

Метрики и окончания тестирования.

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

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

46. Основы тестирования программного обеспечения методом «чёрный ящик» (функциональное тестирование). Роль прецедентов в функциональном тестировании.

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

Основное место приложения тестов «черного ящика» -интерфейс ПО.

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

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

Тестирование «черного ящика» обеспечивает поиск следующих категорий ошибок:

1) некорректных или отсутствующих функций;

2) ошибок интерфейса;

3) ошибок во внешних структурах данных или в доступе к внешней базе данных;

4) ошибок характеристик (необходимая емкость памяти и т. д.);

5) ошибок инициализации и завершения;

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

Техника «черного ящика» ориентирована на решение следующих задач:

· сокращение необходимого количества тестовых вариантов (из-за проверки не статических, а динамических аспектов системы);

· выявление классов ошибок, а не отдельных ошибок.

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

47. Основы тестирования программного обеспечения методом «белый ящик» (структурное тестирование).

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

Известна: внутренняя структура программы. Исследуются: внутренние элементы программы и связи между ними.

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

В этом случае формируются тестовые варианты, в которых:

· гарантируется проверка всех независимых маршрутов программы;

· проходятся ветви True, False для всех логических решений;

· выполняются все циклы (в пределах их границ и диапазонов);

· анализируется правильность внутренних структур данных.

(+)учесть особенности программных ошибок: 1) Количество ошибок минимально в «центре» и максимально на «периферии» программы. 2) Предварительные предположения о вероятности потока управления или данных в программе часто бывают некорректны. В результате типовым может стать маршрут, модель вычислений по которому проработана слабо. 3) При записи алгоритма ПО в виде текста на языке программирования возможно внесение типовых ошибок трансляции (синтаксических и семантических). 4) Некоторые результаты в программе зависят не от исходных данных, а от внутренних состояний программы.

(–): 1). Количество независимых маршрутов может быть очень велико. 2). Исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней. 3). В программе могут быть пропущены некоторые маршруты. 4). Нельзя обнаружить ошибки, появление которых зависит от обрабатываемых данных.