Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
[2 курс] Программная инженерия.docx
Скачиваний:
9
Добавлен:
20.08.2020
Размер:
47.85 Кб
Скачать

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

Отладка ПС – деятельность, направленная на обнаружение и исправление ошибок с использованием процессов выполнения его программ.

Тестирование ПС – процесс выполнения программ на некотором наборе данных, для которого заранее известен результат либо правило поведения программы. Набор соответствующих данных называется тестом или тестовым набором.

Таким образом отладку можно представить в виде многократного повторения 3х процессов:

  1. Тестирование. В результате может быть констатирование наличие ошибки, также место ошибки.

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

  3. Редактирование. Процесс исправления ошибок.

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

  1. Подготовка такого набора тестов, чтобы можно было обнаружить максимальное количество ошибок.

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

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

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

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

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

  3. На каждую исключительную ситуацию, указанную в спецификации, хотя бы один тест.

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

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

  1. Автономная отладка – это тестирование только одной части программы. Она включает в себя отдельную отладку каждого модуля, а также отладку с сопряжением модулей.

  2. Комплексная отладка – это тестирование программного средства в целом, а также в сопровождающихся документах.

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

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

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

Существует 6 правил по организации отладки ПС.

  1. Тестирование – ключевая задача разработки ПС, поэтому поручается наиболее квалифицированным программистам. Не желательно тестировать свою собственную программу.

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

  3. Необходимо готовить тесты как для правильных, так и для неправильных данных.

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

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

  6. Необходимо пропускать все тесты заново, если в программу были внесены изменения.