我們並不是做出了成績才能出來發聲,每天不間斷地記錄自己成長的過程,就能給別人帶來很大很大的力量了。
昨天終於開通了公眾號【不只是測試】,今天卻被我更名為【Tester阿常】。(取前面的名稱,是因為我想給大家分享的除了測試,還有其他有意思的東西;改取后面的名稱,是因為我覺得它更具備個人特色。不過雙子座的我飄忽不定,說不定哪天又想改回去,哈哈)
關於公號更新頻率,目前我給自己定的是日更。(篇幅盡量簡短,這樣容易實施)
關於公號分享內容,我的規划是:測試理論、java編程、職場經驗、育兒雜談、生活趣事。
下面開始我的第一篇文章,探討【軟件測試的目的】。
那么,軟件測試的目的是什么呢?
軟件測試的目的是盡可能發現並改正被測試軟件中的錯誤,提高軟件的可靠性。
這個定義聽起來很正確,但用它來指導測試,會帶來很多問題。比如有的組織用發現的bug數量來衡量測試人員的業績,其實這就是這種測試目的論在后面作祟。
其結果如何呢?
其一,有一些不夠敬業的測試人員,會找來一些無關痛癢的bug來充數,結果許多時間會被浪費在這些無關痛癢的bug上。
其二,測試人員會花很大力氣設計一些復雜的測試用例去發現一些迄今尚未發現的缺陷,而不關心這些缺陷是否在實際用戶的使用過程中是否會發生,從而浪費了大量的寶貴時間。
究其根源,就是因為對測試目的的種種錯誤理解造成的。
為什么這么說呢?
因為軟件里bug的數量是無法估計的。那么如果測試的目的是為了找bug,那么測試工作將變成一項無法完成,也無法衡量進度,而且部分無效的工作。因為有些bug在實際的運行過程當中,根本不會發生。
那么該怎么做呢?以下談談我的思考。
其一,基於需求說明文檔進行用例設計,保證需求覆蓋率100%。(正向流程、反向流程以及異常場景。忽略實際用戶使用過程中不會涉及的場景)
其二,提bug前先反思,該bug是否應該修復,需要何時修復,嚴重程度是什么,優先級是什么等等。(優先關注影響核心主流程、主功能的bug)