В чем разница между модульными, функциональными, приемочными и интеграционными тестами?

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

вопрос задан 4.02.2011
Andrew
93274 репутация

8 ответов


  • 1269 рейтинг

    В зависимости от того, куда вы смотрите, вы получите несколько разные ответы. Я много читал на эту тему, и вот моя перегонка; опять же, они слегка шерстистые, и другие могут не согласиться.

    Юнит-тесты

    Проверяет наименьшую единицу функциональности, обычно метод / функцию (например, г. учитывая класс с определенным состоянием, вызов метода x в классе должен вызвать y). Модульные тесты должны быть сосредоточены на одной конкретной функции (например, г. вызов метода pop, когда стек пуст, должен вызвать InvalidOperationException). Все, к чему это касается, должно быть сделано в памяти; это означает, что тестовый код и тестируемый код не должны:

    • Вызов (нетривиальных) соавторов
    • Доступ к сети
    • Попадание в базу данных
    • Использовать файловую систему
    • Закрутить нить
    • и т. Д.

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

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

    Интеграционные тесты

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

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

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

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

    Функциональные испытания

    Функциональные тесты проверяют правильность определенной функции, сравнивая результаты для данного ввода со спецификацией. Функциональные тесты не касаются промежуточных результатов или побочных эффектов, а только результата (их не волнует, что после выполнения x объект y имеет состояние z). Они написаны для проверки части спецификации, такой как «вызов функции Square (x) с аргументом 2 возвращает 4».

    Приемочные испытания

    Приемочные испытания, похоже, делятся на два типа:

    Стандартные приемочные испытания включают в себя выполнение испытаний всей системы (например, г. используя веб-страницу через веб-браузер), чтобы увидеть, удовлетворяет ли функциональность приложения спецификации. E. г. "нажатие на значок масштабирования должно увеличить вид документа на 25%. «Нет никакого реального континуума результатов, просто результат или неудача.

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

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

    Заключение

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

    ответ дан Mark Simpson, с репутацией 20662, 5.02.2011
  • 77 рейтинг

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

    Недавно я наткнулся на систему именования Google для их тестов, и мне она очень понравилась - они обходят аргументы, просто используя Small, Medium и Large. Чтобы решить, к какой категории относится тест, они учитывают несколько факторов: сколько времени требуется для запуска, имеет ли он доступ к сети, базе данных, файловой системе, внешним системам и так далее.

    http: // googletesting. Blogspot. ком / 2010/12 / тест-размеры. HTML

    Я полагаю, что разница между Малым, Средним и Большим для вашего текущего рабочего места может отличаться от Google.

    Однако речь идет не только о сфере, но и о цели. Мнение Марка о различных перспективах испытаний, e. г. Программист против клиента / конечного пользователя, это действительно важно.

    ответ дан testerab, с репутацией 1214, 5.02.2011
  • 56 рейтинг

    http: // martinfowler. com / статьи / микросервис-тестирование /

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

    Я процитирую из его краткого слайда:

    • Юнит-тесты - используйте мельчайшие части тестируемого программного обеспечения в приложении, чтобы определить, ведут ли они себя должным образом.
    • Интеграционные тесты - проверка путей связи и взаимодействия между компонентами для выявления дефектов интерфейса.
    • Тесты компонентов - ограничивают область действия используемого программного обеспечения частью тестируемой системы, манипулируя системой посредством внутренние интерфейсы кода и использование двойников теста для изоляции кода тестируется от других компонентов.
    • Контрактные тесты - проверяют взаимодействие на границе внешней службы, утверждая, что она соответствует контракту, ожидаемому потребителем оказание услуг.
    • Сквозные тесты - проверка соответствия системы внешним требованиям и достижения поставленных целей, тестирование всей системы, от концы с концами.
    ответ дан Maxim, с репутацией 5893, 21.02.2015
  • 4 рейтинг
    Модульное тестирование

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

    Интеграционный тест

    : объединение всех модулей и тестирование приложения для проверки правильности работы связи и потока данных между модулями. Это тестирование также проводится разработчиками.

    функциональный тест проверка функциональности отдельных приложений означает функциональное тестирование

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

    ответ дан malini, с репутацией 117, 26.04.2014
  • 4 рейтинг

    Я объясню вам это с практическим примером и без теории вещи:

    Разработчик пишет код. GUI пока не реализован. Тестирование на этом уровне проверяет, что функции работают правильно и типы данных являются правильными. Этот этап тестирования называется модульным тестированием.

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

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

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

    ответ дан fahad shaikh, с репутацией 78, 12.02.2015