【tool】沒有需求文檔的時候如何來設計測試用例

沒有需求文檔的時候如何來設計測試用例

　　1.根據客戶的功能點整理測試需求追朔表：

　　一般的客戶都要把要開發軟件的功能點寫成一個表格交給市場部，讓市場部門轉交研發部。所以客戶的功能點是編寫測試用例一個最最重要的依據。

　　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等網絡聊天工具咨詢部分需求：

　　我們做的產品，大多數的客戶都在國外，測試經理也可以用這些網絡聊天工具和客戶確認部分需求疑問。不過要要事先越好時間，并注意異地的“時差”。