Что такое тестирование компонентов? Методы, примеры тестовых случаев

Автор: Томас Гамильтон Томас Гамильтон
Hours обновлено

⚡ Умное резюме

Компонентное тестирование проверяет каждую отдельную часть приложения, не интегрируя её с остальными компонентами, так что дефекты обнаруживаются и исправляются внутри отдельного модуля до начала сборки.

  • 🧩 Объем: По одному компоненту за раз, изолированному от окружающих его компонентов.
  • 👥 Właściciel: Тестировщики запускают его после того, как разработчики завершат модульное тестирование.
  • 🔬 КТИС: Тестирование компонентов в небольших масштабах позволяет полностью изолировать компонент.
  • 🔗 CTIL: В крупномасштабном компонентном тестировании учитываются все зависимости, как реальные, так и смоделированные.
  • 🧱 Двойные/Парные: Драйвер вызывает компонент; заглушка вызывается им.
  • ✅ Выход: В журнале не осталось открытых критических, сложных или средних дефектов.
Читать

Методы компонентного тестирования и примеры тестовых случаев.

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

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

Любое программное обеспечение в целом состоит из нескольких компонентов, а тестирование на уровне компонентов занимается проверкой этих компонентов по отдельности. Это один из наиболее распространенных видов тестирования. тестирование черного ящика Типы данных, выполняемые командой контроля качества.

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

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

Иерархия компонентного тестирования: от стратегии тестирования до низкоуровневых тестовых случаев.

Использование термина «компонентное тестирование» варьируется от области к области и от организации к организации. Наиболее распространенными причинами этих различий в восприятии являются три, перечисленные ниже.

  1. Тип выбранной модели жизненного цикла разработки
  2. Сложность тестируемого программного обеспечения или приложения.
  3. Независимо от того, проводится ли тестирование с изоляцией от других компонентов приложения или без нее.

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

Кто занимается тестированием компонентов

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

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

Компонентное тестирование выполняется вскоре после завершения разработчиками модульного тестирования и передачи сборки команде тестирования. Такая сборка называется сборкой модульного тестирования (UT build). На этом этапе тестируется основная функциональность каждого компонента.

Критерии входа в тестирование компонентов

  • Разработан и протестирован минимальный набор компонентов, которые должны быть включены в модульную сборку.

Критерии выхода из тестирования компонентов

  • Функциональность каждого компонента соответствует заявленным характеристикам.
  • В настоящее время не осталось нераскрытых дефектов критического, высокого или среднего уровня серьезности или приоритета. журнал дефектов.

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

В зависимости от уровня сложности тестирования, компонентное тестирование подразделяется на два типа.

  1. CTIS — тестирование компонентов в малых масштабах
  2. CTIL — Тестирование компонентов в больших масштабах

CTIS — тестирование компонентов в малых масштабах

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

Пример 1: На веб-сайте, состоящем из пяти разных страниц, тестирование каждой страницы отдельно и изолированно от других компонентов — это компонентное тестирование в небольших масштабах.

Пример 2: На главной странице сайта guru99.com, показанной ниже, представлено множество разделов, таких как «Главная», «Тестирование» и другие. SAPВеб, Обязательно к изучению!, Большие данные, Реальные проекты и Блог.

Guru99. Навигационное меню главной страницы рассматривается как отдельный тестируемый компонент.

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

Открыв выпадающее меню «Тестирование», вы увидите подкомпоненты компонента «Тестирование»: Ручное тестированиеСОАПУИ QTP, JUnit, SeleniumУправление тестированием и Мобильное тестированиеНа приведенном ниже снимке эти подкомпоненты выделены красным цветом.

Тестирование выпадающего меню с выделенными красным цветом подкомпонентами.

СТАТЬИ ПО ТЕМЕ

CTIL — Тестирование компонентов в больших масштабах

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

Пример делает разницу более понятной. Предположим, приложение состоит из трех компонентов: компонента A, компонента B и компонента C.

Разработчик создал компонент B и хочет его протестировать. Для полного тестирования компонента B часть его функциональности зависит от компонента A, а часть — от компонента C, как показано на диаграмме ниже.

Компонент B протестирован с заменой компонента A на драйвер и заменой компонента C на заглушку.

Последовательность выполнения функции выглядит следующим образом: A → B → C, что означает, что компонент B зависит как от A, так и от C. В этой последовательности заглушка является вызываемой функцией, а драйвер — вызывающей функцией.

Компоненты A и C еще не разработаны. Для полного тестирования компонента B компоненты A и C заменены драйвером и заглушкой, как того требуют условия, поэтому две недостающие части служат в качестве фиктивных объектов до тех пор, пока не будут созданы настоящие компоненты.

  • Заглушка: Компонент C вызывается заглушкой. Компонент C не готов, поэтому заглушка заменяет его и возвращает ответы, которые ожидает компонент B.
  • Водитель: Драйвер вызывает тестируемый компонент. Компонент А не готов, поэтому драйвер заменяет его и вызывает компонент В с необходимыми входными данными.

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

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

Веб-страница 1 — это страница входа на демонстрационный банковский сайт.

Компонент страницы входа с полями для ввода идентификатора пользователя и пароля.

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

Компонент главной страницы менеджера с навигационными ссылками и изображениями.

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

Сценарии тестирования компонентов представлены на веб-странице 1:

  • Введите недопустимый идентификатор пользователя и убедитесь, что пользователю отображается понятное предупреждение.
  • Введите неверный логин и пароль, нажмите «Сбросить» и убедитесь, что поля «Логин» и «Пароль» очищены.
  • Введите действительное имя пользователя и пароль и нажмите кнопку «Войти».

Сценарии тестирования компонентов представлены на веб-странице 2:

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

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

В таблице ниже приведено краткое описание различий между двумя уровнями в повседневной практике.

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

Часто задаваемые вопросы (FAQ)

Снижение рисков, проверка функционального и нефункционального поведения компонента, укрепление доверия к его качеству, выявление дефектов и предотвращение их распространения.ping на более высокие уровни тестирования.

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

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

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

Codeфреймворки уровня -, такие как JUnit, TestNGNUnit и pytest, а также средства запуска компонентов пользовательского интерфейса, такие как Cypress Компонентное тестирование, Storybook и Jest. Все они органично вписываются в общую концепцию. автоматизация трубопровод.

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

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

И то, и другое зависит от того, кто проводит тестирование. Тестировщики работают методом «черного ящика», ориентируясь на спецификацию компонента, в то время как разработчики, имеющие доступ к коду, применяют свои знания на практике. белая коробка покрытие внутри того же компонента.

Подведем итог этой публикации следующим образом: