項目管理綜合輔導之測試過程中的配置管理

申請免費試用、咨詢電話：400-8352-114

軟件測試需要進行充分的測試準備，需要科學的，規(guī)范的測試過程管理。有效的配置管理對跟蹤和提高測試質(zhì)量和效率起到十分重要的作用。測試過程中的配置管理工作不僅包括搭建滿足要求的測試環(huán)境，還包括獲取正確的測試、發(fā)布版本。但是在實際軟件測試工作中，配置管理并沒有得到相應的重視。
　　軟件測試的“泥潭”
　　可能有讀者會覺得奇怪，軟件測試就是發(fā)現(xiàn)軟件中隱藏的缺陷，和配置管理有啥關系呢。但是，不知道大家在實際工作中有沒有發(fā)現(xiàn)，我們在軟件測試工作中碰到的一些問題，實際上就是由于配置管理工作沒做好而產(chǎn)生的。
　　在軟件測試工作中，我們經(jīng)常碰到以下三個問題：
缺陷只能在測試環(huán)境出現(xiàn)，但是在開發(fā)環(huán)境中無法重現(xiàn)；
已經(jīng)修復的缺陷在測試時又重現(xiàn)；
發(fā)布程序在內(nèi)部確認測試中測試通過，但是發(fā)布時卻發(fā)生系統(tǒng)運行失效的情況。
　　產(chǎn)生原因
　　不考慮缺陷報告描述不清楚這種情況，究其原因，上述三個問題的產(chǎn)生主要有以下七點原因：
　　測試環(huán)境配置的復雜性
　　由于不同（版本）的操作系統(tǒng)、不同（版本）的數(shù)據(jù)庫，不同（版本）的網(wǎng)絡服務器、應用服務器，再加上不同的系統(tǒng)架構(gòu)等組合，使得要構(gòu)建的軟件測試環(huán)境多種多樣、不勝枚舉；而且現(xiàn)在隨著軟件運行環(huán)境的多樣性、配置各種相關參數(shù)的“浩大工程”和測試軟件的兼容性等方面的需要，使得構(gòu)建軟件測試環(huán)境的工作變得較為復雜和頻繁，而軟件測試環(huán)境的構(gòu)建是否合理、穩(wěn)定和具有代表性，將直接影響到測試結(jié)果的真實性、可靠性和正確性。在筆者曾經(jīng)做過的一個項目中，考試/大由于測試環(huán)境使用了和開發(fā)系統(tǒng)不同版本的 JDK（測試環(huán)境使用 JDK1.5，而開發(fā)環(huán)境為 JDK1.4），導致測試中出現(xiàn)了在開發(fā)環(huán)境不會出現(xiàn)的缺陷。
測試產(chǎn)品與開發(fā)產(chǎn)品之間的密切關系
　　在一個項目的軟件測試過程中，會有大量的“產(chǎn)品”產(chǎn)生，典型的如文檔（包括測試計劃、測試用例、測試報告、日常管理文檔等）、數(shù)據(jù)、腳本等。軟件測試的一個獨特的特征，就是他的產(chǎn)品都是基于開發(fā)產(chǎn)品（如源代碼、文檔、安裝文件等）產(chǎn)生和變化的。而開發(fā)產(chǎn)品都是以“信息”的形式存放在計算機中，因此，較硬件而言，開發(fā)產(chǎn)品比較容易被修改和變化。一旦開發(fā)產(chǎn)品發(fā)生改變，測試產(chǎn)品也需要相應發(fā)生改變。如何有效的管理測試產(chǎn)品，維護測試產(chǎn)品與開發(fā)產(chǎn)品之間的關系成為測試過程中的一個棘手的問題。
開發(fā)人員在處理新的開發(fā)任務時間接修復了缺陷
　　由于缺少工具的支撐，開發(fā)人員不能詳細的、準確的獲取提交測試的缺陷涉及修改的源碼，所以在有些項目組中，每次測試時，開發(fā)人員將個人開發(fā)的所有源碼提交給測試人員，由測試人員采用完全覆蓋的方式更新測試環(huán)境。但是由于開發(fā)人員的工作環(huán)境仍在進行新變更、新功能或缺陷的處理，而修改新變更、新功能或缺陷的同時，很容易將原來存在的缺陷一并修復。這就可能導致測試環(huán)境中存在的缺陷在開發(fā)環(huán)境中無法重現(xiàn)問題的發(fā)生。
　　開發(fā)人員漏提交待測試的源碼
　　假設項目組意識到完全覆蓋方式的不合理，要求開發(fā)人員只能提交修改缺陷或變更對應的源碼供測試。可是由于缺少工具的支撐，開發(fā)人員只能手工記錄、追蹤變更和缺陷對應修改的源碼，這種方式一是記錄和追蹤的工作量大，二是很容易漏提交源碼。由于開發(fā)人員漏提交源碼，就很容易發(fā)生測試環(huán)境的缺陷在開發(fā)環(huán)境無法重現(xiàn)或者已經(jīng)修復的缺陷又重現(xiàn)的情況。
公共參數(shù) / 基礎數(shù)據(jù) / 配置文件未進行配置管理
　　一些項目組未將公共參數(shù) / 基礎數(shù)據(jù) / 配置文件等全局文件納入配置管理。由于沒有將其納入配置管理，考試/大所以這部分全局文件的變更也同樣的未進行變更管理。當這些全局文件發(fā)生變更時，很容易出現(xiàn)測試環(huán)境、開發(fā)環(huán)境，甚至包括生產(chǎn)環(huán)境配置不一致的情況。一旦出現(xiàn)這種情況，那么即使發(fā)布程序在內(nèi)部確認測試時測試通過，但是部署到生產(chǎn)環(huán)境后系統(tǒng)運行失效的情況就在所難免。這實際上是因配置項缺失而帶來的問題。
　　很多人可能不認為公共參數(shù)或者基礎數(shù)據(jù)應該作為配置項納入配置管理，實際上這種想法是錯誤的。假設沒有將這些公共參數(shù)等信息納入配置管理，那么試想一下，假設有一天系統(tǒng)意外崩潰，我們拿什么去恢復生產(chǎn)環(huán)境？所以說，系統(tǒng)運行支撐的所有內(nèi)容（包括基礎數(shù)據(jù)、配置文件等）都需要納入配置庫進行配置管理。
　　曾經(jīng)有這樣一個案例：某審批系統(tǒng)的公司組織機構(gòu)信息是通過數(shù)據(jù)庫進行維護的。項目組在處理某個需求變更時，需要相應修改公司組織機構(gòu)信息，但是項目組未將組織機構(gòu)的修改作為一個變更單獨提出，測試組也不知道有這個潛在變更的存在。系統(tǒng)測試通過后如期部署上線，但是上線后發(fā)生審批流程節(jié)點出錯的問題。假如項目組將這個組織機構(gòu)信息作為配置項納入配置庫，它的變更也經(jīng)過變更管理，那么怎么可能發(fā)生這種情況呢？
上線的源碼版本組合為未經(jīng)測試的版本組合
　　在項目已定義的發(fā)布流程中，可能因為一些看似合理的步驟，導致系統(tǒng)部署到生產(chǎn)環(huán)境后出現(xiàn)系統(tǒng)運行失效的情況。
　　在圖一中，假設 F1 和文件 F2 在修改之前的版本都是 1，在實現(xiàn)了需求 1 和缺陷 1 后，版本均變?yōu)榘姹?nbsp;2，表示為 F1（v2），F(xiàn)2（v2）。在測試環(huán)境測試時，測試的源碼版本均為 F1 和 F2 的版本 2，但是需求 1 沒有通過測試，最后只部署了缺陷 1 這個活動對應的源碼到生產(chǎn)環(huán)境。那么部署到生產(chǎn)系統(tǒng)的版本將是 F1（v1）和 F2（v2）。F1（v1）是原來生產(chǎn)系統(tǒng)的版本，F(xiàn)2（v2）是包含了缺陷 1 所對應的版本。但是，和 F1（v1）匹配的版本組合應該是 F2（v1），和 F2（v2）匹配的版本組合應是 F1（v2）。這時上線帶來的結(jié)果是在生產(chǎn)系統(tǒng)上運行的是未經(jīng)測試的版本組合。這潛在的質(zhì)量陷阱可能導致發(fā)布時系統(tǒng)運行失效的情況。
上線的源碼版本為未經(jīng)測試的版本
　　除了上線的源碼版本組合是未經(jīng)測試的版本組合這種質(zhì)量陷阱外，在發(fā)布流程中，還可能存在另一種質(zhì)量陷阱。
　　在圖二中，假設文件 F1 和文件 F2 在修改之前的版本都是 1，在實現(xiàn)了需求 1 后 F1 的版本變成了 2，F(xiàn)2 的版本為 3。開發(fā)任務 1 在需求 1 修改的基礎上進行了開發(fā)，生成 F2（v4）。在測試環(huán)境測試的源碼版本為 F1（v2）和 F2（v4）。但是開發(fā)任務 1 沒有通過測試，最后部署到生產(chǎn)系統(tǒng)的版本將是 F1（v2）和 F2（v3），F(xiàn)1（v2）和 F2（v3）是包含了需求 1 所對應的版本。但是，F(xiàn)2（v3）是未經(jīng)過測試的版本，這潛在的質(zhì)量陷阱也可能導致發(fā)布時系統(tǒng)運行失效的情況。
　　解決方案
　　為了避免上述的問題的產(chǎn)生，筆者從以下七點出發(fā)給出測試過程中配置管理問題的解決方案。
　　選取合適的配置管理工具
　　整理配置項，明確相應管理流程
　　將配置項作為一個整體進行配置管理
　　增加發(fā)布前驗收測試環(huán)節(jié)
　　采用并行開發(fā)方式區(qū)分不同的開發(fā)活動
　　定制文件開發(fā)方式
　　明確角色與職責
　　選取合適的配置管理工具
　　為了能讓開發(fā)人員不用手工記錄和追蹤缺陷修改的源碼，我們引入 IBM Rational ClearCase?？荚?大通過使用 ClearCase 的 UCM 模式，我們實現(xiàn)了一個可以立即用于軟件開發(fā)項目的一致并基于活動的變更管理流程。UCM（統(tǒng)一變更管理）是 IBM Rational 提出的用于管理軟件開發(fā)過程（包括從需求到版本發(fā)布）中所有變更的“最佳實踐”流程。UCM 通過抽象層次的提升簡化了軟件開發(fā)，從而使得軟件開發(fā)團隊從更高的層次根據(jù)活動（activity）來管理變更。通過 UCM，一個開發(fā)活動可以自動地同其變更集（封裝了所有用于實現(xiàn)該活動的項目工件）相關聯(lián)，這樣避免了項目成員手動跟蹤所有文件變更。
　　ClearCase 管理員利用 ClearCase 提供的命令進行二次開發(fā)，可實現(xiàn)獲取某個指定活動或一批活動變更集包含的源碼集合，這為開發(fā)人員提交開發(fā)活動變更集包含的源碼集合，測試人員 / 配置管理員增量更新測試環(huán)境、生產(chǎn)環(huán)境提供了方便。
　　整理配置項，明確相應管理流程
　　為了避免因配置項缺失導致開發(fā)環(huán)境、測試環(huán)境和生產(chǎn)環(huán)境的不一致，我們需要對系統(tǒng)中所有的配置項（如公共參數(shù) / 基礎數(shù)據(jù) / 配置信息等）進行整理，明確各種類型配置項的存放方式、控制流程。例如：某項目的 SQL 建表文件、UNIX 操作系統(tǒng)的配置參數(shù)文件屬于系統(tǒng)的全局文件，其存放方式為文本文件。根據(jù)項目測試與配置管理要求，項目相關負責人針對全局文件定義了相應的控制流程。
　　同樣的，對于源碼這類文件，我們也需要規(guī)范相應的管理流程。通過使用 ClearCase UCM 方式，開發(fā)人員在修改源碼時，可以使用 ClearCase 的“處理活動”功能，快速切換當前處理的活動，使他們可以選擇正確的活動進行源碼修改。采用 UCM 方式的好處之一，就是項目成員對于配置庫的修改必須有活動關聯(lián)，如果沒有分配給操作用戶的活動，用戶就無法對配置庫進行任何修改。這對于正在運行的系統(tǒng)而言，源碼的修改獲得批準是非常重要的。
　　將配置項作為一個整理進行配置管理
　　配置管理工作是整個軟件開發(fā)過程的生命線，對于測試人員來講，由于測試產(chǎn)品與開發(fā)產(chǎn)品之間的密切關系（參見“產(chǎn)生原因”一節(jié)），測試人員必須得到自己關心的程序的任意一個測試版本，以便可以在正確的版本上執(zhí)行正確的測試用例。
　　由于上述原因，我們需要將配置項作為一個整體進行配置管理，方便進行測試版本的回溯。我們可以通過 ClearCase 的基線來實現(xiàn)這個功能。UCM 將項目活動嵌入到各個基線中，這樣測試人員可以確切地知道他們將測試什么，而開發(fā)人員則確切地知道其他開發(fā)人員做了什么。在其他一些配置管理工具中，基線只是一個文件版本的快照，并沒有將該快照關聯(lián)修改這些文件對應的活動。
　　增加發(fā)布前驗收測試環(huán)節(jié)
　　由于缺少獨立的發(fā)布前的確認測試環(huán)節(jié)，而將程序潛在的質(zhì)量陷阱（見圖一和圖二）遺留到在生產(chǎn)環(huán)境部署后才爆發(fā)。為了避免這種風險的發(fā)生，筆者建議在項目的配置管理流程中增加發(fā)布前驗收測試環(huán)節(jié)。所有上線的發(fā)布包，必須將上線包在發(fā)布前驗收測試環(huán)境中進行驗收測試。待驗收測試通過后，方可在生產(chǎn)環(huán)境部署（見圖六）。
　　采用并行開發(fā)方式區(qū)分不同的開發(fā)活動
　　在項目實際開發(fā)中，開發(fā)人員會面臨不同類型的開發(fā)活動，如變更、缺陷、新增特性等。而不同類型的開發(fā)活動，它的緊急程度不一樣，如果將這些開發(fā)活動混在一起工作，那么可能因為版本間的依賴影響項目的上線進度。另外，這種工作方式也會影響項目測試工作的開展。由于上線計劃可能只包含部分開發(fā)活動，導致測試環(huán)境有不同上線階段的開發(fā)活動需要測試，這種方式無形中增加了運行在生產(chǎn)環(huán)境的源碼組合為未經(jīng)測試的版本組合（見圖一）和未測試的版本（見圖二）的幾率。
　　針對這種情況，筆者建議將不同類型的開發(fā)活動按照緊急性或類型將工作區(qū)分開來，這就涉及多個版本的并行開發(fā)，如項目 V1.0 的缺陷修復、V1.0 的新增功能版本 V1.1、新版本 V2.0。IBM Rational ClearCase 可以很好的支持這種并行開發(fā)模式。在 ClearCase 中，我們可以在項目 V1.0 的發(fā)布基線（V1.0_rel01_20071101）的基礎上分別創(chuàng)建針對三種版本（V1.0_bugfix、V1.1、V2.0）的開發(fā)項目（見圖七）。在 ClearCase 管理下，這三種版本位于不同的分支下，他們的開發(fā)是獨立的，互不影響，并且版本 V1.0_bugfix 中的缺陷修復可以及時的合并到版本 V1.1 和 V2.0 中，版本 V1.1 的新增功能也可以在需要的時候合并到版本 V2.0 中。
　　定制文件開發(fā)方式
　　在項目實際開發(fā)中，通常需要對文件進行并行開發(fā)，因此存在因為多人同時修改同一個文件而需要對文件進行合并的情況。對于大部分格式的源碼，配置管理工具都提供不同程度的自動合并功能。但是對于不能合并的二進制文件或不允許合并的文本文件（例如通過第三方開發(fā)工具導出的文本文件，ClearQuest 模式文件等），就不適合使用并行開發(fā)方式。因為這些文件或者不能合并，或者是不能通過簡單的合并來實現(xiàn)版本的合并。對于這類文件如果處理不當，就會導致測試時使用了錯誤內(nèi)容的版本，導致測試不通過。
　　但是，在項目實際開發(fā)中又不能因為存在這類特定類型的文件，而限制使用并行開發(fā)方式。串行開發(fā)與并行開發(fā)是矛盾的，如何解決這個問題是存在這類文件的項目在開發(fā)和測試過程中很頭痛的一個問題。IBM Rational ClearCase 可以很好的解決這個問題。我們可以利用 ClearCase 提供的強大的二次開發(fā)功能，為這些不能進行合并的二進制文件或不允許合并的文件創(chuàng)建特定的文件類型。在執(zhí)行檢出操作時，判斷該文件是否屬于已定義的特定類型文件。如果是，則判斷該文件是否已經(jīng)被檢出。如果已經(jīng)被檢出則不允許執(zhí)行檢出操作。通過這種方式，我們既可以保證大部分的源碼可以進行并行開發(fā)，又能解決這類特定類型文件的串行開發(fā)問題。
　　明確角色與職責
　　在整個測試過程與配置管理過程中，要非常清晰項目的角色劃分，及角色對應的職責，并要求相關角色人員嚴格履行各自的職責。某個大型已上線系統(tǒng)在進行升級時就有過一次因角色與職責混淆的教訓。在這次升級上線手冊中有“檢查四個參數(shù) A、B、C、D”這么一個步驟，測試人員在測試時發(fā)現(xiàn)測試環(huán)境因沒有這四個參數(shù)而導致了測試失敗，于是測試人員聯(lián)系開發(fā)人員，得知創(chuàng)建這四個參數(shù)的方法，以及需要設置的參數(shù)值。然后測試人員在測試環(huán)境自行創(chuàng)建了這四個參數(shù)。由于正確設置了這四個參數(shù)后，此次升級測試通過。當該升級包提交運維組部署到生產(chǎn)環(huán)境時，運維組按照上線手冊要求檢查了生產(chǎn)環(huán)境，發(fā)現(xiàn)生產(chǎn)環(huán)境有這四個參數(shù)（但不是開發(fā)人員期望設置的值），并且有測試組提供的測試報告，于是他們將升級包按照上線手冊步驟部署到生產(chǎn)環(huán)境。但是上線后由于這四個參數(shù)設置了錯誤的值，導致系統(tǒng)停產(chǎn) 40 多分鐘。
　　在這個事故中，開發(fā)人員與開發(fā)人員都有責任。測試人員未按照上線手冊要求完成他的工作（只是“檢查”，而不是“創(chuàng)建”），這本身就是一個違規(guī)操作。另外，他沒有將實際情況與上線手冊的不一致向開發(fā)組提出并由開發(fā)組更新上線手冊，在開發(fā)組提交更新后的上線手冊后，測試組重新檢查測試環(huán)境并測試。開發(fā)人員則未在上線手冊寫明參數(shù)具體設置的值，上線手冊存在不明確信息。
　　所以在項目的各個過程，包括軟件測試過程和配置管理過程中，一定需要明確各角色相應的職責及工作范圍，避免類似事故的發(fā)生。
　　配置管理貫穿于項目所有過程中，本文主要從軟件測試的角度分析了測試中經(jīng)常碰到的問題，闡述了軟件測試和配置管理之間的密切關系。為了解決測試中存在的配置管理問題，筆者針對測試過程常見問題產(chǎn)生的原因，從配置管理角度給出了相應的解決方案。筆者希望通過本文，能夠改變軟件測試工作中不需要關注配置管理的錯誤思想。
項目管理師考試資料庫
點擊進入：考試大項目管理師考試在線模擬測試
考試大項目管理師考試網(wǎng)校課堂