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

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

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

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

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

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

Таблица 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 2

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

Глава 2 Понятие, методы, принципы и заповеди программ

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

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

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

Наиболее распространенными и наименее эффективными для отладки являются так называемые методы ‘грубой силы’. К ним относят:

1)отладку с использованием дампа памяти;

2)отладку с использованием операторов печати по всей программе;

3)отладку с использованием автоматических средств: наиболее предпочтительно.

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

1. Метод индукции: он включает

1)определение данных тестирования, имеющих отношение к ошибке;

2)анализ от частного к общему позволит выявить закономерности в данных пункта 1);

3)в результате анализа (п.2) выдвигается гипотеза о причине ошибки;

4)для подтверждения гипотезы 3 разрабатывается один или больше тестов, которые должны либо подтвердить, либо опровергнуть гипотезу;

5)если дополнительные тесты подтверждают гипотезу, можно приступать к исправлению ошибки, а вот если не подтверждают, то требуется в лучшем случае возврат к п.3, а в худшем - к п.2.

2.Альтернативный метод дедукции заключается в:

1)перечисление возможных причин или гипотез

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

4)доказательство выбранной гипотезы совпадает с п.4 и п.5 метода индукции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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