- Модульное тестирование vs Интеграционное тестирование vs Функциональное тестирование
- Что такое модульное тестирование?
- Что такое интеграционное тестирование?
- Модульное тестирование и интеграционное тестирование
- Функциональное тестирование
- Заключение
- Рекомендуемое чтение
Подробное сравнение модульного, интеграционного и функционального тестирования:
Для любого программного приложения очень важно как модульное тестирование, так и интеграционное тестирование, поскольку каждое из них использует уникальный процесс для тестирования программного приложения.
Но ни один из них или даже оба не могут заменить функциональное тестирование.
Модульное тестирование vs Интеграционное тестирование vs Функциональное тестирование
Модульное тестирование означает тестирование отдельных модулей приложения в изоляции (без взаимодействия с зависимостями) для подтверждения того, что код работает правильно.
Интеграционное тестирование означает проверку работоспособности различных модулей при объединении их в группу.
Функциональное тестирование означает тестирование фрагмента функциональности в системе (может взаимодействовать с зависимостями) для подтверждения того, что код выполняет правильные действия.
Функциональные тесты связаны с интеграционными тестами, однако они означают тесты, которые проверяют функциональность всего приложения, когда весь код работает вместе, почти супер интеграционный тест.
Единичное тестирование рассматривает проверку отдельного компонента системы, в то время как функциональное тестирование рассматривает проверку работы приложения в соответствии с предполагаемой функциональностью, описанной в спецификации требований к системе. С другой стороны, интеграционное тестирование рассматривает проверку интегрированных модулей в системе.
И, самое главное, для оптимизации возврата инвестиций (ROI) ваша кодовая база должна содержать как можно больше модульных тестов, меньше интеграционных тестов и наименьшее количество функциональных тестов.
Лучше всего это иллюстрирует следующая тестовая пирамида:
Модульные тесты легче написать и быстрее выполнить. Время и усилия по внедрению и поддержке тестов увеличиваются от модульного тестирования к функциональному, как показано в приведенной выше пирамиде.
Пример:
Давайте разберемся в этих трех типах тестирования на слишком упрощенном примере.
Например Для функционального мобильного телефона необходимы следующие основные части: "аккумулятор" и "sim-карта".
Пример модульного тестирования - Батарея проверяется на срок службы, емкость и другие параметры. Сим-карта проверяется на активацию.
Пример интеграционного тестирования - Аккумулятор и sim-карта интегрированы, т.е. собраны воедино, чтобы запустить мобильный телефон.
Пример функционального тестирования - Функциональность мобильного телефона проверяется с точки зрения его возможностей и использования аккумулятора, а также возможностей sim-карты.
Мы рассмотрели пример на обычном языке.
Теперь давайте рассмотрим технический пример страницы входа в систему:
Почти каждое веб-приложение требует от своих пользователей/клиентов входа в систему. Для этого каждое приложение должно иметь страницу "Вход", которая содержит следующие элементы:
- Учетная запись/Имя пользователя
- Пароль
- Кнопка входа/входа в систему
Для модульного тестирования в качестве тестовых случаев могут выступать следующие:
- Длина поля - поля имени пользователя и пароля.
- Значения полей ввода должны быть действительными.
- Кнопка входа в систему активируется только после ввода правильных значений (Формат и длина) в оба поля.
Для интеграционного тестирования в качестве тестовых случаев могут выступать следующие:
- После ввода правильных значений и нажатия кнопки входа пользователь видит приветственное сообщение.
- Пользователь должен быть переведен на страницу приветствия или главную страницу после правильного ввода и нажатия кнопки Войти.
Теперь, после проведения модульного и интеграционного тестирования, давайте посмотрим на дополнительные тестовые случаи, которые рассматриваются для функционального тестирования:
- Проверяется ожидаемое поведение, т.е. может ли пользователь войти в систему, нажав на кнопку входа после ввода правильного имени пользователя и пароля.
- Есть ли приветственное сообщение, которое должно появиться после успешного входа в систему?
- Есть ли сообщение об ошибке, которое должно появляться при неправильном входе в систему?
- Сохраняются ли куки сайта для полей входа в систему?
- Может ли инактивированный пользователь войти в систему?
- Есть ли ссылка "забыл пароль" для пользователей, которые забыли свои пароли?
Таких случаев, которые приходят в голову функциональному тестировщику при выполнении функционального тестирования, гораздо больше. Но разработчик не может учесть все случаи при создании юнит- и интеграционных тестов.
Таким образом, существует множество сценариев, которые еще предстоит протестировать даже после модульного и интеграционного тестирования.
Теперь пришло время рассмотреть модульное, интеграционное и функциональное тестирование по очереди.
Что такое модульное тестирование?
Как следует из названия, этот уровень включает в себя тестирование "Единицы".
Здесь единицей может быть наименьшая часть приложения, которая поддается тестированию, будь то наименьшая отдельная функция, метод и т.д. Разработчики программного обеспечения являются теми, кто пишет тестовые случаи для единиц. Целью здесь является соответствие требований и ожидаемого поведения единицы.
Ниже приведены несколько важных моментов о модульном тестировании и его преимуществах:
- Юнит-тестирование проводится перед интеграционным тестированием разработчиками программного обеспечения с использованием методов тестирования "белого ящика".
- Юнит-тестирование проверяет не только положительное поведение, т.е. правильность вывода в случае правильного ввода, но и сбои, возникающие при неправильном вводе.
- Обнаружение проблем/ошибок на ранней стадии очень полезно и снижает общую стоимость проекта. Поскольку модульное тестирование проводится до интеграции кода, проблемы, обнаруженные на этом этапе, могут быть решены очень легко, и их влияние также очень мало.
- Юнит-тест тестирует небольшие фрагменты кода или отдельные функции, поэтому проблемы/ошибки, обнаруженные в этих тестовых случаях, являются независимыми и не влияют на другие тестовые случаи.
- Еще одним важным преимуществом является то, что случаи модульного тестирования упрощают и облегчают тестирование кода. Таким образом, становится проще решать проблемы на более поздних этапах, поскольку тестированию подвергается только последнее изменение в коде.
- Юнит-тестирование экономит время и затраты, оно многократно используется и легко поддерживается.
JUnit (Java framework), PHPUnit (PHP framework), NUnit (.Net framework) и т.д. являются популярными инструментами модульного тестирования, которые используются для различных языков.
Что такое интеграционное тестирование?
Интеграционное тестирование - это тестирование интеграции различных частей системы вместе. Две различные части или модули системы сначала интегрируются, а затем проводится интеграционное тестирование.
Целью интеграционного тестирования является проверка функциональности, надежности и производительности системы при интеграции.
Интеграционное тестирование проводится на модулях, которые сначала тестируются на модулях, а затем интеграционное тестирование определяет, дает ли комбинация модулей желаемый результат или нет.
Интеграционное тестирование может проводиться как независимыми тестировщиками, так и разработчиками.
Существует 3 различных типа подходов к интеграционному тестированию. Давайте кратко обсудим каждый из них:
a) Интеграционный подход Большого взрыва
При таком подходе все модули или блоки интегрируются и тестируются как единое целое в один момент времени. Обычно это делается, когда вся система готова к интеграционному тестированию в один момент времени.
Пожалуйста, не путайте этот подход интеграционного тестирования с системным тестированием, тестируется только интеграция модулей или единиц, а не вся система, как это делается при системном тестировании.
Основные принципы подхода большого взрыва преимущество заключается в том, что все интегрированное тестируется за один раз.
Один крупный недостаток заключается в том, что становится трудно идентифицировать сбои.
Пример: На рисунке ниже блоки с 1 по 6 интегрированы и протестированы с использованием подхода "большого взрыва".
б) Нисходящий подход
Интеграция блоков/модулей проверяется шаг за шагом от верхнего до нижнего уровня.
Первый блок тестируется отдельно путем написания тестовых STUBS. После этого нижние уровни интегрируются один за другим, пока последний уровень не будет собран вместе и протестирован.
Подход "сверху вниз" - это очень органичный способ интеграции, поскольку он соответствует тому, как все происходит в реальной среде.
Единственный концерн при таком подходе основная функциональность тестируется в конце.
c) Подход "снизу вверх
Блоки/модули тестируются от нижнего уровня к верхнему, шаг за шагом, пока все уровни блоков/модулей не будут интегрированы и протестированы как единое целое. Программы-стимуляторы, называемые DRIVERS При таком подходе легче обнаружить проблемы или ошибки на более низких уровнях.
Основной недостаток Этот подход заключается в том, что проблемы более высокого уровня могут быть определены только в конце, когда все подразделения уже интегрированы.
Модульное тестирование и интеграционное тестирование
Достаточно поговорив о модульном и интеграционном тестировании, давайте быстро пройдемся по различиям между ними в следующей таблице:
| Единичное тестирование | Интеграционное тестирование |
|---|---|
| Тестирует отдельный компонент всей системы, т.е. тестирует единицу в изоляции. | Тестирует компоненты системы, работающие вместе, т.е. тестирует взаимодействие нескольких блоков. |
| Более быстрое выполнение | Может работать медленно |
| Отсутствие внешних зависимостей. Любая внешняя зависимость высмеивается или отбрасывается. | Требуется взаимодействие с внешними зависимостями (например, база данных, оборудование и т.д.) |
| Простой | Комплекс |
| Проводится разработчиком | Проводится испытателем |
| Это один из видов тестирования "белого ящика | Это один из видов тестирования "черного ящика |
| Проводится на начальном этапе тестирования и затем может выполняться в любое время | Должно проводиться после модульного тестирования и перед системным тестированием |
| Дешевое обслуживание | Дорогое обслуживание |
| Начинается со спецификации модуля | Начинается со спецификации интерфейса |
| Юнит-тестирование имеет узкую сферу применения, поскольку оно просто проверяет, выполняет ли каждый небольшой фрагмент кода то, для чего он предназначен. | Он имеет более широкую сферу применения, поскольку охватывает всю область применения |
| Результатом модульного тестирования является детальная видимость кода | Результатом интеграционного тестирования является детальная видимость интеграционной структуры |
| Выявляет проблемы только в рамках функциональности отдельных модулей. Не выявляет ошибок интеграции или общесистемных проблем. | Выявление ошибок, возникающих при взаимодействии различных модулей друг с другом для формирования общей системы |
Функциональное тестирование
Техника тестирования "черного ящика", при которой проверяется функциональность приложения на получение желаемого результата при предоставлении определенных входных данных, называется "функциональным тестированием".
В наших процессах тестирования программного обеспечения мы делаем это путем написания тестовых примеров в соответствии с требованиями и сценариями. Для любой функциональности количество написанных тестовых примеров может варьироваться от одного до многих.
Заключение
Все эти три вида тестирования коррелируют между собой.
Для достижения полного покрытия необходимо иметь модульные тесты для путей/строк кода, функциональные и интеграционные тесты для гарантии того, что "единицы" работают вместе слаженно.
Надеюсь, эта статья дала вам четкое представление о модульном, интеграционном и функциональном тестировании, а также об их различиях, хотя этих видов тестирования гораздо больше!!!