白盒測(cè)試方法介紹

白盒測(cè)試方法介紹—理論篇

文檔修改說明：序號(hào)修改描述時(shí)間責(zé)作人版本1完成初稿2011-07-11王超1.0文檔分發(fā)列表：文檔接收者目錄TOC\o"1-5"\h\z\o"CurrentDocument"1背景 4白盒測(cè)試的范圍 4\o"CurrentDocument"1.2第1代與第2代白盒測(cè)試 4\o"CurrentDocument"第3代白盒測(cè)試方法 5\o"CurrentDocument"1.4第4代白盒測(cè)試方法的產(chǎn)生背景 5\o"CurrentDocument"2什么是第4代白盒測(cè)試方法 6\o"CurrentDocument"3為什么持續(xù)集成 7\o"CurrentDocument"JOEL測(cè)試 7\o"CurrentDocument"持續(xù)集成不是XP專有實(shí)踐 8\o"CurrentDocument"為什么持續(xù)集成 84第4代白盒測(cè)試方法的關(guān)鍵特征 9\o"CurrentDocument"在線測(cè)試 9\o"CurrentDocument"腳本驅(qū)動(dòng)與腳本樁 9\o"CurrentDocument"4.1.2在線測(cè)試邏輯更新 10\o"CurrentDocument"拉通測(cè)試小循環(huán) 11\o"CurrentDocument"4.2灰盒調(diào)測(cè) 11\o"CurrentDocument"白盒測(cè)試的粒度 11\o"CurrentDocument"檢視器 12\o"CurrentDocument"調(diào)試就是測(cè)試 13\o"CurrentDocument"4.2.4編碼、調(diào)試、測(cè)試集成平臺(tái) 14\o"CurrentDocument"持續(xù)測(cè)試 15\o"CurrentDocument"測(cè)試設(shè)計(jì)先行 15\o"CurrentDocument"如何持續(xù)保障信心 16\o"CurrentDocument"重構(gòu)測(cè)試設(shè)計(jì) 17\o"CurrentDocument"5結(jié)論 17\o"CurrentDocument"參考資料 18關(guān)鍵詞：白盒測(cè)試第4代測(cè)試方法4GWM在線測(cè)試持續(xù)測(cè)試灰盒腳本驅(qū)動(dòng)腳本樁摘要：本文是第4代白盒測(cè)試方法的理論介紹，描述3個(gè)關(guān)鍵領(lǐng)域內(nèi)9項(xiàng)關(guān)鍵特征的概念與固有特征。同時(shí)介紹白盒測(cè)試發(fā)展歷程，對(duì)比說明第4代白盒測(cè)試方法與以往測(cè)試方法的異同及優(yōu)化要素。縮略語：4GWM：The4thGenerationWhite-box-testingMethodology，第4代白盒測(cè)試方法XP：ExtremeProgramming，極限編程TDD：TestDrivenDevelopment，測(cè)試驅(qū)動(dòng)開發(fā)IID：IncrementalandIterativeDevelopment，漸增迭代開發(fā)CSE：CommonScriptEngine，通用腳本引擎（一種近似于python的腳本語言）PCO：PointsofControlandObservation，觀察控制點(diǎn)TDF：TestDesignFirst，測(cè)試設(shè)計(jì)先行MCDC：ModifiedCondition/DecisionCoverage1背景1.1白盒測(cè)試的范1.1白盒測(cè)試的范白盒測(cè)試是軟件測(cè)試體系中一個(gè)分支，測(cè)試關(guān)注對(duì)象是一行行可見代碼，如果代碼不可見就不是白盒，是黑盒測(cè)試了。白盒測(cè)試也通常被認(rèn)為是單元測(cè)試與集成測(cè)試的統(tǒng)稱，但這個(gè)概念是相對(duì)的，與當(dāng)前項(xiàng)目遵循的研發(fā)流程有關(guān)，某些流程把白盒測(cè)試劃分為單元測(cè)試與集成測(cè)試，而另一些流程，把白盒測(cè)試劃分為模塊單元測(cè)試、模塊系統(tǒng)測(cè)試、多模塊集成測(cè)試，還有一些流程把單元測(cè)試與集成測(cè)試混為一體，統(tǒng)稱為持續(xù)集成測(cè)試。隨著測(cè)試技術(shù)的發(fā)展，白盒測(cè)試的概念也在發(fā)生變化，比如，本文提倡一種介于白盒與黑盒之間的灰盒操作模式，針對(duì)被測(cè)對(duì)象同樣是可見源碼，這時(shí)，白盒測(cè)試不只是白盒了。盡管如果此，我們?nèi)宰裱蠹伊?xí)慣的思維方式——把本文倡導(dǎo)的測(cè)試方法仍冠名為：第4代白盒測(cè)試方法（4GWM，The4thGenerationWhite-box-testingMethodology）。本文討論白盒測(cè)試方法，范圍限定在功能測(cè)試之前，針對(duì)源碼行的所有測(cè)試，即，被測(cè)對(duì)象是看得到的功能源碼，每個(gè)測(cè)試者必須先獲得源碼才能實(shí)施測(cè)試。1.2第1代與第2代白盒測(cè)試說到第4代白盒測(cè)試方法，就不能不回顧前幾代方法。在測(cè)試發(fā)展初期，測(cè)試工具很不成熟，人們通常以單步調(diào)試代替測(cè)試，或采用assert斷言、print語句等簡單方式的組織測(cè)試體系，即我們所謂的第1代白盒測(cè)試，這一時(shí)期的測(cè)試是半手工的，沒實(shí)現(xiàn)自動(dòng)化，測(cè)試效果也嚴(yán)重依賴測(cè)試者（或者調(diào)試者。的個(gè)人能力，缺少統(tǒng)一規(guī)范的評(píng)判標(biāo)準(zhǔn)。當(dāng)然，調(diào)試算不算測(cè)試在業(yè)界尚存爭議，單論調(diào)試的目的（為了定位問題。與操作方式（過程不可重復(fù)），不應(yīng)把調(diào)試看作測(cè)試，但調(diào)試確能發(fā)現(xiàn)軟件BUG，顯然這也是一種測(cè)試手段。本文暫不評(píng)判調(diào)試用作測(cè)試手段是否合理，但有必要先確定調(diào)試是測(cè)試的某種形式，把它看作特定歷史階段或特定場(chǎng)景下的產(chǎn)物。特定歷史階段大家比較容易理解，調(diào)試伴隨編程語言是天生的，測(cè)試工具卻是后天形成，開發(fā)人員總喜歡認(rèn)調(diào)試器當(dāng)親媽，測(cè)試工具則是愛管不管的后媽。特定場(chǎng)景是什么？比如，某種生僻的RTOS平臺(tái)根本找不到對(duì)應(yīng)測(cè)試工具，怎么辦？拿調(diào)試做測(cè)試是無奈之中的必然。這里，我們不否認(rèn)調(diào)試也是一種測(cè)試，在此基礎(chǔ)上再優(yōu)化其操作過程，使調(diào)試能更好的服務(wù)于測(cè)試（下文介紹“灰盒調(diào)測(cè)”還有進(jìn)一步論述）。第1代白盒測(cè)試方法存在嚴(yán)重缺陷，主要有：測(cè)試過程難以重用，成功經(jīng)驗(yàn)無法拷貝，測(cè)試結(jié)果也難以評(píng)估并用于改進(jìn)，這些對(duì)于團(tuán)隊(duì)運(yùn)作是非常致命的。到第2代白盒測(cè)試，上述主要缺陷得到克服，將測(cè)試操作改用一種形式化語言（通常稱為測(cè)試腳本）來表述，腳本可以組合成用例，用例可組合成測(cè)試集，用例與測(cè)試集再統(tǒng)一到測(cè)試工程中管理，把測(cè)試腳本保存到文件，重用問題解決了。另外，代碼覆蓋率功能使測(cè)試結(jié)果可以評(píng)估，能直觀的看到哪些代碼或分支未被覆蓋，然后有針對(duì)性的增加測(cè)試設(shè)計(jì)。目前市面上有大量商用工具，如RTRT、CodeTest、VisualTester、C++Tester等都屬于這第2代白盒測(cè)試工具。1.3第3代白盒測(cè)試方法按理說，第2代白盒測(cè)試工具已經(jīng)很完善了，那第3代又是什么？軟件測(cè)試是一門復(fù)雜科學(xué)，支持自動(dòng)測(cè)試與覆蓋率評(píng)估后不見得就能成功實(shí)施白盒測(cè)試，尤其重要的是，第2代白盒測(cè)試解決了重復(fù)測(cè)試問題，但沒解決持續(xù)測(cè)試問題。簡單來說，重復(fù)測(cè)試使測(cè)試操作能以規(guī)范格式記錄，當(dāng)被測(cè)對(duì)象沒變化（或變化很少）時(shí)，測(cè)試用例是可重用的，但如果源碼大幅調(diào)整（甚至重構(gòu)），或者按迭代模式不停追加新功能時(shí)，如何維持用例同步增長，并與源碼一起同步更新，已經(jīng)不是簡單的增強(qiáng)用例復(fù)用能力就能解決的。因?yàn)榇a更新與用例更新交織進(jìn)行，測(cè)試用例與被測(cè)源碼一樣對(duì)等的成為日常工作對(duì)象，必然促使原有工作模式與測(cè)試方法產(chǎn)生變革，概括而言，白盒測(cè)試過程要從一次測(cè)試模式過渡到持續(xù)測(cè)試模式。第3代白盒測(cè)試工具以xUnit為代表，包括JUnit、DUnit、CppUnit等，當(dāng)然，我們列舉xUnit工具，并不說這些第3代工具就比第2代工具要好。事實(shí)上，目前xUnit工具在功能上普遍趕不上第2代商用工具，許多xUnit工具甚至連基本的覆蓋率都支持不了，況且，xUnit使用被測(cè)代碼的編程語言寫用例，普遍效率低下。這里，我們區(qū)別第2代方法與第3代方法，主要是測(cè)試?yán)砟钌喜顒e，而不以工具差別為基準(zhǔn)，因?yàn)楣ぞ吲涮赘M(jìn)還與諸多現(xiàn)實(shí)因素相關(guān)，是另一層面話題。1.4第4代白盒測(cè)試方法的產(chǎn)生背景xUnit是XP實(shí)踐的重要支撐工具，XP作為一種軟件開發(fā)方法論，總體雖然敏捷，但很脆弱，它對(duì)程序員非常友好，但對(duì)組織不是。以xUnit為代表的XP測(cè)試實(shí)踐同樣表現(xiàn)出這一特質(zhì)，據(jù)已有案例分析，XP持續(xù)集成在java項(xiàng)目中成功的很多，C++有一些，C語言項(xiàng)目就很少了，為什么編程語言對(duì)持續(xù)集成的影響如此深遠(yuǎn)？第4代白盒測(cè)試嘗試解決軟件測(cè)試的深層次矛盾：測(cè)試的投入產(chǎn)出比問題。大家知道，研發(fā)資源總是有限的，你可以把測(cè)試人員與開發(fā)人員的比例配到1:1，也可以配到2:1，甚至5:1，但你做不到10:1、100:1，如果你有錢，也有人，完全可以按100:1或更高比例配置，這時(shí)所有測(cè)試瓶頸都沒了，你可以讓測(cè)試人員邊喝咖啡邊干活，因?yàn)槊啃聦?行代碼總有人編出100行腳本測(cè)試它，還怕產(chǎn)品不穩(wěn)定嗎？不過，瘋子才會(huì)這么做，比爾蓋茲有的是錢，一年捐款十多億美金，但不見得微軟旗下產(chǎn)品就經(jīng)常讓測(cè)試人員比開發(fā)人員多出一倍。我的意思是，測(cè)試資源必然是受限的，這個(gè)前提下我們才討論第1代、第2代白盒測(cè)試向第3代、第4代演化的必要性。基于同樣原理的xUnit工具，針對(duì)不同開發(fā)語言效果截然不同，這說明什么？說明這種實(shí)踐的瓶頸仍在投入產(chǎn)出比上，也就是上面所說的1:1效果，還是2:1，抑或是5:1效果。高效平臺(tái)下的高效工具可以大幅提高測(cè)試效率，測(cè)試投入與開發(fā)投入之比小于1:1就能保證測(cè)試質(zhì)量，項(xiàng)目就成功了，而低效平臺(tái)下的低效工具，必然要投入更多測(cè)試資源（比方5:1）才能保證效果，拐點(diǎn)就在這兒，哪個(gè)公司禁得起5:1的測(cè)試投入？！從這個(gè)意上說，推出第4代白盒測(cè)試方法意義重大，我們要嘗試解決決定項(xiàng)目成敗的拐點(diǎn)問題。事先申明一下，下文涉及持續(xù)集成與測(cè)試先行（或稱測(cè)試驅(qū)動(dòng)開發(fā)，TDD）實(shí)踐，雖然這兩者都是XP的重要組成部分，但我們無意宣揚(yáng)XP,事實(shí)上，真正能適應(yīng)XP的項(xiàng)目范圍并不寬，跳過需求與預(yù)設(shè)計(jì)直接啟動(dòng)項(xiàng)目的做法，足以讓客戶敬而生畏，把文檔丟給獅子，那是無政府主義散兵游勇行徑。不過，XP確有許多閃閃發(fā)光的實(shí)踐，持續(xù)集成只要運(yùn)用恰當(dāng)還是不錯(cuò)的模式，測(cè)試先行的理念也不賴，只要不過度實(shí)施就好。2什么是第4代白盒測(cè)試方法第4代白盒測(cè)試方法（4GWM）針對(duì)前幾代測(cè)試方法不足提出，許多理念仍繼承第2代與第3代測(cè)試方法。下表簡要的列出第1代到第4代白盒方法的主要差別：是否評(píng)估測(cè)試效果是否自動(dòng)測(cè)試是否持續(xù)測(cè)試是否調(diào)測(cè)一體第1代白盒測(cè)試方法否否否否第2代白盒測(cè)試方法是是否否第3代白盒測(cè)試方法是是是否第4代白盒測(cè)試方法是是是是上表中，“是否評(píng)估測(cè)試效果”指是否有覆蓋率或其它評(píng)估測(cè)試效果的指標(biāo)，“是否自動(dòng)測(cè)試”指是否形式化描述測(cè)試操作并將它用于再次測(cè)試，“是否持續(xù)測(cè)試”指是否以按持續(xù)集成的模式開展測(cè)試，“是否調(diào)測(cè)一體”指是否將測(cè)試設(shè)計(jì)高效的融入產(chǎn)品編碼與調(diào)試的日常實(shí)踐之中。第2代白盒測(cè)試與第3代的分水嶺在于“是否持續(xù)集成”，或許您會(huì)說，我的項(xiàng)目也是經(jīng)常出版本，反復(fù)追加測(cè)試用例的呀，請(qǐng)注意，這是兩個(gè)概念,Joel測(cè)試一一改進(jìn)代碼的12個(gè)步驟中有一條：“編寫新代碼之前先修復(fù)故障嗎？”，先修復(fù)故障是質(zhì)量優(yōu)先的項(xiàng)目，否則進(jìn)度優(yōu)先，這是兩種完全不同的行事風(fēng)格，前者時(shí)時(shí)測(cè)試，始終每寫一兩個(gè)函數(shù)就補(bǔ)全相關(guān)測(cè)試用例，測(cè)試實(shí)踐是融入開發(fā)全過程的，而后者依時(shí)間表行事，測(cè)試僅是特定階段里的任務(wù)。對(duì)了，測(cè)試方法怎么跟軟件開發(fā)方法扯上了？因?yàn)闇y(cè)試不是孤立的，測(cè)試是否有效強(qiáng)烈依賴于軟件工程方法，就像早期的開發(fā)語言，只有assert語句與測(cè)試相關(guān)，發(fā)展到現(xiàn)有的C#，單元測(cè)試框架也是該語言的固有組件了。測(cè)試腳本也是一種產(chǎn)品代碼，測(cè)試方法實(shí)際與軟件開發(fā)方法密不可分的，這在第3代與第4代白盒測(cè)試中體現(xiàn)得很充分。第4代白盒測(cè)試方法相對(duì)第3代方法，增加了將測(cè)試過程（包括測(cè)試設(shè)計(jì)、執(zhí)行與改進(jìn)）高效的融入開發(fā)全過程，這里，“高效的”是關(guān)鍵詞，那如何才算高效呢？我們先簡單了解4GWM在3個(gè)關(guān)鍵領(lǐng)域的9項(xiàng)關(guān)鍵特征，如下：第一關(guān)鍵域：在線測(cè)試1、 在線測(cè)試驅(qū)動(dòng)2、 在線腳本樁3、 在線測(cè)試用例設(shè)計(jì)、運(yùn)行，及評(píng)估改進(jìn)第二關(guān)鍵域：灰盒調(diào)測(cè)4、 基于調(diào)用接口5、 調(diào)試即測(cè)試6、 集編碼、調(diào)試、測(cè)試于一體第三關(guān)鍵域：持續(xù)測(cè)試7、 測(cè)試設(shè)計(jì)先行8、 持續(xù)保障信心9、 重構(gòu)測(cè)試設(shè)計(jì)3為什么持續(xù)集成為什么要持續(xù)集成？這個(gè)問題太重要了，我們專門拎出來講，請(qǐng)大家先不急于跳過本章去看4GWM的9個(gè)關(guān)鍵特征怎么定義的。3.1JOEL測(cè)試Joel是個(gè)怪人，當(dāng)然他不認(rèn)識(shí)我，我拜讀他的Blog才知道他的。這家伙總有許多稀奇古怪的思想在小腦瓜里蹦達(dá)，他是“經(jīng)常放貓出來閑逛”的人?？茖W(xué)研究表明，人的大腦只占體重2%，卻消耗20%的能量，當(dāng)大腦思考問題時(shí)，釋放出的能量等同于夜間放一只貓出來活動(dòng)。他的“Joel說軟件”專欄()很火，有一些不乏真知灼見。比如，Joel測(cè)試一一改進(jìn)代碼的12個(gè)步驟：1、有版本控制機(jī)制嗎？2、 能一步完成編譯鏈接嗎？3、 每天都做編譯嗎？4、 使用缺陷跟蹤庫嗎？5、 編寫新代碼之前先修復(fù)缺陷嗎？6、 有最新的進(jìn)度表嗎？7、 有規(guī)格說明書嗎？8、 程序員擁有安靜的工作環(huán)境嗎？9、 你用到了你資金能力內(nèi)可買到的最好工具嗎？10、 有測(cè)試人員嗎？11、 要求新聘人員在面試時(shí)編寫代碼嗎？12、 進(jìn)行走廊可用性測(cè)試嗎？每個(gè)問題可以回答“是”或者“否”，答“是”則加1分，得12分是完美，11分勉強(qiáng)接受，10分以下問題就大了，大家有興趣看看你所在的組織能打多少分。有測(cè)試人員嗎？干嘛這么問，沒測(cè)試人員還叫軟件公司嗎？這個(gè)問題并不可笑，還真有不少公司從未配置過專職測(cè)試人員。某白熾燈生產(chǎn)商在使用說明中特意聲稱，燈泡不能往嘴里塞，否則會(huì)出嚴(yán)重醫(yī)學(xué)事故，說明書中還鄭重其事的介紹燈泡不慎入口后，如何求醫(yī)，如何抹潤滑劑，如何左轉(zhuǎn)90度右轉(zhuǎn)90度慢慢取出來。有人覺得滑稽，誰白癡有事沒事拿燈泡往嘴里送？即使放嘴里了也不用這么麻煩吧？非得試試，結(jié)果如何？怎么也拿不出來了，只得嘴里叼個(gè)燈泡打的上醫(yī)院，最后，醫(yī)生按照說明書費(fèi)老勁才將那玩意卸下。所以，不要輕易否定前人經(jīng)驗(yàn)，早有人試過了?？纯瓷厦?2個(gè)步驟，前5步活脫脫在講如何實(shí)施持續(xù)集成，若進(jìn)一步了解其內(nèi)容，大家不妨瀏覽Joel的Blog原文。3.2持續(xù)集成不是XP專有實(shí)踐持續(xù)集成屬于IID（持續(xù)迭代開發(fā)）方法學(xué)，在測(cè)試上，就現(xiàn)實(shí)而論是以xUnit實(shí)踐為代表，持續(xù)集成概念被XP刻上深深烙印，但它確非XP專有實(shí)踐。早在20世紀(jì)60年代IBM的FederalSystemsDivision就開始應(yīng)用IID開發(fā)模式了，源于IBM的集成產(chǎn)品開發(fā)流程（IPD）相對(duì)CMM，有個(gè)顯著特征，它支持漸增迭代開發(fā)，雖然迭代頻度比不上微軟每日構(gòu)造，但其理念仍是持續(xù)的迭代開發(fā)。有意思的是，PD流程在華為公司本土化后，發(fā)展出“版本火車”理論，有點(diǎn)類似于Scrum實(shí)踐了，版本火車不僅讓產(chǎn)品（通常是大產(chǎn)品）版本發(fā)布更加規(guī)范有序（因?yàn)榛疖嚳偸嵌c(diǎn)出發(fā)的），也推動(dòng)研發(fā)以更快頻度推陳出新。但目前持續(xù)集成仍在有限范圍能成功應(yīng)用，微軟無疑是個(gè)樣板，畢竟純軟件產(chǎn)品容易實(shí)施每日構(gòu)造，還有不少實(shí)踐XP的項(xiàng)目，持續(xù)集成也運(yùn)用得很成功。所以，就整體而言，持續(xù)集成能否成功，已經(jīng)不是方法論問題，更多是IT工具如何支撐的問題。3.3為什么持續(xù)集成我們看一個(gè)實(shí)際案例，某通信產(chǎn)品在VI版本編碼完成時(shí)，進(jìn)行過規(guī)范的單元測(cè)試活動(dòng)，之后V2、V3要不斷增加功能、修改功能，就放棄單元測(cè)試了，當(dāng)V3最后市場(chǎng)交付時(shí)統(tǒng)計(jì)發(fā)現(xiàn)，相對(duì)VI版本，代碼修改量已達(dá)到40%。QA從其中兩個(gè)模塊隨機(jī)抽取100個(gè)問題單做缺陷分析，結(jié)果發(fā)現(xiàn)：第一個(gè)模塊有50%的問題是在VI版本單元測(cè)試結(jié)束后引入的，而另一模塊也有30%問題是單元測(cè)試后引入的。也就是說，在第一次完整單元測(cè)試之后，代碼修改了40%，也因此產(chǎn)生了40%的問題，由于增量白盒測(cè)試難以實(shí)施，這些問題都被遺留到后期功能測(cè)試中才發(fā)現(xiàn)。單元測(cè)試沒能持續(xù)開展，帶來后果是：發(fā)現(xiàn)問題不徹底，付出代價(jià)也更高。上述模式在業(yè)界還普遍存在，我們稱為一次測(cè)試，與持續(xù)測(cè)試不同，一次測(cè)試的測(cè)試設(shè)計(jì)只做一次，用例仍可重復(fù)拿來跑，因?yàn)闇y(cè)試腳本與源碼不同步，用例維護(hù)是間歇進(jìn)行的，或者干脆不維護(hù)。注意，一次測(cè)試與持續(xù)測(cè)試的差別不在于用例是否可重用，而在于測(cè)試設(shè)計(jì)的持續(xù)性。許多企業(yè)做不到持續(xù)測(cè)試，其主要原因不是不想做，第一次測(cè)試都認(rèn)真做了，追加代碼或修改代碼當(dāng)然也要做測(cè)試，做不了是因?yàn)椴僮魃洗嬖诶щy。持續(xù)測(cè)試是需要一開始就規(guī)劃，測(cè)試工具要配套跟進(jìn)才能順利實(shí)施的，對(duì)于老產(chǎn)品，代碼修修補(bǔ)補(bǔ)，無論一次測(cè)試還是持續(xù)測(cè)試都很難做得好。引入持續(xù)測(cè)試，不僅以更低代價(jià)發(fā)現(xiàn)更多問題，更重的是，它體現(xiàn)了一個(gè)組織在測(cè)試?yán)砟钌嫌匈|(zhì)的飛躍。一次測(cè)試是一種被動(dòng)測(cè)試，開發(fā)人員受制于組織紀(jì)律（或主管、QA等壓力）才去做，而持續(xù)測(cè)試是主動(dòng)測(cè)試，大家在測(cè)試中嘗到甜頭，從原先不自覺狀態(tài)，過渡到自發(fā)、自覺的時(shí)時(shí)做測(cè)試。這兩種情形無疑有天壤之別，前面提到的Joel測(cè)試12步驟，實(shí)際上是微軟實(shí)踐，與持續(xù)集成相關(guān)的有5條，足見它的重要性，是否引入持續(xù)集成，以及實(shí)施的效果如何，實(shí)際反映了一流公司與二流公司的差距。白盒測(cè)試是一項(xiàng)實(shí)踐性很強(qiáng)的技術(shù)，我們講第4代白盒測(cè)試方法，離不開相關(guān)測(cè)試實(shí)踐，尤其是測(cè)試工具支撐。本文的上篇先從理論上介紹什么是4GWM，下篇?jiǎng)t結(jié)合具體測(cè)試工具介紹4GWM的典型實(shí)踐。4.1在線測(cè)試4GWM第一個(gè)關(guān)鍵域是在線測(cè)試，包括3個(gè)關(guān)鍵特征?在線測(cè)試驅(qū)動(dòng)?在線腳本樁?在線測(cè)試用例設(shè)計(jì)、運(yùn)行，及評(píng)估改進(jìn)一次白盒測(cè)試中（即一個(gè)用例中）我們關(guān)注被測(cè)單元功能是否實(shí)現(xiàn)，被測(cè)單元作為整體，在特定環(huán)境下運(yùn)行（比如某些全局變量取特定值、某些依賴線程或任務(wù)已啟動(dòng)等），具有特定的輸入輸出，這幾項(xiàng)都屬于“測(cè)試驅(qū)動(dòng)”。另外，被測(cè)單元若能正確運(yùn)行，還依賴它調(diào)用的子函數(shù)是否提供正常功能，這些子函數(shù)我們稱為“測(cè)試樁”。分層結(jié)構(gòu)如下圖：在三層實(shí)體中，被測(cè)單元是測(cè)試關(guān)注對(duì)象，要求盡可能真實(shí)，我們?cè)O(shè)法維持其原狀，測(cè)試驅(qū)動(dòng)與測(cè)試樁可以模擬（或叫仿真），允許存在一定失真，但要求盡可能高效，否則測(cè)試產(chǎn)出的拐點(diǎn)問題解決不了。4.1.1腳本驅(qū)動(dòng)與腳本樁先回答一個(gè)基礎(chǔ)問題，編寫測(cè)試用例應(yīng)優(yōu)先采用腳本語言，而不與被測(cè)代碼使用同一的語言，為什么？還是應(yīng)為軟件測(cè)試的深層次問題——投入產(chǎn)出比，如果被測(cè)編程語言的抽象度較低、封裝性差，用起來就很麻煩。比如拿C或C++寫測(cè)試用例，得處處小心內(nèi)存操作，要正常申請(qǐng)釋放、注意不越界，時(shí)常關(guān)心使用變量是否安全、是否已初始化等。也許有人說，不對(duì)，CppUnit中拿C++測(cè)C++，我用得很爽呀？噢，沒錯(cuò)，我得先恭喜這位老兄，你是好同志吶，安于現(xiàn)狀不失為一種好品質(zhì)。我們?cè)O(shè)想一下，編寫一萬行C++代碼，你要寫多行代碼測(cè)試它，一千行？兩千行？不對(duì)，是一萬行，按業(yè)界普遍規(guī)律，測(cè)試代碼行至少要與被測(cè)代碼行數(shù)相當(dāng)才見效果，測(cè)試代碼要不要調(diào)試？當(dāng)然要調(diào)，天哪，算出來的了，測(cè)試投入至少是開發(fā)投入的三、四倍才做得下來（后期還有功能測(cè)試、性能測(cè)試、兼容性測(cè)試等等，還要占用大量精力），這樣的項(xiàng)目是不是處在能否成功的拐點(diǎn)上？所以，如果您還在用C、C++等過程語言寫用例，請(qǐng)盡快換到腳本語言，如python、ruby、CSE等，用腳本語言能讓你編寫用例的效率提高3到5倍。用腳本編寫用例，意味著測(cè)試驅(qū)動(dòng)與測(cè)試樁仿真也用腳本語言。我們看一下VcTester工具使用的測(cè)試腳本，假定被測(cè)對(duì)象是C代碼的冒泡排序算法：voidBubbleSort(OBJ_DATA_PTR*ObjList,intiMax){——inti,j,exchanged;OBJ_DATA*tmp;for(i=0;i<iMax;i++) //maximumloopiMaxtimes{exchanged=0;for(j=iMax-1;j>=i;j--){if(ObjCompare(ObjList[j+1],ObjList[j])<0){ //exchangetherecordtmp=ObjList[j+1];ObjList[j+1]=ObjList[j];ObjList[j]=tmp;exchanged=1;}}if([exchanged)return;}}排序函數(shù)(BubbleSort)中調(diào)用了對(duì)象比較函數(shù)(ObjCompare),假定當(dāng)前測(cè)試對(duì)象是BubbleSort函數(shù)，我們編寫測(cè)試用例如下：funcStubFunc(vc):ifvc.argO-〉Data()<vc.arg1-〉Data():return-1;endelsereturn1;end;vd.ObjCompare.stub(StubFunc);#打腳本樁vd.BubbleSort(vd.gList,6); #發(fā)起測(cè)試assert(vd.gList[O]-〉Data<=vd.gList[1]-〉Data);#檢查測(cè)試結(jié)果vd.ObjCompare.stub(nil); #青除腳本樁腳本驅(qū)動(dòng)是指將被測(cè)系統(tǒng)的全局變量與全局函數(shù)映射到腳本系統(tǒng)，然后使用腳本讀寫C語言變量，調(diào)用C語言函數(shù)。在VcTester中，C語句的全局變量與函數(shù)映射到腳本的vd集合下，如上面腳本使用“vd.gList”讀取C變量，使用“vd.BubbleSort()”調(diào)用C函數(shù)。腳本樁是指定義一個(gè)腳本函數(shù)，然后讓這個(gè)腳本函數(shù)代替某個(gè)C函數(shù)，打腳本樁是為了讓一段腳本化測(cè)試邏輯，在動(dòng)態(tài)執(zhí)行中，代替被測(cè)系統(tǒng)中的樁函數(shù)。因?yàn)闇y(cè)試中我們經(jīng)常要讓某些子函數(shù)返回特定值，使被測(cè)函數(shù)的特定路徑能被覆蓋。上面例子定義了一個(gè)腳本樁函數(shù)StubFunc，拿這個(gè)腳本函數(shù)模擬對(duì)象比較功能，通過打樁替換C函數(shù)ObjCompare。4.1.2在線測(cè)試邏輯更新4GWM引入腳本驅(qū)動(dòng)與腳本樁，不只是提高測(cè)試設(shè)計(jì)效率，還以此保障在線測(cè)試。所謂在線測(cè)試，是指被測(cè)程序啟動(dòng)后，用例在線設(shè)計(jì)、調(diào)試、運(yùn)行，運(yùn)行結(jié)果在線查看的測(cè)試方法。因?yàn)樗袦y(cè)試操作都在線進(jìn)行，測(cè)試用例不必編譯鏈接，被測(cè)程序也不用復(fù)位重起，被測(cè)環(huán)境(被測(cè)系統(tǒng)的變量、函數(shù)等屬性)在線可查看，所以該測(cè)試模式非常高效，另外，各測(cè)試步驟所見即所得，人性化的操作過程很容易被廣大開發(fā)人員接受。腳本語言具有在線更新功能，比如定義一個(gè)腳本函數(shù)，調(diào)用一次后，發(fā)現(xiàn)某個(gè)地方處理不對(duì)，于是重寫這個(gè)函數(shù)，然后在線的更新這個(gè)函數(shù)定義。編譯語言做不到這一點(diǎn)，修改代碼后必須重新編譯鏈接，程序要復(fù)位重起，腳本語言省去了這些繁瑣過程。比如，在GUI界面編寫測(cè)試用例，定義測(cè)試樁函數(shù)，然后選擇待執(zhí)行的腳本區(qū)塊，按一個(gè)快捷鍵，指定范圍的腳本就執(zhí)行，相關(guān)腳本函數(shù)定義立即被更新，腳本執(zhí)行后的測(cè)試結(jié)果也立即打印輸出。4.1.3拉通測(cè)試小循環(huán)測(cè)試結(jié)果評(píng)估主要是覆蓋率指標(biāo)，包括：語句覆蓋、分支覆蓋、組合條件覆蓋等，結(jié)果評(píng)估也是在線進(jìn)行的，用例執(zhí)行后，隨即在線查閱覆蓋率情況，針對(duì)未覆蓋部分再增加用例。當(dāng)上圖4個(gè)步驟都能在線操作后，測(cè)試小循環(huán)就拉通了，4GWM的第一個(gè)關(guān)鍵域（在線測(cè)試）的目的就在這兒，拉通測(cè)試小循環(huán)，是大幅度提高測(cè)試工作效率的第一環(huán)節(jié)。接下來通過灰盒調(diào)測(cè)，拉通開發(fā)大循環(huán)是提高效率的第二環(huán)節(jié)。4.2灰盒調(diào)測(cè)4GWM第二個(gè)關(guān)鍵域是灰盒調(diào)測(cè)，包括3個(gè)關(guān)鍵特征?基于調(diào)用接口?調(diào)試即測(cè)試?集編碼、調(diào)試、測(cè)試于一體4.2.1白盒測(cè)試的粒度白盒測(cè)試關(guān)注被測(cè)函數(shù)的功能表現(xiàn)，要關(guān)注到什么程度，在不同的測(cè)試實(shí)踐與測(cè)試工具中要求各不同。我們可以簡單的分為3個(gè)級(jí)別，一是源碼行級(jí)別，二是函數(shù)調(diào)用級(jí)別，三是組件接口級(jí)別。源碼行級(jí)別具有調(diào)試特征，可以關(guān)注到函數(shù)內(nèi)局部變量，當(dāng)測(cè)試停留于該級(jí)別會(huì)顯得過于細(xì)碎，因?yàn)榻Y(jié)構(gòu)化程序開發(fā)總是以函數(shù)為單位逐級(jí)劃分功能的，函數(shù)內(nèi)的代碼穩(wěn)定性差，變量定義經(jīng)常變化，過程處理也經(jīng)常調(diào)整。組件接口級(jí)別的測(cè)試對(duì)象僅關(guān)注到組件接口，如Corba接口、控件調(diào)用接口、消息隊(duì)列接口等，這一級(jí)別的白盒測(cè)試無疑偏于粗放。4GWM規(guī)定的白盒測(cè)試關(guān)注粒度是函數(shù)調(diào)用接口，即，測(cè)試設(shè)計(jì)只關(guān)心函數(shù)的輸入、輸出，及該函數(shù)運(yùn)行中對(duì)全局變量的影響，遵循如下原型：設(shè)計(jì)測(cè)試用仞『，先通過腳本構(gòu)造被測(cè)函數(shù)的輸入?yún)?shù)，修改特定全局變量，使被測(cè)函數(shù)處于某特定運(yùn)行環(huán)境下，這兩步屬于測(cè)試驅(qū)動(dòng)。然后調(diào)用被函數(shù)，最后判斷測(cè)試結(jié)果，因?yàn)檫\(yùn)行被測(cè)函數(shù)可能影響輸入?yún)?shù)、全局變量與返回值，所以判斷用『是否運(yùn)行通過，觀察對(duì)象也是這三者。在用『設(shè)計(jì)過程中，我們并不關(guān)心函數(shù)內(nèi)局部變量如何聲明，也不關(guān)心函數(shù)內(nèi)邏輯過程如何處理，只關(guān)心被測(cè)對(duì)象的輸入與輸出，這是一種典型的黑盒思維模式。準(zhǔn)確來說，4GWM是一種灰盒測(cè)試方法，盡管操作方式是黑盒的，但測(cè)試設(shè)計(jì)是白盒的，因?yàn)榭吹靡娫创a，測(cè)試設(shè)計(jì)可以有針對(duì)性的進(jìn)行，測(cè)試過程評(píng)估也是白盒的，運(yùn)行一遍用『后，查看哪些代碼行有沒跑到，再有針對(duì)性補(bǔ)充用『。所以，我們從整體來看，4GWM是介于黑盒與白盒之間的灰盒測(cè)試。根據(jù)已有實(shí)踐推斷，上述灰盒模式關(guān)注的測(cè)試粒度是恰如其分的，既避開了調(diào)試操作的隨意性，也使測(cè)試用『建立在較穩(wěn)健的基礎(chǔ)之上，只要函數(shù)調(diào)用接口沒變，局部變量改了或邏輯過程調(diào)整了，就不會(huì)影響已有用『。同時(shí)，黑盒操作方式附帶白盒分析模式，保障了4GWM具有高效、便捷的特性。4.2.2檢視器檢視器(Inspector)是4GWM推薦的測(cè)試輔助工具，它介于測(cè)試器(Tester)與調(diào)試器(Debugger)之間，是一種能夠提供腳本化控制的粗粒度的調(diào)試器。使用檢視器有助于把無規(guī)則的調(diào)試過程轉(zhuǎn)化為規(guī)范的測(cè)試過程。檢視器有兩種運(yùn)行模式：斷點(diǎn)調(diào)試模式與測(cè)試模式。前者在斷點(diǎn)條件滿足時(shí)進(jìn)入單步跟蹤狀態(tài)，后者在斷點(diǎn)上附加特定腳本語句(比如修改變量、檢查變量值等)，當(dāng)斷點(diǎn)條件滿足附加語句即自動(dòng)執(zhí)行，此時(shí)斷點(diǎn)僅作為一個(gè)觀察控制點(diǎn)( PointsofControlandObservation,PCO)存在，不用作交互調(diào)試目的。一次典型的檢視過程如下圖所示：首先在被測(cè)函數(shù)上設(shè)置斷點(diǎn)，接著用腳本構(gòu)造調(diào)試環(huán)境，包括修改變量、設(shè)置腳本樁等，然后發(fā)起測(cè)試，在斷點(diǎn)觸發(fā)后的單步跟蹤狀態(tài)，觀察各個(gè)變量值是否預(yù)期，還可以修改變量使被測(cè)函數(shù)中特定分支能夠執(zhí)行。最后在調(diào)試完成時(shí)，可以將當(dāng)前調(diào)試操作，包括設(shè)置斷點(diǎn)、檢查變量值是否預(yù)期、修改變量等，自動(dòng)轉(zhuǎn)化為測(cè)試腳本。上述檢視操作向自動(dòng)腳本轉(zhuǎn)換還解決測(cè)試數(shù)據(jù)構(gòu)造問題，尤其在復(fù)雜系統(tǒng)中，構(gòu)造測(cè)試數(shù)據(jù)比較麻煩，比如通信協(xié)議的消息包數(shù)據(jù)，創(chuàng)建消息后要填寫數(shù)十，甚至數(shù)百個(gè)字段的值。檢視操作可以在函數(shù)調(diào)用鏈中插入一段腳本代碼，比如被測(cè)代碼先調(diào)用一個(gè)初始化協(xié)議消息的函數(shù)，得到正確消息包后傳遞給被測(cè)函數(shù)，我們通過插入腳本，在被測(cè)函數(shù)運(yùn)行之前修改傳入消息包的特定字段，從而實(shí)現(xiàn)特定路徑的覆蓋測(cè)試。采用該方法設(shè)計(jì)用例是非常廉價(jià)的，直接重用被測(cè)系統(tǒng)的局部功能，免去了繁重的測(cè)試驅(qū)動(dòng)構(gòu)造工作。檢視過程類似于調(diào)試，主要差別如下：檢視器斷點(diǎn)只在函數(shù)入口設(shè)置，調(diào)試器可以在任意語句設(shè)斷點(diǎn)。檢視既可以在IDE界面手工操作，也可以通過寫腳本控制，調(diào)試器一般只支持手工操作。檢視器在斷點(diǎn)狀態(tài)下可以運(yùn)行任意合法的測(cè)試腳本，調(diào)試器無此功能。由于檢視器與編程語言自帶的調(diào)試器實(shí)現(xiàn)原理不同，一般情況下兩者可以同時(shí)使用，可同時(shí)設(shè)置檢視斷點(diǎn)與調(diào)試斷點(diǎn)。4.2.3調(diào)試就是測(cè)試調(diào)試為了定位問題，測(cè)試是為了發(fā)現(xiàn)問題，兩者雖不能互相替換，但當(dāng)測(cè)試手段趨于豐富，測(cè)試工具也能越來多的承擔(dān)調(diào)試職責(zé)。讓測(cè)試工具承擔(dān)部分調(diào)試功能，可在如下方面獲益：調(diào)試與測(cè)試共享運(yùn)行環(huán)境被測(cè)代碼片斷是在特定環(huán)境下運(yùn)行的，無論調(diào)試還是測(cè)試，都得先構(gòu)造運(yùn)行環(huán)境，比如準(zhǔn)備特定的數(shù)據(jù)、修改狀態(tài)變量、啟動(dòng)特定線程或任務(wù)。借助測(cè)試工具在線構(gòu)造測(cè)試驅(qū)動(dòng)與測(cè)試樁，調(diào)試環(huán)境能便利的搭建起來，而且，構(gòu)造運(yùn)行環(huán)境的腳本能直接在相關(guān)測(cè)試用例中重用。將不可重復(fù)的調(diào)試轉(zhuǎn)化為可重復(fù)的測(cè)試調(diào)試過程具有隨意性與不可重復(fù)性，在哪兒設(shè)斷點(diǎn)、如何看變量、如何單步跟蹤都因人而異。調(diào)試的操作過程難被重用，不像測(cè)試用例，以形式化腳本記錄操作過程，想怎么重復(fù)就怎么重復(fù)，上節(jié)介紹的檢視器就是一種可重復(fù)的調(diào)試器。操作自動(dòng)重復(fù)是提高工作效率的基本途徑，不必強(qiáng)求全過程重復(fù)，片斷可重復(fù)就能大幅提高效率了。測(cè)試設(shè)計(jì)可以很好的重用被測(cè)系統(tǒng)中局部功能如上一節(jié)舉例，直接調(diào)用被測(cè)系統(tǒng)的消息構(gòu)造函數(shù)，能避開繁重的協(xié)議消息仿真工作。解決腳本調(diào)試與源碼調(diào)試的交叉影響問題實(shí)踐證明，白盒測(cè)試的大部分時(shí)間消耗在腳本編寫與調(diào)試中，調(diào)試好的用例，執(zhí)行幾乎不要時(shí)間（即使要時(shí)間，挪到晚上讓它自己自動(dòng)跑好了）。測(cè)試腳本調(diào)試與源碼調(diào)試是交叉進(jìn)行的，單元測(cè)試中的源碼與測(cè)試腳本都不穩(wěn)定，通常我們讓腳本發(fā)起測(cè)試，須同時(shí)跟蹤腳本與源碼，查看執(zhí)行結(jié)果正不正確。如果這兩者調(diào)試過程是分離的，調(diào)源碼時(shí)不能看腳本，或調(diào)腳本時(shí)不能看被測(cè)變量，其操作過程必然非常痛苦。當(dāng)測(cè)試承擔(dān)起調(diào)試職責(zé)，兩者合二為一，交叉影響的問題即自動(dòng)解決。實(shí)事上，大家把測(cè)試當(dāng)測(cè)試、調(diào)試當(dāng)調(diào)試，很大程度上是因?yàn)闆]把測(cè)試腳本也看作產(chǎn)品代碼，不把它當(dāng)成產(chǎn)品固有部件，如果觀念轉(zhuǎn)變過來了，測(cè)試腳本也是代碼，調(diào)試腳本就是調(diào)試代碼，兩者本應(yīng)合二為一的。當(dāng)然，還存在工具的問題，缺少好工具，將兩者強(qiáng)扭一起最終仍會(huì)不歡而散。

4GWM嘗試讓測(cè)試工具承擔(dān)起90%的調(diào)試工作，完全替換并非必要。如果測(cè)試工具能承擔(dān)大部分調(diào)試，開發(fā)大循環(huán)就能拉通了。下圖是開發(fā)與測(cè)試尚未拉通，是孤立兩個(gè)過程的情況：測(cè)試設(shè)計(jì)（即寫腳本）與產(chǎn)品設(shè)計(jì)（即編碼）融為一體，調(diào)試腳本與源碼成為開發(fā)人員主要日常工作。上圖的結(jié)果評(píng)估，對(duì)于測(cè)試腳本是覆蓋率，對(duì)于產(chǎn)品源碼是其運(yùn)行表現(xiàn)（其結(jié)果可能預(yù)期，也可能出差錯(cuò)了），評(píng)估這兩者，再補(bǔ)充用例及完善源碼，之后進(jìn)入下一輪迭代循環(huán)。調(diào)試通過的腳本打包到測(cè)試工程，就是能夠支持每日構(gòu)建的用例庫；測(cè)試通過的源碼經(jīng)release發(fā)布，就是在市場(chǎng)上能提供預(yù)期功能的正式產(chǎn)品。4.2.4編碼、調(diào)試、測(cè)試集成平臺(tái)4GWM在方法論上要求大家把測(cè)試腳本也看成產(chǎn)品代碼，以黑盒調(diào)測(cè)代替大部分單步調(diào)試，但方法論能否順利被實(shí)踐支持，還嚴(yán)重依賴于測(cè)試工具的品質(zhì)。為此，4GWM要限定測(cè)試工具必須將編碼、調(diào)試、測(cè)試集成到一個(gè)平臺(tái)。該要求實(shí)際限定測(cè)試腳本要擁有與源碼一樣的權(quán)益，由于歷史原因，各主流語言的集成開發(fā)環(huán)境總是讓代碼能在同一平臺(tái)下編輯、調(diào)試的，現(xiàn)在既然把腳本也看成一種代碼，就應(yīng)該賦予它同等權(quán)益。拿通俗的話來講，我們要構(gòu)造一種集成平臺(tái)，集編碼、調(diào)試、測(cè)試于一身，是為了讓“測(cè)試”這個(gè)后媽晉升級(jí)為親媽，原先“調(diào)試”是親媽，占盡天時(shí)地利，不妨從IDE讓出一些位置。把調(diào)測(cè)一體化平臺(tái)作為4GWM特征之一明確下來，可以防止4GWM在不同編程語言及不同測(cè)試工具下實(shí)施走樣。請(qǐng)注意，集成平臺(tái)的規(guī)定不是4GWM本質(zhì)方法論，但4GWM對(duì)工具化支持有比較高要求，配套工具要有足夠的功能，能讓廣大開發(fā)人員隨心所欲的使用測(cè)試手段替代調(diào)試。4.3持續(xù)測(cè)試4GWM第三個(gè)關(guān)鍵域是持續(xù)測(cè)試，包括3個(gè)關(guān)鍵特征?測(cè)試設(shè)計(jì)先行?持續(xù)保障信心?重構(gòu)測(cè)試設(shè)計(jì)4.3.1測(cè)試設(shè)計(jì)先行測(cè)試先行是XP典型實(shí)踐，XP中的測(cè)試先行是TestDrivenDevelopment(TDD)，4GWM規(guī)定的測(cè)試先行是TestDesignFirst(TDF),兩者主體內(nèi)容應(yīng)該一致，細(xì)節(jié)要求稍有差異。為方便大家理解，我們還是從XP的TDD基礎(chǔ)上介紹4GWM的TDF。TDD是測(cè)試驅(qū)動(dòng)開發(fā)，測(cè)試代碼在產(chǎn)品代碼之前編寫，要求產(chǎn)品先能測(cè)試，然后在解決問題過程中補(bǔ)充設(shè)計(jì)或完善設(shè)計(jì)。一個(gè)簡單的TDD例子，比如我們要編寫一個(gè)函數(shù)GetHash計(jì)算某對(duì)象的has*值，定義GetHash函數(shù)的原型后，即開始設(shè)計(jì)用例，如：//確定函數(shù)原型intGetHash(void*obj){assert(0”Notdefineyet.");}//設(shè)計(jì)用例assert(GetHash(newObject(12))==12);assert(GetHash(newObJect("AName"))==63632);上述測(cè)試肯定通不過，所以要解決問題，先是整形對(duì)象的hash值算不對(duì)，我們?cè)贕etHash函數(shù)中添加處理分支：intGetHash(void*obj){if(ObjType(obj)==dtlnt){returniHash;}assert(0”Notdefineyet.");}然后，再次運(yùn)行用例發(fā)現(xiàn)字串對(duì)象的hash值也不對(duì)，再添加相應(yīng)處理代碼。TDF也按上述模式操作，但相比TDD稍有差異，主要表現(xiàn)在：TDD強(qiáng)調(diào)測(cè)試驅(qū)動(dòng)開發(fā)，即：測(cè)試先做，然后在測(cè)試主導(dǎo)下完善被測(cè)系統(tǒng)。而TDF只是要求測(cè)試設(shè)計(jì)先做，并不強(qiáng)制測(cè)試代碼總比被測(cè)功能先跑起來。TDD要求一開始就寫規(guī)范的用例，而TDF更多的是讓調(diào)試環(huán)境先跑起來，調(diào)測(cè)代碼既可以是規(guī)范的用例，也可以是待整理的腳本，即草稿狀態(tài)的用例。TDD更傾向于自頂向下的開發(fā)模式，TDF則較少受此限制，實(shí)際操作時(shí)，使用最多的是混合模式。即：如果自頂向下比較容易操作，就自頂向下先設(shè)計(jì)用例，如果自頂向下不好操作，先自底向上先寫底層代碼也無妨。TDF通常采用三文治操作模式，即：先設(shè)計(jì)少量用例，讓調(diào)測(cè)環(huán)境順利跑起來，接著補(bǔ)充功能代碼，最后再增加用例使新寫的代碼能完整測(cè)試。因?yàn)楣δ芫幋a夾在中間，成為三文治的餡，過程的兩端都是用例設(shè)計(jì)。由于結(jié)構(gòu)化設(shè)計(jì)的緣故，TDF三文治模式也是層層嵌套、依次深入的，先寫高層次測(cè)試腳本，接著高層次編碼，然后補(bǔ)充高層次測(cè)試設(shè)計(jì)，之后進(jìn)入下一層結(jié)構(gòu)化設(shè)計(jì)，同樣先設(shè)計(jì)下層測(cè)試腳本，接著下層功能編碼，再補(bǔ)充下層測(cè)試設(shè)計(jì)。TDF要求盡可能高效的編寫用例，調(diào)試操作可以轉(zhuǎn)化成用例，已測(cè)試通過的功能也可以在用例中重用，TDD對(duì)此沒有特別要求。TDD與TDF都強(qiáng)調(diào)盡可能在編碼之前設(shè)計(jì)用例，看得到代碼后編寫用例容易墜入慣性思維陷阱，比如，某個(gè)被測(cè)函數(shù)少了一個(gè)分支處理，看自己寫的代碼做測(cè)試，也同樣容易忽略這個(gè)分支。所以，先寫腳本后寫代碼可以檢驗(yàn)設(shè)計(jì)是否合理，這時(shí)測(cè)試設(shè)計(jì)依據(jù)的是規(guī)格。測(cè)試先行經(jīng)XP實(shí)踐論證，整體是可行的，BobyGeorge與LaurieWilliams的統(tǒng)計(jì)數(shù)據(jù)表明（參見《AnInitialInvestigationofTestDrivenDevelopmentinIndustry》），實(shí)施TDD,有87.5%的開發(fā)者認(rèn)為能更好理解需求，有95.8%認(rèn)為TDD有助于減少bug，78%的人認(rèn)為TDD提高了生產(chǎn)率，另外還有92%的人認(rèn)為TDD能促進(jìn)代碼質(zhì)量，79%的人認(rèn)為TDD有助于簡化設(shè)計(jì)。同時(shí)，這份統(tǒng)計(jì)還表明，有40%開發(fā)者表示采用TDD比較困難，困難主要原因在于看不到代碼情況下先做測(cè)試設(shè)計(jì)，容易讓人無所適從。TDF在一定程度上克服TDD應(yīng)用困難的弊端，它并不過于強(qiáng)調(diào)測(cè)試設(shè)計(jì)一定先于編碼，但要求先行編寫的測(cè)試腳本與代碼能盡早展現(xiàn)功能，或盡早的驗(yàn)證規(guī)格，腳本與代碼一起對(duì)等的被設(shè)計(jì)者用來實(shí)施他的意圖——當(dāng)然，遵循結(jié)構(gòu)化設(shè)計(jì)原則，越高層越抽象的邏輯應(yīng)先驗(yàn)證，越重要的功能也應(yīng)先驗(yàn)證。盡早展現(xiàn)功能，也意味著：寫一點(diǎn)測(cè)一點(diǎn)、測(cè)一點(diǎn)寫一點(diǎn)，一有可展現(xiàn)或可調(diào)試的小功能，測(cè)試設(shè)計(jì)總與功能編碼同步跟進(jìn)的。4.3.2如何持續(xù)保障信心4GWM非常強(qiáng)調(diào)維持良好的客戶體驗(yàn)，在線測(cè)試保證白盒測(cè)試所見即所得，人性化操作催生快感，拉通測(cè)試小循環(huán)與開發(fā)大循環(huán)，使工作效率大幅提高，強(qiáng)化了這種快感，現(xiàn)在再加一條：測(cè)試過程可度量，讓開發(fā)者至始至終都對(duì)自己的代碼充滿信心，鞏固快感使個(gè)體愉悅延伸到團(tuán)隊(duì)愉悅。白盒測(cè)試最重要的度量指標(biāo)是覆蓋率，包括語句覆蓋、分支覆蓋、條件覆蓋、組合條件覆蓋、路徑覆蓋、數(shù)據(jù)流覆蓋等。設(shè)計(jì)測(cè)試度量標(biāo)準(zhǔn)，不是種類越多就越好，也是越高標(biāo)準(zhǔn)（如路徑覆蓋、MCDC覆蓋）就越好，最重要的是，要恰如其分，另外還得考慮現(xiàn)實(shí)因素：測(cè)試工具能不能支持。尤其在持續(xù)測(cè)試模式下，恰當(dāng)?shù)倪x擇覆蓋指標(biāo)尤顯重要，要求過高使測(cè)試成為累贅，必然讓持續(xù)測(cè)試做不下去。與一次測(cè)試不同，不恰當(dāng)覆蓋指標(biāo)帶來的負(fù)面影響，在持續(xù)迭代中放大了，稍過復(fù)雜就帶來很大傷害。實(shí)踐經(jīng)驗(yàn)表明，常規(guī)的白盒測(cè)試拿語句覆蓋與分支覆蓋度量已經(jīng)足夠，對(duì)于局部邏輯復(fù)雜的代碼，再增設(shè)MCDC覆蓋就夠用了。4GWM推薦把調(diào)用覆蓋（近似于語句覆蓋）當(dāng)作主要測(cè)試指標(biāo)，調(diào)用覆蓋是觀察函數(shù)調(diào)用與被調(diào)用關(guān)系的一種覆蓋指標(biāo)，因?yàn)?GWM以函數(shù)為單位關(guān)注測(cè)試過程，函數(shù)是識(shí)別不同測(cè)試及同一測(cè)試中不同分層的依據(jù)，以調(diào)用關(guān)系度量測(cè)試程度，是這種基于調(diào)用接口、灰盒模式的測(cè)試方法論自然延伸。除了覆蓋率指標(biāo)，我們還得區(qū)別經(jīng)意測(cè)試與不經(jīng)意測(cè)試。比方測(cè)試某特定分支設(shè)計(jì)一個(gè)用例，除了你期望的分支跑到外，同一函數(shù)中其它部分的某些分支也能跑到，這是