1. 程式人生 > >軟體測試員這些坑一定要記住了

軟體測試員這些坑一定要記住了

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

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

 

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

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

 

 

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

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

 

 

 

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

 

 

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