Инкрементное тестирование

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

Содержание

• Что такое инкрементное тестирование
• Пример инкрементного подхода к интеграционному тестированию
• Цели инкрементного тестирования
• Методологии инкрементного интеграционного тестирования
  • Метод сверху вниз
  • Метод снизу вверх
  • Сэндвич-тестирование
• Заключение

Что такое инкрементное тестирование

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

Этот вид тестирования сочетает в себе стратегию модульного и интеграционного тестирования.

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

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

Как и при интеграционном тестировании, основное внимание при инкрементном тестировании уделяется проверке программного интерфейса, ссылок для интеграции и потока информации между модулями. Этот процесс повторяется до тех пор, пока модули не будут объединены и успешно протестированы.

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Пример инкрементного подхода к интеграционному тестированию

Давайте разберем, что собой представляет инкрементное тестирование, на примере.

У нас есть система, состоящая из следующих модулей:

• Каждый модуль, т.е. M1, M2, M3 и т.д., тестируется отдельно в рамках модульного тестирования.
• Модули объединяются инкрементально, т.е. один за другим, и тестируются на успешное взаимодействие.
• На рис. 2 модуль M1 и модуль M2 объединены и протестированы.
• На рис. 3 добавлен и протестирован модуль M3.
• На рис. 4 добавлен модуль M4 и проведено тестирование, чтобы убедиться, что вместе все работает успешно.
• Остальные модули также добавляются постепенно на каждом этапе и тестируются на успешную интеграцию.

Цели инкрементного тестирования

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

Методологии инкрементного интеграционного тестирования

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

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

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

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

Вопрос, который может возникнуть у некоторых из нас: почему бы не подождать, пока не будут готовы все модули приложения, вместо того чтобы использовать заглушки/драйверы перед началом тестирования?

Ответ прост: это увеличивает время реализации проекта, поскольку, пока все модули не будут разработаны, тестировщики будут сидеть без дела. Кроме того, это затрудняет анализ локализации дефектов. Но такой подход к тестированию тоже применяется, это Big-Bang Integration testing (тестирование методом “Большого взрыва”).

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

Метод “сверху вниз”

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

Этот подход соответствует структурному потоку тестируемого приложения. Недоступные или не разработанные модули или компоненты заменяются заглушками.

Рассмотрим пример:

• Модуль L: Вход на сайт
• Модуль O: Заказ
  • Модуль OS: Формирование заказа (еще не разработан)
• Модуль P: Оплата
  • Модуль CP: Наличный платеж
  • Модуль DP: Дебетовый/Кредитный платеж (еще не разработан)
  • Модуль WP: Платеж через кошелек (еще не разработан)
• Модуль R: Отчетность (еще не разработан)

Инкрементное интеграционное тестирование сверху вниз

Будут разработаны следующие тест-кейсы:

1. Модуль L и модуль O будут интегрированы и протестированы
2. Модули L, O и P будут интегрированы и протестированы
3. Модули L, O, P и R будут интегрированы и протестированы.

Этот тип тестирования, при котором сначала интегрируются и тестируются все модули на одном уровне, известен как “breadth-first” (“сначала в ширину”). Другой тип – “depth-first” (“сначала в глубину”).

Для “depth-first” будут разработаны следующие тест-кейсы:

1. Модуль L и модуль O будут интегрированы и протестированы.
2. Модули L, O и OS будут интегрированы и протестированы
3. Модули L, O, OS, P будут интегрированы и протестированы
4. Модули L, O, OS, P, CP будут интегрированы и протестированы.

И так далее.

Достоинства методологии “сверху вниз”

• Раннее выявление дефектов архитектуры.
• Описывает работу приложения в целом на более ранних стадиях и помогает в раннем выявлении дефектов проектирования.
• Тестирование основных функций на ранних стадиях.

Недостатки методологии “сверху вниз”

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

Метод “снизу вверх”

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

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

Модули Rank, Marks, Percentage и Sports Grade еще не готовы, поэтому они будут заменены соответствующими драйверами:

Инкрементное интеграционное тестирование “сверху вниз”

Будут разработаны следующие тест-кейсы:

1. Unit-тестирование модуля Practical и Theory
2. Интеграция и тестирование модулей Marks-Practical -Theory
3. Интеграция и тестирование модулей Percentage-Marks-Practical -Theory
4. Unit-тестирование модуля Sports Grade
5. Интеграция и тестирование модулей Rank-Sports Grade-Percentage-Marks-Practical-Theory

Достоинства методологии “снизу вверх”

• Эта методология очень полезна для приложений, где используется модель проектирования снизу вверх.
• При подходе “снизу вверх” легче создавать тест-кейсы.
• Начало тестирования на нижнем уровне означает, что тестирование критических модулей или функций происходит на ранней стадии. Это помогает в раннем обнаружении дефектов.
• Дефекты интерфейса обнаруживаются на ранней стадии.

Недостатки методологии “снизу вверх”

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

Сэндвич-тестирование

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

Подход к тестированию

• Определяется средний слой, на котором проводится тестирование “снизу вверх” и “сверху вниз”. Этот средний слой также известен как целевой слой.
• Целевой слой определяется в соответствии с эвристическим подходом, т.е. выбирается тот, который позволяет минимально использовать заглушки и драйверы.
• Тестирование “сверху вниз” начинается со среднего слоя и движется вниз к модулям нижнего уровня. Слой модулей, расположенных ниже среднего, так и называется – нижний слой.
• Тестирование “снизу вверх” также начинается со среднего слоя и движется вверх к модулям верхнего уровня. Слой над средним слоем известен как верхний слой.
• С помощью заглушек и драйверов тестируются пользовательский интерфейс и функции модулей нижнего уровня.
• В итоге для выполнения финального теста остается только средний слой.

Рассмотрим пример:

Следующие тест-кейсы разработаны с помощью стратегии сэндвич-тестирования:

1. Тестирование A, X, Y и Z по отдельности – где тестирование A относится к проверкам верхнего слоя, а тестирования X, Y и Z относятся к проверкам нижнего слоя
2. Тестирование A, G, H и I
3. Тестирование G, X и Y
4. Тестирование H и Z
5. Тестирование A, G, H, I, X, Y и Z

Достоинства метода сэндвич-тестирования

• Это очень эффективно для большого проекта, который имеет различные подпроекты
• Методологии тестирования “сверху вниз” и “снизу вверх” могут работать одновременно

Недостатки метода сэндвич-тестирования

• Перед объединением модулей подсистемы и их интерфейсы не тестируются тщательно
• Более высокая стоимость из-за привлечения как методологии сверху вниз, так и методологии снизу вверх
• Этот тип тестирования не рекомендуется для систем, в которых модули сильно зависят друг от друга

Заключение

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

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

Все три методологии инкрементного тестирования относятся к категории горизонтальных из-за следующих поведенческих аспектов:

• Все три методологии фокусируются на тестировании слоев
• Все они рассматривают структурный или иерархический дизайн
• Все они интегрируют слои инкрементально

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

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

Перевод статьи Neha B. «What is Incremental Testing: Detailed Explanation With Examples».