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

第第頁沒有需求文檔的時候如何來設(shè)計測試用例沒有需求文檔的時候如何來設(shè)計測試用例

發(fā)表于：2023-02-23來源：：點擊數(shù)：標簽：

沒有需求文檔的時候如何來設(shè)計測試用例軟件測試1.根據(jù)客戶的功能點整理測試需求追朔表：一般的客戶都要把要開發(fā)軟件的功能點寫成一個表格交給市場部，讓市場部門轉(zhuǎn)交研發(fā)部。所以客戶的功能點是編寫測試用例一個最最重要的依據(jù)。2.根據(jù)開發(fā)人員的

沒有需求文檔的時候如何來設(shè)計測試用例軟件測試

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

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

2.根據(jù)開發(fā)人員的SoftwareSpecificationList整理我們的功能測試點：

一般來說，開發(fā)人員實現(xiàn)一個功能都要把該功能分成幾個子模塊來實現(xiàn)，所以SoftwareSpecificationList也是我們參考的另一個比較重要的依據(jù)。

3.開展項目跨部門討論會：

可以抽出時間，叫市場部的項目負責人、產(chǎn)品經(jīng)理、項目經(jīng)理、軟件開發(fā)經(jīng)理和軟件開發(fā)人員，分別講講他們對整個產(chǎn)品的認識和設(shè)計模式，對每個功能點的理解和認識，理順思路，達成共識，測試人員負責記錄，測試Leader負責整理匯總，形成測試的部分參考文檔。

4.測試人員整理用例需求疑問遞交項目組和客戶代表回復(fù)：

測試人員根據(jù)項目討論會后的理解，測試過程中可能碰到的問題(如：邊界值、輸入數(shù)據(jù)類型等等)和需求不明確的問題，整理用例需求疑問，讓相關(guān)的模塊負責人在“用例需求疑問”表格中回復(fù)，并給出詳細解釋和說明。

5.項目內(nèi)部用例評審：

測試人員根據(jù)對項目的理解，編寫測試用例要點，測試組內(nèi)部評審修改后，可以召集項目組的成員，幫助Review一下，然后進行修改。經(jīng)過多次修改和評審以后，測試用例要點可能會更加全面一些。

6.郵件和客戶代表確認部分爭議問題：

測試人員與開發(fā)人員、項目組成員，在需求問題上討論有時候觀點不一致，各說各有理，這種情況下最好把爭議問題寫成郵件，發(fā)給客戶讓客戶來拍板，確定那種需求合理，到底如何做?抄送項目組的全體成員，方便大家都了解客戶的意見。最后編寫測試用例的時候，以客戶的郵件內(nèi)容為準。

7.項目Demo和部分已開發(fā)系統(tǒng)：

大部分的系統(tǒng)，由于沒有需求，為了避免項目風(fēng)險，開發(fā)方一般都要做成Demo，不斷讓客戶確認后簽字，不斷展現(xiàn)新開發(fā)的功能，以達到吸引客戶的目的。如果項目中有Demo，Demo也是參考標準。如果什么都沒有，那已經(jīng)開發(fā)的部分功能模塊，要去隨時讓用戶了解了解，并提出部分修改意見，也可以為我們熟悉系統(tǒng)提供部分依據(jù)。

8.參考同行業(yè)和競爭對手的類似產(chǎn)品：

假如說是做一個網(wǎng)上書店類似的網(wǎng)站，我們編寫測試用例的時候，可以看看“當當網(wǎng)”，“China—pub”等等類似成熟相關(guān)的網(wǎng)站。很容易發(fā)現(xiàn)本公司產(chǎn)品的問題，無意識給產(chǎn)品添加了競爭力。對于競爭對手的了解一定不能夠少。

9.交叉模塊的測試，最容易被人忽略：

一般的產(chǎn)品，功能部分的交叉，即是說在A模塊中設(shè)置了參數(shù)，在B模塊和C模塊中體現(xiàn)該參數(shù)的實際運用。比較難的如我們現(xiàn)在測試的“銀行系統(tǒng)”中的交叉模塊，還可能牽涉到不同的用戶，3個以上的模塊之間的調(diào)用。即是有了需求也很少寫，同時也是需求編寫的一個薄弱環(huán)節(jié)。這樣的測試用例編寫問題，一般初級測試工程師很難考慮全。對于有這種交叉功能的模塊，必須要求項目組中的精兵強將，畫出相關(guān)的調(diào)用關(guān)系圖，表明調(diào)用關(guān)系，方便后面編寫測試用例。

10.可以使用電話、MSN、Skype等網(wǎng)絡(luò)聊天工具咨詢部分需求：