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

Задача проектировщика системы сделать цену проникновения более высокой, чем цена полученной информации.

1. Стрессовые тесты.

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

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

1. Тестирование производительности.

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

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

1. Методы тестирования и отладки программного обеспечения
   1. Восходящее тестирование

Восходящее тестирование – метод тестирования аппаратных и программных средств, при котором проверка начинается с самых простых элементов или частей программы.

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

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

Шаги методики восходящего тестирования интеграции:

1. Модули нижнего уровня объединяются в так называемые кластеры (группы, блоки), выполняющие определенную программную подфункцию.
2. Для координации ввода/вывода тестового варианта пишется драйвер, управляющей тестированием кластеров.
3. Тестируется кластер.
4. Драйверы тестирования удаляются, а кластеры объединяются в структуру движения вверх.

---

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

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

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

Признаки критического модуля:

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

Критические модули должны тестироваться, как можно, раньше. Кроме того, к ним рекомендуется применять регрессионное тестирование, то есть повторять уже выполненные тесты в полном или частичном объеме.

• 1. Нисходящее тестирование

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

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

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

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

---

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

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

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

Возможные шаги процесса нисходящей интеграции:

1. Главный управляющий модуль, находящийся на вершине иерархии, используется как тестовый драйвер. Все подчиненные ему модули замещаются заглушками.
2. Одна из заглушек заменяется реальным модулем. Этот модуль выбирается поиском в глубину или в ширину.
3. После подключения каждого модуля и установки на нем заглушек проводится набор тестов, проверяющих полученную структуру.
4. Если в модуле-драйвере уже нет заглушек, производится смена модуля-драйвера поиском в ширину или в глубину.
5. Выполняется возврат на шаг два до тех пор, пока не будет протестирована вся структура.

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

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

Существует три пути борьбы с этим недостатком:

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

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

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

---

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

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

Модифицированный метод сандвича.

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

• 1. Метод тестирования «черного ящика»

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

1. набор, образуемый входными данными, который приводит к аномалиям поведения программы;
2. набор, образуемый такими входными данными, которые демонстрируют дефекты программы.

Любой способ тестирования черного ящика должен:

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

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

---

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

Тестирование черного ящика обеспечивает поиск следующих категорий ошибок:

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

Подобная категория ошибок не позволяет выявить тестирование белого ящика.

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

Технология тестирования черного ящика ориентирована на решение следующих задач:

1. Сокращение необходимого количества тестовых вариантов из-за проверки нестатических, а динамических аспектов системы;
2. Выявление классов ошибок, а не отдельных ошибок.
   1. Тестирование методом «белого ящика»

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

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

Недостатки тестирования белого ящика:

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

Достоинства тестирования белого ящика позволяют учесть особенности программных ошибок.

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

---