Отладка и тестирование приложений в среде Visual Studio 2005. Евсеева О.Н - 62 стр.

UptoLike

Составители: 

62
модули (а именно, спецификацию интерфейса), в то время как ошибки в алго-
ритме обработки параметров довольно легко обнаруживаются.
Являясь по способу исполнения структурным тестированием или тести-
рованием «белого ящика», модульное тестирование характеризуется степенью,
в которой тесты выполняют или покрывают логику программы (исходный
текст). Тесты, связанные со структурным тестированием, строятся по следую-
щим принципам:
На основе анализа потока управления. В этом случае элементы, которые
должны быть покрыты при прохождении тестов, определяются на основе
структурных критериев тестирования С0, С1, С2. К ним относятся вершины,
дуги, пути управляющего графа программы (УГП), условия, комбинации
условий и т. п.
На основе анализа потока данных, когда элементы, которые должны быть
покрыты, определяются на основе потока данных, т. е. информационного
графа программы.
4.1.1. Тестирование на основе потока управления
Особенности использования структурных критериев тестирования С0,
С1, С2 были рассмотрены в разделе 3. К ним следует добавить критерий по-
крытия условий, заключающийся в покрытии всех логических (булевских) ус-
ловий в программе. Критерии покрытия решений (ветвейС1) и условий не
заменяют друг друга, поэтому на практике используется комбинированный
критерий покрытия условий/решений, совмещающий требования по покрытию
и решений, и условий.
К популярным критериям относятся критерий покрытия функций про-
граммы, согласно которому каждая функция программы должна быть вызвана
хотя бы один раз, и критерий покрытия вызовов, согласно которому каждый
вызов каждой функции в программе должен быть осуществлен хотя бы один
раз. Критерий покрытия вызовов известен также как критерий покрытия пар
вызовов (call pair coverage).
4.1.2. Тестирование на основе потока данных
Этот вид тестирования направлен на выявление ссылок на неинициализи-
рованные переменные и избыточные присваивания (аномалий потока данных).
Как основа для стратегии тестирования поток данных впервые был описан в
1976 году [14]. Предложенная еще тогда стратегия требовала тестирования всех
взаимосвязей, включающих в себя ссылку (использование) и определение пе-
ременной, на которую указывает ссылка (т. е. требуется покрытие дуг инфор-
мационного графа программы). Недостаток стратегии в том, что она не включа-
ет критерий С1 и не гарантирует покрытия решений.
Стратегия требуемых пар [4] также тестирует упомянутые взаимосвязи.
Использование переменной в предикате дублируется в соответствии с числом