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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 4. Подходы к проектированию тестов

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

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

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

- применять на каждую использованную функцию либо возможность хотя бы один тест;

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

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

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

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