軟體測試基礎理論

軟體測試基礎理論

測試理論

⭐️測試的八大原則

1. 所有的測試都應該追溯到使用者的需求

2. 測試應當儘早介入，將“儘早和不斷的測試”寫入座右銘！

   • 在實際當中，開發進行的同時測試可以去編寫測試用例文件

   • 開發是按模組開發：每個模組開發好了之後就可以進行測試了

3. 測試的工作應該由專門的測試人員完成

   • 避免自己測試自己寫的程式碼：思維定式

4. 二八原則：

   • 測試中發現的80%的問題是由其中20%的模組引起的，譬如：社會上80%的犯罪案件是由一小撮犯罪份子導致的。

5. 寫測試用例的時候，應該考慮到各種情況

   • 測試不能窮盡：測試分支很多，根據不同的情況指定不同的策略。

6. 殺蟲劑現象：

   • 當測試人員對同一用例測試的次數越多，發現的缺陷就會越來愈少。就像老用同一種農藥，害蟲的免疫力就會逐漸提高，農藥發揮不了效力。根本原因：思維定勢。

7. 用例包含了合理和不合理的輸入條件：

   • 登入舉例：

     合理：賬號密碼正確

     不合理：賬號或密碼錯誤

8. 測試軟體能證明它存在哪些缺陷，而不能證明他不存在哪些缺陷。

   • 為什麼：在實際過程中測試無法做到百分百的覆蓋

測試的物件、目的

1. 物件：程式、資料、文件

2. 目的：提高軟體質量

測試的風險

1. 進度風險

2. 人員風險

   • 數量：人員不足

   • 技術：技術不足

3. 質量風險：

   • 跟開發對質量的認知不一致

   • 開發認為不是問題？溝通

4. 成本風險：

   • 進度、人員、質量風險，都會導致成本風險

5. 變更風險：

   • 需求變更等

軟體開發的流程

軟體開發過程

1. 從構思到公開發行：0--->1的過程

軟體開發的模型

1. 瀑布模型

   

   • 特點：軟體開發的階段劃分明確，從上個階段到下個階段有明顯的界限

   • 優點：

     • 當在後續開發階段發現缺陷的時候，可以把這個缺陷反饋到上一階段進行修正

     • 有利於大型軟體開發過程人員的組織和管理

     • 有利於開發方法和工具的使用

     • 提高軟體的質量和效率

   • 缺點：

     • 一旦需求分析階段出現錯誤，那麼在後面過程中這個錯誤會不斷放大，導致後期維護工作相當繁重。

     • 難以適應變化。瀑布模型精準定義了每個階段的結果，而每一階段的結果又十分依賴上一階段。如果後面需求發生變化，牽一髮動全身。

     • 交付長，只有等所有階段都結束才能交付。客戶需要相當長的一段時間才能看到結果。

     • 文件驅動型的瀑布模型會造成一大堆的文件，而大部分文件對客戶沒有任何價值，花費了大量的人力。

2. V/W模型

   

   • V模型和瀑布模型類似，從上到下是開發模型，從下到上是測試模型。

     • 概要設計一般設計整體架構、框架

     • 詳細設計一般設計的是模組和模組之間的詳細設計

     • 單元測試和整合測試通常由開發人員完成

   • 優點：

     • 明確標註了測試的型別

     • 明確標註了測試和開發階段的對應關係與開發同步（引入檢測機制，需求分析做的好不好看驗收測試）

     • V模型的測試策略包含了低層測試（程式碼級的測試）、又包含了高層測試（需求級的測試）

   • 缺點

     • 僅僅把測試過程作為需求分析、概要設計、詳細設計、編碼之後的一個階段，容易讓人誤解測試是軟體開發的最後一個階段。

     • 測試被後置了，類似於瀑布開發模型，風險被推遲到測試時才發現，導致測試沒有時間及早的發現問題而遺留給客戶。

     • 和瀑布模型一樣，流程是單向不可逆的。

   • W模型（雙V模型）：

     

     由兩個V組成，一個開發模型，一個測試模型

   • 優點：

     • 測試從需求階段就介入了，符合儘早測試的原則

     • 符合實際工作中的測試活動

   • 缺點：

     • 上個階段完成才能開始下個階段

     • W模型與V模型一樣，視軟體開發活動是一系列序列的活動，開發和測試保持一種線性的前後關係，這樣就無法支援迭代

   • W模型也是個重文件的、重過程的模型

3. 增量模型

   

   增量模型是一種軟體開發過程模型，它將軟體系統分為多個獨立的部分，並逐步構建每個部分，逐步完善整個系統。這種方法允許在專案的不同階段逐漸增加功能，而不是一次性開發整個系統。增量模型通常用於大型和複雜的軟體專案，以降低專案風險，並允許更快地推出初始產品版本。

   1. 增量原型的特點原則：

      • 逐步構建：系統逐步構建，每個增量（部分）都是可用的，並且可以被測試驗證。

      • 迭代開發：每個增量可以包含一個或多個迭代，其中開發人員新增新的功能或改進現有功能。

      • 模組化設計：系統被劃分為獨立的模組或元件，每個模組可以單獨開發和測試。

      • 快速交付：初始的增量可以在較短時間內交付，客戶可以更早地開始使用部分系統。

      • 客戶反饋：客戶的反饋被積極吸收，用於指導後續增量的開發。

   2. 優點：

      • 降低風險：逐步構建系統減少了整體專案風險，因為問題可以在早期階段發現和解決。

      • 更早的交付：初始增量的快速交付允許客戶更早地獲得部分功能，從而獲得更早的價值。

      • 客戶滿意度：客戶可以在專案的不同階段提供反饋，以確保最終產品符合其需求和期望。

      • 靈活性：增量模型允許在專案進行的過程中根據需求變化進行調整和擴充套件。

   3. 缺點：

      • 複雜性：需要仔細的規劃和管理，以確保不同的增量正確整合。

      • 可擴充套件性挑戰：在後期增量中新增新功能可能會更加複雜，因為它們需要與現有的系統部分整合。

      • 需求變化：如果客戶需求頻繁變化，增量模型可能需要頻繁調整和重新規劃。

   4. 使用場景：

      • 大型和複雜的軟體專案，其中需求可能不完全明確或會隨時間變化。

      • 專案需要快速交付初始版本以滿足客戶的基本需求。

      • 客戶願意在專案進行的過程中提供反饋，並願意接受逐步完善的系統。

4. ⭐️迭代模型（面試重點）

   

   1. 迭代模型的每次迭代都經歷了一次完整的工作流程：需求分析、設計、實施、測試工作流程，類似與小型的瀑布模型每一次的迭代都會產生一個可以釋出的產品，這個產品是最終產品的一個子集。

   2. 迭代週期的劃分原則：

      每個迭代的週期依據該迭代工作量的不同而不同，一般2-4周。

   3. 迭代模組的優先順序確定：

      產品的核心功能、給使用者帶來最大化利益的，要在前面的迭代中實現。

   4. 面試問題：

      • 專案採用什麼開發模式

        • 迭代模型

      • 專案多長時間迭代一輪

        • 從0開始，工作量大，3周或者4周

        • 遊戲開發：2-3天釋出一個新版

      • 迭代優先順序

        • 優先順序如何確定

        • 產品的核心模組（簡歷、專案）對使用者利益最大的功能優先開發

      • 一輪迭代（假設三週）

        • 怎麼安排的？開發，測試的具體工作內容

          • 第一週：需求的評審。設計（概要設計，詳細設計）

            • 測試計劃——》測試設計——》編寫測試用例——》搭建測試環境

          • 第二週：開發編碼，自測

          • 第二週週五：釋出，交付測試（提測，進行冒煙測試）

          • 第三週：進行冒煙測試後沒什麼大問題，進行正式的測試，按照測試用例一步一步執行

      • 版本號命名：X. Y. Z. α，用非負整數表示

        • X：主版本號 1.0——》2.0（改動比較大：基於1.0新增很多功能，架構調整）

        • Y：子版本號 1.1.0——》1.2.0（有一定的改動：新增了一些功能）

        • Z：修訂版本號 1.1.1——》1.1.2（修復了一些bug，變化較小）

        • 預釋出版本號beat，α 等：公測內測版本，處於開發階段

5. 增量和迭代的區別

   

6. 敏捷開發（發揮人的主觀能動性，以人為本）

   1. Scrum模型：

      • product owner 劃分user story，根據商業價值排序

      • master召開各種會議

      • team（開發和測試）分別進行編碼、按照測試流程測試、每日會議daily meeting

      • 成果驗收

      • reviewing meeting 回顧會議（針對這一輪迭代，個人、團隊的角度進行總結，做的好的不好的，改進措施）

   2. 以人為核心，適應變化，迭代，循序漸進的開發方法

   3. 開發理念：

      • 個體和互動，勝過過程和工具

      • 可以工作的軟體，勝過面面俱到的文件

      • 客戶合作，勝過談判合同

      • 響應變化，勝過遵循計劃

   4. 核心價值觀：

      • 溝通，反饋，簡單，勇氣，尊重

   5. 優點：

      • 投資回報率高

      • 精確要求，精確成果

      • 團隊工作效率高

   6. 缺點：

      • 使用小型專案

      • 可能缺乏必要的設計和文件

7. 軟體研發模型的目的

   1. 保證最終產品滿足使用者需求

   2. 提高產品質量，降低產品開發成本

   3. 保證專案可管理，進度可控制

8. 總結

   • 瀑布、V、W：

     • 線性化、不可逆、專案前期一次性分析需求，所以很長時間專案的其他人員拿不到需求

     • 適用於大型的專案，對安全性、可靠性要求比較高

   • 增量、迭代、敏捷：

     • 分多輪交付，更能適應變化，實際上每個迭代就是一個小瀑布。

     • 適用於一開始需求不是很明確，快速交付

     • 敏捷：適用於團隊成員比較少的，30-40人

軟體測試流程

測試需求分析

測試計劃

測試設計

測試用例編寫

測試執行和bug管理

編寫測試報告

軟體測試分類

軟體測試型別

從是否執行程式的角度劃分

靜態測試：不允許被測試的軟體，只是靜態地檢查程式碼、介面或文件

動態測試：實際執行被測試的軟體，輸入相應的測試資料，檢查實際的輸出結果是否和預期結果相一致的過程

從測試實現方式劃分

1. 手工測試：

   • 由人根據用例進行資料輸入，並分析判斷測試結果的方式

2. 自動化測試：

   • 由程式實現的工具代替人進行測試條件預置、程式執行、測試結果分析判斷的方式。

3. 比較：

   • 自動化用例執行效果高，隨時執行

   • 人工：加入工程師的思考，有變化

從測試執行階段劃分

1. 單元測試

   • 單元測試是在軟體開發過程中的最早階段執行的測試，旨在驗證單個程式碼單元（通常是函式或方法）的正確性。

   • 這些測試由開發人員編寫，用於檢查程式碼是否按照預期執行，並且通常是自動化的。

   • 單元測試有助於捕捉和糾正程式碼級別的錯誤，提高程式碼的質量和可維護性。

2. 整合測試

   • 整合測試發生在單元測試之後，它關注不同程式碼單元（模組、元件）之間的互動和整合。

   • 目標是確保這些單元在組合在一起時能夠協同工作，不會導致功能故障或錯誤。

   • 整合測試可以採用逐步增量的方式，逐漸將元件整合到系統中，以確保各部分都相互相容。

3. ⭐️系統測試

   1. 什麼是系統測試：是軟體測試的一個關鍵階段，旨在驗證整個系統的完整性、功能和效能。

   2. 分類

      • 功能測試：透過執行一系列測試用例，驗證系統的各個功能和特性是否按照規格要求正常工作。這包括正常操作、異常情況和邊界條件的測試。

      • 效能測試：評估系統在不同負載和條件下的效能，包括響應時間、吞吐量、資源利用率等。效能測試型別包括負載測試、壓力測試和效能穩定性測試。

      • 安全性測試：檢查系統的安全性，包括身份驗證、授權、資料保護和漏洞掃描，以確保系統不容易受到惡意攻擊或資料洩露。

      • 相容性測試：驗證系統在不同作業系統、瀏覽器、裝置和網路環境下的相容性，確保使用者的廣泛範圍可以正常使用系統。

      • 可用性測試：評估系統的使用者介面、導航和文件，以確保系統易於使用和使用者友好。

      • 迴歸測試：在每次系統更改後執行，以確保新的更改沒有引入新問題，也沒有破壞現有功能。

4. 驗收測試

   • 驗收測試是在開發完成之後，通常由終端使用者、客戶或業務利益相關者執行的測試。

   • 它的目標是驗證軟體是否滿足使用者需求和預期，以決定是否接受軟體的交付。

   • 驗收測試可以分為alpha測試（在內部環境中進行）和beta測試（在真實使用者環境中進行）。

從測試介入程式碼的程度來分

1. 黑盒測試

   1. 概念：把軟體看成一個黑盒子，不管內部邏輯和內部特性，只依據規格說明書檢查程式的功能是否符合功能說明，又稱為功能測試或資料驅動測試

   2. 黑盒測試特點

      黑盒測試注重於測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程式所有功能需求的輸入條件。黑盒測試並不是白盒測試的替代品，而是用於輔助白盒測試發現其他型別的錯誤

      • 對於更大的程式碼單元來說（子系統甚至系統級）比白盒測試效率更高

      • 測試人員不需要了解軟體的實現細節，包括特定的程式語言

      • 從使用者的視角進行測試，更容易被理解和接受

      • 有助於暴露任何規格不一致或者有歧義的問題

      • 沒有清晰簡明的規格，用例很難設計

      • 不能控制內部執行路徑，會有很多內部程式路徑沒有被測試到

      • 不能針對特定的程式段，這些程式可能更復雜，問題更多

      舉例：

      x=2，y=4，不關心使用了什麼演算法

      登入功能：輸入正確賬號密碼觀察是否正常登入，不考慮程式碼如何實現（演算法資料結構等）

   3. 優點：

      • 測試效率比較高

      • 門檻低（不懂程式碼也能測試）

      • 站在使用者角度，更容易理解接受

      • 相對於白盒測試，儘早測試（需求規格明確後，就可以開始設計測試用例）

   4. 缺點：

      • 不能測試程式碼的固定位置

      • 哪些程式碼沒有被測試，不知道

2. 白盒測試

   1. 概念：又稱為結構測試或邏輯驅動測試，透明盒測試。著重於程式內部結構和演算法，不關心功能和效能指標。主要用於單元測試，程式碼和邏輯的測試，重點複雜的測試。白盒測試可以看到內部程式碼如何執行的。

   2. 優點：

      • 程式碼覆蓋率高

   3. 缺點：

      • 覆蓋所有程式碼路徑難度大

      • 業務功能可能覆蓋不全

      • 測試開銷大

      • 白盒測試不能驗證程式碼的正確性

3. 灰盒測試

   白盒和黑盒測試之間，多用於整合測試階段，基於程式執行時刻的外部表現同時又結合程式內部邏輯結構來設計用例，執行程式並採集程式路徑執行資訊和外部使用者介面結果的測試技術。

   定義：灰盒測試由方法和工具組成，這些方法和工具取材於應用程式的內部知識和與之互動的環境，能夠用於黑盒測試以增強測試效率、錯誤發現和錯誤分析的效率。

   1. 特點

      • 同黑盒一樣，也是根據需求文件來設計用例

      • 通常是在程式設計師做完白盒測試之後，在功能測試人員大規模整合測試之前

      • 需要了解程式碼工程的實現

      • 是透過類似白盒測試的方法進行，是透過類似白盒測試的方法進行，是透過編寫程式碼、呼叫函式或者封裝好的介面進行，但無需關心程式內部的實現細節，依然可以把他當成一個黑盒

   2. 優點

      • 能夠進行基於需求的覆蓋測試和基於程式路徑覆蓋的測試

      • 測試結果可以對應到程式內部路徑，便於bug定位、分析、解決

      • 能夠保證設計的黑盒測試用例的完整性，防止遺漏軟體的一些不常用的功能或者功能組合

      • 能夠避免需求或設計不詳細或不完整對測試造成的影響

   3. 缺點

      • 投入時間對比黑盒多20%-40%

      • 對人員要求較高

      • 需要理解內部系統結構由哪些模組組成，模組之間協作

      • 不如白盒深入

      • 不適用簡單系統

4. 其他測試

   1. 冒煙測試

      是對軟體基本的功能進行測試，測試的物件是每一個新編譯的需要正式測試的軟體版本，目的是確認軟體基本的功能正常，保證軟體系統能跑的起來，可以進行後續的正式測試工作。

   2. 迴歸測試

      是指軟體bug被修改後，進行的測試，以確認原來的bug已經被解決，並且沒有因為此次修改而引入新的bug

   3. 發散測試

      指測試人員基於對被測物件的理解，在不受測試計劃、測試用例等相關規則的約束進行的自由測試。

   4. 探索性測試

      是指在對測試物件進行測試的同時學習測試物件，並設計測試，在測試過程中利用對測試物件的理解來設計更好的測試。

⭐️軟體質量

概念

是指反映軟體系統或軟體產品滿足規定或隱含要求的能力的特徵和特性全體。軟體質量保證是為保證軟體系統或軟體產品充分滿足使用者要求的質量而進行的有計劃。有組織的活動，其目的是生產該質量的軟體。

內部質量

軟體的架構、編碼規範性、複雜度等

外部質量

功能是否滿足、效能是否達標、能不能相容各種瀏覽器等

使用質量

使用感受、體驗、易用性（好理解、好用、吸引性等）

⭐️軟體質量的八大特性（重中之重！）

1. 功能性

   • 定義：在指定條件下使用時，產品或系統提供滿足明確和隱含要求的功能的程度

   • 適合性：軟體為指定任務和使用者目標，提供了一組合適功能的能力。

   • 準確性：軟體系統提供給使用者的功能是否滿足使用者對該功能的精確度要求。

   • 互操作性：軟體系統和一個或多個周邊系統進行資訊互動的能力

   • 功能性的依從性：遵循相關的標準（國際標準、國家標準、行業標準、企業內部規範等)約定或法規以及類似規定的能力。

2. 可靠性

   可靠性是指在特定條件下使用時，軟體產品維持規定的效能級別的能力。

   1. 可靠性的三要素：規定的環境、規定的時間、規定的效能

   2. 可靠性包括以下子特性

      • 成熟性：

        軟體為避免由軟體中的錯誤而導致軟體失效的能力

      • 容錯性：

        軟體出現故障或者違反了制定介面的情況，軟體規定了維護效能級別的能力。如：檢查外部傳進來的指標是否非空、或者外部傳進來的引數是否合法

      • 易恢復性：

        系統失效後重新恢復原有功能、效能的能力

      • 可靠性依從性：

        遵循相關的標準（國際標準、國家標準、行業標準、企業內部規範等)約定或法規以及類似規定的能力。

3. 易用性

   在指定條件下使用時，軟體產品被理解、學習、使用和吸引使用者的能力

   1. 易理解性：

      使用者在使用軟體系統的過程中，系統互動給使用者的資訊是否準確、清晰、易懂，能幫助

      使用者準確理解系統當前真實的狀態，指導其進一步的操作。

   2. 易學性：

      軟體系統提供相關的輔助手段，幫助使用者學習使用它的能力

   3. 易操作性：

      軟體使使用者能操作和控制它的能力

   4. 吸引性：

      軟體吸引使用者的能力。美觀、新穎等

   5. 易用性的依從性：

      遵循相關的標準（國際標準、國家標準、行業標準、企業內部規範等)約定或法規以及類似規定的能力。

4. 效能（效率）

   1. 時間效率：

      系統在各業務場景下完成使用者指定的業務請求所需的響應時間。

   2. 資源效率：

      系統在各業務場景下完成使用者指定的業務請求所消耗的系統資源。如CPU使用率、記憶體使用率、IO、通訊頻寬使用等。

   3. 效率的依從性：

      遵循相關的標準（國際標準、國家標準、行業標準、企業內部規範等)約定或法規以及類似規定的能力。

5. 安全性

   1. 保密安全性：軟體系統保護資訊和資料的能力

      • 防止未得到授權的人或系統訪問相關的資訊或資料

      • 保證得到授權的人或系統能正常訪問相關的資訊或資料

   2. 常見安全性測試：

      • 使用者驗證：登入密碼驗證、IP地址訪問限制等

      • 使用者許可權管理：驗證低階別使用者是否具有了高階別使用者的許可權，各級別使用者許可權都得到了實現。

      • 系統資料的保護：對例如系統檔案、使用者密碼檔案等進行隱藏、密碼驗證、內容加密、備份。

      • 防Dos攻擊

      • 加密，解密：在計算機通訊中，採用密碼技術將資訊隱蔽起來，再將隱蔽後的資訊傳輸出去，使資訊在傳輸過程中即使被竊取或截獲，竊取者也不能瞭解資訊的內容，從而保證資訊傳輸的安全。

6. 可移植性

   1. 適應性：

      軟體系統無需做任何相應變動就能適應不同執行環境（作業系統平臺、資料庫平臺、硬體平臺等）的能力

   2. 易安裝性：

      易安裝性，是指軟體產品在指定環境中被安裝的能力。

   3. 共存性：

      軟體系統和在公共環境與其共享資源的其他系統共存的能力

   4. 易替換性：

      是指軟體產品在環境相同、目的相同的情況下替代另一個指定軟體產品的能力（線上升級，補丁升級等）

   5. 可移植性的依從性：

      遵循相關的標準（國際標準、國家標準、行業標準、企業內部規範等)約定或法規以及類似規定的能力

7. 可相容性

   對於常用的BS架構和CS架構，相容性需要考慮如下方面：

   架構	相容性測試內容	優勢	劣勢	說明
   B/S	不同瀏覽器的相容性	可維護性較好	效能相對較差	瀏覽器——》前端——》後端架構的原因，導致效能相對差一些
   C/S	作業系統、螢幕大小解析度	效能較好	維護性不太好	釋出了新版本，APP需要升級，同時APP上架還需要稽核（IOS需要一週時間稽核）

8. 可維護性

   1. 易分析性：（日誌）

      指軟體產品診斷軟體中的缺陷或失效原因，以及判定待修改的部分的能力

   2. 易改變性：

      指軟體產品使指定的修改可以被實現的能力

   3. 穩定性：

      指軟體產品避免由於軟體修改而造成意外結果的能力。如：定義的變數

   4. 易測試性：

      • 軟體可控制：

        軟體系統提供輔助手段幫助測試工程師控制該系統的執行，實現其測

        試執行步驟的能力（如：API測試，透過打點、改變內部狀態、值等手段。

      • 可觀察：

        軟體系統提供輔助手段幫助測試工程師獲得充分的系統執行資訊，以正

        確判斷系統執行狀態和測試執行結果的能力。

        a、設計單獨的測試模式

        b、提供單獨的測試版本（如：測試版本上開啟日誌功能）

   5. 維護性的依從性：

      遵循相關的標準（國際標準、國家標準、行業標準、企業內部規範等)約定或法規以及類似規定的能力。