В чем надежность SOAP
Что проверяют
Отличаете ли вы сам протокол от стека расширений WS-*, на котором держится его репутация надёжного, и что из этого вам как тестировщику проверять. Следом обычно спрашивают, чем SOAP отличается от REST и как вы тестировали SOAP-сервис.
Как отвечать
SOAP это формат XML-сообщения (Envelope, Header, Body, Fault) и правила его обработки. Надёжность складывается из слоёв:
- строгий контракт: WSDL описывает операции, XSD описывает типы. Сообщение, не прошедшее валидацию по схеме, отвергается, а клиент генерируется из контракта;
- стандартные ошибки: у
Faultобязательная структура (в SOAP 1.2 этоCodeиReason, в 1.1faultcodeиfaultstring), видно, кто виноват: клиент или сервер; - WS-Security: подпись и шифрование на уровне сообщения, а не только канала, поэтому защита сохраняется и при прохождении через посредников;
- WS-ReliableMessaging: гарантированная доставка, отбрасывание дублей, сохранение порядка;
- WS-AtomicTransaction: распределённые транзакции между сервисами.
Оговорка: всё, кроме контракта и Fault, это отдельные спецификации, и работают они, только если их поддерживают обе стороны. SOAP поверх HTTP без WS-ReliableMessaging доставку не гарантирует. К HTTP протокол не привязан, бывает и поверх JMS.
Отсюда проверки: валидация запросов и ответов по XSD, негатив с битым XML, лишними и пропущенными полями, корректность Fault и HTTP-кода (в SOAP 1.2 ошибка Sender идёт с 400, ошибка сервера с 500), истёкшие и неверные подписи WS-Security. Инструменты: SoapUI или ReadyAPI, Postman, в автотестах zeep на Python или Spring WS на Java.
Где спотыкаются
Говорят, что транзакции и гарантированная доставка встроены в SOAP. Это расширения, и в конкретной интеграции их может не быть.
Проверяют только HTTP-статус. Часть сервисов возвращает Fault с кодом 200, и такой тест ошибку пропустит.
Сравнивают XML-ответ строкой целиком. Префиксы пространств имён (soap: или env:), пробелы и порядок атрибутов меняются при корректном ответе, тест становится хрупким. Надёжнее XPath и валидация по схеме.