Отладка ПС — это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Тестирование ПС — это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом.
Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами:
Отладка = Тестирование + Поиск ошибок + Редактирование
Тестирование — процесс многократного повторения программы с целью обнаружения ошибок. Тестирование — составная часть отладки.
Отладка имеет место тогда, когда программа со всей очевидностью работает неправильно. Поэтому отладка начинается всегда в предвидении отказа программы. Если же оказывается, что программа работает верно, то она тестируется. Часто случается так, что после прогона тестов программа вновь подвергается отладке.
Форт Боярд | Сезон 2 | Выпуск 1
Таким образом, тестирование устанавливает факт наличия ошибки, а отладка выявляет ее причину. Основная цель выделения отладки и тестирования как отдельных этапов создания программы заключается в том, чтобы обратить внимание обязательности обеих стадий и на необходимость специального планирования временных затрат по каждой из них в отдельности.
Нельзя гарантировать, что тестированием можно установить наличие каждой имеющейся в ПС ошибки. Поэтому возникает две задачи. Первая задача — подготовить такой набор тестов и применить к ним ПС, чтобы обнаружить в нем по возможности большее число ошибок. Однако чем дольше продолжается процесс тестирования (и отладки в целом), тем большей становится стоимость ПС.
Отсюда вторая задача — определить момент окончания отладки ПС (или отдельной его компоненты). Признаком возможности окончания отладки является полнота охвата тестами, пропущенными через ПС множества различных ситуаций, возникающих при выполнении программ ПС, и относительно редкое проявление ошибок с учетом требуемой степени надежности ПС, указанной в спецификации его качества.
Каждый тест определяет:
- • свой набор исходных данных и условий для запуска программы;
- • набор ожидаемых результатов работы программы.
Полную проверку программы гарантирует исчерпывающее тестирование. Оно требует проверить все наборы исходных данных, все варианты их обработки и включает большое количество тестовых вариантов, но такое тестирование не всегда возможно из-за ограниченных временных ресурсов.
Хорошим считают тестовый вариант с высокой вероятностью обнаружения ошибки. Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.
Не дрогни! | Выпуск 1
- • обнаружение ошибок;
- • демонстрацию соответствия функций программы ее назначению;
- • демонстрацию реализации требований к характеристикам программы;
- • отображение надежности как индикатора качества программы.
Тем не менее, тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов). Информационные потоки процесса тестирования показаны на рисунке 4.3.
На входе процесса тестирования три потока:
- • текст программы;
- • исходные данные для запуска программы;
- • ожидаемые результаты.
Выполняются тесты, все полученные результаты оцениваются и сравниваются с ожидаемыми результатами. Когда обнаруживается несовпадение, фиксируется ошибка — начинается отладка. Процесс отладки непредсказуем по времени. На поиск места дефекта и исправление может потребоваться час, день, месяц. Неопределенность в отладке приводит к большим трудностям в планировании действий.
Рисунок 4.3 — Информационные потоки процесса тестирования
После сбора и оценивания результатов тестирования начинается оценка качества и надежности ПО. Если регулярно встречаются серьезные ошибки, требующие проектных изменений, то качество и надежность ПО считаются неудовлетворительными, и возникает необходимость в продолжении тестирования. Если функции ПО реализованы правильно, а обнаруженные ошибки легко исправляются, может быть сделан один из двух выводов:
- • качество и надежность ПО удовлетворительны;
- • тесты не способны обнаруживать серьезные ошибки.
В конечном счете, если тесты не обнаруживают ошибок, появляется сомнение в том, что тестовые варианты достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки в дальнейшем будут обнаруживаться пользователями и корректироваться разработчиками на этапе сопровождения (когда стоимость исправления возрастает в 60-100 раз по сравнению с этапом разработки).
Результаты, накопленные в ходе тестирования, могут оцениваться формальными способами. Для этого используют модели надежности ПО, выполняющие прогноз надежности по реальным данным об интенсивности ошибок.
Источник: bstudy.net
Испытания программного средства
Испытания являются одним из самых важных моментов при создании программного продукта, потому что благодаря им, видно как лучше организовать работу программы и ее интерфейс. Целью проведения испытания программного продукта является проверка правильности работы программы, выявление противоречий между разработанной системой и первоначальными целями ее создания и выявление возможных ошибок при работе с программой. Также в ходе тестирования программы производится проверка на соответствие техническим требованиям, то есть испытания производятся на нескольких компьютерах различной конфигурации.
Назначение испытаний
После разработки необходимо провести испытание работоспособности программного продукта. Целью проводимых испытаний является:
— выявление возможных ошибок (математических или логических) в работе алгоритма программы для дальнейшего их исправления;
— проверка реакции программы на ввод разных значений (в том числе заведомо неправильных);
— проверка интерфейса программы на удобство пользования конечным пользователем;
— определение времени загрузки и времени формирования отчетов;
— определение минимальных аппаратно-программных требований для обеспечения работы программы;
— выявление выполнения всех требований, установленных при постановке задачи.
Программа и методика испытаний
Программа испытаний состоит из следующих пунктов:
— Проверка инфологической модели базы данных на ошибки и избыточность в таблицах;
— Проверка работы алгоритма программы;
— Проверка исходного кода программы на наличие синтаксических ошибок языка программирования;
— Проверка работы всех кнопок в окнах программы;
— Тестирование программы на компьютерах с разными техническими характеристиками и определение времени загрузки на каждом из них.
Работа программы проверялась на компьютере, технические характеристики которого приведены в пункте, касающемся выбора аппаратных средств разработки. Дополнительно тестирование проводилось на компьютере со следующими характеристиками: процессор AMD Athlon 1200 МГц, оперативная память 128 Mб, операционная система Windows 2000.
Результаты испытаний
В процессе испытаний не было выявлено ошибок в работе логической и математической структур программы. Все модули программы выполняют свои функции.
На компьютерах, где проводилось тестирование, загрузка длится чуть дольше (5 секунды). Это может быть объяснено меньшим количеством оперативной памяти. На компьютере с процессором AMD Athlon 600 загрузка происходит за 6 секунды, т.к. практически все его характеристики намного меньше характеристик выше описанных машин.
Поиск нужной информации и формирование отчетов происходит практически мгновенно на более мощных компьютерах, а машина с процессором AMD Athlon 600 опять же проигрывает в скорости.
Скорость распечатывания документов и отчетов зависит от модели используемого принтера.
В результате проведенных испытаний были определены следующие требования к программному и аппаратному обеспечению:
— процессор не слабее AMD Athlon c частотой 1200 МГц или другой с аналогичными характеристиками;
— оперативная память 128 Мб;
— цветной монитор с поддерживаемым разрешением не ниже 800х600 точек;
— принтер для вывода на печать отчетов;
— операционная система Windows 2000 или более поздние версии.
Необходимый объем жесткого диска зависит от объема базы данных. При увеличении числа записей может потребоваться дополнительное свободное место.
В целом в ходе проведения испытаний программного продукта существенных ошибок обнаружено не было. Потребовалось только скорректировать расположение управляющих элементов для более удобного пользования ими.
Результаты и методы испытания программного продукта приведены в таблице 1.
Таблица 1 — Результаты и методы испытания программы
Проверка совместимости с различными операционными системами
Проверка работоспособности программного продукта в
различных версиях операционных систем от Microsoft (98,2000,XP), проверка работоспособности всех предусмотренных функций программы
Программа работает без каких-либо нареканий в её сторону во всех выбранных для тестирования операционных системах
Экстренное завершение работы операционной системы
Во время ввода различной информации в программу произведено экстренное выключение компьютера
После перезагрузки компьютера, данные в программе не потеряны
Добавление новых данных в каждой форме
В процессе работы программы используя соответствующие окна добавлены новые данные во все таблицы
Добавление данных происходит без каких-либо замечаний
Редактирование уже введенных данных
Используя все формы, на каждой из них изменены данные
Все проделанные операции выполнены успешно
Завершение работы программы
Произведен выход из программы
Программа завершила свою работу успешно
Источник: studbooks.net
Тестирование (испытание) программ
4.5.1. Итак, целью тестирования, по определению предыдущего пункта, является диагностика всех потенциальных причин нарушений (сбоев) работы программы. Более же категорично [21]: «тестирование- это процесс выполнения программы с намерением найти ошибки». Хотя оно и способствует повышению надежности ПО, его значение ограничено, так как последняя определяется качеством проектирования и разработки на всех стадиях и этапах.
В подходе к тестированию возможны две крайних точки зрения. Одна из них заключается в том, что проектирование тестов основано исключительно на основе спецификаций программ или модулей, которые рассматриваются как «черные ящики». Цель, которая ставится при этом, заключается в проверке всех возможных комбинаций и значений данных на входе и результатов на выходе.
Содержание тестирования во втором случае базируется только на логике программы, когда идеалом считается проверка всех возможных ветвей и путей алгоритма. Эта цель практически является недостижимой, кроме того, она не гарантирует соответствия ПО его спецификациям. Если программа не реализует по какой-либо причине одну из своих функций (например, проверку знака аргумента логарифма), то тестирование всех путей не имеет смысла. В действительности, для испытания программы необходимо совместное использование как ее логики, так и спецификаций.
4.5.2. Модульно-иерархическая структура ПО ИС, минимизирующая его объемные характеристики, значительно упрощает проблему тестирования. В связи с тем, что взаимодействие модулей ограничивается передачей параметров, тестирование программы, скомпонованной из них, легче, чем такой же по величине монолитной.
Использование оптимальных по объему модулей, как показано выше, уменьшает вероятность возникновения ошибок при внесении изменений. Но самое главное, с точки зрения проблемы тестирования, становится обозримой связь между спецификацией и логикой фрагментов ПО, так как модуль, как правило, реализует одну функцию. Цель тестирования — найти несоответствие между его логикой и сопряжениями, с одной стороны, и внешними спецификациями (функцией, входными и выходными данными), с другой.
Для анализа автономного тестирования модуля используются диаграммы управления: ориентированные графы, изображающие структуру ветвлений в программе. Каждая вершина графа (кружок) представляет собой линейный участок (последовательность операторов между точками ветвления), а дуги графа — связи между ними. Чтобы оценить трудоемкость тестирования модуля, Мак-Кейб [22] предложил использовать подсчет базисных маршрутов в его управляющем графе. Комбинируя их, можно получить всю совокупность путей от входа программы к ее выходу. Каждый базисный маршрут, называемый еще линейно независимым, отличается от остальных хотя бы одной вершиной или дугой. Показано, что количество базисных маршрутов равно цик- ломатическому числу 2 управляющего графа программы:
где пп — полное количество вершин, а У — количество связывающих их дуг. При этом вычисление 2 производится для графа, образуемого из исходного замыканием дугой его конечной (выхода программы) и начальной вершин. В результате этого в графе появляются маршруты между любыми двумя вершинами. Для примера (заимствован из [18]) рассмотрим граф некоторой программы, представленной на рис. 5.
Здесь пп = 14, У = 21 (с дополнительной дугой, обозначенной пунктиром) и 1 = 21 — 14 + 1 = 8.
Далее на рис. 6 представлены все восемь базисных маршрутов.
Установлено, что объем программы V и ее цикломатическая мера сложности I сильно коррелируют [22].
В структурированных программах Z может быть определено без построения управляющего графа путем подсчета в тексте предикатов, т. е. простых логических выражений (условий выбора маршрута), которые образуют вершины , где происходит ветвление вычислительного процесса:
Граф программы, как известно, можно описать матрицей смежности размером пп х ^, в которой единица располагается на позиции (/,/), если из вершины / можно за один шаг перейти к вершине /,
в противном случае ставится ноль. В свою очередь, маршруты в алгоритме характеризуются матрицей достижимости, в которой на позиции (/, у) помещается единица, если из /’ можно перейти в у за любое число шагов. Описание структуры программ этими матрицами позволяет автоматизировать оценку цикломатической сложности. Разработаны алгоритмы, формирующие матрицу смежности и затем матрицу достижимости, по которым можно в поисковой форме автоматически выделить цикломатические матрицы исполнения программы, представить их в распечатанном виде для контроля и планирования отладки [18].
На основе большого количества опытных данных установлено, что при 2 >8 надежность программ начинает быстро ухудшаться. Этот факт также объясняется с позиций закона Миллера « 7 ± 2 ».
4.5.3. Способ и последовательность сборки ПО ИС из автономных модулей определяет не только порядок их программирования, но и метод тестирования. При способе «снизу-вверх» изолированно тестируются только модули самого нижнего уровня; затем — более высокого, но уже совместно с первыми.
Процесс повторяется до тех пор, пока не будет завершено написание всей программы, т. е. пока не будет достигнута вершина. На этом завершается и тестирование модулей, и тестирование сопряжений. При таком подходе для каждого модуля необходимо писать драйвер.
Однако существуют коммерчески доступные программы их отладки, позволяющие описывать тесты на специальном языке и избавляющие программистов от такой необходимости. При нисходящем подходе программа собирается и тестируется «сверху-вниз». Автономно тестируется только головной модуль; затем совместно с ним те, которые им последовательно вызываются. Так продолжается до тех пор, пока не будет собрана вся программа. В случае физического отсутствия вызываемых модулей (более низкого уровня) пишутся «заглушки», имитирующие их функции.
Одно из основных достоинств этого метода заключается в совмещении тестирования модуля, его сопряжений и частично внешних спецификаций. Он выгоден также тогда, когда существует сомнение в осуществимости ПО ИС в целом: в этом случае риск непроизводительных затрат по созданию модулей нижнего уровня устраняется до начала их программирования.
Однако разработка и тестирование «сверху-вниз» имеет и недостатки, один из которых заключается в следующем. Проектирование и разработка больших и средних ПО ИС носит итеративный характер. По окончании работ по созданию нижнего уровня, как правило, возникает необходимость в коррекции, иногда серьезной, верхних уровней. Однако если к этому времени головная часть программы уже готова, то возникает сопротивление любому ее изменению. Поэтому раннее программирование теряет смысл.
Наконец, возможен, главным образом для небольших («прозрачных») систем, еще один подход: все модули тестируются автономно и предъявляются на сборку одновременно.
Выбор любого из этих подходов обусловлен настолько большим числом факторов, что однозначные рекомендации просто невозможны.
Источник: studref.com