Продолжаем
разбираться в понятиях тестирования, и в данном блоге рассмотрим классификацию
«по уровню детализации приложения»: модульное, интеграционное и системное (рис.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. Функциональный инкремент: интеграция
и тестирование происходит на основе функций и функциональных возможностей, как
описано в функциональной спецификации.
Системное тестирование направлено на проверку всего приложения как единого
целого, собранного из частей, проверенных на двух предыдущих стадиях. Здесь не
только выявляются дефекты «на стыках» компонентов, но и появляется возможность
полноценно взаимодействовать с приложением с точки зрения конечного
пользователя, применяя множество других видов тестирования.
Так с чего же начинать? Каждый решает сам. Но! Если
вам необходим качественный продукт с самых ранних стадий его разработки, то
лучше всего начинать с модульного тестирования, и не забывать также и про
другие уровни тестирования.
Комментарии
Отправить комментарий