1.14 Bug Bash
問:我們已經講得太多的測試了,好像微軟還有一個叫“bug bash”的活動,是啥意思?
答:簡而言之,就是大家一起來找小強的活動 – 小強大掃除。一般是安排出一段時間(一天),所有測試人員(有時也加入其他角色)放下手里的事情,專心找某種類型的小強。然后結束時,統計并獎勵找得最多的,和最厲害的小強的員工。這種活動,如果運用得好,有下面的作用:
鼓勵大家做探索試的測試,開闊思路。
鼓勵測試隊伍學習并應用新的測試方法,例如在做完“軟件安全性測試”培訓后,立馬做一個針對“安全性”的小強大掃除.
找到很多小強,讓開發人員忙一陣子
當然,小強大掃除也有一些副作用:
擾亂正常的測試工作
如果過分重視獎勵,會導致一些數量至上,濫竽充數的做法。
兩個細節是:
1.一定要讓“小強大掃除”有明確的目標,明了的技術支持。
2.一定要讓表現突出的人介紹經驗,讓別人學習。
要記住,最好的測試,是能夠防止小強的出現。
2總結和思考
2.1十八般兵器
阿毛:超總, 我的腦袋好像裝不下了!? 聽了這么多,我感覺像是身上扛著十八般兵器,累得半死,但是不知道什么時候,對哪一種敵人用哪一種兵器,能不能總結一下!
阿超:好,我們用軟件開發的生命周期來說明一下不同的測試在不同階段的使用:
遠景和計劃階段:
測試只是處于計劃階段,同時要收集用戶對于軟件非功能性的需求,如效能,可用性,國際化等。一些“小強大掃除”的類型也可以在這個時候初步安排。
開發階段:
開發人員要寫單元測試, 測試人員要寫BVT。
對于每一個成功的構建,測試人員要運行功能測試/場景測試,同時建立回歸測試基準以便開始回歸測試。各類測試人員要進行探索式測試。
隨著軟件功能的逐步完善,測試人員要進行集成測試。這時,團隊可以開展對程序非功能性特性的測試,如效能/壓力測試,國際化/本地化測試,安全性測試,可用性,適用性測試等。在這個時候,可以考慮分析各個模塊的代碼覆蓋率,以增加測試的有效性。根據計劃,各種類型的“小強大掃除”會以適當的頻率發生。
穩定階段:
到了一個開發階段的尾聲,這時測試團隊就可以依據以前制定的驗收標準,對軟件逐項進行驗收測試。按照測試計劃,各個方面的測試都會宣布“測試完成”- 所有想到的測試都做了,所有問題都發現了。在此階段,團隊也可以把軟件發布給外部進行alpha/beta測試。
一般情況下,測試隊伍要把迄今為止發現的所有小強都從新試一次,確保它們都在最后的版本中被清除了,沒有一個“回歸”出現。
發布階段:
測試隊伍要把盡可能多的測試用例自動化,并為下一個版本的測試工作做好準備。
2.2構建的質量
1.編譯失敗
2.可測/不可測
3.可用/不可用
2.3問題
2.3.1 如果連續幾天都不能產生“可測”版本,怎么辦?
提示:可以在下一個構建版本中限制簽入的數量,只接受那些高等級的修改,在一般的做法中,導致“不可測”的小強的嚴重性是1,必須在下一個構建開始的時候得到改正。