Всем привет, мы снова встретились, я ваш друг Цюаньчжаньцзюнь.

Случайные мысли в начале:

18Я написал статью, когда был《ИнтернетСервертестЧто это такое（Вводная наука）》（указывать путьhttps://blog.csdn.net/wangyueshu/article/details/81944250）,В основном ориентирован на тех, кто не сталкивался с серверным тестом.,Особенно это актуально для тех читателей, которые уже имеют опыт работы на серверной стороне и которым срочно необходимо изменить свое мышление при столкновении с серверной частью.

Прошло три года, и когда я вернулся, чтобы заняться серверным тестированием, контент тоже был расширен. Интерфейс в исходной статье больше относится к интерфейсу HTTP, а служба больше относится к службе данных. С постепенным углублением применения моделей алгоритмов сервисы расширились до сервисов моделей и политик, а интерфейсы RPC стали более распространенными и стали одним из объектов серверного тестирования.

Основной текст будет включать три части: основные понятия, результаты услуги (с точки зрения разработки) и тестирование службы (с точки зрения тестирования).

1. Основные понятия:

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

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

Язык — язык кода, используемый службой для реализации функций программного обеспечения, таких как Java, php, python и т. д.

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

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

2. Выход услуги:

Теперь предположим, что вы являетесь поставщиком услуг. Сначала вы выбираете язык разработки A и разрабатываете систему. Для реализации внешних служб вам необходимо предоставить интерфейс службы посредством инкапсуляции API. В настоящее время доступны следующие варианты: интерфейс HTTP, интерфейс RPC или другие интерфейсы связи на основе протоколов. Что касается конкретного выбора, мы не будем здесь вдаваться в подробности.

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

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

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

3. Сервисный тест:

Давайте вернемся к перспективе тестирования.

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

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

Сначала настройте среду, которая в основном включает в себя три аспекта:

1. Конфигурация рабочей среды RPC, включая некоторые конфигурации протокола, реферера и другие конфигурации.
2. Установка пакета клиентского кода, например, установка maven через зависимости файла pom.
3. Конфигурация адреса сервера, включая группу, адрес прямого подключения и т. д. (облачные сервисы обычно начинаются с RPC).

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

Точно так же метод вызова не является самым важным. Сервер не эквивалентен простому тестированию интерфейса. Вызов интерфейса — это всего лишь средство, которое помогает нам протестировать и принять сервис и саму систему. Поэтому важно понимать тестируемый сервис. Например, большинство интерфейсов RPC предоставляют услуги моделей и политик, поэтому нам необходимо четко понимать тестируемый объект. Если это модель, то на какие основные показатели следует обратить внимание? Как оценить? Каковы требования к тестовым данным (доля и количество каждого типа данных и т. д.)? Если это стратегия, на какие входные данные она нацелена? Каковы ожидания результата? Это основы тестирования RPC.

Заявление об авторских правах: Содержание этой статьи добровольно предоставлено пользователями Интернета, а мнения, выраженные в этой статье, представляют собой только точку зрения автора. Данный сайт лишь предоставляет услуги по хранению информации, не имеет никаких прав собственности и не несет соответствующей юридической ответственности. Если вы обнаружите на этом сайте какое-либо подозрительное нарушение авторских прав/незаконный контент, отправьте электронное письмо, чтобы сообщить. После проверки этот сайт будет немедленно удален.

Издатель: Лидер стека программистов полного стека, укажите источник для перепечатки: https://javaforall.cn/182423.html Исходная ссылка: https://javaforall.cn