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