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

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

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

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

有了上述這些信息就可以開始設(shè)計(jì)測試用例了，比如iNumber = 047788, sName = "li hong",  iSex = 1, 我們期待的返回值就是false，因?yàn)樾詣e和工號(hào)有沖突。如果測試返回true，則說明軟件有bug。

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

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

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

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

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

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

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