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

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也要修改。