ПРИМЕРЫ интеграционного тестирования...
Хочу поблагодарить за вопросы, которые пишите мне для разбора.
И вот был следующий вопрос: "Добрый день! Подскажите, что значит высокоуровневые и низкоуровневые модули?" после того как я запостила информацию про расшифровку понятий. И тут я поняла, что общими фразами как-то понятно , но нет примеров... Согласны???

Давайте разберемся.

Интеграционное тестирование - тестирование связи между модулями и тестирование связи между частями ПО.

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

#Driver, #Stub - эмулируемые компоненты системы.

#Драйвер (Driver) - это заглушка, которая отправляет запросы к нашей тестируемой системе (или другим образом управляет).

#Заглушка (Stub) - это заглушка, которая получает запросы от системы и отправляет какой-то "вшитый" ответ.

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

#Заглушки используются при тестировании сверху вниз, когда основной модуль готов к тестированию, но подмодули еще не готовы. Таким образом, на простом языке заглушки - это «вызываемые» программы, которые вызываются для проверки функциональности основного модуля.
Например, в ситуации, когда у одного есть три разных модуля: Login, Home, User. Предположим, модуль входа в систему готов к тестированию, но два второстепенных модуля Home и User, которые вызываются модулем входа, еще не готовы для тестирования. В это время написан кусок фиктивного кода, который имитирует вызываемые методы Home и User. Эти фиктивные фрагменты кода являются заглушками.
Или
Например, ситуация, в которой веб-приложение готово, но база данных ещё не готова, и вместо базы данных делают временно заглушку. Вместо базы данных будет использована заглушка.


#Драйверы являются «вызывающими» программами. Драйверы используются при восходящем тестировании (Снизу вверх). Драйверы - это фиктивный код, который используется, когда подмодули готовы, но основной модуль еще не готов. Возьмем тот же пример, что и выше. Предположим, на этот раз модули User и Home готовы, но модуль Login не готов к тестированию. Теперь, когда Home и User возвращают значения из модуля Login, создается фиктивный фрагмент кода, имитирующий модуль Login. Этот фиктивный код затем называется Driver.

Пример: https://ru.qaz.wiki/wiki/Test_stub

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

#теория https://news.1rj.ru/str/protestinginfo/427

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

Повторяем. Обязательно продолжу тестирование по этой теме.

Привет всем! Так, извиняюсь за задержку, задач по работе в Сбере стало больше.
Каждый день по 2 консультации с менти на разбор разных тем. Стараюсь также успевать проверять домашки, ещё 4 работы в ожидании. Конечно, сейчас с поиском работы сложновато, и все же не сдаёмся, главное закреплять свои знания каждый день!
Сейчас обещанные тесты по теме «Третования».
Кстати я разместила свой пост на vc.ru, хотя вы с этой уже информацией ознакомлены, просто собрала все шаблоны по API в одном месте.
Шаблоны тест-кейсов по API, тест-кейсы по идемпотентности

Для ознакомления как составлять «Сценарий использования».Хочу сказать, что на наших проектах для описания функциональных требований используется Сценарий Использования.

В тему требований 😂