К основному контенту

С чего начинать: модульного, интеграционного или системного тестирования?

Продолжаем разбираться в понятиях тестирования, и в данном блоге рассмотрим классификацию «по уровню детализации приложения»: модульное, интеграционное и системное (рис.1).


Рисунок 1. Схематичное представление классификации тестирования по уровню детализации приложения
Уровни тестирования в основном предназначены для выявления недостающих областей и предотвращения дублирования и повторения между этапами жизненного цикла разработки. В моделях жизненного цикла разработки программного обеспечения существуют определенные этапы, такие как сбор и анализ требований, проектирование, кодирование или внедрение, тестирование и развертывание.  Каждая фаза проходит тестирование. 
Модульным тестированием (unit testing, module testing, component testing) в основном занимаются (хорошие, но не все=) ) разработчики, чтобы убедиться что разрабатываемая часть кода работает верно в соответствии с документацией.
Тестовый модуль является наименьшим проверяемым частью приложения , как функции, классы, процедуры, интерфейсы. 
Часто данный вид тестирования реализуется с использованием специальных технологий и инструментальных средств автоматизации тестирования, значительно упрощающих и ускоряющих разработку соответствующих тест-кейсов.
Из-за особенностей перевода на русский язык теряются нюансы степени детализации: «юнит-тестирование», как правило, направлено на тестирование атомарных участков кода, «модульное» — на тестирование классов и небольших библиотек, «компонентное» — на тестирование библиотек и структурных частей приложения.
Преимущества модульных испытаний:
1. Проблемы находятся на ранней стадии и могут быть решены сразу же, где и найдены разработчиком, не затрагивая другой код.
2. Тестирование модулей помогает поддерживать и изменять код. Это возможно, делая коды менее взаимозависимыми, чтобы можно было выполнить единичное тестирование. Следовательно, шансы на воздействие изменений на любой другой код снижаются.
3. Поскольку ошибки обнаруживаются на ранних этапах модульного тестирования, следовательно, это также помогает снизить стоимость исправлений ошибок. 
4. Тестирование модулей помогает упростить процесс отладки. Если предположить, что тест завершился неудачей, необходимо отлаживать только последние изменения, сделанные в коде.
Тестирование компонентов также называют модульным тестированием. это метод, при котором тестирование каждого компонента в приложении выполняется отдельно.  Давайте возьмем пример, чтобы лучше понять его. Предположим, что есть приложение, состоящее из трех модулей: модуль A, модуль B и модуль C. Разработчик разработал модуль B и теперь хочет его протестировать. Но для того, чтобы протестировать модуль B, лишь немногие его функции зависят от модуля A и некоторые от модуля C. Но модуль A и модуль C еще не разработаны. В этом случае, чтобы полностью протестировать модуль B, мы можем заменить модуль A и модуль C на заглушку (stubs) и драйверы по мере необходимости, имитируя интерфейс между программными компонентами простым способом.
Интеграционное тестирование. Тестирование  интеграции выполняется, когда два модуля интегрированы, чтобы проверить поведение и функциональность обоих модулей после интеграции. Ниже приведены несколько типов интеграционных тестов:
- Тестирование интеграции Big Bang
- Сверху вниз (top down)
- Снизу вверх (bottom up)
- Функциональные инкрементные
1. Тестирование интеграции компонентов выполняется после их объединения (рис 2.), взаимодействия с различными частями системы следует за двумя подходами, известными как подход «сверху вниз» и «снизу вверх» (рис.3)
Рисунок 2. Интеграция модулей
Рисунок 3. Интеграционное тестирование
Главный недостаток Big Bang заключается в том, что в целом тестирование требует много времени и трудно проследить причину сбоев из-за поздней интеграции.
2. Тестирование сверху вниз происходит, следуя потоку управления или архитектурной структуре (например, начиная с графического интерфейса или главного меню). Компоненты или системы заменяются заглушками. Ниже приведена диаграмма «Top down Approach» (рис.4):

                                                Рисунок 4. диаграмма «Top down Approach»
Недостатки подхода «сверху вниз» в том, что базовая функциональность тестируется в конце цикла.
3. Интеграционное тестирование снизу вверх происходит из нижней части потока управления вверх. Драйверы заменяются компонентами или системами (рис. 5). 

Рисунок 5. Подход интеграционного тестирование «снизу вверх».
Недостатки подхода Bottom-Up:
  • Мы можем поймать дефекты интерфейса (методов) в конце цикла
  • Требуется создать тестовые драйверы для модулей на всех уровнях, кроме верхнего управления
4. Функциональный инкремент: интеграция и тестирование происходит на основе функций и функциональных возможностей, как описано в функциональной спецификации.
Системное тестирование направлено на проверку всего приложения как единого целого, собранного из частей, проверенных на двух предыдущих стадиях. Здесь не только выявляются дефекты «на стыках» компонентов, но и появляется возможность полноценно взаимодействовать с приложением с точки зрения конечного пользователя, применяя множество других видов тестирования.
Так с чего же начинать? Каждый решает сам. Но! Если вам необходим качественный продукт с самых ранних стадий его разработки, то лучше всего начинать с модульного тестирования, и не забывать также и про другие уровни тестирования.

Комментарии

Популярные сообщения из этого блога

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н...

Тест план и тестовая модель - что это?

Test Plan (тест план)  — это документ или совокупность документов, расписывающих всю тестовую активность (цели, подходы, ресурсы и график запланированных тестовых активностей)  в пределах одного проекта, все работы проводимые командой тестирования или одним тестировщиком. В стандарте IEEE 829 перечислены пункты, из которых должен состоять тест-план:   1) Test plan identifier (идентификатор);   2) Introduction (описание/цель) - Предельно краткое описание цели разработки приложения (частично это напоминает бизнес-требования);   3) Features to be tested (Области, подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые будут подвергнуты тестированию. В некоторых случаях здесь также приводится приоритет соответствующей области. 4) Features not to be tested (Области, не подвергаемые тестированию) - Перечень функций и/или нефункциональных особенностей приложения, которые не будут по...

Советы для молодых тестировщиков или как составлять тест - кейс =)

Тест (test) представляет собой набор операций, предназначенных для получения одного или большего числа ожидаемых результатов в некоторой программной системе. Тест-кейсы должен помочь тестировщику (даже начинающему) провести проверку продукта без ознакомления со всей документацией. В тест – кейсе желательно избегать зависимостей от других тест – кейсов. Тест кейс в основном состоит из * Основных параметров - id (номер) - уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге). - Автор – имя и фамилия тестировщика, который написал тест – кей. - Название — краткое описание сути проверки. - Предусловие – предварительные шаги. - Шаги – что нужно сделать, чтобы что-то получить. - Ожидаемый результат – тот результат, который соответствует документации или здравому смыслу =). - Фактический результат – то, что получилось в итоге действия в шаге. - Постусловия ...