Можно ли представить отчет об испытаниях после завершения разработки? Простое в использовании руководство по автоматизации тестирования интерфейса!

Сценарий применения

Разработка еще не завершена, это проверки на сервисе, как синхронизировать тесты? Как только сервер настроен, тесту необходимо отправить отчет.Это сверхурочно?

Тестирование похоже на постработу: только после разработки версии или настройки сервера можно предпринимать реальные действия. И часто на этом этапе наступает и дата выхода системы (программы) в сеть. На самом деле нет необходимости делать это на ранней стадии, но на более поздней стадии это утомительно.

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

Напоминание: если вы хотите последовать примеру, обязательно настройте следующие инструменты.

Вариант использования в основном заключается в объединении основных функций rest-Assured и MockServer для предварительного автоматического тестирования API. Для тех, кто не знает о rest-Assured, пожалуйста, сделайте дополнительную домашнюю работу (вы можете обратиться к rest-Assured статью, которую я писал ранее . Там подробно описаны шаги по настройке и применению, а в MockServer также есть базовые статьи ).

• IDE: IntelliJ ИДЕЯ

• Язык: Ява

• Разработка тестов API: будьте уверены

• API-сервер: MockServer

• Платформа тестирования: TestNg

• Тип проекта: Maven

фокус знаний

Приложение MockServer: проверьте запрос, полученный сервером

будьте уверены: имитируйте запросы API

Конфигурация проекта Maven

Настройте MockServer с уверенностью в POM.xml.

Как показано на рисунке ниже: MockServer и rest-Assured необходимо правильно ввести в узел <dependent> файла pom.xml.

Совет: Если зависимость не загружается автоматически, вы можете загрузить ее вручную, и будет загружен соответствующий jar-пакет.

Моксервер:

Будьте уверены:

Декомпозиция тестового примера

прецедент

Следующее описание варианта использования должно быть вам знакомо. Это типичное описание BDD. Здесь я записываю параметры и запрос проверки вместе для удобства этого объяснения. Реальная среда может отделить данные от сцены, что будет более четко.

Дано: сервер API работает.

Когда: сервер получает запрос от API (адрес API: http://localhost:10800/testing.retry/{id}).

И: параметр «?testParameter=false».

И: (заголовок)头字段:headerId="id"; headerVersion="версия"; заголовокName="имя"

Затем: Убедитесь, что сервер получил правильный запрос.

Пример: раз: 1,

(заголовок)头字段:headerId="id"; headerVersion="версия"; заголовокName="имя"

Параметр: «?testParameter=false»

И: проверьте код ответа сервера (200).

анализ вариантов использования

Сначала создайте сервер, который принимает API и может отвечать 200 на соответствующие запросы API.

Адрес: http://localhost:10800/testing.retry/{id}

Параметры: ?testParameter=false

(заголовок)头字段:headerId = "id"; headerVersion = "версия"; headerName = "имя";

Когда сервер получает запрос, ему необходимо убедиться, что сервер получил правильный запрос, а количество запросов равно 1 и возвращает 200.

1. Ответ кода может быть проверен компанией rest-Assured.

2. Данные, полученные сервером, проверяются MockSever.

Учитывая вышеизложенное, теперь необходимо выполнить следующие шаги:

1. API-сервер — MockServer.

2. Создайте ожидания ответа API (Активные ожидания) — MockServer.

3. Смоделируйте запрос – будьте уверены и проверьте статус возврата.

4. Проверить количество запросов, параметров, полей заголовка — MockServer.

5. Закройте MockerServer.

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

Скрипт варианта использования TestNg

Согласно приведенному выше анализу, давайте посмотрим на реализацию кода шаг за шагом.

Совет: В этом примере используется Java + Maven + testNg (если вы немного незнакомы с этой комбинацией, вы можете прочитать мои соответствующие базовые статьи ).

Полный тестовый сценарий показан на изображении ниже.

Подробный код

1. Глобальные параметры

Мы можем определить общую информацию как переменные, а область рассматриваемого приложения можно определить как локальные переменные или глобальные переменные.

Что делать, если я не могу определить, какие переменные определяют локальные или глобальные переменные?

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

String headerId = "id";
String headerVersion = "version";
String headerName = "name";
String queryParameter = "testParameter";
String queryParameterValue = "false";
String baseURI = "http://localhost:10800";
int requestTime = 1;
private ClientAndServer mockServer;

2. API-сервер – макетный сервер

Как показано на рисунке: сначала мы создаем метод startMockServer(), этот метод предназначен для запуска порта MockServer 10800. Адрес по умолчанию — этот компьютер: http://localhost:10800. Переменная MockServer вызывается другими методами. Здесь определяются глобальные переменные.

private void startMockServer() {
    mockServer = startClientAndServer(10800);
}

3. Создайте ожидания ответа API (активные ожидания) — MockServer

Как анализировалось выше, нам нужно, чтобы сервер API отвечал 200 на следующие запросы.

Примечание. {id} адреса запроса является переменной, а переменная pathId параметризуется в коде.

МетодockServerActiveExpectations() запускает API-сервер и создает ожидания ответа API (Active Expectations).

Адрес: http://localhost:10800/testing.retry/{id}

Параметры: ?testParameter=false

(заголовок)头字段:headerId = "id"; headerVersion = "версия"; заголовокName="имя"

Приложение mockServerActiveExpectations():

startMockerServer() запускает сервер API http://localhost:10800.

Код mockServer.when(request().withPath.... предназначен для создания активных ожиданий, это стандартный синтаксис MockServer, не беспокойтесь о непонимании, просто попробуйте.

4. Ложный запрос – будьте уверены, код ответа на проверку 200

Это синтаксис rest-Assured. Проще говоря, он имитирует поведение пользователя и отправляет API-запрос на сервер http://localhost:10800/.

Примечание. Заголовок (поле заголовка) представляет собой все тестовые данные, и все они используют слово «тест».

log().all : только для отладки, его можно удалить или сохранить позже.

5. Проверка количества запросов, параметров, полей заголовка — MockServer

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

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

Не волнуйтесь, это тоже синтаксис MockServer.

6. Закройте мокер-сервер.

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

запуск варианта использования

Хорошо, давайте сначала проверим результаты. Здесь я запускаю его прямо в IDE.

Одновременно откройте панель управления MockerSever: http://localhost:10800/mockserver/dashboard.

Советы: код выполняется очень быстро. Чтобы захватывать записи панели мониторинга, добавьте 20-секундное время ожидания, прежде чем код закроет MockerSever.

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

На рисунке ниже показан результат проверки запроса MockerSever.

1. Подробности запроса на проверку;

2. Количество запросов аутентификации.

Данные запроса API, смоделированного rest-Assured, можно просмотреть в журнале работающего кода, как показано на следующем рисунке:

Проверка ошибок и оптимизация кода

Теперь мы проводим несколько отрицательных тестов, чтобы убедиться, что этот вариант использования может обнаружить ошибки в рамках «неправильного» запроса и ожидания.

Проверяем, что сервер API получил 2 запроса

После запуска кода мы получим следующую ошибку: Мы ожидали, что сервер получит 2 запроса, но на самом деле получил 1 запрос, поэтому ошибка сообщила, что не найдено ни одного соответствующего запроса.

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

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

Поэтому мы улучшаем функциюverifyReceivedRequestDataAndTimes() и добавляем try...catch..

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

Запустите код еще раз: на панели мониторинга может отображаться информация об ошибке проверки.

Метод проверки добавляет SoftAssert, поэтому код сталкивается с ошибкой проверки и продолжает выполняться. Также добавьте в конце AssertAll(). Таким образом, проверка завершается неудачно, и вариант использования терпит неудачу.

Чтобы иметь возможность сразу проверить, где находится ошибка в текущем результате, улучшите try..catch.. для распечатки ошибки (здесь я использую print, а в реальной среде рекомендуется использовать Log). Таким образом, становится понятно, что проверка не удалась, вариант использования не пройден, а также указана причина сбоя.

Проверяем, что заголовок не совпадает

Например, мы ожидаем, что значением headerId запроса будет «ID», но запрос, полученный сервером, является «тестовым».

Результаты неудачной проверки следующие:

Подведем итог

Ну вот и закончено, как положить слона в холодильник, не сложно!

Когда реальный сервер подключен к сети, вам нужно только указать запрос Rest-Assured на реальный тестовый сервер и прокомментировать MockServer, даже если начальник хочет отчитаться в тот же день, мы можем его доставить.

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

Наконец: приведенное ниже полное видеоруководство по тестированию программного обеспечения было отсортировано и загружено, и друзья, которым оно нужно, могут получить его самостоятельно [гарантировано 100% бесплатно]

Документация для собеседования по тестированию программного обеспечения

Мы должны учиться, чтобы найти высокооплачиваемую работу.Следующие вопросы для интервью представляют собой последние материалы интервью от таких интернет-компаний первого уровня, как Ali, Tencent и Byte, и некоторые руководители Byte дали авторитетные ответы.Завершите этот набор Материалы для интервью считаю, что каждый может найти достойную работу.