軟體測試架構師修煉之道 (二)

一. 軟體測試架構師的核心技能- 制定測試策略：

1. 如何才能制定好測試策略：

　　

1.1 理解測試策略 - 什麼是測試策略：

　　

1.1.1 通俗說：就是 6 個字：“測什麼” 和 “怎麼測”。

　　

1.1.2 具體來講，就是答好和產品測試相關的六大問題：

• a. 測試的物件和範圍是什麼？

• b. 測試的目標是什麼？

• c. 測試的重點和難點是什麼？

• d. 測試的深度和廣度？

• e. 如何安排各種測試活動 (先測試什麼，再測試什麼)？

• f. 如何評價測試的效果？

　　

1.2 測試策略不等於測試方針：

1.2.1 測試方針：

• a. 是產品測試中的通用要求、原則或底線。

• b. 顯著特點：通用。它不針對某個特點產品，而是一個產品族，或是一個產品系列，並且在較長的一段時間內都是適用的。

　　

1.2.2 測試策略：

• a. 針對當前特定的產品版本而言，不像測試方針那樣具備通用性。

• b. 測試策略 = 遵循測試方針 + 專案實際情況。

　　

1.3 測試策略不等於測試計劃：

• a. 測試策略不是測試計劃，之間的關係：透過測試策略確定的測試活動，在測試計劃中拆解為一個個任務，併為每個任務確定工期、執行的先後次序和責任人。

• b. 測試計劃的制定者是測試經理，屬於測試管理的範疇。而測試策略的制定者是軟體測試架構師，屬於測試技術的範疇。

　　

1.4 測試策略不等於測試方案：

• a. 測試方案主要解決的是，特性在測試設計和測試執行方面的問題。

• b. 測試策略要解決的是產品測試的六大問題。測試方案要解決的問題，沒有那麼 “高大上”，就是如何對特性進行測試設計和如何安排這個特性的測試執行，具體包括：

  • b1. 對特性的需求、場景、設計進行分析，提取測試點。
  • b2. 對測試點選擇合適的測試設計方法 (如使用怎樣的測試設計模型、測試資料的選擇)，生成測試用例。
  • b3. 自動化測試設計。
  • b4. 測試執行時，需要按照怎樣的順序來執行這些測試用例。

• c. 測試方案需要遵循測試策略：

  • 測試方案需要遵循測試策略對具體某個特性的測試深度和廣度的要求。

• d. 從責任人的角度：

  • 測試策略的責任人是軟體測試架構師；測試方案的責任人是各個特性測試責任人。

　　

1.2 四步測試策略制定法：

1.2.1 明確 “產品質量目標”：

• a. 我們的測試目標，就是讓產品在釋出的時候，能滿足事先約定的質量目標。

• b. 圍繞產品質量目標進行剛剛好的測試：

  • 產品質量要求高的是測試重點，反之未非重點；
  • 產品質量要求高的測試投入打，反之小；
  • 產品質量要求高的要測得深，反之淺。

• c. 將目標 - 行為 - 評估 形成閉環：

  • 產品質量目標使得產品質量評估變得可行。思路：
  • 首先，將產品質量評估模型作用於具體的產品，得到產品質量目標；
  • 其次，根據產品質量目標來制定測試策略，確定接下來的測試活動；
  • 再次，執行各種測試活動；
  • 最後，對測試效果進行評估，評估產品的質量目標是否達到。

　　

1.2.2 進行 “風險分析”：

• a. 提前識別專案中，可能存在哪些會阻塞測試的風險，然後基於風險來調整測試策略。

• b. 基於風險來加強和降低測試投入：

  • 對高風險的部分，加強測試投入；
  • 對低風險的部分，降低測試投入。

• c. 適配 “產品研發流程”：

  • c1. 測試策略的結構：

• c2. 根據研發流程來安排測試活動：

　　　　　　　　　　

• d. 進行 “測試分層”：

  • 概念：測試分層，是指將有共同測試目的的測試活動，放在一起形成一個組，然後一組一組地逐一進行測試。

• e. “四步測試策略制定法” 中的測試技術：

  • 產品質量評估模型缺陷分析技術；
  • 風險分析技術；
  • 老功能分析技術；
  • 分層測試技術。

　　　　　　　　　　

• 1.3.2 軟體質量評估模型：

  • 從 3 個方面來建立軟體產品質量評估模型，對產品質量進行分析、確定和評估：
  • a. 測試覆蓋度評估：
    • 對測試範圍及測試的深度與廣度進行分析和評估；
    • 包括需求覆蓋度評估和路徑覆蓋度分析兩個方面，從 “需求” 和 “實現” 兩個緯度來對測試的全面性進行分析和評估，屬於定量指標。
  • b. 測試過程評估：
    • 對測試過程和測試的投入情況進行分析與評估； 包括測試用例分析、測試方法分析和測試投入分析 3 個方面，既包含定量指標，又包含定性分析。
  • c. 缺陷分析：
    * 對測試結果進行分析和評估；
    * 包括缺陷密度分析、缺陷修復情況分析、缺陷趨勢分析、缺陷年齡分析和缺陷觸發因素分析。從這 5 個方面來對測試結果進行分析和評估，也是既包含定量指標，又包含定性分析。

　　

　　　　　　　　

1.4 測試覆蓋度評估：

* 概念：測試覆蓋評估是對產品測試的全面性的分析和評估，是對產品測試能夠對產品質量進行評估的基礎。

1.4.1 需求覆蓋度評估：

• 概念：需求覆蓋度是 “已經測試驗證的產品需求數” 和 “產品需求規格總數” 的比值。

• 需求覆蓋度的目標必須為 100%，即測試保證對產品承諾要實現的需求都進行了驗證，並要對產品是否滿足需求給出評估。

• 需求覆蓋度評估方法：

  • 方法 1：直接在需求表中確認測試情況 - 各個測試責任人，直接在需求表中對需求的測試情況進行確認。
  • 方法 1 最好不要在測試快結束的時候才進行，可以根據開發的合入計劃，一邊測試，一邊確認：

  • 方法 2：在測試設計的時候，透過編號來建立需求和測試用例的對應關係。只要保證這些測試用例都被執行了，需求也都就被驗證了。

    • 優勢：　　

      • 測試能夠從一開始就保證需求的覆蓋，從源頭上避免了需求遺漏的風險；
      • 很容易透過不同的測試設計方法，讓不同優先順序的需求能夠有不同的測試深度，更利於軟體測試架構師對整個專案進行把控。

      • 注意點：

        • 需要注意需求變化的部分 - 特別是在專案後期 “增加”、“修改” 和 “刪除” 的需求，避免遺漏。
        • 方法 2 和測試設計的關係變得比較緊密，測試設計遺漏，可能會影響對需求覆蓋度的評估。
          

1.4.2 路徑覆蓋法評估：

• 1.概念：路徑覆蓋度是 “已經測試到的語句的數量” 和 “程式中可執行語句的總數量” 的比值。

• 2.路徑分析法總結：

• 3.對產品的路徑覆蓋度進行評估：

  • 第一步：確定路徑覆蓋率策略：
  • 軟體測試架構師，可以以特性或者功能未粒度，根據該功能的質量目標，來確定路徑覆蓋策略。方法：
  • a. 可以將最小線性無關覆蓋作為一個基本的路徑覆蓋方式；
  • b. 對優先順序高的功能特性，可以在最小無關覆蓋的基礎上增加一些路徑；
  • c. 對優先順序低的功能特性，可以在最小無關覆蓋的基礎上減少一些路徑；　　
  • d. 不建議全面進行全覆蓋，也不建議使用語句覆蓋。
  • 第二步：使用路徑分析法，設計測試用例。
  • 第三步：跟蹤測試用例的執行情況。

　　　　　　　　

1.5 測試過程評估：

• 1.測試過程評估分析的物件：測試用例、測試方法和測試投入。

• 2.測試用例評估：

  • 2.1 測試用例執行率：
  • a.測試用例執行率：指 “已經執行的測試用例數目” 和 “測試用例總數” 的比值。
  • b."已經執行的測試用例數目"包含 測試結果為 “透過” 和 “失敗” 的測試用例。
  • c.測試用例執行率可以幫助我們分析測試的全面性，影響測試用例的執行率的因素：
    • 測試阻塞：指測試用例因為產品開發 (一般是指缺陷)、測試 (如測試環境不具備) 等原因，無法被執行的測試用例。
    • 未執行：指可以執行，但是因為進度、人力或其它原因等還沒有被執行的測試用例。

　　　　　　

• 2.2 測試用例執行透過率：

  • a. 概念：指 “測試用例執行結果” 為 “透過” 的測試用例數和 “已經執行的測試用例數目” 的比值。
  • b. 將測試用例執行透過率細分為：
  • 測試用例首次執行透過率：指 “第一次執行該測試用例的結果為 ‘透過’ 的測試用例數” 和 “已經執行的測試用例數目” 的比值。
  • 測試用例累積執行透過率：指 “測試用例結果為 ‘透過’ 的測試用例數” 和 “已經執行的測試用例數目” 的比值。

　　　　　　

• 2.3 測試用例和非測試用例發現缺陷比：

  • a. “透過測試用例發現的缺陷” 和 “發散測試，也就是非測試用例發現的缺陷” 的比值，能夠在一個合理的範圍內。
  • b. 如果比值過低，即大部分缺陷都是透過發散測試發現的，可能的問題是：
  • 隨機測試投入太多；
  • 測試設計水平不高，存在測試設計遺漏；
  • 對產品的需求或者設計的理解不正確、不準確或者不深入，存在測試設計錯誤；
  • c. 如果比值過高，大多數缺陷都是透過測試用例發現的，可能的問題是：
  • 測試人員不願意進行發散測試 (這樣的測試團隊可能也是一個比較沉悶、缺乏激情、只是完成任務的測試團隊);
  • 測試投入不足，沒有時間進行發散測試；
  • 測試思路還沒有開啟。

　　　　　　

• 3.測試方法分析：

  • 3.1 對軟體測試架構師來說，在測試之前，我們就需要根據產品的質量要求，根據測試目標、測試的深度和廣度來確定測試方法；在測試設計和測試執行中跟進，保證各個特性使用的測試方法和測試策略相符，並透過缺陷來確認測試策略是否符合，是否需要調整測試策略。

• 3.2 “分析測試設計是否和測試策略中的測試方法符合”，可以透過測試設計的過程跟蹤、測試評審等方式去跟蹤和分析。

• 3.3 “分析測試執行時的測試方法是否符合測試策略”，可以透過測試執行時的日報、週報，測試用例執行情況等方式去跟蹤和分析。

• 3.4 “透過缺陷分析來確定測試策略是否需要調整”，主要是對缺陷進行缺陷觸發因素分析。

　　　　

• 4.測試投入分析：

  • 4.1 主要從測試人員安排和測試投入工作量來進行分析，確認重要的、高風險的特性，能夠保證測試投入，符合測試策略。
  • 4.2 如果發現測試投入和測試策略不符，則需要考慮調整測試投入，或者調整測試策略。進行風險識別和風險控制，及時調整測試策略。

　　

1.6 缺陷分析：

• 概念：缺陷是指在產品測試中，發現產品不符合需求和設計的地方。
  

　　

• 1.6.1 缺陷密度：

  • a. 缺陷密度是指每千行發現的缺陷數。對一個產品研發專案而言，確定、分析缺陷密度的重要意義在於：
  • a1. 透過缺陷密度，我們可以預測產品中可能會有多少缺陷；
  • a2. 透過缺陷密度，可以幫助我們評估當前已經發現的缺陷總數是否足夠多。如果 “缺陷密度” 和預期偏差較大，原則上不應該退出測試，釋出產品。
  • b. 在實際專案中，真實 的缺陷密度不會和預估的缺陷密度恰好相等，往往會有一點的偏差。
  • b1. 實際的缺陷密度偏高，通常最可能的原因為：產品質量不高。此時，軟體測試架構師可以：
    • 提高缺陷密度的預估值；
    • 對缺陷較多的地方增加測試投入，如增加測試人力、增加測試時間、使用更多的測試方法等；
    • 考慮和研發經理、開發人員、系統工程師等一起進行一些質量改進和質量保證工作，如加強評審等。
  • b2. 實際的缺陷密度偏低，通常最可能的原因為：
    • 產品整體質量較好；
    • 測試能力不足，未能充分暴露缺陷；
    • 測試投入不足，未能充分暴露缺陷；

　　　　

• 1.6.2 缺陷修復率：

  • 概念：缺陷修復率是指，產品 “已經修復的缺陷總數” 和 “已經發現缺陷總數” 的比值。　
  • a1. 缺陷修復率能夠幫助我們確定當前產品發現的缺陷，是否被有效修復，為當前的產品質量是否達到測試質量目標提供最直接的判斷依據。這需要我們：
  • 在每個測試分層 (如整合測試、系統測試) 開始的時候，確定缺陷修復率目標；
  • 在每個測試分層結束時，判斷是否達到目標，是否可以進入下一階段的測試；
  • 如果最終的缺陷修復率不能達到預期，原則上不應該退出測試，釋出產品。
    

　　　

• a2. 缺陷的嚴重程度：

  • 概念：缺陷的嚴重程度是基於缺陷如果不修改，會對使用者造成的影響來劃分的。

• a3. 考慮了缺陷的嚴重程度的缺陷修復率：

  • 考慮了缺陷的嚴重程度後，缺陷修復率變成了在某些特定的嚴重程度下，缺陷的修復率，例如：
  • 一般以上的缺陷的修復率：缺陷的嚴重程度為 “一般” 、“嚴重” 和 “致命” 的修復率。
  • 嚴重以上的缺陷的修復率：缺陷的嚴重程度為 “嚴重” 和 “致命” 的修復率。 　　　

　　　　

• 1.6.3 缺陷趨勢分析：

  • 1.概念：缺陷趨勢是指 “隨著測試時間的進行，測試發現的缺陷趨勢和開發解決缺陷的趨勢”。
  • 2.進行此項分析的重要原因：缺陷趨勢分析，能夠幫助我們判斷當前系統是否還能很容易發現缺陷，進而幫我們確定是否可以退出測試，釋出產品。
  • 3.繪製缺陷趨勢圖：進行缺陷分析的第一步就是繪製缺陷趨勢分析圖：

缺陷趨勢分析圖：

　　　　　　　　

　　　　　　

• 4.缺陷趨勢曲線的 “凹凸性” 和 “拐點”：

  • 4.1 概念：用於凹函式特性的曲線，呈現出遞增的變化趨勢；用於凸函式特性的曲線，呈現出遞減的變化趨勢；拐點就是凹函式和凸函式中間的連線點，即函式的變化趨勢出現改變的點。 　　　　　　

　　　　　　　　

• 4.2 理想的 “累積發現的趨勢趨勢” 曲線：

  • a. 在一個新的測試階段開始的時候，希望 “累積發現缺陷的趨勢” 未凹函式，如 “①” 所示。
  • b. 在測試策略不變的情況下，測試一段時間後，出現 “拐點”。如下圖中的 “拐點 1”。

　　　　　　　　　　

• 4.3 “累積發現的缺陷趨勢” 的 “拐點” 出現得過早：
  

• a. 出現可能的原因：

  • a1. 測試團隊的投入傳送了變化 (如人員調動或減少)，並且已經影響了測試。
  • a2. 測試傳送了阻塞 (如產品質量差，存在會阻塞測試執行的缺陷)，無法有效開展測試活動。
  • a3. 測試策略不當，當前的測試方法確實已經發現不了產品的缺陷了。

　　　　　　　　　　

• 4.4 “累積發現的缺陷趨勢” 的 “拐點” 出現得過早：
  

• a. 出現可能的原因：

  • a1. 測試團隊未按照測試策略進行測試，可能使用了更多、更復雜的方法來發現產品缺陷。
  • a2. 版本質量太差，缺陷密度高於預期。

　　　　

• 1.6.4 缺陷年齡分析：
• 1.含義：指軟體 (系統) 產生或引入缺陷的時間。

　　　　　　　

• 2.不同階段，缺陷年齡的定義：

  • 2.1 繼承或歷史遺留：屬於歷史版本、繼承版本或是移植程式碼中的問題，非新開發的問題。
    　　　　　
  • 2.2 需求階段引入：缺陷是在產品需求設計階段引入的，主要包括如下情況：
  • (1）“需求不清” 的問題；
  • (2）“需求錯誤” 的問題；
  • (3）“系統整體設計” 的問題。
    

　　　　　

• 2.3 設計階段引入：缺陷是在產品設計階段引入的，主要包括如下情況：

  • （1）“功能和功能之間介面” 的問題；
  • （2）“功能互動” 的問題；
  • （3）“邊界值設計” 方面的問題；
  • （4）“流程、邏輯設計相關” 的問題；
  • 5）“演算法設計” 方面的問題。

　　　　　

• 2.4 編碼階段引入：缺陷是在編碼設計階段引入的，主要包括如下情況：

  • （1）“流程、邏輯實現相關” 的問題；
  • （2）“演算法實現相關” 的問題；
  • （3）“程式設計規範相關” 的問題；
  • （4）“模組和模組之間介面” 的問題。

　　　　　

• 2.5 新需求或變更引入：缺陷是因為新需求、需求變更或設計變更引入的問題。

  　　　　　

• 2.6 缺陷修改引入：缺陷是因為修改缺陷時引入的問題。
  　　　　　

  　　　　　

  • 2.開展缺陷年齡分析活動步驟：

• 第一步：確定缺陷的缺陷年齡：
  

• 第二步：統計出各類缺陷年齡的數量，繪製缺陷年齡分析圖：
  

　　　　　　　　

• 第三步：進行缺陷年齡分析：

  • （1）理想的缺陷年齡分析圖：
    
  • （2）在測試分層發現該層的問題：

　　　　

• 1.6.5 缺陷觸發因素分析：

  • 1.含義：缺陷的觸發因素就是測試者發現缺陷的測試方法。缺陷觸發因素分析，就是對測試中使用的測試方法進行分析。
  • 2.進行缺陷觸發因素分析步驟：
  • 第一步：確定缺陷的測試方法和測試型別:
  • 第二步：統計出各種測試方法發現的缺陷數目，繪製缺陷觸發因素分析圖。
  • 第三步：進行缺陷觸發因素分析:
    • 1.功能測試-- 單執行正常輸入：進行基本功能測試，覆蓋業務流程的基本路徑和測試時發現的問題。
    • 2.功能測試 -- 單執行邊界值測試：進行配置測試時發現的問題。
    • 3.功能測試 -- 多執行相互作用：進行基本功能測試，覆蓋業務流程的基本路徑和配置測試時發現的問題。
    • 4.效能測試：進行滿規格測試時發現的問題。

　　　　

• 1.6.6 組合使用各種缺陷分析技術：

  • 1. 產品質量評估表：
    
• 1. 組合使用缺陷分析技術：

1.7 風險分析技術：

• 1.含義：風險分析技術，用在保證測試策略的順利進行和基於風險來加強或降低測試投入上，涉及的主要技術：風險識別、風險評估、風險應對和老功能分析。

• 2.風險分析：此處討論的風險分析的物件是測試策略，目標是提前識別那些可能會阻塞測試策略順利進行的問題，包括風險識別和風險評估。

  • 2.1 風險識別：
  • a. 可以根據測試策略的內容，逐一分析哪些問題可能會對測試策略的開展帶來阻礙，並進行風險識別；
  • b. Step3 中不能滿足的那些條件，就是我們尋覓的風險點。
    
  • c. 風險識別清單：
  • 2.2 風險評估：

  • A. 風險評估的目標：確定風險優先順序。

    • B. 風險優先順序正交表：
    • b1. 風險評估的兩個方面：風險傳送頻率、風險影響程度。
      

  • C. 需求類的風險 - 高：

    • c1：需求的質量不高，不足以支撐後續開發和測試。
    • c2：開發和測試未能正確理解需求。
      

  • D. 設計類的風險 - 高：

    • d1. 設計類的風險，主要集中在設計的正確性和全面性上。
      

  • E. 流程類的風險 - 中：

    • e1：從風險影響程度的角度來說，會影響到團隊合作，或是設計規範性方面的風險。
      

  • F：歷史類的風險：

    • f1：歷史類的風險影響程度，參考歷史的風險影響程度來確定。

　　

• 3.風險應對：

  • 3.1 風險管理中，風險應對主要分為 4 種：
  • 迴避風險：指主動避開損失發生 的可能性。
  • 轉移風險：指透過某種安排，將自己面臨的風險全部或部分轉移給其它一方。
  • 減輕風險：指採取預防措施，以降低損失發生的可能性和影響程度。
  • 接受風險：指自己理性或非理性地主動承擔風險。 　 　　

• 4.老功能分析：

  • 4.1 差異性分析：指找出老功能在新版本和老版本上的差異。這些差異包括需求、設計、平臺、實現等各種差異。“找” 差異也是新版本中做好老功能測試的金鑰匙。
  • 4.2 歷史測試情況分析：歷史測試情況分析，是對老功能在老版本中的測試情況 (包括測試策略、測試用例、缺陷) 進行分析，以此來確定老功能在新版本中需要採用怎樣的測試策略。
  • A. 確認老功能在新版本和老版本中的質量要求是否一致。
  • B. 進行測試方法分析：
    
  • C. 進行缺陷分析：
    
  • D. 對 “組織和人” 進行分析：

　　　　　　　　　　

1.8 分層測試技術：

• 1.V 模型：
  

• 對 V 模型而言，每個測試分層測試圖測試的重點：

  • A. 單元測試：從產品實現的函式單元的角度，驗證函式單元是否正確。
  • B. 整合測試：從產品模組和功能的角度，驗證功能模組和模組之間的介面是否正確。
  • C. 系統測試：從系統的角度，驗證功能是否正確，驗證系統的非功能屬性是否能夠滿足使用者的需求。
  • D. 驗收測試：從使用者的角度，確認產品是否能夠滿足使用者的業務需求。
    

　　

• 2.設計測試層次：

  • A. 測試層次設計的基本原則：使得每個測試層次中的測試目標都是 “SMART”(具體、可衡量、可獲得、具有相關性和時限性) 化的。
  • B.某通訊公司的測試分層：
    
  • B1. 模組級系統測試 (MST)：保證軟體開發專案組各個單元/模組之間的介面正確，以及對專案組級別的功能進行驗證。
  • B2. Building Block Integrated Test(BBIT)：驗證的是子系統之間的單元/模組的介面的正確性，也就是 “聯調”。
  • B3. 系統設計確認 (SDV)：從系統的角度來驗證功能的正確性。
  • B4. 系統整合測試 (SIT)：從系統的角度來驗證功能互動和非功能方面的正確性。
  • B5. 系統驗證測試 (SVT)：驗證場景、解決方案的正確性。
    

　　

• C. 某公司在敏捷環境下的測試分層：

  • C1：單元測試 (UT test)：針對程式碼或者元件的測試。
  • C2：功能測試 (function test)：針對產品功能方面的測試。
  • C3：非功能測試 (non-functional test)：指非功能方面的其它質量屬性的測試。
  • C4：探索測試 (Explore test)：基於任務的測試。