測試設計（即寫指令碼）與產品設計（即編碼）融為一體，除錯指令碼與原始碼成為開發人員主要日常工作。上圖的結果評估，對於測試指令碼是覆蓋率，對於產品原始碼是其執行表現（其結果可能預期，也可能出差錯了），評估這兩者，再補充用例及完善原始碼，之後進入下一輪迭代迴圈。

除錯通過的指令碼打包到測試工程，就是能夠支援每日構建的用例庫；測試通過的原始碼經release釋出，就是在市場上能提供預期功能的正式產品。

4.2.4編碼、除錯、測試整合平臺

4GWM在方法論上要求大家把測試指令碼也看成產品程式碼，以黑盒調測代替大部分單步除錯，但方法論能否順利被實踐支援，還嚴重依賴於測試工具的品質。為此，4GWM要限定測試工具必須將編碼、除錯、測試整合到一個平臺。

該要求實際限定測試指令碼要擁有與原始碼一樣的權益，由於歷史原因，各主流語言的整合開發環境總是讓程式碼能在同一平臺下編輯、除錯的，現在既然把指令碼也看成一種程式碼，就應該賦予它同等權益。拿通俗的話來講，我們要構造一種整合平臺，集編碼、除錯、測試於一身，是為了讓“測試”這個後媽晉升級為親媽，原先“除錯”是親媽，佔盡天時地利，不妨從IDE讓出一些位置。

把調測一體化平臺作為4GWM特徵之一明確下來，可以防止4GWM在不同程式語言及不同測試工具下實施走樣。請注意，整合平臺的規定不是4GWM本質方法論，但4GWM對工具化支援有比較高要求，配套工具要有足夠的功能，能讓廣大開發人員隨心所欲的使用測試手段替代除錯。

4.3持續測試

4GWM第三個關鍵域是持續測試，包括3個關鍵特徵：

²測試設計先行

²持續保障信心

²重構測試設計

4.3.1測試設計先行

測試先行是XP典型實踐，XP中的測試先行是Test Driven Development（TDD），4GWM規定的測試先行是Test Design First（TDF），兩者主體內容應該一致，細節要求稍有差異。

為方便大家理解，我們還是從XP的TDD基礎上介紹4GWM的TDF。TDD是測試驅動開發，測試程式碼在產品程式碼之前編寫，要求產品先能測試，然後在解決問題過程中補充設計或完善設計。一個簡單的TDD例子，比如我們要編寫一個函式GetHash計算某物件的hash值，定義GetHash函式的原型後，即開始設計用例，如：

// 確定函式原型

int GetHash(void *obj)

{

assert(0,”Not define yet.”);

}

// 設計用例

assert( GetHash(newObject(12)) == 12 );
assert( GetHash(newObject(”AName”)) == 63632 );

上述測試肯定通不過，所以要解決問題，先是整形物件的hash值算不對，我們在GetHash函式中新增處理分支：

int GetHash(void *obj)

{

if ( ObjType(obj) == dtInt )
{

...

return iHash;

}

assert(0,”Not define yet.”);

}

然後，再次執行用例發現字串物件的hash值也不對，再新增相應處理程式碼。

TDF也按上述模式操作，但相比TDD稍有差異，主要表現在：

1.TDD強調測試驅動開發，即：測試先做，然後在測試主導下完善被測系統。而TDF只是要求測試設計先做，並不強制測試程式碼總比被測功能先跑起來。

TDD要求一開始就寫規範的用例，而TDF更多的是讓除錯環境先跑起來，調測程式碼既可以是規範的用例，也可以是待整理的指令碼，即草稿狀態的用例。

2.TDD更傾向於自頂向下的開發模式，TDF則較少受此限制，實際操作時，使用最多的是混合模式。即：如果自頂向下比較容易操作，就自頂向下先設計用例，如果自頂向下不好操作，先自底向上先寫底層程式碼也無妨。

TDF通常採用三文治操作模式，即：先設計少量用例，讓調測環境順利跑起來，接著補充功能程式碼，最後再增加用例使新寫的程式碼能完整測試。因為功能編碼夾在中間，成為三文治的餡，過程的兩端都是用例設計。由於結構化設計的緣故，TDF三文治模式也是層層巢狀、依次深入的，先寫高層次測試指令碼，接著高層次編碼，然後補充高層次測試設計，之後進入下一層結構化設計，同樣先設計下層測試指令碼，接著下層功能編碼，再補充下層測試設計。

3.TDF要求儘可能高效的編寫用例，除錯操作可以轉化成用例，已測試通過的功能也可以在用例中重用，TDD對此沒有特別要求。

TDD與TDF都強調儘可能在編碼之前設計用例，看得到程式碼後編寫用例容易墜入慣性思維陷阱，比如，某個被測函式少了一個分支處理，看自己寫的程式碼做測試，也同樣容易忽略這個分支。所以，先寫指令碼後寫程式碼可以檢驗設計是否合理，這時測試設計依據的是規格。

測試先行經XP實踐論證，整體是可行的， Boby George與Laurie Williams的統計資料表明（參見《An Initial Investigation of Test Driven Development in Industry》），實施TDD，有87.5%的開發者認為能更好理解需求，有95.8%認為TDD有助於減少bug，78%的人認為TDD提高了生產率，另外還有92%的人認為TDD能促進程式碼質量，79%的人認為TDD有助於簡化設計。同時，這份統計還表明，有40%開發者表示採用TDD比較困難，困難主要原因在於看不到程式碼情況下先做測試設計，容易讓人無所適從。

TDF在一定程度上克服TDD應用困難的弊端，它並不過於強調測試設計一定先於編碼，但要求先行編寫的測試指令碼與程式碼能儘早展現功能，或儘早的驗證規格，指令碼與程式碼一起對等的被設計者用來實施他的意圖——當然，遵循結構化設計原則，越高層越抽象的邏輯應先驗證，越重要的功能也應先驗證。儘早展現功能，也意味著：寫一點測一點、測一點寫一點，一有可展現或可除錯的小功能，測試設計總與功能編碼同步跟進的。

4.3.2如何持續保障信心

4GWM非常強調維持良好的客戶體驗，線上測試保證白盒測試所見即所得，人性化操作催生快感，拉通測試小迴圈與開發大迴圈，使工作效率大幅提高，強化了這種快感，現在再加一條：測試過程可度量，讓開發者至始至終都對自己的程式碼充滿信心，鞏固快感使個體愉悅延伸到團隊愉悅。

白盒測試最重要的度量指標是覆蓋率，包括語句覆蓋、分支覆蓋、條件覆蓋、組合條件覆蓋、路徑覆蓋、資料流覆蓋等。設計測試度量標準，不是種類越多就越好，也是越高標準（如路徑覆蓋、MCDC覆蓋）就越好，最重要的是，要恰如其分，另外還得考慮現實因素：測試工具能不能支援。尤其在持續測試模式下，恰當的選擇覆蓋指標尤顯重要，要求過高使測試成為累贅，必然讓持續測試做不下去。與一次測試不同，不恰當覆蓋指標帶來的負面影響，在持續迭代中放大了，稍過複雜就帶來很大傷害。

實踐經驗表明，常規的白盒測試拿語句覆蓋與分支覆蓋度量已經足夠，對於區域性邏輯複雜的程式碼，再增設MCDC覆蓋就夠用了。4GWM推薦把呼叫覆蓋（近似於語句覆蓋）當作主要測試指標，呼叫覆蓋是觀察函式呼叫與被呼叫關係的一種覆蓋指標，因為4GWM以函式為單位關注測試過程，函式是識別不同測試及同一測試中不同分層的依據，以呼叫關係度量測試程度，是這種基於呼叫介面、灰盒模式的測試方法論自然延伸。

除了覆蓋率指標，我們還得區別經意測試與不經意測試。比方測試某特定分支設計一個用例，除了你期望的分支跑到外，同一函式中其它部分的某些分支也能跑到，這是不經意產生的覆蓋率貢獻。不經意測試使結果評估產生偏差，也給想偷懶的員工帶來便利，比方，測試某通訊產品，設計用例打一個電話，就可能貢獻20%的覆蓋率。

為避免上述情況，4GWM設計出另一指標：測試設計程度（或稱用例覆蓋度），該指標分析測試工程中，被測函式呼叫次數與該函式分支總數的關係。一個函式分支越多，就應設計更多的用例來測試它。用例覆蓋度是作為基礎條件參與測試評估體系的，設定門檻閥值，過了門檻條件，即使多設計用例也不給測試效果加分，但沒過門檻，結果評估則是一票否決的。

4GWM要求測試工具以直觀、簡潔的方式隨時統計測試程度。因為是增量式設計，被測程式碼與測試指令碼都按對等速度遞增的，測試評估先要求定義測試觀察範圍，選中當前關注的被測原始檔與指令碼檔案，成為測試工程，然後，工具始終以工程為單位進行評估，在主操作介面顯示一個標誌燈，亮紅燈表示當前測試未通過，有bug等待先解決，亮黃燈表示測試通過了但覆蓋率指標不符合要求，亮綠燈表示滿足覆蓋指標並且測試通過。

遵循4GWM的軟體開發過程，就是時時刻刻要讓介面綠燈亮起的持續開發過程，這好比開車，功能編碼是踩油門，測試編碼是踩剎車，介面紅綠燈是執法標準，只亮綠燈才能往前走。規則已經很清晰了，時時刻刻遵守交規就是持續信心的保障。

4.3.3重構測試設計

做好人不難，難就難在一輩子都做好人（做壞人更難？沒見過一輩子只做壞事的人）。我們照章開車，沒人給你開罰單，但不意味著專案就沒問題了，方向走反了是南轅北轍，方向偏了可別指望歪打正著。同樣，要讓白盒測試能持續的跟進，很重要一點，測試設計要能快速重構。軟體設計總是難免出錯，事實上，多數產品開發都會經歷幾次區域性重構，當被測程式碼大幅調整，規模與之對等的測試程式碼如何快速修正成了迫切待解決的難題。

重構測試設計要依據被測程式碼，測試工具應儲存最近綠燈狀態時的原始碼資訊，比如，系統中都有哪些全域性符號（變數、函式），符號是什麼型別，被測函式都呼叫哪些子函式、都使用哪些全域性變數等。重構測試設計時，依據歷史被測程式碼與重構後代碼的差異，自動分析當前哪些用例會受影響，如何影響，再具體指出哪些指令碼行應作調整。這好比開車走錯路，要回頭想想在哪個十字路口開始錯的，錯在哪個方向。當上述過程有工具幫我們分析，維護用例的效率就高多了。

5結論

目前，4GWM已有實踐主要集中在C語言測試，線上測試、持續測試諸多實踐很早就有測試工具支援，已有數年應用積累。本文歸納的4GWM九大特徵，都來源於白盒測試長期實踐，先實踐後總結，先有具體應用，然後歸納出通用方法。

這裡再總結一下，上文介紹的3個關鍵域中，線上測試是基礎，是維持良好客戶體驗的第一步，線上測試不僅拉通測試小迴圈，初步解放生產力，而且，線上特性讓灰盒調測成為可能。灰盒調測拉通開發大迴圈，再次大幅度解放生產力。當測試效率兩度提升後，持續整合就不再困難了。