Интеграционное тестирование

20.2.2. Временная классификация методов интеграционного тестирования

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

В рамках этой классификации выделяют:

• тестирование с поздней интеграцией;
• тестирование с постоянной интеграцией;
• тестирование с регулярной или послойной интеграцией.

Тестирование с поздней интеграцией - практически полный аналог монолитного тестирования. Интеграционное тестирование при такой схеме откладывается на как можно более поздние сроки проекта. Этот подход оправдан в том случае, если система является конгломератом слабо связанных между собой модулей, которые взаимодействуют по какому-либо стандартному интерфейсу, определенному вне проекта (например, в случае, если система состоит из отдельных Web-сервисов). Схематично тестирование с поздней интеграцией может быть изображено в виде цепочки R-C-V-R-C-V-R-C-V-I-R-C-V-R-C-V-I, где R - разработка требований на отдельный модуль, C - разработка программного кода, V - тестирование модуля, I - интеграционное тестирование всего, что было сделано раньше.

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

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

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

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

20.2.3. Планирование интеграционного тестирования

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

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

Составляется интеграционный тест-план, например, кластерного типа [10, 20], в котором для каждого кластера из интегрированных модулей определяется следующее:

• кластеры, от которых зависит данный кластер;
• кластеры, которые должны быть протестированы до тестирования данного кластера;
• описание функциональности тестируемого кластера;
• список модулей в кластере;
• описание тестовых примеров для проверки кластера;

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