Модульное тестирование или функциональное тестирование?[закрыто]

Question

Недавно я услышал о функциональном тестировании, а не о модульном тестировании.

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

Для меня это звучит только как проверка того, работает ли код, но так ли это надежно, как модульное тестирование?

Мне говорили, что по этому поводу существовало две школы мышления.Некоторые предпочли бы модульное тестирование, другие - функциональное.

Есть ли какие-нибудь хорошие ресурсы, ссылки, книги, какие-либо упоминания или кто-нибудь из вас, кто может объяснить и осветить мой путь по этому вопросу?

Спасибо!

Answer 1

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

• Модульное тестирование = проектирование приводов (с Разработка, основанная на тестировании, или TDD)
• Интеграционное тестирование = работают ли все части вместе
• Приемо-сдаточное тестирование клиента = соответствует ли оно требованиям клиента
• Ручное тестирование = часто охватывает пользовательский интерфейс;специализированные тестировщики могут найти то, чего не хватает автоматизации
• Нагрузочное тестирование = насколько хорошо система работает с реальными объемами данных

Между этими категориями существует некоторое совпадение;модульные тесты могут определять поведение, например.

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

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

Вы просили предоставить ресурсы;Я рекомендую книгу Роя Ошерова Искусство модульного тестирования с примерами в .NET.Хотя ни одна книга не идеальна, в этой дается много отличных советов по написанию хороших тестов.

Редактировать:А для написания тестов на основе существующего программного обеспечения ничто не сравнится с книгой Майкла Перса Эффективная работа с Устаревшим кодом.

Answer 2

Модульное тестирование по сравнению с функциональным тестированием не является xor, но скорее and.Модульное тестирование - это тестирование отдельных модулей, в то время как функциональное тестирование - это тестирование целого в интеграции (все ли модули работают вместе должным образом?).

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

Answer 3

Модульное тестирование проверяет единицы вашего кода (методы и т.д.), Чтобы убедиться, что они делают то, чего вы от них ожидаете.

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

Оба типа тестирования важны.

Редактировать:Чтобы добавить немного иной взгляд на то, что сказал gbjbaanb:

• Модульный тест = мой код работает
• Функциональный тест = мои дизайнерские работы
• Интеграционный тест = мой код правильно использует ваши сторонние материалы (базы данных и т.д.)
• Заводской приемо-сдаточный тест = моя система работает
• Приемочный тест сайта = ваш код отстой, это совершенно не то, о чем я просил !?!

Answer 4

• Модульный тест = самый низкий, детализированный уровень.
• Функциональный тест = средний, модульный уровень.
• Интеграционный тест = более высокий уровень приложения.
• Заводской приемо-сдаточный тест = посмотрите, как все это работает
• Приемо-сдаточный тест сайта = увидеть, как все это провалится :)

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

Answer 5

Функциональное тестирование, также называемое Тестирование системы, направлен на тестирование всей системы и проверку соответствия функциональным требованиям.

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

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

Answer 6

Модульное тестирование и функциональное тестирование дают два разных результата.

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

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

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

Если вы создаете, скажем, компонент database engine (или какой-либо другой продукт, который не обязательно ориентирован на пользователя), модульное тестирование может быть тем, что вам действительно следует сделать.

Answer 7

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

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

Answer 8

В большинстве работ по разработке есть место и тому, и другому.

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

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

Они находятся на разных уровнях, и следует использовать оба.