軟件測試工作的三個階段(2)

　　常常做的事情可以從下面幾個方面來看：

　　1. 做質量數據的統計和分析

　　收集的數據很多，常見的有：

　　- 外網的bug情況，包括事故，及影響的程度

　　- 測試階段的bug數量，分布(按系統，團隊，開發個人)，嚴重程度，bug的類別等維度

　　- bug的橫向跨團隊和系統的對比，縱向的和歷史情況對比

　　- 版本發布的情況，代碼變更行數的情況

　　從這些數據的收集中就能發現很多問題，比如問題集中在哪里，哪些模塊，哪些人，哪些類別等等，以及有沒有改善。

　　2. 問題的追溯和對于開發的考核

　　這個方面也許有一些爭議，但是我還是覺得這個是一個很重要的方法。光靠觀念和自覺是不夠的，必需要有一定的反饋機制，就好比交規一定是配合著扣分和罰款等手段，否則記錄闖紅燈有什么意義呢?而且現實的來說，這些方法起到約束的作用，也是一種心理暗示，要做自己做的東西負責，也便于養成好的習慣。

　　通常的考核指標涉及這些方面：

　　- 編譯失敗次數的考核

　　- 外網事故和bug的數量

　　- 測試階段的bug，特別是基礎功能bug和嚴重bug

　　粗略的列了這么多，其實可以有很多，比如配置文件改錯的情況，漏提測文件的次數等等。

　　這里也許有很多的討論，但是讓我們看看一個實際的例子。下圖是某個系統的編譯失敗的情況，在11月份的時候提出要統計并公開(并無懲罰條款)編譯失敗的情況，包含到開發的團隊和個人等明顯，12月份開始出現了明顯的下降并穩定了。這個圖隱藏了一些細節，如果剔除其他因素只看開發代碼原因的編譯失敗則更明顯，特別是后面有懲罰機制之后，進一步下降。

　　編譯失敗大幅的下降一方面是節省了大家的時間，另一方面其實也是提高了版本質量，想想如果有很多的編譯失敗，而且是到提交測試的階段，這樣的代碼質量能好嗎?是可能做過自測嗎? 有了這樣的機制，至少會更仔細一些。

　　對于bug方面其實也是一樣，如果開發在乎(或者被迫在乎)外網bug或者被測試發現的bug數量，他寫代碼的時候一定會更仔細，也會做些簡單的自測，讓提測的質量更高，提高了整個研發系統的效率，同時也是提升了質量，因為quality must be built in。

　　我個人的經驗，作為測試人員幾乎同時面對過兩個開發團隊，一個有上述的考核，一個沒有。表現出來的版本質量和對質量的關注完全不一樣，而且前者也并沒有出現開發和測試的對立，以及測試不敢提bug等負面的情況。

　　3. 對于測試的考核

　　除了對于開發的考核，同樣也有對于測試的考核，這樣也更加的公平。

　　測試的考核通?？紤]下面的指標：

　　- 漏測：絕對數量或者漏測率

　　- 版本的工作量和測試效率

　　- 發布延期的情況

　　如果測試有這樣的壓力，也需要不斷努力去發現更多的bug。

　　說起考核，總有人覺得這不符合智力勞動的情況，或者互聯網的作風，其實不太理解為什么會這么覺得，放眼望去，有什么工作不被考核呢，sales要背quota，為什么軟件開發和測試不能對自己的工作的質量負責呢?當然，具體的指標如何去定才更合理那是另一個要去考慮的。

　　換個角度來看，適當的壓力(不應該導致焦慮和扭曲的做法)，其實是讓一個人表現最好的狀態。

　　4. 推動開發的自測

　　這個問題一向是個老大難問題。愿意自測的開發團隊你不用太多的推動，不愿意做的推動也很難，或者你無法判斷他有沒有做自測。而且這方面，通常取決于開發負責人的觀念和態度。

　　如果是介于之間的，我們可以做一些事情，比如：

　　- 統計測試階段的bug中，屬于開發可自測發現的比例。通過這個可以看有多少bug是不應該到測試階段的，以及橫行縱向的對比。當然這個標準要自己拿捏。

　　- 給出一個自測的checklist。開發在提交前要完成這個list并正式的給出報告。這個方式我們曾經在一個項目中用過，效果不錯，基本功能都通過這個保證了，前提是開發負責人認可。

原文轉自：http://blog.csdn.net/superqa/article/details/21485737