你注意到了嗎，用這個方法，別說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測試機器上發動執行，但是沒法跟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/
