軟件測試之測試過程中的配置管理

7. 上線的源碼版本為未經測試的版本

　　除了上線的源碼版本組合是未經測試的版本組合這種質量陷阱外，在發布流程中，還可能存在另一種質量陷阱。

　　在圖二中，假設文件 F1 和文件 F2 在修改之前的版本都是 1，在實現了需求 1 后 F1 的版本變成了 2，F2 的版本為 3。開發任務 1 在需求 1 修改的基礎上進行了開發，生成 F2（v4）。在測試環境測試的源碼版本為 F1（v2）和 F2（v4）。但是開發任務 1 沒有通過測試，最后部署到生產系統的版本將是 F1（v2）和 F2（v3），F1（v2）和 F2（v3）是包含了需求 1 所對應的版本。但是，F2（v3）是未經過測試的版本，這潛在的質量陷阱也可能導致發布時系統運行失效的情況。

　　解決方案

　　為了避免上述的問題的產生，筆者從以下七點出發給出測試過程中配置管理問題的解決方案。

1. 選取合適的配置管理工具
2. 整理配置項，明確相應管理流程
3. 將配置項作為一個整體進行配置管理
4. 增加發布前驗收測試環節
5. 采用并行開發方式區分不同的開發活動
6. 定制文件開發方式
7. 明確角色與職責

　　選取合適的配置管理工具

　　為了能讓開發人員不用手工記錄和追蹤缺陷修改的源碼，我們引入 IBM Rational ClearCase。通過使用 ClearCase 的 UCM 模式，我們實現了一個可以立即用于軟件開發項目的一致并基于活動的變更管理流程。UCM（統一變更管理）是 IBM Rational 提出的用于管理軟件開發過程（包括從需求到版本發布）中所有變更的“最佳實踐”流程。UCM 通過抽象層次的提升簡化了軟件開發，從而使得軟件開發團隊從更高的層次根據活動（activity）來管理變更。通過 UCM，一個開發活動可以自動地同其變更集（封裝了所有用于實現該活動的項目工件）相關聯，這樣避免了項目成員手動跟蹤所有文件變更（見圖三）。

文章來源于領測軟件測試網 http://www.kjueaiud.com/