1、1（測試需求分析）（測試需求分析）2目錄目錄 測試需求分析背景測試需求分析背景 測試需求分析理論測試需求分析理論 測試需求分析工程方法測試需求分析工程方法 測試需求分析應用測試需求分析應用3為什么要做測試需求分析？為什么要做測試需求分析？測試了很多，還有這么多網上問題？客戶到底關心什么？不知道如何站在客戶立場測試？網上問題漏測：測試設計不充分60%！這些問題怎么沒有考慮到？需要做測試需求分析！4現狀？現狀？測試對象分析測試用例設計（方案內的）測試用例測試輸入TR3TR4沒有測試需求分析過程測試經理口頭分配測試方案任務不明確測試對象分析側重測試方案內部實現現狀存在什么問題？測試過程與結果缺乏質量

2、評估與控制過多關注功能實現、產品質量維度關注不全面沒有統一成熟的分析設計工程方法支撐5業界情況業界情況 SDTSDT公司測試分析設計公司測試分析設計 IBMIBM的測試設計七步法的測試設計七步法 某路由器公司的測試階段和測試類型某路由器公司的測試階段和測試類型 MOTOMOTO故障插入測試故障插入測試以業界公司為標桿，建立以業界公司為標桿，建立自己的測試分析設計體系自己的測試分析設計體系借鑒業界公司的經驗，總借鑒業界公司的經驗，總結相關工程方法結相關工程方法好的示例好的示例6測試需求分析業界介紹（測試需求分析業界介紹（SDT公司）公司）System Analysis of Test Basis

3、Test PartitionsTest ItemsTest CasesAction WordsAW Test CasesTest Design is an iterative processTest Frame的測試設計模式測試劃分測試需求分析7業界思路總結業界思路總結測試類型測試類型測試劃分測試劃分強調測試需求分析，測試需求不僅僅來自需求文檔強調測試需求分析，測試需求不僅僅來自需求文檔電子表格是支撐測試分析設計的主要工具電子表格是支撐測試分析設計的主要工具(我現在常用的是freemind,先分解劃塊兒，在分塊細化)不同類型的測試會發現不同類型的Bug。測試類型是從不同的角度來分析和測試產品8

4、目錄目錄 測試需求分析背景測試需求分析背景 測試需求分析理論測試需求分析理論 測試需求分析工程方法測試需求分析工程方法 測試需求分析應用測試需求分析應用9測試需求分析目的測試需求分析目的測試需求分析目的是：明確應該測試需求分析目的是：明確應該測試什么測試什么。即明確測試需求，。即明確測試需求，其核心是產品質量。其核心是產品質量。產品質量產品質量就是符合用戶的明確的或隱含的需求的程度。就是符合用戶的明確的或隱含的需求的程度。 需求文檔中的產品需求、系統設計需求是明確的需求需求文檔中的產品需求、系統設計需求是明確的需求 未在需求文檔中明確的隱含的用戶需求也是我們需要未在需求文檔中明確的隱含的用戶需

5、求也是我們需要分析的，如用戶使用產品方式、感受、業務習慣分析的，如用戶使用產品方式、感受、業務習慣Test requirementsTest requirements are useful sets of input that are useful sets of input that should be tested.should be tested. Brian MarickBrian Marick測試需求分析的目的？10測試需求分析基本概念（測試需求分析基本概念（1）測試視角）測試視角測試類型功能交互產品繼承分解分配測試有哪些獨特的視角？測試與開發的思路有哪些不同？測試的視角體現了測試的

6、思維活動測試的視角體現了測試的思維活動這四個視角是工程方法的基礎這四個視角是工程方法的基礎11測試需求分析基本概念（測試需求分析基本概念（2）活動框架（）活動框架（1）階段階段活動活動工程方法工程方法測試測試分析分析設計設計基本基本概念概念測試測試分析分析設計設計組織組織保證保證測試分析設計表測試分析設計表12產品測試需求分析測試規格分解分配產品測試規格特性測試需求分析分配后測試規格特性測試設計測試設計維護特性測試規格測試用例設計規格協議/規范/標準測試分析經驗庫SRS協議/規范測試設計經驗庫其他輸入測試方案設計測試用例設計測試用例設計測試用例測試用例設計維護產品分析產品包需求設計需求僅做參考

7、測試需求分析基本概念（測試需求分析基本概念（3）活動框架（）活動框架（2）13測試需求分析基本概念（測試需求分析基本概念（3）活動框架（）活動框架（2）產品測試需求分析特性測試需求分析特性測試設計測試用例設計SRSHLDLLDCODING測試需求分析活動類比開發活動圖14階段階段產品分析測試規格分解分配特性測試需求分析特性測試設計測試用例設計活動活動/子活動子活動結果輸出結果輸出測試需求分析測試需求分析測試方案設計測試方案設計產品測試規格分析原始需求提取產品測試需求分析測試類型分析；功能交互分析；關聯圖分析；測試特性建模；測試規格整合測試特性交互分析測試組網分析；判定表；因果圖；測試場景分析正

8、交測試分析法正交試驗設計法等價類劃分；邊界值；因果圖；正交試驗設計法；測試分析設計表之需求來源表測試分析設計表之原始需求表測試分析設計表之產品測試規格表；測試需求分析報告.doc特性測試工作任務書.doc測試分析設計表之特性測試規格表測試分析設計表之測試用例表原始需求提取方法繼承性分析工程方法工程方法測試需求分析基本概念（測試需求分析基本概念（4）活動框架（）活動框架（3）15測試需求分析基本概念（測試需求分析基本概念（5）名詞解釋）名詞解釋l測試原始需求測試原始需求：產品測試規格分析的輸入，是從產品包需求、系統需求、產品包需求、系統需求、測試經驗庫測試經驗庫等需求來源中提取的經過整理的輸入集

9、合。l測試規格測試規格：測試規格是產品測試規格和特性測試規格的通稱。一般而言，我們所說的測試規格都是指產品測試規格。產品測試規格是對客戶需求、產品包需求、設計需求、設計規格以及其它可能的需求進行綜合的測試分析，從測試角度分析并整合形成的測試需求集合，明確了測試應該測試什明確了測試應該測試什么么。產品測試規格經過相關整理后相互之間沒有重復，每條產品測試規格都有唯一的標識。 l測試特性測試特性：邏輯上相關邏輯上相關的產品測試規格集合，可以是功能性的產品測試規格集合，也可以是非功能性的產品測試規格集合。邏輯相關性，指的是按照一定的規則進行劃分，這個規則是個廣義的規則，區別于開發按照功能進行劃分的特性

10、。 16測試需求分析活動（測試需求分析活動（1）產品分析）產品分析l 產品分析主要是產品知識前期學習和熟悉產品分析主要是產品知識前期學習和熟悉l 確定產品測試需求分析的來源確定產品測試需求分析的來源l 確定測試分析設計策略確定測試分析設計策略這個產品/版本是什么？趕緊學習相關資料！下一步如何分析？17測試需求分析活動（測試需求分析活動（2）提取測試原始需求）提取測試原始需求l 子活動準備（分工組織、提取策略）子活動準備（分工組織、提取策略）l 提取測試原始需求提取測試原始需求l 測試原始需求整理測試原始需求整理l 確定測試規格分析工程方法確定測試規格分析工程方法測試經驗庫 開發需求 協議和規范

11、用戶需求繼承產品需求測試原始需求測試原始需求測試原始需求直接提取繼承性分析繼承性分析直接提取直接提取直接提取分工合作確定工程方法合理規整測試原始需求18l子活動準備（分工組織、工程方法應用策略）子活動準備（分工組織、工程方法應用策略）l運用工程方法進行分析，得出初始的產品測試規格：測試類型分析、功能交互分析、關運用工程方法進行分析，得出初始的產品測試規格：測試類型分析、功能交互分析、關聯圖分析、其他分析方法聯圖分析、其他分析方法l測試特性建模測試特性建模: :從測試角度，劃分出測試特性，并對初始的測試規格進行整合，按照測試從測試角度，劃分出測試特性，并對初始的測試規格進行整合，按照測試特性進行

12、歸類，得到最終具有完整屬性的產品測試規格。特性進行歸類，得到最終具有完整屬性的產品測試規格。修正測試原始需求測試類型分析功能交互分析關聯圖分析其他工程方法初始產品測試規格測試特性建模測試特性測試規格整合產品測試規格修正修正測 試 原 始 需求測試類型分析功能交互分析關聯圖分析其他工程方法初始產品測試規格測試特性測試規格整合產 品 測 試 規格測試特性建模測試特性建模時機的不同產生兩種活動方式測試需求分析活動（測試需求分析活動（3）產品測試規格分析）產品測試規格分析19測試需求分析活動（測試需求分析活動（4）測試規格分解分配）測試規格分解分配l 通過測試特性建模形成測試特性通過測試特性建模形成測

13、試特性l 產品測試規格分解分配到測試特性產品測試規格分解分配到測試特性l 以測試特性為單位進行測試方案設計以測試特性為單位進行測試方案設計l 以測試方案設計任務書形式交付測試方案設計階段以測試方案設計任務書形式交付測試方案設計階段測試方案設計任務書測試特性3測試特性2測試特性1產品測試規格20測試分析設計評估質量測試用例密度覆蓋率ODC評估（不同觸發因素的比率）測試類型評估（不同測試類型的比率）測試用例/每千行代碼不同設計規格的覆蓋率（2/8原則）設計規格的覆蓋率測試需求分析活動（測試需求分析活動（5）測試規格評估）測試規格評估21評估方法評估思路適用范圍備注測試類型評估不同測試類型能否發現不

14、同類型的缺陷，依據測試類型來評估測試分析設計工作是非常必要的，我們必須在產品初期就要規劃測試類型，以期盡可能的發現所有相關類型的缺陷，而不是發現某幾種類型的缺陷針對產品測試規格評估，可以發現測試需求分析中的問題。每種測試類型的比率是否合適，需要建立一個基線設計規格覆蓋率所有的設計規格都應該覆蓋，但是由于部分設計規格不適合做系統測試或者沒有相關測試手段，對于這部分設計規格需要明確提出。針對產品測試規格進行評估，可以給出系統測試可以驗證的覆蓋率對于不能測試的設計規格，應該提出相應的驗證方法（檢視、單元測試等等），這是一種風險，另外，這些設計規格也是可測試性需求的一部分不同設計規格的覆蓋率每個設計規

15、格的使用頻率和發生錯誤的可能性都不一樣，對于風險較大的設計規格，應該依據2/8原則，會設計更多的測試用例。基于這種思路來評估，可以確定我們的設計重點針對產品測試規格評估，明確那些測試規格是重點。這種評估可以測試方案設計的策略測試需求分析活動（測試需求分析活動（6）測試規格評估）測試規格評估22客戶需求產品包需求設計需求設計規格SRSHLDLLDMSTMITMUT產品測試規格測試特性特性測試規格測試用例TSE負責跟蹤PL負責跟蹤測試要同時驗證客戶測試要同時驗證客戶需求、產品包需求、需求、產品包需求、設計需求設計需求測試需求分析活動（測試需求分析活動（7）測試規格跟蹤）測試規格跟蹤23通過編號方案

16、可以弄清楚測試分析設計輸出之間的關系，建立一個跟蹤體系。需求來源：來源編碼XXX 原始需求：特性編碼XXX 初始產品測試規格：工程方法編碼-子類編碼-XXX 產品測試規格：測試特性編碼-大類編碼-子類編碼-XXX 特性測試規格：測試特性編碼-XXX 測試用例：特性測試規格編號-XXX 測試需求分析活動（測試需求分析活動（8）測試規格編號方案）測試規格編號方案24為什么有測試規格維護？產品測試規格基線化；測試輸入產生變更！l開發類來源 ：l變更的客戶需求l產品包需求l產品設計需求l設計規格l概要設計l詳細設計l代碼 l測試類來源 ：l變更的測試經驗庫l測試方案l測試報告等 l更新的基線化輸出產品

17、測試規格、測試用例；l總結的經驗輸出到測試經驗庫中，更新的測試經驗庫的相關內容也是一個輸出；l在測試需求分析報告、測試方案中對于測試分析與設計維護活動的過程和內容的記錄；測試規格維護輸入輸出測試需求分析活動（測試需求分析活動（9）測試規格維護）測試規格維護25目錄目錄 測試需求分析背景測試需求分析背景 測試需求分析理論測試需求分析理論 測試需求分析工程方法測試需求分析工程方法 測試需求分析應用測試需求分析應用26測試需求分析工程方法概圖測試需求分析工程方法概圖產品分析指導書繼承性分析工程方法原始測試需求提取指導書需求來源表原始需求表測試類型分析工程方法功能交互分析工程方法關聯圖分析工程方法產品

18、測試規格分析指導書產品測試規格表(未劃分測試特性)測試特性建模工程方法測試規格整合工程方法產品測試規格表(劃分測試特性)測試規格分解分配指導書測試特性方案設計任務書測試特性交互分析工程方法27推薦的工程方法推薦的工程方法雖然說上面提到的工程方法都是一種參考，大家可以雖然說上面提到的工程方法都是一種參考，大家可以依據實際情況選用，但是從測試視角出發，在測試規格的分依據實際情況選用，但是從測試視角出發，在測試規格的分析活動中，推薦以下三種工程方法：析活動中，推薦以下三種工程方法：n 繼承性分析繼承性分析n 測試類型分析測試類型分析n 功能交互分析功能交互分析28一、繼承性分析繼承性分析29應用背景

19、應用背景n 目前開發的新版本有一個基礎版本，他們之間的關系如何？目前開發的新版本有一個基礎版本，他們之間的關系如何？n 新版本測試策略又是如何制定的？新版本測試策略又是如何制定的？新增和繼承特性什么關系？新增了什么？繼承了什么？該測試哪些？ 版本B 版本A特性1特性2新增特性新增特性新增特性30分析思路（分析思路（1）輸入：輸入： 需求來源表需求來源表 歷史版本的測試報告歷史版本的測試報告 歷史版本的產品的特性清單歷史版本的產品的特性清單及其說明等及其說明等 其它可供參考的資料其它可供參考的資料 輸出：輸出： 測試策略建議測試策略建議 新增原始需求新增原始需求 需要進行功能交互分析需要進行功能

20、交互分析的繼承特性的繼承特性 其它一些過程輸出其它一些過程輸出網上使用情況歷史測試情況應用變化情況交互成熟度失效影響度測試策略建議新增測試原始需求需要作功能交互分析的繼承特性變化獨立繼承特性現狀分析特性交互關系分析 版本B版本A新增特性新增特性繼承特性繼承特性新增特性31分析思路（分析思路（2）來源編號來源編號繼承特性繼承特性失效影響度失效影響度成熟度成熟度繼承方式繼承方式IR001XXX特性交互IR001YYY特性變化IR001ZZZ特性獨立IR001MMM特性交互，變化 失效影響度：失效影響度：特性使用頻度、特性重要性。特性使用頻度、特性重要性。 成熟度：成熟度：經過測試的經過測試的V/R

21、版本數、網上應用情況反饋（應用性質、應版本數、網上應用情況反饋（應用性質、應用范圍、網上問題數量）。用范圍、網上問題數量）。 繼承方式：繼承方式：獨立、交互、變化或者組合。獨立、交互、變化或者組合。32過程與結果過程與結果來源編來源編號號繼承繼承特性特性新特新特性性1新特新特性性2.新特新特性性nIR001XXX特性特性填寫可能相互影響點描述IR001YYY特性特性同上IR001ZZZ特性特性同上IR001MMM特性特性同上繼承特性與新特性交互分析表 來源編號來源編號繼承特性繼承特性應用變化應用變化1應用變化應用變化2.應用變化應用變化nIR001XXX特性應用變化情況1應用變化情況2應用變化

22、情況3IR001YYY特性同上IR001ZZZ特性同上來源編號來源編號繼承特性繼承特性繼承方式繼承方式影響點說明影響點說明IR001XXX特性交互IR001YYY特性變化IR001ZZZ特性交互，變化來源編號來源編號繼承特性繼承特性測試建議測試建議1測試建議測試建議2.IR001XXX特性測試建議1測試建議2IR001YYY特性同上IR001ZZZ特性同上繼承特性變化分析表 需要交互的繼承特性 繼承特性測試建議表 繼承特性失效影響度分析繼承特性成熟度分析 交互 獨立 變化 33二、測試類型二、測試類型分析分析34應用背景應用背景產品應用中出現的問題有各種方面產品應用中出現的問題有各種方面效率易

23、用性可靠性功能性可維護性可移植性質量模型升級擴容不便？界面太差、操作煩雜？定位問題手段少？類似如下情況：其實質量是多維的那么如何發現各類問題呢？測試類型分析!不能僅有功能測試功能異常？35分析思路（分析思路（1）基本過程）基本過程TSETSE召集討論確定測試類型及其子類型召集討論確定測試類型及其子類型明確各測試類型分析思路明確各測試類型分析思路控制分析的粒度控制分析的粒度36分析思路（分析思路（2）使用階段）使用階段測試類型SDVSIT功能測試一致性測試安全性測試性能測試壓力測試配置測試安裝測試恢復測試長時間測試系統指標測試易用性測試備份測試大容量測試流控測試兼容測試互操作測試說明： 表示該測

24、試類型的主要的測試階段； 表示對應測試階段有該測試類型或回歸測試針對不同的測試階段，使用不同的測試類型：針對不同的測試階段，使用不同的測試類型：37分析思路（分析思路（3）建立測試類型庫）建立測試類型庫l 測試類型分析法是從不同的角度來分析和測試產品，不同類型的測試會發現測試類型分析法是從不同的角度來分析和測試產品，不同類型的測試會發現不同類型的不同類型的BugBug，每類測試類型的測試方法也會不同；，每類測試類型的測試方法也會不同；l 通過測試類型的建立，我們可以對整個產品的測試有一個系統的思路，而不通過測試類型的建立，我們可以對整個產品的測試有一個系統的思路，而不是僅僅關注功能測試；是僅僅

25、關注功能測試；l 測試組應該建立并不斷完善自己的測試類型庫。測試組應該建立并不斷完善自己的測試類型庫。多發現25%的測試需求業界公司都建立了完整的測試類型庫拓展了測試思路38三、功能交互三、功能交互分析分析39l 產品功能不是獨立的，功能之間存在交互產品功能不是獨立的，功能之間存在交互l 防止有交互作用的功能的遺漏，提高功能測試的完備性防止有交互作用的功能的遺漏，提高功能測試的完備性l 是功能測試方面的分析，與測試類型分析形成互補是功能測試方面的分析，與測試類型分析形成互補應用背景應用背景產品其他相關功能被測功能功能交互40分析思路（分析思路（1）交互關系）交互關系交互點原始需求與功能特性關系

26、交互點原始需求與功能特性關系影響與約束影響與約束時序關系影響（時間、時序）功能之間存在順序關系功能之間存在交互關系共享關系影響（數據和資源）共享數據影響共享資源影響41分析思路（分析思路（2）基本過程）基本過程橫軸是新增特性和繼承特性，繼承特性來自于繼承性分析的結果橫軸是新增特性和繼承特性，繼承特性來自于繼承性分析的結果分析方法有兩種形式：先標記后分析、直接分析分析方法有兩種形式：先標記后分析、直接分析功能交互分析的結果可以作為測試類型分析的輸入，但是操作復雜，不建議功能交互分析的結果可以作為測試類型分析的輸入，但是操作復雜，不建議這樣應用這樣應用42四、關聯圖四、關聯圖分析分析43l 從用戶

27、角度出發來關注每個用戶從用戶角度出發來關注每個用戶如何使用被測功能特性如何使用被測功能特性如何影響被測功能特性如何影響被測功能特性l 對測試類型分析、功能交互分析的結果進行補充對測試類型分析、功能交互分析的結果進行補充 應用背景應用背景44分析思路分析思路對象用戶2用戶1用戶3用戶1對對象的影響對象對用戶1的影響用戶4用戶3對對象的影響對象對用戶3的影響用戶4對對象的影響對象對用戶4的影響用戶2對對象的影響對象對用戶2的影響確定用戶：對象與外部實體確定用戶：對象與外部實體/ /端點端點確定相互聯系的數據流、物流、行為確定相互聯系的數據流、物流、行為依據不同的用戶類和響應的影響因素，輸出測試規格

28、依據不同的用戶類和響應的影響因素，輸出測試規格用戶類可以是執行者，也可以是應用軟件、系統硬件、目標實體、接口實體或者三維空間、時間等。45分析樣例分析樣例特性用戶類產品測試規格編號產品測試規格定義指定用戶BAM打印維護人員RF-OPERATOR-001設置不同的打印方式RF-OPERATOR-002設置不同的打印級別RF-OPERATOR-003各種界面操作主機/PCRF-HOST-001主機各種復位影響RF-HOST-002PC關機復位影響用戶跟蹤RF-TRACE-001不影響用戶跟蹤RF-TRACE-002不影響BAM打印局域網絡RF-LAN-001局域網故障影響業務實體RF-SERVIC

29、E-001各種典型流程的打印46五、測試特性建模五、測試特性建模47應用背景測試特性和開發特測試特性和開發特性有區別嗎？性有區別嗎？如何合理劃分測試如何合理劃分測試方案？方案？48l 全局因素全局因素：指對大部分特性都有影響的因素，這里指的因素是泛義的，：指對大部分特性都有影響的因素，這里指的因素是泛義的，可以是具體的硬件，也可以是軟件實體，或者是邏輯實體，只要它們的可以是具體的硬件，也可以是軟件實體，或者是邏輯實體，只要它們的變化對大部分特性有影響就可以確定是全局因素。變化對大部分特性有影響就可以確定是全局因素。l 子系統子系統：子系統是一些邏輯相關的模塊集合，可以包括多個模塊。平時：子系統

30、是一些邏輯相關的模塊集合，可以包括多個模塊。平時常說的子系統，比如：話統子系統、話單子系統、維護子系統等等，就常說的子系統，比如：話統子系統、話單子系統、維護子系統等等，就屬于這個范疇。如何合理的劃分子系統，需要參考系統架構設計。屬于這個范疇。如何合理的劃分子系統，需要參考系統架構設計。 基本概念（基本概念（1）49l 測試特性劃分：測試特性劃分：由于開發和測試之間的分解分配思路不一樣，測試需由于開發和測試之間的分解分配思路不一樣，測試需要從要從提高測試設計與執行的質量和效率提高測試設計與執行的質量和效率出發建立測試自己的模型，避出發建立測試自己的模型，避免測試按照設計規格分解分配思路（模塊）

31、來分配測試方案，從功能免測試按照設計規格分解分配思路（模塊）來分配測試方案，從功能和測試類型兩個角度進行測試特性劃分，劃分過程中考慮以下幾個方和測試類型兩個角度進行測試特性劃分，劃分過程中考慮以下幾個方面的因素：面的因素： 開發特性或者功能開發特性或者功能 BuildBuild劃分劃分 系統架構（模塊）系統架構（模塊） 全局因素或者技術風險分析全局因素或者技術風險分析 測試組人員技能測試組人員技能基本概念（基本概念（2）50SDV/SIT所有的測試用例分布在不同的測試特性中，隨著每個Build構建完成，需要確定SDV/SIT測試策略； Build （SDV）測試執行策略需要考慮如何回歸，并保證

32、功能交互測試的完備性；圖例中，Build B首先需要對Build A進行回歸，確保BuildA沒有出現新問題，同時補充測試兩者之間的功能交互的測試用例，然后再執行測試特性3和測試特性4的相關測試用例。測試特性1測試特性2測試特性3測試特性4測試特性5測試特性6Build ABuild BBuild CTR4測試策略測試策略劃分測試特性SDV/SIT策略決定測試用例如何執行基本概念（基本概念（3）51基本過程（基本過程（1）測試特性分解分配測試規格測試類型全局因素測試方案設計任務書測試特性模型n 測試特性建模的主要目的是劃分測試特性，明確每個測試特性的內容測試特性建模的主要目的是劃分測試特性，明

33、確每個測試特性的內容和邊界。原則上，一個測試方案對應一個測試特性。和邊界。原則上，一個測試方案對應一個測試特性。 52子系統1子系統2子系統3子系統4子系統5全局因素1全局因素2全局因素3全局因素4測試特性功能1TCCCC功能測試特性1功能2CTCS功能測試特性2功能3TCXCC功能測試特性3功能4CCTSC功能測試特性3功能5CTCTCC功能測試特性5測試特性功能測試特性6功能測試特性8功能測試特性9n T 對應的功能和子系統關聯密切，主要實現在該子系統中，適合在該功能的測試特性中測試，強調以功能為主導的思想。n C 功能和該子系統有接口，關系比較松散，可以將該子系統作為檢查點對待n X 對

34、應的功能和子系統關系松散，子系統可以作為功能測試特性的主要檢查點; 但是為確保這種關系深入測試，在子系統或者全局因素特性中，要作為主要內容進行測試n S 對應的功能和子系統關聯松散，不過子系統作為功能測試特性的檢查點不合適，在子系統或者全局因素特性中，要作為主要內容進行測試基本過程（基本過程（2）53功能測試特性1功能測試特性2功能測試特性3功能測試特性4功能測試特性5功能測試特性6功能測試特性7測試特性測試類型1TTTTTTT非功能測試特性1測試類型2TTTTT非功能測試特性2；非功能測試特性4測試類型3OOOOOO測試類型4NNNNNNN非功能測試特性3測試類型5XXTTT非功能測試特性5

35、nT 測試類型獨特雖然和測試特性有關系，但是有自己的獨特測試方法，建議獨立劃分到非功能測試特性nX 測試類型一部分和功能測試特性關系密切，測試方法和功能測試相同，這部分適合放在功能測試特性中測試，一部分有自己獨特的測試方法，建議獨立劃分非功能測試特性。nO 測試類型和功能測試特性關系密切，測試方法和功能測試相同，建議劃分到相應的功能測試特性中。nN 測試類型和功能測試特性關系不緊密，需要單獨劃分非功能測試特性 基本過程（基本過程（3）54分析樣例分析樣例55六、測試規格整合六、測試規格整合56應用背景應用背景測類型分析功能交互分析關聯圖分析初始產品測試規格存在很多冗余沒有跟蹤關系測試規格整合5

36、7基本思路基本思路測試建模測試特性樹建立測試規格分配測試規格合并測試規格整合如果建模不能滿足要求如果特性樹遺漏根據特性整合要求刪除冗余和合并測試規格測試規格分析1. 松散的測試規格2. 特性樹3. 已分配測試規格 4. 合并后測試規格 5. 整合后測試規格 測試規格分解分配58測試規格整合樣例測試規格整合樣例l New：在測試規格中新增一項測試規格l Repeated：該測試規格已存在l Combined：將測試規格歸入到一條已經存在的測試需求。如果原始測試規格A/B 合并成一條測試規格X, 則其中只有一個是新增，其它都是合并。59目錄目錄 測試需求分析背景測試需求分析背景 測試需求分析理論測

37、試需求分析理論 測試需求分析工程方法測試需求分析工程方法 測試需求分析應用測試需求分析應用60什么時候進行測試需求分析？什么時候進行測試需求分析？產品測試需求分析測試規格分解分配產品測試規格特性測試需求分析分配后測試規格特性測試規格特性測試設計測試項系統規格SRS（參考）測試用例設計測試用例TR2產品分析產品包需求TR1TR3TR461測試參與測試參與TR的方式的方式測試參與開發文檔評審的一個原則是，必須先要輸出自己的交付件，才能參測試參與開發文檔評審的一個原則是，必須先要輸出自己的交付件，才能參加開發的文檔評審：加開發的文檔評審：先有測試分析，后有開發文檔評審參與先有測試分析，后有開發文檔評

38、審參與在參與開發評審前，測試應該完成了自己的輸出，帶著問題參加評審，在參與開發評審前，測試應該完成了自己的輸出，帶著問題參加評審，效果就會不同，參與評審，也是為了解答自己的問題。因此，在效果就會不同，參與評審，也是為了解答自己的問題。因此，在TR2時，時，必須先完成測試規格。必須先完成測試規格。保留評審不改問題的測試規格保留評審不改問題的測試規格測試參與評審提出的問題，開發答復不需要修改或者風險較小，這部分測試參與評審提出的問題，開發答復不需要修改或者風險較小，這部分的測試規格也應該保留，只是不用進行分配和測試。如果網上發現問題的測試規格也應該保留，只是不用進行分配和測試。如果網上發現問題和這

39、些內容相關，測試就有據可查，是風險分析的一個參考內容。和這些內容相關，測試就有據可查，是風險分析的一個參考內容。 62測試需求分析應用原則測試需求分析應用原則測試需求分析報告產品分析測試規格分解分配產品測試規格分析測試原始需求提取需求來源表測試原始需求表產品測試規格表測試方案設計工作任務書n過程記錄和結果分開（過程記錄和結果分開（測試需求分析報告測試需求分析報告與結果表與結果表測試分析設計表測試分析設計表分開）分開）n活動可以裁減，工程方法是參考，工程方法有一定的使用環境活動可以裁減，工程方法是參考，工程方法有一定的使用環境n每個工程方法都有明確的輸出，但是每個活動的結果可以脫離于工程方法每個

40、工程方法都有明確的輸出，但是每個活動的結果可以脫離于工程方法結果表輸出過程記錄輸出工程方法63關于測試規格的理解關于測試規格的理解l 業界公司的實踐提出，不管設計規格是否完善都要建立測試需求，我們稱為測試規格；測試規格；l 測試規格是測試對于產品設計規格分析之后的產物；l 測試分析設計整體思路都是圍繞著測試規格來開展的；l 如果產品設計規格是測試的“客戶需求”，那么測試規格就是測試的“產品設計規格”；64l 測試粒度是指一個測試焦點的精細度或粗糙度 l 測試粒度是一個譜，而不是一系列的“是/或”類別 l 一個高粒度的測試方案允許測試人員檢查低級別的細節，一般是系統的內部；低粒度的測試方案為測試

41、人員提供一般的系統行為信息 “純”結構化（白盒）測試“純”行為化（黑盒）測試“純”現場測試開發測試技術支援關于測試規格粒度的理解（關于測試規格粒度的理解（1）65l 測試規格的粒度應該把握灰度原則灰度原則，建議各測試組在進行需求分析之前，內部經過充分討論，就粒度問題達成共識； l 盡可能的從不同側面分析（測試類型、功能交互等）測試原始需求，給出初始的測試規格，可能會產生冗余，此時不要過分要求初始測試規格的粒度統一，在測試規格整合時考慮粒度統一問題；l 對于一些較為清晰的功能，相似的子功能可以組合在一起描述，作為一個測試規格對待。比如：涉及到一個表格的設置，我們可以將增加、修改、刪除等作為一個測

42、試規格，大家一目了然，沒有歧異；（CRUD原則）l 測試規格應該是完整地描述從用戶角度出發所能看到的需求，而不是一個需求的片斷，比如：彩鈴業務的建立、釋放是需求的片斷，用戶是看不到這一點的，建議這樣描述：彩鈴業務基本呼叫，考慮各種釋放情況把握灰度把握灰度用戶可見用戶可見關于測試規格粒度的理解（關于測試規格粒度的理解（2）66l 對于大家常見的分析思路，可以通過經驗庫的形式進行傳遞和統一。比如：常見的組網模型、常見的用戶分類以及各種用戶常見的操作等等；l 測試規格的描述要清晰，不能有混淆的地方，在測試方案設計階段，可以直接對測試規格進行細化，而不用參考其他的文檔即可。比如：要考慮各種異常情況下的

43、基本呼叫功能，這個測試規格就不是十分清晰，可以進一步給出具體的異常類別形成新的測試規格，比如：要考慮主叫各種異常釋放情況下的基本呼叫；要考慮A接口各種異常情況下的基本呼叫等等。l 測試規格的粒度，不僅僅和測試需求分析的思路有關，而且和測試原始需求的粒度有關。建議對于測試原始需求也要進行整理、合并、分解，只羅列從用戶角度所看到的功能和非功能，其他的細節可以作為這些內容的附件，在測試需求分析中考慮。比如：支持彩鈴業務的觸發、建立，可以合并為彩鈴業務的基本呼叫（觸發、建立作為附件）。前后聯系傳遞經驗積累約定關于測試規格粒度的理解（關于測試規格粒度的理解（3）67測試經理(PM)項目經理(PL)測試工

44、程師 (TE)項目經理(PL)項目經理(PL)測試工程師 (TE)測試工程師 (TE)測試工程師 (TE)測試工程師 (TE)測試系統工程師(TSE)項 目 經 理（PL）測試高級工程師（STE）TSE是測試分析設計的靈魂人物，他組織產品的技術決策，職責是：負責測試需求分析階段的相關活動對最終的產品測試規格完備性、正確性負責負責設計規格測試規格測試特性的需求跟蹤負責劃分測試特性，確保合理性和完備性指導測試方案設計工作測試需求分析的組織與職責測試需求分析的組織與職責68產品分析原始需求提取產品測試規格分析質量評估測試規格分解分配TSE任務分工選擇模型組建測試系統組Chart客戶需求；產品規模；人力資源；測試組模式測試分析設計模型；測試需求分析報告客戶需求；產品包需求；規范協議；經驗庫需求來源表；測試需求分析報告測試規格基線化客戶需求；產品包需求；規范協議；經驗庫；繼承特性原始需求表；繼承特性；測試需求分析報告；繼承特性；原始需求表；測試類型；全局因素產品測試規格；測試特性；測試需求分析報