---恢復內容開始---

軟體測試幹了幾年，專案一個接著一個，一路從一個坑跳入另一個坑，有些是開發問題，一些是測試本人問題，大家在測試過程中踩過哪些坑尼？

1.自以為了解業務邏輯，實際浮於表面
這是個深坑，產品迭代跟的久了，功能上閉著眼睛都能說清楚就自以為很瞭解，實際上連該功能使用的協議，呼叫的介面都不知道，所以看到問題都是表面的問題。
你只看到了兩個操作的入口不一樣，提示資訊不一樣，你就以為是兩個問題，而這兩個問題都是調同一個介面引起的，但你分析不出來。。
這樣導致的問題有：
①修改bug後對影響範圍評估不夠
②提相同的bug，碰上特別注重bug數量的開發，真是揪心。。
我們公司對於bug定期要做bug根因分析，這在一定程度上也是幫助測試更深入的瞭解產品，因為每次bug單上開發寫的產生原因和解決方案，真是言簡意賅。。

2.思維定死，不會向前多走一步
比如同一個賬號新增之後刪除再新增，同一份文件匯入之後匯出再匯入，密碼修改成功之後再修改，等等，向前多走一步，就可能有意外收穫。

3.忽略偶現的問題
測試要記住：所有偶現的問題，都只是沒有找到必現的規律！
不要以為偶現的問題，沒有出現，就不提出來，等上線後用戶發現這個問題，你再說曾經遇到過，只是沒有提出來，那測試不背鍋還有誰背？？
提出問題但不解決，測試就可以甩鍋給產品，給開發，完美！（這個真是從踩過的坑裡得出血淋淋的教訓）
這裡有個好的習慣：遇到問題先截圖！！！先錄視訊！！！再分析原因，再提交給開發，最怕偶現的問題口說無憑，又沒有證據證明，開發說你逗我呢？？？

4.避免隨機測試
避免沒有用例而進行的隨機測試，雖然隨機測試能發現一些問題，但是它的特點是我們測試人員想到什麼就測試什麼，這樣就會導致有些功能點重複測試，而有的業務流程卻沒有覆蓋到，出現漏測，一旦上線後出現Bug，就不好說了。

5.Bug的復現步驟描述必須要詳細
這個其實算不上坑，只是個人總結。之前提交過一個Bug，Bug描述非常簡單，在後期給開發復現的時候，費了很大的勁兒，如果我們能在Bug描述中，準確描述Bug的復現步驟，就可以明顯縮短開發分析問題、定位問題的時間。

6.不要 “動” 之前的業務邏輯，因為會 “牽一髮而動全身”
要 “遵守” 之前的業務邏輯，現有的業務邏輯儘量不要和之前的衝突，為啥呢？
因為啊，一旦按照現在業務邏輯的話，就得把之前的改了，改之前的業務邏輯會非常的複雜，不僅開發需要改程式碼，而且我們測試要重新再測，所以，不要動之前的業務邏輯。