Модульное тестирование

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



Содержание

• Разработка
• Аналогия
• Метод
• Задачи
• Выгоды
• Советы

Разработка

Блок - это самая маленькая тестируемая часть любого программного обеспечения. Он обычно имеет один или несколько входов и, как правило, один выход. В процедурном программировании единицей может быть индивидуальная программа, функция, процедура и т.д. В объектно-ориентированном программировании наименьшей единицей является метод, который может принадлежать базовому/суперклассу, абстрактному классу или производному/дочернему классу. (Некоторые рассматривают модуль приложения как единицу. Это может обескуражить, поскольку в этом модуле, вероятно, будет много отдельных блоков.) Фреймворки модульного тестирования, драйверы, заглушки и фиктивные/поддельные объекты используются для помощи в модульном тестировании.

Дефекты обычно устраняются сразу же, как только они обнаруживаются, и они официально не сообщаются и не отслеживаются.

Аналогия

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

Метод

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

Задачи

План Модульного Тестирования [Подготовка >> Обзор >> Доработка >> Базовая Линия] Модульные Тестовые Случаи/ Тестовые Сценарии/ Тестовые Данные [Подготовка >> Обзор >> Доработка >> Базовый Уровень]

Модульный тест [выполнить >> повторное выполнение]

Когда это делается?

Модульное тестирование-это первый уровень тестирования программного обеспечения, который выполняется перед интеграционным тестированием. Хотя модульное тестирование обычно выполняется после кодирования, иногда, особенно в тестовой разработке (TDD), автоматизированные модульные тесты пишутся до кодирования.

Кто этим занимается?

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

Выгоды

• Модульное тестирование повышает уверенность в изменении/поддержании кода. Если будут написаны хорошие модульные тесты, и если они будут выполняться каждый раз, когда какой-либо код изменяется, мы сможем быстро поймать любые дефекты, возникшие из-за этого изменения. Кроме того, если коды уже сделаны менее взаимозависимыми, чтобы сделать возможным модульное тестирование, непреднамеренное влияние изменений в любом коде будет меньше.
• Разработка идет быстрее. Как же так? Если у вас нет модульного тестирования, вы пишете свой код и выполняете этот нечеткий "тест разработчика" (вы устанавливаете некоторые точки останова, запускаете графический интерфейс, предоставляете несколько входных данных, которые, надеюсь, попадут в ваш код и надеетесь, что все готово.) Но если у вас есть модульное тестирование, вы пишете тест, пишете код и запускаете тест. Написание тестов требует времени, но это время компенсируется меньшим количеством времени, которое требуется для запуска тестов; вам не нужно запускать графический интерфейс и предоставлять все эти входные данные.
• И, конечно же, модульные тесты более надежны, чем "тесты разработчика". Разработка происходит быстрее и в долгосрочной перспективе. Как же так? Усилия, необходимые для поиска и исправления дефектов, обнаруженных во время модульного тестирования, очень малы по сравнению с усилиями, необходимыми для исправления дефектов, обнаруженных во время тестирования системы или приемочного тестирования.
• Стоимость устранения дефекта, обнаруженного в ходе модульного тестирования, меньше по сравнению с затратами на дефекты, обнаруженные на более высоких уровнях. Сравните стоимость (время, усилия, разрушение, унижение) дефекта, обнаруженного во время приемочных испытаний или когда программное обеспечение находится в производстве.
• Отладка очень проста. При неудачном тестировании отлаживаются только последние изменения. При тестировании на более высоких уровнях изменения, внесенные в течение нескольких дней/недель/месяцев, проще отслеживаются.
• Код более надежен. Почему? Я думаю, что нет необходимости объяснять это здравомыслящему человеку.

Советы

• Создайте правильный план модульного тестирования. [Если не документально, то хотя бы в голове.]
• Найдите инструмент автоматизации тестирования/фреймворк для вашего языка.
• Создавайте тестовые примеры, фокусируясь на областях, которые больше всего влияют на поведение системы.
• Изолируйте среду разработки от тестовой среды.
• Используйте тестовые данные, близкие к реальным.
• Перед устранением дефекта напишите или измените тест, который выявит дефект. Почему? Во - первых, вы позже сможете поймать дефект, если не исправите его должным образом. Во-вторых, ваш набор тестов теперь более полный. В-третьих, вы, скорее всего, будете слишком ленивы, чтобы написать тест после того, как вы уже исправили дефект.
• Напишите тестовые случаи, которые не зависят друг от друга. Например, если класс зависит от базы данных, не следует писать обращение, которое взаимодействует с базой данных для тестирования класса. Вместо этого создайте абстрактный интерфейс вокруг этого соединения с базой данных и реализуйте этот интерфейс с помощью макетного объекта.
• Стремитесь охватить все пути, проходящие через блок. Обратите особое внимание на условия цикла.
• Убедитесь, что вы используете систему контроля версий для отслеживания ваших тестовых сценариев.
• В дополнение к написанию обращений для проверки поведения, напишите обращения для обеспечения производительности кода.
• Выполняйте модульные тесты непрерывно и часто.

Еще одна причина

Допустим, у вас есть программа, состоящая из двух блоков, и единственный тест, который вы выполняете, - это системное тестирование. [Вы пропускаете модульное и интеграционное тестирование.] Во время тестирования вы обнаружите ошибку. Теперь, как вы будете определять причину проблемы?

• Причина ошибки в блоке 1?
• Причина ошибки в блоке 1?
• Причина ошибки в обоих блоках?
• Причина ошибки в интерфейсе между блоками?
• Причина ошибки в тесте или тестовом случае?

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