Как объяснить единичное, функциональное, приемочное и интеграционное тестирование в одном примере / сценарии?

Question

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

У нас есть теория, но практические примеры могут помочь понять концепции дальше.

Answer 1

Я собираюсь объяснить различные уровни тестирования на примере ниже.

Майк Кон в своей книге «Успех с Agile» предложил « Testing Pyramid » как способ приблизиться к автоматизированным тестам в проектах.

Модель объясняет, какие виды автоматических тестов необходимо создать, как быстро они могут дать отзыв о тестируемом приложении и кто пишет эти тесты. В принципе, для любого проекта необходимо 3 уровня автоматизированного тестирования. Они следующие:

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

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

Исторически разработчик пишет эти тесты, так как они обычно пишутся на том же языке программирования, что и программное приложение. Для этой цели используются платформы модульного тестирования, такие как JUnit и NUnit (для Java), MSTest (для C # и .NET) и Jasmine / Mocha (для JavaScript).

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

API / Интеграционные тесты - Они тестируют различные компоненты системы программного обеспечения вместе. Компоненты могут включать тестирование баз данных, API (Application Programming Interface), сторонних инструментов и сервисов вместе с приложением.

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

Исторически разработчик или технический QA писал бы эти тесты, используя различные инструменты, такие как Postman, SoapUI, JMeter и другие инструменты, такие как Testim.

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

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

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

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

Самое большое ограничение тестов пользовательского интерфейса, они относительно медленны по сравнению с тестами уровня и уровня API. Таким образом, он должен составлять всего 10-20% от общего количества автоматизированных тестов.

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

-Raj

Testim

Answer 2

Для практического примера давайте рассмотрим платформу электронной коммерции, которая продает одежду в Великобритании.Вот пара требований для этого примера:

• Покупатель может выбрать одежду (правильного размера) и положить ее в корзину
• Налог облагается только взрослой одеждой (НДС)), детская одежда освобождается от уплаты налога.
• Покупатель может оплатить кредитной картой

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

Единица

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

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

Обычно это выполняется командой разработчиков.

Функциональный

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

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

Обычно это делается командой QA.

Acceptance

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

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

Обычно это делаетсявладельцем бизнеса.

Интеграция

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

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

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