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

Функциональное тестирование и интеграционное тестирование - это одно и то же?

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

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

Функциональное тестирование - это проверка системы на соответствие функциональным требованиям продукта. Менеджмент продукта / проекта обычно записывает их, а QA формализует процесс того, что пользователь должен увидеть и испытать, и каким должен быть конечный результат этих процессов. В зависимости от продукта это можно автоматизировать или нет.

Функциональное тестирование :

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

Например: страница входа в систему.

вы предоставляете имя пользователя и пароль, вы проверяете, ведет ли он вас на домашнюю страницу или нет.

Интеграционное тестирование :

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

Например: отправка электронной почты

Вы отправляете кому-то одно письмо, есть поток данных, а также изменение в базе данных (отправленная таблица увеличивает значение на 1)

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

Надеюсь, это вам помогло.

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

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

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

Но как насчет огромного пространства между ними?

• Например, что, если вы протестируете немного больше, чем CUT? Что, если вы включите функцию Фибоначчи вместо того, чтобы использовать приспособление, которое вы ввели? Я бы назвал это функциональным тестированием , но мир со мной не согласен.
• Что если включить time()или rand()? А если позвонить http://google.com? Я бы назвал это системным тестированием , но опять же, я один.

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

Я провожу тесты по 3 осям, со всеми их нулями при модульном тестировании :

1. Функциональное тестирование: использование реального кода все глубже и глубже в стеке вызовов.
2. Интеграция тестирования: все выше и выше вверх ваш вызов в стек; другими словами, тестирование вашего CUT путем запуска кода, который будет его использовать.
3. Системное тестирование: все больше и больше неповторимых операций (планировщик O / S, часы, сеть и т. Д. )

В тесте легко может быть все три, в разной степени.

Функциональное тестирование: это процесс тестирования, при котором проверяется каждый компонент модуля. Например: если веб-страница содержит текстовое поле, необходимо проверить компоненты радиоботона, кнопок и раскрывающегося списка и т. Д.

Интеграционное тестирование: процесс, в котором проверяется поток данных между двумя модулями.

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

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

Когда дело доходит до интеграционного тестирования, это взаимодействие между модулями. Если модуль A отправляет ввод, модуль B может его обработать или нет.

Интеграционное тестирование - Интеграционное тестирование - это не что иное, как тестирование различных модулей. Вы должны проверить взаимосвязь между модулями. Например, вы открываете facebook, затем вы видите страницу входа после ввода идентификатора входа и пароля, вы можете видеть домашнюю страницу facebook, поэтому страница входа - это один модуль, а домашняя страница - другой модуль. вы должны проверить только взаимосвязь между ними, значит, когда вы вошли в систему, должна быть открыта только домашняя страница, а не окно сообщений или что-то еще. Существует 2 основных типа интеграционного тестирования: подход TOP-DOWN и подход BOTTOM UP.

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

В функциональном тестировании тестер фокусируется только на функциональности и подфункции приложения. Функциональность приложения должна работать или нет.

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

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

Функциональное тестирование: - Тестирование в основном делится на две категории: 1. Функциональное тестирование 2. Нефункциональное тестирование ** Функциональное тестирование: - Чтобы проверить, работает ли программное обеспечение в соответствии с требованиями пользователя или нет. ** Нефункциональное тестирование: - Чтобы проверить, соответствует ли программное обеспечение критериям качества, таким как стресс-тест, тест безопасности и т. Д.

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

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

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

Авторы по этому поводу расходятся. Я не верю, что это "правильное" толкование. Это действительно зависит от обстоятельств.

Например: большинство разработчиков Rails рассматривают модульные тесты как модельные тесты, функциональные тесты как тесты контроллеров и интеграционные тесты как те, которые используют что-то вроде Capybara для изучения приложения с точки зрения конечного пользователя, то есть навигации по сгенерированному HTML странице с использованием DOM. проверить ожидания.

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

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