Многие компании в разной степени спрашивают : « Вы когда-нибудь понимали TDD ?» Используя этот процесс разработки, интервьюер также будет использовать ваше описание этой относительно «незнакомой» концепции, чтобы понять, насколько вы знакомы с некоторыми концепциями, связанными с тестированием, и пониманием идей тестирования.
Что такое TDD (разработка через тестирование)?
Введение разработки через тестирование в энциклопедии выглядит следующим образом: разработка через тестирование, полное английское название Test-Driven Development, называемое TDD, это новый метод разработки, отличный от традиционного процесса разработки программного обеспечения . Требуется написать тестовый код перед написанием кода определенной функции, а затем написать только код функции, который проходит тест, и продвигать всю разработку через тест. Это помогает писать чистый, удобный и качественный код и ускоряет процесс разработки.
Разработка через тестирование - это не метод, который был разработан только в последние годы. Впервые эта идея начала практиковаться в методологии экстремального программирования. Существует много "экстремального программирования", "непрерывной интеграции", "есть разные углы внедрения" . в книге "Разработка через тестирование".
Проще говоря, разработка через тестирование — это гибкая практика разработки для некоторых небольших функциональных точек или даже таких небольших, как метод. Традиционный режим разработки заключается в том, что разработчики начинают писать сценарии модульных тестов после написания бизнес-кодов для проверки кодов бизнес-функций на предыдущем шаге, в то время как основная идея разработки через тестирование заключается в том, чтобы сначала написать тестовые коды в соответствии с документами требований (которые то есть сначала напишите модульные тесты (скрипты)), и подумайте, как проверить реализацию этих бизнес-функций. После написания достаточного количества скриптов модульного тестирования продолжайте писать коды бизнес-функций. дело написано.Необходимые функциональные модули.
модульный тест
Концепция, полученная из вышеизложенного — модульное тестирование, вот краткое объяснение. Модульный тест обычно представляет собой независимый тест, написанный разработчиком для проверки каждой единицы кода, разработанной разработчиком при написании кода бизнес-функции. После завершения модульного теста разработчик выпустит отчет модульного тестирования и отчет о покрытии модульного теста, и тестировщику необходимо использовать приведенные выше отчеты в качестве основы для разработки функциональных тестовых случаев .
Процесс разработки через тестирование
Узлы основного процесса хорошо видны на следующей диаграмме цикла разработки, основанной на тестировании. Мантра разработки через тестирование: не запускай/запускай/рефакторинг.
Отличие разработки через тестирование от традиционной разработки
Сценарий модульного тестирования, написанный в традиционном режиме разработки, на самом деле предназначен для проверки функции, и это все еще форма тестирования. И разработка через тестирование больше не является простым поведением при тестировании, если быть точным, это поведение проектирования. Разработка через тестирование похожа на спецификацию дизайна, написанную для использования фрагмента кода, что видно по связности, тестируемости, возможности повторного использования, плотности дефектов и простоте интерфейса написанного кода. При разработке через тестирование анализ требований и понимание бизнес-функций пользователей являются прогрессивными и могут постепенно улучшаться до уровня кода, и этот процесс просто улучшает охват теста. вызваны ошибками проектирования бизнес-логики.
Плюсы и минусы разработки через тестирование
Из приведенной выше диаграммы циклов TDD также видно, что самым большим преимуществом разработки через тестирование является рефакторинг, непрерывная итерация, непрерывный рефакторинг существующего кода, непрерывная оптимизация внутренней структуры кода и, наконец, улучшение всего кода. . Таким образом, некоторая избыточность конструкции, избыточность кода, сложность интерфейса и т. д. постоянно уменьшаются.
Кроме того, для некоторых требований на ранней стадии, которые неясны или даже требуют очень мало информации, а позже будет большое количество изменений бизнес-функций, традиционная модель разработки должна работать сверхурочно, чтобы догнать разработку, тестирование, и ремонт дефектов.Сказал, самое главное качество продукции не может быть гарантировано. Конечно, этот режим также является наиболее подходящим для принятия метода прототипа и режима гибкой разработки, ведь цель гибкой разработки — принятие изменений. И разработка через тестирование также является основой гибкой модели разработки, так что будь то срочное требование от заказчика или техническая реформа проектной команды, ее можно реализовать путем рефакторинга дизайна и добавления тестовых сценариев.
Области применения разработки через тестирование
Вышеприведенный анализ имеет много преимуществ разработки через тестирование, но широкого применения в настоящее время не получил: во-первых, это изменение технологии или методов управления, которое необходимо постепенно доводить до сведения общественности, во-вторых, требует достаточных профессиональных навыков и опыт.Высококачественные таланты для обеспечения бесперебойного и профессионального процесса всего процесса;В-третьих, на ранней стадии требуется определенный объем инвестиций, а производимой продукции достаточно для решения проблем качества, эффективности и затраты, с которыми в настоящее время сталкивается большинство предприятий, поэтому выбор - это один шаг, и он может действительно строго соблюдаться редко.
конец
Короче говоря, если это происходит во время собеседования, вы можете шаг за шагом объяснить свое понимание разработки через тестирование с помощью вышеперечисленных аспектов. собственный личный опыт, который обязательно оставит у интервьюера хорошее впечатление о ясном мышлении и богатом опыте тестирования.
Напоследок хотелось бы поблагодарить всех, кто внимательно прочитал мою статью.Взаимность всегда нужна.Хоть это и не очень ценная вещь, но если надо, то можно забрать:
Эти материалы должны быть наиболее полным и полным подготовительным складом для [тестирования программного обеспечения] друзей. Этот склад также сопровождал десятки тысяч инженеров- испытателей в самом сложном путешествии, и я надеюсь, что он может помочь вам!