1. 測試計劃
這里所說的測試計劃,是指測試階段的測試計劃,而不是整個項目過程的測
試計劃。
現狀:目前測試文檔關于測試的內容主要是測試的時間計劃。而這種時間劃分也是非常粗略的,而且沒有依據。為什么要花這么多時間?目前只是按照個人直觀、經驗等方法來判斷測試時間。因此,這類測試計劃的隨意性太大,粒度太粗,不便于管理。目前的測試是為了測試而測試,沒有規劃性。
個人意見:細化測試計劃,使測試時間可以量化。
1) 更改測試時間的劃分方式,使用工作日/人的計算方法。
目前在編寫測試計劃時,測試進度中的計劃開始/結束時間往往用如20050101-20051201的具體時間劃分方式,這樣引起的問題是當項目計劃進行變更的時候,測試計劃時間不得不隨時調整,這種變更可能是頻繁而瑣碎的,可以替代的辦法是取消這種方式,采用30工作日/2人或者2人月這種工作量記錄方式,這樣,只需在項目計劃中跟蹤具體開始時間即可,不必反復更改測試計劃。
2) 測試時間的計算
測試時間的計算比較困難,,但主要有以下幾個方面:
a) 編寫測試用例的時間
目前沒有測試用例的管理和收集,測試主要是依照個人的經驗來進行,不利
于管理和積累。我覺得測試用例可以文檔化實現,盡管剛開始會花一些時間,但社區的各個系統相似性很高,因此測試用例的復用性就非常高。個人建議:建立測試用例模板。
b) 系統執行測試用例的時間
c) 提交測試報告時間
即在BUG管理系統中提交BUG時間。
d) BUG確認測試時間。
e) BUG修復時間及系統更新時間
f) 其他時間
再根據系統的功能點來計算測試所用的時間,這樣就可以計算出一個功能點
所花的時間,進而得出一個模塊或者一個工作臺帳的測試時間,從而得出測試計劃所需的工作量。其中,e)不是測試人員所花的時間,但不算入測試人員的工作量。
2. 測試工具
目前的測試方法都是手工測試,手工測試的效率跟測試員的經驗有很大關
系,需要一定的技巧性。而有部分測試類型是可以用測試工具來實現的。比如:邊界測試、非法測試、功能測試、性能測試等。但自動化測試并不能代替手工測試,它是一個補充。一般來講,測試自動化在整個測試過程中只能占到30%左右。
但測試人員對測試工具不熟悉,目前只能先以手工測試為主,繼續探討自動化測試的可操作性。(手頭沒有自動化測試工具)
3. 測試方法和測試類型
目前的測試方法以黑盒測試為主。從實際情況來說,能做好黑盒測試已經
很不錯了,也是可以滿足實際項目需要的。
黑盒測試的優點有:
1)比較簡單,不需要了解程序內部的代碼及實現;
2)與軟件的內部實現無關;
3)從用戶角度出發,能很容易的知道用戶會用到哪些功能,會遇到哪些問題;
4)基于軟件開發文檔,所以也能知道軟件實現了文檔中的哪些功能;
5)在做軟件自動化測試時較為方便。
黑盒測試的缺點有:
1)不可能覆蓋所有的代碼,覆蓋率較低,大概只能達到總代碼量的30%;
2)自動化測試的復用性較低。
談到測試類型,我覺得這是我們忽略的一個環節。比如發現一個BUG,開發人員修改后,測試員可能只是考慮這個BUG是否依然存在,而忽略了其他問題,這就可能引起其他的BUG。(可能在修改這個BUG的同時,引起其他功能模塊的連鎖反應而產生其他的BUG。)那么,冒煙測試便可以解決這類問題(盡管它的覆蓋率還是比較低)。
其它的測試類型還有Functional Test(功能測試)、Security Test(安全性測試)、Stress Test(壓力測試)、Performance Test(性能測試)、Regression Test(回歸測試)、Setup/Upgrade Test(安裝升級測試)等。
我認為,可以通過一些培訓或文檔來培養測試人員的這些測試技巧。
4. 測試用例
這里談的主要是黑盒測試用例。具體參考黑盒測試的測試用例設計方法。
5. 測試工作的考核
工作考核的內容,在整個公司來講也是剛剛起步階段,而測試工作的考核也
是比較可能的。下面我列舉幾個考核標準,只供參考。
按照測試周期測試階段分為:測試計劃、測試設計、測試執行。
測試計劃是測試經理負責的。測試人員主要是測試設計和測試執行。
考核標準:
1.BUG數量 目前使用BUG管理系統進行管理,因此可以通過該系統考核測試人員發現的缺陷數。
2.BUG跟蹤情況 即該測試人員發現的BUG,是否及時跟蹤該BUG的處理情況。
3.測試用例數 即測試人員設計的測試用例,相關標準是功能點,即一個功能點設計的測試用例數。
4.測試進度 即計劃時間和實際使用時間的差距。
5.嚴重缺陷率 在BUG管理系統中,對BUG按照緊急程度進行了分類,這里的嚴重缺陷率就是指測試人員發現BUG的緊急程度。
原文轉自:http://www.anti-gravitydesign.com