第9章 黎明之前最后的沖刺：成品測試
項目結尾時是小艾最能感受到成就感時，總結一段時間以來的項目經驗，總會有很多收獲。小艾非常享受這種學習與收獲的過程。但是，明明測試和開發已經完成了，距離計劃發布日還有一段時間，這段時間要做什么呢？
9.1 產品包裝成金蛋，手握光碟抓蟲子
這兩天小艾明顯感覺到項目團隊的氣氛緊張。項目經理凱文和各團隊主要負責人每天都神色凝重地在會議室激烈地討論著什么。這又勾起了小艾的好奇心。
9.1.1 成品測試全體總動員
他問身旁的凱文：“現在我們的各方面測試都基本完成了，不是應該松口氣慶祝了嗎？怎么領導們看著比以前還緊張，是出什么問題了嗎？”
凱文拍了一下小艾的肩膀答道：“知道什么是黎明前的黑暗嗎？這就馬上到最后的沖刺--GMV測試階段啦。”
小艾一頭霧水地問：“什么是GMV？”
凱文看小艾很迷惑，就放下手頭工作，給小艾認真講解起來。
凱文的話：
GMV是Golden Master Verification Test的簡稱，也就是我們通常說的成品測試或介質測試。它的測試目的是保證客戶拿到的成品沒有質量問題。從軟件發布的角度來說，就是保障客戶順利安裝并使用產品生產部門提供的光盤（CD或DVD）或網上下載的應用程序。
在GMV階段構建團隊會向測試團隊提供DVD ISO文件和DVD光盤作為驅動，測試團隊則使用這些介質來進行測試。GMV的另外一個測試目的是保證產品在前期缺陷修復過程中不會因為代碼改動而產生新問題。
因為GMV測試的重要性及其在進度上的緊迫性，GMV測試階段需要各個測試團隊在已有的測試案例里有針對性地選擇重要案例進行重新測試，以保證之前的代碼改動不會為最終成品帶來新的質量問題。切記不要在此階段運行新的測試案例，以保證GMV能在合理時間內完成（一般2～4周）并成功交付給客戶或投放市場。
小艾聽了凱文的簡單介紹，對GMV有了初步認識，但是對GMV具體計劃和測試策略要點仍舊不甚了解。到底GMV需要怎么進行？而我們應該在GMV中做些什么呢？
小艾星期四剛到公司就接到項目經理發的通知，要求下午2點項目全體人員參加重要會議。
會議準時開始，凱文站在會議室前方掃視了下面一張張熟悉的面孔說：“這個時間召開此次會議的目的，我想在座的老員工都能猜出來吧？”
“不錯，經過大約一年各團隊的努力，我們已經到了最后的沖刺階段。前兩天和各團隊負責人一起詳細討論了目前項目的進展情況。我很高興地宣布明天將構建第一個成品候選介質！”
隨后凱文站在放映機前，詳細匯報了各測試團隊到目前為止的測試結果。總體來講，除了性能測試還有一些少量收尾工作，其他測試類別像功能測試、安裝測試、產品遷移測試、多國語言測試等都已順利完成，測試用例都已100%完成，通過率都達到甚至超過質量計劃里所保證的百分比。失敗的測試案例目前都有了解決方案，并在現有測試驅動上通過了補丁測試，按照計劃，第二天下午4點前就能完成所有源代碼改動。
會議最后，凱文凝重地說：“接下來兩周的成品測試將是關鍵的一場戰役，就像足球場上的臨門一腳，關系著我們整個產品發布的成敗。希望大家鼓足干勁堅持到最后的勝利！”
9.1.2 協同作戰--成品測試特性
小艾聽完凱文的講話，對即將到來的成品測試充滿了期待。但他還不是很清楚自己具體應該做些什么。會議結束后凱文找到小艾給他分配測試案例。小艾看了一眼測試案例，不解地問：“以往我們功能測試都是在已裝好產品的機器上直接進行測試，這次為什么讓我們自己安裝產品呢？安裝測試不是應該安裝團隊負責嗎？”
凱文回答說：“你這個問題問得很好。由于成品測試的特性，成品測試有其獨特的測試策略。它要求各團隊協同作戰，才能在較短時間完成所有測試任務。”于是凱文給小艾詳細講述了成品測試的特點。
項目經理凱文的話：
成品測試的一個主要目的是測試最終介質和包裝有無缺陷，以保障客戶拿到最終產品時能順利安裝并使用我們提供的光盤（CD或DVD）或網上下載的應用程序。對于不同操作系統平臺或數據庫，調用的安裝程序和啟動的包裝有可能不同。這就要求在成品測試階段，盡可能涵蓋所有系統平臺和數據庫，以保障客戶在不同系統上的正常應用。
對于數目繁多的操作系統平臺（Window，AIX，Solaris，xLinux，pLinux，zLinux，iLinux等）和數據庫類型（DB2，Oracle，Cloudscape等），安裝團隊是不可能在短時間內涵蓋所有的，這就要求各團隊協同合作。一般來講，功能測試團隊、構建團隊、產品遷移測試團隊和多國語言測試團隊會用DVD或DVD ISO文件在較常見的操作系統平臺上簡單安裝產品，并進一步進行功能或多國語言測試。安裝團隊會在此階段著重測試一些復雜的安裝路徑和操作系統平臺。
小艾聽完凱文的解釋，明白了成品測試階段各團隊協同作戰的必要性。脫口而出道：“是不是人人都要手握光碟來抓蟲子啊？”
凱文笑道：“比喻很形象，但我們除了傳統物流方式銷售給客戶CD或DVD光碟，還允許客戶通過網絡下載我們的應用程序。一般會把DVD ISO文件經過壓縮放到網絡上供客戶直接下載。所以除了測試真正的物理光碟，我們還要測試放到網上的可供客戶下載的DVD ISO文件，即常說的電子版光碟。”
小艾點頭說：“哦，我明白了。凱文，成品測試階段測試范圍是如何規定的？還有，它的測試策略又都有哪些呢？”
凱文說：“我很高興看到你對成品測試的求知欲，我現在還要去構建團隊安排一下工作。這樣吧，我把各測試團隊成品測試的計劃發給你，那里面詳細描述了各測試團隊的測試范圍和策略。你仔細看一下，有什么問題可以問我。”
9.1.3 取舍之間--測試范圍和策略
小艾系統地閱讀了凱文發給他的成品測試計劃，并且根據各團隊計劃對成品測試階段的測試范圍和策略做了總體歸納總結。
成品測試范圍及策略歸納總結：
成品測試的測試案例必須是以前測試階段測試過的案例，不應該有新測試案例或對新系統平臺設置的測試。
所被挑選的回歸測試案例要盡量能夠涵蓋程序的主要功能，以確保程序的主框架沒有由于前期代碼改動而產生缺陷。
對于前期測試中發現較多問題并改動代碼較多的功能部分，應多挑選一些回歸測試案例進行回歸測試。
性能測試一般選擇最被廣泛使用或者大型客戶常用的平臺。測試用例選擇最簡單的分支，但是盡量擴大分支覆蓋的范圍，一般選用可靠性測試（關于可靠性
測試的定義見6.2.4節），測試時間一般在24～72小時。
所有測試都應基于DVD或DVD ISO文件安裝的應用程序，嚴禁再用構建測試環境來安裝應用程序并進行測試。
安裝應盡量涵蓋應用程序支持的所有系統平臺（Window，AIX，Solaris，xLinux，pLinux，zLinux，iLinux等），數據庫類型（DB2，Oracle，Cloudscape等）和安 裝模式（快捷安裝，定制安裝等）。
由于時間限制，成品測試案例大約占前期測試階段所有測試案例的5%～10%。
除了各測試團隊詳細的測試計劃，在凱文所提供的材料中，還有一份在測試中要求各測試團隊統一檢查的清單列表。清單列表里主要需要檢查下列內容。
a、DVD布局
應按照產品構建團隊提供的DVD布局文件里所列信息核對所測DVD光碟或電子光碟，布局一般包括：
不同系統平臺的安裝設置文件：setup.exe，setup_aix等。
不同支持語言的說明文件（readme）。
自動調用文件（AutoRun）：autorun.exe，autorun.inf等。
產品版本文件等一些和產品有關的文件。
除了核對布局里應存在的文件名外，還應該核對文件大小以保證文件沒有損壞和缺失。整體DVD內容大小也是需要核對的一個數據。
b、產品安裝
根據安裝說明書和安裝測試模式要求進行產品安裝。
c、產品許可同意書
在安裝過程中，檢查產品許可同意書是否正確顯示，并閱讀上面所列內容是否正確。最重要的是要檢查產品許可同意書里產品名稱和版本號是否正確。
d、產品主要頁面
安裝成功后，根據測試的不同產品特性，瀏覽一下主要網頁是否能夠正確顯示。
e、產品數據核心文件
產品中有些是產品信息核心文件，文件中的數據會被多個子程序引用。例如Product.xml中產品名稱及版本號等。應檢查這些文件是否安裝在正確文件夾里，并打開文件，根據產品情況檢查文件里面所列的信息是否正確。
f、產品構建號碼
最終提供給客戶的產品中一定要有產品構建號碼并存儲在一個產品文件中，以方便以后查詢。這個產品構建號碼一般以構建日期來命名。安裝成功后，需要打開文件檢查產品構建號碼是否正確，以確定所測試的驅動版本是正確的。
g、數據庫核心數據
一般產品都會有些核心數據存儲在數據庫里。可以根據情況列一些數據庫查詢語句在清單列表里，并要求各團隊進行查詢，以確保核心數據在安裝過程中被正確引入到數據庫中。
h、產品文檔文件
對于每個產品來講都會有文檔文件，其中包括產品使用說明，產品問題幫助等。安裝成功后，應檢查一下這些文件是否被安裝在正確文件夾里以確保能夠被程序正確調用。
i、產品卸載
所有測試都結束后，應按照產品卸載說明書卸載產品。
9.1.4 爭分奪秒--成品測試周期
GMV測試開始當天小艾很早便來到公司，看到各團隊負責人都已在辦公室里。凱文遞給他一張DVD光碟，說：“這是構建團隊周末燒刻的產品光碟，里面是上星期五的驅動。你今天的任務就是用DVD安裝產品并完成上星期四分配給你的相應功能測試案例。所有測試必須在第二天下午4點之前完成，有什么問題嗎？”
小艾問道：“如果沒有發現任何新缺陷，明天上午就應能完成所有案例測試。如果真是這樣，我是否就再也不用在新驅動上測試了？”
凱文說：“這需要視情況而定。就像我以前講的，成品測試是各團隊協同作戰。一個團隊的完成并不代表整體的完成。成品測試一般需要1～2周時間，對于每個驅動，大約需要2天完成。根據以往成品測試經驗，大約需要構建3～5個驅動才能最終完成。對不同的驅動，由于周期短，時間有限，每個測試團隊根據情況有自己的測試策略。并不是每個驅動都要重新測試所有案例。”
小艾稍后收到凱文的郵件，上面是各測試團隊對不同成品測試候選驅動的測試安排。
功能測試：
在第一個成品測試候選驅動上2天內完成所有被選定的成品功能測試案例。
在接下來的成品測試候選驅動上，只運行功能測試可接受性案例和由于修正程序缺陷而可能受到影響的測試案例。
在最終項目組宣布的成品候選驅動上，重新運行所有被選定的成品功能測試案例。
安裝測試：
在所有成品測試候選驅動上2天內完成所有被選定的成品安裝測試案例（集群環境安裝測試案例除外）。
在第一個成品測試候選驅動上，3天內完成集群環境安裝測試案例。在以后的成品測試候選驅動上如果沒有和集群環境相關的代碼改動，就無須重新運行集群環境安裝測試案例。
構建測試：
在第一個成品測試候選驅動上2天內完成所有被選定的成品構建測試案例。
在接下來的成品測試候選驅動上，如果無Java代碼改動，則無須重新運行java API掃描。但需重新運行源代碼掃描案例、版權掃描案例及SAR掃描案例。
性能測試：
在第一個成品測試候選驅動上3天內完成所有被選定的成品性能測試案例。
在接下來的成品測試候選驅動上，如果無性能相關的代碼改動，則無須重新運行性能測試案例。
在倒數第二個成品測試候選驅動上，重新運行所有被選定的成品性能測試案例。
遷移測試：
在第一個成品測試候選驅動上3天內完成所有被選定的成品遷移測試案例。
在接下來的成品測試候選驅動上，如果無遷移相關的代碼改動，則無須重新運行遷移測試案例。
多國語言測試：
在第一個成品測試候選驅動上2天內完成所有被選定的成品多國語言測試案例。
在接下來的成品測試候選驅動上，只運行多國語言測試接受案例和由于修正程序缺陷而可能受到影響的測試案例。
在最終項目組宣布的成品候選驅動上，重新運行所有被選定的成品多國語言測試案例。
定制測試：
在第一個成品測試候選驅動上2天內完成所有被選定的成品定制測試案例。
在接下來的成品測試候選驅動上，只運行由于修正程序缺陷而可能受到影響的測試案例。
在最終項目組宣布的成品候選驅動上，重新運行所有被選定的定制測試案例。
小艾看后撓撓頭說：“這么復雜啊，每個測試團隊對不同的成品測試候選驅動的安排都不太一樣，完成時間也不盡相同，怪不得你要作為總調度來統籌安排。”
凱文笑了笑說：“各個團隊對不同成品測試候選驅動的安排是基于測試類別的不同特性，其實解讀起來不外乎以下幾點。”
凱文對不同成品測試候選驅動測試策略的解讀：
各團隊必須完全測試第一個驅動，以后的驅動需要審時度勢，看編碼改動情況來決定測試范圍。
由于每個驅動都需要重新構建打包，因此每個驅動都需要進行必要的安裝測試和構建測試，以保障沒有重要文件的缺失。
項目組決定的最終成品候選驅動，將會是客戶最終拿到的產品。各測試團隊盡可能在此驅動上重新完成重要測試案例，以防功虧一簣。
遷移測試和個別安裝測試（例如集群安裝）案例測試周期長，極少受由于其他類別測試缺陷而修改代碼的影響。因此在整個成品測試周期一般只需要測試一遍。
由于大部分測試都會在兩天內完成，為了有效縮短整個成品測試周期，第二個成品測試候選驅動會在兩天后開始構建，而不必等待遷移測試和個別安裝測試（如集群安裝）案例測試結束。
小艾聽了凱文的解讀，覺得很有收獲，深刻認識到成品測試周期的緊迫性，感覺各團隊都是在爭分奪秒來完成最后沖刺。于是他匆匆和凱文告辭，拿著DVD趕快到實驗室開始執行分配給他的成品測試案例。
（未完待續）
相關鏈接：
一個軟件測試工程師的成長日記（連載一）
一個軟件測試工程師的成長日記（連載二）
一個軟件測試工程師的成長日記（連載三）
一個軟件測試工程師的成長日記（連載四）