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

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

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

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

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

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

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

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

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

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

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

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

Комплексная же отладка предполагает тестирование программного средства в общем при помощи нахождения и исправления зафиксированных в процессе тестирования ошибок уже во всех документах, даже в текстах программ программного средства, которые относятся к программному средству в целом.

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

2.3 Заповеди отладки программного средства

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

Ниже приведены рекомендации по организации отладки в форме заповедей.

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты, как для правильных, так и для неправильных данных.

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

Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Заключение

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

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

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

Никогда не делайте вывода, что программа правильна, лишь на том основании, что она не отвергнута машиной, полностью транслирована и выдала численные результаты. Ведь все, что достигнуто в данном случае,— это получение некой выходной информации, не обязательно правильной. В программе все еще может оставаться большое количество логических ошибок, а между тем задача, которая ставится при написании программы, — это не просто получение ответов, но получение правильных ответов. Поэтому обычно бывает необходима “(ручная” проверка машинных результатов. После того как отладка полностью завершена, даже в программе опытного программиста существует примерно одна ошибка на 20—30 написанных: операторов. Эти ошибки могут быть как катастрофическими по своим последствиям, так и незначительными и могут быть связаны как с неправильным алгоритмом, так и с несущественными ошибками кодирования. Таким образом, отлаженная программа — это программа, для которой просто не нашлось подходящего набора тестовых данных, чтобы привести ее к отказу.