當Bug跟蹤系統上所有的bug都被打上Closed後，你是否感到如釋重負。當項目成功交付後你是否感到大腦進入了“冬眠”期，上網，聊天，寫自己感興趣的小程式，但是對於上個項目你已不願去想它。既然項目間隙還有點時間，就幹點輕鬆的活吧，免的老闆給你找些更受罪的事來作。
“溫故而知新”，這句古訓可以幫你給老闆交差，對項目的進行過程作個分析，總結，最好再交個分析資料，老闆絕對不會覺得你拿了錢不幹活，而且自己也能有些收穫。
開發階段最好找的就是Bug記錄，Bug管理系統已經記錄下了所有的Bug的現象，分類，所處模組，發生原因。雖然幾乎所有的Bug管理系統都提供報表，分類匯總功能。但是真正對這些資訊作認真分析的項目恐怕不很多。
Bug出現的範圍
對Bug的修正過程分析後，你可能發現絕大部分Bug都和少數幾個關鍵的代碼檔案有關係，例如我有一個模組，共25個代碼檔案，還有三個外部檔案，80%的bug在修正中都對兩個代碼檔案有修改。也就是說，Bug的表現形式可能不同，但是追溯其發生原因，大部分都在很有限的代碼範圍內。但是，這些代碼都不是關鍵區段，而在一些不怎麼重要的地方。原因是關鍵代碼（比如資料庫操作）在程式員開發時就多次運行，驗證過了，或者都已統一作了封裝，包含在Fremework中，可靠性高，出現Bug的機率不大。非關鍵的部分常常是細節上的問題，比如焦點的移動，控制項的對齊，特殊資料類型（時間，貨幣）的表示格式，字型，顏色等，某些值的計算或精確度有誤。而在這些細節中，一個模組又會集中在其中的幾項上，還是以我上面提到的模組，70％的Bug又都是焦點移動和表示格式的問題。
Bug出現的原因
對於Bug出現的原因，比較多的有幾種：代碼實現與設計不符；單純的實現錯誤或遺漏；對某個點設計和實現同時遺漏，沒有人提出，直到測試時才發現；沒有遵守項目的規範，本不是Bug，但是測試人員和實現人員的理解不同。
以上Bug出現的原因中對於設計，代碼，測試不一致的問題，常常是由於三者之間對與模組要實現什麼和要測試什麼沒有一個統一的標準，所以我認為首先必須有一份文檔（不管你把它叫什麼），來作為參照，如果出現理解上的偏差或不一致，可以到這裡找答案，如果找不到，把缺失的部分補上。
對於實現階段出現的問題，除過上面說到的標準不一致外，主要是因為程式員自己單純的錯誤或粗心，遺漏了某個細節，或者雖然實現了，但是不完全正確。對於後者，可以是因為一個模組自己的特殊功能，代碼寫的有問題，也可以是因為一個在多個模組中都要用到的功能，但是沒有作統一的封裝，大家各寫各的，結果是實現方式上的差異和Bug出現機率的增高。對於第二種情況，應當首先考慮將這個功能封裝起來，統一調用，並且寫下文檔。
對於測試，在保持和設計，實現一致的前提下，可以對測試點分為通用部分（焦點，字型，控制項大小，日期，貨幣的顯示格式），非通用部分（除通用部分外該模組自身要實現的功能），正常情況，異常情況四類，進行測試。
以上的分析都是基於單元測試的結果，並且只針對一個模組，有很大的局限性，但是相信對於後面項目的開發是很有協助的，開發與測試會變得更有針對性，一方面可以減少Bug，一方面測試的效率也可以提高。
你可以應付老闆，但是不能應付自己，“認真”只會讓你更高效，更輕鬆。
希望大家分享更多的經驗。
