Тестирование играет важнейшую роль в жизненном цикле разработки программного обеспечения (SDLC). Чтобы оценить качество, функциональность, надежность, удобство использования и производительность разрабатываемого программного продукта, команда тестировщиков проводит различные виды тестирования. Одним из них является компонентное тестирование.
Программный продукт состоит из различных модулей или компонентов. Каждый компонент выполняет определенную задачу или набор задач. Несколько компонентов объединяются в полнофункциональную программную систему. В программной инженерии это называется модульностью. Модульность подразумевает разделение системы на управляемые фрагменты, которые можно разрабатывать и тестировать по отдельности.
Тестирование отдельных компонентов программы перед их интеграцией называется компонентным тестированием. В этой статье мы познакомимся с ним поближе.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Содержание
- Что собой представляет компонентное тестирование?
- Виды компонентного тестирования
- Процесс компонентного тестирования
- Компонентное тестирование и юнит-тестирование
- Заключение
Что собой представляет компонентное тестирование?
Компонентное тестирование – это тип тестирования ПО, в ходе которого проверяется функциональность и удобство использования каждого компонента программного продукта до его интеграции с другими компонентами.
Компонентное тестирование также называют модульным.
Прим. ред.: здесь модульное тестирование (module testing) – не то же самое, что юнит-тестирование (unit testing), хотя обычно именно эти два термина используются как синонимы.
С помощью компонентного тестирования легче определить, какой именно компонент программного обеспечения приводит к ошибкам или багам. Кроме того, проверяется поведение и функциональность отдельных компонентов.
Почему это важно?
Компонентное тестирование важно по нескольким причинам. Оно:
- Выявляет проблемы на уровне компонентов. Это позволяет обнаружить возможные ошибки на ранней стадии разработки и в итоге сократить усилия, необходимые для проверки всей системы.
- Позволяет устранять ошибки на уровне компонентов. Устранение проблем на этапе создания компонентов дешевле, чем на более поздних этапах разработки.
- Позволяет команде разработчиков уверенно интегрировать компоненты и перейти к следующему типу тестирования – интеграционному.
Цели компонентного тестирования
- Обнаружение ошибок в компонентах. В ходе компонентного тестирования тестировщики выявляют все возможные ошибки в каждом модуле разрабатываемого ПО.
- Снижение рисков. В случае обнаружения ошибок или недочетов команда разработчиков немедленно устраняет их, прежде чем перейти к следующему этапу тестирования. Таким образом, компонентное тестирование снижает риски ошибок на уровне компонентов.
- Повышение качества компонентов. Обнаружение ошибок и их немедленное устранение повышает качество отдельных компонентов.
- Предотвращение перехода дефектов на следующий уровень тестирования. Дефекты, выявленные при тестировании компонентов, не передаются на более высокий уровень тестирования.
Кто проводит компонентное тестирование?
Как правило, компонентное тестирование выполняется после юнит-тестирования и перед интеграционным.
Разработчики проводят юнит-тестирование каждого компонента и выпускают сборку под названием UT (Unit Testing), чтобы команда QA могла провести компонентное тестирование. Таким образом, критерием начала компонентного тестирования является завершение юнит-тестирования.
Давайте разберемся в этом на примере. Рассмотрим проект по разработке сайта.
После разработки веб-страниц команда разработчиков проводит юнит-тестирование. Затем сборка передается команде тестирования для проверки компонентов сайта.
Тестировщики проверяют каждый компонент и сообщают об ошибках или багах (если они есть) разработчикам, а те их исправляют.
При этом, чтобы позволить тестировщикам провести проверку, команда разработчиков не обязательно должна создать все веб-страницы сразу.
- Критерий входа: все компоненты продукта должны пройти юнит-тестирование.
- Критерии выхода:
- Каждый компонент должен быть функционально правильным.
- Не должно быть багов с высокими или средними серьезностью и приоритетом.
Виды компонентного тестирования
Как правило, компонентное тестирование делится на два вида, в зависимости от сложности: тестирование компонентов в малом и в целом.
Тестирование компонентов в малом
Когда тестировщики оценивают конкретный компонент изолированно, без зависимости от других компонентов программного продукта, это называется тестированием компонентов в малом (Component testing In Small, CTIS). Такое тестирование идеально подходит для небольших приложений.
Давайте разберем CTIS на реальном примере. Представьте, что вы работаете в компании по производству медицинского оборудования, выпускающей инсулиновые помпы. Инсулиновая помпа состоит из различных компонентов, таких как блок управления, двигатель, батарея и т. д.
Тестирование компонентов в малом требует, чтобы вы проверили все компоненты по отдельности, чтобы убедиться в их качестве, надежности и функциональности.
Таким образом можно выявить проблемы до интеграции компонентов, снизить потенциальные риски и повысить общее качество помпы.
Тестирование компонентов в целом
Когда тестировщики проверяют конкретный компонент с помощью других компонентов продукта, это называется тестированием компонентов в целом (Component testing In Large, CTIL). Тестирование каждого компонента требует ввода или вывода других компонентов.
Для лучшего понимания CTIL разберем пример из реальной жизни. Рассмотрим аналитическую платформу для социальных сетей, состоящую из трех компонентов:
- Сбор данных с различных платформ социальных сетей, таких как Twitter, Facebook, Instagram и т. д.
- Обработка данных, полученных из различных источников, и применение различных алгоритмов для анализа настроений, выявления тенденций и профилирования пользователей.
- Визуализация данных – создание визуального отчета на основе обработанных данных, его анализ его и генерация ценных идей.
Итак, команда разработчиков создала компонент обработки данных и хочет, чтобы он прошел тестирование. Однако этот компонент имеет несколько зависимостей от компонентов сбора данных и визуализации данных, которые еще не разработаны.
Функциональный поток выглядит следующим образом: сбор данных → обработка данных → визуализация данных.
Для тестирования компонента обработки данных необходимы два компонента:
- Драйвер. Это фиктивный код, который имитирует поведение отсутствующих компонентов. Он используется для вызова тестирования низкоуровневых компонентов. Драйвер – это модуль более высокого уровня, который вызывает функцию для модуля более низкого уровня, когда вызывающая функция недоступна.
- Заглушка. Это фиктивный код, который имитирует поведение отсутствующих компонентов. Он используется для вызова тестирования высокоуровневых компонентов. Заглушка – это модуль нижнего уровня и вызывающая функция. Она принимает входные данные от модулей более высокого уровня и возвращает соответствующие выходные данные.
В нашем примере, где нам нужно протестировать компонент обработки данных, связанные компоненты сбора данных и визуализации данных еще не развернуты. В таком случае мы можем их заменить на заглушки и драйверы при необходимости.
Процесс компонентного тестирования
- Анализ требований. Первым шагом является анализ требований, связанных с каждым компонентом программного продукта.
- Планирование тестирования. На основе анализа требований составляется план или стратегия тестирования. Создаются тестовые сценарии и тест-кейсы.
- Подбор тестов. На этом этапе необходимо определить, какие тесты необходимо выполнить для того или иного модуля, а какие пропустить.
- Выполнение тестов. Для модулей выполняются тест-кейсы, основанные на требованиях. Эти тест-кейсы оценивают компоненты с точки зрения функциональных и нефункциональных аспектов.
- Запись тестов. Записывайте результаты выполнения тест-кейсов и любые выявленные ошибки или недочеты. Если обнаружены ошибки или проблемы, тестировщики сообщают об этом разработчикам для исправления. Этот процесс продолжается до тех пор, пока команда тестирования не перестанет находить ошибки в продукте.
- Проверка теста. На этом этапе команда тестировщиков проверяет, соответствует ли продукт спецификациям.
- Завершение. Последний шаг – анализ результатов для определения готовности программного продукта.
Пример
Давайте разберем процесс компонентного тестирования на примере.
Рассмотрим разработку банковского приложения. Приложение состоит из различных страниц для каждой услуги, предлагаемой банком, таких как счета, страхование, карты, инвестиции и т. д. Здесь каждая страница является отдельным компонентом и тестируется после полной разработки.
Предположим, что необходимо протестировать страницу счетов, но страница входа в систему еще не разработана. В этой ситуации на помощь приходит концепция драйвера.
Для тестирования страницы счетов тестировщики создают драйвер, имитирующий функциональность страницы входа в систему. В результате тестировщики может легко перемещаться по странице счетов и выполнять необходимые тест-кейсы. Как только страница входа в систему будет разработана, драйвер будет заменен на эту страницу, и тестировщики тщательно проверят ее функциональность.
Аналогичным образом концепция заглушки используется для тестирования страницы перевода средств, поскольку она зависит от страницы добавления получателя, которая еще не разработана.
Компонентное тестирование и юнит-тестирование
Теперь давайте разберемся, в чем разница между компонентным и юнит-тестированием.
| Компонентное тестирование | Модульное тестирование |
|---|---|
| Тестирование компонентов по отдельности или без изоляции для проверки их функциональности на соответствие требованиям. | Тестирование разработанного кода на программном уровне на соответствие спецификациям проекта. |
| Выполняется тестировщиками. | Выполняется разработчиками. |
| Проводится после юнит-тестирования и перед интеграционным. | Это первый уровень тестирования программного обеспечения. |
| Тестировщики не знают о внутренней структуре продукта. Следовательно, это тестирование “черного ящика”. | Поскольку разработчики оценивают код, юнит-тестирование – это тестирование “белого ящика”. |
| Для проверки учитываются тестовые сценарии и функциональные спецификации. | Для проверки учитываются проектные спецификации. |
| Тестировщики приступают к проверке компонента, когда он полностью разработан. | Разработчики тестируют компонент на каждом этапе его разработки. |
Заключение
Вот и все, что мы хотели вам рассказать о компонентном тестировании. Суть его в том, что каждый компонент системы проверяется на корректность и функциональность отдельно от других. Это экономичный вид тестирования, который избавляет команду разработчиков от головной боли в будущем, устраняя все потенциальные ошибки и погрешности на ранней стадии.
Многие люди путают компонентное и юнит-тестирование. Компонентное тестирование выполняется тестировщиками или QA-специалистами в соответствии с требованиями и тестовыми сценариями. Юнит-тестирование проводят разработчики, проверяя программные модули на соответствие спецификациям.
Перевод статьи «Component Testing».