在51Testing論壇的每周一問活動中看到這樣一道題目：測試用例應(yīng)該依照需求文檔來開發(fā)，但是我們的項目根本就沒有需求文檔？那測試用例該如何開發(fā)呢？
我也常常碰到這樣的問題，我的經(jīng)驗是跟系統(tǒng)開發(fā)人員多溝通以便了解到他們的開發(fā)流程、思路、注意細節(jié)等等，用筆記下來（俗話說“好記性不如爛筆頭”嘛），理順思路，然后再運用設(shè)計測試用例的等價類劃分、邊界值分析等方法對照系統(tǒng)各模塊進行設(shè)計！
沒有文檔對于單元測試來說也是一個難題，弄不好會使測試毫無意義。前段時間，我收到用戶反饋說，單元測試的效果不好，經(jīng)了解，情形是這樣的：沒有詳細設(shè)計文檔，由測試部門做單元測試，由于沒有文檔，測試員只好讀代碼來判斷程序功能，預(yù)期輸出是讀代碼后自已算出來的，結(jié)果效果不好。
例如：
int func(int a, int b){return a-b;};
本來是計算兩個數(shù)的和的，結(jié)果程序員將加號寫成了減號。
測試時，如果有文檔，哪怕是很簡單的寫一句：返回兩個數(shù)的和，那么，測試員就可以這樣設(shè)計用例：輸入兩個1,判斷返回值是不是2，馬上就能發(fā)現(xiàn)錯誤，但由于沒有文檔，測試員不知道代碼的設(shè)計功能，根據(jù)代碼，自己算出一個輸出：0，這種測試基本上就沒有意義了。
我們推薦的解決辦法有：
辦法一：由開發(fā)部門補充文檔，可以不要求太正規(guī)，只要讓測試員想得清楚：什么輸入應(yīng)該產(chǎn)生什么輸出就OK了。
辦法二：測試員只是設(shè)定用例的輸入，輸出全部設(shè)為FALSE，然后由開發(fā)部門設(shè)定輸出。
辦法三：由開發(fā)部門做基本功能測試，測試部門補充用例。由于已有基本用例，測試員根據(jù)現(xiàn)有用例就可以判斷程序功能。
辦法四：程序員編碼時，邊開發(fā)邊測試代碼的基本功能，測試部門只是補充用例。與辦法三的區(qū)別是：辦法三是事后測試，辦法四是測試驅(qū)動開發(fā)。
越是排在后面的辦法，推薦指數(shù)越高。如果這些全部做不到，那我的最后建議是：重新考慮測試是否值得。1、要求項目組提供測試特性；
2、如果項目組由于各種因素不能提供，則要測試人員自己寫測試特性。
3、組織評審，要求對模塊熟悉的人員（項目經(jīng)理、需求、開發(fā)）參加。
4、根據(jù)測試特性，寫測試點，再組織評審。
……
總之，開始一項工作之前，一定要問清楚是什么，完成標準是什么。測試工作的血淚史告訴我們：如果這時講義氣，后面就要遭殃了。
這應(yīng)該是一個非常普遍的問題，目前很多公司的現(xiàn)狀就是這樣！
沒有需求文檔，最頭疼的問題就是不知道開發(fā)的產(chǎn)品應(yīng)該是個什么樣，要完成哪些功能，達到什么指標。
下面幾個步驟應(yīng)該可以幫助你明確目標：
1、首先可以查找其他相關(guān)文檔。比如產(chǎn)品策劃書、Feature List，不可能什么文檔都沒有吧。我們可以收集一切相關(guān)的文檔來幫助理解所要測試的產(chǎn)品需要完成的目標。
2、盡量多參加該項目組內(nèi)的會議。比如需求討論、設(shè)計討論、計劃討論等會議，盡管沒有白紙黑字的文檔，但討論過程中也能讓你加深對產(chǎn)品的理解。
3、咨詢相關(guān)人員。經(jīng)過以上兩個過程，應(yīng)該對產(chǎn)品有了一個初步的理解，花點時間自己把大致的功能點整理一下，遇到不明確的、有疑問的，可以咨詢項目負責人或者相關(guān)市場人員，他們應(yīng)該對整個產(chǎn)品心中有數(shù)，否則這個產(chǎn)品真的就沒法做下去了。這里有一個前提是，在對產(chǎn)品有了初步了解后，才有針對性的去咨詢，否則在什么都不知道的情況下，第一，對方?jīng)]有耐心和時間向你介紹整個產(chǎn)品；第二，對于對方的講解，估計最多也只能了解個大概，不能很好理解。
4、使用舊版本。如果當前開發(fā)的產(chǎn)品是以前做
過產(chǎn)品的升級版，或者和以前某個項目類似，這樣就最好了，有個實實在在的“demo”給你用，當然理解也更深入了。
5、召集相關(guān)人員，對你整理的結(jié)果進行討論。整理以上幾步得出的結(jié)論，總結(jié)成文檔，發(fā)給相關(guān)人員，包括項目負責人、市場部代表、開發(fā)人員等，讓他們幫助評審check，根據(jù)意見對文檔不斷進行補充完善。當最后通過評審后，這個文檔就可以當作依據(jù)來設(shè)計你的測試用例了。