Если вы тестировщик и сталкиваетесь с проверкой API, то в обязательном порядке должны понимать и разбираться в 2 базовых формах передачи данных:
- XML – применяется в SOAP и REST-запросах;
- JSON – применяется в REST-запросах.
Итак, в статье мы попробуем детально разобраться с первым понятием.
XML – это особый расширяемый язык разметки. Применяется для процесса хранения и передачи информации. То есть «увидеть» его можно внутри не только API, но и программного кода.
Применительно к SOAP – это единственно правильный и доступный формат для передачи исходящей и входящей информации.
Расшифровка аббревиатуры XML
Структура XML
Внутри каждого XML-документа все элементы необходимо заключать в специальные теги (своего рода особый текст, который оборачивается в угловые скобки, <tag>). Сам текст внутри таких угловых скобок – наименование тега. Часто используемые парные теги состоят из 2 частей: открывающего и закрывающего тега.
Также XML-файл содержит корневую составляющую. Это такой тег, с использования которого и начинается документ, а также им и заканчивается.
Применительно к REST API документ – это особый запрос, который может отправлять система либо же ответ, который он может получить.
Для того чтобы обозначить запрос, необходимо использовать корневой элемент. Обычно он обозначается как <req> / <main> / <sugg>. Он всего лишь показывает начало и завершение запроса. А внутри такого корневого элемента идет непосредственно тело файла – сам запрос (параметры, которые пользователь должен передать внешней системе или другой архитектуре).
Все данные элементов сохраняются между открывающимися и закрывающимися тегами. Для этого может использоваться строка, определенное число, ну или вложенные теги. Например, name_attribute = «value of attribute».
XML пролог
Порой сверху любого XML-документа, можно прочесть что-то подобное:
<?xml version=»1.0″ encoding=»UTF-8″?>.
Эта строка именуется XML-прологом. Именно она демонстрирует версию XML, используемую в документе, и кодировку.
Стоит отметить, что пролог не является обязательным, а значит, если его нет – ничего страшного. Но если он все же присутствует, то это должна быть 1 строка внутри любого XML-файла. UTF-8 – классическая кодировка XML-файла по умолчанию.
Схема XML
Касательно XSD (XML-схемы), то это простое описание созданного XML-файла. Это своего рода техническое задание, созданное на языке программ в формате XML.
Но дело в том, что тестирование по схеме запросто можно переложить на плечи машины, и программисту даже не придется расписывать каждый тест (ему просто необходимо будет разработать одну схему, по которой будет проходить процесс тестирования).
Если пользователь, к примеру, создает SOAP-метод, в схеме нужно указывать:
- какие именно поля будут предоставлены в запросе;
- какие поля будут присутствовать в ответе;
- виды данных, которые будут закреплены за каждым полем;
- какие поля обязательные, а какие не обязательны к пользовательскому заполнению;
- есть ли поля по умолчанию или нет;
- ограничено ли поле по длине;
- присутствуют ли у поля прочие характеристики;
- какова структура запроса по типу вложенности элементов.
И теперь, когда пользователю поступает любой запрос, для начала он должен проверятся на валидность по XSD. Если запрос оказывается корректным, запускается метод, отрабатывается вся заложенная бизнес-логика.
Но порой эта логика может быть трудоемкой и сложной. К примеру, создать выборку по параметрам внутри большой многоуровневой БД. Либо же провести 20 проверок по разным таблицам баз данных и прочее.
Это все значит, что нет необходимости запускать крайне сложную задачу, если изначально понимать, что запрос будет плохим и будет показывать ошибку каждые 2 минуты при проверке. Именно валидация по XSD позволяет тестировщикам и конечным пользователям мгновенно отсеивать явно некорректные запросы при этом, не захламляя ПО.
Запросы пользователей и программ
Кроме этого, подобную защиту инсталлируют на некоторые программы-клиенты для процедуры отправки разнообразных запросов. К примеру, SOAP UI умеет тестировать пользовательские запросы на предмет well-formed xml. Но он просто не выполнит процедуру отправки запроса на сервер, если вы допустили где-то ошибку. Таким образом, экономится время на отправку будущих запросов.
А вот обычный пользователь сможет на основе простого SOAP API понять, как правильно составлять запросы. Кто же такой обычный пользователь?
- Создатель ПО, который применяет нужное API: он просто прописывает в коде, что конкретно нужно отправлять из одной системы в другую.
- Тестировщик, который должен это API тщательно проверить: он должен хорошо понимать, как именно создается и формируется запрос (со всеми вытекающими последствиями).
Естественно, в идеальных условиях у пользователя должно быть тщательно проработанное техническое задание, где всё детализировано расписано. Но, к сожалению, такое встречается очень редко. Порой задания просто нет либо оно устарело с технической точки зрения.
Анализируем, как применяется схема при создании SOAP API:
- Наш программист создает некую XSD (схему XML) для API-запроса: например, требуется передать элемент Х, который будет обладать дочерними типами данных. Некоторые обязательные, а некоторые нет.
- Программист системы-клиента, которая должна интегрироваться с нашей системой, знакомится со схемой и создает свои персонализированные запросы исключительно по ней.
- Система-клиент отсылает все запросы нам как тестировщикам.
- Система, за которой наблюдают тестировщики, валидирует запросы исключительно по XSD – если где-то есть баг, тест точно не пройдет.
- Если же по XSD проверка прошла – бизнес-логика проверенна и может использоваться на многократной основе.
Well-Formed XML
Все XML-документы должны подчиняться определенным стандартам. Неправильный запрос по синтаксису не только не уйдет на сервер, но и будет забракован самим клиентом. В первую очередь, тестирование на well-formed, а потом уже вся остальная бизнес-логика.
Базовые правила well-formed XML:
- Содержится корневой элемент;
- Элементы содержат закрывающиеся теги;
- Все теги регистрозависимые;
- Исполняется корректная вложенность элементов;
- Все используемые атрибуты оформлены в кавычки.
Если вы предоставляете услуги тестирования ПО, то при проверке запроса в форме XML вам придется правильно ломать запрос! Естественно, проверяемая система должна уметь справляться с такими ошибками, а также в корректной форме возвращать специальные сообщения об ошибках. Но такое происходит далеко не на постоянной основе.
Оставить комментарий