Автор: Сад Латиао
В основном он делится учебными ресурсами по тестированию, которые помогут вам быстро понять индустрию тестирования, а также помогает новичкам, которые хотят сменить карьеру, продвинуться по карьерной лестнице и стать старшими инженерами по тестированию.
1. Предисловие
Когда я раньше не занимался тестированием интерфейсов, я имел слабое представление о концепции тестирования интерфейсов. Я мог полагаться только на Baidu для проверки различных примеров интерфейсов, но тогда это было бесполезно в моей работе. В настоящее время доступны все виды интерфейсов. После этого я наконец получил практическое понимание. Поскольку это всего лишь функциональный тест интерфейса, в настоящее время я использую для тестирования Postman, что относительно просто. Конечно, это всего лишь введение в тестирование интерфейса. То, что я понимаю, — это только верхушка айсберга. , мы будем усердно работать, чтобы приблизиться к давлению интерфейса, производительности интерфейса и автоматизации интерфейса.
2. Теория интерфейса
Интерфейс, о котором мы часто говорим, — это API, а тестирование интерфейса — это тест, проверяющий интерфейсы между компонентами системы. Тестирование интерфейсов в основном используется для обнаружения точек взаимодействия между внешними системами и системами, а также между внутренними подсистемами. Целью тестирования является проверка обмена данными, процессов передачи и контроля управления, а также взаимных логических зависимостей между системами и т. д.
По сути, тестирование интерфейса ничем не отличается от обычного функционального тестирования. Разница в том, что функциональное тестирование заключается в вводе значений на странице и отправке данных для просмотра результатов, в то время как тестирование интерфейса не использует адрес вызова. документ спецификации интерфейса, параметры запроса и соединение сообщения, а затем отправьте запрос и проверьте возвращенные результаты.
3. Примеры интерфейса
1. ПОСТ
Для отправки данных используются POST-запросы. В качестве примера следующая система XX выделяет перерабатывающие предприятия.
1. Требования к документу PRD менеджера по продукту следующие (изменения в интерфейсе назначенного перерабатывающего предприятия следующие):
1) В интерфейс фабрики обработки распределения добавляется новое поле идентификатора фабрики, которое является целочисленным типом и является необязательным;
2.) Если список комплектации заказов утвержден, статус ожидания утверждения может быть присвоен только перерабатывающему заводу. В противном случае появится сообщение: «Список комплектации заказов не ожидает утверждения, и перерабатывающее предприятие не может быть назначено».
2. Интерфейсный документ разработчика выглядит следующим образом:
Имя интерфейса: Интерфейс завода по переработке распределения системы XX
Путь интерфейса: POST
/process/requisitionOrder/updateDistributeStatus
Параметры запроса:
Headers:
Body:
{
"factoryId": "123",//Идентификатор перерабатывающего завода
"factory": «XX Одежда», // Название перерабатывающей фабрики.
"produce_order_id": [//Производственный заказ (чисто цифровой) Используйте несколько раз, отдельно
1134360
]
}
Возвратные данные:
{
"msg": "success",
"code": "0",
"info": «Операция прошла успешно»
}
3. Примеры тестов тестировщиков следующие:
4. Тестировщики выполняют тестовые случаи следующим образом:
1) Откройте Postman и заполните информацию об интерфейсе. Конкретная операция показана на рисунке.
Примечание. URL-адрес в документе интерфейса не содержит адрес среды, поэтому при копировании URL-адреса в адресную строку необходимо добавить адрес среды, например адрес тестовой среды + URL-адрес интерфейса.
Конечно, если имеется несколько сред, вы можете использовать функцию настройки среды. Конкретные шаги настройки описаны в шаге 4).
2) В сочетании с тестовым примером после объединения информации о параметрах преобразования проверьте, соответствуют ли возвращаемые данные JSON PRD.
3) После завершения прохождения тестового примера завершается проверка функции интерфейса POST-запроса.
4) Вот описание конфигурации среды почтальона.
Первый шаг, как показано на рисунке
Второй шаг, как показано на рисунке
Третий шаг, как показано на рисунке.
Четвертый шаг, как показано на рисунке
Шаг 5, как показано на рисунке (это для ситуаций, когда имеется несколько сред, например среда тестирования, среда приемки и производственная среда).
Запросы GET используются для получения данных. Ниже в качестве примера используется система XX для получения исходящих счетов (только часть информации о данных указана ниже для демонстрации).
1. Требования к документу PRD менеджера по продукту следующие:
2. Интерфейсный документ разработчика выглядит следующим образом:
Имя интерфейса: Синхронизировать исходящие счета с системным интерфейсом XX.
Путь интерфейса: GET /purchase/prepareOrder/importListFromPlm
Параметры запроса:
Query:
Возвратные данные:
{
"msg": "success",
"code": "0",
"info": {
"list": [
{
"billNo": "ML201902205005", //Номер счета
"billDate": "2019-02-20", //Дата выставления счета
"factory": «Производственный отдел Savin Clothing-Ye Lin», //Имя поставщика
"materialSku": "16MLZS0513-628", //Артикул материала
"num": 20, //количество
"purchasePrice": 0, //Цена единицы покупки
"billSum": 0, //Сумма счета
}
]
}
}
3. Примеры тестов тестировщиков следующие:
4. Тестировщики выполняют тестовые случаи следующим образом:
1) Откройте Postman и заполните информацию об интерфейсе. Конкретная операция показана на рисунке.
Примечание. URL-адрес в документе интерфейса не содержит адрес среды, поэтому при копировании URL-адреса в адресную строку необходимо добавить адрес среды, например адрес тестовой среды + URL-адрес интерфейса.
Конечно, если имеется несколько сред, вы можете использовать функцию настройки среды. Конкретные шаги настройки см. в описании POST.
2) В сочетании с тестовым примером после объединения информации о параметрах преобразования проверьте, соответствуют ли возвращаемые данные JSON PRD.
3) После завершения прохождения тестового примера завершается проверка функции интерфейса запроса GET.