軟件測試配置管理 軟件測試
一、軟件測試配置管理
一般應用過程方法和系統方法來建立軟件測試管理體系，也就是把測試管理作為一個系統，對組成這個系統的各個過程加以識別和管理，以實現設定的系統目標。同時要使這些過程協同作用、互相促進，從而使它們的總體作用大于各過程作用之和。其主要目標是在設定的條件限制下，盡可能發現和排除軟件缺陷。測試配置管理是軟件配置管理的子集，作用于測試的各個階段。其管理對象包括測試計劃、測試方案（用例）、測試版本、測試工具及環境、測試結果等。
目標
1、控制和審計測試活動的變更；
2、在測試項目的里程碑建立相應的基線；
3、紀錄和跟蹤測試活動變更請求；
4、相應的軟件測試活動或產品(work products)被標識、控制、并是可用的
承諾執行
承諾1：每個測試項目的配制管理責任明確；
承諾2：配置管理貫穿項目的整個測試活動；
承諾3：配置管理應用于所有的測試配置項，包括支持工具；
承諾4：建立配置庫和基線庫(Baseline)；
承諾5：定期評審基線庫內容和測試配置項活動
需要納入配置管理的項
項目測試過程中會產生許許多多的工作成果，例如測試計劃文檔、測試用例以及自動化測試執行腳本和測試缺陷數據等，他們都應當被保存起來，以便查閱和修改。這些納入配置管理范疇的工作成果統稱為配置項（Configuration Item，CI），每個配置項的主要屬性有：名稱、標識符、文件狀態、版本、作者、日期等。
要進行管理的配制項包括：
測試合同信息：《軟件測試技術合同》、《軟件委托測試合同》和《保密合同》；
被測軟件資源如：《用戶手冊》、《規格說明》等；
測試文檔模板以及測試過程中產生的系列文檔和測試數據：
軟件配置項任務：
指明配置項的功能特性和物理特性，編制文 檔，并建立配置項的標識體制；
控制對這些特性的更改；
記錄、報告更改處理以及執行狀態；
對配置進行檢查和評審等。
a. 在制定每一基線時，把基線要求受控的軟件實體標識為軟件配置管理項，并為每個軟件配置管理項賦予唯一的標識符；
b. 要確定全部文檔的格式、內容和控制機構，以便在配置管理各層次中追溯；
c. 用一種編號法提供軟件配置管理項的信息，以便對全部產品文檔和介質指定合適的標識號；
d. 標識方式要有利于軟件配置管理項的狀態控制，便于增、刪和更改；
測試過程角色和活動：
測試描述性表示：（測試過程中的文檔和資料）軟件測試的計算機表示（測試代碼/數據/結果）
軟件測試需求；
軟件測試角色：測試需求分析
輸入： 1）軟件測試的方法與規范
2）軟件需求規格說明、
3）軟件設計說明（概要設計說明和詳細設計說明）
4）《軟件用戶手冊》
輸出：軟件測試計劃：
軟件測試過程設計
軟件測試角色：測試過程設計
輸入：1）測試方法和規范；
2）軟件測試計劃； 輸出： 軟件測試說明包括： a、軟件測試步驟； b、軟件測試基準； c、軟件測試用例。
軟件測試實施
軟件測試角色：軟件測試實施；
輸入： 1）測試方法和規范； 2）軟件測試計劃；
3）軟件測試用例；
輸出： 1）測試運行結果表示；
2）測試自動化腳本/測試數據；
3）測試日志； [Page]
4）軟件問題報告
軟件測試評估
測試角色：軟件測試評估
輸入：1）《軟件用戶手冊》
2）軟件測試文檔
3）軟件測試配置
4）軟件測試記錄
輸出：軟件測試報告：1) 測試結果的統計信息；
2) 測試結果的分析/評價
二、配置管理變更的關鍵路徑的方法
配置管理來源于硬件系統。例如PC行業中，每一臺PC由主機和顯示器等構成，而主機又由CPU、主板等構成，對這些構件配置情況進行管理，就是硬件的配置管理。在軟件行業，計算機軟件由編譯后的代碼和相關的一系列文檔組成。但構成軟件的部件的變化是跟隨軟件產品的開發周期而不斷變化的。就頻率和程度來說，軟件的變化遠遠大于硬件。因此，軟件配置管理是一套管理軟件開發和軟件維護的方法和規則，其最終體現的是維護軟件產品的一致性和完整性。
變更常有
筆者所在銀行科技部已經建立了比較完善的項目管理體系和質量保障體系，但要應對分行或支行需求變更和相關軟件版本配置管理的問題，如果沒有一整套的解決措施和工具的支持，就會出現以下問題：
1)分行反映的缺陷更改不能快速響應，不能快速分配缺陷到指定的開發人員，只能依靠口頭或文檔的傳輸，缺乏一個整合開發商服務人員、產品經理(或項目經理)、開發團隊領導、開發人員、分行領導的信息傳遞和交流的平臺。
2)分行的需求變更不能快速響應。分行的需求變更和軟件版本配置只能依靠手工備份，因而，自身不能快速有效地管理各系統的版本，缺乏版本基線的管理策略。
針對以上問題，可以考慮采用軟件配置管理這一關鍵域的思路系統地解決以上問題。配置管理是整個集成軟件項目正常運作的一個管理支撐平臺，其目的就是將有關該項目的客戶、客戶服務人員、產品經理(或項目經理)、開發團隊領導、開發人員、高層領導等項目干系人的工作協同起來，實現高效的溝通，及時地共享工作成果。
配置管理的基本功能包括配置標識、變更控制、配置狀態發布和配置審計。變更控制是配置管理的重要內容，其目的是為了在動態中保證配置項的完整性、一致性和可回溯性，保證配置項的變更過程規范、受控、有完整記錄，受影響的各方均能及時了解情況，并協調一致。
控制不可少
變更控制是通過創建產品基線，在產品的整個生存周期中控制它的發布和變更。配置控制指在配置項標識正式確定之后，對配置項特別是對已提交的代碼、相關文檔和數據等的變更進行系統地跟蹤和控制的過程，主要包括變更的提出、確定配置項的控制等級、變更的評價、變更的處置、實施經批準的變更、對變更進行驗證和結束變更。變更控制的目的是建立一套控制軟件修改的機制，保證生產符合質量標準的軟件和保證每個版本的軟件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以確定在變更控制過程中控制什么，如何控制，誰控制變更、何時接收變更、批準和檢驗。
配置項級別
1)已基線化的配置項是指已完成該配置項的審核和批準，并且成為創建或修改其他配置項的輸入。例如：一個設計文檔已審核、通過、簽發，并且成為編碼活動的基礎。
2)受管理和受控的配置項是指已提交審核，但還沒有批準通過的配置項。例如：一個正在進行審核的設計文檔。
3)受控的配置項指已置于版本控制，但項目組不能直接進行改動的配置項。例如：用戶提供的軟件、購買的工具、產品標準等等。
變更請求的狀態
軟件變更、軟件優化和軟件bug都是產生變更的原因。變更申請人(用戶或產品經理)提出變更時，首先要對受控的配置項的修改提出一個變更請求，說明對軟件變更的需求。這是因為變更控制過程是通過變更請求的流動來實現的，而且對軟件的任何請求都必須和相應的變更請求對應。
變更請求的狀態包括：
1)提交：變更請求提交給配置管理員；
2)拒絕：變更控制委員會拒絕變更請求；
3)接受：變更控制委員會接受變更請求；
4)掛起：變更請求被掛起，以后再作決定； [Page]
5)已驗證：更改已執行和驗證；
6)關閉：驗證并歸檔配置項，更新的配置項提交給用戶(例如：通過版本發布)。
變更請求的類型
1)增強型：變更請求要求對已批準的項目功能進行增強。
2)改進型：變更請求不會造成功能更改，但使配置項的維護更加有效率。
3)糾錯型：變更請求對錯誤進行修正(諸如bug)。
變更請求的優先級
在評價變更請求的優先級時，要對請求變更的配置項進行系統的分析，確定變更影響范圍和修改的程度，確定變更的級別，為確定是否有必要記錄變更提供參考依據。變更請求的優先級可分為三類：
1)高：嚴重地影響一些用戶或許多用戶。
2)中：對用戶造成不方便，或是可以采取相應的變通方法處理的主要問題。
3)低：小問題。
修改完后簽入（Check in）
對變更的處理，要按照變更控制規程，將變更請求及其相關附件提交軟件配置控制委員會審批。配置管理組根據審批意見處理變更請求。
只有配置管理員具有Check in權限。在進行Check in之前，確認下面的事項：
1)所有對配置項所做的修改被批準；
2)所有的更改都經過審核或驗證；
3)所對應的變更請求已經被保存起來；
4)所有相關的審核記錄被保存；
5)Check in時須注明Check in原因，如對應的變更請求。
從數據庫中簽出（Check out）
1)對于文檔，配置管理員在更改審批人同意后，從配置庫中Check out配置項，發給項目組成員修改。
2)Check out時須注明Check out原因，如將要修改的問題。
3) 配置管理員一定要在配置狀態發布中跟蹤被Check out出來的配置項。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
