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

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

Семантика языка – это система правил истолкования построений конструкций.

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

1. Синтаксические ошибки.

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

1. Семантические ошибки.

Семантические (смысловые) ошибки — это применение операторов, которые не дают нужного эффекта, ошибка в структуре алгоритма, в логической взаи­мосвязи его частей, в применении алгоритма к тем данным, к которым он неприменим и т.д. Правила семантики не фор­мализуемы. Поэтому поиск и устранение семантической ошибки и составляет основу отладки.

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

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

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

1. Стратегия тестирования и отладки программного обеспечения

   1. Тестирование элементов

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

---

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

Тестированию подвергаются:

1. Интерфейс модуля;
2. Внутренняя структура данных;
3. Независимые пути;
4. Пути обработки ошибок;
5. Ограниченные условия;

Интерфейс модуля тестируется для проверки правильности ввода/вывода тестовой информации. Исследование внутренних структур данных гарантирует целостность сохраняемых данных. Тестирование независимых путей гарантирует однократное выполнение всех операторов модуля.

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

Наиболее общими ошибками вычислений являются:

1. Неправильный или неопределенный приоритет арифметических операций;
2. Некорректная инициализация;
3. Несогласованность представления и точности;
4. Некорректное символьное представление выражений;

Источником ошибок сравнения и неправильных потоков управления являются:

1. Сравнение данных различных типов;
2. Некорректные логические операции или их приоритеты;
3. Ожидание эквивалентности в условиях, когда ошибки точности делают эквивалентность невозможной;
4. Неправильное прекращение цикла;
5. Отказ в выходе из цикла при прекращении итераций;
6. Неправильное изменение элементов цикла;

Обычно при проектировании модуля предвидят некоторые ошибочные условия. Для защиты от ошибочных условий в модуль вводят пути обработки ошибок. Такие пути тоже должны тестироваться.

Тестирование путей обработки ошибок необходимо ориентировать на следующие ситуации:

1. сообщение об ошибке невразумительно;
2. текст сообщения не соответствует обнаруживаемой ошибке;
3. вмешательство системных средств, регистрация ошибки произошла до обработки ошибки в модуле;
4. обработка исключительного условия некорректна;
5. описание ошибки не позволяет определить ее причину.

Часто необходимо выполнять граничное тестирование модулей, поскольку ошибки часто происходят:

1. при обработке n-ого элемента массива из n элементов;
2. при выполнении m-ой итерации цикла с m-проходами;
3. при появлении минимального или максимального значения.

Тестовые варианты, ориентированные на данные варианты, имеют высокую вероятность обнаружения ошибок.

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

---

Дополнительными средствами тестирования является драйвер тестирования и заглушки.

Драйвер – это управляющая программа, которая принимает исходные данные и ожидаемые результаты тестовых вариантов, запускает тестируемый модуль, получает из модуля реальные результаты и на основе сравнения ОР и РР формирует отчет о результатах тестирования.

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

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

• 1. Тестирование итераций

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

Категории ошибок интерфейса:

1. потеря данных при прохождении через интерфейс;
2. отсутствие в модуле необходимой ссылки;
3. неправильное влияние одного модуля на другой;
4. подфункции при объединении не образуют требуемую главную функцию;
5. отдельные допустимые неточности при интеграции выходят за допустимый уровень;
6. возникают проблемы при работе с глобальными структурами данных.

Существует два варианта тестирования, поддерживающих процессы интеграции:

1. нисходящее тестирование (см. п. 2.1);
2. восходящее тестирование (см. п. 2.1).
   1. Тестирование правильности

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

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

---

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

1. Системная спецификация;
2. План программного проекта;
3. Спецификация требований к программной системе и работающий или бумажный макет;
4. Предварительное руководство пользователя;
5. Спецификация проектирования;
6. Листинги исходных текстов программ;
7. Плановая методика тестирования;
8. Руководство по работе;
9. Исполняемый код программы;
10. Описание базы данных;
11. Руководство пользователя по настройке;
12. Документы сопровождения;
13. Отчеты о проблемах программной системы;
14. Отчеты о конструкторских изменениях;

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

Разработчик не может предугадать, как заказчик будет реально использовать программную систему. Для обнаружения ошибок, которые может найти только конечный пользователь, используют процесс, включающий «Альфа» – тестирование и «Бета» –тестирование.

«Альфа» –тестирование – тестирование проводится заказчиком в организации разработчика. Разработчик фиксирует все выявляемые заказчиком ошибки и проблемы использования программной системы.

«Бета» –тестирование – тестирование проводится конечным пользователем в организации заказчика. Разработчик в этом процессе участия не принимает.

Фактически «Бета» –тестирование – это реальное применение программной системы в среде, которая не управляется разработчиком. Заказчик сам записывает все обнаруженные проблемы и сообщает о них разработчику.

«Бета»–тестирование проводится в течение фиксированного срока, обычно, около года. По результатам выявленных проблем разработчик изменяет программную систему и тем самым подготавливает полностью программный продукт к использованию в организации заказчика.

• 1. Системное тестирование

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

---

1. Предусмотреть средства обработки ошибок, которые тестируют все виды информации из других элементов системы;
2. Провести тесты, моделирующие неудачные данные или другие потенциальные ошибки интерфейса программной системы;
3. Записать результаты тестов, чтобы использовать их в качестве доказательства невиновности;
4. Надо принять участие в планировании и проектировании системных тестов, чтобы гарантировать адекватное тестирование программной системы;

В конечном счете, системные тесты должны проверить, что все системные элементы правильно объединены и выполняют назначенные функции.

Основные типы системных тестов:

1. Тестирование установления.

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

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

1. Тестирование безопасности.

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

При неограниченном времени и ресурсах хорошее тестирование безопасности взломает любую систему.

---