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