SoapUI полезен QA там, где интеграция строится вокруг SOAP, WSDL, XML и последовательностей сервисных вызовов. Он позволяет работать с сообщениями и контрактом на уровне, который плохо виден из пользовательского интерфейса. Например, кнопка «Создать договор» может скрывать обмен несколькими SOAP-сообщениями, проверку пространства имён и обработку SOAP Fault. Чтобы проверить такую цепочку, недостаточно увидеть успешный HTTP-ответ: нужно понимать смысл самого сообщения.
Как связаны WSDL, SOAP и проект
WSDL описывает интерфейс сервиса: операции, сообщения, привязки и адреса. XML Schema задаёт структуру и ограничения данных. SOAP-конверт содержит служебную и содержательную части сообщения. При импорте WSDL SoapUI помогает получить запросы, но шаблон ещё не является рабочим тестом. В нём могут остаться вопросительные знаки, необязательные элементы и неподходящий адрес. QA проверяет актуальность зависимых XSD, версию контракта и настройки тестового endpoint.
Модель TestSuite, TestCase и TestStep
Проект объединяет настройки и тестовые наборы. TestSuite группирует сценарии, TestCase описывает исполняемую цепочку, а TestStep выполняет отдельное действие: отправляет запрос, хранит свойства, переносит значение или выполняет скрипт. Assertions оценивают ответ. Это помогает разделить понятный бизнес-сценарий на диагностируемые шаги. Если получение идентификатора не удалось, последующее чтение договора не должно выглядеть самостоятельным дефектом сервиса: сначала разбирают причину первоначального сбоя.
SoapUI и ReadyAPI: где проходит граница
В документации встречаются примеры для SoapUI и ReadyAPI. Некоторые шаги, в частности расширенные DataSource/DataSink и связанные возможности, относятся к ReadyAPI. Не переноси название функции из инструкции в обещание возможностей любой установленной редакции. Для своей команды фиксируй продукт, версию и реально доступный способ запуска. Начать полезнее с одного запроса и осмысленного assertion, чем проектировать сложную архитектуру вокруг отсутствующего компонента.
Что подготовить до первого запроса
Попроси действующий WSDL со всеми зависимостями, тестовый адрес, схему авторизации и пример корректных бизнес-данных. Отдельно уточни ограничения дат, кодировок и справочников. XML, валидный по XSD, может содержать несуществующий код подразделения или договор с недопустимым состоянием. Убедись, что тестовое окружение не отправляет реальные документы клиентам. Для сервиса с сертификатами также важно знать, кто выдаёт тестовые credentials и как обновляются доверенные сертификаты.
Практика: создать договор и прочитать его
Пусть операция CreateContract принимает customerCode и amount, возвращает contractId, а GetContract возвращает состояние договора. По требованиям amount задаётся десятичным числом, минимальное значение равно 0.01, валюта фиксирована. Создание выполняется на тестовом клиенте, а повторное чтение должно подтверждать сохранение суммы. Сначала согласуй эти ожидания с контрактом продукта; названия полей в этом примере условны.
- 1.Импортируй WSDL и проверь endpoint каждого запроса. Подставь допустимого тестового клиента и amount=100.50; ожидается бизнес-успех с идентификатором.
- 2.Добавь assertions для отсутствия неожиданного SOAP Fault, корректной структуры ответа и непустого contractId. Одной проверки «в ответе есть число» недостаточно.
- 3.Через Property Transfer перенеси contractId в свойство TestCase и используй его в GetContract. Ожидаются тот же клиент, сумма и начальное состояние.
- 4.Повтори создание с amount=0 и с отсутствующим customerCode. Ожидаются согласованные ошибки; убедись, что новый договор не появился.
- 5.Сбрось временный идентификатор и повтори сценарий. После ошибки CreateContract чтение не должно использовать договор предыдущего запуска.
Свойства и перенос значений
Свойства проекта подходят для общих несекретных настроек, TestSuite — для параметров набора, TestCase — для данных конкретной цепочки. Ссылка вида ${#TestCase#contractId} подставляет значение свойства в запрос. Property Transfer извлекает значение из ответа и передаёт его следующему шагу. При XML учитывай namespaces: одинаковое локальное имя элемента ещё не означает, что XPath выбрал нужный узел. Проверь результат извлечения на пустом и ошибочном ответе.
Для динамических данных можно использовать Groovy, но не стоит прятать весь сценарий в одном длинном скрипте. Простой явный перенос и отдельная проверка структуры обычно понятнее человеку, который расследует ночное падение. Скрипт должен завершаться понятной ошибкой, если предпосылка не выполнена, а не заменять отсутствующий идентификатор случайной строкой и продолжать цепочку.
Assertions на нескольких уровнях
Сначала проверь транспорт: пришёл ли ответ и соответствует ли HTTP-поведение договорённости. Затем SOAP: успешный ответ или ожидаемый Fault, правильная операция и пространство имён. После этого проверь схему и бизнес-значения. Не всякая ошибка имеет один и тот же HTTP-код, а отсутствие Fault само по себе не доказывает успех. Сравнение XML как обычной строки хрупко: префиксы namespace и форматирование могут измениться без изменения смысла.
Учитывай и поведение потребителя при изменении контракта. Если добавлен необязательный элемент ответа, проверь старого клиента: строгий десериализатор может отклонить сообщение, хотя новая схема выглядит совместимой. Для финансовых значений сравнивай десятичный смысл и установленное округление, а не количество пробелов в XML. Если сервер возвращает дату со смещением, проверь её интерпретацию в согласованной временной зоне. Эти проверки находятся за пределами простого «соответствует XSD», но часто определяют, сохранится ли рабочая интеграция после выпуска.
Негативные проверки и диагностика
Полезны неизвестный клиент, превышение допустимой суммы, некорректный формат даты, отсутствие обязательного элемента и повтор операции. Отдельно исследуй различие между отсутствующим элементом, пустым значением и xsi:nil, когда схема их допускает: сервер может обрабатывать эти состояния по-разному. При сбое сохрани обезличенные request/response, версию WSDL, endpoint и время. Не публикуй сертификаты, пароли и полные персональные данные в отчёте или проектном XML.
Ограничения и типичные ошибки
SoapUI не отменяет проверки совместимости потребителей и не заменяет наблюдение за реальными побочными эффектами. Успешный вызов может сохранить неверную сумму или дважды создать документ. Частые ошибки — оставить устаревший WSDL, передать предыдущий id, отключить проверку сертификата навсегда и считать проверку строки достаточным assertion. Хороший проект объясняет контракт, контролирует данные и даёт локальную причину падения. Именно это делает его пригодным для поддержки enterprise-интеграций.