寫給測試小白:怎麼快速找到bug?怎麼寫測試用例?

博為峰網校發表於2019-03-25

軟體測試工作中找bug就是這個崗位本身立足的職責,那麼對於很多新人和新入行的同學們來說,這個過程會有點苦逼,畢竟經歷的專案經驗不多,想快速的切入尋找bug往往會比較痛苦。

寫給測試小白:怎麼快速找到bug?怎麼寫測試用例?

那下面我就以自身的經驗來普及下如何在工作快速找出系統的不足或缺陷。

1、熟悉你做的產品

不管你是Dev、Test或者PM,熟悉自己開發的產品越多越好,你不但應該熟悉自己開發的模組,也應改熟悉和自己模組相關的其他模組,他們之間是怎樣協作的。比如資料庫中的某個欄位,是如何被各個模組使用的,這利於你在設計階段就能夠找到Bug,把修復的成本降到最低。

同樣,你需要熟悉這個產品以前的版本,因為無法向後相容和升級的產品恐怕很難獲得使用者的認可。在測試過程中,如果你發現你的產品和以前不相容或者不一致,80%的情況,這是一個Bug。

2、儘早的去發現Bug

我們大家都知道,Bug修復的成本是和Bug被找到的時間成指數關係的。越早開始找Bug,你能找到的Bug也就越多,對專案的貢獻也就越大。

3、每天Review別人的Bug

如果你的團隊沒有每日的Bug Report,我建議你們建立一個,其實技術上應該沒有任何的難度,透過Bug追蹤系統的API或者資料庫,你完全可以得到你要的資料,這樣,整個團隊透過學習每天察看別人的Bug,你可以更加容易發現Bug,也不會發現那種Duplicated Bug。現在經常有人跑過來問我,某個Bug是不是一個已知的問題,因為我每天都看Bug Report。

4、在你的日常生活中多準備一些測試的模式

模式是一個很時髦的詞,因為它很有用。在日常的測試中,多準備一些測試模式,你會有非常大的驚喜,有時候一個使用一個模式,你可以找到10來個Bug也不是不可能的。比如,使用特殊字元作輸入資料;斷開網路看UI是否會Crash;在本地化版本中,各個字串提示是否被本地化;

5、多測試各個模組之間的合作

各個模組之間的測試往往是我們測試中的薄弱點,對於使用者來說模組間的合作卻至關重要。往往一個資料在模組A中是合法的,在B中卻是非法的,一定要找出這些資料,往往者都是Bug

6、編寫自動測試程式碼

你肯定不原意每天都去做同樣的事情,那樣太沒有意思了,簡直就是對你的智慧的侮辱。但是一旦我們不進行這些測試,突然有一天早上,我們發現我們的產品以前能夠很好工作的功能突然就不工作了,於是大家亂作一團,有人急著修復它,有人在找是誰Check in的。

7、檢視產品程式碼

透過檢視產品程式碼,你往往能找到一些Dead Code或者邏輯上的Bug,這些Bug常常是你無法透過手工測試找到的。

初次怎麼寫用例?

有很多朋友初次寫用例,不知道從何下手,雖然有的公司給出了相關說明文件,但是寫起來還是不能得心應手,編寫用例方法有很多種:功能導向用例(邊界值、等價類等等),使用者導向用例(場景法),使用者、功能相結合導向用例……

那麼對於初次編寫用例,應該怎樣高效率的編寫用例?應該注意點什麼?

一、功能導向用例是按照系統需要達到的每一個功能,進行編寫用例,這樣的用例著重點在功能實現上,而沒有考慮到每個功能之間的關聯,因而雖然用例已經達到功能覆蓋,卻不一定達到邏輯覆蓋,因而這種方法通常會和其他方法結合使用。功能導向用例是每個用例編寫者前期最常用的方法。

二、使用者導向用例是按照使用者的習慣,將使用者使用系統的每個目的作為一個目標,以每個目標實現為基點設計測試用例,但是設計這一類用例,初寫者,可能會產生很多困惑(下面寫一下我第一次寫的時候有哪些困惑,並針對這些困惑,後來採取了怎樣的解決方案)

1、編寫用例的第一步我該做什麼?

理解系統,首先站在測試的角度深入理解系統的每個功能與系統業務邏輯,畫出業務邏輯圖(即:系統能做什麼)。

其次站在使用者的角度,列出使用者使用系統的目的(即:使用者使用這個系統,想幹什麼?)

2、怎樣確定使用者目標?

不能確定使用者目標,可能由2方面原因造成:a>對系統不夠熟悉,b>不瞭解使用者背景。對於第一點原因,那是你自己的原因,只有回過去頭看文件了,對於第二點原因,可以從‘系統能做什麼’推算出‘使用者可以做什麼’然後再總結出‘使用者可能想做什麼’,當然這樣做的前提是你對系統已非常熟悉。

3.這個月我將做什麼?

剛進入測試行業是怎樣總結的(利用測試管理工具進行總結):

1)把測試管理工具中的缺陷全部分類匯出,總結一下哪些模組容易產生哪些缺陷,重點看一下自己沒發現或沒有考慮到的缺陷。

2)如果說測試新人工作的第一層次是從執行用例開始,那麼第二層次就是編寫測試用例了。把測試管理工具中的用例詳細看幾遍,學習別人的用例編寫方法和思想,空閒時間可以自己試著編寫,看自己編寫的與別人編寫的用例差距在哪,從而不斷完善。重要說明;著重用例編寫方法和思想的學習,而不要死搬硬套。

3)進入一些測試論壇,把自己的困惑和經驗和大家一起分享,在學習中,不斷進步。

總結:

正所謂功夫在詩外,測試理論知識就是那麼多,理論知識掌握之後就要不斷的參與到專案中來,一個一個專案的練習,鍛鍊自己的發現Bug的能力,就算隨機測試,一個好的測試和一個壞的測試,他們發現問題的能力也是完全不同的。以上完全是個人的一點體悟,未必上的了檯面,各位看官,看的時候也請多多指教。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31407649/viewspace-2639293/,如需轉載,請註明出處,否則將追究法律責任。

相關文章