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


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

Уровни тестирования программного обеспечения

Содержание Разработка

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

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

Аналогия

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

Метод

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

Задачи

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

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

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

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

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

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

Выгоды

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

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

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

  • Причина ошибки в блоке 1?
  • Причина ошибки в блоке 1?
  • Причина ошибки в обоих блоках?
  • Причина ошибки в интерфейсе между блоками?
  • Причина ошибки в тесте или тестовом случае?
Модульным тестированием часто пренебрегают, но на самом деле это самый важный уровень проверки вашей программы.
Автор этого материала - я - Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML - то есть могу доработать ваш сайт или помочь с веб-программированием. Пишите сюда.

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




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




Баланс и DRY (Don't Repeat Yourself)
Лабиринты Java, часть 2: класс Waypoint
Консультация и быстрая помощь по сайту онлайн