Перейти к содержимому

Фотография

Тестирование XSLT-приложений


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 7

#1 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 27 октября 2004 - 12:03

Уважаемые форумчане, кто-нибудь имеет опыт тестирования XSLT-приложений? Поделитесь, пожалуйста!

Изложу проблему более детально (это уже для тех, кто представляет предметную область).

Имеется B2B-приложение, которое, в частности, выполняет проеобразование данных из одного XML-представления в другое XML-представление. Известна схема (XSD) входных документов, схема выходных документов. Приложение, преобразующее данные, реализовано на XSLT (как вариант -- на XQuery).

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

В рамках этих двух задач (вторая, очевидно, сложнее), стоит три проблемы:
-- как генерировать входные данные для тестирования?
-- как проверять правильность работы преобразователя на этих входных данных, в частности как формализовать требования к преобразованиям?
-- как формализовать описание дополнительных семантических ограничений, чтобы решить описанные выше две проблемы с учётом этих дополнительных ограничений?

Решение "писать руками, смотреть глазами" не предлагать. Интересуют подходы к автоматизации и построению комплекта регрессионных тестов.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#2 dlg99

dlg99

    Специалист

  • Members
  • PipPipPipPipPip
  • 609 сообщений
  • ФИО:Andrey Yegorov
  • Город:Redmond, WA

Отправлено 27 октября 2004 - 15:31

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

Решение "писать руками, смотреть глазами" не предлагать. Интересуют подходы к автоматизации и построению комплекта регрессионных тестов.

Уважаемые форумчане, кто-нибудь имеет опыт тестирования XSLT-приложений?


нет, к сожалению.

как проверять правильность работы преобразователя на этих входных данных


просто common-sense idea:

если преобразование обратимо, то можно тестировать алгебру:

a -> b
b -> a'
assert( a == a' )

Можно каким-либо образом создать "базу эталонов" и сравнивать с ними.

a -> b
c = get_etalon( a )
assert( b == c )

Эталоны либо сначала "писать руками, смотреть глазами" один раз, а потом ре-использовать, либо при помощи third-party tool if there is any.

Попробую на досуге еще подумать, что тут можно сделать.
  • 0
Andrey Yegorov. Изображение

#3 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 27 октября 2004 - 15:42

Алексей,

лень писать заново. Я просто скопировал описание проекта из материалов странички, которую готовлю для размещения на сайте Тестер.

"Практически каждые проект сочетал в себе как ручное, так и автоматизированное тестирование. Но один проект был не характерным, так как тестировался полностью в автоматизированном режиме. Это был XML конвертер для компании Datalex.

С утверждением нового XML стандарта по обмену данными между компаниями туристического бизнеса заказчик обратился с просьбой разработать XML конвертер, что бы трансформировать запросы нового стандарта в сообщения, понимаемые его программным продуктом, использующим устаревший стандарт. Трансформация из одного стандарта в другой была реализована в программе с использованием XSLT трансформации. Для тестирования данного приложения мне пришлось написать библиотеку тестировочных скриптов на Jscript, которые подавали на вход приложения тестировочные данные, получали результирующие данные и автоматически анализировали их на соответствие правилам трансформации."

Если интересуют детали - you are welcome!
Можно здесь, можно по телефону.
B)
  • 0
Гринкевич Сергей

#4 Dmitry_NJ

Dmitry_NJ

    Консультант

  • Members
  • PipPipPipPipPipPip
  • 3 122 сообщений
  • ФИО:Дмитрий Шевченко
  • Город:New Jersey, USA

Отправлено 28 октября 2004 - 03:22

Вообще говоря, QuickTest Professional имеет WebServices add-in, который позволяет ставить XML Checkpoints, в том числе и "...confirm that the XML
in the file or returned object adheres to the XML structure defined in a specific XML schema". Не знаю подходит ли это к поставленной задаче, но попробовать, наверное, можно.
  • 0
Дмитрий Шевченко

HP Software

#5 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 28 октября 2004 - 03:43

Если интересуют детали - you are welcome!
Можно здесь, можно по телефону.

Ещё как интересуют! И лучше здесь, вдруг у кого ещё мысль хорошая появится.

К меня вопросы концептуальные, а не технические (какой инструмент использовать). Я знаю как проверить соответствие выхода схеме. JScript будет данные на вход подавать или нет -- это как раз мало интересно. Автоматическая подача входных данных -- это не проблема. Вопрос -- откуда их взять, эти входные данные? И сколько? Выборка должна быть репрезентативной, чтобы продемонстировать, что (см. выше постановку задачи) "для любого правильного входного документа преобразователь создаёт правильный выходной документ". Как оценить репрезентативность выборки?
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#6 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 28 октября 2004 - 03:47

...и автоматически анализировали их на соответствие правилам трансформации.

Вот это тоже очень интересно. Как определялась правильность?

Это функция трёх аргументов -- входной документ, выходной документ и преобразователь. Как известно, XSLT -- это turing-complete язык, поэтому строгими аналитическими методами проверить правильность работы XSLT-программы не представляется реальным. Поэтому, вероятно, использовались некоторые эмпирики -- какие? Или какие-то вспомогательные данные -- какие? Или какая-то совсем незнакомая мне техника -- очень интересно было бы узнать!
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#7 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 28 октября 2004 - 03:58

если преобразование обратимо, то можно тестировать алгебру:

a -> b
b -> a'
assert( a == a' )

Хорошая мысль. Мы так делали уже для одного XML-приложения. Но там было построение по XML-данным внутреннего представления этих данных, для тестирования оставалось только сбросить их обратно в XML и сравнить (причём не на полное совпадение, а с известной точностью, так что полная обратимость не всегда требуется).

Но XSLT-преобразование в общем случае "сильно" необратимо. При преобразовании часть данных может теряться. И вообще, как я уже упомянул, XSLT -- turing-complete язык, так что на нём можно написать всякое-разное, в том числе необратимое. Да что там, например, совсем простое -- во входном документе два числа, а в выходном -- их сумма.

Можно каким-либо образом создать "базу эталонов" и сравнивать с ними.

a -> b
c = get_etalon( a )
assert( b == c )

Эталоны либо сначала "писать руками, смотреть глазами" один раз, а потом ре-использовать, либо при помощи third-party tool if there is any.

Вот-вот, именно в это проблема -- и эталоны-то писать руками не хочется, и инструментов-то нет. По мне так лучше уж один раз напрячься и инструмент сделать, чем входные данные и эталоны писать, :) потому что система-то эволюционирует, входные данные и эталоны придётся постоянно поддерживать в актуальном состоянии.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#8 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 28 октября 2004 - 07:25

Если интересуют детали - you are welcome!
Можно здесь, можно по телефону.

Ещё как интересуют! И лучше здесь, вдруг у кого ещё мысль хорошая появится.

К меня вопросы концептуальные, а не технические (какой инструмент использовать). Я знаю как проверить соответствие выхода схеме. JScript будет данные на вход подавать или нет -- это как раз мало интересно. Автоматическая подача входных данных -- это не проблема. Вопрос -- откуда их взять, эти входные данные? И сколько? Выборка должна быть репрезентативной, чтобы продемонстировать, что (см. выше постановку задачи) "для любого правильного входного документа преобразователь создаёт правильный выходной документ". Как оценить репрезентативность выборки?

Вкратце опишу проект (повторюсь, что бы было цельное описание).

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

По сути схема трансформации выглядела следующим образом. На всходе системы подавался XML документ, который валидировался на корректность XSD схемой. После этого осуществлялась XSLT трансформация в преобразованный XML документ.

При трансформации каждому элементу одного XML ставился элемент преобразованного XML. Тем самым формулировались правила трансформации. Одним из жестких условий, поставленных заказчиком, было необходимость проверки каждого такого правила. Но прежде чем приступить к реализации приложения, заказчик должен был утвердить эти правила. Для этой цели каждое правило было занесено в Excel документ в виде XPath определенного элемента. В результате получился длинный список (более 20 тысяч строк) состоящий из двух колонок. В одной колонке были XPaths для нового стандарта, в другой - соответствующие XPaths старого. Реально таких списков было несколько, каждый для определнного условия трансформации: трансформация в одну сторону, в другую, отсутсвие трансформации по причине соответствия правил, отсутствие трансформации по причине не используемости правил.

Этот же документ с правилами использовался для тестирования. Для написания тула я применил MS WSH и JScript (Очень удобно. Сейчас на JScript.NET можно написать любую программу, использую .NET классы. Но это так, к слову). Прога читала входной тестовый документ, находила нужные правила трансформации в одной колонке, потом определяла как должен выглядеть трансформированный элемент и проверяла его в выходном элементе. Результат записывался в копию документа с правилами трансформации, в строку соответствующую проверяемому правилу. Таким образом проверялось каждое правило трансформации.

В моем случае не было необходимости генерировать тестовые данные, т.к. нам предоставляли копии реальных запросов. Впоследствии наш тул некоторое время был включен в реальный поток и тестировался в реальном режиме. Но обладая списком правил трансформации сгенерировать тестовые данные не представляет ни какой сложности.
  • 0
Гринкевич Сергей


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных