當時我只能簡單的解釋一下�，F在可以多說一些了。
舉個例子，單元測試。適合不同語言的工具有一大堆，各個論壇上都能搜到大堆文章。出現頻率最高的不外乎CppUnit，NUnit，JUnit三種。比起NUnit和JUnit，CppUnit因為C++語言特性的關系，用起來較不方便。
這里我給大家秀一下，解決這個問題，測試工程師會如何的“不擇手段”。
單元測試往往需要解決以下幾個問題：
1. 用戶能在產品代碼中指定需要測試的函數
2. 用戶能在測試代碼中指定需要執行的函數
3. 用戶能指定各種控制執行過程的參數，比如優先級、重復、初始化/清理函數等等
其它就先不說了，待會大家就知道再多的都能做到，現在先做到這三個需求就挺不錯了。需求1是可選的。Visual Studio從2005開始有這個功能，但是如果沒有，估計大家也不會太在意，對吧？
那么，CppUnit如果要做到NUnit和JUnit的樣子會遇到什么困難呢？首先就是C++缺乏反射（Reflection）功能。
你看NUnit和JUnit都是定義了一大堆attribute。用戶通過為函數指定恰當的attribute，就能標明這個函數需要作為test case執行，之前執行初始化函數Setup，之后執行Cleanup，還有重復100次，優先級2什么的，其它的往上堆attribute就行了。
Visual Studio 2005之后為實現需求1，通過.NET Reflection找出一個類的全部成員函數，然后列個表讓你選要測試的函數，最后代碼架子都給你搭好。
而CppUnit得用模板，還有另外一個我忘了名字的C++單元測試工具用的是宏。他們費這么些勁是為了什么呢？其實是為了取得這些信息：
具有特定標記的函數的名字或者入口地址/函數指針
附加在該函數上的各種整數，字符串或者函數指針的值
拿到之后呢？CppUnit也好，NUnit或JUnit也好，都是按照取得的信息規劃每個函數的執行，保證異常和錯誤不干擾其它函數的執行，統計整理執行結果和記錄日志，沒什么區別。
我們來看看，Reflection對于取得那些信息是不是必需的呢？
沒錯，Reflection是能夠在執行時（runtime）取得上述信息，然后在執行時利用它指導test case的執行。
等等，我雞蛋里挑個骨頭：非要把“取得信息”和“指導test case執行”放在同一段執行時期里面嗎？或者說，先“取得信息”，停一下，再“指導test case執行”，行不行？
甚至，“取得信息”放在一個程序里先執行，“指導test case執行”放在另一個程序里后執行，又如何？
更甚之，“取得信息”是讓別的程序做的，之后讓“指導test case執行”撿現成的呢？
可見，Reflection提供了比我們所需要的多得多的功能，實際上我們只需要知道“怎樣指導test case執行”就夠了。
那可以如何實現呢？
一、 編譯鏈接兩次
對，你沒聽錯！編譯鏈接之后除了可執行文件還會產生不少有用信息，最有用的當屬PDB文件，包含了所有標識符（Symbol）的信息。Visual Studio 2003開始就帶有一個DIA SDK，可以在其安裝目錄的DIA SDK文件夾下面找到頭文件、庫文件、COM組件DLL和示例程序。用它分析一個DLL或者EXE可執行文件對應的PDB文件，你可以取得每個編譯單元 （用.c/.cpp編譯得到的obj或者lib）里全部函數的情況，包括函數名字、是否成員函數、返回類型、全部參數的名字和類型、全部局部變量的名字和 類型，甚至它在哪個文件的哪一行定義。
在這些信息中可以過濾出用戶預先指定的信息，用來拼成另一個C/C++源文件，這個源文件叫做執行表，里面包含了所有需要執行函數的名字列表以及各項參數 的靜態定義�！爸笇est case執行”是可以預先分離實現的模塊，把它include進來即可。最后，把原先用來產生可執行文件的全部文件，把定義main或者DllMain的 那個源文件，改為執行表，再編譯鏈接一次，大功告成。
問題是怎樣產生第一個可執行文件呢？用戶使用單元測試工具的時候不都實現了一些函數嗎？那就能產生用戶的編譯單元。我們可以預先提供一個定義 DllMain的殼lib，它與用戶的編譯單元鏈接在一起就成為被DIA SDK分析的DLL。然后像前面說的，最后換成執行表的編譯單元。
你注意到了嗎，用這個方法，別說CppUnit，做CUnit都可以。
二、 用struct表達attributes
剛才并沒有提到如何像NUnit和JUnit一樣取得attribute所定義的信息。我們要求需要執行的函數定義成返回BOOL類型，只有一個參數，一個結構的指針。
如果用戶定義的這個結構像這樣
struct SIGNATURE_001
{
SIGNATURE_001()
{
const char* title = "Test case 1";
const DWORD priority = PRIORITY.P1;
const char* Setup = "MySetup";
const char* Cleanup = "MyCleanup";
…
}
};
用DIA SDK分析就會發現，這個函數的參數類型具有構造函數，其中有局部的常量名字如何，值多少。依靠這些信息，我們足可以判斷一個函數是不是需要執行，所需要的參數都是怎么樣。
為了簡化，我們可以用一個簡單的宏幫助定義這一切，放在函數前面就可以了。當然它不是必需的。
在C下面可不能這么用，但辦法還是有的。
三、 用注釋表達attributes
既然我們能把函數定位到某一行，那么往前掃描源文件行，遇到三個斜杠開頭的就濾掉“///”讀進來，如果我們預期這些注釋看起來是這個樣子
/// <TestCase>
/// <Title>Test case 1</Title>
/// <Priority>1</Priority>
/// <Setup>MySetup</Setup>
/// <Cleanup>MyCleanup</Cleanup>
/// </TestCase>
那么只要分析這段XML文本，接下來的事情就跟前面說的一樣了。
四、 自動運行整個過程
用戶需要的是寫好測試代碼，執行一個命令就能得到所有可執行代碼。我們可以利用makefile把這一切連接起來：先寫好需要分析的DLL的依賴關系，然 后讓執行表依賴上述DLL，命令為執行分析代碼產生執行表，最后讓目標DLL依賴執行表即可。又或者用Visual Studio的Build Steps來驅動也可以。
到這里，大家可以看到，為了實現最終目的，我們突破了習慣的限制（只使用語言特性），并且充分利用現有的技術和工具（DIA SDK和XML Parser）。只要能實現目的，“無所不用其極”。
你可能覺得折騰這么一套東西動作也挺大的。我得說，“看菜吃飯”。
另一個例子，有一個測試框架，萬事俱備，就是沒法把test case自動傳送到Apple Macintosh的機器上�，F有的代碼可以讓test case在Apple Macintosh上執行，也可以把test case從服務器下載到Windows');" target="_self" _base_target="_blank">Windows測試機器上發動執行，但是沒法跟Apple Macintosh交流。
怎么辦？在Apple上開發誰都不懂。在Apple Macintosh上寫一個客戶端跟服務器交流，夠忙半天的了。面對一整套已經完備的測試框架，讓它盡快用于新的環境，比做什么都重要。
別人告訴我，可以Apple Macintosh上開一個共享夾，然后Windows的機器可以用UNC路徑往里面讀寫文件。
OK，這就足夠了。Windows測試機器上發動執行的只是一個腳本，把需要用到的文件往指定Apple機器的共享文件夾上寫。寫完之后再寫一個文件，名 字是約定好的，例如“ready”，里面包含啟動test case的命令行。然后不停的隔一段時間檢查共享文件夾里面一個叫做例如“done”的文件，出現之后把它作為結果返回服務器，最后把它和其它文件都刪 掉，退出。
Apple Macintosh上面則運行另一個腳本，始終不退出。它不停的隔一段時間檢查其指定的共享文件夾里面一個叫做“ready”的文件，出現之后執行里面的 命令并且等待它結束。這個命令必須生成一個叫做“done”的文件，包含執行結果。然后，不停的隔一段時間檢查“done”是不是還在，不在了就回到最初 的檢查“ready”的代碼。
這就足夠了。兩個腳本加起來50行不到。
你覺得它太粗糙了吧？這么簡單的協議？
事實上，它并不需要十分健壯。
一、 Windows和Macintosh雙方的網絡文件系統協議解決了很多問題
二、 測試機器是不會有人去用的，你可以安全的假設只有你的程序在執行
三、 服務器和test case都已經測試過，他們應該負擔起若干健壯性的需求。事實上，他們比這兩個腳本更適合做這個，不是嗎？
這就是“看菜吃飯”：不需要的功能，是不需要去實現的，無論它看上去有多么的cool；必需的功能，無論如何都要做到，無論它看上去有多么的boring。
其實，無論開發測試，都是為了讓人們更好的發揮自身的潛力。開發工程師讓人們可以專注于自身的事業而不用過多學習計算機技術；測試工程師讓開發工程師可以發揮自身開發的潛力而不用過多參與質量保證的事務。代碼高下之分，只能通過讓人們發揮了多少潛力來檢驗。
《神雕俠侶》里提到獨孤求敗晚年“飛花摘葉皆可傷人”，皆因“不滯于物”，達到“無劍勝有劍”的境界。
所以，開發和測試工程師寫出來的代碼高下之分，對于這個問題，我會這樣回答：皆可傷人，何須理會是花葉還是刀劍；都能發揮人們的潛力，不必關心來自開發還是測試的手筆；優劣之分，或者只來自于用劍者本身。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
