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

Внедрение

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

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

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

---