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.kjueaiud.com/
