SoapUI有些TestStep对应的Resource总是会自动改变

摘要: SoapUI测试中Resource会影响TestStep当初选择的Resource Method

1. 问题描述：

我在ReadyAPI的Projects面板中添加了一些Resource资源，然后某一个资源“AA”被加入到了SoapUI NG面板的TestCase中，成为了一个TestStep的URL。

因为测试的API越来越多，发现有些API的URL之间差别很小（可能只有一个单词不同或者多了少了几个参数），于是通过克隆或者重新添加的方法将这个新的Resource也放到了原有资源“AA”所在的目录下，并且重命名为“BB”，最后BB也被关联到了某一些TestStep中。一切在我如行云流水般的操作下看起来那么顺手那么正常。

但是某一天，当我打开原来关联了资源“AA”的TestStep并运行的时候，在该TestStep信息面板中看到关联的Resource从AA变为了BB。查了一下log发现并没有改动这个TestStep的资源啊，究竟是谁在作怪？只能当做是自己不小心点错了，毕竟一天要自动化很多case啊，偶尔出错也是可能的。。。

所以立马改成了AA，运行一下正常，提交代码。。。但是下次打开，或者重新关闭该TestStep的详细信息面板在重新打开，再或者重新加载Project并打开该TestStep，发现该TestStep关联的Resource又从AA变成了BB。。。 还有的时候，本地都是好好的，但是Jenkins远程跑的时候却奇葩的关联错误的Resource BB，这个时候有点怀疑人生啊。。。

查了各种资料，有了自己的解决方法，在此以两个场景和方法为例说明。

2. 解决方法一：

两个URL都是相同的，不同的是一个URL只需要用在普通的TestStep中，这时候URL的固定参数部分参数化为"${#TestCase#portfolioId}". 另一个需要用在被DataSource和DataSource Loop包围并且需要使用DataSource中的portfolioId，这时候URL固定部分参数化为“${DataSource#portfolioId}”.



如上图所示，每个TestStep都有对应的Resource，有时候为了适应不同的测试场景，我们需要同一个resource有两种参数形式，类似portfolioId会有"${#TestCase#portfolioId}"和"${DataSource#portfolioId}"这两种形式，因为portfolioId是一个api的固定URL中的一部分，所以这两种形式的参数需要建立两个Resource：



然后我们就根据自己的测试需求，从第一张图所示的下拉列表中选择要使用哪一种参数的resource，然后运行。

本来这些操作如行云流水般自然，但是当你第二天打开Project运行整个项目的时候，你会发现：
原本应该用第一种参数形式的TestStep自动选择用第二种参数形式的resource，而且即使你删除缓存，重新加载Project也不行，这种映射关系始终不能保存。

后来研究发现这是因为在同一资源文件夹下面，若仅仅是上图所示的参数形式不同，即使你新建了不同的resource，这些不同的resource会被SoapUI赋同一ID，也就是你想的并不是SoapUI机器所想的。。。。

为了绕开上述问题，相处了如下解决方法：

01. SoapUI的Resource分类如下：



02. 如果PAAPI中有多个resource是同样的URL，仅仅是因为固定URL中的某一参数被参数化成不同的形式了，那就将其放入另外一个文件夹中：



03. 在PAAPI01和PAAPI02 文件夹中都只能放入唯一的resource，之前会引发冲突的要全部删除。

这样你就必须去更新Project中的TestStep，因为这些resource相关的TestStep都会被删除。

类似：原来PAAPI中有两个resource : dates1和dates2，他们仅仅是参数化不同，在将dates2删除的时候，TestStep中用到dates1 或者dates2的全部都会被删除。。。。 这点很痛苦。。。。

3. 解决方法二：

上述的解决方法虽然复杂且需要修改的TestStep非常多，过程很痛苦。。。但终究解决了眼前的问题啊。

突然，某一天，一个灰蒙蒙的下雨天的下午，我的同事碰到了另外一个类似的问题找我解决，我才硬着头皮试着从根本上解决这一类问题。

情况是这样的，有两个URL，参数相同，但是URL的固定部分仅仅最后一个单词不同（这种URL的设计是为了适应一个Component的不同视图），这两个URL的格式如下：

a.http://${servername}/${product}/v1/${component}/metrics?investmentIds=0P00002PNZ&benchmark=0P00001GK1。。。。。

b.http://${servername}/${product}/v1/${component}/trend?investmentIds=0P00002PNZ&benchmark=0P00001GK1。。。。。

其中a已经被加入到SoapUI中了,被关联的TestStep叫AA，现在要添加b，但因为参数很长，所以QA选择了clone原有的资源a，然后修改metrics为trend，然后把资源重命名为b,并且关联到TestStep BB中去。

在本地跑的挺好的，但是代码上传到git并且在Jenkins上面跑的时候发现AA失败，看了Console Output发现AA现在居然跑的是资源b的URL，也就是说好端端的AA被关联到了b资源上。。。但是本地却运行正常，这是见鬼了吗？

这种情况如果用第一种情况解决有点不合情理，于是趁着这个机会，我就用了终极解决方法。

这个方法需要了解SoapUI将这些Resource，TestSuite，TestCase和TestStep关联起来的逻辑。于是我就研究了一个TestSuite所有TestCase的xml文件，和这些TestCase中TestStep用到的Resource对应的XML文件，发现他们之间的关系如下：

001：这是项目在SoapUI中的目录结构：





002：这是项目在本地中的目录结构：



003：某一个TestSuite "ClientsAPI"在SoupUI中的结构：



004：“ClientsAPI”在本地中的结构：



从上面的这些图里面可以看到每个TestSuite都在本地有一个文件夹，每个TestCase都在本地保存成了xml文件，那么TestCase中的那么多的TestStep，以及每个TestStep关联的URL是怎么被记录到这些TestCase的xml中呢？

打开一个TestCase的xml你会找到所有问题的答案：



我这些截图都是以当前自己写的Project为例，为了让大家查看方便就格式化了，并且隐藏了很多其他东西。

现在我们打开该Accounts其中一个个TestStep “GetAccountList_PAAPI”对应的URL所在的accounts.xml文件:



你会发现这个URL的ID跟用到了该Resource的TestStep中的<con:restRequest>节点中的ID是相同的，没错，他们就是这么关联的。

如果一个URL是被Clone的或者两个URL的固定部分都是相同的，那么虽然在资源面板他们被展示成不同的URL，但是在本地资源文件夹中却有着相同的ID, 这就是导致上面两种场景的罪魁祸首。

所以终极解决方法就是修改其中一个URL的资源ID，并且需要与此URL关联的TestCase的xml中对应的TestStep节点用到的URL也要修改。