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

Последнее утверждение имеет два слабых пункта: во-первых, число не повторяющих друг друга маршрутов — астрономическое; во-вторых, даже если каждый маршрут может быть проверен, сама программа может содержать ошибки (например, некоторые маршруты пропущены).

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

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

1.3 Сравнение методов тестирования

Рассмотрим с позиций надежности программного обеспечении стратегии тестирования и сравним их по семи критериям (табл.1 ).

Таблица 1

Качественная оценка подхода к сборке

Итак. Первый критерий - время до момента сборки модулей, - это является важным при обнаружении ошибок в сопряжениях и предположениях модулей о свойствах друг друга.

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

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

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

Шестой критерий связан с ответом на вопрос: возможно ли проверить любой конкретный путь и любое условие в программе?

Седьмой критерий характеризует сложность планирования, надзора и управления в процессе тестирования.

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

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

Сложность подготовки заглушек, планирования и управления последовательностью тестов также важны, они получают вес 2.

Третий критерий, необходимость драйверов - вес 1 ввиду доступности общих инструментов тестирования.

Критерий, связанный с параллелизмом работы, имеет вес 1 (он может быть важен по другим причинам, но на надежность сильно не влияет).

Шестой критерий - вес 3.

Седьмой критерий получает вес 2.

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

Таблица 2

Взвешенная оценка подхода к сборке

Глава 2 Отладка программ

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

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

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

После того, как программные модули были успешно оттранслированы, размещены по конкретным адресам и связаны между собой, для отладки программы можно воспользоваться любым из следующих методов^[3]:

• внутрисхемным эмулятором
• встроенным программным отладчиком
• внешним программным отладчиком
• отлаживаемым устройством с записанным в память программ двоичным кодом программы

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

Рисунок 2. Пример системы отладки программного обеспечения для микроконтроллеров

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

При использовании интегрированной среды программирования предоставляется удобный интерфейс, позволяющий легко отлаживать разрабатываемую программу. В настоящее время стандартом де-факто стал интерфейс, похожий на программную оболочку Visual C. Пример внешнего вида такой программной оболочки приведён на рисунке 3.

Рисунок 3. Пример внешнего вида отладчика интегрированной системы отладки программного обеспечения

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

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

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

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

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

Успешность отладки программного средства в немаловажной степени предопределена рациональной и правильной организацией тестирования.

В процессе отладки программного средства можно отыскать и устранить обычно ошибки, которые появляются в программном средстве при тестировании.^[4] Конечно, процесс тестирования не имеет возможности подтвердить правильность программного средства, максимум что оно может – продемонстрировать что ошибки здесь присутствуют. Вывод: нет никакой гарантии, что в процессе тестирования программного средства на практике выполнимым комплексом тестов в том, что станет возможным установить присутствие каждой имеющейся в программном средстве ошибки.

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

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