記得當初上測試課程時，老師就講到頭腦風暴，讓我們盡情發揮:想象，講的就是不局限思維、發散、開拓思維，可能發生的情況都可作為輸入條件，實際我們運用到工作中，測試用例的設計是一樣的道理，不能局限正思維、逆思維，要全方位思維去想象和思考，總結，從而得到最終結論，我不是測試大神，但有個對測試熾熱的心，在不斷工作中，經常思考想象并反問自己，不斷總結方法和經驗，擴大測試覆蓋范圍面，你們也是和我一樣嗎？下面我列舉幾個案例，可能是我們測試工作中經常忽略的測試用例點。

案例一：用戶淘寶網下單，進行訂單付款

用例1：新創建的訂單，是否可進行多次付款？

用例2：已付款的訂單，是否可再次付款？

用例3：已發貨、已收貨、已完成、已退款訂單、已評價訂單等，是否可進行付款？

用例4：不存在的訂單是否可付款？

案例二：APP中提現金額到銀行卡

用例1：未實名認證，是否可提現？

用例2：未綁定銀行卡，是否可提現？

用例3：綁定了錯誤的銀行卡，是否可提現？

用例4：未登錄，是否可提現？

從用例1 2 3 4可看出，應該很多人都不會去這樣設計測試用例,你們覺得需要這樣去設計測試用例嗎？

案例三、未來狀態/不存在的關聯傳參

用例1：如果status有1：招聘 ?2：非招聘?

考慮0和3測試，程序如何處理的？是否會=<1統一處理成招聘,>=2統一處理成非招聘，如果這樣處理了，下個版本如果加了status 3：急招，新版本后端先上線，app審核階段，0會顯示招聘，3會顯示非招聘，這樣是錯誤的，所以當時就應該非1和2，統一處理為不存在的狀態
案例四：系統有客服和主管權限，客服和主管權限各不相同

用例1：客服是否可操作主管權限？

用例2：主管是否可操作客服權限？

案例五：列表類頁面展示

用例1：假設列表字段為0、空、null值、超長、超大，測試異常、報錯、溢出，列表是否正常展示

案例六：從商品列表，進入商品詳情頁

用例1：商品列表數據還未拿到時，進入了商品詳情，商品詳情頁是否正常？

案例七：APP賬號登錄

用例1：登錄失敗，是否正常處理？

用例2:登錄超時，是否正常處理？

從以上案例的用例中可以看出，我們很多時候都不會去這樣設計，大多給出的理由都是，根本就沒有入口、根本不會發生、沒必要的，但我們有沒有認證思考想一下，我們如果不這樣去設計用例，后端代碼邏輯到底能覆蓋全嗎？我們有沒有注意到，線上經常發生的很多問題都是這些情況造成的？

?

如果覺得這篇文章對你有幫助，請幫忙轉發和關注，大牛勿噴！！！

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的【探索篇】测试人员一直疏忽掉的测试用例点，你中枪了吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。