Ўзбекистон республикаси ахборот технологиялари ва коммуникацияларини ривожлантириш вазирлиги муҳаммад ал-хоразмий номидаги

Нисходящее тестирование
предполагает, что процесс интеграционного тестирования 
движется следом за разработкой. Сначала при нисходящем подходе тестируют только самый 
верхний управляющий уровень системы, без модулей более низкого уровня. Затем 
постепенно с более высокоуровневыми модулями интегрируются более низкоуровневые. В 
результате применения такого метода отпадает необходимость в драйверах (роль драйвера 
выполняет более высокоуровневый модуль системы), однако сохраняется нужда в заглушках 
(Рис. 20). 
Модуль 1
Заглушки
Модуль 1
Модуль 2
Модуль 3
Заглушки
Заглушки
Модуль 1
Модуль 2
Модуль 3
Заглушки
Заглушки
Модуль 4
Модуль 5
Заглушки
Рис. 20 Постепенная интеграция модулей при нисходящем методе тестирования 
У разных специалистов в области тестирования разные мнения по поводу того, какой из 
методов более удобен при реальном тестировании программных систем. Йордан доказывает, 
что нисходящее тестирование наиболее приемлемо в реальных ситуациях [27], а Майерс 
полагает, что каждый из подходов имеет свои достоинства и недостатки, но в целом 
восходящий метод лучше [28]. 

---

153 
В литературе часто упоминается метод интеграционного тестирования объектно-
ориентированных программных систем, основанный на выделении кластеров классов, 
имеющих вместе некоторую замкнутую и законченную функциональность [10]. По своей 
сути такой подход не является новым типом интеграционного тестирования, просто меняется 
минимальный элемент, получаемый в результате интеграции. При интеграции модулей на 
процедурных языках программирования можно интегрировать любое количество модулей 
при условии разработки заглушек. При интеграции классов в кластеры существует 
достаточно нестрогое ограничение на законченность функциональности кластера. Однако, 
даже в случае объектно-ориентированных систем возможно интегрировать любое 
количество классов при помощи классов-заглушек. 
Вне зависимости от применяемого метода интеграционного тестирования, необходимо 
учитывать степень покрытия интеграционными тестами функциональности системы. В 
работе [17] был предложен способ оценки степени покрытия, основанный на управляющих 
вызовах между функциями и потоках данных. При такой оценки код всех модулей на 
структурной диаграмме системы должен быть выполнен (должны быть покрыты все узлы), 
все вызовы должны быть выполнены хотя бы раз (должны быть покрыты все связи между 
узлами на структурной диаграмме), все последовательности вызовов должны быть 
выполнены хотя бы один раз (все пути на структурной диаграмме должны быть покрыты) 
[10].