不論是單元測試還是接口測試，熟悉程序內部實現都是有用的——這種理解是有問題的，我們目前所做的測試除了集成測試就是小規模的集成測試。

現在測試組目前的所有測試都不是單元測試，因為單元測試最基本的單位是函數，接口測試是一種測試手段，不是一種測試分類。

編寫測試用例跟程序實現沒有必然聯系，比如按照測試驅動開發的理論的測試用例編寫是從函數接口都沒有的情況下開始寫的，此時接口都沒有，更別說實現了，這樣就寫不出測試用例來了么？
編寫測試用例關注什么，關注的是模塊的行為，也就是通過輸入看輸出，是否和設計文檔、接口頭文件中的描述一致。比如一個函數聲明為

// 為公司的數據庫添加一位新員工的信息，包括工號，姓名，性別
// 約定工號始終為正數，男同事為1打頭，女同事為0打頭
// 姓名不得為空
// 性別0代表女同事，1代表男同事
// 添加成功則返回true，失敗返回false
bool AddEmployee(int iNumber, String sName, int iSex)；

有了上述這些信息就可以開始設計測試用例了，比如iNumber = 047788, sName = "li hong",  iSex = 1, 我們期待的返回值就是false，因為性別和工號有沖突。如果測試返回true，則說明軟件有bug。

這是寫一條測試用例的整個過程，其中并沒有設計到函數的內部實現啊？

我們現在的開發離測試驅動開發還有很長的路要走。
我們能做的是什么呢？
是回歸測試，開發人員對模塊進行回歸測試，帶著反饋工作，尤其是在添加新功能，修正bug的時候，有了回歸測試，就像有了雜技演員的身上有了保險繩，可以放心地在高空中做各種動作。

現在該怎么做呢？
我的想法是，測試框架的搭建是由開發人員做好的，因為一些解耦和的工作是必須開發組來做的（隨著技術的進步，越來越多的解耦合方法被提出來，想詳細了解這方面的東西，推薦看《修改代碼的藝術》）。具體來說，比如我要做一個模塊，現在已經做到一半了，基本功能都做得差不多了，但是心里沒底，因為沒有QA。這是后就可以用DUnit來創建測試工程，寫一些測試用例。但是，現在版本壓力大，沒有這么多時間把測試用例寫全面，怎么辦？把測試框架給測試組，由測試組的同學來完善和豐富測試用例，因為測試組的同學比開發組的同學有更深厚的測試用例設計基礎，能寫出更好的測試用例，同時也有助于提高測試組同學開發水平，促進TEST向QA轉變。另外，這也避免了開發人員在編寫測試用例時的思維定勢，導致明顯的問題也測不出來。

這樣，隨著模塊的不斷完善，開發人員把測試框架進行補充，測試人員豐富測試用例。如此交替進行。

另外一個比較關鍵的問題是開發組測試組提供什么來進行測試。提供源文件的方式是行不通的，目前采用比較多的是提供DLL，同時為了避免測試規模增長，采用了DLL注冊等一系列機制。
我的想法是由開發組提供模塊代碼的.obj文件和測試用例的源文件，這樣測試人員可以隨時構建出自己需要運行的版本，感覺上就像手里有模塊的源代碼一樣，只是不能進去debug。

所以說，現在先做一個模塊，解耦合、大框架、測試組編寫測試用例，這一整套流程做通了，證明切實可行，方便有效。開發組自然就樂于接受了，測試組可以在模塊的級別上進行QA，而不是在發布版本之后才進行集成測試。

一點小想法，具體實現，還需要各位都加把勁啊，呵呵。