測試架構師：4 如何才能制定好測試策略

測試架構師：4 如何才能制定好測試策略

 

2016-08-18

目錄

1　理解測試策略
  1.1 什麼是測試策略？
  1.2 測試策略等於測試方針？
  1.3 測試策略等於測試計劃？
  1.4 測試策略等於測試方案？
2　四步測試策略制定法
  2.1 明確「產品質量目標」
  2.2 進行「風險分析」
  2.3 適配「產品研發流程」
  2.4 進行「測試分層」
  2.5 「四步測試策略制定法」中的測試技術
3　產品質量評估模型
  3.1　優秀的產品質量評估模型的特徵
  3.2　軟件產品質量評估模型
4　測試覆蓋度評估
  4.1　需求覆蓋度評估
  4.2　路徑覆蓋度評估
5　測試過程評估
  5.1　測試用例評估
  5.2　測試方法分析
  5.3　測試投入分析
6　缺陷分析
  6.1　缺陷密度
  6.2　缺陷修復率
  6.3　缺陷趨勢分析
    6.3.1 繪製缺陷趨勢圖
    6.3.2 缺陷趨勢曲線的「凹凸性」和「拐點」
    6.3.3 缺陷是否收斂
  6.4　缺陷年齡分析
    6.4.1 肯定缺陷的缺陷年齡
    6.4.2 統計出各種缺陷年齡的數量，繪製缺陷年齡分析圖
    6.4.3 進行缺陷年齡分析
  6.5　缺陷觸發因素分析
    6.5.1 肯定缺陷的測試方法和測試類型
    6.5.2 統計出各類測試方法發現的缺陷數目，繪製缺陷觸發因素分析圖
    6.5.3 進行缺陷觸發因素分析
  6.6　組合使用各類缺陷分析技術
7　風險分析技術
  7.1　風險分析
    7.1.1 風險識別
    7.1.2 風險評估
  7.2　風險應對
  7.3　老功能分析
    7.3.1 差別性分析
    7.3.2 歷史測試狀況分析
8　分層測試技術
  8.1　V模型
  8.2　設計測試層次

 

四步測試策略制定發思惟導圖

1 理解測試策略

---

 返回

1.1 什麼是測試策略？

「測試策略」通俗來說就是6個字：「測什麼」和「怎麼測」。

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

• 測試的對象和範圍是什麼？
• 測試的目標是什麼？
• 測試的重點和難點是什麼？
• 測試的深度和廣度？
• 如何安排各類測試活動（先測試什麼，再測試什麼）？
• 如何評價測試的效果？

1.2 測試策略等於測試方針？

測試方針是產品測試中的通用要求、原則或底線。

通用是測試方針的顯著特色：它不針對某個特定產品，而是一個產品族，或是一個產品系列，而且在較長的一段時間內都是適用的。

測試方針舉例：

• 產品的缺陷修復率要達到75%以上，才能發佈。
• 開發轉給測試的版本，須要進行自測，並出具測試報告。
• 對發佈版本，不管代碼修改了多少，都要對基本功能進行迴歸測試。
• 產品升級後發現有功能丟失了，這類缺陷的等級爲嚴重。

試策略僅針對當前特定的產品版本而言，並不像測試方針那樣具有通用性。反過來，咱們卻是能夠這樣理解測試策略：循測試方針+項目實際狀況=測試策略

試策略須要遵循測試方針，並不意味着咱們不能根據項目的實際狀況來對測試方針進行調整。

• 產品的缺陷修復率要達到75%以上，才能發佈這條測試方針爲例。若是當前某個特定產品版本，對產品質量的要求特別高，在制定測試策略的時候，咱們能夠考慮將這條測試方針調整爲「產品的缺陷修復率要達到90%，嚴重以上的缺陷修復率爲100%」。

1.3 測試策略等於測試計劃？

測試策略也不是測試計劃，它們之間的關係是：經過測試策略肯定的測試活動，在測試計劃中被拆解爲一個個任務，併爲每一個任務肯定工期、執行的前後次序和責任人，如圖1所示。

圖1　測試策略與測試計劃的關係

表1 「測試計劃」示例

此外，測試計劃的制訂者是測試經理，屬於測試管理的範疇。而測試策略的制定者是軟件測試架構師，屬於測試技術的範疇。

1.4 測試策略等於測試方案？

1）測試方案主要解決的是特性在測試設計和測試執行方面的問題

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

• 對特性的需求、場景、設計進行分析，提取測試點。
• 對測試點選擇合適的測試設計方法（如使用怎樣的測試設計模型、測試數據的選擇），生成測試用例。
• 自動化測試設計。
• 測試執行時須要按照怎樣的順序來執行這些測試用例。

舉例以下：

測試方案模板（以一個「特性」爲單位）：

• 1.××特性的場景
  • a）用戶場景描述。描述用戶會如何使用這個特性。
  • b）測試場景描述。描述測試時會怎樣模擬用戶的使用，模擬和實際的差異在哪裏，是否會有風險，等等。
• 2.××特性設計分析
  • a）產品實現中的關鍵業務流程。
  • b）重要的算法（或實現技術）的分析。
  • c）其餘須要注意的內容分析。
• 3.××特性測試分析
  • a）測試類型分析。
  • b）功能交互分析。
• 4.××特性測試設計
  • 對測試點使用四步測試設計法，逐一獲得測試用例。
  • 以「樹」形結構來組織這些測試用例。
  • 爲測試用例劃分優先級。
• 5.××特性測試執行
  • 哪些測試用例準備進行手工測試。
  • 哪些用例計劃進行自動化測試。
  • 哪些地方可能還須要進行探索測試。
  • 測試用例是否須要考慮測試執行順序。

2）測試方案須要遵循測試策略

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

例如，某測試策略對特性A和特性B的測試說明，見表2。

表2 測試說明

2　四步測試策略制定法

---

 返回

該在何時開始制定測試策略？若是在項目開頭進行，你會發現不少和測試策略相關的內容根本就還不明瞭，無從下手；若是在項目後期進行，內容是明瞭，可是作測試策略的意義又在哪裏呢？

可見，咱們仍是須要一套方法來指導咱們制定測試策略的整個過程，「四步測試策略制定法」應運而生，如圖2所示。

圖2　四步測試策略制定法

2.1 明確「產品質量目標」

明確「產品質量目標」是咱們在制定測試策略過程當中十分關鍵的一個步驟。對咱們而言，不只須要關注操做層面的具體方法，更要理解其中蘊含的測試策略思想。

1）咱們的測試目標就是讓產品在發佈的時候可以知足事先約定的質量目標

2）圍繞產品質量目標進行剛恰好的測試

3）將目標—行爲—評估造成閉環

圖3　產品質量評估

如圖3：

• 首先，咱們將產品質量評估模型做用於具體的產品，獲得產品質量目標。
• 其次，咱們根據產品質量目標來制定測試策略，肯定接下來的測試活動。
• 再次，執行各類測試活動。
• 最後，對測試效果進行評估，評估產品的質量目標是否達到。

2.2 進行「風險分析」

1）提早識別項目中可能存在哪些會阻塞測試的風險，而後基於風險來調整測試策略

實際項目中真的有不少問題，都會讓咱們的測試變得舉步維艱。

舉例：實際項目中測試活動沒法順利開展的一些例子

• 例1：在需求階段，需求工程師未能提供全面的產品需求文檔，致使測試設計時場景缺失，沒法達到測試設計的預期效果。
• 例2：在測試設計時，開發未能提供相關的設計文檔，或是文檔未能及時更新，致使測試設計遺漏或不許確，沒法達到測試設計的預期效果。
• 例3：在測試執行時，發現一些測試用例由於缺陷或者代碼提交的緣由阻塞了，不能按照計劃進行測試執行。
• 例4：在測試執行時，發現缺陷遲遲不能修改，缺陷分析的結果不能達到預期。

「骨感」的現實告訴咱們，須要提早識別項目中可能存在哪些會阻塞測試的風險，而後基於風險來調整咱們的測試策略，增長一些測試活動或者質量保證活動。

2）基於風險來增強和下降測試投入

2.3 適配「產品研發流程」

什麼時候開展測試策略的制定活動？制定測試策略是一次到位，仍是要分幾回完成？

這就須要咱們將測試策略的制定和研發流程結合起來。

1）測試策略的結構

圖4是一個傳統研發流程示意圖。針對這個研發流程，咱們設計了整體測試策略—階段測試策略—測試執行策略這樣的測試策略結構。

圖6-4　傳統研發流程示意圖

有了這樣的結構，咱們可以將當前的測試策略老是控制在「當下」，即項目的狀況老是在比較肯定的範圍內，避免咱們過於糾結「將來」。

2）根據研發流程來安排測試活動

測試策略中具體的內容，也須要和研發流程保持一致，確保測試和開發的節奏可以彼此吻合。

從大層面來講，測試在各個階段的活動和開發的活動是可以配合起來的，如圖6-5所示：

圖6-5　測試人員職責

要達到這個大層面的吻合，是比較容易的。相對比較困難的是，是在版本測試階段，開發活動和測試活動彼此配合的問題。簡單地說，就是開發人員在作計劃的時候是否考慮了測試活動：

• 是否只是提交了一個「中間層」而非最後用戶可見的功能？提交的功能是否可測？
• 測試可否有足夠的時間進行測試準備？
• 測試可否在下個版本提交以前完成測試？

這就須要軟件測試架構師可以作好版本測試策略，可以和開發人員進行有效溝通，使得雙方可以理解彼此的節奏，達到更好的配合。

除此以外，咱們即將要介紹的測試分層，也能幫助咱們更好地制定版本測試策略。

2.4 進行「測試分層」

到目前爲止，咱們已經可以綜合考慮研發流程、風險，並基於產品質量目標來制定測試策略。經過上面的分析，咱們能夠獲得不少測試活動，會發現有那麼多要作的事情，如今的問題是咱們該以什麼策略去安排這些測試活動？

這個問題的最佳答案就是進行「測試分層」。

測試分層最大的價值在於：

• 經過測試分層，咱們可以將一個大的測試目標，分到不一樣層次中分階段去完成；
• 合理的測試分層，可以讓測試目標SMART化。可以讓咱們將目標（產品質量目標）—行爲（測試活動）—評估（質量評估）的閉環，真正在產品測試中落地。

2.5 「四步測試策略制定法」中的測試技術

經過前面的介紹，咱們瞭解到在使用四步測試策略制定法來制定測試策略時，會使用到一些方式或者模型。總的來講，如圖6-6所示。

圖6　四步測試策略制定法中用到的方式或模型

3　產品質量評估模型

---

 返回

產品質量評估模型將用在測試目標的肯定和評估上，它是整個測試策略的基礎。在介紹這個重要模型以前，咱們想先花一點筆墨來討論一下一個優秀的產品質量評估模型應該具有哪些特徵。

3.1　優秀的產品質量評估模型的特徵

產品質量評估中的幾個場景：

• 場景1：項目計劃的時間到了，就發佈產品。
• 場景2：將缺陷修復率做爲產品的質量目標。產品必須達到必定的缺陷修復率，才能發佈。
• 場景3：咱們爲產品創建了不少指標來做爲質量目標，如缺陷修復率、測試代碼覆蓋率等。產品必須達到制訂的質量目標，才能發佈。

結果：

• 場景1說明測試團隊當前尚未產品質量評估的具體辦法
• 場景2和場景1相比，已經有了判斷標準，能夠說是有質的改變，但場景2也有「軟肋」，就是評價的標準太過於單一
• 場景3看起來很好，可是在實際操做的時候，咱們每每會發現，咱們費時費力地對這些指標進行了統計、分析和跟蹤，最後也都達到了，可是咱們對產品質量的好壞依然感到內心沒底

我分析出現場景3中的問題，主要緣由有3點：

• 第一，這些指標覆蓋的維度可能不全，咱們可能遺漏掉了一些重要的考察項。
• 第二，「指標」自己比較容易被「聰明人」繞過去，變得形同虛設。
• 第三，整個質量評價體系中全是指標，缺乏定性的分析

例如，咱們以測試的代碼覆蓋度要達到90%做爲一項質量目標。爲了達到這個目標，咱們可能會選擇一些容易進行測試「覆蓋」，但實際上風險並不大的地方進行測試。雖然最終能達到90%的測試覆蓋目標，可是沒有被測試到的10%那部分狀況如何，是否真的不須要測試，可能會有哪些風險，對咱們來講都是「未知」的。未知正是內心沒底的源頭。

若是咱們將這個問題從評估引伸到目標的層面，若是咱們在制訂目標的時候，考慮的不只僅是指標，而能包含一些如「對重要特性，要達到100%的測試覆蓋」「測試方法要包含語句覆蓋、判斷覆蓋、路徑覆蓋」等的描述，以此做爲要達到的質量目標，不只能解決上述的問題，還能更好地幫助咱們肯定要進行的測試活動。

綜上，一個優秀的產品質量評估模型，應該具有以下特質：

• 多維度：可以覆蓋質量評估的各個緯度，可以幫助評估者全面分析和考慮。
• 定量+定性：指標和分析相結合，可以有效避免在只有指標的狀況下，被「繞」過去，變得形同虛設。
• 過程+結果：不只評估測試的結果，還對過程進行分析和評估。

3.2　軟件產品質量評估模型

咱們將從3個方面來創建軟件產品質量評估模型，對產品質量進行分析、肯定和評估（圖7）：

圖7　產品質量評估模型

• 測試覆蓋度評估：對測試範圍及測試的深度與廣度進行分析和評估。（定量指標）
• 測試過程評估：對測試過程和測試的投入狀況來進行分析與評估。（定量指標+定性分析）
• 缺陷分析：對測試結果進行分析和評估。（定量指標+定性分析）

4　測試覆蓋度評估

---

 返回

表3　測試覆蓋度評估的定義與屬性

4.1　需求覆蓋度評估

需求覆蓋度的目標必須爲100%，即測試保證對產品承諾要實現的需求都進行。

「需求覆蓋度」中的「需求」，能夠是「包需求」，也能夠是「需求規格」「story」「user case」等能夠表明項目中產品需求的內容，你們能夠根據項目的實際狀況來選擇。

需求覆蓋度評估有如下兩種方法：

方法1：直接在需求表中確認測試狀況

方法2：創建測試用例和需求的對應關係

方法2是在測試設計的時候，經過編號來創建需求和測試用例的對應關係。這樣咱們只要保證這些測試用例都被執行了，需求也就都被測試驗證了，見表6-5。

方法2的優點是，測試可以從一開始就保證需求的覆蓋，從源頭上避免了需求遺漏的風險；還很容易經過不一樣的測試設計方法，讓不一樣優先級的需求可以有不一樣的測試深度，更利於軟件測試架構師對整個項目進行把控。

可是方法2也有一些須要注意的地方：

• 須要注意需求變化的部分：特別是在項目後期「增長」「修改」和「刪除」的需求，避免遺漏。
• 方法2和測試設計的關係變得比較緊密，測試設計遺漏可能會影響對需求覆蓋度的評估。
• 另外在實際項目中，需求和測試用例的對應關係，可能也並不像前面表格的例子中那樣標準的一對一的關係，而是一對多、多對一或多對多這種比較混亂的狀況，要想手工維護好這些關係並非一件容易的事情，特別是當遇到需求發生變化了，或是經過缺陷來增長測試用例等狀況的時候，要修改的地方就更多了。因此，方法2最好可以有工具支持，可以經過工具來維護這些對應關係。

4.2　路徑覆蓋度評估

表6-6　路徑分析法總結

第一步：肯定路徑覆蓋策略。
軟件測試架構師能夠以特性或者功能爲粒度，根據該功能的質量目標來肯定路徑覆蓋策略。在如何選擇肯定路徑覆蓋策略上，建議以下：

• 能夠將最小線性無關覆蓋做爲一個基本的路徑覆蓋方式。
• 對優先級高的功能特性，能夠在最小線性無關覆蓋的基礎上增長一些路徑。
• 對優先級低的功能特性，能夠在最小線性無關覆蓋的基礎上減小一些路徑。

表7　路徑覆蓋策略的記錄

第二步：使用路徑分析法設計測試用例。

第三步：跟蹤測試用例的執行狀況。

當測試團隊按照路徑覆蓋策略完成了用例設計後，對路徑覆蓋度的評估，就轉換爲了測試用例執行狀況的評估。咱們的目標是這些設計的用例可以至少被執行一遍，而且測試結果爲「經過」。若是存在測試用例在產品發佈的時候都被「阻塞」，沒法執行的狀況，咱們就須要對阻塞的狀況進行分析，評估當前的覆蓋度是否可以知足測試的基本要求。

5　測試過程評估

---

 返回

5.1　測試用例評估

1.測試用例執行率

2.測試用例執行經過率

3.測試用例和非測試用例發現缺陷比

們但願「經過測試用例發現的缺陷」和「發散測試」，也就是非測試用例發現的缺陷」的比值可以在一個合理的範圍內。

若是比值太低，即大部分缺陷都是經過發散測試發現的，可能的問題是：

• 隨機測試投入過多。
• 測試設計水平不高，存在測試設計遺漏。
• 對產品的需求或者設計的理解不正確、不許確或者不深刻，存在測試設計錯誤。

若是果比值太高，大多數缺陷都是經過測試用例發現的，可能的問題是：

• 測試人員不肯意進行發散測試（這樣的測試團隊可能也是一個比較沉悶、缺少激情、只是完成任務的測試團隊）。
• 測試投入不足，沒有時間進行發散測試。
• 測試思路尚未打開。若是存在這種狀況，說明測試設計可能也不夠全面。

5.2　測試方法分析

圖8　詳細總結圖

其中：

• 「分析測試設計是否和測試策略中的測試方法符合」，能夠經過測試設計的過程跟蹤、測試評審等方式去跟蹤和分析。
• 「分析測試執行時的測試方法是否符合測試策略」，能夠經過測試執行時的日報、週報，測試用例執行狀況等方式去跟蹤和分析。
• 「經過缺陷分析來肯定測試策略是否須要調整」，主要是對缺陷進行缺陷觸發因素分析，相關的內容將在6.6節中爲你們詳細描述。

5.3　測試投入分析

測試投入分析也是很重要的一項測試過程評估項目，在這裏咱們主要從測試人員安排和測試投入工做量來進行分析，確認重要的、高風險的特性可以保證測試投入，符合測試策略。

表8　測試投入分析

6　缺陷分析

---

 返回

可是若是咱們僅僅把缺陷當成產品問題的記錄，而不去挖掘缺陷數據背後隱含的和產品質量有關的信息，就顯得太惋惜了。

6.1　缺陷密度

缺陷密度是指每千行代碼發現的缺陷數。咱們在肯定了缺陷密度後，還能夠順帶獲得缺陷總數。

對一個產品研發項目而言，肯定、分析缺陷密度的重要意義在於：

• 經過缺陷密度，咱們能夠預測產品中可能會有多少缺陷。
• 經過缺陷密度，能夠幫助咱們評估當前已經發現的缺陷總數是否足夠多。若是「缺陷密度」和預期誤差較大，原則上不該該退出測試，發佈產品。

咱們可以在產品測試以前，較爲準確地預測產品的缺陷密度並將此做爲一個測試目標，主要基於以下假設：

• 在系統複雜度、研發能力必定的狀況下，由各個環節引入系統中的缺陷總數也會是基本一致的。

若是咱們發現實際的缺陷密度值偏高，一般最可能的緣由爲：產品總體質量不高。此時，軟件測試架構師能夠：

提升缺陷密度的預估值。

對缺陷較多的地方增長測試投入，如增長測試人力、增長測試時間、使用更多的測試方法等。

考慮和研發經理、開發人員、系統工程師等一塊兒進行一些質量改進和質量保證工做，如增強評審等。

若是咱們發現實際的缺陷密度值偏低，一般最可能的緣由爲：

• 產品總體質量較好。
• 測試能力不足，未能充分暴露缺陷。
• 測試投入不足，未能充分暴露缺陷。

6.2　缺陷修復率

在每一個測試分層（如集成測試、系統測試）開始的時候肯定缺陷修復率目標。有時候產品的缺陷實在太多，爲了保證重要缺陷可以被優先修復，咱們能夠對缺陷按照嚴重程度進行劃分，而後按照不一樣的嚴重程度來肯定缺陷修復率。

1.缺陷的嚴重程度

表9　缺陷的嚴重程度的定義與示例

6.3　缺陷趨勢分析

缺陷趨勢是指「隨着測試時間的進行，測試發現的缺陷趨勢和開發解決缺陷的趨勢」。咱們進行此項分析的重要緣由在於：缺陷趨勢分析可以幫助咱們判斷當前系統是否還能很容易地發現缺陷，進而幫咱們肯定是否能夠退出測試，發佈產品。

6.3.1 繪製缺陷趨勢圖

表10　缺陷趨勢分析表

咱們將表10繪成圖，就獲得瞭如圖9所示的缺陷趨勢分析圖。

圖9　缺陷趨勢分析圖

在繪製缺陷趨勢分析圖時，不要忘記去掉節假日、週末公休日等「沒有工做的日子」。

6.3.2 缺陷趨勢曲線的「凹凸性」和「拐點」

1）理想的「累積發現的缺陷趨勢」曲線

圖10　理想的變化趨勢

2）「累積發現的缺陷趨勢」的「拐點」出現得過早

「拐點」的出現，意味着測試團隊在這個測試階段裏已經沒法有效發現產品的缺陷了。出現這種狀況，可能的緣由有：

• 測試團隊的投入發生了變化（如人員調動或者減小），而且已經影響了測試。
• 測試發生了阻塞（如產品質量差，存在會阻塞測試執行的缺陷），沒法有效開展測試活動。
• 測試策略不當，當前的測試方法確實已經發現不了產品的缺陷了。

3）「累積發現的缺陷趨勢」的拐點未出現

這說明在這個測試階段裏，測試團隊依然能夠發現產品大量的問題。出現這種狀況，可能的緣由是：

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

出現第一種狀況，這個團隊的測試者水平應該比較不錯（至少掌握的測試方法比較多）；也應該比較有測試激情（不是按照軟件測試架構師要求的任務測完就結束了，而是本身主動去發現系統更多的問題）；另外版本的質量可能也不錯（至少還可以使用各類測試方法來「折騰」系統），沒有嚴重的測試阻塞。但這依然須要軟件測試架構師和測試者仔細覈對測試計劃，確認測試者是在保證了測試計劃的前提下才進行發揮的——覈對的過程可能會讓人感到有些尷尬，但咱們的核心理念是：經過測試策略來進行「剛恰好」（咱們必須保證對重點測試部分的確認）的測試，而不只是爲了發現產品的缺陷。

若是確認發現測試計劃存在誤差，須要在下個版本中進行補充測試，並和測試者作好溝通。

出現第二種狀況，軟件測試架構師能夠考慮從以下幾個方面來更新後續的測試策略：

• 增長相關內容的測試用例執行次數。
• 增強相關內容的迴歸測試。
• 對發現的缺陷進行逆向分析，增長探索式測試。

6.3.3 缺陷是否收斂

咱們在判斷缺陷趨勢是否收斂時，須要具有如下兩個條件，缺一不可：

• 「累積發現的缺陷趨勢」變爲凸函數。
• 「累積發現的缺陷趨勢」和「累積解決的缺陷趨勢」兩條曲線愈來愈靠近，最後逐漸趨於一點。

當咱們發現缺陷不收斂時，作好代碼改動方面的控制，是一個很好的思路：

• 嚴格控制代碼改動，非必要不改動。
• 作好代碼的靜態檢查。
• 作好和修改相關的功能自測，避免由於缺陷修改而引入新的問題。

6.4　缺陷年齡分析

表11　缺陷年齡的定義

進行缺陷年齡分析，可以幫助咱們確認每一個可能引入缺陷環節、可能引入的缺陷是否都已經被有效去除。具體操做時，咱們經過如下簡單的3個步驟來開展缺陷年齡分析活動。

6.4.1 肯定缺陷的缺陷年齡

若是你的項目有缺陷的管理工具（如bugzilla），能夠增長缺陷年齡的選項。在開發修復缺陷的時候，能夠對缺陷年齡進行選擇。

若是沒有缺陷管理工具也沒有關係，你可使用相似表6-12的形式來肯定缺陷年齡。

表12　缺陷年齡肯定方法

6.4.2 統計出各種缺陷年齡的數量，繪製缺陷年齡分析圖

表13　缺陷年齡的數量

圖11　缺陷年齡分析圖

6.4.3 進行缺陷年齡分析

咱們在進行缺陷年齡分析以前，須要先理解一下理想的缺陷年齡應該具備怎樣的特色。

1）理想的缺陷年齡分析圖

理想的缺陷年齡分析圖應該是以下這樣的。

（1）在缺陷的引入階段就能及時發現該類缺陷，缺陷不會逃逸到下個階段，如圖12所示：

圖12　引入階段

若是真能達到這樣的水平，測試也就能夠「光榮」失業了。但實際狀況是，每一個階段都會有一些缺陷「逃逸」到下一階段，須要「測試」來發現這些逃掉的缺陷。

咱們已經瞭解到測試不該該想到哪裏就測到哪裏，而應該進行分層測試：在每一個測試分層圍繞不一樣的測試目標，使用不一樣的測試方法來進行測試。

（2）在特定的測試分層發現該層的問題，如圖13所示。

圖13　發現特定測試分層問題

對其餘幾類缺陷年齡，咱們的指望是：

• 沒有繼承或歷史遺留引入的缺陷。
• 沒有新需求或變動引入的缺陷。
• 沒有缺陷修改引入的缺陷。

2）沒有在特定的測試層次發現該層的缺陷

例如，在集成測試階段，咱們但願發如今編碼階段和設計階段引入的缺陷，但實際上卻發現了大量的在需求階段引入的缺陷。這說明：

• 產品需求的質量不高，需求存在不清晰或錯誤的狀況。
• 系統架構設計的質量不高。
• 需求質量不高，產品功能的質量也不會過高。
• 系統架構設計的質量不高，產品在非功能屬性方面的質量也不會過高。

這就須要測試或整個研發團隊來有針對性地進行改進。例如：

• 對需求再次進行檢測，確保還沒有集成的功能對應的需求的正確性。
• 分析架構設計中的問題，找出對非功能屬性方面的主要影響，調整測試策略，儘可能提早並加大這些內容的測試力度。
• 調整測試策略，增長相關功能的測試力度和迴歸測試的規模。

3）繼承或歷史遺留引入的缺陷過多

當咱們發現測試中出現了不少由於繼承或歷史遺留引入的缺陷時，這就說明產品還存在一些「舊帳」還沒有清理，這時咱們須要：

• 進行或從新進行老功能分析（詳見6.7.2節），更新測試策略。
• 對這些缺陷進行分析，由此更新測試策略，進行探索式測試。
• 若是被繼承的版本處於維護階段，考慮這些缺陷是否須要在維護版本中解決，併發布補丁或升級包。
• 確認被繼承的版本在維護階段發現的其餘缺陷，是否須要同步到當前新版本中。

圖14清理「舊帳」

4）新需求或變動引入的缺陷過多

5）缺陷修改引入的缺陷過多

6.5　缺陷觸發因素分析

缺陷的觸發因素就是測試者發現缺陷的測試方法。缺陷觸發因素分析，就是對測試中使用的測試方法進行分析。

對缺陷觸發因素進行分析，可以幫助咱們確認產品測試是否已經進行得足夠全面和深刻

和缺陷年齡分析方法相似，咱們也能夠經過下面3個步驟來進行缺陷觸發因素分析。

6.5.1 肯定缺陷的測試方法和測試類型

若是你的項目有缺陷的管理工具（如bugzilla），能夠增長測試方法和測試類型的選項，在測試發現缺陷的時候來記錄相關的信息。

果沒有缺陷管理工具也沒有關係，你可使用相似表6-14的形式，來肯定該缺陷的測試方法和測試類型。

表14 肯定缺陷測試方法和測試類型

6.5.2 統計出各類測試方法發現的缺陷數目，繪製缺陷觸發因素分析圖

圖15　缺陷觸發因素分析圖

6.5.3 進行缺陷觸發因素分析

在理想狀況下，咱們但願作出的缺陷觸發因素圖和測試策略是吻合的。例如，當前版本咱們的測試策略是：

對功能首先進行配置的遍歷測試，須要保證新提交的命令行和之前已有的Web頁面功能具備一致性；再進行基本功能測試，可以覆蓋業務流程的基本路徑；最後進行滿規格的測試。

若是咱們持續對產品進行缺陷觸發因素分析，參考歷史數據，結合自身的經驗，咱們還能夠獲得「不一樣的測試方法發現缺陷的大體比值和分佈」。固然，這個比值可能不是很準，可是也能夠做爲軟件測試架構師對數據進行分析時的參考。

6.6　組合使用各類缺陷分析技術

表15　產品質量評估表

7　風險分析技術

---

 返回

咱們將風險分析技術用在保證測試策略的順利進行和基於風險來增強或下降測試投入上，涉及的主要技術爲風險識別、風險評估、風險應對和老功能分析。

7.1　風險分析

此處咱們討論的風險分析的對象是測試策略，目標是提早識別那些可能會阻塞測試策略順利進行的問題，包括風險識別和風險評估兩個部分。

7.1.1.風險識別

圖16 風險識別的方法

舉例：對測試設計進行風險識別

Step1：首先分析測試設計須要關注哪些內容。例如：

• 須要對某個重要的特性進行深刻的測試，須要可以經過路徑分析法來對開發人員的設計流程進行全面的覆蓋，不遺漏基本的流程。
• 須要可以經過功能交互分析對功能間的相互做用進行深刻的測試。
• 須要可以進行壓力、穩定性和性能方面的測試。

Step2：分析上述內容都可以保質保量順利地進行，須要哪些條件。例如：

• 條件1：開發可以提供相關的設計材料（如相關的概要設計文檔），而且可以保證材料的內容是正確的。
• 條件2：有條件或者有機制可以保證開發人員和測試人員之間的有效溝通。
• 條件3：測試人員對產品的使用場景、多個特性都有必定的理解，可以進行全面的功能交互分析。
• 條件4：測試人員可以理解並掌握壓力、穩定性和性能方面的測試方法，有能力結合測試方法和產品實現來進行測試設計。

Step3：逐一分析這些條件是否可以知足。假如條件1和條件4可能沒法知足，那麼識別出來的風險點就是：

• 風險1：開發可能會缺失重要的設計文檔，或者一些設計文檔更新不及時。
• 風險2：測試人員對壓力、穩定性和性能方面的測試方法掌握不足，可能會出現測試設計遺漏。

須要特別說明的是，雖然此處咱們進行風險分析的對象是測試策略，圍繞測試活動可否正常展開，但並不等於咱們只在測試內部識別風險點——咱們依然要從整個項目的角度來進行風險識別。咱們可使用表6-16風險識別清單，來幫助咱們進行風險識別。

表16　風險識別清單 

 

7.1.2 風險評估

風險評估的目標就是肯定風險優先級。

1）風險優先級正交表

表17 風險優先級正交表

7.2　風險應對

表18 常見風險及應對思路

7.3　老功能分析

7.3.1 差別性分析

差別性分析是指找出老功能在新版本和老版本上的差別。這些差別包括需求、設計、平臺、實現等各類差別。

7.3.2 歷史測試狀況分析

歷史測試狀況分析是對老功能在老版本中的測試狀況（包括測試策略、測試用例、缺陷）進行分析，以此來肯定老功能在新版本中須要採用怎樣的測試策略。

1）確認老功能在新版本和老版本中的質量要求是否一致

2）進行測試方法分析

表19　分析角度

3）進行缺陷分析

表20　老功能歷史缺陷分析點

4）對「組織和人」進行分析

表21　測試團隊分析

8　分層測試技術

---

 返回

咱們將分層測試運用在測試目標的SMART化上和測試活動的安排上。

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

8.1　V模型

• 單元測試：從產品實現的函數單元的角度，驗證函數單元是否正確。
• 集成測試：從產品模塊和功能的角度，驗證功能模塊和模塊之間的接口是否正確。
• 系統測試：從系統的角度，驗證功能是否正確，驗證系統的非功能屬性是否可以知足用戶的需求。
• 驗收測試：從用戶的角度，確認產品是否可以知足用戶的業務需求。

8.2　設計測試層次

1.某通訊公司的測試分層

 

圖17　某通訊公司的測試分層

和V模型相比，集成測試在本例中被分紅了MST和BBIT；系統測試被分紅了SDV、SIT和SVT。

• 模塊級系統測試（MST）：保證軟件開發項目組各個單元/模塊之間的接口正確，以及對項目組級別的功能進行驗證。
• Building Block Integrated Test（BBIT）：驗證的是子系統之間的單元/模塊的接口的正確性，也就是咱們常說的開發「聯調」。
• 系統設計確認（SDV）：從系統的角度來驗證功能的正確性。
• 系統集成測試（SIT）：從系統的角度來驗證功能交互和非功能方面的正確性。
• 系統驗證測試（SVT）：驗證場景、解決方案的正確性。

爲何此處的「測試分層」要這麼複雜呢？這是由於在這個例子中，被測對象是通訊產品。咱們知道，通訊產品須要包含硬件、驅動和軟件，業務也比較複雜，還會涉及不少協議和規範。在設計上經常會包含多個子系統，涉及不少接口。用戶不只關注功能，還特別關注可靠性、性能等方面的質量，對產品質量總體要求很高。

2.某公司在敏捷環境下的測試分層

圖18 某公司在敏捷環境下的測試分層

和前面的介紹的測試分層相比，本例就顯得簡單多了：

• 單元測試（UT test）：針對代碼或者組件的測試。
• 功能測試（function test）：針對產品功能方面的測試。
• 非功能測試（non-functional test）：指非功能方面的其餘質量屬性的測試。
• 探索測試（Explore test）：基於任務的測試。

這時被測對象是一個純軟件產品，根據用戶的業務需求進行迭代開發，但整體來講並不複雜，基本不涉及協議或規範。用戶比較關注功能、易用性和性能，對可靠性方面的問題有必定的容忍性，總的來講對質量的總體要求並不算過高，但願產品可以快速交付。

在這樣的背景下，快速評估產品是否可以發佈，進行快速測試是有必要的。若是咱們仍是按照V模型中的測試分層來進行測試，就顯得過重了。在這個測試分層中，咱們在單元測試層中測試代碼、接口的質量；提交給測試後，在功能測試層中集中測試功能；待功能相對穩定後，在非功能測試層中再集中易用性、性能和可靠性等方面的內容；在探索測試層，再結合缺陷，進行補充測試和迴歸測試。