軟體測試基礎知識
基本概念
-
軟體測試
在規定條件下對程式進行操作，以發現錯誤，對軟體品質進行評估，包括對軟體形成過程的文檔、資料以及程式進行測試
- 軟體測試的目的
- 發現程式中存在的錯誤 發現程式中存在的錯誤，而不是證明程式無錯誤。一個好的測試用例在于它能發現至今尚未發現的錯誤。一個成功的測試則是發現了至今未發現的錯誤。開始我們認為做測試無非是為了證明我們編的程式是無錯誤的，那是大錯特錯了。因為bug會因時間不同，條件不同而出現。永遠無法證明我們的程式是絕對正确的。
- 為回報資訊做準備 為開發者或軟體項目經理提供回報資訊，以及為風險評估所準備的資訊
- 軟體測試的原則
- 所有的測試都應追溯到使用者需求。因為軟體的目的是使使用者完成預定的任務，滿足其需求，而軟體測試揭示軟體的缺陷和錯誤，一旦修正這些錯誤就能更好地滿足使用者需求。
- 應盡早地和不斷地進行軟體測試。由于軟體的複雜性和抽象性，在軟體生命周期各階段都可能産生錯誤，是以不應把軟體測試僅僅看作是軟體開發的一個獨立階段，而應當把它貫穿到軟體開發的各個階段去。在需求分析和設計階段就應開始進行測試工作，編寫相應的測試計劃及測試設計文檔，同時堅持在開發各階段進行技術評審和驗證，這樣才能盡早發現和預防錯誤，杜絕某些缺陷和錯誤，提高軟體品質，測試工作進行得越早，越有利于提高軟體的品質，這是預防性測試的基本原則。
- 在有限的時間和資源下進行完全測試，找出軟體所有的錯誤和缺陷是不可能的，軟體測試不能無限進行下去，應适時終止。因為，測試輸入量大、輸出結果多、路徑組合太多，用有限的資源來達到完全測試是不現實的。
- 測試隻能證明軟體存在錯誤而不能證明軟體沒有錯誤。測試是無法顯示潛在的錯誤和缺陷，繼續進一步錯誤可能還會找到其它錯誤和缺陷。
- 充分關注測試中的叢集現象。在測試的程式段中，若發現的錯誤數目多，則殘存在其中的錯誤也越多，是以應當花較多的時間和代價測試那些具有更多錯誤數目的程式子產品。
- 程式員應避免檢查自己的程式。考慮到人們的心理因素，自己揭露自己程式中的錯誤是件不愉快的事，自己不願意否認自己的工作;另一方面，由于思維定勢，自己難以發現自己的錯誤。是以，測試一般由獨立的測試部門或第三方機構進行。
- 盡量避免測試的随意性。軟體測試是有組織、有計劃、有步驟的活動，要嚴格按照測試計劃進行，要避免測試的随意性。
-
軟體測試對象
程式開發過程中的各個文檔、源程式、目标程式及資料
- 軟體測試的模型
- 測試是開發之後的一個階段。
- 測試的對象就是程式本身。
- 實際應用中容易導緻需求階段的錯誤一直到最後系統測試階段才被發現。
- 整個軟體産品的過程品質保證完全依賴于開發人員的能力和對工作的責任心，而且上一步的結果必須是充分和正确的，如果任何一個環節出了問題，則必将嚴重的影響整個工程的品質和預期進度
- V模型
- 從左到右，描述了基本的開發過程和測試行為，非常明确地标明了測試過程中存在的不同級别，并且清楚地描述了這些測試階段和開發過程期間各階段的對應關系 。
- 左邊依次下降的是開發過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。
- V模型問題：
- W模型 相對于V模型，W模型更科學。W模型是V模型的發展，強調的是測試伴随着整個軟體開發周期，而且測試的對象不僅僅是程式，需求、功能和設計同樣要測試。測試與開發是同步進行的，進而有利于盡早地發現問題。 W模型也有局限性。W模型和V模型都把軟體的開發視為需求、設計、編碼等一系列串行的活動，無法支援疊代、自發性以及變更調整。
軟體測試的流程
-
需求評審
閱讀需求、了解需求及了解需求
-
測試計劃
根據需求估算測試所需資源（人力、裝置等）、所需時間、功能點劃分、如何合理配置設定安排資源等。
-
用例設計
根據測試計劃、任務配置設定、功能點劃分，設計合理的測試用例。
-
執行測試
根據測試用例的詳細步驟，執行測試用例。
常見的用例設計方法
-
黑盒測試用例設計方法
邊界值分析和等價類劃分的一個弱點是未對輸入條件的組合進行分析。
- 将規格說明書分解為可執行的片段。
- 确定規格說明中的因果關系。
- 分析規格說明的語義内容，并将其轉換為連接配接因果關系的布爾圖。
- 給圖加上注解符号，說明由于文法或環境的限制而不能聯系起來的“因”和“果”。
- 将因果圖轉換為判定表。
- 将判定表轉換為測試用例。
- 因果圖
- 定義 因果圖法是一種适合于描述對于多種輸入條件組合的測試方法，根據輸入條件的組合、限制關系和輸出條件的因果關系，分析輸入條件的各種組合情況，進而設計測試用例的方法，它适合于檢查程式輸入條件涉及的各種組合情況。因果圖法着重分析輸入條件的各種組合，每種組合條件就是“因”，它必然有一個輸出的結果，這就是“果”。
- 利用因果圖生成測試用例的步驟。
- 邊界值分析不是從某等價類中随便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。
- 邊界值分析不僅考慮輸入條件，還要考慮輸出空間産生的測試情況。
- 在輸入條件規定的取值範圍或值的個數的情況下，可以确定一個有效 等價類和兩個無效等價類。
- 在規定了輸入資料的一組值中（假定有n個值），并且程式要對每個輸 入值分别處理的情況下，可以确定n個有效等價類和一個無效等價類。
- 在規定輸入資料必須遵守的規則的情況下，可以确定一個有效等價類 和若幹個無效等價類。
- 在輸入條件規定了輸入值的集合或規定了“必須如何”的條件下，可以确定一個有效等價類和一個無效等價類。
- 在确定已劃分的等價類中各元素在程式進行中的方式不同的情況下，則應将該等價類進一步地劃分為更小的等價類。
- 按區間劃分。
- 按數值劃分。
- 按數值集合劃分。
- 按限制條件或規劃劃分。
- 按處理方式劃分。
- 等價劃分
- 定義 等價類劃分法是一種典型的、重要的黑盒測試方法，它将程式所有可能的輸入資料（有效的和無效的）劃分成若幹個等價類。然後從每個部分中選取具有代表性的資料當做測試用例進行合理的分類，測試用例由有效等價類和無效等價類的代表組成，進而保證測試用例具有完整性和代表性。利用這一方法設計測試用例可以不考慮程式的内部結構，以需求規格說明書為依據，選擇适當的典型子集，認真分析和推敲說明書的各項需求，特别是功能需求，盡可能多地發現錯誤。等價類劃分法是一種系統性的确定要輸入的測試條件的方法。
- 有效等價類 有效等價類指對于程式規格說明來說，是合理的、有意義的輸入資料構成的集合。利用有效等價類可以檢驗程式是否實作了規格說明預先規定的功能和性能。有效等價類可以是一個，也可以是多個，根據系統的輸入域劃分若幹部分，然後從每個部分中選取少數有代表性資料當做資料測試的測試用例，等價類是輸入域的集合。
- 無效等價類 無效等價類和有效等價類相反，無效等價類是指對于軟體規格說明而言，沒有意義的、不合理的輸入資料集合。利用無效等價類，可以找出程式異常說明情況，檢查程式的功能和性能的實作是否有不符合規格說明要求的地方。
- 等價類劃分的方法
- 等價類劃分的原則
- 邊界值分析
- 定義 邊界值是指輸入和輸出等價類中哪些恰好處于邊界、或超過邊界、或在邊界以下的值、
- 與等價類劃分方法的不同
- 白盒測試用例設計方法
- 語句覆寫（SC）
- 判定覆寫（DC）
- 條件覆寫（CC）
- 判定/條件覆寫（DCC）
- 條件組合覆寫（CMC）
- 路徑覆寫
常見的測試方法和類型
- 按代碼的可見程度劃分
- 黑盒測試 黑盒測試又稱為資料驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程式内部結構和處理過程的情況下，測試者僅依據程式功能的需求規範考慮，确定測試用例和推斷測試結果的正确性，它是站在使用軟體或程式的角度，從輸入資料與輸出資料的對應關系出發進行的測試。
- 白盒測試 白盒測試又稱為結構測試或邏輯驅動測試，是一種按照程式内部邏輯結構和編碼結構，設計測試資料并完成測試的一種測試方法。
- 灰盒測試 灰盒測試是一種綜合測試法，它将“黑盒”測試與“白盒”測試結合在一起，是基于程式運作時的外部表現又結合内部邏輯結構來設計用例，執行程式并采集路徑執行資訊和外部使用者接口結果的測試技術。
- 按項目流程階段劃分
- 單元測試 單元測試又稱子產品測試，是針對軟體設計的最小機關----程式子產品或功能子產品，進行正确性檢驗的測試工作。其目的在于檢驗程式各子產品是否存在各種差錯，是否能正确地實作了其功能，滿足其性能和接口要求。
- 內建測試 內建測試又叫組裝測試或聯合，是單元測試的多級擴充，是在單元測試的基礎上進行的一種有序測試。目的是檢查軟體機關之間的接口是否正确。
- 系統測試 系統測試是對已經內建好的軟體系統進行徹底的測試，以驗證軟體系統的正确性和性能等是否滿足其規約所指定的要求。
- 驗收測試 驗收測試是部署軟體之前的最後一個測試操作。驗收測試的目的是確定軟體準備就緒，向軟體購買者展示該軟體系統滿足其使用者的需求。
- 按執行過程是否需要人工幹預劃分
- 手工測試 手工測試就是由人去一個一個的去執行測試用例，通過鍵盤滑鼠等輸入一些參數，檢視傳回結果是否符合預期結果。
- 自動化測試 自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例并通過評審之後，由測試人員根據測試用例中描述的規程一步步執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬體資源，提高測試效率，便引入了自動化測試的概念。 自動化測試：又可分為功能自動化測試與性能自動化測試。 我們一般所說的自動化測試就是指功能自動化測試，通過相關的測試技術，通過編碼的方式用一段程式來測試一個軟體的功能，這樣就可以重複執行程式來進行重複的測試。如果一個軟體一小部分發生改變，我們隻要修改一部分代碼，就可以重複的對整個軟體進行功能測試。這樣就大大的提高了測試效率。 性能自動化測試，當然，除了早期階段，現在的性能測試工作都是通過性能測試工具輔助完成的。能過工具可以模拟成千上萬的使用者向系統發送請求，用來驗證系統的處理能力。
- 其他測試方法
- 冒煙測試 冒煙測試是指在對一個新版本進行系統大規模的測試之前，先驗證一下軟體的基本功能是否實作，是否具備可測性。
- 回歸測試 回歸測試是指修改了舊代碼後，重新時行測試以确認修改後沒有引入新的錯誤或導緻其他代碼産生錯誤。
- 随機測試 是指測試中的所有輸入資料都是随機生成的，其目的是模拟使用者的真實操作，并發現一些邊緣性的錯誤。
- 壓力測試、負載測試及性能測試 壓力測試：驗證軟體在超過負載設計的情況下仍能傳回正确的結果，沒有崩潰負載測試：測試軟體在負載情況下能否正常工作 性能測試：測試軟體的性能，是否提供滿意的服務品質
最後:【可能給予你助力的教程】
