圖四 獲得活動包含變更集圖
2. 整理配置項，明確相應管理流程
為了避免因配置項缺失導致開發環境、測試環境和生產環境的不一致，我們需要對系統中所有的配置項（如公共參數/基礎數據/配置信息等）進行整理，明確各種類型配置項的存放方式、控制流程。例如：某項目的SQL建表文件、UNIX操作系統的配置參數文件屬于系統的全局文件，其存放方式為文本文件。根據項目測試與配置管理要求，項目相關負責人針對全局文件定義了相應的控制流程（見圖五）。
圖五 某項目全局文件控制流程圖
同樣的，對于源碼這類文件，我們也需要規范相應的管理流程。通過使用ClearCase UCM方式，開發人員在修改源碼時，可以使用ClearCase的“處理活動”功能，快速切換當前處理的活動，使他們可以選擇正確的活動進行源碼修改。采用UCM方式的好處之一，就是項目成員對于配置庫的修改必須有活動關聯，如果沒有分配給操作用戶的活動，用戶就無法對配置庫進行任何修改。這對于正在運行的系統而言，源碼的修改獲得批準是非常重要的。
3. 將配置項作為一個整理進行配置管理
配置管理工作是整個軟件開發過程的生命線，對于測試人員來講，由于測試產品與開發產品之間的密切關系（見2產生原因），測試人員必須得到自己關心的程序的任意一個測試版本，以便可以在正確的版本上執行正確的測試用例。
由于上述原因，我們需要將配置項作為一個整體進行配置管理，方便進行測試版本的回溯。我們可以通過ClearCase的基線來實現這個功能。UCM將項目活動嵌入到各個基線中，這樣測試人員可以確切地知道他們將測試什么，而開發人員則確切地知道其他開發人員做了什么。在其他一些配置管理工具中，基線只是一個文件版本的快照，并沒有將該快照關聯修改這些文件對應的活動。
4. 增加發布前驗收測試環節
由于缺少獨立的發布前的確認測試環節，而將程序潛在的質量陷阱（見圖一和圖二）遺留到在生產環境部署后才爆發。為了避免這種風險的發生，筆者建議在項目的配置管理流程中增加發布前驗收測試環節。所有上線的發布包，必須將上線包在發布前驗收測試環境中進行驗收測試。待驗收測試通過后，方可在生產環境部署（見圖六）。
圖六 某項目變更與發布流程圖
5. 采用并行開發方式區分不同的開發活動
在項目實際開發中，開發人員會面臨不同類型的開發活動，如變更、缺陷、新增特性等。而不同類型的開發活動，它的緊急程度不一樣，如果將這些開發活動混在一起工作，那么可能因為版本間的依賴影響項目的上線進度。另外，這種工作方式也會影響項目測試工作的開展。由于上線計劃可能只包含部分開發活動，導致測試環境有不同上線階段的開發活動需要測試，這種方式無形中增加了運行在生產環境的源碼組合為未經測試的版本組合（見圖一）和未測試的版本（見圖二）的幾率。
針對這種情況，筆者建議將不同類型的開發活動按照緊急性或類型將工作區分開來，這就涉及多個版本的并行開發，如項目V1.0的缺陷修復、V1.0的新增功能版本V1.1、新版本V2.0。IBM Rational ClearCase可以很好的支持這種并行開發模式。在ClearCase中，我們可以在項目V1.0的發布基線（V1.0_rel01_20071101）的基礎上分別創建針對三種版本（V1.0_bugfix、V1.1、V2.0）的開發項目（見圖七）。在ClearCase管理下，這三種版本位于不同的分支下，他們的開發是獨立的，互不影響，并且版本V1.0_bugfix中的缺陷修復可以及時的合并到版本V1.1和V2.0中，版本V1.1的新增功能也可以在需要的時候合并到版本V2.0中。
圖七 ClearCase實現并行開發模式
6. 定制文件開發方式
在項目實際開發中，通常需要對文件進行并行開發，因此存在因為多人同時修改同一個文件而需要對文件進行合并的情況。對于大部分格式的源碼，配置管理工具都提供不同程度的自動合并功能。但是對于不能合并的二進制文件或不允許合并的文本文件（例如通過第三方開發工具導出的文本文件，ClearQuest模式文件等），就不適合使用并行開發方式。因為這些文件或者不能合并，或者是不能通過簡單的合并來實現版本的合并。對于這類文件如果處理不當，就會導致測試時使用了錯誤內容的版本，導致測試不通過。
但是，在項目實際開發中又不能因為存在這類特定類型的文件，而限制使用并行開發方式。串行開發與并行開發是矛盾的，如何解決這個問題是存在這類文件的項目在開發和測試過程中很頭痛的一個問題。IBM Rational ClearCase可以很好的解決這個問題。我們可以利用ClearCase提供的強大的二次開發功能，為這些不能進行合并的二進制文件或不允許合并的文件創建特定的文件類型。在執行檢出操作時，判斷該文件是否屬于已定義的特定類型文件。如果是，則判斷該文件是否已經被檢出。如果已經被檢出則不允許執行檢出操作。通過這種方式，我們既可以保證大部分的源碼可以進行并行開發，又能解決這類特定類型文件的串行開發問題。
7. 明確角色與職責
在整個測試過程與配置管理過程中，要非常清晰項目的角色劃分，及角色對應的職責，并要求相關角色人員嚴格履行各自的職責。某個大型已上線系統在進行升級時就有過一次因角色與職責混淆的教訓。在這次升級上線手冊中有“檢查四個參數A、B、C、D”這么一個步驟，測試人員在測試時發現測試環境因沒有這四個參數而導致了測試失敗，于是測試人員聯系開發人員，得知創建這四個參數的方法，以及需要設置的參數值。然后測試人員在測試環境自行創建了這四個參數。由于正確設置了這四個參數后，此次升級測試通過。當該升級包提交運維組部署到生產環境時，運維組按照上線手冊要求檢查了生產環境，發現生產環境有這四個參數（但不是開發人員期望設置的值），并且有測試組提供的測試報告，于是他們將升級包按照上線手冊步驟部署到生產環境。但是上線后由于這四個參數設置了錯誤的值，導致系統停產40多分鐘。
在這個事故中，開發人員與開發人員都有責任。測試人員未按照上線手冊要求完成他的工作（只是“檢查”，而不是“創建”），這本身就是一個違規操作。另外，他沒有將實際情況與上線手冊的不一致向開發組提出并由開發組更新上線手冊，在開發組提交更新后的上線手冊后，測試組重新檢查測試環境并測試。開發人員則未在上線手冊寫明參數具體設置的值，上線手冊存在不明確信息。
所以在項目的各個過程，包括軟件測試過程和配置管理過程中，一定需要明確各角色相應的職責及工作范圍，避免類似事故的發生。
總結
配置管理貫穿于項目所有過程中，本文主要從軟件測試的角度分析了測試中經常碰到的問題，闡述了軟件測試和配置管理之間的密切關系。為了解決測試中存在的配置管理問題，筆者針對測試過程常見問題產生的原因，從配置管理角度給出了相應的解決方案。筆者希望通過本文，能夠改變軟件測試工作中不需要關注配置管理的錯誤思想。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
