針對這種情況，筆者建議將不同類型的開發活動按照緊急性或類型將工作區分開來，這就涉及多個版本的并行開發，如項目 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 實現并行開發模式圖
定制文件開發方式
在項目實際開發中，通常需要對文件進行并行開發，因此存在因為多人同時修改同一個文件而需要對文件進行合并的情況。對于大部分格式的源碼，配置管理工具都提供不同程度的自動合并功能。但是對于不能合并的二進制文件或不允許合并的文本文件(例如通過第三方開發工具導出的文本文件，ClearQuest 模式文件等)，就不適合使用并行開發方式。因為這些文件或者不能合并，或者是不能通過簡單的合并來實現版本的合并。對于這類文件如果處理不當，就會導致測試時使用了錯誤內容的版本，導致測試不通過。
但是，在項目實際開發中又不能因為存在這類特定類型的文件，而限制使用并行開發方式。串行開發與并行開發是矛盾的，如何解決這個問題是存在這類文件的項目在開發和測試過程中很頭痛的一個問題。IBM Rational ClearCase 可以很好的解決這個問題。我們可以利用 ClearCase 提供的強大的二次開發功能，為這些不能進行合并的二進制文件或不允許合并的文件創建特定的文件類型。在執行檢出操作時，判斷該文件是否屬于已定義的特定類型文件。如果是，則判斷該文件是否已經被檢出。如果已經被檢出則不允許執行檢出操作。通過這種方式，我們既可以保證大部分的源碼可以進行并行開發，又能解決這類特定類型文件的串行開發問題。
明確角色與職責
在整個測試過程與配置管理過程中，要非常清晰項目的角色劃分，及角色對應的職責，并要求相關角色人員嚴格履行各自的職責。某個大型已上線系統在進行升級時就有過一次因角色與職責混淆的教訓。在這次升級上線手冊中有“檢查四個參數 A、B、C、D”這么一個步驟，測試人員在測試時發現測試環境因沒有這四個參數而導致了測試失敗，于是測試人員聯系開發人員，得知創建這四個參數的方法，以及需要設置的參數值。然后測試人員在測試環境自行創建了這四個參數。由于正確設置了這四個參數后，此次升級測試通過。當該升級包提交運維組部署到生產環境時，運維組按照上線手冊要求檢查了生產環境，發現生產環境有這四個參數(但不是開發人員期望設置的值)，并且有測試組提供的測試報告，于是他們將升級包按照上線手冊步驟部署到生產環境。但是上線后由于這四個參數設置了錯誤的值，導致系統停產 40 多分鐘。
在這個事故中，開發人員與開發人員都有責任。測試人員未按照上線手冊要求完成他的工作(只是“檢查”，而不是“創建”)，這本身就是一個違規操作。另外，他沒有將實際情況與上線手冊的不一致向開發組提出并由開發組更新上線手冊，在開發組提交更新后的上線手冊后，測試組重新檢查測試環境并測試。開發人員則未在上線手冊寫明參數具體設置的值，上線手冊存在不明確信息。
所以在項目的各個過程，包括軟件測試過程和配置管理過程中，一定需要明確各角色相應的職責及工作范圍，避免類似事故的發生。
總結
配置管理貫穿于項目所有過程中，本文主要從軟件測試的角度分析了測試中經常碰到的問題，闡述了軟件測試和配置管理之間的密切關系。為了解決測試中存在的配置管理問題，筆者針對測試過程常見問題產生的原因，從配置管理角度給出了相應的解決方案。筆者希望通過本文，能夠改變軟件測試工作中不需要關注配置管理的錯誤思想。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
