Методика тестирования программных систем

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

На втором шаге выполняется тестирование интеграции, ориентированное на выявление ошибок этапа проектирования программной системы.

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

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

Рисунок 16– Методика тестирования программной системы

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

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

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

Практический ответ обычно основан на статистическом критерии, который заключается в следующем. Можно с 95% уверенностью сказать, что провели достаточное тестирование, если вероятность безотказной работы компьютера с программной системой в течение 1000 часов составляет 0,995.

Научный ответ на этот вопрос состоит в применении математической модели отказов.

Например, для логарифмической модели Пуассона формула расчета текущей интенсивности отказа имеет вид , где

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

–начальная интенсивность отказа, т.е. интенсивность отказа на момент тестирования.

p – экспоненциальное уменьшение интенсивности отказа за счет обнаружения и устранения ошибок.

t – время тестирования.

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

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

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

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

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

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. при появлении минимального или максимального значения.

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

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

Программная среда для тестирования модуля будет выглядеть следующим образом:

Рисунок 17– Программная среда для тестирования модуля

ИД – исходные данные.

ОР – ожидаемые результаты.

РР – реальные результаты.

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

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

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

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