問題提出背景：

開發(fā)人員在開發(fā)程序過程中，總是會有一些相同的Bug并非是因為自己發(fā)現(xiàn)不了，而是因為不夠重視。而測試人員或者項目經(jīng)理總是在一些低級問題上與開發(fā)人員斗法，無法集中優(yōu)勢兵力發(fā)現(xiàn)更多的業(yè)務(wù)邏輯上的Bug。因此我想著是否升級。

問題的危害：

1、  重復(fù)的低質(zhì)量Bug不利于開發(fā)人員成長，當(dāng)然也很容易危害測試人員(項目經(jīng)理)心理健康。

2、  重復(fù)的低質(zhì)量會增加測試人員的工作量，也是增加開發(fā)工作量 J

3、  重復(fù)的低質(zhì)量的Bug會增加回歸測試的時間。

4、  不利于整個團隊的成長，不利于項目質(zhì)量的長久提高。

問題的解決：

任何以流程存在的過程都是可以優(yōu)化的。

看看我們開發(fā)-測試的一般流程。

從上圖可以看出，工作量是由回歸的次數(shù)和每次回歸Bug單中Bug的數(shù)量來決定的，而這兩個都是可以在開發(fā)過程中改變的，也是我們要改進的方向。

對于回歸次數(shù)的控制很多公司依靠測試工具和改進測試方法來提高效率（測試可以改進的地方）；而Bug數(shù)量的控制更多的是依靠“Bug績效考核”（開發(fā)可以改進的地方）。因為主題的原因，我們只討論第二種情況。

推行“Bug考核機制”？？？目前來看是不太現(xiàn)實的，因為測試人員稀缺、地域原因等等。當(dāng)然我們不能此作罷，不走尋常路的我們需要另外一種方式：??推行開發(fā)人員自測規(guī)范。大致的意思是：有開發(fā)人員、測試人員共同總結(jié)一些特別、特別共性基礎(chǔ)的Bug（表現(xiàn)形式為一些公用的測試用例），開發(fā)人員開發(fā)完畢之后，要保證自己的程序至少能通過這些用例的測試。如果沒有達到，可以采用測試人員或者項目經(jīng)理問責(zé)制度……

如何實施（建議性）：

1、  各個項目組總結(jié)基礎(chǔ)的共性問題，測試部總結(jié)共性問題，得到一個基礎(chǔ)Bug庫。

2、  經(jīng)過各個項目組、測試部篩選，達成共識，得到一個試行版的規(guī)范。

3、  每隔一個月（或者更長時間）更新依次規(guī)范。

4、  項目組內(nèi)部對不合規(guī)范的程序進行公示。