一般公司發展到一定程度，均要進行開發質量的考核。 考核的指標一般有：bug數，千行程式碼bug率，低階bug率，bug關閉時間，bug重開次數，bug重開率等。 大部分是關於bug的，在這種時候，當bug真的和開發績效掛鉤，同時暗示著也要和測試績效掛鉤的時候，我們到底該如何正確的看待bug，如何擺正自己對待bug的心態。   開始質量考核前，開發與測試不存在嚴格的厲害關係，我們都是為質量負責的人，開發通過程式碼設計與自測來提供基本服務質量，QA通過介面測試模組測試系統測試等測試手段來最終保證服務質量。大家是同一條船上的螞蚱，對一個或幾個服務質量負責。這是友好共生的美好畫面。 但是，開始質量考核後，開發與QA突然站到了對立面，開發認為QA你這樣提這麼多bug影響了我的績效，QA認為bug數本身我也有績效啊，不給你提我的績效怎麼辦。   解決這個異常畫風，要從三個方面考慮： 1.提供方便合理的回滾或廢棄機制，所有異常或錯誤資料均可以回滾或廢棄，並且不計入開發和QA績效中。 很多時候由於開發與QA角度不同理解力不同，經常會出現一些無效bug，包括因為環境問題/需求問題/技術實現問題等產生的無效bug，這種無效bug一定要支援開發關閉。並且當流轉到QA那裡時，QA可以對此bug二次確認，決定關閉或者重新開啟。   2.與績效掛鉤但不嚴格掛鉤 一個開發者能力的好壞，程式碼質量是其一部分。對開發能力的評估，決不能僅僅從質量維度出發，其他的如需求維度、服務穩定性維度統統都要考慮。所以要點是制定各個維度合理的權重，在核心指標上加大比例，在非核心指標上縮小比例。 同樣，直接用bug數來評判QA能力也是愚蠢的。QA不等於測試，但bug數只體現了測試部分。   3.開發者的心態 要知道大家都是在工作，所有的手段方法都是在為質量負責。QA提bug是，開發解bug也是。 我們遵循這個流程來做事情，是在工作，不存在個人恩怨和情仇。 同樣的，開發者想要提高自己的績效，不能通過圍堵QA提bug來做，這是一種風險很高的事情，影響了QA測試，其實是影響服務質量的，出故障還是要自己背鍋。 正確的做法是引導QA測試，介紹自己的設計編碼思路和方法，幫助其提高測試覆蓋率，最大限度降低風險。 同時QA不要把提出bug來當做一件很快樂高興值得驕傲的事情，本職工作並不值得炫耀。千萬不要拿著bug嘲諷開發。 另外開發與QA要進行良好的溝通與互動，對無效bug直接關閉不用往復多次開關。   最後，bug只是開發與QA協同工作為質量負責下的一個產物，不應過分看重與在乎。