На нашем сайте мы используем cookie для сбора информации технического характера и обрабатываем IP-адрес вашего местоположения. Продолжая использовать этот сайт, вы даете согласие на использование файлов cookies. Здесь вы можете узнать, как мы пользуемся файлами cookies.
Модульное тестирование, также известное как компонентное тестирование - это уровень тестирования программного обеспечения, на котором проверяются отдельные блоки/компоненты программы. Цель состоит в том, чтобы проверить, что каждый блок приложения работает так, как задумано.
Блок - это самая маленькая тестируемая часть любого программного обеспечения. Он обычно имеет один или несколько входов и, как правило, один выход. В процедурном программировании единицей может быть индивидуальная программа, функция, процедура и т.д. В объектно-ориентированном программировании наименьшей единицей является метод, который может принадлежать базовому/суперклассу, абстрактному классу или производному/дочернему классу. (Некоторые рассматривают модуль приложения как единицу. Это может обескуражить, поскольку в этом модуле, вероятно, будет много отдельных блоков.) Фреймворки модульного тестирования, драйверы, заглушки и фиктивные/поддельные объекты используются для помощи в модульном тестировании.
Дефекты обычно устраняются сразу же, как только они обнаруживаются, и они официально не сообщаются и не отслеживаются.
Аналогия
В процессе изготовления шариковой ручки колпачок, корпус, хвостовик, чернильный картридж и шариковая ручка изготавливаются отдельно и проходят отдельные испытания.
Метод
Модульное тестирование обычно выполняется с использованием метода тестирования белого ящика и обычно автоматизируется.
Модульный тест [выполнить >> повторное выполнение]
Когда это делается?
Модульное тестирование-это первый уровень тестирования программного обеспечения, который выполняется перед интеграционным тестированием. Хотя модульное тестирование обычно выполняется после кодирования, иногда, особенно в тестовой разработке (TDD), автоматизированные модульные тесты пишутся до кодирования.
Кто этим занимается?
Обычно это делают сами разработчики программного обеспечения или их коллеги. В редких случаях это может быть сделано независимыми тестировщиками программного обеспечения, но они должны иметь доступ к коду и иметь представление об архитектуре и дизайне.
Выгоды
Модульное тестирование повышает уверенность в изменении/поддержании кода. Если будут написаны хорошие модульные тесты, и если они будут выполняться каждый раз, когда какой-либо код изменяется, мы сможем быстро поймать любые дефекты, возникшие из-за этого изменения. Кроме того, если коды уже сделаны менее взаимозависимыми, чтобы сделать возможным модульное тестирование, непреднамеренное влияние изменений в любом коде будет меньше.
Разработка идет быстрее. Как же так? Если у вас нет модульного тестирования, вы пишете свой код и выполняете этот нечеткий "тест разработчика" (вы устанавливаете некоторые точки останова, запускаете графический интерфейс, предоставляете несколько входных данных, которые, надеюсь, попадут в ваш код и надеетесь, что все готово.) Но если у вас есть модульное тестирование, вы пишете тест, пишете код и запускаете тест. Написание тестов требует времени, но это время компенсируется меньшим количеством времени, которое требуется для запуска тестов; вам не нужно запускать графический интерфейс и предоставлять все эти входные данные.
И, конечно же, модульные тесты более надежны, чем "тесты разработчика". Разработка происходит быстрее и в долгосрочной перспективе. Как же так? Усилия, необходимые для поиска и исправления дефектов, обнаруженных во время модульного тестирования, очень малы по сравнению с усилиями, необходимыми для исправления дефектов, обнаруженных во время тестирования системы или приемочного тестирования.
Стоимость устранения дефекта, обнаруженного в ходе модульного тестирования, меньше по сравнению с затратами на дефекты, обнаруженные на более высоких уровнях. Сравните стоимость (время, усилия, разрушение, унижение) дефекта, обнаруженного во время приемочных испытаний или когда программное обеспечение находится в производстве.
Отладка очень проста. При неудачном тестировании отлаживаются только последние изменения. При тестировании на более высоких уровнях изменения, внесенные в течение нескольких дней/недель/месяцев, проще отслеживаются.
Код более надежен. Почему? Я думаю, что нет необходимости объяснять это здравомыслящему человеку.
Советы
Создайте правильный план модульного тестирования. [Если не документально, то хотя бы в голове.]
Найдите инструмент автоматизации тестирования/фреймворк для вашего языка.
Создавайте тестовые примеры, фокусируясь на областях, которые больше всего влияют на поведение системы.
Изолируйте среду разработки от тестовой среды.
Используйте тестовые данные, близкие к реальным.
Перед устранением дефекта напишите или измените тест, который выявит дефект. Почему? Во - первых, вы позже сможете поймать дефект, если не исправите его должным образом. Во-вторых, ваш набор тестов теперь более полный. В-третьих, вы, скорее всего, будете слишком ленивы, чтобы написать тест после того, как вы уже исправили дефект.
Напишите тестовые случаи, которые не зависят друг от друга. Например, если класс зависит от базы данных, не следует писать обращение, которое взаимодействует с базой данных для тестирования класса. Вместо этого создайте абстрактный интерфейс вокруг этого соединения с базой данных и реализуйте этот интерфейс с помощью макетного объекта.
Стремитесь охватить все пути, проходящие через блок. Обратите особое внимание на условия цикла.
Убедитесь, что вы используете систему контроля версий для отслеживания ваших тестовых сценариев.
В дополнение к написанию обращений для проверки поведения, напишите обращения для обеспечения производительности кода.
Выполняйте модульные тесты непрерывно и часто.
Еще одна причина
Допустим, у вас есть программа, состоящая из двух блоков, и единственный тест, который вы выполняете, - это системное тестирование. [Вы пропускаете модульное и интеграционное тестирование.] Во время тестирования вы обнаружите ошибку. Теперь, как вы будете определять причину проблемы?
Причина ошибки в блоке 1?
Причина ошибки в блоке 1?
Причина ошибки в обоих блоках?
Причина ошибки в интерфейсе между блоками?
Причина ошибки в тесте или тестовом случае?
Модульным тестированием часто пренебрегают, но на самом деле это самый важный уровень проверки вашей программы.
Автор этого материала - я - Пахолков Юрий. Я оказываю услуги по написанию программ на языках Java, C++, C# (а также консультирую по ним) и созданию сайтов. Работаю с сайтами на CMS OpenCart, WordPress, ModX и самописными. Кроме этого, работаю напрямую с JavaScript, PHP, CSS, HTML - то есть могу доработать ваш сайт или помочь с веб-программированием. Пишите сюда.
заметки, теория программирования, тестирование
Программы на заказ
Отзывы
Контакты