ЧТО ТАКОЕ КОМПОНЕНТНОЕ ТЕСТИРОВАНИЕ В ТЕСТИРОВАНИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

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

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

Что такое тестирование компонентов или тестирование модулей

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

Компонент Тестирование — это тип тестирования белого ящика, при котором вы проверяете отдельный компонент приложения перед тестированием всего приложения.

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

ISTQB определяет тестирование компонентов как отдельное и эффективное тестирование каждого отдельного аппаратного или программного компонента для данного приложения. Предположим, например, что приложение содержит пять компонентов. Тестирование каждого компонента по отдельности называется тестированием компонентов.

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

Ниже приведены цели тестирования компонентов:

1. Проверка функциональности компонентов. Цель тестирования компонентов — убедиться, что входы и выходы объекта тестирования работают правильно, как указано. Это гарантирует, что функциональность объекта работает правильно, а также соответствует желаемой спецификации.
2. Снижение риска:Разработчик находит ошибки в коде и исправляет их. В результате он снижает вероятность риска на фундаментальном уровне.
3. Поиск ошибок. Его основная цель — найти ошибки в исходном коде приложения. Кроме того, он проверяет потоки вызовов функций, поток управления, структуру данных и т. д., используемые в программе.
4. Повышение уверенности в качестве компонента:Большинство ошибок обнаруживаются и исправляются при кодировании, поскольку тестирование компонентов выполняется на уровне модулей. Таким образом, продукт разрабатывается с большей гарантией того, что при дальнейшем тестировании будет меньше ошибок.
5. Вывод дефектов на более высокий уровень: разработчики обнаруживают и устраняют все ошибки кодирования при тестировании компонентов до переход на более высокие уровни тестирования.

Понимание заглушек и драйверов

Тестирование компонентов делится на две части в зависимости от глубины тестирования: тестирование компонентов в малом (CTIS) и тестирование компонентов в большом (CTIL). Тестирование компонентов в малых масштабах означает проведение тестирования компонентов изолированно от других компонентов. Это не требует других компонентов для интеграции. С другой стороны, тестирование компонентов в целом выполняется, когда есть зависимость от других компонентов, и мы не можем разделить два зависимых компонента.

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

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

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

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

Тестирование компонентов может включать в себя функциональные аспекты (например, проверку вычисленных ошибок), нефункциональные характеристики (для например, выявление утечек памяти) или структурные аспекты (например, тестирование процессов принятия решений).

Когда нам нужно проводить тестирование компонентов< /h2>

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

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

Зачем выполняется cтестирование компонентов

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

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

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

Как выполняется cтестирование компонентов

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

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

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

Чтобы повысить качество и минимизировать бизнес-риски, доступно несколько автоматизированных сред для облегчения тестирования компонентов, включая Jtest, Junit, JMockit, EMMA.

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

Хотя JMockit — это инструмент для тестирования компонентов с открытым исходным кодом, который обеспечивает покрытие линий, маршрутов и данных, EMMA также представляет собой набор инструментов для анализа кода.

Кто выполняет cкомпонент тестирование

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

Процесс тестирования компонентов

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

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

Как писать тестовые примеры компонентов

< p>Тестовые примеры компонентов должны быть написаны таким образом, чтобы тестировались как отдельные компоненты, так и интегрированные компоненты.

1. Компоненты, модули или модули. Каждый компонент или модуль должен создаваться каждым разработчиком, чтобы его или ее работа не нарушала работу других компонентов, использующих общий код.
2. Код и данные. Структуры: это может означать использование передовых методов кодирования и обеспечение того, чтобы код не причинял вреда другим компонентам.
3. Классы:Чтобы обеспечить соблюдение объектно-ориентированных принципов, необходимо протестировать каждый класс и использовать инкапсуляцию, чтобы другой класс не мог получить прямой доступ к данным внутри класса. В результате приложение менее уязвимо для угроз безопасности.
4. Модули базы данных. В базе данных хранится информация, введенная в пользовательский интерфейс (например, регистрация нового клиента). Поэтому необходимо тестировать базу данных в компонентном тестировании вместе с внешним интерфейсом.

Методы тестирования компонентов

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

При использовании TDD первым шагом является создание неудачного тестового случая, его запуск и проверка его неудачи. Поскольку кодирование еще не завершено, тестовый пример не будет выполнен. Разработчик завершает кодирование, чтобы гарантировать прохождение тестового примера. После прохождения тестового примера разработчик переходит к следующей функции; в противном случае он реорганизует код. Если тестовый пример не пройден, код необходимо изменить. Также может случиться так, что тест-кейс пройден, но есть проблемы с производительностью, требующие дальнейшего рефакторинга. Этот процесс повторяется до тех пор, пока разработчик не пройдет тест с рефакторингом кода.

Примеры тестов для тестирования компонентов

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

1. Функциональность компонента: протестируйте функциональность компонента/модуля в соответствии с бизнес-требованиями. Например, если протестирован компонент, который должен возвращать значение скидки всякий раз, когда покупатель применяет купон на веб-сайте электронной коммерции, он должен возвращать правильное значение.
2. Поток данных: Обычно компоненты передают данные другому интегрирующему компоненту, и этот поток данных должен вести себя так, как ожидалось. Например, компонент скидки, который возвращает значение скидки, ограничен буквенно-цифровыми символами, а компонент создания купона на скидку также не должен разрешать использование специальных символов. Следовательно, если компонент скидки интегрирован с компонентом создания купона на скидку, это не вызовет проблем с потоком данных.
3. Логика кода: протестируйте логику кода для крайних случаев. Например, в приложении электронной коммерции логика «Купи два — один бесплатно» должна обрабатывать случаи, когда в корзине четыре товара.
4. Производительность компонента: проверьте, не вызывает ли конкретный компонент каких-либо проблем, связанных с производительностью. Проверка на отсутствие утечек памяти.

Тестирование компонентов и модульное тестирование

1. Принцип тестирования компонентов аналогичен принципу модульного тестирования. , за исключением того, что разработчик может использовать реальные данные вместо фиктивных для тестирования компонентов.
2. Основное различие между тестированием компонентов и модульным тестированием заключается в том, что первое выполняется тестировщиками, а второе — разработчиками или специалистами SDET.
3. Модульные тесты выполняются на уровне детализации, тогда как компонентные тесты выполняются на уровне приложения. .
4. В рамках модульного тестирования проверяется, выполняется ли отдельная программа или фрагмент кода, как указано. При компонентном тестировании отдельные объекты программного обеспечения тестируются либо по отдельности, либо в комплекте с другими объектами/компонентами.
5. Тестирование компонентов выполняется на более высоком уровне интеграции и по отношению ко всему приложению, в то время как модульное тестирование выполняется в контексте только одного модуля/программы.

Компоненты, интерфейс, интеграция и системы тестирование

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

Интерфейс действует как связующее звено между двумя компонентами. По сути, это слой, соединяющий два компонента. Тестирование интерфейса оценивает интерфейс между двумя компонентами или платформой, на которой они взаимодействуют.

Как правило, при тестировании интерфейса тестируются API или веб-службы. Таким образом, мы не можем использовать методы тестирования черного ящика для тестирования этих интерфейсов, но вместо этого мы будем использовать пользовательский интерфейс SOAP или какой-либо другой инструмент для тестирования API или веб-служб.

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

После того, как все компоненты прошли интеграционное тестирование, мы принимаем участие в Системном тестировании, которое проверяет все приложение/систему в целом. Основная цель системного тестирования — проверить, соответствуют ли бизнес-требования реализации программного обеспечения.

Заключение

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

TAG: qa

Еще об этом:

150+ ЛУЧШИХ ВОПРОСОВ И ОТВЕТОВ НА ИНТЕРВЬЮ О ТЕСТИРОВАНИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ТЕСТИРОВАНИЕ ПРИЛОЖЕНИЙ В БАНКОВСКОЙ ОБЛАСТИ: ПОЛНОЕ РУКОВОДСТВО ПО ТЕСТИРОВАНИЮ BFSI РУКОВОДСТВО ПО A/B-ТЕСТИРОВАНИЮ: КАК ПРОВОДИТЬ AB-ТЕСТИРОВАНИЕ ЧТО ТАКОЕ ТЕСТИРОВАНИЕ НА СООТВЕТСТВИЕ ПРИ ТЕСТИРОВАНИИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ЛУЧШИЕ ИНСТРУМЕНТЫ ДЛЯ АВТОМАТИЗАЦИИ AP И СЧЕТОВ ДЛЯ ДИНАМИКИ РУКОВОДСТВО ПО ТЕСТИРОВАНИЮ AR/VR – КАК ПРОВОДИТЬ ТЕСТИРОВАНИЕ AR/VR Метрики Agile-тестирования: чем они могут помочь? ЛУЧШИЕ ИНСТРУМЕНТЫ ДЛЯ АВТОМАТИЗАЦИИ AP И СЧЕТОВ ДЛЯ NETSUITE СПЕЦИАЛЬНОЕ РУКОВОДСТВО ПО ТЕСТИРОВАНИЮ | ТО, ЧТО ВЫ ДОЛЖНЫ ЗНАТЬ АЛЬФА-ТЕСТИРОВАНИЕ – ПОДРОБНОЕ РУКОВОДСТВО