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

　　常常做的事情可以從下面幾個(gè)方面來(lái)看：

　　1. 做質(zhì)量數據的統計和分析

　　收集的數據很多，常見(jiàn)的有：

　　- 外網(wǎng)的bug情況，包括事故，及影響的程度

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

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

　　- 版本發(fā)布的情況，代碼變更行數的情況

　　從這些數據的收集中就能發(fā)現很多問(wèn)題，比如問(wèn)題集中在哪里，哪些模塊，哪些人，哪些類(lèi)別等等，以及有沒(méi)有改善。

　　2. 問(wèn)題的追溯和對于開(kāi)發(fā)的考核

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

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

　　- 編譯失敗次數的考核

　　- 外網(wǎng)事故和bug的數量

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

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

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

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

　　對于bug方面其實(shí)也是一樣，如果開(kāi)發(fā)在乎(或者被迫在乎)外網(wǎng)bug或者被測試發(fā)現的bug數量，他寫(xiě)代碼的時(shí)候一定會(huì )更仔細，也會(huì )做些簡(jiǎn)單的自測，讓提測的質(zhì)量更高，提高了整個(gè)研發(fā)系統的效率，同時(shí)也是提升了質(zhì)量，因為quality must be built in。

　　我個(gè)人的經(jīng)驗，作為測試人員幾乎同時(shí)面對過(guò)兩個(gè)開(kāi)發(fā)團隊，一個(gè)有上述的考核，一個(gè)沒(méi)有。表現出來(lái)的版本質(zhì)量和對質(zhì)量的關(guān)注完全不一樣，而且前者也并沒(méi)有出現開(kāi)發(fā)和測試的對立，以及測試不敢提bug等負面的情況。

　　3. 對于測試的考核

　　除了對于開(kāi)發(fā)的考核，同樣也有對于測試的考核，這樣也更加的公平。

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

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

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

　　- 發(fā)布延期的情況

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

　　說(shuō)起考核，總有人覺(jué)得這不符合智力勞動(dòng)的情況，或者互聯(lián)網(wǎng)的作風(fēng)，其實(shí)不太理解為什么會(huì )這么覺(jué)得，放眼望去，有什么工作不被考核呢，sales要背quota，為什么軟件開(kāi)發(fā)和測試不能對自己的工作的質(zhì)量負責呢?當然，具體的指標如何去定才更合理那是另一個(gè)要去考慮的。

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

　　4. 推動(dòng)開(kāi)發(fā)的自測

　　這個(gè)問(wèn)題一向是個(gè)老大難問(wèn)題。愿意自測的開(kāi)發(fā)團隊你不用太多的推動(dòng)，不愿意做的推動(dòng)也很難，或者你無(wú)法判斷他有沒(méi)有做自測。而且這方面，通常取決于開(kāi)發(fā)負責人的觀(guān)念和態(tài)度。

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

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

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

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