一般的客戶都要把要開發軟件的功能點寫成一個表格交給市場部，讓市場部門轉交研發部。所以客戶的功能點是編寫測試用例一個最最重要的依據。
2.根據開發人員的Software Specification List整理我們的功能測試點：
一般來說，開發人員實現一個功能都要把該功能分成幾個子模塊來實現，所以Software Specification List也是我們參考的另一個比較重要的依據。
3.開展項目跨部門討論會：
可以抽出時間，叫市場部的項目負責人、產品經理、項目經理、軟件開發經理和軟件開發人員，分別講講他們對整個產品的認識和設計模式，對每個功能點的理解和認識，理順思路，達成共識，測試人員負責記錄，測試Leader負責整理彙總，形成測試的部分參考文檔。
4.測試人員整理用例需求疑問遞交項目組和客戶代表回複：
測試人員根據項目討論會後的理解，測試過程中可能碰到的問題（如：邊界值、輸入數據類型等等）和需求不明確的問題，整理用例需求疑問，讓相關的模塊負責人在“用例需求疑問”表格中回複，並給出詳細解釋和說明。
5.項目內部用例評審：
測試人員根據對項目的理解，編寫測試用例要點，測試組內部評審修改後，可以召集項目組的成員，幫助Review一下，然後進行修改。經過多次修改和評審以後，測試用例要點可能會更加全麵一些。
6.郵件和客戶代表確認部分爭議問題：
測試人員與開發人員、項目組成員，在需求問題上討論有時候觀點不一致，各說各有理，這種情況下最好把爭議問題寫成郵件，發給客戶讓客戶來拍板，確定那種需求合理，到底如何做？抄送項目組的全體成員，方便大家都了解客戶的意見。最後編寫測試用例的時候，以客戶的郵件內容為準。
7.項目Demo和部分已開發係統：
大部分的係統，由於沒有需求，為了避免項目風險，開發方一般都要做成Demo，不斷讓客戶確認後簽字，不斷展現新開發的功能，以達到吸引客戶的目的。如果項目中有Demo，Demo也是參考標準。如果什麼都沒有，那已經開發的部分功能模塊，要去隨時讓用戶了解了解，並提出部分修改意見，也可以為我們熟悉係統提供部分依據。
8.參考同行業和競爭對手的類似產品：
假如說是做一個網上書店類似的網站，我們編寫測試用例的時候，可以看看“當當網”，“China—pub”等等類似成熟相關的網站。很容易發現本公司產品的問題，無意識給產品添加了競爭力。對於競爭對手的了解一定不能夠少。
9.交叉模塊的測試，最容易被人忽略：
一般的產品，功能部分的交叉，即是說在A模塊中設置了參數，在B模塊和C模塊中體現該參數的實際運用。比較難的如我們現在測試的“銀行係統”中的交叉模塊，還可能牽涉到不同的用戶，3個以上的模塊之間的調用。即是有了需求也很少寫，同時也是需求編寫的一個薄弱環節。這樣的測試用例編寫問題，一般初級測試工程師很難考慮全。對於有這種交叉功能的模塊，必須要求項目組中的精兵強將，畫出相關的調用關係圖，表明調用關係，方便後麵編寫測試用例。
10.可以使用電話、MSN、Skype等網絡聊天工具谘詢部分需求：
我們做的產品，大多數的客戶都在國外，測試經理也可以用這些網絡聊天工具和客戶確認部分需求疑問。不過要要事先越好時間，並注意異地的“時差”。
從做測試過程中發現，一般沒有需求說明文檔有3種情況
1、開發人員的意識不足，開發流程不規範，可能是以前做項目一直都是拿到市場可行性分析，然後項目管理人員進行簡單模塊劃分，任務就分配下去了，更不就不寫需求文檔，或者隻是簡單書寫大體功能點。
2、項目進度緊張，後期需求變動可能比較大，來不及書寫詳細的需求文檔
3、項目是從原有項目上進行迭代開發，開發人員認為不要再進行需求文檔編寫。
針對上述2點提出個人意見：
對於第一種情況：
1、測試負責人應該堅持開發沒出需求文檔，就不進行測試，要堅持讓開發輸出項目需求文檔，哪怕是寫的不夠詳細也好。
2、需求文檔要進行評審，評審做會議記錄，並有專門人員對需求文檔進行修改
3、最後就是測試人員進行測試需求分析，再根據測試需求點進行測試用例編寫了。
對於第二種和第三種情況：
1、測試人員盡量找到已存在的資料，比如市場調研書，可行性分析報告，收集一切對項目有用的文檔。並提出其中的功能點需求
2、如果是迭代項目開發，則找到前期項目的一些需求文檔，概要設計，詳細設計，測試需求，用例等。提起裏麵的功能點
3、谘詢相關人員，獲取項目一些大體功能，最好能知道大體項目的框架，然後記錄谘詢到的功能點。
4、了解項目大體框架後，可以在網上尋找同類產品，把裏麵的一些亮點功能點進行提起
5、整合上麵的幾點，測試人員應該書寫一份你認為的測試需求點，然後分發給每個和項目有關人員，如測試人員，開發人員，市場人員。組織進行一個會議評審，在評審中詳細記錄修改的地方
6、最後整理出一份評審過的測試需求點，進行設計測試用例。
沒有需求文檔對於編寫測試用例來說，確實很困難，做為測試人員，在沒有測試需求文檔情況下，我們不能等著開發人員輸出，應該主動點，盡可能去多了解項目的一些情況，多知道一點，對測試用例就能多寫點。
書寫測試用例時通常要考慮的檢查點
對於屏幕顯示來說包括：檢查顯示的布局；
檢查域和按鈕的順序；
檢查域的尺寸；
檢查字體的大小和風格；
檢查文本的含義；
檢查拚寫錯誤；
檢查屏蔽域；
檢查隻讀域；
檢查圖片；
檢查按鈕的狀態；
檢查按鈕的尺寸；
檢查按鈕的圖標和名字；
檢查是否有重複的圖標；
檢查指針是否在第一個可輸入域；
檢查TAB鍵的次序；
對於域來說包括：檢查可編輯性；
檢查域間的移動；
檢查分界條件；
檢查有效分界符；
檢查無效分界符；
檢查連續多個有效分界符；
檢查僅一個分界符輸入；
檢查多餘空格的截取；
檢查隻讀域和屏蔽域在TAB時的狀態；
對於數字域來說包括：檢查正數值；
檢查負數值；
檢查零值；
檢查小數點；
檢查特殊字符加數字；
檢查字母加數字；
檢查ASCII值；
檢查重複值；
檢查空值；
對於字符域來說包括：檢查僅有字母；
檢查僅有數字；
檢查字母數字；
檢查允許的特殊字符；
檢查禁止的特殊字符；
檢查包含特殊字符的字母數字；
檢查ASCII值；
對於字母域來說包括：檢查字母；
檢查數字值；
檢查字母數字值；
檢查特殊字符；
檢查ASCII值；
對於時間域來說包括：檢查字符?和/；
檢查其他特殊字符；
檢查字母數字值；
檢查正確的格式；
檢查錯誤的格式；
檢查錯誤的日期數字；
檢查正確的日期數字；
檢查日曆表；
對於錯誤信息和警告信息來說：檢查錯誤信息和警告信息的含義；
檢查錯誤信息和警告信息的一致性；
檢查確定位置的錯誤信息；
檢查錯誤信息後的光標位置；
檢查所有異常對應的錯誤信息；
檢查錯誤信息的格式；
對於普通的檢查來說：檢查文本域和字符域輸入是否左對齊；
檢查數字域輸入是否右對齊；
檢查標簽的切換；
檢查重複的名字；
檢查可刪除的表格；
檢查表格的多選；
檢查過濾器的邏輯性；
檢查多個過濾器的邏輯性；
檢查重複的序列號；
檢查顯示切換；
檢查快捷鍵；
檢查工具欄提示；
檢查日期域是否居中；
檢查選擇項的高顯；
檢查選擇符；
檢查顯示窗口的風格統一性；
對於按鍵的功能包括：New button：檢查包含next和cancel按鍵的子窗口的顯示；
檢查子窗口顯示的內容；
Add button：檢查包含save和cancel按鍵的子窗口的顯示；
Edit button：檢查在未選擇項目情況下點擊後的警告信息；
檢查包update和canc
el按鍵的子窗口的顯示；
檢查選擇的項目是否顯示在製定的位置；
Copy button：檢查在未選擇項目情況下點擊後的警告信息；
檢查點擊後的確認信息；
檢查插入後的複製數據；
Delete button：檢查在未選擇項目情況下點擊後的警告信息；
檢查點擊後的確認信息；
檢查刪除後的數據；
Run button：檢測運行時的參數窗口；
檢查執行結果；
檢查未選擇項目情況下點擊後的警告信息；
Back button：檢查是否回到上一屏幕；
Next button：檢查是否顯示下一屏幕；
Finish button：檢查數據是否進入數據庫；
檢查完成屏幕的顯示；
Cancel button：檢查確認信息；
檢查是否有其他鍵執行同樣功能；
檢測是否能能夠正確處理；(未完待續，如欲知後事如何，請登陸www.，章節更多，支持作者，支持正版閱讀！)