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

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

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

🎯 Цель: Цель состоит в том, чтобы выявить ошибки в модуле, а не продемонстрировать его работоспособность.
⚪ Ориентация: Данная методика в основном основана на принципе «белого ящика», дополненном примерами «черного ящика», взятыми из спецификации.
⏩ Параллелизм: Можно тестировать несколько модулей одновременно, что сокращает общее время тестирования.
🔗 Два метода: Модули объединяются либо постепенно, шаг за шагом, либо не пошагово за один проход.
🧰 Строительные леса: Драйверы передают тестовые данные модулю, а заглушки заменяют модули, к которым они обращаются.
🆚 Собственность: Тестировщики пишут модульные тесты после завершения кодирования, тогда как разработчики пишут модульные тесты в процессе кодирования.
⚠️ Задачи Непостепенная работа, неправильно понятые тестовые дубли и частая отладка поглощают большую часть усилий.

Читать

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

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

Модульное тестирование в значительной степени ориентировано на метод «белого ящика». Цель модульного тестирования состоит не в демонстрации правильного функционирования модуля, а в выявлении наличия в нем ошибки. Эта инверсия имеет значение: запуск, который ничего не обнаружил, подтвердил очень мало, тогда как запуск, который выявил дефект, выполнил свою задачу.

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

Зачем проводить тестирование модулей

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

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

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

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

Спецификация модуля
Исходный код модуля

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

После разработки тестовых примеров следующим шагом является объединение модулей для тестирования. Используемый метод — это либо дополнительный или неинкрементальный метод.

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

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

Аспект	Инкрементный метод	Неинкрементальный метод
Сочетание	Добавляется по одному модулю в проверенную коллекцию.	Все модули объединены, а затем протестированы совместно.
Необходимы строительные леса.	Больше водительских удостоверений и бланков, написанных постепенно.	Меньше дублирований тестов, поскольку присутствуют реальные модули.
Локализация отказов	Высокий уровень сигнала — сбой указывает на только что добавленный модуль.	Слабое место — причина неудачи может быть где угодно.
Наиболее подходит для	Крупные проекты с множеством взаимодействующих модулей.	Небольшие программы с малым количеством модулей и низкой степенью связанности.

Драйверы и заглушки в модульном тестировании

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

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

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

Примеры советов по тестированию модулей

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

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

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

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

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

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

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

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

Аспект	Модульное тестирование	Тестирование компонентов	Интеграционное тестирование
Под тестом	Одна подпрограмма, класс или процедура	Один самодостаточный компонент со своими непосредственными зависимостями	Интерфейсы между объединенными модулями
Обычный владелец	Тестировщик после написания кода	тестер	Интеграционный тестер
строительные леса	Водители и талоны	Заглушки для внешних зависимостей	Постепенное уменьшение числа дубликатов в тестах.
Выявлен дефект	Логическая ошибка внутри модуля.	Ошибка в работе компонента.	Ошибка интерфейса и передачи данных

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

Проблемы при тестировании модулей

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

Неинкрементное тестирование требует больше работы — Если сначала всё объединить, одна-единственная ошибка может заставить тестировщиков пройти всю программу заново.
Тест на непонимание удваивается — Заглушка, возвращающая нереалистичное значение, приводит к положительному результату, который ничего не доказывает.
Отладочные тесты часто — В генеративном коде тоже есть свои недостатки, и время, потраченное на исправление драйвера, — это время, не потраченное на тестирование модуля.
Нужно понять код — Ориентация в виде «белого ящика» означает, что тестировщик, не умеющий читать модуль, не сможет разработать для него осмысленные сценарии тестирования.

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

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

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

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

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

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

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

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

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