測試需求分析

1、（測試需求分析）,目錄,測試需求分析背景測試需求分析理論測試需求分析工程方法測試需求分析應用,為什么要做測試需求分析？,測試了很多，還有這么多網(wǎng)上問題？,客戶到底關(guān)心什么？,不知道如何站在客戶立場測試？,網(wǎng)上問題漏測：測試設(shè)計不充分60%！,這些問題怎么沒有考慮到？,需要做測試需求分析！,現(xiàn)狀？,測試對象分析,測試用例設(shè)計（方案內(nèi)的）,測試用例,測試輸入,TR3,TR4,沒有測試需求分析過程,測試經(jīng)理口頭分配測試方案任務(wù)不明確,測試對象分析側(cè)重測試方案內(nèi)部實現(xiàn),現(xiàn)狀存在什么問題？,測試過程與結(jié)果缺乏質(zhì)量評估與控制,過多關(guān)注功能實現(xiàn)、產(chǎn)品質(zhì)量維度關(guān)注不全面,沒有統(tǒng)一成熟的分析設(shè)計工程方法支撐,業(yè)

2、界情況,SDT公司測試分析設(shè)計IBM的測試設(shè)計七步法某路由器公司的測試階段和測試類型MOTO故障插入測試,以業(yè)界公司為標桿，建立自己的測試分析設(shè)計體系,借鑒業(yè)界公司的經(jīng)驗，總結(jié)相關(guān)工程方法,好的示例,測試需求分析業(yè)界介紹（SDT公司）,TestFrame的測試設(shè)計模式,測試劃分,測試需求分析,業(yè)界思路總結(jié),測試類型測試劃分強調(diào)測試需求分析，測試需求不僅僅來自需求文檔電子表格是支撐測試分析設(shè)計的主要工具(我現(xiàn)在常用的是freemind,先分解劃塊兒，在分塊細化),不同類型的測試會發(fā)現(xiàn)不同類型的Bug。測試類型是從不同的角度來分析和測試產(chǎn)品,目錄,測試需求分析背景測試需求分析理論測試需求分析工程方

3、法測試需求分析應用,測試需求分析目的,清晰把握測試需求！,時刻關(guān)注產(chǎn)品質(zhì)量！,測試需求分析目的是：明確應該測試什么。即明確測試需求，其核心是產(chǎn)品質(zhì)量。產(chǎn)品質(zhì)量就是符合用戶的明確的或隱含的需求的程度。需求文檔中的產(chǎn)品需求、系統(tǒng)設(shè)計需求是明確的需求未在需求文檔中明確的隱含的用戶需求也是我們需要分析的，如用戶使用產(chǎn)品方式、感受、業(yè)務(wù)習慣Testrequirementsareusefulsetsofinputthatshouldbetested.BrianMarick,測試需求分析的目的？,測試需求分析基本概念（1）測試視角,測試類型,功能交互,產(chǎn)品繼承,分解分配,測試有哪些獨特的視角？,測試與開發(fā)的

4、思路有哪些不同？,測試的視角體現(xiàn)了測試的思維活動這四個視角是工程方法的基礎(chǔ),測試需求分析基本概念（2）活動框架（1）,產(chǎn)品測試需求分析,測試規(guī)格分解分配,產(chǎn)品測試規(guī)格,特性測試需求分析,分配后測試規(guī)格,特性測試設(shè)計,測試設(shè)計維護,特性測試規(guī)格,測試用例,設(shè)計規(guī)格協(xié)議/規(guī)范/標準測試分析經(jīng)驗庫,SRS協(xié)議/規(guī)范測試設(shè)計經(jīng)驗庫其他輸入,測試需求分析,測試方案設(shè)計,測試用例設(shè)計,測試用例設(shè)計,測試用例,測試用例設(shè)計維護,產(chǎn)品分析,產(chǎn)品包需求設(shè)計需求,僅做參考,測試需求分析基本概念（3）活動框架（2）,測試需求分析基本概念（3）活動框架（2）,產(chǎn)品測試需求分析,特性測試需求分析,特性測試設(shè)計,測試用例

5、設(shè)計,SRS,HLD,LLD,CODING,測試需求分析活動類比開發(fā)活動圖,階段,產(chǎn)品分析,測試規(guī)格分解分配,特性測試需求分析,特性測試設(shè)計,測試用例設(shè)計,活動/子活動,結(jié)果輸出,測試需求分析,測試方案設(shè)計,產(chǎn)品測試規(guī)格分析,原始需求提取,產(chǎn)品測試需求分析,測試類型分析；功能交互分析；關(guān)聯(lián)圖分析；測試特性建模；測試規(guī)格整合測試特性交互分析,測試組網(wǎng)分析；判定表；因果圖；測試場景分析正交測試分析法正交試驗設(shè)計法,等價類劃分；邊界值；因果圖；正交試驗設(shè)計法；,測試分析設(shè)計表之需求來源表,測試分析設(shè)計表之原始需求表,測試分析設(shè)計表之產(chǎn)品測試規(guī)格表；測試需求分析報告.doc,特性測試工作任務(wù)書.doc

6、,測試分析設(shè)計表之特性測試規(guī)格表,測試分析設(shè)計表之測試用例表,原始需求提取方法繼承性分析,工程方法,測試需求分析基本概念（4）活動框架（3）,測試需求分析基本概念（5）名詞解釋,測試原始需求：產(chǎn)品測試規(guī)格分析的輸入，是從產(chǎn)品包需求、系統(tǒng)需求、測試經(jīng)驗庫等需求來源中提取的經(jīng)過整理的輸入集合。測試規(guī)格：測試規(guī)格是產(chǎn)品測試規(guī)格和特性測試規(guī)格的通稱。一般而言，我們所說的測試規(guī)格都是指產(chǎn)品測試規(guī)格。產(chǎn)品測試規(guī)格是對客戶需求、產(chǎn)品包需求、設(shè)計需求、設(shè)計規(guī)格以及其它可能的需求進行綜合的測試分析，從測試角度分析并整合形成的測試需求集合，明確了測試應該測試什么。產(chǎn)品測試規(guī)格經(jīng)過相關(guān)整理后相互之間沒有重復，每條產(chǎn)

7、品測試規(guī)格都有唯一的標識。測試特性：邏輯上相關(guān)的產(chǎn)品測試規(guī)格集合，可以是功能性的產(chǎn)品測試規(guī)格集合，也可以是非功能性的產(chǎn)品測試規(guī)格集合。邏輯相關(guān)性，指的是按照一定的規(guī)則進行劃分，這個規(guī)則是個廣義的規(guī)則，區(qū)別于開發(fā)按照功能進行劃分的特性。,測試需求分析活動（1）產(chǎn)品分析,產(chǎn)品分析主要是產(chǎn)品知識前期學習和熟悉確定產(chǎn)品測試需求分析的來源確定測試分析設(shè)計策略,這個產(chǎn)品/版本是什么？趕緊學習相關(guān)資料！,下一步如何分析？,測試需求分析活動（2）提取測試原始需求,子活動準備（分工組織、提取策略）提取測試原始需求測試原始需求整理確定測試規(guī)格分析工程方法,子活動準備（分工組織、工程方法應用策略）運用工程方法進行分

8、析，得出初始的產(chǎn)品測試規(guī)格：測試類型分析、功能交互分析、關(guān)聯(lián)圖分析、其他分析方法測試特性建模:從測試角度，劃分出測試特性，并對初始的測試規(guī)格進行整合，按照測試特性進行歸類，得到最終具有完整屬性的產(chǎn)品測試規(guī)格。,修正,測試原始需求,測試類型分析功能交互分析關(guān)聯(lián)圖分析其他工程方法,初始產(chǎn)品測試規(guī)格,測試特性建模,測試特性,測試規(guī)格整合,產(chǎn)品測試規(guī)格,修正,修正,測試原始需求,測試類型分析功能交互分析關(guān)聯(lián)圖分析其他工程方法,初始產(chǎn)品測試規(guī)格,測試特性,測試規(guī)格整合,產(chǎn)品測試規(guī)格,測試特性建模,測試特性建模時機的不同產(chǎn)生兩種活動方式,測試需求分析活動（3）產(chǎn)品測試規(guī)格分析,測試需求分析活動（4）測試規(guī)

9、格分解分配,通過測試特性建模形成測試特性產(chǎn)品測試規(guī)格分解分配到測試特性以測試特性為單位進行測試方案設(shè)計以測試方案設(shè)計任務(wù)書形式交付測試方案設(shè)計階段,測試分析設(shè)計評估,質(zhì)量,測試用例密度,覆蓋率,ODC評估（不同觸發(fā)因素的比率）測試類型評估（不同測試類型的比率）,測試用例/每千行代碼,不同設(shè)計規(guī)格的覆蓋率（2/8原則）設(shè)計規(guī)格的覆蓋率,測試需求分析活動（5）測試規(guī)格評估,測試需求分析活動（6）測試規(guī)格評估,TSE負責跟蹤,PL負責跟蹤,測試要同時驗證客戶需求、產(chǎn)品包需求、設(shè)計需求,測試需求分析活動（7）測試規(guī)格跟蹤,通過編號方案可以弄清楚測試分析設(shè)計輸出之間的關(guān)系，建立一個跟蹤體系。需求來源：來

10、源編碼XXX原始需求：特性編碼XXX初始產(chǎn)品測試規(guī)格：工程方法編碼-子類編碼-XXX產(chǎn)品測試規(guī)格：測試特性編碼-大類編碼-子類編碼-XXX特性測試規(guī)格：測試特性編碼-XXX測試用例：特性測試規(guī)格編號-XXX,測試需求分析活動（8）測試規(guī)格編號方案,測試需求分析活動（9）測試規(guī)格維護,目錄,測試需求分析背景測試需求分析理論測試需求分析工程方法測試需求分析應用,測試需求分析工程方法概圖,推薦的工程方法,雖然說上面提到的工程方法都是一種參考，大家可以依據(jù)實際情況選用，但是從測試視角出發(fā)，在測試規(guī)格的分析活動中，推薦以下三種工程方法：繼承性分析測試類型分析功能交互分析,一、繼承性分析,應用背景,目前開

11、發(fā)的新版本有一個基礎(chǔ)版本，他們之間的關(guān)系如何？新版本測試策略又是如何制定的？,分析思路（1）,輸入：需求來源表歷史版本的測試報告歷史版本的產(chǎn)品的特性清單及其說明等其它可供參考的資料,輸出：測試策略建議新增原始需求需要進行功能交互分析的繼承特性其它一些過程輸出,分析思路（2）,失效影響度：特性使用頻度、特性重要性。成熟度：經(jīng)過測試的V/R版本數(shù)、網(wǎng)上應用情況反饋（應用性質(zhì)、應用范圍、網(wǎng)上問題數(shù)量）。繼承方式：獨立、交互、變化或者組合。,過程與結(jié)果,繼承特性與新特性交互分析表,繼承特性變化分析表,需要交互的繼承特性,繼承特性測試建議表,繼承特性失效影響度分析繼承特性成熟度分析,交互,獨立,變化,二

12、、測試類型分析,應用背景,產(chǎn)品應用中出現(xiàn)的問題有各種方面,分析思路（1）基本過程,TSE召集討論確定測試類型及其子類型明確各測試類型分析思路控制分析的粒度,分析思路（2）使用階段,說明：表示該測試類型的主要的測試階段；表示對應測試階段有該測試類型或回歸測試,針對不同的測試階段，使用不同的測試類型：,分析思路（3）建立測試類型庫,測試類型分析法是從不同的角度來分析和測試產(chǎn)品，不同類型的測試會發(fā)現(xiàn)不同類型的Bug，每類測試類型的測試方法也會不同；通過測試類型的建立，我們可以對整個產(chǎn)品的測試有一個系統(tǒng)的思路，而不是僅僅關(guān)注功能測試；測試組應該建立并不斷完善自己的測試類型庫。,三、功能交互分析,產(chǎn)品功

13、能不是獨立的，功能之間存在交互防止有交互作用的功能的遺漏，提高功能測試的完備性是功能測試方面的分析，與測試類型分析形成互補,應用背景,產(chǎn)品其他相關(guān)功能,被測功能,功能交互,分析思路（1）交互關(guān)系,分析思路（2）基本過程,橫軸是新增特性和繼承特性，繼承特性來自于繼承性分析的結(jié)果分析方法有兩種形式：先標記后分析、直接分析功能交互分析的結(jié)果可以作為測試類型分析的輸入，但是操作復雜，不建議這樣應用,四、關(guān)聯(lián)圖分析,從用戶角度出發(fā)來關(guān)注每個用戶如何使用被測功能特性如何影響被測功能特性對測試類型分析、功能交互分析的結(jié)果進行補充,應用背景,分析思路,確定用戶：對象與外部實體/端點確定相互聯(lián)系的數(shù)據(jù)流、物流、

14、行為依據(jù)不同的用戶類和響應的影響因素，輸出測試規(guī)格,用戶類可以是執(zhí)行者，也可以是應用軟件、系統(tǒng)硬件、目標實體、接口實體或者三維空間、時間等。,分析樣例,五、測試特性建模,應用背景,全局因素：指對大部分特性都有影響的因素，這里指的因素是泛義的，可以是具體的硬件，也可以是軟件實體，或者是邏輯實體，只要它們的變化對大部分特性有影響就可以確定是全局因素。子系統(tǒng)：子系統(tǒng)是一些邏輯相關(guān)的模塊集合，可以包括多個模塊。平時常說的子系統(tǒng)，比如：話統(tǒng)子系統(tǒng)、話單子系統(tǒng)、維護子系統(tǒng)等等，就屬于這個范疇。如何合理的劃分子系統(tǒng)，需要參考系統(tǒng)架構(gòu)設(shè)計。,基本概念（1）,測試特性劃分：由于開發(fā)和測試之間的分解分配思路不一樣

15、，測試需要從提高測試設(shè)計與執(zhí)行的質(zhì)量和效率出發(fā)建立測試自己的模型，避免測試按照設(shè)計規(guī)格分解分配思路（模塊）來分配測試方案，從功能和測試類型兩個角度進行測試特性劃分，劃分過程中考慮以下幾個方面的因素：開發(fā)特性或者功能Build劃分系統(tǒng)架構(gòu)（模塊）全局因素或者技術(shù)風險分析測試組人員技能,基本概念（2）,SDV/SIT所有的測試用例分布在不同的測試特性中，隨著每個Build構(gòu)建完成，需要確定SDV/SIT測試策略；Build（SDV）測試執(zhí)行策略需要考慮如何回歸，并保證功能交互測試的完備性；圖例中，BuildB首先需要對BuildA進行回歸，確保BuildA沒有出現(xiàn)新問題，同時補充測試兩者之間的功能

16、交互的測試用例，然后再執(zhí)行測試特性3和測試特性4的相關(guān)測試用例。,基本概念（3）,基本過程（1）,測試特性建模的主要目的是劃分測試特性，明確每個測試特性的內(nèi)容和邊界。原則上，一個測試方案對應一個測試特性。,T對應的功能和子系統(tǒng)關(guān)聯(lián)密切，主要實現(xiàn)在該子系統(tǒng)中，適合在該功能的測試特性中測試，強調(diào)以功能為主導的思想。C功能和該子系統(tǒng)有接口，關(guān)系比較松散，可以將該子系統(tǒng)作為檢查點對待X對應的功能和子系統(tǒng)關(guān)系松散，子系統(tǒng)可以作為功能測試特性的主要檢查點;但是為確保這種關(guān)系深入測試，在子系統(tǒng)或者全局因素特性中，要作為主要內(nèi)容進行測試S對應的功能和子系統(tǒng)關(guān)聯(lián)松散，不過子系統(tǒng)作為功能測試特性的檢查點不合適，在

17、子系統(tǒng)或者全局因素特性中，要作為主要內(nèi)容進行測試,基本過程（2）,T測試類型獨特雖然和測試特性有關(guān)系，但是有自己的獨特測試方法，建議獨立劃分到非功能測試特性X測試類型一部分和功能測試特性關(guān)系密切，測試方法和功能測試相同，這部分適合放在功能測試特性中測試，一部分有自己獨特的測試方法，建議獨立劃分非功能測試特性。O測試類型和功能測試特性關(guān)系密切，測試方法和功能測試相同，建議劃分到相應的功能測試特性中。N測試類型和功能測試特性關(guān)系不緊密，需要單獨劃分非功能測試特性,基本過程（3）,分析樣例,六、測試規(guī)格整合,應用背景,基本思路,測試規(guī)格整合樣例,New：在測試規(guī)格中新增一項測試規(guī)格Repeated：

18、該測試規(guī)格已存在Combined：將測試規(guī)格歸入到一條已經(jīng)存在的測試需求。如果原始測試規(guī)格A/B合并成一條測試規(guī)格X,則其中只有一個是新增，其它都是合并。,目錄,測試需求分析背景測試需求分析理論測試需求分析工程方法測試需求分析應用,什么時候進行測試需求分析？,測試參與TR的方式,測試參與開發(fā)文檔評審的一個原則是，必須先要輸出自己的交付件，才能參加開發(fā)的文檔評審：先有測試分析，后有開發(fā)文檔評審參與在參與開發(fā)評審前，測試應該完成了自己的輸出，帶著問題參加評審，效果就會不同，參與評審，也是為了解答自己的問題。因此，在TR2時，必須先完成測試規(guī)格。保留評審不改問題的測試規(guī)格測試參與評審提出的問題，開發(fā)

19、答復不需要修改或者風險較小，這部分的測試規(guī)格也應該保留，只是不用進行分配和測試。如果網(wǎng)上發(fā)現(xiàn)問題和這些內(nèi)容相關(guān)，測試就有據(jù)可查，是風險分析的一個參考內(nèi)容。,測試需求分析應用原則,測試需求分析報告,產(chǎn)品分析,測試規(guī)格分解分配,產(chǎn)品測試規(guī)格分析,測試原始需求提取,需求來源表,測試原始需求表,產(chǎn)品測試規(guī)格表,測試方案設(shè)計工作任務(wù)書,過程記錄和結(jié)果分開（測試需求分析報告與結(jié)果表測試分析設(shè)計表分開）活動可以裁減，工程方法是參考，工程方法有一定的使用環(huán)境每個工程方法都有明確的輸出，但是每個活動的結(jié)果可以脫離于工程方法,結(jié)果表輸出,過程記錄輸出,工程方法,關(guān)于測試規(guī)格的理解,業(yè)界公司的實踐提出，不管設(shè)計規(guī)格

20、是否完善都要建立測試需求，我們稱為測試規(guī)格；測試規(guī)格是測試對于產(chǎn)品設(shè)計規(guī)格分析之后的產(chǎn)物；測試分析設(shè)計整體思路都是圍繞著測試規(guī)格來開展的；如果產(chǎn)品設(shè)計規(guī)格是測試的“客戶需求”，那么測試規(guī)格就是測試的“產(chǎn)品設(shè)計規(guī)格”；,測試粒度是指一個測試焦點的精細度或粗糙度測試粒度是一個譜，而不是一系列的“是/或”類別一個高粒度的測試方案允許測試人員檢查低級別的細節(jié)，一般是系統(tǒng)的內(nèi)部；低粒度的測試方案為測試人員提供一般的系統(tǒng)行為信息,關(guān)于測試規(guī)格粒度的理解（1）,測試規(guī)格的粒度應該把握灰度原則，建議各測試組在進行需求分析之前，內(nèi)部經(jīng)過充分討論，就粒度問題達成共識；盡可能的從不同側(cè)面分析（測試類型、功能交互等）

21、測試原始需求，給出初始的測試規(guī)格，可能會產(chǎn)生冗余，此時不要過分要求初始測試規(guī)格的粒度統(tǒng)一，在測試規(guī)格整合時考慮粒度統(tǒng)一問題；對于一些較為清晰的功能，相似的子功能可以組合在一起描述，作為一個測試規(guī)格對待。比如：涉及到一個表格的設(shè)置，我們可以將增加、修改、刪除等作為一個測試規(guī)格，大家一目了然，沒有歧異；（CRUD原則）測試規(guī)格應該是完整地描述從用戶角度出發(fā)所能看到的需求，而不是一個需求的片斷，比如：彩鈴業(yè)務(wù)的建立、釋放是需求的片斷，用戶是看不到這一點的，建議這樣描述：彩鈴業(yè)務(wù)基本呼叫，考慮各種釋放情況,把握灰度,用戶可見,關(guān)于測試規(guī)格粒度的理解（2）,對于大家常見的分析思路，可以通過經(jīng)驗庫的形式進行傳遞和統(tǒng)一。比如：常見的組網(wǎng)模型、常見的用戶分類以及各種用戶常見的操作等等；測試規(guī)格的描述要清晰，不能有混淆的地方，在測試方案設(shè)計階段，可以直接對測試規(guī)格進行細化，而不用參考其他的文檔即可。比如：要考慮各種異常情況下的基本呼叫功能，這個測試規(guī)格就不是十分清晰，可以進一步給出具體的異常類別形成新的測試規(guī)格，比如：要考慮主叫各種異常釋放情況下的基本呼叫；要考慮A接口各種異常情況下的基本呼叫等等。測試規(guī)格的粒度，不