SoapUI导入WSDL后未生成请求模板，主因是WSDL缺少有效的wsdl:binding声明或soap:address端点地址；需检查绑定类型、端点可达性及XSD引用路径。
SoapUI里WSDL导入后没生成请求模板？检查wsdl:binding和soap:address
SoapUI读WSDL不是“有文件就能用”，它依赖WSDL中明确声明SOAP 1.1/1.2绑定和有效端点地址。常见现象是导入后接口列表为空，或只有空的TestRequest节点——这通常不是SoapUI坏了，而是WSDL本身不完整或被精简过。
实操建议：
- 用浏览器或
curl打开WSDL URL，搜索<binding>，确认存在<code>type="tns:..."且对应<porttype></porttype> - 检查
<address location="..."></address>是否为真实可访问地址（有些WSDL用http://localhost或占位符，SoapUI会跳过） - 若WSDL含
import多个XSD，确保所有引用路径可解析（本地文件需用file:///绝对路径，网络URL需能直连）
生成的XML报文字段全为空？别急着手写，先看request节点的useDefaultValues设置
SoapUI默认不填默认值，尤其当WSDL里字段定义了default="xxx"或fixed="yyy"，但生成的XML里仍是空标签。这不是bug，是设计行为——它把填充逻辑交给了你。
实操建议：
- 右键
Request→Get Data Type Info，确认字段是否真有default属性；没有的话，空是合理的 - 双击请求编辑区任意空白处，勾选右下角
Use default values复选框（注意：该选项只对当前请求生效，不继承到新复制的请求） - 如果字段类型是
xs:dateTime，SoapUI不会自动生成2024-01-01T00:00:00+08:00这种格式，得手动补或用${=new Date().format('yyyy-MM-dd\'T\'HH:mm:ssXXX')}脚本
想批量生成不同参数组合的测试报文？别用Groovy脚本硬扫，优先用DataSource + DataSink链
直接写Groovy循环拼XML容易失控：字段嵌套深时字符串拼接易错、SOAP Header难统一、失败后不好定位哪组数据崩了。SoapUI原生的数据驱动机制更稳，也方便后续导出为CSV或对接CI。
实操建议：
- 在TestCase里加
DataSource步骤，类型选Excel或CSV，列名必须和XML中字段名严格一致（大小写敏感） - 把
Request里的变量写成${DataSource#col_name}，不是${col_name}——后者是全局属性，会跨请求污染 - 加
DataSink步骤前，务必先运行一次单条数据，确认Response能正常解析XPath（比如//ns:return/text()），否则DataSink写入会失败静默
中文字符乱码或特殊符号报org.apache.xmlbeans.XmlException？关掉Auto Detect Encoding并显式设UTF-8
SoapUI默认开启编码自动探测，遇到WSDL里声明encoding="UTF-8"但实际内容含BOM或混合编码时，解析XML Schema阶段就崩溃，错误堆栈里常带XmlException: error: 后面跟一堆不可见字符。
实操建议：
- 菜单
File → Preferences → HTTP Settings，取消勾选Auto detect encoding for responses - 在
Request窗口右上角点击Raw标签页，在首行手动加上<?xml version="1.0" encoding="UTF-8"?>（即使WSDL没写，也要加） - 如果WSDL本身是GBK编码（老国产系统常见），导入时选
File → Import WSDL → Advanced → Encoding，手动选GBK，否则xs:element name里的中文注释会变问号，导致后续字段识别失败
WSDL不是标准文档，是契约也是妥协。真正卡住的往往不是SoapUI操作，而是WSDL里某个没公开的tns:命名空间别名，或者SOAP Header里那个从不写进WSDL却强制要求的AuthTicket字段——这些得翻对方接口文档，或者抓包比对。
