Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Отладка и тестирование программ: основные подходы и ограничения (Основные этапы проектирования программы)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

Теоретической основой исследования выступили научные труды таких отечественных исследователей проблемы, как Герман О., Павловская Т. А., Хабибуллин И. и др.

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

Глава 1. Проектирование программы

1.1 Основные этапы проектирования программы

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

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

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

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

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

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

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

2. Анализ задачи и моделирование – определяются исходные данные и результат, выявляются ограничения на их значения, выполняется формализованное описание задачи и построение (выбор) математической модели, пригодной для решения на компьютере [20].

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

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

5. Кодирование – запись алгоритма на языке программирования. Современные системы программирования позволяют ускорить процесс разработки программы, автоматически создавая часть ее текста, однако творческая работа по–прежнему лежит на программисте. Для успешной реализации целей проекта программисту необходимо использовать методы структурного программирования [20].

6. Отладка и тестирование программы. Под отладкой понимается устранение ошибок в программе. Тестирование позволяет вести их поиск и, в конечном счете, убедиться в том, что полностью отлаженная программа дает правильный результат. Для этого разрабатывается система тестов – специально подобранных контрольных примеров с такими наборами па­раметров, для которых решение задачи известно. Тестирование должно охватывать все возможные ветвления в программе, т. е. проверять все ее инструкции, и включать такие исходные данные, для которых решение невозможно. Проверка особых, исключительных ситуаций, необходима для анализа корректности. Например, программа должна отказать клиенту банка в просьбе выдать сумму, отсутствующую на его счете. В ответственных проектах большое внимание уделяется так называемой «защите от дурака» подразумевающей устойчивость программы к неумелому обращению пользователя. Использование специальных программ – отладчиков, которые позволяют выполнять программу по отдельным шагам, просматривая при этом значения переменных, значительно упрощает этот этап [1].

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

8. Публикация результатов работы, передача заказчику для эксплуатации.

9. Сопровождение программы – включает консультации представителей заказчика по работе с программой и обучение персонала. Недостатки и ошибки, замеченные в процессе эксплуатации, должны устраняться [20].

1.2 Отладка и тестирование программы: цели и этапы

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

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

Синтаксическая ошибка. Неправильное употребление синтаксических конструкций, например употребление оператора цикла For без то или Next.

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

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

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

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

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

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

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

  1. Анализ продукта
  2. Работа с требованиями
  3. Разработка стратегии тестирования и планирование процедур контроля качества
  4. Создание тестовой документации
  5. Тестирование прототипа
  6. Основное тестирование
  7. Стабилизация
  8. Эксплуатация

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

Глава 2. Основные подходы и ограничения к отладке и тестированию программ

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

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

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

Особенности процесса тестирования программы состоят в том, что:

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

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

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

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

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

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

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

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

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

Один из вариантов этого подхода состоит в тестировании одной полной ветви программы. Первой проверяется (с использованием при необходимости заглушек) управляющая логика. Некоторые системы реализуются очередями, причем вначале, до полного тестирования программы, обрабатывается некоторое подмножество данных. Такой порядок реализации системы возможен, поскольку при разработке каждой программы нетрудно предусмотреть отдельные ветви для обработки различных данных. Это может оказаться весьма полезным, т. к. часто 10 % обрабатываемых типов данных могут на 90 % обеспечить потребности пользователей [21].

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 Отладка и тестирование программ: основные подходы и ограничения

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

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

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

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

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

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

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

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

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

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

  1. Ввод неверных значений.
  2. Модульное тестирование.
  3. Утечка памяти.
  4. Тестирование цепочек.
  5. Исследование покрытия.
  6. Покрытие решений.
  7. Покрытие условий [22].

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

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

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

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

  1. Неверная или пропущенная функциональность
  2. Ошибки интерфейса
  3. Проблемы удобства использования
  4. Методы тестирования на основе
  5. Автоматизированные инструменты
  6. Ошибки в структурах данных или ошибки доступа к внешним базам данных
  7. Проблемы снижения производительности и другие ошибки производительности
  8. Ошибки загрузки
  9. Ошибки многопользовательского доступа
  10. Ошибки инициализации и завершения
  11. Проблемы сохранения резервных копий и способности к восстановлению работы
  12. Проблемы безопасности [20].

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

  1. Эквивалентное разбиение.
  2. Системное тестирование.
  3. Тестирование безопасности.
  4. Тестирование перегрузок.
  5. Тестирование производительности.
  6. Тестирование удобства использования [3].

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

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

  1. Ручное тестирование.
  2. Прологи.
  3. Снижения.
  4. Обратная трассировка [4].

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

  1. Биллиг, В. А. Основы объектного программирования на C# (C# 3.0, Visual Studio 2008) / В. А. Биллиг. – М.: Интернет–университет информационных технологий, Бином. Лаборатория знаний, 2016. – 584 c.
  2. Буховец, А. Г. Алгоритмы вычислительной статистики в системе R. Учебное пособие / А. Г. Буховец, П. В. Москалев. – М.: Лань, 2015. – 160 c.
  3. Васильев, П. П. Турбо Паскаль в примерах и задачах / П. П. Васильев. – М.: Финансы и статистика, 2016. – 496 c.
  4. Гавриков, М. М. Теоретические основы разработки и реализации языков программирования / М. М. Гавриков, А. Н. Иванченко, Д. В. Гринченков. – М.: КноРус, 2014. – 184 c.
  5. Гергель, В. П. Современные языки и технологии параллельного программирования / В. П. Гергель. – М.: Издательство МГУ, 2016. – 408 c.
  6. Герман, О. Программирование на Java и C# для студента / О. Герман, Ю. Герман. – М.: БХВ–Петербург, 2014. – 512 c.
  7. Истомин, Е. П. Информатика и программирование / Е. П. Истомин, A. M. Власовец. – М.: Андреевский Издательский дом, 2015. – 294 c.
  8. Зыков, С. В. Введение в теорию программирования. Курс лекций. Учебное пособие / С. В. Зыков. – М.: Интернет–университет информационных технологий, 2017. – 400 c.
  9. Ишкова, Э. А. C#. Начала программирования / Э. А. Ишкова. – М.: Бином–Пресс, 2016. – 334 c.
  10. Кетков, Ю. Л. Свободное программное обеспечение. FREE PASCAL для студентов и школьников (+ CD) / Ю.Л. Кетков, А.Ю. Кетков. – М.: БХВ–Петербург, 2017. – 376 c.
  11. Культин, Н. Visual Basic для студентов и школьников / Н. Культин. – М.: БХВ–Петербург, 2017. – 354 c.
  12. Медведик, В. И. Практика программирования на Паскаль. Задачи и решения. Учебное пособие / В. И. Медведик. – М.: ДМК Пресс, 2015. – 590 c.
  13. Опалева, Э. А. Языки программирования и методы трансляции / Э. А. Опалева, В. П. Самойленко. – М.: БХВ–Петербург, 2015. – 480 c.
  14. Павловская, Т. А. C/C++. Программирование на языке высокого уровня / Т. А. Павловская. – М.: Питер, 2016. – 464 c.
  15. Павловская, Т. А. C/C++. Процедурное и объектно–ориентированное программирование. Учебник / Т. А. Павловская. – М.: Питер, 2015. – 496 c.
  16. Рапаков, Г. Г. Turbo Pascal для студентов и школьников / Г. Г. Рапаков, С. Ю. Ржеуцкая. – М.: БХВ–Петербург, 2017. – 352 c.
  17. Санников, Е. В. Курс практического программирования в Delphi. Объектно–ориентированное программирование / Е. В. Санников. – М.: Солон–Пресс, 2015. – 188 c.
  18. Семакин, И. Г. Основы программирования и баз данных. Учебник / И. Г. Семакин. – М.: Academia, 2016. – 224 c.
  19. Финогенов, К. Г. Использование языка Ассемблера. Учебное пособие / К. Г. Финогенов. – М.: Горячая линия – Телеком, 2017. – 440 c.
  20. Финогенов, К. Основы языка Ассемблера / К. Финогенов. – М.: Горячая Линия – Телеком, Радио и связь, 2017. – 963 c.
  21. Хабибуллин, И. Программирование на языке высокого уровня. C/C++ / И. Хабибуллин. – М.: БХВ–Петербург, 2016. – 512 c.
  22. Хорев, П. Б. Объектно–ориентированное программирование с примерами на С#. Учебное пособие / П. Б. Хорев. – М.: Форум, Инфра–М, 2016. – 200 c.
  23. Черпаков, И. В. Основы программирования. Учебник и практикум / И. В. Черпаков. – М.: Юрайт, 2016. – 220 c.