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

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

724
definition terminology testing

8 ответов

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

Тесты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вывод

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

1269

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

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

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

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

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

77

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

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

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

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

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

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

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

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

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

25

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

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

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

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

  4. интеграционное тестирование: блоки кода (объясненные в пункте 1) интегрированы друг с другом для завершения проекта. Эти единицы кодов могут быть написаны в другой технологии кодирования или могут иметь другую версию, поэтому это тестирование выполняется разработчиками для обеспечения того, чтобы все единицы из кода совместимы с другими, и нет никакой проблемы интеграции.

16
5

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

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

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

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

4

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

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

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

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

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

4