傳回
“測試政策”通俗來講就是6個字：“測什麼”和“怎麼測”。
具體來講，就是答好和産品測試相關的六大問題：
測試的對象和範圍是什麼？
測試的目标是什麼？
測試的重點和難點是什麼？
測試的深度和廣度？
如何安排各種測試活動（先測試什麼，再測試什麼）？
如何評價測試的效果？
測試方針是産品測試中的通用要求、原則或底線。
通用是測試方針的顯著特點：它不針對某個特定産品，而是一個産品族，或是一個産品系列，并且在較長的一段時間内都是适用的。
測試方針舉例：
産品的缺陷修複率要達到75%以上，才能釋出。
開發轉給測試的版本，需要進行自測，并出具測試報告。
對釋出版本，無論代碼修改了多少，都要對基本功能進行回歸測試。
産品更新後發現有功能丢失了，這類缺陷的等級為嚴重。
試政策僅針對目前特定的産品版本而言，并不像測試方針那樣具備通用性。反過來，我們倒是可以這樣了解測試政策：循測試方針+項目實際情況=測試政策
試政策需要遵循測試方針，并不意味着我們不能根據項目的實際情況來對測試方針進行調整。
産品的缺陷修複率要達到75%以上，才能釋出這條測試方針為例。如果目前某個特定産品版本，對産品品質的要求特别高，在制定測試政策的時候，我們可以考慮将這條測試方針調整為“産品的缺陷修複率要達到90%，嚴重以上的缺陷修複率為100%”。
測試政策也不是測試計劃，它們之間的關系是：通過測試政策确定的測試活動，在測試計劃中被拆解為一個個任務，并為每個任務确定工期、執行的先後次序和責任人，如圖1所示。
圖1 測試政策與測試計劃的關系
表1 “測試計劃”示例
此外，測試計劃的制訂者是測試經理，屬于測試管理的範疇。而測試政策的制定者是軟體測試架構師，屬于測試技術的範疇。
1）測試方案主要解決的是特性在測試設計和測試執行方面的問題
測試政策要解決的是産品測試的六大問題。顯然，測試方案要解決的問題沒有那麼“高大上”，就是如何對特性進行測試設計和如何安排這個特性的測試執行，具體包括：
對特性的需求、場景、設計進行分析，提取測試點。
對測試點選擇合适的測試設計方法（如使用怎樣的測試設計模型、測試資料的選擇），生成測試用例。
自動化測試設計。
測試執行時需要按照怎樣的順序來執行這些測試用例。
舉例如下：
測試方案模闆（以一個“特性”為機關）：
1.××特性的場景
a）使用者場景描述。描述使用者會如何使用這個特性。
b）測試場景描述。描述測試時會怎樣模拟使用者的使用，模拟和實際的差别在哪裡，是否會有風險，等等。
2.××特性設計分析
a）産品實作中的關鍵業務流程。
b）重要的算法（或實作技術）的分析。
c）其他需要注意的内容分析。
3.××特性測試分析
a）測試類型分析。
b）功能互動分析。
4.××特性測試設計
對測試點使用四步測試設計法，逐一得到測試用例。
以“樹”形結構來組織這些測試用例。
為測試用例劃分優先級。
5.××特性測試執行
哪些測試用例準備進行手工測試。
哪些用例計劃進行自動化測試。
哪些地方可能還需要進行探索測試。
測試用例是否需要考慮測試執行順序。
2）測試方案需要遵循測試政策
測試方案需要遵循測試政策對具體某個特性的測試深度和廣度的要求。
例如，某測試政策對特性a和特性b的測試說明，見表2。
表2 測試說明
該在什麼時候開始制定測試政策？如果在項目開頭進行，你會發現很多和測試政策相關的内容根本就還不明了，無從下手；如果在項目後期進行，内容是明了，但是做測試政策的意義又在哪裡呢？
可見，我們還是需要一套方法來指導我們制定測試政策的整個過程，“四步測試政策制定法”應運而生，如圖2所示。
圖2 四步測試政策制定法
明确“産品品質目标”是我們在制定測試政策過程中十分關鍵的一個步驟。對我們而言，不僅需要關注操作層面的具體方法，更要了解其中蘊含的測試政策思想。
1）我們的測試目标就是讓産品在釋出的時候能夠滿足事先約定的品質目标
2）圍繞産品品質目标進行剛剛好的測試
3）将目标—行為—評估形成閉環
圖3 産品品質評估
如圖3：
首先，我們将産品品質評估模型作用于具體的産品，得到産品品質目标。
其次，我們根據産品品質目标來制定測試政策，确定接下來的測試活動。
再次，執行各種測試活動。
最後，對測試效果進行評估，評估産品的品質目标是否達到。
1）提前識别項目中可能存在哪些會阻塞測試的風險，然後基于風險來調整測試政策
實際項目中真的有很多問題，都會讓我們的測試變得舉步維艱。
舉例：實際項目中測試活動無法順利開展的一些例子
例1：在需求階段，需求工程師未能提供全面的産品需求文檔，導緻測試設計時場景缺失，無法達到測試設計的預期效果。
例2：在測試設計時，開發未能提供相關的設計文檔，或是文檔未能及時更新，導緻測試設計遺漏或不準确，無法達到測試設計的預期效果。
例3：在測試執行時，發現一些測試用例因為缺陷或者代碼送出的原因阻塞了，不能按照計劃進行測試執行。
例4：在測試執行時，發現缺陷遲遲不能修改，缺陷分析的結果不能達到預期。
“骨感”的現實告訴我們，需要提前識别項目中可能存在哪些會阻塞測試的風險，然後基于風險來調整我們的測試政策，增加一些測試活動或者品質保證活動。
2）基于風險來加強和降低測試投入
何時開展測試政策的制定活動？制定測試政策是一次到位，還是要分幾次完成？
這就需要我們将測試政策的制定和研發流程結合起來。
1）測試政策的結構
圖4是一個傳統研發流程示意圖。針對這個研發流程，我們設計了總體測試政策—階段測試政策—測試執行政策這樣的測試政策結構。
圖6-4 傳統研發流程示意圖
有了這樣的結構，我們能夠将目前的測試政策總是控制在“當下”，即項目的情況總是在比較确定的範圍内，避免我們過于糾結“未來”。
2）根據研發流程來安排測試活動
測試政策中具體的内容，也需要和研發流程保持一緻，確定測試和開發的節奏能夠彼此吻合。
從大層面來說，測試在各個階段的活動和開發的活動是能夠配合起來的，如圖6-5所示：
圖6-5 測試人員職責
要達到這個大層面的吻合，是比較容易的。相對比較困難的是，是在版本測試階段，開發活動和測試活動彼此配合的問題。簡單地說，就是開發人員在做計劃的時候是否考慮了測試活動：
是否隻是送出了一個“中間層”而非最後使用者可見的功能？送出的功能是否可測？
測試能否有足夠的時間進行測試準備？
測試能否在下個版本送出之前完成測試？
這就需要軟體測試架構師能夠做好版本測試政策，能夠和開發人員進行有效溝通，使得雙方能夠了解彼此的節奏，達到更好的配合。
除此之外，我們即将要介紹的測試分層，也能幫助我們更好地制定版本測試政策。
到目前為止，我們已經能夠綜合考慮研發流程、風險，并基于産品品質目标來制定測試政策。通過上面的分析，我們可以得到很多測試活動，會發現有那麼多要做的事情，現在的問題是我們該以什麼政策去安排這些測試活動？
這個問題的最佳答案就是進行“測試分層”。
測試分層最大的價值在于：
通過測試分層，我們能夠将一個大的測試目标，分到不同層次中分階段去完成；
合理的測試分層，能夠讓測試目标smart化。能夠讓我們将目标（産品品質目标）—行為（測試活動）—評估（品質評估）的閉環，真正在産品測試中落地。
通過前面的介紹，我們了解到在使用四步測試政策制定法來制定測試政策時，會使用到一些方式或者模型。總的來說，如圖6-6所示。
圖6 四步測試政策制定法中用到的方式或模型
産品品質評估模型将用在測試目标的确定和評估上，它是整個測試政策的基礎。在介紹這個重要模型之前，我們想先花一點筆墨來讨論一下一個優秀的産品品質評估模型應該具備哪些特征。
産品品質評估中的幾個場景：
場景1：項目計劃的時間到了，就釋出産品。
場景2：将缺陷修複率作為産品的品質目标。産品必須達到一定的缺陷修複率，才能釋出。
場景3：我們為産品建立了很多名額來作為品質目标，如缺陷修複率、測試代碼覆寫率等。産品必須達到制訂的品質目标，才能釋出。
結果：
場景1說明測試團隊目前還沒有産品品質評估的具體辦法
場景2和場景1相比，已經有了判斷标準，可以說是有質的改變，但場景2也有“軟肋”，就是評價的标準太過于單一
場景3看起來很好，但是在實際操作的時候，我們往往會發現，我們費時費力地對這些名額進行了統計、分析和跟蹤，最後也都達到了，但是我們對産品品質的好壞依然感到心裡沒底
我分析出現場景3中的問題，主要原因有3點：
第一，這些名額覆寫的次元可能不全，我們可能遺漏掉了一些重要的考察項。
第二，“名額”本身比較容易被“聰明人”繞過去，變得形同虛設。
第三，整個品質評價體系中全是名額，缺少定性的分析
例如，我們以測試的代碼覆寫度要達到90%作為一項品質目标。為了達到這個目标，我們可能會選擇一些容易進行測試“覆寫”，但實際上風險并不大的地方進行測試。雖然最終能達到90%的測試覆寫目标，但是沒有被測試到的10%那部分情況如何，是否真的不需要測試，可能會有哪些風險，對我們來說都是“未知”的。未知正是心裡沒底的源頭。
如果我們将這個問題從評估引申到目标的層面，如果我們在制訂目标的時候，考慮的不僅僅是名額，而能包含一些如“對重要特性，要達到100%的測試覆寫”“測試方法要包含語句覆寫、判斷覆寫、路徑覆寫”等的描述，以此作為要達到的品質目标，不僅能解決上述的問題，還能更好地幫助我們确定要進行的測試活動。
綜上，一個優秀的産品品質評估模型，應該具備如下特質：
多元度：能夠覆寫品質評估的各個緯度，能夠幫助評估者全面分析和考慮。
定量+定性：名額和分析相結合，能夠有效避免在隻有名額的情況下，被“繞”過去，變得形同虛設。
過程+結果：不僅評估測試的結果，還對過程進行分析和評估。
我們将從3個方面來建立軟體産品品質評估模型，對産品品質進行分析、确定和評估（圖7）：
圖7 産品品質評估模型
測試覆寫度評估：對測試範圍及測試的深度與廣度進行分析和評估。（定量名額）
測試過程評估：對測試過程和測試的投入情況來進行分析與評估。（定量名額+定性分析）
缺陷分析：對測試結果進行分析和評估。（定量名額+定性分析）
表3 測試覆寫度評估的定義與屬性
需求覆寫度的目标必須為100%，即測試保證對産品承諾要實作的需求都進行。
“需求覆寫度”中的“需求”，可以是“包需求”，也可以是“需求規格”“story”“user case”等可以代表項目中産品需求的内容，大家可以根據項目的實際情況來選擇。
需求覆寫度評估有以下兩種方法：
方法1：直接在需求表中确認測試情況
方法2：建立測試用例和需求的對應關系
方法2是在測試設計的時候，通過編号來建立需求和測試用例的對應關系。這樣我們隻要保證這些測試用例都被執行了，需求也就都被測試驗證了，見表6-5。
方法2的優勢是，測試能夠從一開始就保證需求的覆寫，從源頭上避免了需求遺漏的風險；還很容易通過不同的測試設計方法，讓不同優先級的需求能夠有不同的測試深度，更利于軟體測試架構師對整個項目進行把控。
但是方法2也有一些需要注意的地方：
需要注意需求變化的部分：特别是在項目後期“增加”“修改”和“删除”的需求，避免遺漏。
方法2和測試設計的關系變得比較緊密，測試設計遺漏可能會影響對需求覆寫度的評估。
另外在實際項目中，需求和測試用例的對應關系，可能也并不像前面表格的例子中那樣标準的一對一的關系，而是一對多、多對一或多對多這種比較混亂的情況，要想手工維護好這些關系并不是一件容易的事情，特别是當遇到需求發生變化了，或是通過缺陷來增加測試用例等情況的時候，要修改的地方就更多了。是以，方法2最好能夠有工具支援，能夠通過工具來維護這些對應關系。
表6-6 路徑分析法總結
第一步：确定路徑覆寫政策。
軟體測試架構師可以以特性或者功能為粒度，根據該功能的品質目标來确定路徑覆寫政策。在如何選擇确定路徑覆寫政策上，建議如下：
可以将最小線性無關覆寫作為一個基本的路徑覆寫方式。
對優先級高的功能特性，可以在最小線性無關覆寫的基礎上增加一些路徑。
對優先級低的功能特性，可以在最小線性無關覆寫的基礎上減少一些路徑。
表7 路徑覆寫政策的記錄
第二步：使用路徑分析法設計測試用例。
第三步：跟蹤測試用例的執行情況。
當測試團隊按照路徑覆寫政策完成了用例設計後，對路徑覆寫度的評估，就轉換為了測試用例執行情況的評估。我們的目标是這些設計的用例能夠至少被執行一遍，并且測試結果為“通過”。如果存在測試用例在産品釋出的時候都被“阻塞”，無法執行的情況，我們就需要對阻塞的情況進行分析，評估目前的覆寫度是否能夠滿足測試的基本要求。
1.測試用例執行率
2.測試用例執行通過率
3.測試用例和非測試用例發現缺陷比
們希望“通過測試用例發現的缺陷”和“發散測試”，也就是非測試用例發現的缺陷”的比值能夠在一個合理的範圍内。
如果比值過低，即大部分缺陷都是通過發散測試發現的，可能的問題是：
随機測試投入過多。
測試設計水準不高，存在測試設計遺漏。
對産品的需求或者設計的了解不正确、不準确或者不深入，存在測試設計錯誤。
如果果比值過高，大多數缺陷都是通過測試用例發現的，可能的問題是：
測試人員不願意進行發散測試（這樣的測試團隊可能也是一個比較沉悶、缺乏激情、隻是完成任務的測試團隊）。
測試投入不足，沒有時間進行發散測試。
測試思路還沒有打開。如果存在這種情況，說明測試設計可能也不夠全面。
圖8 詳細總結圖
其中：
“分析測試設計是否和測試政策中的測試方法符合”，可以通過測試設計的過程跟蹤、測試評審等方式去跟蹤和分析。
“分析測試執行時的測試方法是否符合測試政策”，可以通過測試執行時的日報、周報，測試用例執行情況等方式去跟蹤和分析。
“通過缺陷分析來确定測試政策是否需要調整”，主要是對缺陷進行缺陷觸發因素分析，相關的内容将在6.6節中為大家較長的描述。
測試投入分析也是很重要的一項測試過程評估項目，在這裡我們主要從測試人員安排和測試投入工作量來進行分析，确認重要的、高風險的特性能夠保證測試投入，符合測試政策。
表8 測試投入分析
但是如果我們僅僅把缺陷當成産品問題的記錄，而不去挖掘缺陷資料背後隐含的和産品品質有關的資訊，就顯得太可惜了。
缺陷密度是指每千行代碼發現的缺陷數。我們在确定了缺陷密度後，還可以順帶得到缺陷總數。
對一個産品研發項目而言，确定、分析缺陷密度的重要意義在于：
通過缺陷密度，我們可以預測産品中可能會有多少缺陷。
通過缺陷密度，可以幫助我們評估目前已經發現的缺陷總數是否足夠多。如果“缺陷密度”和預期偏差較大，原則上不應該退出測試，釋出産品。
我們能夠在産品測試之前，較為準确地預測産品的缺陷密度并将此作為一個測試目标，主要基于如下假設：
在系統複雜度、研發能力一定的情況下，由各個環節引入系統中的缺陷總數也會是基本一緻的。
如果我們發現實際的缺陷密度值偏高，通常最可能的原因為：産品整體品質不高。此時，軟體測試架構師可以：
提高缺陷密度的預估值。
對缺陷較多的地方增加測試投入，如增加測試人力、增加測試時間、使用更多的測試方法等。
考慮和研發經理、開發人員、系統工程師等一起進行一些品質改進和品質保證工作，如加強評審等。
如果我們發現實際的缺陷密度值偏低，通常最可能的原因為：
産品整體品質較好。
測試能力不足，未能充分暴露缺陷。
測試投入不足，未能充分暴露缺陷。
在每個測試分層（如內建測試、系統測試）開始的時候确定缺陷修複率目标。有時候産品的缺陷實在太多，為了保證重要缺陷能夠被優先修複，我們可以對缺陷按照嚴重程度進行劃分，然後按照不同的嚴重程度來确定缺陷修複率。
1.缺陷的嚴重程度
表9 缺陷的嚴重程度的定義與示例
缺陷趨勢是指“随着測試時間的進行，測試發現的缺陷趨勢和開發解決缺陷的趨勢”。我們進行此項分析的重要原因在于：缺陷趨勢分析能夠幫助我們判斷目前系統是否還能很容易地發現缺陷，進而幫我們确定是否可以退出測試，釋出産品。
6.3.1 繪制缺陷趨勢圖
表10 缺陷趨勢分析表
我們将表10繪成圖，就得到了如圖9所示的缺陷趨勢分析圖。
圖9 缺陷趨勢分析圖
在繪制缺陷趨勢分析圖時，不要忘記去掉節假日、周末公休日等“沒有工作的日子”。
6.3.2 缺陷趨勢曲線的“凹凸性”和“拐點”
1）理想的“累積發現的缺陷趨勢”曲線
圖10 理想的變化趨勢
2）“累積發現的缺陷趨勢”的“拐點”出現得過早
“拐點”的出現，意味着測試團隊在這個測試階段裡已經無法有效發現産品的缺陷了。出現這種情況，可能的原因有：
測試團隊的投入發生了變化（如人員調動或者減少），并且已經影響了測試。
測試發生了阻塞（如産品品質差，存在會阻塞測試執行的缺陷），無法有效開展測試活動。
測試政策不當，目前的測試方法确實已經發現不了産品的缺陷了。
3）“累積發現的缺陷趨勢”的拐點未出現
這說明在這個測試階段裡，測試團隊依然可以發現産品大量的問題。出現這種情況，可能的原因是：
測試團隊未按照測試政策進行測試，可能使用了更多、更複雜的方法來發現産品缺陷。
版本品質太差，缺陷密度高于預期。
出現第一種情況，這個團隊的測試者水準應該比較不錯（至少掌握的測試方法比較多）；也應該比較有測試激情（不是按照軟體測試架構師要求的任務測完就結束了，而是自己主動去發現系統更多的問題）；另外版本的品質可能也不錯（至少還能夠使用各種測試方法來“折騰”系統），沒有嚴重的測試阻塞。但這依然需要軟體測試架構師和測試者仔細核對測試計劃，确認測試者是在保證了測試計劃的前提下才進行發揮的——核對的過程可能會讓人感到有些尴尬，但我們的核心理念是：通過測試政策來進行“剛剛好”（我們必須保證對重點測試部分的确認）的測試，而不僅是為了發現産品的缺陷。
如果确認發現測試計劃存在偏差，需要在下個版本中進行補充測試，并和測試者做好溝通。
出現第二種情況，軟體測試架構師可以考慮從如下幾個方面來更新後續的測試政策：
增加相關内容的測試用例執行次數。
加強相關内容的回歸測試。
對發現的缺陷進行逆向分析，增加探索式測試。
6.3.3 缺陷是否收斂
我們在判斷缺陷趨勢是否收斂時，需要具備以下兩個條件，缺一不可：
“累積發現的缺陷趨勢”變為凸函數。
“累積發現的缺陷趨勢”和“累積解決的缺陷趨勢”兩條曲線越來越靠近，最後逐漸趨于一點。
當我們發現缺陷不收斂時，做好代碼改動方面的控制，是一個很好的思路：
嚴格控制代碼改動，非必要不改動。
做好代碼的靜态檢查。
做好和修改相關的功能自測，避免因為缺陷修改而引入新的問題。
表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）缺陷修改引入的缺陷過多
缺陷的觸發因素就是測試者發現缺陷的測試方法。缺陷觸發因素分析，就是對測試中使用的測試方法進行分析。
對缺陷觸發因素進行分析，能夠幫助我們确認産品測試是否已經進行得足夠全面和深入
和缺陷年齡分析方法類似，我們也可以通過下面3個步驟來進行缺陷觸發因素分析。
6.5.1 确定缺陷的測試方法和測試類型
如果你的項目有缺陷的管理工具（如bugzilla），可以增加測試方法和測試類型的選項，在測試發現缺陷的時候來記錄相關的資訊。
果沒有缺陷管理工具也沒有關系，你可以使用類似表6-14的形式，來确定該缺陷的測試方法和測試類型。
表14 确定缺陷測試方法和測試類型
6.5.2 統計出各種測試方法發現的缺陷數目，繪制缺陷觸發因素分析圖
圖15 缺陷觸發因素分析圖
6.5.3 進行缺陷觸發因素分析
在理想情況下，我們希望做出的缺陷觸發因素圖和測試政策是吻合的。例如，目前版本我們的測試政策是：
對功能首先進行配置的周遊測試，需要保證新送出的指令行和以前已有的web頁面功能具有一緻性；再進行基本功能測試，能夠覆寫業務流程的基本路徑；最後進行滿規格的測試。
如果我們持續對産品進行缺陷觸發因素分析，參考曆史資料，結合自身的經驗，我們還可以得到“不同的測試方法發現缺陷的大緻比值和分布”。當然，這個比值可能不是很準，但是也可以作為軟體測試架構師對資料進行分析時的參考。
表15 産品品質評估表
我們将風險分析技術用在保證測試政策的順利進行和基于風險來加強或降低測試投入上，涉及的主要技術為風險識别、風險評估、風險應對和老功能分析。
此處我們讨論的風險分析的對象是測試政策，目标是提前識别那些可能會阻塞測試政策順利進行的問題，包括風險識别和風險評估兩個部分。
7.1.1.風險識别
圖16 風險識别的方法
舉例：對測試設計進行風險識别
step1：首先分析測試設計需要關注哪些内容。例如：
需要對某個重要的特性進行深入的測試，需要能夠通過路徑分析法來對開發人員的設計流程進行全面的覆寫，不遺漏基本的流程。
需要能夠通過功能互動分析對功能間的互相作用進行深入的測試。
需要能夠進行壓力、穩定性和性能方面的測試。
step2：分析上述内容都能夠保質保量順利地進行，需要哪些條件。例如：
條件1：開發能夠提供相關的設計材料（如相關的概要設計文檔），并且能夠保證材料的内容是正确的。
條件2：有條件或者有機制能夠保證開發人員和測試人員之間的有效溝通。
條件3：測試人員對産品的使用場景、多個特性都有一定的了解，能夠進行全面的功能互動分析。
條件4：測試人員能夠了解并掌握壓力、穩定性和性能方面的測試方法，有能力結合測試方法和産品實作來進行測試設計。
step3：逐一分析這些條件是否能夠滿足。假如條件1和條件4可能無法滿足，那麼識别出來的風險點就是：
風險1：開發可能會缺失重要的設計文檔，或者一些設計文檔更新不及時。
風險2：測試人員對壓力、穩定性和性能方面的測試方法掌握不足，可能會出現測試設計遺漏。
需要特别說明的是，雖然此處我們進行風險分析的對象是測試政策，圍繞測試活動能否正常展開，但并不等于我們隻在測試内部識别風險點——我們依然要從整個項目的角度來進行風險識别。我們可以使用表6-16風險識别清單，來幫助我們進行風險識别。
表16 風險識别清單
7.1.2 風險評估
風險評估的目标就是确定風險優先級。
1）風險優先級正交表
表17 風險優先級正交表
表18 常見風險及應對思路
7.3.1 差異性分析
差異性分析是指找出老功能在新版本和老版本上的差異。這些差異包括需求、設計、平台、實作等各種差異。
7.3.2 曆史測試情況分析
曆史測試情況分析是對老功能在老版本中的測試情況（包括測試政策、測試用例、缺陷）進行分析，以此來确定老功能在新版本中需要采用怎樣的測試政策。
1）确認老功能在新版本和老版本中的品質要求是否一緻
2）進行測試方法分析
表19 分析角度
3）進行缺陷分析
表20 老功能曆史缺陷分析點
4）對“組織和人”進行分析
表21 測試團隊分析
我們将分層測試運用在測試目标的smart化上和測試活動的安排上。
對v模型而言，每個測試分層測試圖測試的重點為：
單元測試：從産品實作的函數單元的角度，驗證函數單元是否正确。
內建測試：從産品子產品和功能的角度，驗證功能子產品和子產品之間的接口是否正确。
系統測試：從系統的角度，驗證功能是否正确，驗證系統的非功能屬性是否能夠滿足使用者的需求。
驗收測試：從使用者的角度，确認産品是否能夠滿足使用者的業務需求。
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模型中的測試分層來進行測試，就顯得太重了。在這個測試分層中，我們在單元測試層中測試代碼、接口的品質；送出給測試後，在功能測試層中集中測試功能；待功能相對穩定後，在非功能測試層中再集中易用性、性能和可靠性等方面的内容；在探索測試層，再結合缺陷，進行補充測試和回歸測試。