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

雖然Bug的數(shù)量也是衡量軟件測試人員績效方式的一種，但是這種單純的以Bug數(shù)量作為測試人員的績效考核方式在我看來不太合理。該方式可能會產(chǎn)生許多無效的Bug，增加測試和開發(fā)的溝通時間。如果作為測試領(lǐng)導(dǎo)或測試負(fù)責(zé)人我們應(yīng)該避免使用該方式作為考核標(biāo)準(zhǔn)，以下是我認(rèn)為不合理的幾種原因：

1、測試模塊安排不合理

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

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

2、Bug的嚴(yán)重程度

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

3、軟件測試人員能力

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

4、軟件測試產(chǎn)品的受眾程度

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

最后的思考：

1、給Bug分配系數(shù)，如發(fā)現(xiàn)致命Bug是10分、嚴(yán)重Bug是3分、一般Bug是1分、輕微Bug的0.1分，然后根據(jù)Bug的數(shù)量乘以相應(yīng)的系數(shù)獲取總分，這種更能體現(xiàn)發(fā)現(xiàn)Bug的價值和激發(fā)測試人員的積極性。

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

軟件測試人員的能力主要體現(xiàn)在找出系統(tǒng)存在的潛在Bug，上線后無漏測；也可以是測試流程的優(yōu)化和測試標(biāo)準(zhǔn)的建立，提高測試測試質(zhì)量和測試效率；還可以是總結(jié)歷史測試問題，避免在新項目中再次發(fā)生。這些都是測試人員能力的體現(xiàn)。