Содержание грамотности:

1. Зачем нам нужно проводить тестирование интерфейса?

2. Как проводить тестирование интерфейса?

3. Каковы точки тестирования интерфейса?

4. Какие знания вам необходимо освоить для тестирования интерфейсов?

5. Другие соответствующие знания?

1. Зачем нам нужно проводить тестирование интерфейса?

① Чем ниже обнаружена ошибка, тем ниже стоимость ее ремонта.

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

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

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

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

⑥ В настоящее время интерфейсная и серверная архитектура многих систем разделены с точки зрения безопасности:

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

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

2. Как проводить тестирование интерфейса?

Поскольку фронтенд- и бэкенд-вызовы нашего проекта — это в основном интерфейсы, основанные на протоколе http, при тестировании интерфейса мы в основном моделируем отправку и получение http-запросов посредством инструментов или кода. Существует множество инструментов, таких как:

почтальон, jmeter, soupUI, java+httpclient, robotframework+httplibraryждать.

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

3. Какова центральная идея тестирования интерфейса?

Цель: Проверить корректность и стабильность интерфейса;

Принцип: имитируйте отправку клиентом сообщения запроса на сервер, сервер получает сообщение запроса, обрабатывает соответствующее сообщение и возвращает ответ клиенту, а клиент получает ответ;

Цель: проверка процесса обмена, передачи и управления данными, включая количество раз обработки;

Ядро: Непрерывная интеграция — это основа тестирования интерфейсов;

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

Фокус разработки варианта использования. Обычно в основном тестируются два внешних интерфейса: данные, поступающие в системный интерфейс (вызов параметров внешней системы для использования системой) и данные, выходящие из системного интерфейса (проверка того, обрабатываются ли данные система в норме);

PS: При разработке вариантов использования также необходимо обратить внимание на то, какие функции внешние интерфейсы предоставляют внешним пользователям, использующим эти интерфейсы, и какие функции действительно нужны внешним пользователям;

1. Базовая функциональная проверка:

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

2. Тест на граничный анализ:

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

3. Тест производительности:

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

4. Какие знания вам необходимо освоить для тестирования интерфейсов?

① Понять взаимодействие бизнес-логики между системой и различными внутренними компонентами;

② Понять ввод-вывод интерфейса (ввод/вывод: ввод и вывод);

③Понимать основное содержание протокола, включая: принципы связи, трехстороннее рукопожатие, часто используемые типы протоколов, состав сообщений, методы передачи данных, общие коды состояния, состав URL-адресов и т. д.;

④Распространенные инструменты тестирования интерфейса, такие как: jmeter, loadrunner, postman, SoapUI и т. д.;

⑤Основные команды работы с базой данных (проверка данных в базе данных, извлечение тестовых данных и т. д.);

⑥Распространенные типы символов, такие как: char, varchar, text, int, float, datatime, string и т. д.;

Как освоить эти навыки?

①Логика бизнес-взаимодействия между системами: через множество каналов и методов, таких как документы с требованиями, блок-схемы, интеллектуальные карты и общение;

②Протокол: Я рекомендую книгу «Иллюстрированный HTTP», которая имеет яркое содержание и является книгой относительно начального уровня. Другие включают «Иллюстрированный TCP, IP» и т. д.;

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

④ Команды работы с базами данных: обучающие веб-сайты (W3C, учебные пособия для новичков), обучающие блоги и некоторые рекомендации по базам данных: «MySQL должен знать и должен знать», «Oracle PL/SQL должен знать и должен знать» и т. д. .

⑤Тип персонажа: Тем не менее, в Baidu есть поговорка: если вы не уверены во внутренних делах, спросите Baidu, а если вы не уверены в международных делах, спросите Google. . .

Восемь элементов интерфейсной документации:

Обложка: желательно, чтобы обложка была обложкой, указанной компанией, с логотипом, названием контента, номером версии, названием компании и датой выпуска документа;

История изменений: лучше использовать табличную форму, включающую: версию, описание версии, дату редакции, автора версии, время проверки рецензента и т. д.;

Информация об интерфейсе: метод вызова интерфейса, часто используемый метод GET/POST, адрес интерфейса;

Функциональное описание: краткое и четкое описание функции интерфейса, например: какая информация не включена в интерфейс;

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

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

Описание возвращаемого значения:

① Лучше всего иметь возвращаемое значение шаблона и объяснять значение каждого возвращаемого параметра;

② Обеспечить реальный интерфейс вызова и реальное возвращаемое значение;

Ограничения вызовов, аспекты безопасности:

Метод шифрования или специальный процесс шифрования вашей собственной компании, если обе стороны используют один и тот же алгоритм шифрования, интерфейс может быть вызван, обеспечивая безопасность вызова интерфейса, например, общий md5;

Ведение документа: при сохранении документа, если есть какие-либо изменения, необходимо указать дату изменения и лицо, внесшее изменение, а для серьезных изменений необходимо изменить номер версии;

5. Другие соответствующие знания?

Разница между запросом получения и запросом публикации:

1. GET использует URL-адрес или файл cookie для передачи параметров. А POST помещает данные в BODY.

2. URL-адрес GET будет иметь ограничение на длину, поэтому данные POST могут быть очень большими.

3. POST безопаснее, чем GET, поскольку данные не видны в адресной строке.

4. Как правило, запрос на получение используется для получения данных, а запрос на отправку используется для отправки данных.

Фактически, из вышеперечисленных пунктов более надежным является только последний. Первый момент заключается в том, что почтовые запросы также могут помещать данные в URL-адрес. Фактически, для запросов на получение не существует ограничения по длине. Это немного безопаснее, но это только для начинающих пользователей. Даже если вы сделаете почтовый запрос, вы все равно сможете получить параметры, перехватив пакет. (Единственная разница в том, что все три вышеуказанных различия неточны)

http-код статуса:

1. Все, что начинается с 200 или 2, означает, что запрос был отправлен успешно. Чаще всего это 200, что означает, что запрос одобрен и сервер его вернул.

2. 300 3 означает перенаправление. Самый распространенный — 302, который перенаправляет запрос в другое место.

3. 400 400 означает, что запрос, отправленный клиентом, содержит синтаксическую ошибку, 401 означает, что страница, к которой осуществляется доступ, не авторизована, 403 означает, что нет разрешения на доступ к этой странице, а 404 означает, что такой страницы нет.

4. 500 5 означает, что на сервере есть исключение, 500 означает, что на сервере есть внутреннее исключение, 504 означает, что на сервере истекло время ожидания и результат не возвращен.

Как протестировать интерфейс веб-сервиса:

Вам не требуется писать сообщение. Он предоставит вам адрес веб-сервиса или файла wsdl. Импортируйте его непосредственно в SOAPUI, и вы сможете увидеть все интерфейсы веб-сервиса, а также сообщение. заполните параметры для вызова и посмотрите возвращаемый результат.

Разница между cookie и сеансом:

1. Данные cookie хранятся в браузере клиента, а данные сеанса — на сервере.

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

3. Сессия будет сохранена на сервере в течение определенного периода времени. Когда количество посещений увеличивается, это увеличивает производительность вашего сервера. Чтобы снизить производительность сервера, следует использовать файлы cookie.

4. Размер данных, сохраняемых одним файлом cookie, не может превышать 4 КБ. Многие браузеры ограничивают сохранение на сайте до 20 файлов cookie.

5. Итак, личные предложения:

Храните важную информацию, такую ​​​​как данные для входа в систему, как сеанс.

Если необходимо сохранить другую информацию, ее можно поместить в файлы cookie.

Если статья вам полезна, подписывайтесь, ставьте лайки, смотрите и делитесь ею с друзьями!

END