利用軟件測試開源工具Rational ClearQuest 進行變更管理 軟件測試工具
關鍵字:Rational 管理技術
ClearQuest MultiSite 主控權的功能就是確保一個 ClearQuest 記錄只能夠同一時間在一個數據庫鏡像站點更新。一個登陸到站點的用戶如果沒有記錄的主控權,只能查看記錄信息,而不能夠對它進行修改。要想進行記錄更新,用戶必須登陸到擁有主控權的站點。
考慮這樣一個場景,客戶在倫敦,支持代表在班加羅爾,開發人員在羅利,測試人員在北京。如果這個變更請求的確認發生在北京,這也是一個數據庫鏡像的地點,這個記錄所有者可能要從一個站點更換到另一個站點,比如這個記錄的狀況從活動變更到解決以及修正需要確認的情況。(注意:用戶可以登陸到任何一個鏡像中來讀取信息,但是必須登陸到一個擁有主控權的鏡像才能變更這個記錄。)
樂觀鎖定
當兩個人要更新同一個記錄時,ClearQuest 就可以利用樂觀鎖定來處理這種情況。第一個保存記錄更新的人——并不是第一個為了更新而打開記錄的人——會成功。其它的變更就不會被保存。因此,第二個試圖更新記錄的人將需要重新得到這個記錄并重新進行他或者她的更新。
我可以推薦一個減少這些麻煩的技術,因為 IBM Rational 內部也使用它,就是利用一個叫作 Record_Script_Alias 的 ClearQuest scripted Action 類型創建一個記錄。這個 Action 在一個遠程的或者同時正在進行更新的記錄上執行。它可以創建一個新的記錄并且在這個帶有 Action 記錄 ID 的新記錄上更新一個新的字段。ClearQuest 然后創建一個從這個新的記錄 ID 到這個 Action 記錄的 反向引用(back-reference),不管是否設置了主控權。這兩個記錄都是對方的相關擴展——直接在當前站點,接下來就鏡像到其他站點。這個反向引用確保相連接的記錄能夠合適地更新。也就是說,當您創建一個記錄并更新涉及的字段時,這個反向引用將會更新相關的記錄,不管主控權還是樂觀鎖的爭用。
這里還有一個更進一步的提示:當創建子記錄作為創建父記錄的副產品時,使用您創建的父記錄的 Commit Event 來創建這個子記錄。
所有權(Ownership)的角色
由于鏡像的局限性,對于 ClearQuest 來說不能實時地確定記錄是否在更多的站點被創建或者變更。因此,如果記錄在多個站點被創建并反向引用,對于用戶來說是不可能在事前知道這些情況的。您可以通過分配所有權和確定最有可能執行 Action 的人(或者唯一的人員)來進行限制。這樣就縮減了與記錄相關的冗余的過程,更有效地創建一個虛擬調度機制。
這個方法同時還簡化了主控權和樂觀鎖爭用問題的解決。就是說,您即可以象上面所描述的一樣來創建一個記錄然后用反向引用連接記錄,也可以用所有者指派的隱含更新來構建記錄。您不必同時使用兩種方法。
基于角色的用戶體驗
為了設計、實現和管理變更管理系統,ClearQuest 產品支持基于角色的模型 。
原文轉自:http://www.anti-gravitydesign.com