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

Введение
Сегодня многие программисты и организации занимаются прикладным и системным программированием и созданием программного обеспечения для постоянно растущих потребностей пользователей. При этом значительная часть временных и финансовых ресурсов тратится на отладку и тестирование создаваемых ими приложений. Но тем не менее, несмотря на колоссальные затраты, конечный продукт очень часто вызывает много претензий у пользователя, и проблема качества продукта говорит нам о несомненной важности процессов отладки и тестирования программ на сегодняшний день. Более правильным будет определить процесс тестирования и отладки как - завершающий этап создания программного продукта, который заключается в выполнении программы с целью выявления сбоев и ошибок программного кода. Вместо того, чтобы гарантировать отсутствие ошибок в новой программе, разумней будет хотя бы продемонстрировать их наличие. Если приложение корректно работает при выполнении множества различных тестов, это придает некоторую уверенность, но еще не гарантирует отсутствие в ней ошибок. Это лишь показывает, что нам пока неизвестно, в каких случаях программа может дать сбой. Получается «парадокс тестирования». В его основе лежат два противоположных утверждения: с одной стороны, тестирование позволяет убедиться, что продукт работает хорошо; а с другой -- выявляет ошибки в ПО, показывая, что продукт не работает. Вторая цель тестирования является более продуктивной с точки зрения улучшения качества, так как не позволяет игнорировать недостатки ПО.1. Понятие отладки программных средствОтладка ПС - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами:Отладка = Тестирование + Поиск ошибок + Редактирование.Отладка не является разновидностью тестирования, хотя слова «отладка» и «тестирование» часто используют как синонимы. Под ними подразумеваются разные виды деятельности:тестирование — деятельность, направленная на обнаружение ошибок;отладка направлена на установление точной природы известной ошибки, а затем - на исправление этой ошибки;результаты тестирования являются исходными данными для отладки.Эти два вида деятельности очень тесно связаны и поэтому они обычно рассматриваются совместно.В результате отладки программное обеспечение должно соответствовать определенной фиксированной совокупности правил и показателей качества, принимаемой для него за эталонную. Иными словами, отладка — это этап разработки, на котором устраняются недостатки только что созданного программного обеспечения.Основная задача отладки в целом состоит в завершении разработки всего программного обеспечения и в доведении его характеристик до значений, заданных требованиями технического задания (соглашения о требованиях). При этом ПО должно гарантированно удовлетворять всем требованиям не только в диапазоне типичных условий его функционирования, но и при предельных, критических сочетаниях значений всех параметров. Это обеспечивает надежность функционирования ПО при разнообразных произвольных, в том числе, искаженных сочетаниях исходных данных.По оценкам специалистов, в общем, времени разработки программного обеспечения, отладка занимает от 50 % до 90% (зависит от результатов проведения предыдущих этапов).Отладку можно разделить на синтаксическую и семантическую.Отладка синтаксиса обычно не вызывает трудностей и требует только аккуратности. Результаты синтаксически правильной программы сравниваются с тестовыми, их несовпадение является признаком наличия семантической ошибки. Это сравнение надо выполнять очень скрупулезно: даже лишний пробел между двумя значениями может дать ключ к поиску ошибки.В отличие от синтаксической ошибки, семантическая ошибка не формализуемаи поэтому она составляет основу отладки.Отладка готовой части (ветви) программного обеспечения может быть начата ранее, чем будет написан весь программный продукт, в результате чего сокращается время разработки ПО, т.е. экономится календарное время его разработки. Временно отсутствующие блоки либо оставляются пустыми, либо заменяются печатью сообщения о том, что программное обеспечение не рассчитано на такие данные, или пишутся временные программные заглушки.Системная отладка предназначена для проверки соответствия логической схемы комплекса программ ее функциональному назначению с использованием специально подготовленных массивов и в условиях, моделирующих процесс функционирования АСУ. В процессе системной отладки устраняется большинство сложных алгоритмических и системных ошибок. Общее число выявляемых в процессе системной отладки ошибок определяется ограничениями на временные и стоимостные ресурсы и исходным количеством ошибок в комплексе программ, поступающем на этап системной отладки. При достижении выбранного уровня показателей качества системной отладки комплекс программ передается в опытную эксплуатацию для проверки его функционирования с использованием реальных полноразмерных массивов и в реальном масштабе времени.Обнаружение ошибок в программах на этапе эксплуатации системы может привести к существенным потерям времени и средств на их устранение, а в отдельных случаях к потере работоспособности системы. Поэтому с целью повышения качества комплексов программ, поступающих в эксплуатацию, необходимо улучшить планирование и организацию отладки, что позволит в конечном счете повысить эффективность функционирования АСУ за счет снижения затрат, связанных с наличием необнаруженных ошибок и получением недостоверных результатов; уменьшения времени и затрат на устранение и выявление ошибок; уменьшения вероятности наличия ошибок в программах.Качество комплекса программ, поступающего на этап отладки, определяется в основном эффективностью методов проектирования и программирования, которые используются при его разработке. Использование модульно-иерархического построения программ с применением принципов структурного программирования позволяет существенно снизить сложность компонентов и их взаимодействия, упростить общее координирование компонентов, повысить адаптивность и модернизируемость комплекса программ, минимизировать пути распространения ошибок за счет минимизации или ограничения числа связей между модулями и, таким образом, повысить качество создаваемого программного обеспечения.2. Принципы и виды отладки программного средстваУспех отладки ПС в значительной степени предопределяет рациональная организация тестирования. При отладке ПС отыскиваются и устраняются, в основном, те ошибки, наличие которых в ПС устанавливается при тестировании. Как было уже отмечено, тестирование не может доказать правильность ПС, в лучшем случае оно может продемонстрировать наличие в нем ошибки. Другими словами, нельзя гарантировать, что тестированием ПС практически выполнимым набором тестов можно установить наличие каждой имеющейся в ПС ошибки. Поэтому возникает две задачи. Первая задача: подготовить такой набор тестов и применить к ним ПС, чтобы обнаружить в нем по возможности большее число ошибок. Однако, чем дольше продолжается процесс тестирования (и отладки в целом), тем большей становится стоимость ПС. Отсюда вторая задача: определить момент окончания отладки ПС (или отдельной его компоненты). Признаком возможности окончания отладки является полнота охвата пропущенными через ПС тестами (т.е. тестами, к которым применено ПС) множества различных ситуаций, возникающих при выполнении программ ПС, и относительно редкое проявление ошибок в ПС на последнем отрезке процесса тестирования. Последнее определяется в соответствии с требуемой степенью надежности ПС, указанной в спецификации его качества.Для оптимизации набора тестов, т.е. для подготовки такого набора тестов, который позволял бы при заданном их числе (или при заданном интервале времени, отведенном на тестирование) обнаруживать большее число ошибок в ПС, необходимо, во-первых, заранее планировать этот набор и, во-вторых, использовать рациональную стратегию планирования тестов. Проектирование тестов можно начинать сразу же после завершения этапа внешнего описания ПС. Возможны разные подходы к выработке стратегии проектирования тестов, которые можно условно графически разместить между следующими двумя крайними подходами. Левый крайний подход заключается в том, что тесты проектируются только на основании изучения спецификаций ПС (внешнего описания, описания архитектуры и спецификации модулей). Строение модулей при этом никак не учитывается, т.е. они рассматриваются как черные ящики. Фактически такой подход требует полного перебора всех наборов входных данных, так как в противном случае некоторые участки программ ПС могут не работать при пропуске любого теста, а это значит, что содержащиеся в них ошибки не будут проявляться. Однако тестирование ПС полным множеством наборов входных данных практически неосуществимо. Правый крайний подход заключается в том, что тесты проектируются на основании изучения текстов программ с целью протестировать все пути выполнения каждой программ ПС. Если принять во внимание наличие в программах циклов с переменным числом повторений, то различных путей выполнения программ ПС может оказаться также чрезвычайно много, так что их тестирование также будет практически неосуществимо.Оптимальная стратегия проектирования тестов расположена внутри интервала между этими крайними подходами, но ближе к левому краю. Она включает проектирование значительной части тестов по спецификациям, но она требует также проектирования некоторых тестов и по текстам программ. При этом в первом случае эта стратегия базируется на принципах:на каждую используемую функцию или возможность - хотя бы один тест,на каждую область и на каждую границу изменения какой-либо входной величины - хотя бы один тест,на каждую особую (исключительную) ситуацию, указанную в спецификациях, - хотя бы один тест.Во втором случае эта стратегия базируется на принципе: каждая команда каждой программы ПС должна проработать хотя бы на одном тесте.Оптимальную стратегию проектирования тестов можно конкретизировать на основании следующего принципа: для каждого программного документа (включая тексты программ), входящего в состав ПС, должны проектироваться свои тесты с целью выявления в нем ошибок. Во всяком случае, этот принцип необходимо соблюдать в соответствии с определением ПС и содержанием понятия технологии программирования как технологии разработки надежных ПС. В связи с этим Майерс даже определяет разные виды тестирования в зависимости от вида программного документа, на основании которого строятся тесты. В нашей стране различаются два основных вида отладки (включая тестирование): автономную и комплексную отладку ПС. Автономная отладка ПС означает последовательное раздельное тестирование различных частей программ, входящих в ПС, с поиском и исправлением в них фиксируемых при тестировании ошибок. Она фактически включает отладку каждого программного модуля и отладку сопряжения модулей. Комплексная отладка означает тестирование ПС в целом с поиском и исправлением фиксируемых при тестировании ошибок во всех документах (включая тексты программ ПС), относящихся к ПС в целом. К таким документам относятся определение требований к ПС, спецификация качества ПС, функциональная спецификация ПС, описание архитектуры ПС и тексты программ ПС.3. Методы отладки программного обеспеченияОтладка программы так или иначе принимает рассмотрение и логическое решение доступной информации о ошибках. Большая часть ошибок может быть узнана к косвенным знакам посредством тщательного анализа текстов программ и результатов тестирования, не получая дополнительной информации. Таким образом используйте различные методы: Ручное тестирование; Прологи; Снижения; Обратная трассировка. Метод ручного тестирования. Это - самый простой и естественный метод данной группы. В обнаружении ошибок необходимо выполнить протестированную программу вручную, используя коммутируемый тест, работой, с которой была узнана ошибка. Метод очень эффективен, но не применим для больших программ, программ с трудными расчетами и когда ошибка соединяется с неправильным представлением компании-производителя телевизионных программ о производительности некоторых операций. Данный метод часто использует в качестве компонента других методов устранения неисправностей. Метод пролога. Метод основан на тщательном анализе симптомов Ошибки, которую можно показать, как неправильные результаты расчетов или как сообщение об ошибке. Если компьютер просто "зависает", фрагмент дисплея Ошибки вычисляют, происхождение последних полученных результатов и движений потребителя. Информация, полученная таким образом, организует и осторожно учится, просматривая адекватный фрагмент программы. В результате этих гипотез усовершенствования движений о погрешностях, каждая из которых проверяют. Если гипотеза - истина, детализируйте информацию о Ошибки, по-другому - совершенствуют другую гипотезу. Самый ответственный этап - укладка текста симптомов Ошибки. Организуя о Ошибки, все - способ, чтобы записать данные, которые известны о его дисплеях, и фиксируйте, как местоположения, в которых фрагмент с ошибкаю обычно выполняется, и местоположения, в которых показывают ошибка. Если в результате изучения о данном какие-либо гипотезы не появляются, дополнительная информация о Ошибки необходима. Дополнительная информация может быть получена, например, в результате производительности подобных тестов. В ходе попытки доказательства очиститься, объясняются ли все дисплеи Ошибки данной гипотезой, если не все или гипотеза не истина, или Ошибки - некоторые. Метод снижения. На методе снижения в начинающемся наборе формы причин, которые могли вызвать данный дисплей Ошибки. Затем анализ причин, что противоречит доступным данным, отщепляет. Если все причины отщепляются, необходимо выполнить дополнительное тестирование исследуемого фрагмента. Иначе самая вероятная попытка гипотезы доказать. Если гипотеза объясняет полученные знаки Ошибки, ошибка находится, по-другому - проверяют следующую причину. Метод обратной трассировки. Для малых программ эффективно приложение метода обратной трассировки. Начните с точки вывода неправильного результата. Для этой точки находится в работе гипотеза о значениях основных переменных, которые могли привести к получению доступного результата. Далее, происхождение этой гипотезы, сделайте предложения о значениях переменных в предыдущей точке.Наиболее разработанными методами обнаружения ошибок на этапе отладки являются: формальное доказательство правильности программ; методы Диверсионного программирования; методы тестирования программ.Формальное доказательство правильности программ основано на анализе исполняемых программой действий и состоит в доказательстве того, что утверждения на выходе программы будут удовлетворяться при любом разрешенном входе. Среди методов этого класса можно выделить аксиоматическое доказательство правильности, доказательство правильноети с использованием аннотаций, которые представляют собой утверждения, связанные с каждым принципиальным узлом программы, доказательство корректности программных свойств.В общем случае доказательство корректности составления программных модулей - очень сложная процедура. Для доказательства корректности программного модуля объемом около 100 инструкций требуется один человеко-месяц работы.Основными ограничениями широкого использования методов формального доказательства правильности являются сложность формализации условий в программах, отсутствие развитых языков утверждений для программ с разнообразными типами данных, наличие ошибок в данных, большое число ограничений на семантику языков и работу компилятора и тл. Кроме того, доказательство правильности может подтвердить правильность только действительно верных программ. Вместе с тем после проведения формального доказательства правильности нельзя утверждать, что программа всегда будет выполняться верно. Применение методов формального доказательства правильности программ в настоящее время ограничивается небольшими и несложными программами.Методы N-версионного программирования, получившие развитие в последнее время, являются в определенном смысле аналогами методов резервирования, применяемых в технических системах. При использовании этих методов ресурсы на проведение отладки минимальны. Создается несколько версий программы каждая из которых допускает наличие некоторого числа ошибок. Правильность функционирования набора версий достигается за счет их совместного использования. При этом используется одна из двух стратегий: резервная программа включается в работу при обнаружении ошибки; выбирается верное решение параллельно работающих программ. Согласованным функционированием программ управляет программа-супервизор, а версии программ разрабатываются различными программистами. Программные спецификации при использовании данного метода должны составляться таким образом, чтобы в различных версиях программы использовались различные структуры и приемы программирования.Однако в настоящее время не существует методики формирования соответствующих спецификаций и оценки эффективности метода N-версионного программирования. Следует отметить, что N-версионное программирование не применимо в системах реального времени с жестким ограничением ресурсов, в задачах с большими объемами выходных данных, а также в тех задачах, где трудно определить допустимую разницу результатов, получаемых различными версиями программы.Метод тестирования программ является основным методом отладки. Тестирование обеспечивает проверку того, что постановка задачи правильно понята системщиками и программистами, обеспечивает конкретное доказательство возможности получения решения, по крайней мере, части задачи, концентрирует внимание на небольшом числе наиболее сложных процедур обработки данных и причинах появления ошибок. Тестирование есть процесс оценки степени готовности модулей программного обеспечения к передаче в режим эксплуатации, основанный на сборе и анализе данных о характеристике поведения программного обеспечения по результатам его реализации в известных условиях для заданных входов (тестов).При отладке комплексов программ различают методы статистического и детерминированного тестирования.При статистическом тестировании характеристики тестов описываются некоторыми распределениями или статистическими параметрами, а признаком ошибки является отклонение параметров или законов распределения выходных данных от ожидаемых. Статистическое тестирование применяется в основном для определения надежностных характеристик комплекса программ на этапе опытной эксплуатации, так как не несет в себе информации для локализации и устранения ошибок, а характеризует только их наличие.При использовании методов детерминированного тестирования важнейшим вопросом на этапе отладки является выбор модели исследуемого комплекса программ и степени ее детализации. В качестве модели программы используют ее блок-схему, причем наибольшей степени детализации моделирования соответствует использование в качестве блока оператора программы, наименьшей – всей программы. 
Заключение
В большей степени успешность отладки программного продукта зависит от правильной и рациональной организации его тестирования. Во время отладки программы фиксируются и исправляются, как правило, лишь ошибки, обнаруженные ранее при тестировании продукта. При тестировании не ставится цель доказывать правильность и оптимальность приложения, оно служит для того, чтобы показать наличие в любом программном продукте ошибок и дефектов. Никто не может дать гарантию, что при тестировании программы каким-либо набором тестов можно обнаружить все ошибки в программном обеспечении. Отсюда и необходимость проведения тестирования и отладки, в ходе которых необходимо решить две основных задачи. Отладка является самым трудным и ответственным этапом проектирования программного обеспечения; так было всегда, так, наверное, и будет еще долго. Ошибки встречаются в любых приложениях, и в коммерческих, и в тех продуктах, что лежат в свободном доступе на рынке. Мы все привыкли к тому, что спустя некоторое время после выхода программы на рынок выходят всевозможные патчи с исправлениями, то есть небольшие утилиты, исправляющие ошибки в программе. Поскольку отладка является важнейшей стадией проектирования приложений, то учитывать это нужно уже с самого начала его разработки.
Список использованных источников
Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки программного обеспечения. М.: ИД "ФОРУМ" - ИНФРА-М, 2016. - 400с .Керниган, Брайан Практика программирования / Брайан Керниган , Роб Пайк. - М.: Вильямс, 2015. - 288 c.Касперски, Крис Техника отладки программ без исходных текстов / Крис Касперски. - М.: БХВ-Петербург, 2015. - 165 c.Майерс, Гленфорд Искусство тестирования программ / Гленфорд Майерс , Том Баджетт , Кори Сандлер. - М.: Вильямс, 2016. - 272 c.Рэшка, Дж. Тестирование программного обеспечения / Дж. Рэшка. - М.: ЛОРИ, 2013. - 291 c.Фаулер, Мартин . Улучшение существующего кода / Мартин Фаулер. - М.: Символ-плюс, 2018. - 432 c.