嵌入式軟件白盒測試技術(shù)

領(lǐng)測技術(shù)（EzTester）簡介嵌入式軟件白盒測試技術(shù)——第4代白盒測試方法的理論與實踐ApprovedbyWAYNEWorkStudio

At2007/05/18講師介紹講師：WayneChan(wayne@ezT)任職經(jīng)歷曾在HW公司工作8年（1997～2004），先后擔(dān)任測試技術(shù)經(jīng)理、公司測試系統(tǒng)工程師、公司測試技術(shù)總架構(gòu)師等職務(wù)，是HW公司白盒測試技術(shù)體系的締造者。2005年~2007年，擔(dān)任測試技術(shù)咨詢專家，為眾多公司提供測試技術(shù)專項咨詢服務(wù)，幫助企業(yè)構(gòu)建和推廣測試技術(shù)體系。專業(yè)背景在嵌入式軟件白盒測試領(lǐng)域擁有15年從業(yè)經(jīng)驗，具備豐富的測試技術(shù)背景和測試技術(shù)管理經(jīng)驗。從1997年開始主導(dǎo)HW公司交換機產(chǎn)品實踐白盒測試，是國內(nèi)較早在測試技術(shù)領(lǐng)域有研究的專家。主導(dǎo)HW公司白盒測試平臺體系的研發(fā)，歷經(jīng)五年最終在全公司形成規(guī)模應(yīng)用（超過5000人使用）業(yè)界第四代白盒測試方法的主要倡導(dǎo)者，該方法論已被維普資訊納入科技文獻檢索，所涉及數(shù)項核心技術(shù)已申請美國專利。主導(dǎo)規(guī)劃了CSE測試腳本語言和VcTester嵌入式軟件白盒測試體系，其中CSE是中國第一個具備世界水平的腳本語言體系。2000年被派往印度主管測試工具合作項目，與印度infosys、BFL等公司開展合作，深入學(xué)習(xí)了印度軟件業(yè)的測試技術(shù)和方法。目錄課程介紹單元一：白盒測試基本概念單元二：嵌入式白盒測試遵循的理念-----------------------------------------單元三：嵌入式軟件測試設(shè)計技術(shù)單元四：嵌入式軟件測試評估技術(shù)單元五：第4代白盒測試方法單元六：如何組織嵌入式軟件白盒測試<課后材料清單，選講內(nèi)容>本課程目標：理解白盒測試技術(shù)的演進過程與發(fā)展趨勢深入理解嵌入式軟件白盒測試的主要困難與解決對策掌握第四代白盒測試方法論，包括3個關(guān)鍵域、9個關(guān)鍵特征掌握如何實施嵌入式軟件在線白盒測試？包括在線測試驅(qū)動、在線腳本樁、在線測試改進等掌握如何開展嵌入式軟件的持續(xù)集成測試？掌握如何有效設(shè)計白盒測試用例，如何評價白盒測試的完備性?掌握如何對白盒測試問題進行分析，找出問題根源？掌握如何進行嵌入式軟件白盒自動化測試規(guī)劃和設(shè)計，確保測試腳本的持續(xù)重用了解業(yè)界都有哪些主流的嵌入式白盒測試工具，掌握如何選型？了解業(yè)界優(yōu)秀公司嵌入式軟件白盒測試的方法和經(jīng)驗學(xué)習(xí)目標課程難度偏高課程風(fēng)格HighMiddleLow注重實踐性兩個重點做正確的事！正確的做事！目錄白盒測試基本概念什么是白盒測試?白盒測試在研發(fā)全流程中的位置單元測試與集成測試是什么？不是什么？企業(yè)不做白盒測試的主要原因白盒測試三種境界為什么要做白盒測試？實施白盒測試的差異性驗證白盒測試抽象模型嵌入式軟件的白盒測試特點嵌入式白盒測試遵循的理念嵌入式軟件測試設(shè)計技術(shù)嵌入式軟件測試評估技術(shù)第4代白盒測試方法如何組織嵌入式軟件白盒測試什么是白盒測試？白盒測試是一種“軟件測試”狹義“軟件測試”的定義1990年的IEEE/ANSI標準(IEEE/ANSI,1990[Std610.12-1990])：

在既定的狀況條件下，運行一個系統(tǒng)或組件，觀察記錄結(jié)果，并對其某些方面進行評價的過程。1979年GlenfordJ.Myers在《TheArtofSoftwareTesting》中定義：軟件測試是為了發(fā)現(xiàn)錯誤而運行程序的過程。廣義“軟件測試”由驗證、確認、測試3個方面組成驗證：檢測軟件開發(fā)的每個階段、每個步驟的結(jié)果是否正確無誤，是否與軟件開發(fā)各階段的要求或期望的結(jié)果相一致。驗證意味著確保軟件會正確無誤地實現(xiàn)軟件的需求，開發(fā)過程是沿著正確的方向進行的。確認：評估將要開發(fā)的軟件產(chǎn)品是否正確無誤、可行和有價值的。確認意味著確保一個待開發(fā)軟件是正確無誤的，是對軟件開發(fā)構(gòu)想的檢測。測試：與狹義“軟件測試”概念一致。V模型軟件驗證與確認（VerificationandValidation，簡稱V&V）驗證針對各步驟的產(chǎn)品設(shè)計，確認針對預(yù)設(shè)的產(chǎn)品構(gòu)想W模型W模型：全過程的、同步的、全方位的測試模型案例：SVVP計劃任務(wù)什么是白盒測試？狹義的“白盒測試”包括：單元測試與集成測試廣義的“白盒測試”包括：從設(shè)計、編碼，再到單元測試、集成測試各階段中針對可見源碼的V&V活動代碼檢視（代碼審查）屬不屬于白盒測試？軟件編譯報錯后修改代碼，屬不屬于白盒測試活動？白盒測試活動最早出現(xiàn)在哪個開發(fā)階段？“白盒測試”是與“黑盒測試”相對的一個概念黑盒測試是被測代碼不可見的測試，包括功能測試、驗證測試等白盒測試是被測代碼可見的測試，包括單元測試、集成測試、部分協(xié)議測試等白盒測試基本過程編寫測試用例：查看修改變量，調(diào)用函數(shù)，驗證測試結(jié)果查看代碼覆蓋率，改進測試設(shè)計生成正式的測試報告案例：D項目集成測試的困惑某固網(wǎng)產(chǎn)品D項目主要負責(zé)話務(wù)統(tǒng)計的實現(xiàn)，該項目在頭腦靈活、精明強干的明星經(jīng)理肖某帶領(lǐng)下，各項工作都很出色，需求調(diào)研很深入，還借鑒了業(yè)界優(yōu)秀的話統(tǒng)模型，正當(dāng)D項目一帆風(fēng)順的運行到模塊集成測試，肖經(jīng)理突然發(fā)現(xiàn)：精心構(gòu)造話統(tǒng)模型卻難以測試。這種多業(yè)務(wù)分解，基于事務(wù)處理，又是多線索的統(tǒng)計模型很難按常規(guī)方法（甚至是調(diào)試方式）去測試，而略過集成測試直接做系統(tǒng)測試，就意味著要消耗大量精力在各種組合條件的測試用例設(shè)計，以及手工測試操作上。肖經(jīng)理犯愁了，總覺得前面的項目運作缺了點什么…白盒測試在研發(fā)全流程中的位置白盒測試在研發(fā)全流程中的位置單元測試與集成測試是什么？不是什么？IPL對單元測試的描述單元測試是針對與其它部分隔的、獨立的單元所展開的測試。在不同編程環(huán)境下單元的含義有所不同，比如在C語言中，被測單元是常規(guī)函數(shù)或子過程，在C++語言中，單元是指一個類，在Ada語言中單元是指函數(shù)或過程，或者是AdaPackage，而在4GL語言（如Delphi）中，單元還可以是一個菜單、按鈕、某個顯示單元等。單元測試：針對程序中基本組成部件的測試關(guān)注的被測單元應(yīng)是分隔開的、獨立的被測單元不只是函數(shù)對象也可是手工的、不可重復(fù)的測試單元測試不是：源碼不可見的測試被測范圍不確定的測試集成測試：比單元測試處于更高級別某些情況下，被測對象與單元測試無明顯界限集成測試區(qū)別于單元測試主要是：被測對象的表現(xiàn)特征不同，及由此帶來測試方法有所不同。企業(yè)不做單元測試的原因一個游戲：將小車開出謎宮語錄在恰當(dāng)?shù)臅r間以恰當(dāng)?shù)姆椒ㄗ銮‘?dāng)?shù)氖虑椋】追蜃诱Z錄：IhearandIforget.IseeandIremember.IdoandIunderstand.討論：白盒測試的問題與難題大家在做單元測試與集成測試過程中，都遇到過哪些問題？按重要性排序列出前10條。白盒測試三種境界混沌狀態(tài)：只有零星白盒測試實踐，缺少成功案例各成員對白盒測試普遍認識模糊大家都忙于救火，系統(tǒng)測試的投入尚無保障，代碼級測試無投入有序狀態(tài)：已有多個項目成功推行單元測試，已成可拷貝的活動有一批人對白盒測試具有清晰認識，領(lǐng)導(dǎo)層對實踐的前景既不悲觀，也不盲目樂觀設(shè)立專門機構(gòu)推動UT與IT，白盒測試活動也有流程保障少數(shù)項目有顯著效果，多數(shù)項目稍有成效，個別項目是失敗的自組織狀態(tài)：時時測試、持續(xù)測試已成風(fēng)氣白盒測試已成員工的普遍行為與自發(fā)行為有所為有所不為白盒測試三種境界處于混沌狀態(tài)貴在嘗試！處于有序狀態(tài)貴在堅持！處自組織狀態(tài)貴在自知！子曰：吾十有五，而志于學(xué)，三十而立，四十而不惑，五十而知天命，六十而耳順，七十從心所欲，不逾矩。為什么要做白盒測試？案例公司（ABC）遺留缺陷率：1～4BUG/KLOCUSA國防部（DOD）遺留缺陷率：0.01BUG/KLOC為什么要做白盒測試？一個比喻：清洗面包機為什么要做白盒測試？由CapersJones與McGraw-Hill的統(tǒng)計表明：若將問題發(fā)現(xiàn)、定位與解決都計算進去，單元測試效率最高，是集成測試的2倍，是系統(tǒng)測試的3倍。為什么要做白盒測試？白盒測試能較徹底解決編碼階段引入的問題需求分析概要設(shè)計詳細設(shè)計編碼單元測試集成測試系統(tǒng)測試驗收測試實施白盒測試的差異性驗證兩個性質(zhì)接近的項目（項目A與項目B），項目A沒做正規(guī)白盒測試，僅拿調(diào)試當(dāng)測試，項目B實施規(guī)范的白盒測試，這兩項目結(jié)束時分別按問題根源對全部BUG作統(tǒng)計。從“白盒測試問題比例”與“邏輯問題比例”可看出：不做白盒測試必然導(dǎo)致大量問題漏測項目A：缺少規(guī)范的白盒測試項目B：規(guī)范測試案例：問題根源分析案例：ODC問題根源分析ODC來源于IBM，OrthogonalDefectClassification白盒測試抽象模型嵌入式軟件的白盒測試特點開發(fā)語言以C語言為主體運行環(huán)境比較復(fù)雜（駐留于各式單板，與各種IO設(shè)備打交道）實時、多任務(wù)對于通信軟件：代碼量大、復(fù)雜程度高產(chǎn)品設(shè)計要為測試環(huán)境構(gòu)造提供條件要挖掘所有潛力來提高測試設(shè)計的效率對于通信軟件：測試體系要開放，與其它工具配合使用環(huán)境敏感效率苛刻目錄白盒測試基本概念嵌入式白盒測試遵循的理念為什么盡早測試？為什么持續(xù)測試？在線測試驅(qū)動與在線測試樁在線測試設(shè)計、運行及改進白盒測試的粒度與可見性白盒、黑盒，抑或灰盒調(diào)試是不是測試？檢視器的概念嵌入式軟件測試設(shè)計技術(shù)嵌入式軟件測試評估技術(shù)第4代白盒測試方法如何組織嵌入式軟件白盒測試為什么盡早測試？階段需求設(shè)計編碼單元測試驗收測試交付后維護糾正費早測試付出代價就越低案例：什么是持續(xù)測試？案例：一次測試與持續(xù)測試某通信產(chǎn)品在V1版本編碼完成時，進行過規(guī)范的單元測試活動，之后V2、V3要不斷增加功能、修改功能，就放棄單元測試了。當(dāng)V3最后市場交付時統(tǒng)計發(fā)現(xiàn)，相對V1版本，代碼修改量已達到40%。QA從其中兩個模塊隨機抽取100個問題單做缺陷分析，結(jié)果發(fā)現(xiàn)：第一個模塊有50%的問題是在V1版本單元測試結(jié)束后引入的，而另一模塊也有30%問題是單元測試后引入的。為什么持續(xù)測試持續(xù)集成的典型特征是：寫一點測一點

ObjectMentor：我們在做任何事情時（無論是寫測試、寫產(chǎn)品代碼還是重構(gòu)），都要保證系統(tǒng)能夠一直運行。運行測試的間隔時間是秒或者分鐘級的。即使是10分鐘都太長了。反映了一種質(zhì)量優(yōu)先的策略微軟的“每日構(gòu)建”與“冒煙測試”IBM的“漸增Build測試”XP的持續(xù)集成、測試先行等實踐持續(xù)集成對“軟件穩(wěn)定性”實現(xiàn)重用查錯、改錯的效率提高了被測系統(tǒng)隨時可運行，可展現(xiàn)功能，降低風(fēng)險時時可測試時時做測試案例：Joel測試案例：Joel測試——改進代碼的12個步驟演示：在線測試演示：在線測試設(shè)計（在線測試驅(qū)動、在線測試樁）在線測試調(diào)試在線測試執(zhí)行在線測試評估改進全局變量/函數(shù)：vd.xx類型定義：vt.xx/vt.struct.xx/vt.union.xx<演示材料的背景…>拉通測試小循環(huán)結(jié)果評估用例設(shè)計用例調(diào)試測試執(zhí)行白盒測試的粒度與可見性關(guān)注函數(shù)接口還是關(guān)注函數(shù)內(nèi)部代碼行？考慮因素：測試設(shè)計的工作量用例維護的工作量是否必須基于接口做測試設(shè)計，還是基于代碼行做設(shè)計？白盒、黑盒，抑或灰盒白盒測試設(shè)計形式對照源碼編寫測試用例看到哪行覆蓋，哪行未覆蓋，來優(yōu)化測試用例對照源碼調(diào)試測試用例，并定位測試問題依照源碼維護測試用例黑盒測試操作方式依據(jù)設(shè)計規(guī)格用例腳本只關(guān)注測試運行環(huán)境與輸入輸出接口一鍵運行，沒有單步跟蹤調(diào)試是不是測試？調(diào)試與測試的共性目的：查錯或確認無錯構(gòu)造運行環(huán)境：配置數(shù)據(jù)、修改變量、模擬樁判別是否預(yù)期：過程表現(xiàn)、結(jié)果表現(xiàn)調(diào)試與測試的差異可重復(fù)性粒度與可維護性3個概念：調(diào)試、檢視、測試檢視器檢視器介于調(diào)試器與測試器之間是一種提供腳本化控制的調(diào)試器也是一種提供調(diào)試功能的測試腳本生成器觀察控制點（PointsofControlandObservation，PCO）位于被測單元的上下層之間具有調(diào)試斷點的功能支持調(diào)試操作自動生成測試腳本演示：檢視器演示：檢視器的主要功能目錄白盒測試基本概念嵌入式白盒測試遵循的理念嵌入式軟件測試設(shè)計技術(shù)白盒測試的3類形式化表述語言映射技術(shù)三種測試設(shè)計模式一次性集成與增殖集成測試設(shè)計與產(chǎn)品設(shè)計的耦合關(guān)系測試腳本如何自動生成為什么要TDD？TDD三原則嵌入式軟件測試評估技術(shù)第4代白盒測試方法如何組織嵌入式軟件白盒測試白盒測試的3類形式化表述原生表述（CppUnit、JUnit、CodeTest）轉(zhuǎn)化表述（ParasoftC++Test、RTRT、Cantata++）映射表述（VcTester）編寫C測試代碼編譯連接執(zhí)行測試測試評估編譯連接執(zhí)行測試測試評估編寫測試腳本并轉(zhuǎn)化成C代碼語法分析編譯連接執(zhí)行測試分析測試編寫測試腳本案例：CppUnit與RTRT的測試用例案例：CppUnit與RTRT的測試用例案例：TCL命令字注冊案例：使用TCL命令字注冊發(fā)起單元測試使用Tcl_CreateCommand注冊被測C函數(shù)，使用Tcl_GetVar與Tcl_SetVar存取變量。比如將C函數(shù)MyFunc注冊為TCL的擴展命令TCL_MyFunc：Tcl_CreateCommand(interp,“TCL_Myfunc",Myfunc,NULL,NULL);語言映射技術(shù)全局變量/函數(shù)：vd.xx類型定義：vt.xx/vt.struct.xx/vt.union.xx語言映射技術(shù)A函數(shù)B函數(shù)C函數(shù)腳本樁函數(shù)B函數(shù)A函數(shù)B函數(shù)C函數(shù)A函數(shù)B函數(shù)C函數(shù)腳本樁函數(shù)打腳本樁之前替代模式打樁插入模式打樁演示：C語言映射到CSE腳本演示：C語言映射到CSE腳本演示：3種測試設(shè)計模式演示：3種測試設(shè)計模式仿真模式點控制模式混合模式

一次性集成與增殖集成一次性集成增殖集成（自頂向下、自底向上、混合方式）優(yōu)點缺點自頂向下測試

可以自然地做到逐步求精，一開始便能讓測試者看到系統(tǒng)的框架

需要提供樁模塊在輸入/輸出模塊接入系統(tǒng)以前，在樁模塊中表示測試數(shù)據(jù)有一定困難模擬測試數(shù)據(jù)困難觀察和解釋測試輸出往往也是困難的

自底向上測試

構(gòu)造測試數(shù)據(jù)比較容易測試中較少模擬樁函數(shù)特別適合于關(guān)鍵模塊在結(jié)構(gòu)圖的底部的情況

直到最后一個模塊被加進去之后才能看到整個程序（系統(tǒng)）的框架

只有到測試過程的后期才能發(fā)現(xiàn)時序問題和資源競爭問題測試設(shè)計與產(chǎn)品設(shè)計的耦合關(guān)系緊耦合的需求：測試重用，參考引用，結(jié)構(gòu)化封裝松耦合的需求：用例維護，版本發(fā)布，隔離BUG緊耦合模式分離模式松耦合模式XUNITRTRTVcTester演示：分離模式的應(yīng)用實例演示：分離模式的應(yīng)用實例案例：ParasoftC++Test的腳本生成案例：ParasoftC++Test的腳本自動生成（Source模式）ObjListiMaxNULL0Normal1-1MaxIntMinIntvoidBubbleSort(OBJ_DATA_PTRObjList,intiMax)Obj1Obj2NULLNULLNormalNormalint__stdcallObjCompare(OBJ_DATA*Obj1,OBJ_DATA*Obj2)案例：ParasoftC++Test的腳本生成案例：ParasoftC++Test的腳本自動生成（Native模式）什么腳本能生成，什么不能？圖靈停機與圖靈測試測試腳本自動生成依據(jù)什么？什么測試腳本能自動生成，什么不能生成？演示：VcTester的測試腳本自動生成演示：VcTester的測試腳本自動生成什么是TDD?《ExtremeProgrammingApplied》：Beforeyouwritecode,thinkaboutwhatitwilldo.Writeatestthatwillusethemethodsyouhaven’tevenwrittenyet.在編寫代碼前設(shè)計測試用例Atestisnotsomethingyou“do”,itissomethingyou“write”andrunonce,twice,threetimes,etc.測試驅(qū)動開發(fā)Test-DrivenDevelopment（測試指示開發(fā)）“指示”意味著：測試為片斷代碼提供使用規(guī)格也隱含“測試即設(shè)計文檔”這個飽受爭議的論題TDD操作步驟編寫測試用例編譯修正編譯錯誤運行測試用例，看它報錯修改代碼運行測試用例，看它通過重構(gòu)代碼

并測試為什么要TDD？實施TDD的深刻原因一次好測試：既測試可見代碼，也測試不可見代碼一次好測試：是基于規(guī)格的測試，而不是“機械測試”案例：AnInitialInvestigationofTestDrivenDevelopmentinIndustry如何實施TDD？實施TDD的難點克服未見代碼先寫用例的恐慌提高TDD中編碼與調(diào)試的效率案例：ObjectMentor–TDD三條軍規(guī)

1.除非為了使一個失敗的unittest通過，否則不允許編寫任何產(chǎn)品代碼

2.在一個單元測試中只允許編寫剛好能夠?qū)е率〉膬?nèi)容（編譯錯誤也算)3.只允許編寫剛好能夠使一個失敗的unittest通過的產(chǎn)品代碼演示：第4代白盒方法的TDD實踐演示：第4代白盒方法的TDD實踐討論：測試先行、持續(xù)集成、冒煙測試測試先行（TDD）、持續(xù)集成、冒煙測試，這3者之間有什么關(guān)系？目錄白盒測試基本概念嵌入式白盒測試遵循的理念嵌入式軟件測試設(shè)計技術(shù)嵌入式軟件測試評估技術(shù)常用覆蓋率統(tǒng)計標準基于調(diào)用的覆蓋率統(tǒng)計技術(shù)如何選擇覆蓋率標準用例覆蓋度缺陷密度評估白盒測試問題管理第4代白盒測試方法如何組織嵌入式軟件白盒測試常用覆蓋率統(tǒng)計標準語句覆蓋（Statement

Coverage

）判定覆蓋（Decision

Coverage

）

條件覆蓋（Condition

Coverage

）多條件覆蓋（Multiple

Condition

Coverage

）

判定條件組合覆蓋（Condition/Decision

Coverage

）

修正條件/判定覆蓋（Modified

Condition/Decision

Coverage，MCDC）路徑覆蓋（Path

Coverage

）

基于調(diào)用的覆蓋率統(tǒng)計技術(shù)位置無關(guān)調(diào)用覆蓋（Location-independentcallcoverage）

LICC=(已覆蓋的不重復(fù)的函數(shù)調(diào)用個數(shù)/全部不重復(fù)的函數(shù)調(diào)用個數(shù))*100%位置相關(guān)調(diào)用覆蓋率（Location-dependentcallcoverage

）

LDCC=(已覆蓋的函數(shù)調(diào)用個數(shù)/全部函數(shù)調(diào)用個數(shù))*100%比如某函數(shù)中調(diào)用了3個子函數(shù)，其中第1個子函數(shù)調(diào)用在函數(shù)定義的兩個地方出現(xiàn)，其余2個子函數(shù)都只在一處調(diào)用（即，只使用了一次）。如果這個3個子函數(shù)都被調(diào)用過，而且第1個子函數(shù)只一個位置調(diào)用了，另一個位置尚未覆蓋到。這時，我們計算LICC是“3/3=100%”，而LDCC是“3/4=75%”。演示：覆蓋率定制的一個實例演示：覆蓋率定制的一個實例如何選擇覆蓋率標準？是不是選擇覆蓋率標準越高越好？持續(xù)集成對覆蓋率指標有哪些要求？選擇恰如其分的評估標準避免源碼中“噪聲”給質(zhì)量評估帶來波動語句覆蓋判定覆蓋條件覆蓋判定條件覆蓋MCDC覆蓋LCSAJ覆蓋路徑覆蓋用例覆蓋度為什么引入用例覆蓋度(TestCaseCoverage)？定義

TCC=用例中調(diào)用被測函數(shù)的總次數(shù)/函數(shù)定義的分支總數(shù)函數(shù)分支總數(shù)=1+if語句總數(shù)*2+while語句總數(shù)*2+for語句總數(shù)*2用例覆蓋度的價值彌補代碼覆蓋率的評估欠缺評估標準可定制演示：TCC定制實例缺陷密度評估缺陷密度定義：發(fā)現(xiàn)問題數(shù)/千行代碼主要評估指標缺陷密度遺留缺陷密度測試用例密度回歸測試通過率

DI值=(致命問題*10+嚴重問題*3+一般問題*1+提示問題*0.1)*難度系數(shù)是否符合Compertz退出準則案例：研發(fā)Metrics質(zhì)量體系白盒測試問題管理流程測試開發(fā)管理三方會議開啟分派設(shè)計變更分派解決符合設(shè)計不用解決延遲解決關(guān)閉ODC缺陷分析觸發(fā)因素問題發(fā)現(xiàn)活動驗證開發(fā)開發(fā)驗證結(jié)果影響嚴重程度原因結(jié)果定位責(zé)任來源問題位置缺陷年齡缺陷類型內(nèi)容類型缺陷界定問題根源對象ODC缺陷分析檢視發(fā)現(xiàn)的主要是一般問題壓力測試發(fā)現(xiàn)一個致命問題缺陷根源分析一種系統(tǒng)的解決問題的方法，通過標示問題，分析問題的根本原因，針對根本原因制定可行的糾正預(yù)防措施，以達到解決問題和預(yù)防問題再次發(fā)生的目的標識問題根本原因分析制定糾正預(yù)防措施Rayleigh分析方法目錄白盒測試基本概念嵌入式白盒測試遵循的理念嵌入式軟件測試設(shè)計技術(shù)嵌入式軟件測試評估技術(shù)第4代白盒測試方法白盒測試要遵循的原則嵌入式白盒測試的核心難題是什么？分區(qū)推動理論白盒測試發(fā)展歷程：從第1代到第4代3個關(guān)鍵域與9項關(guān)鍵特征紅綠燈通行機制測試小循環(huán)融入研發(fā)大循環(huán)白盒測試技術(shù)的演進沒有銀彈—除了重用還是重用如何組織嵌入式軟件白盒測試白盒測試要遵循的原則Good-enough原則Zero-bug&Good-enough投入&產(chǎn)出Pareto原則（20/80原則）全方位、多角度嵌入式白盒測試的核心難題是什么？測試效率問題測試質(zhì)量問題第4代白盒測試方法著重解決這兩個問題！另外著眼于保障白盒測試是易操作、易推行的。環(huán)境敏感效率苛刻分區(qū)推動理論測試同比：在恒定質(zhì)量前提下，每新增1KLOC代碼所需開發(fā)投入，與新增用例設(shè)計的投入之比例低效1:2，一般1:1，很好2:1拐點：1:1混沌狀態(tài)有序狀態(tài)自組織狀態(tài)白盒測試技術(shù)發(fā)展歷程第一代白盒測試方法測試操作不規(guī)范、不可重復(fù)，無測試評估print/assert/拿調(diào)試當(dāng)測試第二代白盒測試方法形式化描述用例并階段重用，有覆蓋評估RTRT/CppTest/CodeTest/TrueCoverages等工具第三代白盒測試方法堅持質(zhì)量優(yōu)先的可持續(xù)測試（寫一點測一點）xUnit工具第四代白盒測試方法軟件調(diào)測完全高效的融入研發(fā)全過程VcTester/GccTester測試設(shè)計效率低下全腳本語言、調(diào)測一體、突破效率瓶頸白盒測試技術(shù)演進第2代區(qū)別第1代，主要克服兩大缺陷：沒有測試評估（比如覆蓋率）測試操作不可重復(fù)第3代區(qū)別第2代，增加了：對持續(xù)集成運作模式的支持第4代區(qū)別第3代，在于：強調(diào)對調(diào)試操作的重用3個關(guān)鍵域9項關(guān)鍵特征第一關(guān)鍵域：在線測試在線測試驅(qū)動在線腳本樁在線測試用例設(shè)計、運行，及評估改進第二關(guān)鍵域：灰盒調(diào)測基于調(diào)用接口調(diào)試即測試集編碼、調(diào)試、測試于一體第三關(guān)鍵域：持續(xù)測試測試設(shè)計先行持續(xù)保障信心重構(gòu)測試設(shè)計3個關(guān)鍵域9項關(guān)鍵特征第一關(guān)鍵域：在線測試在線測試驅(qū)動在線腳本樁在線測試用例設(shè)計、運行，及評估改進第二關(guān)鍵域：灰盒調(diào)測基于調(diào)用接口調(diào)試即測試集編碼、調(diào)試、測試于一體第三關(guān)鍵域：持續(xù)測試測試設(shè)計先行持續(xù)保障信心重構(gòu)測試設(shè)計測試效率易操作/易推行測試質(zhì)量演示：集成調(diào)測平臺演示：集成化的編輯、調(diào)試與測試平臺演示：紅綠燈通行機制演示：紅綠燈通行機制拉通研發(fā)大循環(huán)結(jié)果評估用例設(shè)計用例調(diào)試測試執(zhí)行問題定位編碼/改錯源碼調(diào)試結(jié)果評估調(diào)試(源碼與腳本)產(chǎn)品發(fā)布運行編碼/改錯(源碼與腳本)自動測試運行白盒測試技術(shù)演進是否評估測試效果是否自動測試是否持續(xù)測試是否調(diào)測一體第1代白盒測試方法否否否否第2代白盒測試方法是是否否第3代白盒測試方法是是是否第4代白盒測試方法是是是是測試操作重用穩(wěn)定性重用調(diào)試過程重用軟件測試的銀彈沒有銀彈（布魯克斯，1986年）在近十年內(nèi)，沒有任何單獨的軟件工程進展可以使軟件生產(chǎn)率有數(shù)量級的提高大家熟悉的軟件項目具有一些人狼的特性（至少在非技術(shù)經(jīng)理看來），常常看似簡單明了的東西，卻有可能變成一個落后進度、超出預(yù)算、存在大量缺陷的怪物。因此，我們聽到了近乎絕望的尋求銀彈的呼喚，尋求一種可以使軟件成本像計算機硬件成本一樣降低的尚方寶劍。人月神話（查珀爾希爾，1986年）軟件開發(fā)總是非常困難的，天生就沒有銀彈。想想現(xiàn)代軟件系統(tǒng)中這些無法規(guī)避的內(nèi)在特性吧：復(fù)雜度、一致性、可變性和不可見性。軟件測試的銀彈StandishGroup的研究StandishGroup從1994年開始用了10年時間，研究了大約3萬5千個開發(fā)項目，他們定義成功的項目：軟件開發(fā)按時完成預(yù)算未超出軟件功能涵蓋了預(yù)定需求軟件沒有被缺陷致殘軟件已被使用，且產(chǎn)生了積極的效果最初的結(jié)果顯示：只有16%的項目是成功的，而且他們每年都更新這一統(tǒng)計，發(fā)現(xiàn)之后該比例并沒有太大改變。軟件測試的銀彈：除了重用，還是重用！目錄白盒測試基本概念嵌入式白盒測試遵循的理念嵌入式軟件測試設(shè)計技術(shù)嵌入式軟件測試評估技術(shù)第4代白盒測試方法如何組織嵌入式軟件白盒測試與白盒測試相關(guān)的前期開發(fā)活動是開發(fā)人員做單元測試還是測試人員做？白盒測試活動中的角色與配合關(guān)系規(guī)劃白盒測試注意事項仿真層中間件如何構(gòu)造？持續(xù)集成的體系架構(gòu)持續(xù)集成、每日構(gòu)建、冒煙測試之間的關(guān)系與白盒測試相關(guān)的前期開發(fā)活動可測試性需求分析測試策略擬定SVVP計劃制定測試工具選型評估可測試性設(shè)計測試設(shè)計白盒測試是一項系統(tǒng)工程！白盒測試活動中的角色單元測試與集成測試該由誰來實施？人員組織與角色項目經(jīng)理QATC開發(fā)人員開發(fā)人員開發(fā)人員測試經(jīng)理QA測試系統(tǒng)工程師自動化工程師測試人員測試人員規(guī)劃白盒測試的幾點注意事項注重前期規(guī)劃避免在目標系統(tǒng)（單板）做單元測試有所為有所不為，難以實施白盒測試應(yīng)以其它測試手段（如代碼檢視、設(shè)計評審等）彌補先推單元測試，后推集成測試注意測試設(shè)計的重用依據(jù)實踐的推論嵌入式軟件的單元測試及底層的集成測試，應(yīng)在仿真平臺進行集成測試，尤其是基于消息驅(qū)動、組件調(diào)用，或者定義簡潔上下層接口的測試，可以在真實平臺下進行受限于實際環(huán)境，未能詳盡做單元或集成測試的，應(yīng)加強其它類型測試予以彌補。單元測試----調(diào)試/代碼正規(guī)檢視/lint檢查集成測試----調(diào)試/設(shè)計評審上單板做白盒測試的主要弱點測試成本高（搭建測試環(huán)境、調(diào)試與測試麻煩）面對初始代碼，代碼不穩(wěn)定導(dǎo)致上單板效率低下上單板的測試常混雜了集成測試的需求由于嵌入式平臺的多樣性，通常缺乏有效的測試工具要求前期PCB較多投板一個典型的仿真層中間件底層接口任務(wù)管理隊列管理內(nèi)存管理日志管理維護管理配置管理接口管理補丁管理測試接口應(yīng)用層接口手機產(chǎn)品PDA產(chǎn)品寬帶產(chǎn)品數(shù)通產(chǎn)品PSOSVXWORKSUNIXWIN98NTINTELCPUPPCCPUARMCPUVOS平臺無線產(chǎn)品持續(xù)集成的體系架構(gòu)持續(xù)集成、每日構(gòu)建、冒煙測試的關(guān)系時時使用