軟體測試探祕：從各類軟體測試入門，領略測試的奧祕
前言
在軟體開發的世界中，軟體測試是不可或缺的一部分。它是確保軟體質量、功能完整性和使用者滿意度的關鍵環節。本文小編將為大家介紹各類軟體測試的奧祕，並提供入門級的指導和見解。
本文內容概要：
- 軟體測試是什麼？
- 黑箱測試vs白盒測試
- 自動化測試vs手工測試
- 功能測試方法論
- 非功能測試方法論
- 軟體測試生命週期
- 軟體測試最佳實踐
軟體測試是什麼？
軟體測試是在開發流程中被開發者用來持續地評估和糾正特性的功能性的一個迴圈進行的步驟。軟體測試比對軟體的當前構建和軟體需求，以確認沒有疏漏的需求。同樣需要驗證的是，軟體在跨越不同媒介時、與現有軟體整合時執行正確。
軟體測試是如何運作的？
測試軟體有不少辦法。通常來講，開發者首先決定一個需要驗證的行為或者特性，建立一個測試來確認特性，接著要麼修改特性，要麼通過測試就直接繼續後面事情了。
在早期軟體設計哲學中，測試經常完全被忽視。現在軟體已經變得更加複雜，在更大規模被實現，而且在不同裝置與作業系統間各不相同。現代的開發週期中，軟體測試已經是必要的部分了。它扮演著QA一種不斷髮展的形式，驗證軟體可以對各種可能的使用場景和環境正常響應。
黑箱測試vs白盒測試
軟體測試有很多不同型別,每種型別在測試中專攻特定的缺陷。所有的測試型別可以寬泛描述為黑盒或白盒測試。這個區分描述軟體測試人員需要掌握的背景知識。
黑箱測試：測試人員知道軟體產品應該實現什麼而不知道是如何實現的。測試人員僅僅目睹了程式設計的結果或行為，他們自己不必成為程式設計師。測試人員經常是開發步驟外部的某些人，給出外部的觀點。黑箱測試主要用於測試程式行為和評估使用者體驗。
白盒測試：白盒測試是黑箱測試的反面，測試人員的確知道軟體的內部結構。這些測試人員通過特性測試用例輸入的使用來評估原始碼裡面程式的邏輯。通過追蹤這些輸入的流動，測試人員可以驗證這些測試用例在螢幕背後被正確處理。白盒測試人員常常是開發步驟內的程式設計師，他們被用於檢查原始碼的效率。
手工測試vs自動化
測試方法另一個主要分類是手工測試vs自動化測試。很多特定測試方法論可以同時被手工或自動化測試完成。這個區別描述測試是如何被完成的。
手工測試：
手工測試需要一個人類測試人員來扮演終端使用者的角色，一次檢查一個測試用例。這是測試的傳統形式，可以找到自動化測試框架難以識別的問題（web應用元素的表現，令人困惑的佈局等）。
自動化測試
自動化測試（或測試自動化）是使用軟體的步驟，呼叫一個測試框架來建立使用期望輸出對比當前程式輸出的自動的測試用例。最常見的框架是Selenium和Cucumber。
自動測試框架的兩個最常見的測試步驟是圖形使用者介面測試和API測試，前者模擬諸如點選或按鍵的使用者介面事件，後者繞開使用者介面來驗證底層行為。自動化測試被用於快速執行輸出驅動的測試或者為維護測試執行重複的測試用例。
功能測試方法論
現在我們將會討論通過更加廣泛型別區分的測試方法論，功能測試或非功能測試。這個區別描述測試關注的是軟體行為還是內部運作。
功能測試
黑盒QA測試的一種型別測試的是從軟體需求和說明書生成的測試用例。下方是不同功能測試方法論的一些常見型別。
最常見的功能方法論：
- 單元測試
- 整合測試
- 系統測試
- 驗收測試
- 迴歸測試
- 冒煙測試
常見功能測試步驟
絕大多數基礎測試經歷同樣的四步，每個步驟測試範圍更加寬廣。步驟始於評估單一元件的單元測試，終於評估產品和初始計劃關聯性的驗收測試。
單元測試：
單元測試被用於測試和其他元件分離開的程式元件。舉個例子，物件導向程式中，你會在嘗試連線到其他類前單元測試一個單獨的類。這種型別的測試經常是開發者完成的，用於在無需等待完整測試周期下捕捉缺陷。單元測試絕大多數情況是自動執行的，用於快速獲取到結果，但是也能手動進行。
整合測試：
整合測試用於測試諸多互相連線的程式元件的協同執行。這個測試經常是在單元測試後進行的，首先獨立驗證單一元件，然後驗證元件協同的執行。
舉個例子，你可以整合測試一個父類別和兩個關聯子類來確保測試用於所有預期屬性的用例的輸入被分配給預期的類。整合測試，通常都是自動化的測試，是開發者完成的，用於驗證互相關聯的元件無縫銜接。
系統測試：
系統測試是一起使用所有元件來測試完整產品的構建的。當整合測試測試了互相連線的元件的模組後，系統測試測試所有元件整合後程式如何運作，並且在模組內部操作中捕捉缺陷。
驗收測試：
驗收測試（或使用者驗收測試）是一個在開發過程後期執行的，用來評估是否所有初始的特定需求是被最終產品構建滿足的測試。內部和外部測試者都要評審初始產品說明書和業務需求，然後當他們使用產品時候逐一檢查。使用最常見的apha測試（內部）和beta測試（外部）去做驗收測試有很多途徑。
專門的功能方法論
在上面步驟之外去測試一個程式的特定層面，也有經過微調的功能測試手段。下面是最常見的專門的功能方法論
迴歸測試
迴歸測試是在一個更新或改變後用於測試產品整合性的手段。迴歸測試套件要麼在整個程式，要麼僅僅在程式變了的部分執行自動測試。套件接著把輸出和早期產品構建記錄的輸出進行比對。如果輸出是匹配的，那麼測試成功。如果它們以預期方式改變了，那麼測試驗證了功能有迴歸或還原。
迴歸測試是維護測試最常見的形式，因為其檢查程式釋出後表現如何。迴歸測試可以被定期執行來提供持續測試。
冒煙測試
冒煙測試（Smoke Testing）是軟體測試中的一種測試方法，旨在快速驗證系統的基本功能是否正常工作，以確保軟體在進入更詳細的測試階段之前是可用的。
冒煙測試通常在軟體構建或釋出後的早期階段進行，它會對軟體的核心功能進行一系列的簡單測試，以發現可能的嚴重問題或錯誤。這些測試通常是預先定義的基本功能測試用例，涵蓋了軟體的主要功能點。
冒煙測試的目標是在系統經過基本構建之後，對其進行表面層次的測試，以確保沒有明顯的錯誤或問題。如果冒煙測試失敗，即發現了關鍵功能的嚴重問題，那麼可能需要回退到先前的開發階段並解決問題，以避免在後續的詳細測試中浪費時間和資源。
冒煙測試的優點包括：
- 快速驗證：冒煙測試可以在短時間內快速驗證軟體的基本功能，幫助發現可能的嚴重問題。
- 提早發現問題：通過在早期階段發現問題，可以節省後續測試階段的時間和資源。
- 提高軟體質量：通過確保軟體的基本功能正常工作，可以提高軟體的質量和穩定性。
非功能測試方法
非功能測試方法測試一個程式如何執行，而不是特定程式表現的成功執行，舉個例子，一個非功能測試可能測試的是一個程式在更大規模下如何的執行良好或者當系統執行很長一段時間後表現如何。由於非功能測試定義的主體性，很多非功能測試方法論關注點有所重疊。
常見非功能測試方法論：
- 效能測試
- 安全測試
- 可用性測試
- 相容性測試
- 壓力測試
讓我們深入瞭解下這些方法論
效能測試：
效能測試是測試的一種常見形式，評估在預設負載下軟體的執行速度、響應和可靠性等。如果軟體正常執行，但是在這些分類裡面任意一個沒有滿足期望標準，在繼續其軟體開發週期前，軟體將會把打回開發者去提升效能。
安全測試：
安全測試被用於在使用了諸如基於賬號的系統或金融系統軟體的敏感資訊的資訊系統或軟體中尋找缺點。下面是安全測試中的一些要求：
- 保密性：敏感資訊是受約束的。
- 完整性：資料不能被拷貝或修改。
- 認證：使用者比如被驗證為是期望的使用者。
- 鑑權：使用者必須擁有許可權來檢視敏感資訊。
- 可用性：當授權使用者需要資訊時，必須是可用的。
- 不可否認性：通訊兩端的使用者在發生通訊前必須校驗各自憑證
易用性測試：
易用性測試用於識別真正的終端使用者會在哪裡遇到困難或困惑。這個主要是在研究者觀察下由一群受控的終端使用者進行的。測試者被要求去執行特定任務，比如「建立一個賬號」，但是卻沒有被告訴怎麼去完成。他們然後使用產品來完成任務並給出關於體驗的高質量反饋。這個方法論允許開發者獲取到關於他們程式可用性和直觀反應的真實反饋，並且無需很多的說明。
這個與a11y測試聯絡緊密，a11y測試記錄能力各不相同的終端使用者能多容易地操作軟體。舉個例子，文字轉語音軟體和web應用的視覺化元素的互動如何。
相容性測試：
相容性測試評估在不同計算環境下軟體表現如何。這個通常使用一個測試框架完成的。這種框架使用模擬不同目標裝置的很多虛擬機器器器來執行同樣的輸入。每個VM的輸出被記錄和比對，以確認是否所有輸出都是一樣的並且跨越不同平臺時候表現是否有所不同。這種測試確保無論終端使用者在哪裡使用，都有一致的體驗。
舉個例子：如果你曾經為iOS和安卓建立了一個行動端APP，你將會需要一個相容測試，來驗證那個APP在兩個平臺上以相同的預設級別執行。
壓力測試：
壓力測試是開發者把聽他們的軟體推播到一個極端測試用例，來驗證軟體的斷點。最常見的壓力測試是最大化並行使用者來找出當前構建能承載的極限。整個壓力測試中效能被完整記錄，因此開發者可以發現軟體斷點，指出可接受級別下合適使用者體驗會降級。極限情況下，壓力測試致力於找出系統在哪裡會失效，因此你可以在當前產品版本下規避這些失效條件。
舉個例子，設想你正在開發一個線上電動遊戲。你可以通過在這個遊戲中單次儘可能獲得多的線上玩家來進行壓力測試。你可以然後記錄伺服器平臺的表現（速率、響應等），同樣也能發現何時伺服器會崩潰（斷點）。
壓力測試和負載測試高度重疊。負載測試記錄軟體在預期負載下的執行。壓力測試記錄軟體在最大負載下的執行。
軟體測試生命週期
無論你使用何種方法論，你總是被期望遵循一個特定的測試生命週期。軟體測試生命週期幫助你關注產品需求並一次開發一個特性。
讓我們深入看看這六步：
需求分析
你和你的開發團隊與產品、市場團隊會面來討論產品的最終需求和特性。對每個需求，小組進行頭腦風暴，形成一個可以指示需求是否已經被實現的可測試的說明書。這些說明書可以是諸如「執行時間必須低於X」或「客戶必須能很容易操作使用者介面」等事情。你後面步驟將會用到這些說明書。
測試計劃
這個步驟裡，你和你的開發團隊進行頭腦風暴，討論說明書裡如何進行測試的內容。一些常見的點是「我們將會需要什麼資源？」，「我們可以用什麼量化指標來測試我們的需求？」和「可能影響測試結果的關鍵風險因素是什麼？」。這步最重要的方面是留存測試指標/用例說明並植入進產品說明書。
測試用例開發
測試用例開發是軟體測試過程中的一個關鍵活動，它涉及編寫和設計測試用例，以驗證軟體系統的功能、效能和可靠性。
測試用例開發的目標是為了在系統中發現潛在的問題和錯誤，以確保軟體的質量和穩定性。通過編寫測試用例，測試人員可以明確測試的目標、步驟和預期結果，並使用這些測試用例來執行系統測試。
測試用例通常包括以下幾個方面：
- 測試目標：明確測試的目標和測試的覆蓋範圍。確定要測試的功能、特性或場景。
- 測試步驟：定義具體的測試步驟，包括輸入資料、操作或操作流程。
- 預期結果：指定每個測試步驟的預期結果，即在正確的情況下預期系統的行為或輸出。
- 環境設定：確定測試執行所需的測試環境和設定，包括硬體、軟體和網路環境等。
- 前置條件：指定執行測試用例之前的特定條件或狀態，以確保測試的正確性和一致性。
- 後置條件：定義執行測試用例之後所期望的系統狀態或結果。
測試環境設定
這個步驟裡，你將會建立你的測試環境。絕大多數產品是釋出在多平臺的，這意味著你至少需要一個平臺建立一個環境。這個主要是通過測試框架和多個虛擬機器器來完成的。
你同樣將會在這個步驟建立能經過整個程式也能產生穩定輸出的測試輸入。好的測試輸入覆蓋測試用例的全部範圍，就算反覆執行結果也是一致的。
測試執行
這個步驟裡，你和你的團隊將會執行測試並記錄所有決定了的指標。絕大多數團隊會進行執行測試以得到多個可以對比的資料點位。請注意所有嚴重的和不嚴重的程式缺陷將會在下個開發週期被再次處理。
你也可能認可你的指標並沒有記錄所有你需要的資料。這是一個評估你為後面測試選擇的指標的好機會。
測試用例關閉與分析
這個步驟是關於從測試中回收固化的、可報告的測試結果。絕大多數公司將會要求你書寫日報或週報，彙總每個測試的執行和測試後要改變什麼。
從這裡開始，你可以選擇下面一個：
- 調整測試並重復來獲取更多資訊（不同指標，優化的測試環境等）
- 使用測試結果，返回來為產品開發解決方案（優化執行時間，提升量級等）
使用敏捷測試實踐，你將在你創造產品程式碼前和後完成測試周期。這允許你在產品開發中加速開發，因為你把說明書記在腦中了。
軟體測試最佳實踐
- 不要完全依賴自動測試。確保最少要有一套人工測試來捕捉未預期的缺陷。
- 編碼同時以常見語言或虛擬碼書寫測試用例。你的經理和新進成員將會感激你節省了他們解析測試指令碼的時間。
- 僅僅用受控的、隔離的測試環境來避免外部因素。使用一個個人機器或公用的雲範例執行測試來去掉可能影響效能或輸出的變數。
- 選擇特定的量化指標。對於說明書和測試用例，確保你的指標僅僅衡量單一屬性，可以通過數位來追蹤，能幫助到回報。
- 增量測試。在你的測試中建立子條件來追蹤測試中程式哪裡失效了。
- 讓團隊成員為單元和整合測試準備測試工作。避免發生讓另一個開發者為你的程式創造測試的確認偏差。當外部測試不可用時候這是個好法子。
- 使用有幫助的測試名稱。以測試的套件或需求來名稱測試。規避諸如Test1或performanceTest的無效名稱，換成StressTest_10000user。
- 使用諸如Selenium和Reflect的軟體測試工具。測試可能是很難追蹤的。使用測試框架/工具來簡化你的測試，在組內共用它們。
總結
通過本文的深入探索，我們全面瞭解了軟體測試的奧祕和其在軟體開發中的重要性。不同型別的軟體測試方法為我們提供了多種手段來保證軟體的質量、可靠性和穩定性。無論是功能測試、非功能測試、手工測試還是自動化測試，它們都在不同方面提供了有力的驗證和保障。通過合理選擇和應用這些測試方法，我們能夠發現和解決潛在的問題，併為使用者提供高質量的軟體產品。軟體測試不僅是一項技術活動，更是一種質量文化的體現，它對於整個軟體開發生命週期的成功至關重要。
擴充套件連結：