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