正在修改
自由修改
否決
通過
變更控制
測試配置項剛納入版本控制時其狀態為“草稿”，有的狀態為“正式發布”，這些測試配置項通過更改評審(或審批)后，其狀態變為“正式發布”。此后若更改配置項，必須依照“變更控制規程”執行，其狀態變為“正在修改”。當配置項修改完畢并重新通過評審(或審批)時，其狀態又變為“正式發布”，如此循環。
配置項版本號規則：配制項的版本號與配置項的狀態緊密相關
測試配置管理步驟
1、識別軟件測試所需的過程及其應用，即測試需求、測試設計、測試實施、測試評估，并根據這一測試流程讓配置管理員(項目經理)創建相應的配置庫，并為每個項目用戶分配操作權限。一般地，項目用戶擁有Add、Checkin/Checkout、等權限。但是不能擁有“刪除”權限。隨后由配置管理員制定并執行更改申請程序流程、文檔更改程序流程，實施配置控制，將相應的配制管理項添加到管理工具中進行管理，此時
1)測試項目組成員根據自己的權限操作配置庫，例如Add、Checkin/Checkout、等對配置管理相進行操作。
2)配置管理員根據“基線計劃”創建與維護基線，“凍結配置項”，控制變更。
3)配置管理員定期清除配置庫里的垃圾文件。
4)配置管理員定期備份配置庫。
5)配置管理員為每一配置項指定相應的標識。
6)制定基線計劃：配置管理員確定每個基線的名稱(標識符)以及主要配置項，估計每個基線建立和提升、推薦的時間。
2、 確定配置過程所需的準則和方法，制訂這些過程形成文件的程序，以及監視、測量和控制的準則和方法;
3、對于加入配置管理的文檔、數據，項目組成員使用配置管理軟件Checkout/Checkin功能，可以自由修改處于“草稿”狀態的配置項(不受變更控制約束)，并指定其版本號。當項目組成員進行檢出/檢入(Checkout、Checkin)操作時，必須為每一次的操作做一注釋，以方便其他人員對此文檔或者數據的操作。如果配置項是技術文檔，則需要接受技術評審。如果配置項是“計劃”這類文件，則需要項目經理的審批。如果配置項通過了技術評審或領導審批則配置管理員或項目組成員應予以標示。例如在ClearCase LT中Check-out一個文件時，ClearCase就會在視圖中創建該文件的一個可編輯的版本，可以對該文件進行修改;Check-in一個文件時，ClearCase就在VOB中創建該文件的一個新的永久的版本，本地視圖中對應的文件就會變成只讀屬性，無法修改。Check out 時有兩種類型的檢出操作：保留型檢出和非保留型檢出。保留型檢出操作意味著檢出動作者能夠被保證第一個做檢入操作。非保留型檢出并不保證你是下一個檢入操作者。對于同一文件，可以存在任意個數的非保留型檢出。
4、對于需要變更的元素如：測試用例、測試數據、自動化腳本，應按照配置項變遷更改規則進行： 待變更的配置項狀態為“正式發布”，或者該配置項已經成為某個基線的一部分(即被“凍結”)。此時對其變更的主要步驟：
文章來源于領測軟件測試網 http://www.k11sc111.com/