軟件測試BUG中的小概率事件

對于用戶而言，一個產品的好壞不僅僅決定于其產品的功能，而更加在于產品的可靠性及穩定性。小概率BUG則是影響產品可靠性及穩定性的主要因素。而小概率BUG的產生，一般是由于積累操作或多任務并發所引起。哪么在成本及時間等影響產品發布的條件允許的情況下，小概率BUG在產品上遺留的越少，那么產品的質量也就更好，用戶對產品的體驗值可能就越高。

　　但實際情況要解決小概率BUG并不樂觀。由于小概率BUG發生的概率較小，因此不論是對于開發人員還是測試人員而言，要解決或驗證小概率BUG都是一件讓人頭痛不已的事情。

　　哪么作為測試人員的我們如何把握住這僅有的一次或兩次機會，以提供更多的小概率BUG信息給開發人員呢？

　　小概率BUG的多發地帶：

　　1． 臨界測試

　　2． 中斷測試

　　3． 多任務測試

　　4． 積累測試

　　小概率BUG信息的提供：

　　1． 若被測終端提供LOG接口，在測試過程中一定要打開LOG跟蹤工具。在BUG發生時提示LOG或圖像。

　　2． 若發生小概率BUG，我們應該多做測試或者詢問其它同事是否發生類似問題，爭取找出其發生的規律。

　　3． 若發生的小概率BUG引發系統崩潰或主要功能無效，應及時通知開發人員。

　　4． 在提交小概率BUG時，一定要詳細記錄BUG發生的環境，測試步驟及時間點等因素。

　　小概率BUG的驗證：

　　1． 小概率BUG的驗證應當由發現此BUG的測試人員來進行。

　　2． 若小概率BUG相對輕微，在產品經理確認不必修改時，可以將其關閉或保留。

　　3． 若小概率BUG在驗證時再次發生，應及時通知開發人員。

　　4． 小概率BUG連續驗證3輪之后沒有發生（每輪驗證根據BUG的復雜度可分為20-50次），可將其關閉。

　　5． 對于特別嚴重，而開發人員又束手無策的小概率BUG，在條件允許的情況下，可讓開發人員發布T版本來進行測試。

　　6． 對于特別嚴重的，而開發人員又未確認修改的小概率BUG，可在風險中提出此小概率BUG風險。

原文轉自：http://www.kjueaiud.com