軟體測試是軟體生存週期中必不可少的環節，軟體的典型生存週期可以用下圖來形容：

                   

軟體測試的目的是儘可能早的發現軟體缺陷並確保其得以修復，因此軟體測試是提高軟體質量的重要手段，大量的經驗實踐證明，軟體測試越早參與到軟體開發過程中，開發出來的軟體質量相對越高，時間和物力也越經濟。

    根據軟體工程的基本理論，多模組程式的測試共包括以下4個層次：

  

各階段測試的具體內容會在以後章節具體介紹，下面介紹一下軟體測試的經典技術。

軟體測試的經典技術分為黑盒測試和白盒測試技術。其中黑盒測試技術忽略程式內部結構，看不到程式的程式碼細節，只針對程式的功能進行測試，黑盒測試的方法有：

 

具體方法會在以後章節中具體介紹，敬請期待。

        說完黑盒測試，就該介紹白盒測試了，白盒測試也稱結構測試，白盒測試深入程式內部結構，分析程式程式碼結構，因此學好白盒測試，首先要掌握必要的程式語言，比如說Java或者C/C++/C#等。白盒測試的方法有：

 

 白盒測試的方法要涉及到程式圖和流程圖的設計，邏輯覆蓋主要利用程式圖，路徑覆蓋主要利用流程圖，測試者必須能夠根據程式的程式碼結構畫出相應的程式圖和流程圖，白盒測試的方法也會在以後的章節中具體介紹。

本節主要介紹一下層次測試的第一步——單元測試。在瞭解單元測試之前先看一個簡單的主程式樹狀模組圖： 

   所謂模組測試就是在底層進行的測試，如上圖，單元測試就是測試上圖中紫色的模組。單元測試是整個測試的基礎，單元測試中發現的錯誤約佔程式總錯誤數2/3，單元測試的目標是通過對程式底層模組的靜態和動態測試使底層模組達到模組說明的要求。

   單元測試主要測試5方面的的問題：

   模組的介面測試主要檢查資料能否正確地通過模組；資料結構測試目的在於保持程式內部資料的完整性；重要路徑測試是單元測試的一項基本任務，主要做好覆蓋分析；程式最容易在邊界上出錯，因此邊界條件測試是必不可少的；錯誤處理測試要點是在工作中發生了錯誤，其中的錯誤處理措施是否有效。

    單元測試的一般步驟：

   編譯過程中主要檢查物件就是程式碼中的語法錯誤；靜態分析器檢查使用專用工具來進行分析，程式碼審查主要依靠人工，第二步和第三步都是以檢查結構性錯誤為主的靜態分析；動態測試是單元測試的最後步驟，重點是發現單元的功能型錯誤，可採用白盒測試或者黑盒測試方法進行測試，白盒測試和黑盒測試會在以後進行詳細介紹，這裡知道有這兩種方法即可。

   程式碼評審有兩類組織形式：一、辦公桌檢查，由程式設計師自己審查自己的程式碼，僅適用於規模很小的程式。二、以小組會的方式進行，又分為走查和程式碼會審兩種，適用於各種規模的程式。

   單元測試不是獨立的程式，在多模組程式中，模組之間可以相互呼叫，單元測試時往往需要為被測模組編制若干模組替身，替身模組僅是真實模組的簡化，僅需模擬與被測模組直接相關的一部分功能。

   根據經驗總結，在單元級發現問題時，問題肯定就在那個單元中，如果在多個單元模組整合時發現缺陷，那麼它一定與模組之間的互動有關。在實際情況中，有很少的例外。

好的，本節到此結束，下一節將詳細介紹層次測試的第二步——整合測試。

本節主要介紹一下層次測試的第二步——整合測試。上一節我們已經在一定程度上了解了單元測試，這一節我們要講解的整合測試就是建立在單元測試的基礎上，將所有模組按照設計要求組裝成一個完整的系統而進行的測試，也稱為聯合測試或組裝測試。

   整合測試應由獨立於開發人員的測試小組負責實施。整合測試重點測試所有模組的介面部分，需設計測試過程所使用的驅動模組和樁模組，在單元測試時為被測試模組做的上下級模組做的替身分別稱為驅動模組和樁模組。測試方法以黑盒為主。整合測試的方案大致可分為有三種，分別是自頂而下、由底向上以及從兩頭逼近的混合模式。看下面程式模組：

1. 自頂而下

      自頂而下的測試從頂模組開始，沿被測程式的結構圖逐步向下測試，按照移動路線的差異，又可區分為兩種不同的實施步驟，分別是先廣後深和先深後廣兩種，以上圖為例，先廣後深的組裝順序：

M1——M2——M3——M4——M5——M6——M7——M8

      先深後廣的組裝順序：

M1——M2——M5——M8——M6——M3——M4——M7

      自頂而下的測試要使用樁模組，如下圖顯示了先深後廣的測試步驟：

                                                                                                                                              

                     

其中，S2、S3、S4、S5、S6和S8分別是M2、M3、M4、M5、M6和M8的替身。

1. 由底而上

   由底而上模式的典型步驟：

   1. 從下層找出一個沒有下層模組作為開始模組，由下向上逐步新增新模組，組成程式中的一個子系統或模組群。
   2. 從另一子系統或模組群中選出另一個無下級模組開始，按步驟1進行組成一個新的子系統。
   3. 重複上一步，直到得出所有子系統，最後組裝成完整的系統。

   例圖程式模組可能的組裝順序：

   M8——M5——M6——M2

   M7——M4——M3——M1

1. 混合模式

     混合模式是以上兩種模式的綜合，其一般步驟：

1. 對上層模組採取自頂向下測試
2. 對關鍵模組或子系統採取由底向上測試

        此種模式兼有以上兩種模式的優點，應用也最廣泛。

    以上三種模式是從一個模組開始，測一次添一個模組，組裝程式類似於滾雪球，所以統稱為漸增式。三種模式都有各自的優缺點，綜合起來，混合模式正在與揚長避短，綜合了兩種模式的優點，建議多采用混合模式進行總裝。

    好的，本節到此結束，下一節將詳細介紹層次測試的第三步——確認測試。

經過了單元測試和整合測試的學習，組裝測試已經完成，接下來要進行的就是確認測試，那麼本節就主要介紹確認測試。確認測試又稱有效性測試或合格性測試，其任務是驗證系統的功能、效能等特性是否符合需求規格說明。如下圖：

   有效性測試和軟體配置審查是確認測試最重要的兩項工作。

   確認測試一般是在模擬的環境或者就是開發環境下運用黑盒測試法，按照需求說明書，驗證軟體功能、特性是否與使用者需求一致。經過確認測試後，可能有以下兩種情況：

1. 軟體的功能、效能及其他要求均已經滿足需求說明書，可能被認為是合格的軟體。
2. 發現軟體與需求說明書有較大的偏離，得到一個缺陷清單。這樣的錯誤，工作量非常大，往往很難在交付期以前把發現的缺陷修復過來。此時需要開發部門和使用者一起協商進行解決。

   軟體配置審查也稱配置審計，指軟體工程過程中所產生的所有資訊項：文件、報告、程式、表格、資料等。此階段主要複查SCI是否齊全，檢查軟體的所有文件資料的完整性和正確性，然後對發現的缺陷，進行修復，最後編排好目錄，以便後期維護順利進行。

   確認測試繼整合測試之後進行，其目的在於確認組裝完畢的程式是否滿足需求說明書。確認測試是由軟體開發單位組織實施的最後一項開發活動，測試結束後，軟體就交付驗收了，因此開發單位必須十分重視這項工作，和整合測試一樣，也應由獨立測試小組負責實施。

好的，本節到此結束，下一節將詳細介紹層次測試的第四步——系統測試。

經過了前面的總結，今天該到層次測試的最後一步——系統測試了，系統測試是驗收工作的一部分，應由使用者單位組織實施。軟體開發單位應該為系統測試創造良好的條件，負責回答和解決測試中可能發現的一切質量問題。

   系統測試是在更大範圍內進行測試。除被測試程式外，系統還可能包括硬體和原有的其他軟體。系統測試的目的在於把軟體產品順利安裝到系統中以後，保證軟體與系統其餘部分協調工作，並且符合軟體需求說明書的要求。

    下面說一下整合系統的測試，下圖是整合系統測試的測試內容：

         其中：

   功能測試主要檢查軟體功能是否符合需求說明的要求，基本方法是構造一些合理的輸入，檢查是否得到期望的輸出，假如輸入範圍是無限的，關鍵在於尋找等價區間，還有一種有效的測試方法就是邊界值測試，會在以後具體介紹。

   效能測試是用來測試軟體在整合系統中的執行效能，特別是針對實時系統和嵌入式系統，常常與強度測試結合起來進行。

   安全性測試是為了保證安裝在系統內的保護機制能在實際執行中保護系統不受非法侵入等非法行為的干擾，測試過程中需要設定一些測試用例試圖突破系統的安全保密措施，檢驗系統是否有安全保密的漏洞。

   恢復測試目的在於保證系統受到某些外部事故的破壞時能夠重新恢復正常工作，可以通過各種手段，強制性地使軟體出錯而不能正常工作，進而檢驗系統恢復能力。

   強度測試主要是在一些極限條件下，檢查軟體系統的執行情況，例如一些超常數量的輸入資料、超常數量的使用者、超常數量的網路連線，這對於瞭解軟體系統的效能和可靠性、健壯性具有十分重要的意義。

   文件測試主要檢查文件的正確性、完整性和可理解性。正確性指不要把軟體的功能和操作寫錯，也不允許文件內容前後矛盾；完整性是指文件不可以虎頭蛇尾，更不允許漏掉關鍵內容；可理解性指文件內容讓大眾使用者看得懂、能理解。

   到這裡，層次測試的所有階段都介紹完了，下一節將介紹軟體測試的經典方法黑盒測試中的部分內容，最後介紹一下終止測試的標準。

   軟體可以終止測試的標準有兩個，一個標準是規定測試策略和應達目標，例如，在白盒測試中，可以規定完全覆蓋為標準，即語句覆蓋和分支覆蓋率必須達到100%，滿足了這些條件就可以停止測試；在黑盒測試中，可以規定設計各種方法來設計測試用例，當所有測試用例全部用完時即可停止測試。另一個標準是規定至少要查出的錯誤數量，例如根據以往的測試經驗，估算系統中的缺陷數目，規定目標是消除95%的設計缺陷和98%的編碼與結構缺陷，則可以停止錯誤。

前面總結了軟體測試層次的各階段目標和任務等相關內容，接下來將總結軟體測試的經典方法，即黑盒測試和白盒測試。其中黑盒測試有等價分類、邊界值分析、錯誤推測和因果圖等經典分析方法，本節先介紹黑盒測試中的等價分類，也稱等價分配或等價劃分，即分步驟的把過多（無限）的測試案例減小到同樣有效的小範圍過程。

    其中，有效等價類中的任何一個測試測試用例都能代表同一等價類中的其他測試用例，即從某一個等價類中任意選出一個測試用例若未能發現程式的缺陷，就可以合理地認為使用程式中的其他測試用例也不會發現程式的缺陷；無效等價類中的每一個無效等價類至少要用一個測試用例，否則有可能漏掉某一類錯誤。

    劃分等價類有其一般步驟，下面我們就一個具體的例子來講解等價類劃分的具體步驟。

    具體問題：某軟體開發公司進行人員擴增，規定應聘人員的年齡在20週歲（1992年11月前出生）到35週歲（1977年11月後出生）之間，若出生年月不在以上範圍內，則拒絕面試，並顯示“年齡不合格”，請使用等價類劃分方法對這一程式功能設計測試用例。

    第一步：劃分等價類。現規定出生年月由6位數字字元表示，前4位代表年，後2位代表月份，則給出以下3個有效等價類和7個無效等價類，如下表:

    第二步：設計有效等價類的測試用例。在設計有效等價類測試用例前最好將所有等價類都先編號，如上圖，然後根據編號設計測試用例，使其儘可能多的覆蓋尚未被覆蓋的等價類，下面是設計的測試用例表：

    讓幾個等價類公用一個測試用例，可以減少測試次數，有利而無弊。

    第三步：為每一無效等價類至少設計一個測試用例。本例有7個無效等價類，則至少設計7個測試用例，假如少設計測試用例，就有可能產生遺漏。下面是無效測試用例。

    本程式的等價類劃分就算基本寫完了，學習時注意劃分的一般步驟，選擇測試用例時也要仔細斟酌，看是否在所要測試的等價類中。

   等價類劃分是一種典型的黑盒測試方法，也是一種非常實用的重要測試方法，作為一個合格的測試員，應具備劃分等價類併為其設計合理的測試用例的基本能力。

   好的，本節結束，下一講將總結黑盒測試的另一個經典方法——邊界值分析法，敬請期待！謝謝！

上一節講到了黑盒測試中的等價分類，這一節繼續總結黑盒測試又一經典測試方法——邊界值分析法，其實邊界值測試不是專屬於黑盒測試，在白盒測試中也會用到邊界值測試。     邊界值測試其實就是測試程式的各種邊界值，邊界值測試是等價分類的推廣，在實際測試中，在測試程式的邊界時，往往可以測試出很多缺陷，所以兩種方法要結合使用，才能更好的滿足程式的測試需求。邊界值測試分為兩部分：
        對於輸入測試，大家也許可以理解，但是對於輸出測試，大家可能理解起來有點困難了，說再多的道理不如舉幾個例子來說明道理，下面就和大家一起看下面的具體例項。     問題一：某超市出售某品牌的高階盒裝酸奶，現就元旦佳節開展促銷活動，該超市將按照顧客購買量進行不同力度的促銷，具體促銷方案如下：
      分析：我們能夠考慮到的邊界值是1，10，20，30，因為問題中已經詳細給出了邊界條件，其實我們應該還要考慮的邊界值還有0，9，19，29，31和無限大，具體測試用例如下：
    問題二：某保險公司人壽保險的保費計算方式為：     1.保險費=投保額*保險費     2.其中，保險費率根據投保人年齡、性別、婚姻狀況和撫養人數的不同而有所不用，體現在不同的上述條件下對應的點數設定不同，10點及10點以上保險費率為0.6%，10點以下保險費率為0.1，具體規則見下表：         分析：本例需要考慮的邊界值比較多。不僅需要考慮輸入邊界，還要考慮輸出邊界。其中輸入邊界有可以分為年齡邊界和撫養人數邊界，點數可以作為輸出邊界。     其中，年齡邊界有：0  1  19  20  39  40  59  60  90  100  無窮大         撫養人數邊界：0  1  6  7  9  10  無窮大                 點數：9  10  11      下面是一位老師總結的邊界值分析的原則：     1.如果輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界值以及剛剛超過這個範圍邊界的值作為測試輸入資料。     2.如果輸入條件規定了值的個數，則用最大個數，最小個數和比最大個數多一個，比最小個數少一個的數作為測試資料。     3.如果程式的規格說明給出輸入域或輸出域是有序集合，則應選取集合中的第一個和最後一個元素作為測試用例。     4.如果程式中使用了一個內部資料結構，則應當選擇這個內部資料結構邊界上的值作為測試用例。    當然原則還有好多，邊界值分析的最根本的理論就是剛好大於最大值，或者剛好小於最小值。抓住這個基本點，將問題逐個分類，才是做好邊界值測試的基本出發點。    這一節結束，下一節將總結錯誤推測法，敬請關注！謝謝！
三國中的諸葛亮能看破天象，對敵軍的破綻之處也更是瞭如指掌，死孔明嚇跑活仲達的笑話無人不知，無人不曉。作為軟體測試員就應該有孔明先生這樣的本領，測試員能該把軟體當作自己的敵人，兵法雲知己知彼方能百戰不殆。本節將總結黑盒測試中的又一常用方法——錯誤推測法。     在錯誤推測法中，測試員的角色就相當於三國中孔明的角色，測試員要根據自己的經驗，預測出軟體中哪些地方容易出現缺陷，我們應該怎樣發現缺陷，確保缺陷得以修復。     常見的輸入與輸出錯誤推測情況：
      以下是一個軟體測試教師總結的經驗，現分享給大家。   經驗分享一：時間性測試           1.提交操作時限           2.未到達的日期是否可選擇           3.前後時間限制問題           4.系統時間的調整是否影響軟體的使用許可權 經驗分享二：密碼輸入框           1.密碼明文顯示（超級使用者）           2.複製密碼，明文顯示           3.截斷（字元長度限制）：Ctrl+V，滑鼠           4.限制 經驗分享三：配置檔案安全性 經驗分享四：密寬窄屏缺陷 經驗分享五：同時操作問題           1.在不同機器上同時登陸同一使用者           2.對一條記錄在不同機器上進行不同操作（修改、刪除）           解決方法一：鎖定記錄 解決方法二：給出提示資訊           3.一人稽核，一人退回           4.兩個人修改同一張工單 經驗分享六：刪除為空時缺陷 經驗分享七：自動重新整理問題 1.是否具有自動重新整理           2.區域性重新整理與全部重新整理           3.重新整理過程中出現解析度下降等問題
經驗分享八：網頁安全缺陷           已登陸使用者地址複製給其他使用者，其他使用者連線時是否顯示歡迎介面 經驗分享九：判斷順序/邏輯缺陷 經驗分享十：使用者管理           1.超級使用者，忘記刪除           2.超級使用者，回收許可權 經驗分享十一：聊天視窗功能           1.輸入特殊字元後，視窗是否能夠正常顯示           2.輸入空格，是否能夠過濾，是否會算入長度計算           3.輸入html字元           4.輸入指令碼語言函式           5.圖片頭像顯示           6.在需要密碼驗證，或者需要二次輸入確認的地方，通過複製貼上第一次的輸入內容是否能             夠通過 經驗分享十二：查詢功能           1.無條件查詢           2.是否支援模糊查詢           3.查詢的關鍵字之間是否可用連線符           4.是否支援空格           5.是否支援各類字元 經驗分享十三：翻頁功能           1.首頁、上一頁、下一頁、尾頁           2.總頁數、當前頁數           3.指定跳轉頁           4.指定每頁顯示條數 經驗分享十四：刪除功能           1.不選擇記錄，進行刪除，驗證提示資訊“請選擇記錄”           2.刪除記錄許可權驗證           3.刪除結果檢查           4.刪除成功後，再次新增相同記錄，應可成功新增 經驗分享十五：匯入/匯出/列印問題 匯入：
          1.模版內容是否與系統一致           2.模版中是否有必填項、欄位長度等限制           3.匯入時格式不匹配的校驗，提示資訊是否準確           4.匯入兩條相同資料是否提示重複匯入           5.匯入後驗證系統中內容是否正確           6.批量匯入時，容量上限的驗證、個數驗證 匯出：           1.表頭、圖示是否顯示正確           2.檔名顯示有規則和實際意義           3.匯出後資訊驗證 這一節開始總結黑盒測試中的最後一種方法——因果圖法，說到因果圖法，就不能不說決策表法（也稱判定表法），因為這兩種方法經常聯用，經驗豐富的測試員有時跳過因果圖的設計，直接設計決策表，決策表法也是最嚴格也最具有邏輯性的測試方法。下面先介紹一下因果圖的基礎知識。 如果輸入輸出比較多，輸入之間和輸出之間相互制約的條件比較多，在這種情況下應用因果圖法設計決策表很合適。因果圖是一種形式化語言，是一種組合邏輯網路圖，它把輸入條件視為因，把輸入或程式狀態的改變視為果，將黑盒看成是從因到果的網路圖，採用邏輯圖的形式來表達功能說明書中輸入條件的各種組合與輸出的關係，最終生成決策表，寫出相應的測試用例。        因果圖的基本符號：                   因果圖的一些限制符號：  
         因果圖繪製的一般步驟：          1.提取因果，賦予識別符號          2.提取因果關係，表示因果圖          3.標明約束條件     做完因果圖就要轉換成判定表，做判定表的一般步驟：          1.抽象出所有的條件類和動作類          2.確定規則的個數          3.填入條件項          4.簡化（合併類似規則或相同動作）      繪製決策表的一般步驟不固定，假如測試員經驗豐富，可以提前簡化。下面是一個簡單的具體例項，建議讀者先根據以上知識先自行設計因果圖和決策表，然後再與下面的對比，你可能設計的會更好。     問題：某公司要求，對功率大於50馬力且維修記錄不全或已執行10年以上的機器，應給予優先的維修處理，請根據需求運用因果圖法設計測試用例。     因果圖：         a：功率大於50馬力      b：維修記錄不全    c：執行10年以上                    d：優先維修                 e:其他處理
     最初決策表：
        簡化後決策表：
         測