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

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

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

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

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

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

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

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

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

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

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

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