從菜鳥到測試架構師(共22頁)

1、第2章萬事開頭難：軟件從安裝(nzhung)開始在凱文的指導下，小艾開始對于測試(csh)有了初步的了解，就這樣忐忑地開始了自己的測試生涯。“可是，測試(csh)要從哪里開始呢？”他坐在辦公室對凱文問出了這樣的問題。“測試要先熟悉自己的產(chǎn)品。這樣吧，我先安排你到安裝測試組工作，熟悉一下產(chǎn)品?！薄鞍惭b測試組？安裝也需要測試嗎？這不是很簡單的事情嗎？”小艾想起自己在讀書的時候，經(jīng)常給自己的計算機安裝系統(tǒng)和各種軟件，是一件很輕松的事情。于是不由得有些失望。 “以前你所使用的軟件都是經(jīng)過安裝測試后發(fā)布的，所以你可以簡單順利地完成安裝過程，但是事實上安裝測試并不像你想象得那么簡單，試一下你就知道了。而且

2、，你平時用的都是個人桌面計算機上的簡單應用，而對于大型商用軟件來說，它所需要支持的各種集成環(huán)境、集群配置等，都是很復雜的?！眲P文笑著說：“你去安裝測試組報到，安裝測試組的組長安巖會安排并幫助你熟悉工作，遇到任何問題都可以請教她?！?.1 軟件，是裝出來的“安裝測試組都需要做什么呢？”這是小艾問安巖的第一個問題。安巖給小艾的解釋是這樣的： 安裝可以很簡單，像一些簡單的桌面應用程序，只是簡單地復制一些文件，對于這種應用，不需要專門的安裝測試組，安裝測試能夠和其他測試合并在一起。 安裝也可以很復雜，比如說企業(yè) 級Java EE應用軟件的安裝，一般來說，它要支持多個操作系統(tǒng)平臺、多種數(shù)據(jù)庫、多個版本的

3、中間件、多種網(wǎng)絡服務器（Web Server）、多種拓撲結構，等等，這就是要求測試人員具有較好的操作系統(tǒng)、數(shù)據(jù)庫及網(wǎng)絡服務器等知識。一般需要一個專門的安裝測試組來進行相關的測試。我們正在測試的就是一個企業(yè)級的Java EE應用軟件。 小艾接著問：“企業(yè)級Java EE應用軟件？能舉幾個例子嗎？” 安巖說：“沒問題，Java EE應用軟件是符合Java EE 技術規(guī)范開發(fā)的相關應用，一般需要部署Java EE應用服務器上才能對外提供服務。一般來說，企業(yè)級Java EE應用，都需要使用數(shù)據(jù)庫軟件。典型的拓撲結構是三層結構：前端是網(wǎng)絡服務器，中間是應用服務器，后端是數(shù)據(jù)庫服務器?！?“典型的企業(yè)(q

4、y)Java EE應用軟件，像IBM WebSphere Commerce 應用套件，提供一整套完整的電子商務解決方案。”2.1.1 安裝測試(csh)概念解讀小艾仍然略帶疑惑(yhu)地接著問“那什么是安裝測試呢？”安巖說道：“軟件產(chǎn)品多種多樣，很難就所有產(chǎn)品特性下一個安裝測試的定義。就一般的企業(yè)級Java EE 應用軟件來說，安裝測試應該做到以下幾點：”1/view/651442.htm 安裝測試-百度百科2010-05-17確保待測產(chǎn)品能夠在所有支持的操作系統(tǒng)、數(shù)據(jù)庫，應用服務器中間件、網(wǎng)絡服務器、拓撲結構等各種組合情況下，被正確地安裝和卸載。確保安裝文檔的正確性和易讀性。通俗來說，就是

5、確保安裝相關代碼和相關安裝配置文檔的正確性。”安巖繼續(xù)說：“了解了安裝測試的概念，我介紹一下我們如何規(guī)劃安裝測試的，就是安裝測試計劃。可以這么說，一個好測試計劃將成就一個軟件產(chǎn)品。一個壞的測試計劃將毀滅一個軟件產(chǎn)品?！薄懊恳粋€測試人員都需要認真仔細地閱讀安裝測試計劃，并且按照這個文檔的規(guī)定，來進行具體的測試，這是對每一個測試人員的最基本要求。測試計劃的主體部門詳細描述了安裝測試的測試配置和測試場景，這部門內容也最多，我們以后還會詳細講到?！毙“犃税矌r對安裝計劃的講解之后受益匪淺，又跟安巖要了安裝計劃相關的材料，暗下決心，一定先要把安裝測試計劃搞懂、搞透。2.12 測試之初體驗 一份手冊，N臺

6、機器，一堆軟件“紙上得來終覺淺，絕知此事要躬行”。第二天，安巖安排小艾開始進行基本的安裝測試，通過實踐來熟悉安裝測試。 安巖接著(ji zhe)詳細介紹了安裝測試的基本流程，小艾認真地做著筆記。學習(xux)測試計劃與測試用例正確的開始點非常(fichng)重要，學習測試計劃與測試用例是每個安裝測試人員開始的第一步，這個原則對其他測試類型同樣適用。在安裝測試計劃中，包含所有測試用例，一般要求每個測試人員對所有測試用例有一個基本的了解，對自己要測試的那部分，要有全面和細致的了解。 比如，對于一個三個節(jié)點的安裝測試用例，需要搭建一個典型的三節(jié)點的環(huán)境（網(wǎng)絡服務節(jié)點、應用服務器節(jié)點、數(shù)據(jù)庫節(jié)點）。測

7、試用例中規(guī)定了詳細的測試步驟和檢查點，這些需要認真閱讀和特別加以注意。搭建測試機器每個產(chǎn)品對其運行的軟件和硬件都有具體要求，測試用例會明確規(guī)定使用什么樣的硬件配置和操作系統(tǒng)版本，測試人員需要自己來搭建測試機器，并且必須保證與測試計劃的描述嚴格一致。 此外，安裝測試人員在此階段還有一個重要的工作，就是檢查安裝文檔中關于軟硬件配置描述的正確性。千萬不能鬧出“產(chǎn)品實際支持的是 windows 2008操作系統(tǒng)，文檔中卻說是支持Windows XP”這樣的錯誤。這可是非常嚴重的錯誤，這個錯誤可能會導致為客戶提供的方案信息不正確，直接影響客戶的預算和實施，甚至可能延誤上線時間。所以一定要認真對待。 一旦

8、得到一套干凈的測試環(huán)境之后，最好做做個備份，以供下次重復測試時直接恢復，從而節(jié)省部分測試時間。準備待測試軟件產(chǎn)品這一步需要把待測試軟件下載到測試機器上。一般來說，構建測試組（Build Team）會準備待測試軟件包，并且按照一定的頻率（比如每天或每周）發(fā)布到某個文件服務器上，需要確認你要使用哪天的構建，并下載到測試機器上。如果待測試軟件需要依賴某些基礎軟件（如應用服務器軟件、數(shù)據(jù)庫軟件等）來運行，你也需要在這個階段把它們一并準備好。按照安裝(nzhung)手冊中的步驟來執(zhí)行在實際執(zhí)行中，這個步驟是最容易(rngy)被忽視的一步。資深的測試人員可能對安裝測試非常熟悉了，就會常常不看安裝手冊而按照

9、自己的經(jīng)驗來安裝，這就導致安裝手冊有問題而未被發(fā)現(xiàn)糾正。導致的后果就是用戶按照安裝手冊來安裝時，根本安裝不下去，客戶的失望和憤怒可想而知。撰寫(zhun xi)測試報告，詳細記錄測試結果最后我們要寫測試報告，詳細記錄測試的流程和發(fā)現(xiàn)的問題及處理結果。測試組長會仔細閱讀每個測試人員的測試報告，掌握當前測試狀態(tài)和進度情況。小艾總結說：“看來安裝測試真的不簡單呀，有那么多步驟，要準備測試機器，安裝一堆的相關的軟件，最后還要檢查文檔?！卑矌r說道：“總結得不錯，一份手冊，N臺機器，一堆軟件，這是對安裝測試執(zhí)行很形象的總結。”2.2 全面撒網(wǎng)，重點排查一個月過去了，小艾順利完成了安巖交給的第一份任務，對安

10、裝測試流程已經(jīng)基本掌握清楚了。 然而，小艾一直有一個問題：“一個好的可執(zhí)行的測試計劃是確保測試質量的關鍵，那么測試計劃是怎么寫出來的呢？” 一天小艾困惑地問安巖：“在測試計劃中，為什么要選擇這些測試配置和測試場景呢？像我們這么復雜的產(chǎn)品又要支持這個，又要支持那個，要測試的內容好多呀，在時間和人力有限的條件下怎么保證既測得全面又測得完呢？”安巖笑著解釋：“好問題，這可是一門學問，是有規(guī)律可循的，聽我慢慢道來?！?.21 選擇測試配置前面曾經(jīng)介紹過安裝測試的概念，其重要的一部分是要確保待測產(chǎn)品在所有支持的操作系統(tǒng)，數(shù)據(jù)庫、應用服務器中間件、網(wǎng)絡服務器、拓撲結構等的各種組合情況下，能夠被正確地安裝和

11、卸載。撰寫測試(csh)計劃時，首先要清楚得列出產(chǎn)品所有能夠支持的測試配置。測試配置(pizh)指待測軟件所能支持的硬件環(huán)境、軟件環(huán)境和配置方法的組合。對于不同類型的待測軟件，可以從各個角度來找出測試(csh)配置，對于Java EE應用軟件來說，可以嘗試從下面角度來考慮。操作系統(tǒng)：Java EE 應用是跨平臺的應用，一般都能支持多種操作系統(tǒng)，例如 windows ,AIX ,Linux,Solaris 等。應用服務器：Java EE應用需要部署到應用服務器才能發(fā)揮作用，例如IBM wesphere Application Server ,簡稱 WAS。數(shù)據(jù)庫：Java EE應用一般都需要使用

12、數(shù)據(jù)庫來存取信息，例如DB2和Oracle兩種數(shù)據(jù)庫。網(wǎng)絡服務器（Web Server）：像我們前面說過的，Java EE應用一般都需要使用網(wǎng)絡服務器來提高性能和支持可擴展性。例如 Sunone，Internet Information Services (下面 簡稱IIS)，IBM HTTP SERVER（IHS）等。拓撲：Java EE 應用部署時一般都支持不同的拓撲結構來滿足不同的對性能和可擴展性的支持。例如單節(jié)點、三節(jié)點、集群三種拓撲。版本：為了適應不同客戶群的需求，Java EE應用軟件一般被包裝成不同的版本。例如企業(yè)版、專業(yè)版、精簡版三種。安裝類型：一般的Java EE 軟件都會支

13、持多種安裝類型以滿足不同的安裝需求，例如快速安裝、定制安裝兩種。對于上面所列的每一個角度的具體取值，每個產(chǎn)品不盡相同，可以從設計文檔中獲得具體的信息。對于上面多列的每一個角度，都可以看做一個變量。所有變量的乘法組合有幾十種甚至好幾百種，每一個組合就是一個測試配置。下面是一個例子： AIX/WAS/DB2/IHS/三節(jié)點/企業(yè)版/定制安裝我們能用一個乘法公式來計算測試配置的總數(shù)： 其中，V表示某個變量的種類，n 表示變量的個數(shù)，S表示可能組合的總數(shù)。在時間和人力有限的條件下，不可能每種組合都測試，就需要(xyo)根據(jù)一些限制條件來進一步縮小測試的范圍，比如以我們總結得最佳實踐。每種支持(zhch

14、)的操作系統(tǒng)版本至少需要測試一次 每個支持的操作系統(tǒng)版本都至少需要被測試一次，為什么有這個要求呢？因為在安裝文檔中，會敘述產(chǎn)品支持的操作系統(tǒng)版本，不測試哪一個，都會有比較(bjio)大的風險。這里要細化到操作系統(tǒng)版本，例如對于windows 操作系統(tǒng)，某產(chǎn)品支持Windows 2003和windows 2008，那么這兩個版本都需要測試到。每種支持的網(wǎng)絡服務器版本至少測試一次同理，安裝文檔中，會敘述產(chǎn)品支持的網(wǎng)絡服務器版本，所以需要確保在測試配置組合中，每種網(wǎng)絡服務器版本被測試至少一次。每種支持的數(shù)據(jù)庫版本至少測試一次同理，安裝文檔中，會敘述產(chǎn)品支持的數(shù)據(jù)庫，所以需要確保在測試配置組合中，每種

15、數(shù)據(jù)庫版本被測試至少一次。設計文檔中需要重點測試的配置必須測試 開發(fā)人員的一些代碼可能在某些測試配置下會有問題，開發(fā)人員如果有這種擔心，就會在設計文檔中特別指出，測試人員就要特別注意，這個配置很可能會有問題的。客戶典型配置必須測試在總結大多數(shù)客戶使用軟件產(chǎn)品的習慣后，我們發(fā)現(xiàn)一些典型的測試配置，大多數(shù)用戶都這么用。例如，選擇Windows的客戶一般選IIS作為網(wǎng)絡服務器（WebSever）。以往版本產(chǎn)品由客戶報告的問題分析(fnx)和由測試人員報告的缺陷分析如果測試的是一個新產(chǎn)品，可能這部分數(shù)據(jù)(shj)沒用。如果測試的是一個以前產(chǎn)品的升級版本，就能分析這部分的數(shù)據(jù)。 客戶報告的產(chǎn)品問題：是指

16、產(chǎn)品發(fā)布后，客戶發(fā)現(xiàn)的問題。這部分數(shù)據(jù)非常有價值。為什么客戶發(fā)現(xiàn)了這樣的問題，而測試人員卻沒有發(fā)現(xiàn)呢？從中能分析出測試計劃中可能(knng)存在的漏洞。以往版本的缺陷分析：這里的缺陷是由測試人員在產(chǎn)品發(fā)布前發(fā)現(xiàn)的，從中能分析出哪些部分特別容易出現(xiàn)問題，在新的版本中這些部分可能仍然會出問題。這樣，根據(jù)上面的原則選擇后，就能得到合適的測試配置覆蓋（Test Config Coverage）。為了直觀起見，我們也能畫一個矩形圖更形象的表達出測試配置覆蓋，如表2-1所示（畫“X”的組合表示被選中。限于排版的要求，只能列出Windows平臺下的所有組合，在實際應用中，可以補齊AIX，Linux平臺下的相

17、關組合）。 從表-2-1中能夠看出至少有一個測試配置被選中分別取測試每種數(shù)據(jù)庫：DB2和Oracle；至少有一個測試配置被選中分別去測試每種網(wǎng)絡服務器：SunONE、IHS和IIS；至少有一個測試配置被選中分別取測試每種發(fā)行版本：企業(yè)版本、專業(yè)版、精簡版；至少有一個測試配置被選中分別取測試典型的客戶配置，像Windows/IIS,等等。這樣選擇下來，一共選中了11個測試配置，而所有的測試配置有54個之多，可見在根據(jù)最佳實踐選擇后，測試工作量大大降低了，并且測試的質量仍然有保障，因為所有的測試點都有相應的測試覆蓋。2.2.2 找出測試(csh)場景有了測試(csh)配置后，接下來就需要找出測試場

18、景（Test Scenario）。測試場景就是一系列緊密關聯(lián)的操作步驟的組合。比如產(chǎn)品(chnpn)安裝流程、產(chǎn)品卸載流程等?？筛鶕?jù)以下信息來源來設計測試場景。需求說明書需求說明書是設計測試場景的主要依據(jù)，從中能夠找出最終用戶對產(chǎn)品安裝和卸載方面的各種需求。每個測試人員都需要認真閱讀，特別是測試設計的作者，需要對它非常的清楚。用戶手冊就是安裝文檔，最終用戶將按照用戶手冊來安裝產(chǎn)品，其中會陳述一些典型場景和注意事項，我們可以根據(jù)此來設計測試場景。從一個軟件從產(chǎn)品的生命周期來看，一個產(chǎn)品會經(jīng)歷安裝、升級、卸載的過程，所以能從中找出一些基本及典型的場景。在選定的測試配置上安裝產(chǎn)品這是一個最基本的測試

19、場景。從下面的描述中，能發(fā)現(xiàn)基本的步驟。確保在看安裝手冊的情況下，產(chǎn)品能夠被正確、輕松地安裝。如果安裝過程中遇到問題（例如磁盤滿、輸入信息錯誤等），安裝程序能夠清晰明確地指出問題的原因所在，并且在用戶糾正問題后安裝能夠繼續(xù)進行，產(chǎn)品安裝后，應用能夠正常啟動。卸載(xi zi)產(chǎn)品確?；井a(chǎn)品(chnpn)能夠被正確地卸載。這也是一個最基本的測試場景。在卸載(xi zi)后重新安裝產(chǎn)品確保產(chǎn)品卸載后能夠被正確重新安裝。有些客戶可能會用到此場景。文件權限檢查和敏感數(shù)據(jù)檢查確保產(chǎn)品安裝后，文件權限是正確的，沒有敏感數(shù)據(jù)暴露。這個場景是確保軟件產(chǎn)品安全性的典型的場景。殘障人員也能順利安裝產(chǎn)品比如確保為

20、盲人提供語音提示，為近視眼患者提供放大功能，等等。這是確保產(chǎn)品的可訪問性的典型的場景。上面列了一些最基本、最通用的測試場景。當然，針對特定的產(chǎn)品，可以從需求說明書和用戶手冊里找出更多特定的測試場景，這里就不一一敘述了。2.2.3組合出測試用例現(xiàn)在，我們就能寫出具體的測試用例了： 測試用例=測試配置+測試場景測試用例就是某個測試配置上來執(zhí)行某個測試場景。為了方便看出在哪個測試配置上執(zhí)行了哪些測試場景，可以畫出如表2-2所示（畫“”表示被選中）的矩陣表。 表2-2 測試用例測試場景1測試場景2測試場景3.測試場景N測試配置1測試配置2測試配置3.測試配置N我們(w men)分配任務一般是以測試用例

21、為單位來分配的，跟蹤項目狀態(tài)也是以測試用例為單位的。小艾聽了以上(yshng)分析，豁然開朗，疑惑全解開了，感慨說：“測試配置(pizh)、測試場景、測試用例是測試計劃的脊髓呀，看來下次我也能寫測試計劃了！”2.3 安裝測試質量之大觀 在一次討論中，小艾有了新問題：“對于每一個具體的安裝測試用例，怎樣才能保證測試質量是達到標準的呢？” 安巖說到“很簡單，需要制定一套通過標準，當測試用例滿足這套標準后，我們就可以認為測試達到了質量要求?！毙“又鴨枺骸岸加心男┩ㄟ^標準？能和我說說嘛？”安巖笑著說：“我們有過一個系統(tǒng)的總結，請聽我慢慢道來?！?.3.1產(chǎn)品安裝對于一般的Java EE 應用軟件，以

22、下是我們總結的產(chǎn)品安裝測試相關的通過標準。安裝程序能夠自動檢查安裝前提條件是否滿足對于軟件安裝來說，都或多或少地有一些前提條件，如果前提條件不滿足，安裝就不能繼續(xù)或者失敗。廈門列出最通用的一些前提條件：磁盤空間是否符合安裝需求網(wǎng)絡狀況是否符合安裝需求CPU和內存是否符合安裝需求操作用戶是否有足夠的權限操作系統(tǒng)是否符合安裝需求操作系統(tǒng)必須的補丁包是否安裝等一般需要針對每一項設計出一些異常情況，確保安裝程序能夠報告出相應的錯誤信息。比如最小的磁盤空間需求是2GB，如果指定一個僅有1GB自由空間的安裝目錄，應該報告磁盤空間不足。軟件安裝(nzhung)向導的用戶界面（User Interface）測

23、試這也是安裝測試重要的一方面，大多數(shù)程序(chngx)都會提供圖形化安裝方式嗎，所以我們需要重點測試這部門，一般我們需要驗證：用戶界面(yn h ji min)出現(xiàn)的描述性文字是清晰正確的用戶界面出現(xiàn)的輸入框嗎，選擇框功能正常，如果輸入異常信息，需要提示輸入錯誤。用戶界面出現(xiàn)的按鈕，像“像下一步”、“確定”、“取消”、等功能正常。安裝過程中如果有進度條顯示，需要確保進度信息顯示正確。軟件安裝各個選項的組合確保符合概要設計說明軟件安裝可能存在多個選項組合，例如，典型安裝，最小安裝，完全安裝等。要確保每個選項的安裝過程和安裝后的結果是符合設計文檔中的期望行為。軟件安裝過程是否可以取消，單擊“取消”

24、按鈕后，寫入的文件是否如設計文檔中期望的說明來處理如果安裝正式開始后不能取消安裝，“取消”，按鈕應該變灰。如果安裝正式開始后能夠取消安裝，用戶單擊“取消”按鈕后，安裝能夠正常停止，寫入的文件應該自動刪除，如果某些不能刪除，則給出相應提示說明。軟件安裝過程中意外情況的處理是否符合需求（如死機，重啟，斷電等）具體看設計文檔中如何處理意外情況。一般來說軟件安裝過程中如果有意外發(fā)生（如死機，重啟，斷電等）重啟后，安裝程序一般有如下兩種處理方式： 安裝程序偵測到程序意外停止，能夠恢復安裝進度，繼續(xù)安裝。 安裝程序偵測到程序意外終止，不能夠恢復安裝進度，回滾所有安裝操作，例如刪除已經(jīng)寫入的文件，刪除已經(jīng)寫

25、入的注冊信息。然后用戶能夠重新安裝。安裝過程是否是可以(ky)回溯的（即是否可以回上一步重新選擇）這個比較(bjio)好理解，是屬于安裝易用性的一種測試。一般的安裝程序都具有這種功能，所在在測試時，我們要確保功能是正確的。軟件(run jin)安裝過程中是否支持快捷鍵，快捷鍵的設置是否符合用戶要求這個是屬于安裝可用性方面的測試。在考慮用戶沒有鼠標設備的情況下，通過鍵盤也能完成整個安裝。軟件靜默安裝測試一些軟件除了支持圖形界面安裝方式外，還支持靜默（Silent）安裝，一般來說就是把安裝過程中必要用戶輸入信息寫到一個文本響應文件中，然后使用命令行來安裝。靜默安裝一般用于自動化安裝程序中。對于靜默

26、安裝測試，一般需要注意：正確的響應文件，靜默安裝能夠成功完成，并且在日志文件中記錄安裝成功相關的信息。錯誤的響應文件，靜默安裝失敗，并且在日志文件中表妹安裝失敗的原因。9.軟件安裝后安裝日志中沒有錯誤信息軟件安裝后，需要檢查安裝日志文件，確保沒有錯誤信息或者警告信息。軟件安裝后應用是否能夠正常運行 這也是一個重要的通過標準，即使軟件安裝過程沒有問題，但是安裝后應用不能正常運行，也表明安裝測試應用是失敗的。 為了保證這一點，一般我們(w men)在軟件安裝后，需要執(zhí)行一些基本的功能測試用例。安裝后的文件夾及文件是否寫到了指定的目錄里，文件的大小(dxio)權限是否正確我們用這一點來檢查安裝的完整

27、性和安全性是否符合預期。一般安裝后會使用一個掃描程序掃描安裝后的文件夾及文件，然后和通過(tnggu)標準進行比對，來確保這一點。安裝后一些重要文件的內容是否正確一些重要文件像版本信息文件，注冊文件等，需要確保它們的內容是符合設計文檔要求的。13.安裝后數(shù)據(jù)庫中的信息是否正確如果測試的軟件需要使用數(shù)據(jù)庫，需要檢查這一點。一般需要檢查：數(shù)據(jù)庫是否被正確創(chuàng)建；數(shù)據(jù)庫模式（像表、索引、出發(fā)器等）是否被正確創(chuàng)建；數(shù)據(jù)庫中的數(shù)據(jù)是否正確；檢查數(shù)據(jù)庫工作工作量一般比較大，需要使用工具來幫助檢查。上面列的各項屬于最佳實踐總結，針對不同的產(chǎn)品本身的特點，要靈活運用，有些產(chǎn)品可能需要增加一些測試，有些產(chǎn)品可能需

28、要減少一些測試?？傊鶕?jù)具體情況去應用。2.3.2產(chǎn)品卸載對于一般的Java EE應用軟件，以下是我們總結得與卸載測試相關的通過標準。測試軟件自帶的卸載程序一般來說，軟件都會有自帶卸載程序，需要確保它功能正常。測試使用操作系統(tǒng)自帶的添加/刪除工具（以windows為例）來卸載(xi zi)程序的情況在windows 操作系統(tǒng)中比較普通，需要確保它功能(gngnng)正常。測試卸載程序在程序運行/終止(zhngzh)等狀態(tài)時的卸載情況一般來說卸載之前需要使應用程序處于停止狀態(tài)，卸載程序能夠檢查程序狀態(tài)，并且給出正確提示。測試卸載軟件過程中，能否取消卸載進程如果支持取消操作，單擊取消后，觀察軟

29、件能否繼續(xù)正常使用。如果不支持取消，用戶應該不能單擊“取消”按鈕。5.測試卸載后文件是否全部刪除，包括安裝文件夾、注冊表、系統(tǒng)環(huán)境變量如果某些文件在卸載過程中沒有刪除，應該明確提示用戶。卸載過程中出現(xiàn)的意外情況的測試（如死機、斷電、重啟）具體要看設計文檔中如何處理這種異常情況，一般來說： 再次卸載時，能夠偵測前次卸載失敗，恢復卸載進度，繼續(xù)完成卸載。 再次卸載時，能夠偵測前次卸載失敗，但不能恢復卸載進度，需要用戶按照相關文檔手上卸載。軟件自帶卸載程序的UI測試一般來說，卸載程序的UI要逼安裝程序簡單，檢查方法類似于安裝UI測試。這里要強調一點，卸載測試和安裝測試同樣(tngyng)重要，都和用

30、戶體驗息息相關，測試有時候回輕視卸載測試，這一點要引起注意。2.4客戶(k h)的圣經(jīng)用戶手冊驗證(ynzhng)安巖在檢查小艾測試報告時，發(fā)現(xiàn)小艾犯了一般測試人員的通病不重視用戶手冊驗證，小艾負責的一個測試用例的相關文檔有不少明星的錯誤。 安巖找到小艾后，語重心長地對小艾說：“用戶手冊驗證是安裝測試重要的一部分，但往往被測試人員忽視。這一點需要引起特別注意?！薄坝脩舭惭b手冊對最終客戶非常重要，如果安裝手冊的某些信息是錯誤，將導致安裝失敗。如果某些信息時含糊不清的，將引起用戶理解歧義。這些問題將導致安裝工作暫停和項目進度延期，一方面將給客戶帶來不必要的經(jīng)濟損失，另一方面，用戶對這個軟件的質量產(chǎn)

31、生懷疑，這個軟件的口碑也會越來越差?！薄八圆徽撌琼椖拷?jīng)理或是相關的測試人員真的要從此刻開始注意用戶手冊驗證的重要性?！毙“朗亲约旱氖韬?，頻頻點頭道：“從今天起，我一定認真對待文檔驗證工作，能給我講講一般的驗證方法嗎？” 安巖緩和了一下語氣：“知錯能改，善莫大焉！請聽我下文分解?！?.4.1 一般驗證方法用戶手冊驗證工作要貫穿整個安裝測試始終。我們不僅要保證安裝文檔是清晰和正確的，還要保證文檔是易讀的。下面介紹幾種常用并且行之有效的方法。 測試人員在執(zhí)行具體的測試用例時，必須嚴格按照安裝文檔的步驟來操作。測試人員有責任就不正確的部分提交修改建議并且驗證。為了保證這一點，通常創(chuàng)建專門的文檔相

32、關的測試用例，來跟蹤其狀態(tài)。測試組長定期組織所有測試人員集體審閱所有文檔內容，并且就不清楚得內容展開討論和深入追查，也是一個行之有效的方法。2.4.2 文檔審閱(shn yu)流程文檔驗證是一個繁雜(fnz)和反復的過程，對于篇幅比較長、邏輯比較復雜的文檔尤其如此。為了提高文檔審閱的效果，一般需要借助文檔管理(gunl)系統(tǒng)來統(tǒng)一管理，其一般的功能應包括：測試人員可以通同時審閱同一文檔，并且提交修改建議。信息開發(fā)人員根據(jù)修改建議更正文檔，并且給提交者發(fā)送驗證通知。提交者接收到驗證通知后，能夠關閉修改建議以表明驗證通過。如果驗證未通過，能夠拒絕相關的更改，繼續(xù)提交修改建議。小艾聽后頗有感觸，安巖

33、真是太認真負責了。小艾隨后也用起功來，認真總結了一般的文檔審閱流程，如圖2-1所示。2.5引進先進設備安裝自動化測試項目已經(jīng)進行到中期了，小艾基本熟悉了安裝測試內容和測試流程。平時沒事經(jīng)常和功能和性能測試的同事交流，發(fā)現(xiàn)他們的測試都是自動化的，小艾好羨慕呀，想知道是否安裝測試也能自動化呢？2.5.1 效率的提高從自動化開始在一次周會上，小艾問出了上面的問題，安巖講道：“自動化測試是測試的發(fā)展方法和趨勢，能夠大幅度提高測試的效率。從這個版本開始，安裝測試組已經(jīng)開始嘗試自動化測試了。”“我們做過統(tǒng)計，一個測試用例，手工執(zhí)行要三個小時完成，而自動化后需要一個半小時。當然開發(fā)自動化腳本也要花一定時間和

34、成本，維護自動化腳本也需要花成本，但總體來說，自動化后效率還是比手工執(zhí)行效率有大幅的提高。測試用例需要重復執(zhí)行的次數(shù)越多，自動化后能節(jié)省的成本越高，投資回報率越高?！?小艾疑惑地問：“手工執(zhí)行要三個小時完成，而自動化后只需要一個半小時，這個是怎么算出來的，怎么會差那么多？”“我來算一筆賬就清楚了?？匆粋€典型的安裝(nzhung)場景，如表2-3所示?！?表2-3 安裝(nzhung)場景步驟自動化（分鐘）手工（分鐘）原因1.下載待測構建3050由于要從多個FTP站點下載多個文件，手工下載不是連續(xù)的，并且要手工輸入命令，額外的20分鐘是手工操作和等待2.解壓縮（unzip）1020手工unzip

35、多個文件不能連續(xù)完成，并且要手工輸入命令，所以多花10分鐘3.安裝產(chǎn)品304010分鐘是手工輸入4.驗證安裝2080安裝驗證有多個驗證點，手工驗證非常費時，而自動化去驗證既快又準確總計90190 小艾恍然大悟(hung rn d w)，“原來如此，我明白了，計算機最適合高速連續(xù)地執(zhí)行確定的任務，而用人腦來執(zhí)行這些重復且枯燥的步驟就要慢得多?！薄罢f得對，人腦更適合做創(chuàng)造性的工作，自動化測試就是把人腦從枯燥的工作解放出來，而去做更適合人腦的事情，比如去分析問題，寫自動化腳本等?！卑矌r接著說：“對于安裝測試，我們的測試用例一般要重復執(zhí)行多次，所以自動化對安裝測試一樣很大。現(xiàn)在項目進行到中期了，我們已

36、經(jīng)完成了大部分測試用例的自動化開發(fā)，接下來就是執(zhí)行了，現(xiàn)在誰有興趣做這個部門測試？”小艾對自動化很感興趣，首先舉手報名“算我一個！”，接下來又有幾個人報名。小艾接著說：“但是自動化測試怎么做？”安巖說，接下來我將給大家做一個培訓，來解惑答疑，請大家準時參加。2.5.2 自動化測試的實現(xiàn) 為了提高測試效率和增加測試覆蓋，我們自己為安裝測試開發(fā)了一個自動化安裝/卸載/驗證結果的工具?，F(xiàn)在給大家來講一下這個工具設計的思想。 其實，仔細想一想，對于安裝測試，我們(w men)每天手工執(zhí)行的測試用例，包含眾多手工步驟，比如下載測試構建、解壓縮、輸入必要信息、驗證結果等。把這些手工部分使用某種工具變成自動

37、化部分，就把人給解放出來了。 對于一個(y )典型的Java EE應用的安裝場景，讓我們來看看一個手工的測試用例執(zhí)行步驟。安裝(nzhung)數(shù)據(jù)庫驗證：檢查相關日志文件，確保安裝成功。2.安裝應用服務器驗證：檢查相關日志文件，確保安裝成功。安裝網(wǎng)絡服務器驗證：檢查相關日志文件，確保安裝成功。安裝Java EE應用驗證：檢查相關日志文件，確保安裝成功。安裝后基本功能驗證要把手工步驟自動化，一般要選擇合適的自動化工具來實現(xiàn)自動化測試。自動化測試的工具很多，下面主要介紹兩個和安裝測試相關的自動化工具： IBM Rational Function Tester http:/view/1435992.

38、htm ，RFT-百度百科，2011-05-04 IBM Rational Function Tester （RFT）是一款先進的、自動化的功能和回歸測試工具，它適合做GUI界面相關的自動化測試。Apache ANThttp:/view/1479196.htm ，Apache ant-百度百科，2011-12-29ANT是一個基于Java的自動化腳本引擎，腳本格式為XML。除了做Java 編譯相關任務外，ANT還可以通過插件實現(xiàn)很多應用的調用。ANT適合命令行交互(jioh)相關的自動化測試。 我們的產(chǎn)品是支持命令行方式來安裝的，并且自動化測試的目的是做回歸測試，所以我們選擇ANT工具(gng

39、j)來實現(xiàn)自動化。下面 主要介紹一下相關的原理，對于具體的實現(xiàn)，大家可以參考ANT 相關的書籍來具體實現(xiàn)。首先要把測試用例中的每一步(y b)細化，細化到足夠明確，能夠用ANT語言來表達。比如第一步“安裝數(shù)據(jù)庫，驗證：檢查相關日志文件，確保安裝成功”可以細化到從某個文件服務器上下載數(shù)據(jù)庫安裝包；解壓安裝包到/tmp目錄；提供數(shù)據(jù)庫安裝所需的所有必要信息，；例如目標位置，用戶名，密碼等；啟動數(shù)據(jù)庫靜默安裝；驗證安裝日志，確保其中包含相關的安裝成功信息，不包含相關的失敗信息；生成測試報告。把每一個小步驟分別做成一個個ANT Target。做另一個ANT Target去按順序調用它們，這樣就實現(xiàn)了第一步的自動化。同理，可以實現(xiàn)其余步驟的自動化。把所有步驟按順序串起來，就實現(xiàn)了整個測試用例的自動化。同理，測試計劃里的其他測試用例也都可以自動化。執(zhí)行者只需要做下面的步驟：根據(jù)每個人分配到的任務來更新一個控制文件，在這個文件里，每一行表