軟件測試的“泥潭”
可能有讀者會覺得奇怪，軟件測試就是發現軟件中隱藏的缺陷，和配置管理有啥關系呢。但是，不知道大家在實際工作中有沒有發現，我們在軟件測試工作中碰到的一些問題，實際上就是由于配置管理工作沒做好而產生的。
在軟件測試工作中，我們經常碰到以下三個問題：
缺陷只能在測試環境出現，但是在開發環境中無法重現；
已經修復的缺陷在測試時又重現；
發布程序在內部確認測試中測試通過，但是發布時卻發生系統運行失效的情況。
“泥潭”產生的原因
不考慮缺陷報告描述不清楚這種情況，究其原因，上述三個問題的產生主要有以下七點原因：
1. 測試環境配置的復雜性
由于不同（版本）的操作系統、不同（版本）的數據庫，不同（版本）的網絡服務器、應用服務器，再加上不同的系統架構等組合，使得要構建的軟件測試環境多種多樣、不勝枚舉；而且現在隨著軟件運行環境的多樣性、配置各種相關參數的“浩大工程”和測試軟件的兼容性等方面的需要，使得構建軟件測試環境的工作變得較為復雜和頻繁，而軟件測試環境的構建是否合理、穩定和具有代表性，將直接影響到測試結果的真實性、可靠性和正確性。在筆者曾經做過的一個項目中，由于測試環境使用了和開發系統不同版本的JDK（測試環境使用JDK1.5，而開發環境為JDK1.4），導致測試中出現了在開發環境不會出現的缺陷。
2. 測試產品與開發產品之間的密切關系
在一個項目的軟件測試過程中，會有大量的“產品”產生，典型的如文檔（包括測試計劃、測試用例、測試報告、日常管理文檔等）、數據、腳本等。軟件測試的一個獨特的特征，就是他的產品都是基于開發產品（如源代碼、文檔、安裝文件等）產生和變化的。而開發產品都是以“信息”的形式存放在計算機中，因此，較硬件而言，開發產品比較容易被修改和變化。一旦開發產品發生改變，測試產品也需要相應發生改變。如何有效的管理測試產品，維護測試產品與開發產品之間的關系成為測試過程中的一個棘手的問題。
3. 開發人員在處理新的開發任務時間接修復了缺陷
由于缺少工具的支撐，開發人員不能詳細的、準確的獲取提交測試的缺陷涉及修改的源碼，所以在有些項目組中，每次測試時，開發人員將個人開發的所有源碼提交給測試人員，由測試人員采用完全覆蓋的方式更新測試環境。但是由于開發人員的工作環境仍在進行新變更、新功能或缺陷的處理，而修改新變更、新功能或缺陷的同時，很容易將原來存在的缺陷一并修復。這就可能導致測試環境中存在的缺陷在開發環境中無法重現問題的發生。
4. 開發人員漏提交待測試的源碼
假設項目組意識到完全覆蓋方式的不合理，要求開發人員只能提交修改缺陷或變更對應的源碼供測試�？墒怯捎谌鄙俟ぞ叩闹�，開發人員只能手工記錄、追蹤變更和缺陷對應修改的源碼，這種方式一是記錄和追蹤的工作量大，二是很容易漏提交源碼。由于開發人員漏提交源碼，就很容易發生測試環境的缺陷在開發環境無法重現或者已經修復的缺陷又重現的情況。
5. 公共參數/基礎數據/配置文件未進行配置管理
一些項目組未將公共參數/基礎數據/配置文件等全局文件納入配置管理。由于沒有將其納入配置管理，所以這部分全局文件的變更也同樣的未進行變更管理。當這些全局文件發生變更時，很容易出現測試環境、開發環境，甚至包括生產環境配置不一致的情況。一旦出現這種情況，那么即使發布程序在內部確認測試時測試通過，但是部署到生產環境后系統運行失效的情況就在所難免。這實際上是因配置項缺失而帶來的問題。
很多人可能不認為公共參數或者基礎數據應該作為配置項納入配置管理，實際上這種想法是錯誤的。假設沒有將這些公共參數等信息納入配置管理，那么試想一下，假設有一天系統意外崩潰，我們拿什么去恢復生產環境？所以說，系統運行支撐的所有內容（包括基礎數據、配置文件等）都需要納入配置庫進行配置管理。
曾經有這樣一個案例：某審批系統的公司組織機構信息是通過數據庫進行維護的。項目組在處理某個需求變更時，需要相應修改公司組織機構信息，但是項目組未將組織機構的修改作為一個變更單獨提出，測試組也不知道有這個潛在變更的存在。系統測試通過后如期部署上線，但是上線后發生審批流程節點出錯的問題。假如項目組將這個組織機構信息作為配置項納入配置庫，它的變更也經過變更管理，那么怎么可能發生這種情況呢？
6. 上線的源碼版本組合為未經測試的版本組合
在項目已定義的發布流程中，可能因為一些看似合理的步驟，導致系統部署到生產環境后出現系統運行失效的情況。
在圖一中，假設F1和文件F2在修改之前的版本都是1，在實現了需求1和缺陷1后，版本均變為版本2，表示為F1（v2），F2（v2）。在測試環境測試時，測試的源碼版本均為F1和F2的版本2，但是需求1沒有通過測試，最后只部署了缺陷1這個活動對應的源碼到生產環境。那么部署到生產系統的版本將是F1（v1）和F2（v2）。F1（v1）是原來生產系統的版本，F2（v2）是包含了缺陷1所對應的版本。但是，和F1（v1）匹配的版本組合應該是F2（v1），和F2（v2）匹配的版本組合應是F1（v2）。這時上線帶來的結果是在生產系統上運行的是未經測試的版本組合。這潛在的質量陷阱可能導致發布時系統運行失效的情況。
圖一 未經測試的版本組合示意圖
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. 選取合適的配置管理工具
為了能讓開發人員不用手工記錄和追蹤缺陷修改的源碼，我們引入IBM Rational ClearCase。通過使用ClearCase的UCM模式，我們實現了一個可以立即用于軟件開發項目的一致并基于活動的變更管理流程。UCM（統一變更管理）是IBM Rational提出的用于管理軟件開發過程（包括從需求到版本發布）中所有變更的“最佳實踐”流程。UCM通過抽象層次的提升簡化了軟件開發，從而使得軟件開發團隊從更高的層次根據活動（activity）來管理變更。通過UCM，一個開發活動可以自動地同其變更集（封裝了所有用于實現該活動的項目工件）相關聯，這樣避免了項目成員手動跟蹤所有文件變更（見圖三）。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
