Что такое WSDL
Что проверяют
Умеете ли вы тестировать SOAP-сервисы по контракту, а не наугад. Вопрос отсекает тех, кто видел только REST: если интеграция описана в WSDL, и тест-кейсы, и заготовки запросов берутся прямо из него.
Как отвечать
WSDL (Web Services Description Language) это XML-описание веб-сервиса: перечень операций, структура запроса и ответа, типы данных, привязка к протоколу и адрес конечной точки. По структуре стоит назвать types (схема XML с обязательностью полей и ограничениями), message (части запроса и ответа), portType с операциями, binding (обычно SOAP поверх HTTP) и service с адресами.
Дальше переходите к практике тестирования:
- импорт WSDL в SoapUI или ReadyAPI даёт готовые шаблоны запросов и заглушку сервиса, на которой проверяют клиента без доступа к смежной системе;
- позитивные кейсы по схеме и негативные на её нарушение: пропущенное обязательное поле, чужой тип, длина сверх ограничения, лишний элемент;
- проверка ответа по схеме, а не только по коду 200: сервис умеет возвращать тело, которое не проходит валидацию своей же XSD;
- ошибки приходят в SOAP Fault, и проверяется код и текст, а не факт падения;
- сравнение старого и нового WSDL при релизе показывает поломку контракта раньше, чем о ней сообщат смежники.
Где спотыкаются
Берут единственный пример запроса из переписки и гоняют его. Часть операций и почти все необязательные ветки схемы остаются непокрытыми, а генерация запросов из контракта дала бы полный список за пару минут.
Считают, что ответ с кодом 200 это успех. В SOAP ошибка уровня бизнес-логики часто приезжает внутри конверта, и тест, смотрящий только на статус HTTP, пропускает её.
Ждут от WSDL описания поведения. Идемпотентность повтора, таймауты, порядок обработки и смысл кодов ошибок туда не входят, их приходится согласовывать отдельно. Без этого дефект закрывают формулировкой «работает по спецификации».