0

我在 SoapUI 测试用例中有一个 JDBC 请求测试步骤,其中一个属性Foo已由前面的属性传输测试步骤分配了一个值 - 例如12345

我想使用 Contains 断言来检查测试步骤的响应是否包含Foo' 值(因为测试步骤的 SQL 查询本质上是一个标量SELECT- 例如SELECT TOP 1 FooColumn FROM SomeTable WHERE FooColumn = :Foo),但这证明有点棘手。

SoapUI 页面开始使用 JDBC 测试步骤,我尝试:Foo了 Contains 断言:this yielded -> Missing token [:Foo] in Response

所以我尝试${:Foo}了:这个“成功”,但我发现${:Whatever}Whatever不是定义的属性)并且${}“成功”了。这似乎不正确。

如何正确断言 JDBC 请求的响应包含Foo' 值?

4

1 回答 1

0

事实证明,JDBC 请求断言中的属性扩展类似于典型测试请求中的属性扩展(即,就像属性扩展上的 SoapUI 页面所解释的那样)。

:Foo特别适用于 JDBC Request 的SQL Query中的属性扩展。在测试步骤的包含断言中,标准属性扩展适用,并且${JDBC Request Name#Foo}工作 - 成功而不是“成功”。相比之下,${JDBC Request Name#Whatever}不出所料地失败了。

我仍然不清楚为什么${:Foo},,${:Whatever}而且${}一切似乎都成功了。如果有人能阐明那部分,我很想理解。

更新:

虽然对标准属性扩展的更改是正确的,但仅此更改对于 JDBC 请求测试步骤之前的属性传输测试步骤没有向属性传输任何内容的情况仍然不够Foo

在这种情况下,JDBC 请求的 Contains 断言产生了误报,因为Foo' 的值是空字符串,当然 JDBC 请求的(零行但非空)响应包含该字符串。更改包含断言以<FOOCOLUMN>${JDBC Request Name#Foo}</FOOCOLUMN>解决此问题。

这让我意识到 , 和 all 似乎都成功的可能原因${:Foo}${:Whatever}它们${}扩展为空字符串,JDBC 请求的响应再次包含这些字符串。符合这个假设,在复查时<FOOCOLUMN>${:Foo}</FOOCOLUMN>确实失败了。-> Missing token [<FOOCOLUMN></FOOCOLUMN>] in Response

现在我只是想知道为什么${:Foo},${:Whatever}${}扩展为空字符串,我希望它们会产生错误。

于 2013-10-09T06:33:46.840 回答