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