1、目錄一、等價類分析法2二、邊界值分析5三、錯誤猜測法6四、判定表法6五、流程分析方法7六、正交試驗設計法9七、狀態遷移法10一、等價類分析法等價類劃分方法針對手機狀態大致可以歸幾個大類：1.按鍵類（等價法） ：有效輸入和無效輸入（有效輸入指UM 和菜單指示；無效輸入指測試菜單功能此時沒有定義的按鍵和用戶動作）；2. 外部中斷類（等價法） ：常用、不常用及無效2.1.常用：來電和來消息（短信、彩信、push 消息）；掀合蓋；側鍵；耳機 FM；情景模式；電量不足2.2.不常用：充電；鬧鐘記事本關機時間整點報時提示；Icon 動畫顯示； Icon動畫刷新；編輯界面pop 顯示框輸入為空或滿；編輯界面

2、pop 顯示框狀態輸入法默認字符編碼默認；失效 SIM 卡；大容量等 SIM 卡兼容； 排序；號碼識別；2.3.無效：“資料讀取中”；“復制中 ”；“請稍后再試”3. 存儲器類3.1. 等價法分類：讀或寫；不讀或不寫。3.2. 因果法分類：先 SIM 卡后手機；先手機后 SIM 卡；提示用戶選擇存儲器 （對比 Nokia ）。3.3. 操作分類：讀；寫；新增；刪除；復制（先刪除后新增；先新增后刪除）4. 狀態類：正確；錯誤；變更；用戶設定變更舉例一，短消息發送功能 :英文： Default 7-bit alphabet (over 160 characters)合法等價類：0 160非法等價類

3、： >160The quick fox jumps over the lazy brown dog中文： UCS-2 alphabet (over 70 characters)合法等價類：0 70非法等價類： >70諾基亞（英文） ： Extended default 7-bit alphabet (over 140 Bytes)，智慧短信，可以攜帶黑白圖片。合法等價類：0 140非法等價類： >140在寫字板里面輸入“聯通”二字，保存后，再打開，即出現亂碼。舉例二，單個通話實例的撥打與掛斷測試用例標識測試階段：系統測試測試項單個通話實例的撥打與掛斷測試項屬性A參照規范重要級

4、別高測試原因手機在待機狀態下，確保手機能正常撥出電話預置條件1.正常信號環境2.IDLE 狀態3.默認原廠參數設定輸入1.電話號碼（手機號碼，固定電話，帶分機的號碼，字符串，特殊號碼如：*21*021xxxxxxxx# ，+或 00，超短號碼，超長號碼，撥打一位號碼，撥打最大長度號碼 等）2. 撥號過程中電池低電量提示、來短信、來彩信3. 撥號過程中鬧鐘時間到、行事歷時間到4. 撥號過程中插上充電器5. 撥號過程中突然斷電6. 按鍵加鎖測試執行步驟IDLE 狀態撥打號碼按 Send 鍵發送按 End 鍵掛斷預期輸出結果1.按 Send 鍵可以撥打并顯示，按End 鍵可掛斷2. 撥打號碼過程電池

5、低電量提示、來短信、來彩信撥打界面正常3. 撥打號碼過程鬧鐘時間到、行事歷時間到撥打界面正常4. 撥號過程中插上充電器，背光狀態及撥打界面正常5. 撥號過程中突然斷電，插上充電器重新開機后能正常撥出6. 按鍵加鎖僅可撥打緊急電話號碼112測試用例標識測試階段：系統測試測試項單個通話實例的撥打與掛斷測試項屬性A參照規范重要級別高測試原因手機在無信號或無網絡情形下，手機無法正常撥打電話預置條件1.正在搜索網絡或正處于注冊界面2.IDLE 狀態3.默認原廠參數設定輸入同上用例測試執行步驟IDLE 狀態撥打號碼按 Send 鍵撥號預期輸出結果測試用例標識測試項測試項屬性參照規范重要級別測試原因預置條件

6、輸入測試執行步驟1. 重復以上操作，提示無法撥打成功的提示信息2. 重復以上步驟，背光處理正常測試階段：系統測試單個通話實例的撥打與掛斷A高SIM 卡失效情況下，手機無法正常撥打電話1.事先準備欠費、過期、被鎖、注冊失敗、無法使用的SIM 卡2. IDLE 狀態3. 默認原廠參數設定同上用例IDLE 狀態撥打號碼按 Send 鍵撥號預期輸出結果1.重復以上操作，提示無法撥打成功的提示信息2. 重復以上步驟，背光處理正常3. 重復以上步驟，提示給用戶可接受的錯誤異常信息測試用例標識測試階段：系統測試測試項單個通話實例的撥打與掛斷( 開啟固定撥號名單時 )測試項屬性A參照規范重要級別高測試原因手機

7、在待機狀態下，確保手機能正常撥出固定撥號名單中電話號碼預置條件正常信號環境IDLE 狀態默認原廠參數設定SIM 卡開啟固定撥號名單輸入1.預選存取電話號碼（手機號碼，固定電話，帶分機的號碼，字符串，特殊號碼如： *21*021xxxxxxxx#，+或 00 ，超短號碼，超長號碼，撥打一位號碼，撥打最大長度號碼等）2.撥打固定撥號名單中存在的號碼。如，8621xxxxxxxxw00000003.撥打固定撥號名單中沒有的號碼。如，xxxxxxxx4.撥號過程中電池低電量提示、來短信、來彩信5.撥號過程中鬧鐘時間到、行事歷時間到6.撥號過程中插上充電器7.撥號過程中突然斷電8.按鍵加鎖9.操作通話選

8、項菜單測試執行步驟IDLE 狀態撥打號碼按 Send 鍵發送按 End 鍵掛斷預期輸出結果1.按 Send 鍵可以撥打并顯示，按End 鍵可掛斷，撥號畫面正常，且顯示固定撥號名單中名字2.撥號畫面正常3.撥號畫面提示“限撥FDN名單”4.撥打號碼過程電池低電量提示、來短信、來彩信撥打界面正常5.撥打號碼過程鬧鐘時間到、行事歷時間到撥打界面正常6.撥號過程中插上充電器，背光狀態及撥打界面正常7.撥號過程中突然斷電，插上充電器重新開機后能正常撥出8.按鍵加鎖僅可撥打緊急電話號碼1129.通話選項菜單功能正常測試用例標識測試階段：系統測試測試項單個通話實例的撥打與掛斷( 設定通話限制時)測試項屬性A

9、參照規范重要級別高測試原因手機在待機狀態下，確保手機能滿足通話限制功能預置條件正常信號環境IDLE 狀態默認原廠參數設定申請開通通話限制服務輸入測試執行步驟IDLE 狀態撥打號碼按 Send 鍵發送按 End 鍵掛斷預期輸出結果測試用例標識測試階段：系統測試測試項單個通話實例的撥打與掛斷( 漫游情形時 )測試項屬性A參照規范重要級別高測試原因手機在待機狀態下，確保手機能滿足通話限制功能預置條件正常信號環境IDLE 狀態默認原廠參數設定申請開通通話限制服務輸入測試執行步驟IDLE 狀態撥打號碼按 Send 鍵發送按 End 鍵掛斷預期輸出結果二、 邊界值分析例子 1：短消息發送功能的等價類劃分方

10、法:英文： Default 7-bit alphabet (over 160 characters)合法等價類：0 160非法等價類： >160The quick fox jumps over the lazy brown dog中文： UCS-2 alphabet (over 70 characters)合法等價類：0 70非法等價類： >70諾基亞（英文） ： Extended default 7-bit alphabet (over 140 Bytes)，智慧短信，可以攜帶黑白圖片。合法等價類：0 140非法等價類： >140例子 2：首先用 7 列的 LCD顯示屏，軟

11、件可以顯示7 列漢字，如果換成8 列漢字的顯示屏，那么，如果軟件格式化處理比較僵化，可能依然顯示7 個漢字。這樣， 軟件的實現， 與 LCD的規格不符合。因此，需要考慮LCD屏幕的規格，依據邊界值方法設計用例。LCD屏幕上有效顯示區域 4 行每行 8 漢字，可考慮編輯超過 4 行每行超過 16 字符情形來進行測試。LCD列邊界值需要考慮：7 個漢字， 8 個漢字， 9 個漢字行邊界值： 31 個漢字， 32 個漢字， 33 個漢字例子 3：SIM 卡名片簿姓名超長（20 個英文字符），號碼超長情形，新增和查看用戶姓名由學員完成該作業：1、 注意等價類和邊界值的用例設計方法2、 關注 LCD的顯

12、示格式問題3、 關注新增、查看兩種功能的結合，可能新增姓名是正確的，但是查看的格式錯誤。三、錯誤猜測法例子 1：利用手機鬧鐘重響的例子引入錯誤猜測法基本概念，講解錯誤猜測法的意義未接來電 29 通，內存中規劃的分區一直分配被占用。即使同一號碼也同樣占用資源。假設此時第 30 通電話正好為來電號碼不顯示，即“來電號碼未知”或境外來電號碼隱藏時（國外保護個人隱私，自動開啟來電號碼隱藏功能） ，可能會出現 BUG，實際情況證明，此時會出現 Reset 問題。同樣道理，推斷第一通電話如果為“來電號碼未知”，也可能出現上述問題。例子 2：通常手機解決方案中sunplus 、雅馬哈和弦芯片發聲。為了降低成

13、本采用DSP策略純軟件發聲（如果采用硬件獨立聲音控制芯片，不會出現下面問題），此時測試中就猜測當手機設定鬧鐘時，鬧鐘時間到后， 確定為重響，此時用戶進入鈴聲選擇 - 瀏覽 - 播放時，這時候鈴聲控制軟件會出現資源沖突， 可能出現 BUG。測試結果是出現 RESET或者瀏覽鈴聲無響鈴的結果。例子 3：比如， 設定鬧鐘鈴聲, 在 IDLE 下鬧鐘響鈴未處理（響鈴一分鐘后，鈴聲停止，系統進入另外一種狀態，菜單提示為鬧鐘是否重響？）, 待鈐聲響完后按兩次SKL 鍵（確定鍵） ，（第一次確定要重響， 第二次應該返回 IDLE 狀態） , 再次進入 " 鈐聲設定 "/" 鈐聲

14、類型 ", 此時任選一鈴聲都沒有聲音四、判定表法舉例一，若手機用戶欠費或停機，則不允許主被叫。表示為判定表如下：1234條件用戶欠費YYNN用戶被停機YNYN動作可以主被叫NNNY舉例二，區別手機掉網、搜網、飄網、SIM 卡座松動問題1234條件顯示運營商YYNNlogo 正確顯示有信號YNYN動作可以撥打電YNY（除撥 112Y話外還可以撥打其它號碼）五、流程分析方法1- 手動 / 自動選網模式；11- 自動注冊并顯示已有網絡服務2- 手動模式（選網模式的一種）； 3- 搜尋到 HPLMN（歸屬網絡）及FPLMN（禁止網絡）；6- 頻段搜索； 7- 自動選擇頻段；8- 手動選擇頻段

15、900 或 1800；（新手機才有頻段手動選擇）4- 選擇 FPLMN；5- 注冊 FPLMN路徑path1:1-11path2:1-2-3-4-5-1-11path3:1-2-3-6-8-9-10-1-11path4:1-2-3-6-7-9-10-1-11舉例二，彩信發送功能1.終端發送 MMS，如果是終端到終端，那么以WSP（無線會話協議）協議編碼送到WAP網關；如果終端到應用服務器（發送Email ） , 則以 IP 協議發送到IP 網關；2. WAP網關或 IP 網關都以 HTTP協議與 MMS中繼器通信，文件內容傳給中繼器3. 中繼器將文件送往 MMS服務器，并以 MIME格式存儲。

16、（ MIME的格式可以被手機終端識別并顯示，并且可以被 Email 客戶端瀏覽并顯示的文件格式）4. 如果 MMS接收方為手機終端， MMS服務器調用號碼以及相關路由信息， 并進行數據分析，判斷終端支持能力和承載能力，如果終端不支持MMS，只通過短消息格式發文字部分；如果終端支持MMS，直接發送 MIME格式的文件到手機終端。5.如果，發送到Email 服務器，系統通過路由選擇，把MIME格式的文件發送到 Email地址所在的服務器。6.該 MMS支持的媒體格式包括文本、鈴聲、圖片；文本沒有上限64K，包括 64K；鈴聲單首最大為 64K，包括 64K，最多支持 5 頁；單頁圖片最大64K，最

17、多 5 頁；測試用例設計利用流程分析方法，測試分析時需要考慮以下幾點：1. 彩信發送測試時需要考慮基于WAP業務實現和基于 IP 網關的流程差異；2. MMS服務器數據分析并確定處理方法時需要考慮終端到終端的情形和終端到應用的業務情形；3. 確定終端到終端的情形下，還需要考慮終端是否支持MMS發送六、正交試驗設計法例子 1：假設一個WEB站點，該站點有大量的服務器和操作系統，并且有許多具有各種插件的瀏覽器瀏覽：WEB瀏覽器： Netscape6.2 、 IE6.0 、 Opera4.0插件：無、 RealPlayer 、 MediaPlayer應用服務器： IIS 、 Apche、 Netsc

18、ape Enterprise操作系統： Windows2000、 Windows NT、 Linux正交表：1234111112122231333421235223162312731328321393321提取系統功能說明中的因子：WEB瀏覽器插件應用服務器操作系統分析各因子的狀態WEB瀏覽器： 1 Netscape6.2 、 2=IE6.0 、 3=Opera4.0插件 : 1=None 、 2=RealPlayer 、 3=MediaPlayer應用服務器 : 1=IIS、 2=Apche、 3=Netscape Enterprise操作系統 : 1=Windows2000 、2=Wind

19、ows NT、 3=Linux將因子、狀態映射到上面正交表中：測試用例瀏覽器插件服務器操作系統1Netscape6.2NoneIISWindows20002Netscape6.2RealPlayerApcheWindows NT3Netscape6.2MediaPlayerNetscape EnterpriseLinux4IE6.0NoneApcheLinux5IE6.0RealPlayerNetscape EnterpriseWindows20006IE6.0MediaPlayerIISWindows NT7Opera4.0NoneNetscape EnterpriseWindows NT8

20、Opera4.0RealPlayerIISLinux9Opera4.0MediaPlayerApcheWindows2000舉例 2： MMS處理模塊編輯模塊：支持SMIL（同步多媒體綜合語言）、不支持SMIL.效果處理模塊：水波紋、半透明、水印、反透 .界面顯示模塊：POP形式、窗體式顯示 .舉例 3：照相機功能測試七、狀態遷移法舉例手機mp3鍵盤播放模式測試用例設計1. 鍵盤用戶模式基本操作功能2. 支持媒體格式與文件格式要求3. 多媒體播放中對外部事件的響應4. 終端處理能力（包括終端異常處理、文件操作）5. PC與終端同步能力鍵盤用戶模式基本操作功能系統測試用例設計步驟：編寫狀態事件表

21、；編制狀態圖轉換表；編寫合法測試用例；編寫非法測試用例；編寫錯誤異常處理測試項；序號需求內容播放器要求1功能類型和操作方式采用菜單選項方式2文件播放必須支持3播放基本功能 Play, Pause, Stop, Seek必須支持4聲音調節必須支持5亮度調節必須支持6對比度調節推薦支持7播放進度顯示必須支持8模式選擇及切換必須支持，可通過設定功能鍵切換常規模式9后臺播放模式推薦支持10播放器設置必須支持，提供缺省設置11播放統計及列表記錄必須支持125 鍵快捷設定及操作必須支持5 鍵功能定義Up增大音量Down減小音量Left上一首或后退Right下一首或快進Select （側鍵 ok）播放 /

22、暫停 功能切換狀態事件表（黑點著重號表示為非法組合）函數名字Idle倒播放進錄音EvRewindbutton1- 倒·8- 倒11- 倒·（倒）Evplaybutton2-播5- 播放·12- 播·（播放）放Evfastforwardbutton3- 進6- 進9- 進··（進）Evrecord4-錄····（錄音）音Evstopbutton·7-idle10-idle13-idle14-idle（Idle ）7 軟件測試文檔由安博測試空間技術中心提供1、軟件測試文檔 就是為將軟件測試

23、當作一個項目一樣實施計劃和管理而引入的，它為測試項目的組織、規劃和管理提供了一個規范化的架構。2、軟件測試文檔主要包括測試計劃、測試用例、測試規程、測試事件報告、測試總結報告等。測試文檔總所規定的內容可以作為對測試過程完備性的對照檢查表，有助于提高測試工程每個階段的能見度，極大地提高了測試工作的可管理性。為了統一測試文檔的書寫標準，IEEE/ANSI制定了829-1983 標準，還有其他的一些也用于指導軟件測試文檔的編寫，如我國制定的計算機軟件測試文件百年之規范（GB/T9386-1988）3、 測試文檔編寫規范（GB/T 9386-1988 ）簡介（ 1） .引用標準該規范的引用標準為：GB

24、/T 11457軟件工程術語GB 8566 計算機軟件開發規范GB 8567計算機軟件產品開發文件編制指南（ 2） .關鍵術語定義設計層：軟件項的設計分解（如系統，子系統，程序，模塊）通過準則：一個軟件項或軟件特性的測試是否通過的判別依據軟件特性：軟件項的顯著特性（如功能，性能或可移植性）軟件項：源代碼，目標代碼，作業控制代碼，控制數據或這些項的集合。測試項：作為測試對象的軟件項（ 3） .規范的主要內容該規范確定了各個測試文件的格式和內容，所提出的文件類型包括測試計劃，測試說明和測試報告。測試計劃免除測試活動的范圍，方法，資源和進度，他規定被測試的項，被測試的特性，應完成的測試任務，擔任各項

25、工作的人員職責及與本計劃有關的風險等。4、測試說明包括三類文件測試設計說明： 詳細描述測試方法，規定該設計及其有關測試所包括的特性，還規定完成測試所需的測試用例和測試規程，并規定特性的通過準則。測試用例說明： 列出用于輸入的具體值以及預期的輸出結果，并規定在使用具體測試用例時，對測試規程的各種限制。將測試用例與測試設計封開，可以使它們用于多個設計并能在其它情形下重復使用。測試規程說明： 規定對于運行系統和執行指定的測試用例來實現有關測試設計所要求的所有步驟。5、測試報告則包括四類文件：測試項傳遞包括： 指明在開發組和測試組獨立工作的情況下或者在希望正式開始測試的情況下為進行測試而傳遞的測試項。

26、測試日志：測試組用于記錄測試執行過程中發生的情況。測試事件報告：描述在測試執行期間發生并需進一步調查的一切事件。測試總結報告：總結與測試設計說明有關的測試活動。6.對規范的實施使用該規范的每個單位， 要規定測試階段所應有的特性文件，并在測試計劃中規定測試完成后所能提交的全部文件。使用該規范的每個單位應該補充規定對內容的要求和約定，及便反映總結在測試， 文件控制，配置管理和質量保證方面所用的特定方法，設備工具。一下是規范中的文件編制實施及使用指南（ 1）實施指南在實施測試文件編制的初始階段可先編寫測試計劃于測試報告文件。測試計劃將為整個測試過程提供基礎。測試報告將鼓勵測試單位以良好的方式記錄整個

27、測試過程的情況。（ 2）用法指南在項目計劃及單位標準中， 指明在那些測試活動中需要那些測試文件，并可在文件中加入一些內容，使各個文件適應一個特定的測試項及一個特定的測試環境。7軟件測試文件編制規范中的內容要求以下是規范中各個測試文件的書寫格式及內容。a 測試計劃(1)測試計劃名稱（該計劃的第1 章）(2) 引言（該計劃的第 2 章）(3) 測試項(4) 被測試的特性(5) 不被測試的特性(6) 方法(7) 項通過的準則(8) 暫停標準和再啟動要求(9) 應提供的測試文件(10) 測試任務(11) 環境要求(12) 職責(13) 人員和訓練要求(14) 進度(15) 風險和應急(16) 批準b

28、測試設計說明（1）測試設計說明名稱（2）被測試的特性（3）方法詳述（4）測試用例名稱（5）特性通過準則c 測試用例說明（1）測試用例說明名稱（2）測試項（3）輸入說明（4）輸出說明（5）環境要求（6）特殊的規程要求（7）用例間的依賴關系d 測試規程說明（1）測試規程說明名稱（2）目的（3）特殊要求（4）規程步驟e 測試項傳遞報告(1) 傳遞報告名稱(2) 傳遞項(3) 位置(4) 狀態(5) 批準f 測試日志（1）測試日志名稱（2）描述（3）活動和事件條目g 測試事件報告名稱（1）測試事件報告取一個專用名稱（2）摘要（3）事件描述（4）影響h 測試總結報告1. 規定該報告必須由哪些人（姓名和職

29、務）審批，并為簽名和日期留出位置。由安博測試空間技術中心提供目錄1、V 模型152、W 模型173、H 模型184、 X 模型205、其他測試模型211、瀑布模型242、原型模型253、螺旋模型27背景知識：目前主流的 軟件生命周期模型或軟件開發過程模型 有：瀑布模型、原型模型、螺旋模型、增量模型、漸進模型、快速軟件開發 (RAD)以及 Rational 統一過程(RUP)等，這些模型對于軟件開發過程具有很好的指導作用，但是在這些過程方法中，軟件測試的地位和價值并沒有體現出來， 也沒有給軟件測試以足夠的重視，利用這些模型無法更好地指導測試實踐。 軟件測試是與軟件開發緊密相關的一系列有計劃、系統

30、性的活動， 顯然軟件測試也需要測試模型去指導實踐。 下面先對主要的模型做一些簡單的介紹，再補充軟件生命周期做介紹。1、V模型V 模型是最具有代表性 的測試模型。 V 模型最早是由 Paul Rook 在 20 世紀 80 年代后期提出的， V 模型在英國國家計算中心文獻中發布，旨在改進軟件開發的效率和效果。在傳統的開發模型中，比如瀑布模型，通常把測試過程作為在需求分析、概要設計、詳細設計和編碼全部完成之后的一個階段， 盡管有時測試工作會占用整個項目周期一半的時間， 但是有人仍認為測試只是一個收尾工作， 而不是主要的工程。 V 模型是軟件開發瀑布模型的變種， 它反映了測試活動與分析和設計的關系，

31、從左到右，描述了基本的開發過程和測試行為， 明確地標明了測試工程中存在的不同級別，清楚地描述了這些測試階段和開發過程期間各階段的對應關系。如圖 5-1 所示。圖1 V模型圖圖 1 V 模型圖中箭頭代表了時間方向，左邊下降的是開發過程各階段，與此相對應的是右邊上升的部分，即測試過程的各個階段。V 模型的軟件測試策略既包括低層測試又包括了高層測試，低層測試是為了確保源代碼的正確性，高層測試是為了使整個系統滿足用戶的需求。V 模型指出，單元和集成測試是驗證程序設計，開發人員和測試組應檢測程序的執行是否滿足軟件設計的要求； 系統測試應當驗證系統設計， 檢測系統功能、性能的質量特性是否達到系統設計的指標

32、； 由測試人員和用戶進行軟件的確認測試和驗收測試， 追溯軟件需求說明書進行測試， 以確定軟件的實現是否滿足用戶需求或合同的要求。V 模型存在一定的局限性， 它僅僅把測試過程作為在需求分析、概要設計、詳細設計及編碼之后的一個階段。 容易使人理解為測試是軟件開發的最后一個階段，主要是針對程序進行測試尋找錯誤，而需求分析階段隱藏的問題一直到后期的驗收測試才被發現。類比記憶： 此模型與軟件開發模式中的線性模型 （典型的瀑布模型） 有相似的不足，在瀑布模型中， 測試階段處于軟件實現后， 這意味著必須在代碼完成后有足夠的時間預留給測試活動， 否則將導致 測試不充分， 開發前期未發現的錯誤會傳遞并擴散到后面

33、的階段， 而在后面發現這些錯誤時，可能已經很難回頭再修正，從而導致項目的失敗。2、W模型V 模型的局限性在于沒有明確地說明早期的測試， 不能體現“盡早地和不斷地進行軟件測試”的原則 。在 V 模型中增加軟件各開發階段應同步進行的測試，被演化為一種 W模型，因為實際上開發是 V，測試也是與此相并行的 V。基于“盡早地和不斷地進行軟件測試”的原則， 在軟件的需求和設計階段的測試活動應遵循 IEEE std1012-1998 軟件驗證和確認 (V&V)的原則。一個基于 V&V原理的 W模型示意圖如圖 2 所示。圖2W模型圖相對于 V 模型， W模型更科學。 W模型可以說是 V 模型自

34、然而然的發展。W模型強調測試伴隨著整個軟件開發周期， 而且測試的對象不僅僅是程序， 需求、功能和設計同樣要測試 。這樣，只要相應地開發活動完成， 我們就可以開始執行測試，可以說， 測試與開發是同步進行的 ，從而有利于盡早地發現問題。以需求為例，需求分析一完成， 就可以對需求進行測試， 而不是等到最后才進行針對需求的驗收測試。如果測試文檔能盡早提交，那么就有了更多的檢查和檢閱的時間，這些文檔還可用于評估開發文檔。 另外還有一個很大的益處是， 測試者可以在項目中盡可能早地面對規格說明書中的挑戰。這意味著測試不僅僅是評定軟件的質量，還可以盡可能早地找出缺陷所在，從而幫助改進項目內部的質量。參與前期工

35、作的測試者可以預先估計問題和難度，這將可以顯著地減少總體測試時間，加快項目進度。根據 W模型的要求，一旦有文檔提供，就要及時確定測試條件，以及編寫測試用例， 這些工作對測試的各級別都有意義。當需求被提交后， 就需要確定高級別的測試用例來測試這些需求。當概要設計編寫完成后， 就需要確定測試條件來查找該階段的設計缺陷。W模型也是有局限性的。 W模型和 V模型都把軟件的開發視為需求、 設計、編碼等一系列串行的活動。 同樣，軟件開發和測試保持一種 線性的前后關系 ，需要有嚴格的指令表示上一階段完全結束， 才可以正式開始下一個階段。 這樣就無法支持迭代、 自發性以及變更調整 。對于當前很多文檔需要事后補

36、充， 或者根本沒有文檔的做法 ( 這已成為一種開發的文化 ) ，開發人員和測試人員都面臨同樣的困惑。類比記憶： W模型相當兩個 V 模型的疊加 ，一個是開發的 V，一個是測試的 V，由于在項目中開發和測試的是同步進行， 相當于兩個 V是并列同步的進行的， 測試在一定程度是隨著開發的進展而不斷向前進行。3、H模型V 模型和 W模型均存在一些不妥之處。首先，如前所述，它們都把軟件的開發視為需求、設計、編碼等一系列串行的活動，而事實上，雖然這些活動之間存在相互牽制的關系，但在大部分時間內，它們是可以交叉進行的。雖然軟件開發期望有清晰的需求、 設計和編碼階段， 但實踐告訴我們， 嚴格的階段劃分只是一種

37、理想狀況。 試問，有幾個軟件項目是在有了明確的需求之后才開始設計的呢？所以， 相應的測試之間也不存在嚴格的次序關系。 同時，各層次之間的測試也存在 反復觸發、迭代和增量關系 。其次， V 模型和 W模型都沒有很好地體現測試流程的完整性。為了解決以上問題， 提出了 H模型。它將測試活動完全獨立出來， 形成一個完全獨立的流程，將測試準備活動和測試執行活動清晰地體現出來。 H 模型如圖 3 所示。圖3H模型圖H 模型圖僅僅演示了在整個生存周期中某個層次上的一次測試“微循環”。圖中的其他流程可以是任意開發流程。例如，設計流程和編碼流程。也可以是其他非開發流程，例如， SQA流程，甚至是測試流程自身。也

38、就是說，只要測試條件成熟了， 測試準備活動完成了， 測試執行活動就可以 ( 或者說需要 ) 進行了。概括地說， H模型揭示了：1）軟件測試 不僅僅指測試的執行，還包括很多其他的活動。2）軟件測試是一個 獨立的流程，貫穿產品整個生命周期，與其他流程 并發地進行。3）軟件測試要 盡早準備，盡早執行 。4）軟件測試是根據被測物的不同而分層次進行 的。不同層次的測試活動可以是按照某個次序先后進行的，但也可能是反復的。在 H 模型中，軟件測試模型是一個獨立的流程，貫穿于整個產品周期，與其他流程并發地進行。當某個測試時間點就緒時，軟件測試即從測試準備階段進入測試執行階段。4、X模型Marick曾提出過一些

39、觀點和意見，其中首先是Marick不建議要建立一個替代模型。這里我很冒昧地引用了一些Marick的想法，并重新經過組織，形成了“X模型 ”。其實并不是為了和V 模型相對應而選擇這樣的名字，而是由于其它一些原因： X 通常代表未知，而Marick也認為他的觀點并不足以支撐一個模型的完整描述，但其中已經有一個模型所需要的一些主要內容，其中也包括了象探索性測試（ exploratory testing）這樣的亮點。我還需要在使用文字方面也向Marick道歉，因為認同 Marick觀點的無疑大多屬于X 一代（ X 一代）。另外，我勾畫了一張 X 形狀的示意圖，我相信該圖能夠很好地以另一種表達形式來體現

40、Marick的觀點。圖 2-X模型示意圖由于 X 模型從沒有被文檔化，其內容一開始需要從在 V 模型的相關內容中進行推斷，這在 Marick 的相關文章中已有體現。這里關于 X 模型的論述比較簡短，因為它還沒有完全從文字上成為 V 模型的全面擴展，而且我不想在這里重復在軟件測試：不可忽略的階段文章中所提到的很多測試技術的概念。Marick對 V 模型的最主要批評是V 模型無法引導項目的全部過程。 他認為一個模型必須能處理開發的所有方面，包括交接，頻繁重復的集成， 以及需求文檔的缺乏等等。5、前置測試模型前置測試是一個將測試和開發緊密結合的模型，該模型提供了輕松的方式，可以使你的項目加快速度。前

41、置測試模型體現了以下的要點：開發和測試相結合前置測試模型將開發和測試的生命周期整合在一起，標識了項目生命周期從開始到結束之間的關鍵行為。 并且表示了這些行為在項目周期中的價值所在。如果其中有些行為沒有得到很好的執行，那么項目成功的可能性就會因此而有所降低。如果有業務需求， 則系統開發過程將更有效率。我們認為在沒有業務需求的情況下進行開發和測試是不可能的。而且，業務需求最好在設計和開發之前就被正確定義。對每一個交付內容進行測試每一個交付的開發結果都必須通過一定的方式進行測試。源程序代碼并不是唯一需要測試的內容。在圖中的被圈框表示了其它一些要測試的對象，包括可行性報告、 業務需求說明，以及系統設計

42、文檔等。這同V 模型中開發和測試的對應關系是相一致的，并且在其基礎上有所擴展，變得更為明確。前置測試模型包括 2 項測試計劃技術， 這也是屬于上述21 項需求測試技術中的一部分。其中的 第一項技術是開發基于需求的測試用例。這并不僅僅是為以后提交上來的程序的測試做好初始化準備， 也是為了驗證需求是否是可測試的。 這些測試可以交由用戶來進行驗收測試，或者由開發部門做某些技術測試。 很多測試團體都認為， 需求的可測試性即使不是需求首要的屬性， 也應是其最基本的屬性之一。 因此，在必要的時候可以為每一個需求編寫測試用例。不過，基于需求的測試最多也只是和需求本身一樣重要。 一項需求可能本身是錯誤的，但它

43、仍是可測試的。而且，你無法為一些被忽略的需求來編寫測試用例。第 2 項技術是定義驗收標準。 在接受交付的系統之前， 用戶需要用驗收標準來進行驗證。驗收標準并不僅僅是定義需求， 還應在前置測試之前進行定義， 這將幫助揭示某些需求是否正確，以及某些需求是否被忽略了。在設計階段進行計劃和測試設計設計階段是做測試計劃和測試設計的最好時機。在 V 模型中，驗收測試最早被定義好，并在最后執行，以驗證所交付的系統是否真正符合用戶業務的需求。與 V 模型不同的是，前置測試模型認識到驗收測試中所包含的3 種成份 ，其中的2 種都與業務需求定義相聯系：即定義基于需求的測試，以及定義驗收標準。但是，第三種則需要等到

44、系統設計完成， 因為驗收測試計劃是由針對按設計實現的系統來進行的一些明確操作定義所組成，這些定義包括：如何判斷驗收標準已經達到，以及基于需求的測試已算成功完成。技術測試主要是針對開發代碼的測試，例如V 模型中所定義的動態的單元測試，集成測試和系統測試。另外，前置測試還提示我們應增加靜態審查，以及獨立的QA 測試。QA 測試通常跟隨在系統測試之后，從技術部門的意見和用戶的預期方面出發，進行最后的檢查 .同樣的還有特別測試。我們取名特別測試， 并把該名稱作為很多測試的一個統稱，這些測試包括 負載測試、安全性測試、可用性測試 等等，這些測試不是由業務邏輯和應用來驅動的。對技術測試最基本的要求是驗證代

45、碼的編寫和設計的要求是否相一致。 一致的意思是系統確實提供了要求提供的， 并且系統并沒有提供不要求提供的。 技術測試在設計階段進行計劃和設計，并在開發階段由技術部門來執行。6、測試模型的使用前面我們介紹了幾種典型的測試模型，應該說這些模型對指導測試工作的進行具有重要的意義， 但任何模型都不是完美的。 我們應該盡可能地去應用模型中對項目有實用價值的方面， 但不強行地為使用模型而使用模型， 否則也沒有實際意義。在這些模型中， V 模型強調了在整個軟件項目開發中需要經歷的若干個測試級別，而且每一個級別都與一個開發級別相對應， 但它忽略了測試的對象不應該僅僅包括程序，或者說它沒有明確地指出應該對軟件的需求、 設計進行測試，而這一點在 W模型中得到了補充。 W模型強調了測試計劃等工作的先行和對系統需求和系統設計的測試， 但 W模型和 V 模型一樣也沒有專門對軟件測試流程予以說明，因為事