Что такое тестовый жгут? (Примеры)

Тестовая система в тестировании программного обеспечения

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

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

Зачем использовать тестовый жгут?

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

• Автоматизируйте процесс тестирования
• Выполнение тестовых наборов тестовых случаев
• Создание связанных отчетов об испытаниях
• Поддержка отладки
• Для записи результатов теста для каждого из тестов
• Помогает разработчикам измерять покрытие кода на уровне кода.
• Увеличение производительности системы за счет автоматизации
• Повышение качества программных компонентов и приложений.
• Для обработки сложных условий, которые тестировщикам трудно смоделировать.

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

Основные компоненты испытательного жгута

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

• Тестовые скрипты: Автоматизированные инструкции, описывающие необходимые шаги и ожидаемый результат, составленные в соответствии с... тестовый сценарий конвенций.
• Механизм выполнения тестов: Программа-исполнитель, которая считывает скрипты по порядку, разрешает зависимости и запускает последовательное или параллельное выполнение.
• Репозиторий тестовых данных: Входные значения хранятся вне скрипта в форматах CSV, JSON, XML или в предварительно заполненной базе данных, обычно заполняемой пользователем. инструменты генерации тестовых данных.
• Драйверы: Вспомогательные модули вызова, которые запускают тестируемый компонент, когда реальный верхний слой, например, пользовательский интерфейс, еще не завершен.
• Незавершённые версии: В качестве примера используются модули, вызывающие шаблонные ответы, например, платежный сервис, отвечающий «Платеж успешно пройден» без обращения в банк.
• Валидатор выходных данных: Логика проверки, которая сравнивает фактический результат с ожидаемым значением и помечает каждый случай как успешный или неудачный.
• Слой регистрации и отчетности: Отметки времени, скриншоты, вывод консоли и сводка о выполнении — всё это позволяет выявить каждую ошибку. tracЭто будет доступно позже.

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

Как работает тестовый жгут проводов?

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

1. Подготовьте среду: Монтажный модуль определяет конфигурацию окружающей среды, открывает соединения и загружает измерительные приборы, поэтому каждый запуск начинается с одного и того же известного состояния.
2. Загрузите тестовые скрипты: Скрипты, параметры и ожидаемые результаты считываются из репозитория. Во время выполнения ничего не вводится, что позволяет сравнивать результаты второго запуска с результатами первого.
3. Замените недостающие модули: Водители заменяют собой абонентов, которых еще нет, а талоны на оплату услуг обозначают услуги, которые еще не завершены, нестабильны или вызов которых обходится дорого.
4. Запустите тестируемое приложение: Механизм выполнения запускает описанный скриптом рабочий процесс, будь то вызов метода или что-либо еще. API запрос или взаимодействие с браузером.
5. Зафиксируйте фактический результат: Возвращаемые значения, данные ответа, строки базы данных, строки логов и состояние экрана записываются по мере их формирования.
6. Сравните с ожидаемыми результатами: Валидатор выходных данных проверяет каждое полученное значение. Любое несоответствие помечает случай как неудачный и записывает как ожидаемое, так и наблюдаемое значение.
7. Зарегистрировать и составить отчет: В жгуте проводов записывается метка времени. trace — результат выполнения, который генерирует отчет о прохождении/непрохождении, который разработчик может прочитать, не запуская ничего повторно.
8. Срывать: Временные данные, соединения и состояние заглушек очищаются, поэтому следующий случай не сможет унаследовать остатки от этого.

💡 Совет: Обновляйте свои заглушки всякий раз, когда меняется реальный модуль. Заглушка, которая по-прежнему отвечает в формате прошлого квартала, будет сообщать о положительном результате, в то время как интеграция в реальном времени уже не работает.

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

Есть два контекста, в которых используется Test Harness.

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

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

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

Типы испытательных жгутов

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

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

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

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

Инструменты для тестирования жгутов

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

• Юнит: Инструмент, используемый при использовании Java
• Нунит: Инструмент, используемый для использования .NET Framework

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

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

Тестовая система против тестовой среды

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

Часто задаваемые вопросы (FAQ)