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