如果軟件測試部門或小組以提Bug的多少來作為績效考核，你會覺得合理嗎？你是否思考過這個問題？今天我就來談談這種方式是否合理的原因以及思考。類似于還有以寫用例數量的多少作為考核目標的，我們試想一下，用例寫的再多Bug發現不了不僅浪費了測試人力，同時也增加了測試風險。

雖然Bug的數量也是衡量軟件測試人員績效方式的一種，但是這種單純的以Bug數量作為測試人員的績效考核方式在我看來不太合理。該方式可能會產生許多無效的Bug，增加測試和開發的溝通時間。如果作為測試領導或測試負責人我們應該避免使用該方式作為考核標準，以下是我認為不合理的幾種原因：

1、測試模塊安排不合理

如果安排測試穩定的模塊不管是根據用例還是自由測試找到Bug的難度非常大，導致測試人員的Bug數量上不去，而測試新功能模塊則存在的問題比較多，測試該模塊的測試人員能找到Bug的難度就相對來說比較容易，Bug數量自然就上去了；

穩定的模塊就是經過幾輪測試之后修改合入較少的模塊，如第一輪測試出來的Bug數量肯定多于第二輪測試，第二輪測試階段的測試人員發現的Bug數量大概率比不上在第一輪測試過程中發現Bug的數量。類似于維護項目的回歸測試基本很少有Bug了，任憑你投入的人力和時間再多，也很難發現Bug。因此模塊的穩定性、模塊的復雜度決定了測試人員找Bug的難度。

2、Bug的嚴重程度

找出測試對象的一般等級的Bug相對容易，而找出測試對象中嚴重等級的Bug可就困難多了，不僅需要測試人員對被測試對象功能和業務熟悉，還需要測試人員有豐富的測試經驗。一個致命和嚴重的Bug的價值遠遠大于一般Bug的價值，如果僅憑Bug數量的多少而不考慮Bug的嚴重程度根本無法衡量測試人員的能力，因此單一的Bug數量作為考量有失偏頗。

3、軟件測試人員能力

上一個原因也有講到是經驗豐富的測試人員遠比新來的測試人員更容易找出系統的缺陷，畢竟功能業務的熟悉程度和測試經驗在那里，如果所有的人都是同一種考核方式會降低新人員的積極性、主動性，也無法調起新員工的工作熱情。

4、軟件測試產品的受眾程度

一個市場上非常流行的產品會得到高度重視，會經過充分的測試之后才能上線，而一個小眾的產品則不會有這么高的待遇，不僅測試場景少，同時測試人力和資源也分配比較少，對一般的Bug容忍度更高，能保證基本功能使用就可以。如果測試人員分布在不同的產品線中，那找出的Bug絕對不是一個等級的，因此如果以Bug數量作為考核肯定是不合理的。

最后的思考：

1、給Bug分配系數，如發現致命Bug是10分、嚴重Bug是3分、一般Bug是1分、輕微Bug的0.1分，然后根據Bug的數量乘以相應的系數獲取總分，這種更能體現發現Bug的價值和激發測試人員的積極性。

2、如果每次開發提測的版本太爛，我們不應該沾沾自喜提高了Bug的數量，而應該思考怎么管控版本發布，提高待測版本的質量。而不是拿到版本就直接開測，首先可以做一個冒煙測試，沒有嚴重問題后在開始安排測試，否則版本打回等待新版本，此時可以考慮建立測試準入流程。雖然這樣最后提交的Bug數量少了，但是優化了測試流程，提高了測試效率，是一個測試人員更應該關注的。

軟件測試人員的能力主要體現在找出系統存在的潛在Bug，上線后無漏測；也可以是測試流程的優化和測試標準的建立，提高測試測試質量和測試效率；還可以是總結歷史測試問題，避免在新項目中再次發生。這些都是測試人員能力的體現。