Когда к модульному тесту по сравнению с ручным тестом

Просто для уточнения что-то многие люди, кажется, отсутствует:

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

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

"Автоматизированное" тестирование обычно относится к высокоуровневой интеграции/принятию/функциональным испытаниям - Вы можете делать TDD вокруг этого уровня тестирования, и это часто - единственная опция для в большой степени ui-driven код, но необходимо знать, что этот вид тестирования более хрупок, тяжелее к тесту записи сначала и никакой замене для поблочного тестирования.

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

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

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

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

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

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

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

Реальный пример 1:

разработчик А создавал отчет, который мы отображаем на нашей интранет для менеджеров. Было много формул, все из которых разработчик протестировал, прежде чем код прибыл в QA. Мы проверили, что формулы, действительно, производили корректный вывод. Что мы попросили, чтобы разработка для исправления, почти сразу, была тем, что числа были отображены в розовом на фиолетовом фоне.

Реальный пример 2:

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

Самая хорошая точка (IMO) автоматизированных модульных тестов - то, что, когда Вы изменяетесь (улучшаются, осуществить рефакторинг) существующий код, легко протестировать это, Вы не повредили его. Это было бы утомительно для тестирования всего вручную снова и снова.

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

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

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

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

Модульные тесты могут только пойти до сих пор (как может все другие типы тестирования). Я считаю тестирование как своего рода процесс "решета". Каждый другой тип тестирования похож на решето, которое Вы помещаете при выходе Вашего процесса разработки. Материал, который выходит, является (надо надеяться), главным образом функциями Вашего программного продукта, но он также содержит ошибки. Ошибки прибывают в большое количество различных форм и размеров.

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

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

Согласно исследованиям различных проектов (1), Модульные тесты находят 15.. 50% из дефектов (среднее число 30%). Это не делает их худшим средством поиска ошибки в Вашем арсенале, но не серебряной пулей также. Там никакие серебряные пули, любая хорошая стратегия QA состоит из нескольких методов.

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

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

Dev по сравнению с Тестерами Разработчики известно плохи при тестировании их собственного кода: причины являются психологическими, техническими и длятся не в последнюю очередь экономичный - тестеры являются обычно более дешевыми, чем разработчики. Но разработчики могут внести свой вклад и сделать тестирование легче. TDD делает тестирование внутренней части конструкции программы, не только запоздалой мысли, которая является истинным значением TDD.

Другой интересный момент о тестировании: в 100%-м покрытии нет никакого смысла. Статистически, ошибки следуют 80:20 правило - большинство ошибок найдено в маленьких разделах кода. Некоторые исследования предполагают, что это еще более резко - и тесты должны focuse на местах, где ошибки поднимаются.

(1) Производительность Программирования Jones 1986 США, заключенный в кавычки из Кода, Завершенного, 2-го. редактор, Но как другие сказал, единица , тесты являются только одной частью тестов, интеграция, регрессионные тесты и тестирование системы могут быть - в leat частично - автоматизированы также.

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

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

этот код делает то, что я думаю, что он делает?

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

отдельная тестовая команда должна ответить на другой question:-

, эта система делает то, что я (и конечные пользователи) ожидаю, что это сделает? Или это удивляет меня?

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

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

Ручное тестирование требует огромного количества времени (по сравнению с TDD) и страдает от человеческой ошибки.

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

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

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

Обновление 2: Поблочное тестирование не является излишеством для маленького проекта, и при этом автоматизация не является TDD использования или испытаниями с помощью дыма. То, что является излишеством, имеет команду, делающую любое из этого в их первый раз на маленьком проекте. Выполнение любого из тех имеет связанную кривую обучения (специально поблочное тестирование или TDD), и не всегда будет делаться правильно сначала. Вы также хотите кого-то, кто делал, это некоторое время включило, чтобы помочь избежать ловушек и получить прошлое некоторые проблемы кодирования, которые не очевидны при запуске на нем. Проблема - то, что командам не свойственно иметь эти навыки.

Каждое приложение тестируется.

Некоторые приложения тестируются в форме, делает мою компиляцию кода и делает код, появляются к [1 110] функция .