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

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

Ответ 1

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

Тесты устройств

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

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

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

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

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

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

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

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

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

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

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

Приемочные тесты

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

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

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

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

Заключение

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

Ответ 2

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

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

http://googletesting.blogspot.com/2010/12/test-sizes.html

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

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

Ответ 3

http://martinfowler.com/articles/microservice-testing/

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

Я процитирую его сводный слайд:

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

Интеграционные тесты - проверьте пути связи и взаимодействия между компонентами для обнаружения дефектов интерфейса.

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

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

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

Ответ 4

Тестирование устройств - Как следует из названия, этот метод проверяет уровень объекта. Отдельные программные компоненты проверяются на наличие ошибок. Знание программы необходимо для этого теста, и тестовые коды создаются для проверки того, работает ли программное обеспечение так, как оно предназначено.

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

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

Тестирование интеграции - Отдельные модули, которые уже подвергнуты модульному тестированию, интегрированы друг с другом. Как правило, соблюдаются два подхода:

1) Сверху вниз 2) Снизу вверх

Ответ 5

Это очень просто.

Тестирование модулей. Это тестирование, фактически выполненное разработчиками, обладающими знаниями в области кодирования. Это тестирование выполняется на этапе кодирования, и оно является частью тестирования белого ящика. Когда программное обеспечение приходит для разработки, оно превращается в кусок кода или фрагменты кода, известные как единица. И индивидуальное тестирование этих модулей называется модульным тестированием, выполненным разработчиками, чтобы выяснить какие-то человеческие ошибки, такие как отсутствие охвата оператора и т.д.
Функциональное тестирование: это тестирование выполняется на этапе тестирования (QA), и оно является частью тестирования черного ящика. Фактическое выполнение ранее написанных тестовых случаев. Это тестирование действительно выполняется тестировщиками, они находят фактический результат любой функциональности на сайте и сравнивают этот результат с ожидаемым результатом. Если они обнаружили какое-либо несоответствие, то это ошибка.
Приемочное тестирование: знайте как UAT. И это фактически сделано тестером, а также разработчиками, командой менеджеров, авторами, писателями и всеми, кто участвует в этом проекте. Чтобы гарантировать, что проект, наконец, готов к доставке с ошибками.
Тестирование интеграции: единицы кода (объясненные в пункте 1) интегрированы друг с другом для завершения проекта. Эти единицы кода могут быть записаны в другой технологии кодирования или могут быть разных версий, поэтому это тестирование выполняется разработчиками для обеспечения совместимости всех единиц кода с другими, и нет никакой интеграции.

Ответ 6

Некоторые (относительно) недавние идеи против чрезмерного насмешливого и чистого модульного тестирования:

Ответ 7

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

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

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

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

Ответ 8

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

Разработчик пишет код. Пока нет графического интерфейса пользователя. Тестирование на этом уровне проверяет правильность работы функций и правильность типов данных. Эта фаза тестирования называется Unit testing.

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

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

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