軟體測試基礎知識

軟體測試基礎知識

基本概念

• 軟體測試

  在規定條件下對程式進行操作，以發現錯誤，對軟體質量進行評估，包括對軟體形成過程的文件、資料以及程式進行測試

• 軟體測試的目的

  • 發現程式中存在的錯誤 發現程式中存在的錯誤，而不是證明程式無錯誤。一個好的測試用例在於它能發現至今尚未發現的錯誤。一個成功的測試則是發現了至今未發現的錯誤。開始我們認為做測試無非是為了證明我們編的程式是無錯誤的，那是大錯特錯了。因為 bug 會因時間不同，條件不同而出現。永遠無法證明我們的程式是絕對正確的。
  • 為反饋資訊做準備 為開發者或軟體專案經理提供反饋資訊，以及為風險評估所準備的資訊

• 軟體測試的原則

  • 所有的測試都應追溯到使用者需求。因為軟體的目的是使使用者完成預定的任務，滿足其需求，而軟體測試揭示軟體的缺陷和錯誤，一旦修正這些錯誤就能更好地滿足使用者需求。
  • 應儘早地和不斷地進行軟體測試。由於軟體的複雜性和抽象性，在軟體生命週期各階段都可能產生錯誤，所以不應把軟體測試僅僅看作是軟體開發的一個獨立階段，而應當把它貫穿到軟體開發的各個階段去。在需求分析和設計階段就應開始進行測試工作，編寫相應的測試計劃及測試設計文件，同時堅持在開發各階段進行技術評審和驗證，這樣才能儘早發現和預防錯誤，杜絕某些缺陷和錯誤，提高軟體質量，測試工作進行得越早，越有利於提高軟體的質量，這是預防性測試的基本原則。
  • 在有限的時間和資源下進行完全測試，找出軟體所有的錯誤和缺陷是不可能的，軟體測試不能無限進行下去，應適時終止。因為，測試輸入量大、輸出結果多、路徑組合太多，用有限的資源來達到完全測試是不現實的。
  • 測試只能證明軟體存在錯誤而不能證明軟體沒有錯誤。測試是無法顯示潛在的錯誤和缺陷，繼續進一步錯誤可能還會找到其它錯誤和缺陷。
  • 充分關注測試中的叢集現象。在測試的程式段中，若發現的錯誤數目多，則殘存在其中的錯誤也越多，因此應當花較多的時間和代價測試那些具有更多錯誤數目的程式模組。
  • 程式設計師應避免檢查自己的程式。考慮到人們的心理因素，自己揭露自己程式中的錯誤是件不愉快的事，自己不願意否認自己的工作;另一方面，由於思維定勢，自己難以發現自己的錯誤。因此，測試一般由獨立的測試部門或第三方機構進行。
  • 儘量避免測試的隨意性。軟體測試是有組織、有計劃、有步驟的活動，要嚴格按照測試計劃進行，要避免測試的隨意性。

• 軟體測試物件

  程式開發過程中的各個文件、源程式、目標程式及資料

• 軟體測試的模型

  • V 模型
  • 從左到右，描述了基本的開發過程和測試行為，非常明確地標明瞭測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係 。
  • 左邊依次下降的是開發過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。
  • V 模型問題：
    • 測試是開發之後的一個階段。
    • 測試的物件就是程式本身。
    • 實際應用中容易導致需求階段的錯誤一直到最後系統測試階段才被發現。
    • 整個軟體產品的過程質量保證完全依賴於開發人員的能力和對工作的責任心，而且上一步的結果必須是充分和正確的，如果任何一個環節出了問題，則必將嚴重的影響整個工程的質量和預期進度
  • W 模型 相對於 V 模型，W 模型更科學。W 模型是 V 模型的發展，強調的是測試伴隨著整個軟體開發週期，而且測試的物件不僅僅是程式，需求、功能和設計同樣要測試。測試與開發是同步進行的，從而有利於儘早地發現問題。 W 模型也有侷限性。W 模型和 V 模型都把軟體的開發視為需求、設計、編碼等一系列序列的活動，無法支援迭代、自發性以及變更調整。

軟體測試的流程

• 需求評審

  閱讀需求、理解需求及瞭解需求

• 測試計劃

  根據需求估算測試所需資源（人力、裝置等）、所需時間、功能點劃分、如何合理分配安排資源等。

• 用例設計

  根據測試計劃、任務分配、功能點劃分，設計合理的測試用例。

• 執行測試

  根據測試用例的詳細步驟，執行測試用例。

常見的用例設計方法

• 黑盒測試用例設計方法

  • 等價劃分
  • 定義 等價類劃分法是一種典型的、重要的黑盒測試方法，它將程式所有可能的輸入資料（有效的和無效的）劃分成若干個等價類。然後從每個部分中選取具有代表性的資料當做測試用例進行合理的分類，測試用例由有效等價類和無效等價類的代表組成，從而保證測試用例具有完整性和代表性。利用這一方法設計測試用例可以不考慮程式的內部結構，以需求規格說明書為依據，選擇適當的典型子集，認真分析和推敲說明書的各項需求，特別是功能需求，儘可能多地發現錯誤。等價類劃分法是一種系統性的確定要輸入的測試條件的方法。
  • 有效等價類 有效等價類指對於程式規格說明來說，是合理的、有意義的輸入資料構成的集合。利用有效等價類可以檢驗程式是否實現了規格說明預先規定的功能和效能。有效等價類可以是一個，也可以是多個，根據系統的輸入域劃分若干部分，然後從每個部分中選取少數有代表性資料當做資料測試的測試用例，等價類是輸入域的集合。
  • 無效等價類 無效等價類和有效等價類相反，無效等價類是指對於軟體規格說明而言，沒有意義的、不合理的輸入資料集合。利用無效等價類，可以找出程式異常說明情況，檢查程式的功能和效能的實現是否有不符合規格說明要求的地方。
  • 等價類劃分的方法
    • 按區間劃分。
    • 按數值劃分。
    • 按數值集合劃分。
    • 按限制條件或規劃劃分。
    • 按處理方式劃分。
  • 等價類劃分的原則
    • 在輸入條件規定的取值範圍或值的個數的情況下，可以確定一個有效 等價類和兩個無效等價類。
    • 在規定了輸入資料的一組值中（假定有 n 個值），並且程式要對每個輸 入值分別處理的情況下，可以確定 n 個有效等價類和一個無效等價類。
    • 在規定輸入資料必須遵守的規則的情況下，可以確定一個有效等價類 和若干個無效等價類。
    • 在輸入條件規定了輸入值的集合或規定了 “必須如何” 的條件下，可以確定一個有效等價類和一個無效等價類。
    • 在確定已劃分的等價類中各元素在程式處理中的方式不同的情況下，則應將該等價類進一步地劃分為更小的等價類。
  • 邊界值分析
  • 定義 邊界值是指輸入和輸出等價類中哪些恰好處於邊界、或超過邊界、或在邊界以下的值、
  • 與等價類劃分方法的不同
    • 邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。
    • 邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況。

  邊界值分析和等價類劃分的一個弱點是未對輸入條件的組合進行分析。

  • 因果圖
  • 定義 因果圖法是一種適合於描述對於多種輸入條件組合的測試方法，根據輸入條件的組合、約束關係和輸出條件的因果關係，分析輸入條件的各種組合情況，從而設計測試用例的方法，它適合於檢查程式輸入條件涉及的各種組合情況。因果圖法著重分析輸入條件的各種組合，每種組合條件就是 “因”，它必然有一個輸出的結果，這就是 “果”。
  • 利用因果圖生成測試用例的步驟。
    • 將規格說明書分解為可執行的片段。
    • 確定規格說明中的因果關係。
    • 分析規格說明的語義內容，並將其轉換為連線因果關係的布林圖。
    • 給圖加上註解符號，說明由於語法或環境的限制而不能聯絡起來的 “因” 和 “果”。
    • 將因果圖轉換為判定表。
    • 將判定錶轉換為測試用例。

• 白盒測試用例設計方法

  • 語句覆蓋（SC）
  • 判定覆蓋（DC）
  • 條件覆蓋（CC）
  • 判定/條件覆蓋（DCC）
  • 條件組合覆蓋（CMC）
  • 路徑覆蓋

常見的測試方法和型別

• 按程式碼的可見程度劃分

  • 黑盒測試 黑盒測試又稱為資料驅動測試，把測試物件當做看不見的黑盒，在完全不考慮程式內部結構和處理過程的情況下，測試者僅依據程式功能的需求規範考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟體或程式的角度，從輸入資料與輸出資料的對應關係出發進行的測試。
  • 白盒測試 白盒測試又稱為結構測試或邏輯驅動測試，是一種按照程式內部邏輯結構和編碼結構，設計測試資料並完成測試的一種測試方法。
  • 灰盒測試 灰盒測試是一種綜合測試法，它將 “黑盒” 測試與 “白盒” 測試結合在一起，是基於程式執行時的外部表現又結合內部邏輯結構來設計用例，執行程式並採集路徑執行資訊和外部使用者介面結果的測試技術。

• 按專案流程階段劃分

  • 單元測試 單元測試又稱模組測試，是針對軟體設計的最小單位 ---- 程式模組或功能模組，進行正確性檢驗的測試工作。其目的在於檢驗程式各模組是否存在各種差錯，是否能正確地實現了其功能，滿足其效能和介面要求。
  • 整合測試 整合測試又叫組裝測試或聯合，是單元測試的多級擴充套件，是在單元測試的基礎上進行的一種有序測試。目的是檢查軟體單位之間的介面是否正確。
  • 系統測試 系統測試是對已經整合好的軟體系統進行徹底的測試，以驗證軟體系統的正確性和效能等是否滿足其規約所指定的要求。
  • 驗收測試 驗收測試是部署軟體之前的最後一個測試操作。驗收測試的目的是確保軟體準備就緒，向軟體購買者展示該軟體系統滿足其使用者的需求。

• 按執行過程是否需要人工干預劃分

  • 手工測試 手工測試就是由人去一個一個的去執行測試用例，透過鍵盤滑鼠等輸入一些引數，檢視返回結果是否符合預期結果。
  • 自動化測試 自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例並透過評審之後，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬體資源，提高測試效率，便引入了自動化測試的概念。 自動化測試：又可分為功能自動化測試與效能自動化測試。 我們一般所說的自動化測試就是指功能自動化測試，透過相關的測試技術，透過編碼的方式用一段程式來測試一個軟體的功能，這樣就可以重複執行程式來進行重複的測試。如果一個軟體一小部分發生改變，我們只要修改一部分程式碼，就可以重複的對整個軟體進行功能測試。這樣就大大的提高了測試效率。 效能自動化測試，當然，除了早期階段，現在的效能測試工作都是透過效能測試工具輔助完成的。能過工具可以模擬成千上萬的使用者向系統傳送請求，用來驗證系統的處理能力。

• 其他測試方法

  • 冒煙測試 冒煙測試是指在對一個新版本進行系統大規模的測試之前，先驗證一下軟體的基本功能是否實現，是否具備可測性。
  • 迴歸測試 迴歸測試是指修改了舊程式碼後，重新時行測試以確認修改後沒有引入新的錯誤或導致其他程式碼產生錯誤。
  • 隨機測試 是指測試中的所有輸入資料都是隨機生成的，其目的是模擬使用者的真實操作，並發現一些邊緣性的錯誤。
  • 壓力測試、負載測試及效能測試 壓力測試：驗證軟體在超過負載設計的情況下仍能返回正確的結果，沒有崩潰 負載測試：測試軟體在負載情況下能否正常工作 效能測試：測試軟體的效能，是否提供滿意的服務質量