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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

Программа – упорядоченная последовательность команд (инструкций) компьютеру для решения задачи [12]. Конечная цель любой компьютерной программы – управление аппаратными средствами.

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

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

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

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

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

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

Различают четыре уровня программного обеспечения:

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

Основная классификация программного обеспечения представлена на рисунке 1 [20].

Рис. 1 Общая классификация программного обеспечения

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

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

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

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

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

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

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

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

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

Анализ требований

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

Проектирование

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

В рамках данного этапа стороны должны осуществить:

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

Кодирование

Следующим шагом становится непосредственная работа с кодом, опираясь на выбранный в процессе подготовки язык программирования. Описывать особенности и тонкости самого трудоемкого и сложного этапа вряд ли стоит, достаточно указать, что успех реализации любого проекта напрямую зависит от качества предварительного анализа и оценки конкурирующих решений, с которыми создаваемой программе предстоит «бороться» за право называться лучшей в своей нише. Если речь идет о написании кода для выполнения узкоспециализированных задач в рамках конкретного предприятия, то от грамотного подхода к этапу кодирования зависит эффективность работы компании, заказавшей разработку. Кодирование может происходить параллельно со следующим этапом разработки – тестированием программного обеспечения, что помогает вносить изменения непосредственно по ходу написания кода. Уровень и эффективность взаимодействия всех элементов, задействованных для выполнения сформулированных задач компанией–разработчиком, на текущем этапе является самым важным – от слаженности действий программистов, тестировщиков и проектировщиков зависит качество реализации проекта [12].

Тестирование и отладка

После достижения задуманного программистами в написанном коде следуют не менее важные этапы разработки программного обеспечения, зачастую объединяемые в одну фазу – тестирование продукта и последующая отладка, позволяющая ликвидировать огрехи программирования и добиться конечной цели – полнофункциональной работы разработанной программы. Процесс тестирования позволяет смоделировать ситуации, при которых программный продукт перестает функционировать. Отдел отладки затем локализует и исправляет обнаруженные ошибки кода, «вылизывая» его до практически идеального состояния. Эти два этапа занимают не меньше 30% затрачиваемого на весь проект времени, так как от их качественного исполнения зависит судьба созданного силами программистов программного обеспечения. Нередко функции тестировщика и отладчика исполняет один отдел, однако самым оптимальным будет распределить эти обязанности между разными исполнителями, что позволит увеличить эффективность поиска имеющихся в программном коде ошибок [8].

Внедрение

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

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

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

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

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

Конечная цель программиста заключается в написании правильно работающей программы, но, к сожалению, в 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. Аузяк, А. Г. Программирование и основы алгоритмизации: Для инженерных специальностей технических университетов и вузов. /А. Г. Аузяк, Ю. А. Богомолов, А.И. Маликов, Б.А. Старостин. Казань: Изд-во Казанского национального исследовательского технического ун-та - КАИ, 2013, 153 с. Режим доступа: http://au.kai.ru/documents/Auzyak_Progr_osn_alg_C_2013.pdf.
2. Белов, П. М. Основы алгоритмизации в информационных системах: Учебн. Пособие.- Спб.: СЗТУ, 2003. – 85с. Режим доступа: http://www.ict.edu.ru/ft/005406/nwpi225.pdf
3. Биллиг, В. А. Основы объектного программирования на C# (C# 3.0, Visual Studio 2008) / В. А. Биллиг. – М.: Интернет–университет информационных технологий, Бином. Лаборатория знаний, 2016. – 584 c.
4. Буховец, А. Г. Алгоритмы вычислительной статистики в системе R. Учебное пособие / А. Г. Буховец, П. В. Москалев. – М.: Лань, 2015. – 160 c.
5. Васильев, П. П. Турбо Паскаль в примерах и задачах / П. П. Васильев. – М.: Финансы и статистика, 2016. – 496 c.
6. Гавриков, М. М. Теоретические основы разработки и реализации языков программирования / М. М. Гавриков, А. Н. Иванченко, Д. В. Гринченков. – М.: КноРус, 2014. – 184 c.
7. Гергель, В. П. Современные языки и технологии параллельного программирования / В. П. Гергель. – М.: Издательство МГУ, 2016. – 408 c.
8. Герман, О. Программирование на Java и C# для студента / О. Герман, Ю. Герман. – М.: БХВ–Петербург, 2014. – 512 c.
9. Жданова, Т. А. Основы алгоритмизации и программирования: учеб. пособие / Т. А. Жданова, Ю. С. Бузыкова. – Хабаровск : Изд-во Тихоокеан. гос.ун-та, 2011. – 56 с. Режим доступа: http://pnu.edu.ru/media/filer_public/2013/02/25/book_basics.pdf.
10. Зыков, С. В. Введение в теорию программирования. Курс лекций. Учебное пособие / С. В. Зыков. – М.: Интернет–университет информационных технологий, 2017. – 400 c.
11. Истомин, Е. П. Информатика и программирование / Е. П. Истомин, A. M. Власовец. – М.: Андреевский Издательский дом, 2015. – 294 c.
12. Ишкова, Э. А. C#. Начала программирования / Э. А. Ишкова. – М.: Бином–Пресс, 2016. – 334 c.
13. Кадырова, Г. Р. Основы алгоритмизации и программирования: учебное пособие / Г. Р. Кадырова. – Ульяновск : УлГТУ, 2014. – 95 с. Режим доступа: http://venec.ulstu.ru/lib/disk/2014/137.pdf
14. Кетков, Ю. Л. Свободное программное обеспечение. FREE PASCAL для студентов и школьников (+ CD) / Ю.Л. Кетков, А.Ю. Кетков. – М.: БХВ–Петербург, 2017. – 376 c.
15. Культин, Н. Visual Basic для студентов и школьников / Н. Культин. – М.: БХВ–Петербург, 2017. – 354 c.
16. Макаров, В. Л. Программирование и основы алгоритмизации.: учебн. пособие / В. Л. Макаров.-Спб., СЗТУ, 2003, - 110с. Режим доступа: http://window.edu.ru/resource/126/25126/files/nwpi223.pdf
17. Медведик, В. И. Практика программирования на Паскаль. Задачи и решения. Учебное пособие / В. И. Медведик. – М.: ДМК Пресс, 2015. – 590 c.
18. Опалева, Э. А. Языки программирования и методы трансляции / Э. А. Опалева, В. П. Самойленко. – М.: БХВ–Петербург, 2015. – 480 c.
19. Павловская, Т. А. C/C++. Программирование на языке высокого уровня / Т. А. Павловская. – М.: Питер, 2016. – 464 c.
20. Павловская, Т. А. C/C++. Процедурное и объектно–ориентированное программирование. Учебник / Т. А. Павловская. – М.: Питер, 2015. – 496 c.
21. Рак, И. П. Основы алгоритмизации и программирования: Метод. указ. / Сост.: И.П. Рак, А.В. Терехов, А.В. Селезнев. Тамбов: Изд-во Тамб. гос. техн. ун-та. Режим доступа: http://www.ict.edu.ru/ft/004758/terehov.pdf.
22. Рапаков, Г. Г. Turbo Pascal для студентов и школьников / Г. Г. Рапаков, С. Ю. Ржеуцкая. – М.: БХВ–Петербург, 2017. – 352 c.
23. Санников, Е. В. Курс практического программирования в Delphi. Объектно–ориентированное программирование / Е. В. Санников. – М.: Солон–Пресс, 2015. – 188 c.
24. Семакин, И. Г. Основы программирования и баз данных. Учебник / И. Г. Семакин. – М.: Academia, 2016. – 224 c.
25. Финогенов, К. Г. Использование языка Ассемблера. Учебное пособие / К. Г. Финогенов. – М.: Горячая линия – Телеком, 2017. – 440 c.
26. Финогенов, К. Основы языка Ассемблера / К. Финогенов. – М.: Горячая Линия – Телеком, Радио и связь, 2017. – 963 c.
27. Хабибуллин, И. Программирование на языке высокого уровня. C/C++ / И. Хабибуллин. – М.: БХВ–Петербург, 2016. – 512 c.
28. Хорев, П. Б. Объектно–ориентированное программирование с примерами на С#. Учебное пособие / П. Б. Хорев. – М.: Форум, Инфра–М, 2016. – 200 c.
29. Черпаков, И. В. Основы программирования. Учебник и практикум / И. В. Черпаков. – М.: Юрайт, 2016. – 220 c.