在實際的操作過程中，配置管理中，各人員的權限控制非常重要，所謂建立統一的配置管理入口，我個人認為配置管理中的基線管理與人員權限管理的結合即可實現。一旦某一個基線建立之后，責任人對變更有讀寫權限，而其他人只有讀的權限;如果是多人共同修改一個任務包，那可以通過控制任務包的粒度或者控制修改的順序可以保證任務包的唯一性(不會出現多個版本)。所謂統一的出口，指定責任人(配置管理員或者項目負責人)從配置管理庫中提取并且分配任務包即可。注意：任務包中不僅僅包含代碼，必須包含相關的文檔，在每次變更代碼時，保證文檔同步更新。需求的變更管理，首先保證變更的需求必須經過評審、入基線;然后要保證需求、設計、代碼、測試的系統管理和可跟蹤性;如果單獨把需求變更管理拿出來單獨管理，很難保證其他基線的同步變更和可跟蹤性，這是我堅持需求變更不能用TD管理的主要原因。所謂保證測試的獨立性，并不是指不能與需求變更一起去管理;而是相對的獨立，最起碼，要保證人員和人員管理是獨立的;至于用例以及bug的管理，在不同的階段涉及到各類權限以及方方面面人員的參與，但是其主導的仍舊是測試人員和項目的負責人，這就是相對獨立性的局限性，畢竟bug的最終確認需要測試人員和項目負責人協商確定。但是因此就把需求變更的流程放到TD中去，似乎更加亂了。如果td單獨管理bug，是可以通過狀態來控制流程，甚至是可逆的;但是需求變更呢?一旦評審不通過，我們將如何處理?顯然，流程在TD中是走不下去的。 軟件測試
這個問題，不僅僅涉及到需求變更與測試中對應的bug之間的可跟蹤關系;還有變更后的設計呢，編碼呢?怎么保證他們都經過評審，并且用一條線把變更的需求、設計、編碼、測試用例、bug管理都串起來?實現他們的可跟蹤性，我想這不僅僅是某個工具能夠解決的問題，凌駕于工具之上的是建立統一的過程管理，當然，凌駕于過程之上的，是參與其中的人怎么去執行的問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/