Что такое xml тестирование

Русские Блоги

В основы понимания JSON и XML в тестировании интерфейса Java

Справочник статей

введение

Введение в JSON

Структура данных JSON

JSON имеет две структуры данных:

Другими словами, все объекты JSON должны быть представлены в этих формах;

Проще говоря, это карта в Java, заданная в виде пар имя-значение. Имя и значение разделены символом «:», а две карты разделены символом «,». Общее представление выглядит следующим образом:

Следующий объект имеет 3 пары ключ-значение

Array

Это массив в обычном смысле, общая форма выглядит следующим образом:

Следующий массив имеет 3 объекта JSON, а каждый объект имеет 3 пары ключ-значение

Строки очень похожи на строки C или Java.

Число (число) также очень похоже на значение C или Java. Удалите неиспользуемые восьмеричные и шестнадцатеричные форматы. Удалите некоторые детали кодирования.

Вложенная карта

Объекты JSON также могут быть вложенными:

резюме

Введение в XML

Правила грамматики XML

Веб-сайты, которые проверяют XML-структуру онлайн:https://codebeautify.org/xmlvalidator

Ссылки на сущности в XML

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

В XML есть 5 предопределенных ссылок на сущности:

Источник

Статьи

Создание тестов без редактора.

Введение

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

Некоторых пользователей, например, смущает большое количество окон, появляющихся при редактировании теста. У многих уже есть готовые тесты, набранные в текстовых редакторах, например MS Word, или просто отсканированные с бумажных копий, и занесение всей информации в редактор тестов методом copy+paste становиться трудоемким, особенно при большом количестве вопросов.

VeralTest предоставляет такую возможность. Все дело в том, что формат файлов, в которых хранятся тесты, основан на языке XML – специальном языке разметки гипертекста. Файлы *.xtf, используемые VeralTest, представляют собой zip архивы, в которых содержится файл content.xml (это непосредственно сам тест) и файлы рисунков, используемых в тесте. Чтобы проверить это, достаточно изменить расширение файла на zip и распаковать полученный архив.

Краткие сведения о языке XML

XML – это универсальный язык разметки, позволяющий с помощью специальных ключевых слов (тегов) выделять в тексте определенные элементы. Звучит сложно? Ну хорошо, вот простой пример: Рассмотрим один из самых распространенных документов – письмо электронной почты. Какие элементы можно выделить в этом документе?

1. Адрес отравителя; 2. Арес получателя; 3. Тема письма; 4. Текст письма. На языке XML этот документ можно записать так:

Внимательный читатель, конечно же, задаст вопрос: «А какие имена должны быть у тегов?». И вот на этот вопрос я, к сожалению, не смогу ответить. И дело здесь не в том, что я плохо знаком с языком XML, просто язык XML задает лишь правила написания тегов, а имена тегов могут быть любыми. Наш пример можно записать и в таком виде:

С точки зрения XML этот документ имеет такое же право на существование, как и предыдущий.

Приведенный здесь краткий обзор ни в коем случае не претендует на полноту и строгость описания XML. Этот краткий экскурс нужен лишь для понимания дальнейшего материала, изложенного ниже в данной статье. Если вы хотите узнать больше о XML, его возможностях и сопутствующих технологиях, могу порекомендовать сайт Школы Консорциума W3C ( http://xml.nsu.ru ), содержащий статьи, в которых просто и доходчиво изложены основы языка.

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

Атрибут записывается в виде имя=”значение”. Значение атрибута всегда должно помещаться в кавычки.

И еще: Любой XML документ должен начинаться с такой строки:

Закрывающий тег здесь не нужен.

Что нам понадобиться

Создаем простой тест

Кто автор произведения «Евгений Онегин»?

Какие из этих городов находятся в Российской Федерации?

Теперь рассмотрим, как этот тест должен быть записан при помощи XML.

Посмотрим, из каких элементов состоит написанный нами текст.

Первая строчка – это стандартный заголовок XML документа. Мы уже говорили о нем выше. Атрибут encoding указывает кодировку, в которой записан текст.

Вторая строчка задает ссылку на файл, в котором хранятся правила для составления тестов на языке XML. Вот в нем-то как раз и указано, какие названия элементов могут использоваться и в каком порядке элементы должны следовать.

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

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

Вопрос с единичным выбором

Вопрос с множественным выбором

Вопрос с вводом числа

Вопрос с вводом текста

Вопрос с сопоставлением

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

Запишите этот пример в удобном для вас текстовом редакторе. Будьте внимательны, не допускайте ошибок при написании элементов, иначе ничего не получится.

После того, как тест составлен, нужно сохранить его с именем content.xml. Если вы пользуетесь специализированным XML редактором, то достаточно просто нажать на кнопку «Сохранить» и дать название content сохраняемому файлу.

Если вы пользуетесь редактором простого текста, например блокнотом, то выберите пункт меню «Файл/сохранить как», в диалоговом окне сохранения выберите тип файла: «Все файлы» и дайте имя сохраняемому файлу content.xml.

Если вы пользуетесь текстовым процессором типа MS Word, то задача несколько усложняется. Вам сначала надо сохранить файл как обычный текст (*.txt), а затем переименовать его в content.xml

Следующим шагом будет упаковка полученного файла content.xml в архив zip. Пользователи Windows версии XP и выше могут сделать это следующим образом:

Пользователям младших версий Windows для упаковки придется использовать сторонние архиваторы: WinZip, WinRar и т.д.

Последний шаг состоит в переименовании полученного zip архива content.zip. Дайте файлу удобное название и расширение: *.xtf, например mytest.xtf

Файл теста готов. Чтобы проверить его работоспособность, откройте полученный файл в редакторе тестов. Если все сделано правильно, то файл откроется, и вы можете просматривать и редактировать вопросы, запускать тест на выполнение. Если при открытии файла появилось сообщение об ошибке, значит, вы допустили неточность при написании кода XML – найдите ошибку в своем коде и повторите операцию еще раз.

И напоследок расскажу об еще одной полезности. Если вы не пользуетесь специализированными XML редакторами, то велика вероятность, что вы допустите ошибку при написании теста. Чтобы можно было быстро найти и исправить эту ошибку еще до упаковки фала в zip архив, откройте ваш файл content.xml в веб браузере (например, InternetExplorer или Firefox). Современные браузеры поддерживают стандарт XML, и если ваш файл содержит ошибку, они покажут вам описание этой ошибки и номер строки в вашем файле, где ошибка находится.

Заключение

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

Источник

Правильная проверка XML данных в java-проектах

В ряде проектов мне потребовалось сравнивать XML данные в тестах.

Под катом я постараюсь рассказать о том, как лучше всего, по моему мнению, тестировать генерацию XML в коде. В качестве инструмента сравнения XML я использовал XmlUnit.

Мне нужно быстро и удобно сравнивать XML данные в тестах. Изобретать велосипед не хотелось, и я выбрал наиболее популярную библиотеку для этих целей. В начале я постараюсь описать список проблем, которые я решал.

С чего всё началось

Как-то работая над очередным проектом, я сломал тест коллеги. Когда стал изучать тест, то нашел там что-то типа такого:

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

Чем плох данный код?

Попробую обосновать по пунктам.

1. Слишком много телодвижений, чтобы сравнить два файла

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

2. Нет проверки валидности сгенеренного XML-кода

Из-за того, что валидность не проверялась, другой модуль отказывался обрабатывать невалидные данные, хотя по тестам было всё нормально. Хотелось решать эту проблему на стадии отладки теста.

3. Идентичные по структуре и данным XML могут оказаться неодинаковыми из-за разного порядка тегов или атрибутов

Например, так:

или так:

4. Хочу в тестах XML c форматированием

В тесте, представленном в начале статьи, XML данные были представленны без пробелов и переносов строк. Почувствуйте разницу:

5. Автоматически обрабатывались переносы внутри данных

В рассматриваемом в начале статьи тесте, исходные данные были в одну строчку, только тегов и атрибутов было несколько больше. Посадить туда ошибку — очень просто, а исправлять так, чтобы тест проходил, — долго и мучительно.

После недолгого поиска мой выбор пал на XmlUnit.

Основные способы подключения XmlUnit

Библиотека XmlUnit в первую очередь является расширением JUnit3.
Его основа — это класс XMLTestCase, наследник класса TestCase из JUnit3. Здесь вы можете посмотреть основные примеры использования класса.
На практике XmlUnit легко использовать и в других библиотеках тестов. Для этого есть класс Diff.

Итак, поехали

Для своих проектов я использую maven. Подключим XmlUnit как зависимость в maven. Для этого открываем pom.xml и в dependencies добавляем новую зависимость.

Открываем тест, пишем туда новое сравнение

Запускаем тест… и не работает. Ещё немного поискав в интернете, я нашел решение. Дело было в пробелах между тегами. Чтобы их не учитывать, нужно добавить предварительную настройку:

Вроде бы всё, можно радоваться результату. Однако, предположим, что мы допустили в XML ошибку. Тогда нам нужно знать, в каком именно теге проблема.
Решить её нам поможет следующий пример:

Обратите внимание на метод showXmlDiff. В нем получаем список различий и выводим его.

Что ещё можно сделать хорошего?

Литература

Ссылки, по которым я черпал информацию.

Ещё раз отмечу, что XmlUnit позволяет проверять валидность XML по DTD и XSD схемам.
Как правильно отметил Lure_of_Chaos, в схемах XSD можно требовать порядка задания элементов. Проверять это в тестах — критически важно.

UPD2: поправил последний пример проверки. Спасибо, Colwin.
На этом всё, спасибо за внимание.

Источник

Что такое XML

Если вы тестируете API, то должны знать про два основных формата передачи данных:

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:
Что такое API — общее знакомство с API
Что такое JSON — второй популярный формат
Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

Так что давайте разберемся, как он выглядит, как его читать, и как ломать! Да-да, а куда же без этого? Надо ведь выяснить, как отреагирует система на кривой формат присланных данных.

Содержание

Как устроен XML

Возьмем пример из документации подсказок Дадаты по ФИО:

И разберемся, что означает эта запись.

В XML каждый элемент должен быть заключен в теги. Тег — это некий текст, обернутый в угловые скобки:

Текст внутри угловых скобок — название тега.
Тега всегда два:

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

С помощью тегов мы показываем системе «вот тут начинается элемент, а вот тут заканчивается». Это как дорожные знаки:

— На въезде в город написано его название: Москва
— На выезде написано то же самое название, но перечеркнутое: Москва*

* Пример с дорожными знаками я когда-то давно прочитала в статье Яндекса, только ссылку уже не помню. А пример отличный!

Корневой элемент

В любом XML-документе есть корневой элемент. Это тег, с которого документ начинается, и которым заканчивается. В случае REST API документ — это запрос, который отправляет система. Или ответ, который она получает.

Чтобы обозначить этот запрос, нам нужен корневой элемент. В подсказках корневой элемент — «req».

Он мог бы называться по другому:

Да как угодно. Он показывает начало и конец нашего запроса, не более того. А вот внутри уже идет тело документа — сам запрос. Те параметры, которые мы передаем внешней системе. Разумеется, они тоже будут в тегах, но уже в обычных, а не корневых.

Значение элемента

Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!

Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.

Внутри — значение запроса.

Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):

Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.

Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».

Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.

Откройте консоль разработчика через f12, вкладку Network, и посмотрите, какой запрос отправляется на сервер. Там будет значение count = 7.

Атрибуты элемента

У элемента могут быть атрибуты — один или несколько. Их мы указываем внутри отрывающегося тега после названия тега через пробел в виде

Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.

Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:

Давайте разберем эту запись. У нас есть основной элемент party.

У него есть 3 атрибута:

Внутри party есть элементы field.

У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.

Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10+ заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.

Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):

— есть элемент party;
— у него есть элементы field;
— у каждого элемента field есть атрибут name, в котором хранится название поля.

А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:

— При чтении XSD сразу видны реальные поля. ТЗ может устареть, а код будет актуален.
— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику + заказчик иногда так тестирует, ему тоже хорошо.

В общем, любой подход имеет право на существование. Надо смотреть по проекту, что будет удобнее именно вам. У меня в примере неговорящие названия элементов — все как один будут field. А вот по атрибутам уже можно понять, что это такое.

Помимо элементов field в party есть элемент attribute. Не путайте xml-нотацию и бизнес-прочтение:

У элемента attribute есть атрибуты:

Такая вот XML-ка получилась. Причем упрощенная. В реальных системах, где хранятся физ лица, данных сильно больше: штук 20 полей самого физ лица, несколько адресов, телефонов, емейл-адресов…

Но прочитать даже огромную XML не составит труда, если вы знаете, что где. И если она отформатирована — вложенные элементы сдвинуты вправо, остальные на одном уровне. Без форматирования будет тяжеловато…

А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.

XML пролог

Иногда вверху XML документа можно увидеть что-то похожее:

Эта строка называется XML прологом. Она показывает версию XML, который используется в документе, а также кодировку. Пролог необязателен, если его нет — это ок. Но если он есть, то это должна быть первая строка XML документа.

UTF-8 — кодировка XML документов по умолчанию.

XSD-схема

XSD (XML Schema Definition) — это описание вашего XML. Как он должен выглядеть, что в нем должно быть? Это ТЗ, написанное на языке машины — ведь схему мы пишем… Тоже в формате XML! Получается XML, который описывает другой XML.

Фишка в том, что проверку по схеме можно делегировать машине. И разработчику даже не надо расписывать каждую проверку. Достаточно сказать «вот схема, проверяй по ней».

Если мы создаем SOAP-метод, то указываем в схеме:

Поэтому зачем запускать сложную процедуру, если запрос заведом «плохой»? И выдавать ошибку через 5 минут, а не сразу? Валидация по схеме помогает быстро отсеять явно невалидные запросы, не нагружая систему.

Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!

А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?

Итого, как используется схема при разработке SOAP API:

Попробуем написать для него схему. В запросе должны быть 3 элемента (email, name, password) с типом «string» (строка). Пишем:

А в WSDl сервиса она записана еще проще:

Конечно, в схеме могут быть не только строковые элементы. Это могут быть числа, даты, boolean-значения и даже какие-то свои типы:

А еще в схеме можно ссылаться на другую схему, что упрощает написание кода — можно переиспользовать схемы для разных задач.

Практика: составляем свой запрос

Ок, теперь мы знаем, как «прочитать» запрос для API-метода в формате XML. Но как его составить по ТЗ? Давайте попробуем. Смотрим в документацию. И вот почему я даю пример из Дадаты — там классная документация!

Что, если я хочу, чтобы мне вернуть только женские ФИО, начинающиеся на «Ан»? Берем наш исходный пример:

В первую очередь меняем сам запрос. Теперь это уже не «Виктор Иван», а «Ан»:

Далее смотрим в ТЗ. Как вернуть только женские подсказки? Есть специальный параметр — gender. Название параметра — это название тегов. А внутри уже ставим пол. «Женский» по английски будет FEMALE, в документации также. Итого получили:

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

Вот и все! Взяли за основу пример, поменяли одно значение, один параметр добавили, один удалили. Не так уж и сложно. Особенно, когда есть подробное ТЗ и пример )))

Попробуй сам!
Напишите запрос для метода MagicSearch в Users. Мы хотим найти всех Ивановых по полному совпадению, на которых висят актуальные задачи.

Well Formed XML

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

1. Есть корневой элемент

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

И если у вас будет лежать несколько тегов подряд без общего родителя — это плохой xml, не well formed. Всегда должен быть корневой элемент:

Что мы делаем для тестирования этого условия? Правильно, удаляем из нашего запроса корневые теги!

2. У каждого элемента есть закрывающийся тег

Тут все просто — если тег где-то открылся, он должен где-то закрыться. Хотите сломать? Удалите закрывающийся тег любого элемента.

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

Это тоже самое, что передать в нем пустое значение

Аналогично сервер может вернуть нам пустое значение тега. Можно попробовать послать пустые поля в Users в методе FullUpdateUser. И в запросе это допустимо (я отправила пустым поле name1), и в ответе SOAP Ui нам именно так и отрисовывает пустые поля.

Итого — если есть открывающийся тег, должен быть закрывающийся. Либо это будет один тег со слешом в конце.

Для тестирования удаляем в запросе любой закрывающийся тег.

3. Теги регистрозависимы

Как написали открывающий — также пишем и закрывающий. ТОЧНО ТАК ЖЕ! А не так, как захотелось.

А вот для тестирования меняем регистр одной из частей. Такой XML будет невалидным

4. Правильная вложенность элементов

Элементы могут идти друг за другом

Один элемент может быть вложен в другой

Но накладываться друг на друга элементы НЕ могут!

5. Атрибуты оформлены в кавычках

Даже если вы считаете атрибут числом, он будет в кавычках:

Для тестирования пробуем передать его без кавычек:

Итого

XML (eXtensible Markup Language) используется для хранения и передачи данных.

Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.

Хранение данных — это когда XML встречается внутри кода. Его легко понимает как машина, так и человек. В формате XML можно описывать какие-то правила, которые будут применяться к данным, или что-то еще.

Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).

Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.

Правила well formed XML:

Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.

А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!

Что такое JSON — второй популярный формат

PS — больше полезных статей ищите в моем блоге по метке «полезное». А полезные видео — на моем youtube-канале

Источник