Что такое тестирование интерфейса? Типы и примеры

Что такое тестирование интерфейса?

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

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

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

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

Как провести тестирование интерфейса

Тестирование интерфейса включает в себя тестирование двух основных сегментов:

1. Интерфейс веб-сервера и сервера приложений
2. Интерфейс сервера приложений и сервера базы данных.

Для вышеупомянутых сценариев тестирование интерфейса выполняется для

• Проверьте, работают ли серверы правильно или нет.
• Ошибки обрабатываются правильно или возвращают сообщение об ошибке для любого запроса, сделанного приложением.
• Проверьте результаты, когда соединение с веб-сервером сбрасывается между

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

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

Пример тестирования интерфейса

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

С помощью этих спецификаций мы можем создать образцы входных XML-файлов и передать их в интерфейс. А затем проверка входного (XML) и выходного (JSON) файла с требованием — тестирование интерфейса.

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

Зачем проводить тестирование интерфейса

Тестирование интерфейса завершено.

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

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

Виды тестирования интерфейса

Во время тестирования интерфейса выполняются различные типы тестирования интерфейса, которые могут включать

• Процедура: Это гарантирует, что механизм интерфейса обрабатывает ваши стандартные рабочие процессы должным образом.
• Крайние случаи — неожиданные значения: Это учитывается при тестировании, включающем обратные даты, месяц и день.
• Тестирование производительности, нагрузки и сети: Для интерфейса с большим объемом данных может потребоваться больше ресурсов. испытание нагрузкой чем малообъемный интерфейс, в зависимости от механизма интерфейса и инфраструктуры подключения
• Индивидуальные системы: Это включает в себя тестирование каждой системы индивидуально. Например, биллинговая система и система управления запасами для розничного магазина должны иметь возможность работать отдельно.

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

Стратегия тестирования интерфейса

Стратегия тестирования интерфейсов — это метод, используемый для тестирования интерфейсов с помощью общих тестов независимо от реализации. Мы можем использовать абстракции.tracСоздайте тестовые примеры и конкретные экземпляры тестового примера для каждой реализации стратегии тестирования интерфейса. Базовый/абсолютныйtracТестовые примеры выполняют независимые от реализации тесты, в то время как конкретные тесты занимаются созданием экземпляров объектов для тестирования и выполнением тестов, специфичных для реализации.

Преимущество такой структуры заключается в повторном использовании. Когда появляется третья реализация того же интерфейса, абсолютноеtracПакет программ t suite работает с ним без изменений, и нужно написать только код для создания экземпляров. Та же идея применяется в более крупном масштабе в тестирование компонентовгде общий участникtracТест T Suite запускается для каждого компонента, который, как утверждается, соответствует требованиям теста.

Инструменты тестирования интерфейса

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

• API-клиенты и конструкторы запросов: Инструменты, такие как Postman, SoapUIInsomnia и Hoppscotch отправляют REST, SOAP или GraphQL-запросы, сохраняют их в виде многократно используемых коллекций и проверяют коды состояния, заголовки и тела ответов.
• CodeБиблиотеки тестов уровня: Библиотеки, работающие внутри существующего набора тестов, позволяют выполнять проверки интерфейса параллельно с модульными тестами и при каждой сборке, что предотвращает их устаревание.
• Инструменты загрузки и протоколирования: Такой инструмент, как JMeter использует один и тот же интерфейс в больших объемах, что и превращает функциональную проверку в тестирование производительности связи.
• Виртуализация сервисов и имитация объектов: Заглушка, заменяющая собой дальний конец, позволяет проверить одну сторону, пока другая недоступна, не завершена или слишком дорога для многократных звонков.

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

Контрольный список и лучшие практики тестирования интерфейсов

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

• В лице tracт первый: Убедитесь, что схемы запроса и ответа соответствуют опубликованной спецификации, поле за полем, включая типы данных и необязательные поля.
• Граничные значения: Отправка пустых данных, полей максимальной длины, неожиданных наборов символов и обратных форматов дат.
• Пути возникновения ошибок: Убедитесь, что каждая ошибка возвращает осмысленный код и сообщение, а не стек вызовов. tracили тихий успех.
• Тайм-ауты и повторные попытки: Прервите соединение в середине запроса и подтвердите, что вызывающая сторона безопасно повторит попытку, не дублируя транзакцию.
• Безопасность: Проверьте аутентификацию, авторизацию и шифрование по ссылке и убедитесь, что сообщения об ошибках не раскрывают внутреннюю информацию.
• Согласованность данных: Прочитайте запись с обратной стороны и убедитесь, что ничего не было усечено, перекодировано или изменено в процессе передачи.
• Объем: Повторите вызов с наибольшим трафиком при одновременной нагрузке и следите за исчерпанием пула соединений.

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

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

Тестирование интерфейса против интеграционного тестирования

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

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

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