Тестирование софта - статьи


Регламентирующие документы и требования к реализациям ИПО Грид - часть 2


Так, например, большая их часть функциональных требований снабжена ключевыми словами стандарта RFC 2119 ? MUST, SHOULD, MAY. Кроме того, большинство требований снабжено блоками объяснений и примерами, написанными на псевдокоде, имеющем много общего с языком WSDL 2.0 описания Web-сервисов.

Отдельные части стандарта имеют различные уровни обязательности в градации RFC 2119. А именно: WS-ресурс обязан (MUST) реализовывать требования спецификаций WS-Resource и WS-ResourceProperties, ему следует (SHOULD) руководствоваться требованиями WS-BaseFaults и он может (MAY) удовлетворять требованиям WS-ResourceLifetime. Следовательно, при создании тестового набора наиболее пристальное внимание нужно уделить именно первым двум обязательным спецификациям. Действительно, такой подход существенно упрощает как структуру тестового набора, так и его размер, при этом сохраняя корректность тестов как решения задачи соответствия.

Итак, спецификация WS-Resource содержит определения ресурса и WS-ресурса. Также она содержит описания двух сообщений об ошибках, которые WS-ресурс может (MAY) возвращать в ответ на запросы. Что же касается спецификации WS-ResourceProperties, то в ней описан следующий способ хранения свойств WS-ресурса. Каждое свойство WS-ресурса представляет собой XML-элемент, полями которого являются уникальное имя свойства (в терминах спецификации WS-ResourceProperties ? QName), значение свойства и, возможно, служебные параметры. Все свойства ресурса объединены в некоторую композицию, называемую Resource Property Document (далее RPD), имеющую собственный идентификатор. Иными словами, свойства ресурса являются дочерними элементами по отношению к некоторому корневому элементу ? фактически, идентификатору RPD. Вместе с тем не указывается, каким именно образом сервис должен реализовывать свой RPD.

В спецификации WS-ResourceProperties описаны следующие обмены сообщениями:

  1. GetResourcePropertyDocument ? получение всех свойств WS-ресурса;
  2. GetResourceProperty ? получение определенного свойства WS-ресурса;
  3. GetMultipleResourceProperties ? получение нескольких свойств WS-ресурса;
  4. QueryResourceProperties ? выяснение структуры свойств WS-Resource и выполнение запросов к RPD  и вычислений над его элементами (отдельно указывается диалект, на котором записано вычисляемое выражение, примером такого диалекта может служить язык XPath);
  5. PutResourcePropertyDocument ? замена всего RPD WS-ресурса “новым” RPD;
  6. SetResourceProperties ? изменение нескольких свойств WS-ресурса (фактически, некоторая композиция следующих трех обменов сообщениями);
  7. InsertResourceProperties ? добавление новых свойств WS-ресурса;
  8. UpdateResourceProperties ? изменение значений свойств WS-ресурса;
  9. DeleteResourceProperties ? удаление свойств WS-ресурса.

В ходе анализа стандартов были выделены 325 функциональных требований, из них 29 относятся к спецификации WS-BaseFaults, 12 ? к WS-Resource, 51 ? к WS-ResourceLifetime, 159 ? к WS-ResourceProperties, 73 ? к WS-ServiceGroup.


Начало  Назад  Вперед