Основные шаги для тестирования API

Вообще говоря, основные этапы тестирования API в основном включают следующие три шага:

1. Подготовить тестовые данные;

2. Инициировать запрос к тестируемому API с помощью общего или самостоятельно разработанного инструмента тестирования API;

3. Проверьте ответ возвращенного результата.

Обычно используемые инструменты тестирования API включают инструмент командной строки cURL, инструмент графического интерфейса Postman или SoapUI и JMeter, который поддерживает тестирование производительности API.

Примеры сложных сценариев API

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

Сценарий 1: последовательные вызовы API

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

Сценарий 2. Шифрование интерфейса API

Чтобы обеспечить безопасность интерфейса API, взаимный доступ между системами и модулями в системе должен быть зашифрован.Обычно используемые методы шифрования: DES, AES, RSA, MD5 и т. д. Методы шифрования каждой системы различны (вызывающий интерфейс и провайдер интерфейса). Это может быть согласовано), а это означает, что тестирование API должно поддерживать различные методы автоматического шифрования. Некоторые системы также возвращают зашифрованные ответные сообщения, которые также необходимо идентифицировать и расшифровать.

Сценарий 3: Асинхронное тестирование API

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

Сценарий 4: Внешние зависимости в тестировании API

APIA вызывает APIB, а B недоступен.Необходимо подумать, как проверить APIA. Например, платежная система зависит от трехсторонних платежных каналов и банков. Не все три стороны поддерживают тестовую среду. Основная идея для решения этой проблемы — создать MockServer и попытаться сделать его максимально универсальным. Мы разработали фиктивная система-aMock. Введите информацию об интерфейсе через страницу, сохраните ее в базе данных, получите доступ к настроенному фиктивному интерфейсу через Nginx, равномерно обработайте информацию о запросе в фоновом режиме, а затем сопоставьте конкретную информацию ответа с помощью URL-адреса и характеристик сообщения. .

Платформа для тестирования API

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

КУСОЧЕК:Тест бизнес-интерфейса (BusinessInterfaceTest)

СУТ:Тестируемая система (SystemUnderTest)

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

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

Валидатор:Проверка инкапсуляции полей ответа интерфейса и полей базы данных.

Управление рисками:Обработка контроля рисков, поскольку она будет включать выплату реальных средств, требует встроенных правил контроля рисков для обеспечения безопасности средств и контролируемых рисков.

Таймер:Службы запланированных задач, в том числе

1) В варианте использования последовательного API — оценка состояния предыдущего варианта использования;

2) Проверка базы данных асинхронного API;

3) Оценка состояния отказа варианта использования API тайм-аута;

4) Запланированные задачи, которые должны выполняться регулярно.

Мок-сервер:Служба имитации внешней системы, от которой зависит вариант использования.

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

БД:Храните данные тестового примера и соответствующие тестовые задачи, данные отчета о тестировании и конфигурации проекта.

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

Подготовка тестовых данных

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

<accountName>${accountName}</accountName>

<accountNo>${accountNo}</accountNo>

<identNo>${identNo}</identNo>

DataProvider предоставляет несколько ключевых узлов данных.Чтобы увеличить покрытие тестами, в базе данных есть несколько похожих тестовых данных, таких как несколько четырехэлементных данных (номер банковской карты, номер мобильного телефона, идентификационный номер, имя). необходимо прочитать большое количество вариантов использования, его можно сохранить в кеше и прочитать в cList. Благодаря циклу все тестовые данные могут быть прочитаны равномерно. Ниже приведен фрагмент кода, который заменяет ключевые узлы данных и назначает данные cList в соответствующие переменные по очереди.

Логическое управление выполнением теста

Тесты во многих случаях представляют собой сценарные тесты API, включающие последовательные вызовы вариантов использования. Как показано на рисунке ниже, «signing-success-kftn-agreement» зависит от выполнения «signing-success-kftn SMS»; настройте отношение ассоциации при добавлении вариантов использования.

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

Запланированная задача выполняется раз в минуту. Следующий абзац предназначен для оценки статуса выполнения предварительного API. Только "0000" означает успех, текущий API может быть выполнен. При выполнении данные результата предварительного варианта использования должны быть прочитаны и переданы; в случае сбоя предварительного API выполнение задачи будет остановлено. То же самое верно для последовательного выполнения нескольких вариантов использования API. Даже если есть внешне зависимые варианты использования, такие как SMS коды подтверждения, мы можем автоматически загрузить коды подтверждения SMS на сервер, написав программу мобильного приложения, а затем вызвать задержку.Получите код подтверждения, запишите статус и результаты выполнения варианта использования через БД и передайте его в следующий API для завершения последовательного выполнения нескольких вариантов использования. Кроме того, выполнение тестовых заданий инкапсулировано в restful-интерфейс, который можно более гибко комбинировать с разрабатываемой в настоящее время командой CICD-системой.

Валидация результатов испытаний

При анализе бизнеса проверка результатов API грубо делится на два типа: проверка ответов и проверка базы данных. Проверка ответа — это проверка поля сообщения ответа, которое может быть точно или нечетко сопоставлено с помощью регулярных выражений; проверка базы данных основана на задачах, рассчитанных по времени, и метод проверки должен быть установлен в прецеденте в соответствии с согласованным форматом, таким как как следующий sql. Чтобы проверить условие, в квазипроизводственной среде укажите номер заказа и другие условия для запроса возвращаемого поля и оцените, равен ли статус 7, чтобы определить, является ли вариант использования успешным.

PreOnline.3|,|SELECTtb.outer_batch_no,tb.status,bs.send_statusFROM

bs_outpay.trans_batchtbleft joinbs_outpay.es_business_sendbsontb.business_batch_no=bs.entity_uuidandbs.entity_status<>2 WHEREtb.outer_batch_noin (?) order bytb.CREATED_TIMEDESC|,|{"status":"7"}

Статус варианта использования делится на четыре состояния: успех, сбой, обработка и тайм-аут. Они сопоставляются путем настройки соответствующих условий SQL-запроса. Успех и сбой являются конечными состояниями. При обработке для продолжения запроса требуется запланированная задача. Тайм-аут — это наша внутренняя настройка. Состояние , в настоящее время прошло более часа, а конечное состояние установлено на тайм-аут. Этот вариант использования API дает сбой и вызывает тревогу, и для его просмотра требуется ручное вмешательство. Все эти правила добавляются при создании и редактировании варианта использования. Как показано на рисунке ниже, вариант использования включает проверку ответа (проверка значения, проверка ключа) и проверку базы данных. Сценарии тестирования API. Следует отметить, что многие приложения не позволяют внешним тестовым платформам напрямую обращаться к базе данных.Наше решение состоит в том, чтобы написать сервис запроса данных и развернуть его в системной среде (между сервисами) доверенными.

Вообще говоря, тестовую платформу или фреймворк можно понимать как набор цепочек инструментов определенного уровня.В процессе разработки этой платформы стек технологий, который мы используем, включает в себя springmvc+herbinate для логического управления, AmazingUI для управления вариантами использования и echart для отображения результатов, а также использовать Jenkins для планирования задач и т. д. Пользователи являются тестировщиками каждого направления бизнеса, им не нужно знать реализацию конкретного кода, но они должны хорошо понимать систему правила структуры и вариантов использования, чтобы они могли разрабатывать варианты использования, соответствующие сценариям тестирования.

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

-END-

автор:Сунь Ин Источник: Технологический институт CreditEase.