單元測試
集成測試
系統測試
程序的常規步驟，但實際的軟件生產過程中，這幾步驟遠遠做不到，應視情況而定。
為什麼做不到？
這與很多因素有關，如：公司的規模、性質，軟件的規模、性質，軟件的開發類型（有些只是demo版本），還有一個原因是由以上派生出來的原因，團隊的管理制度（有沒有強制去做一些友好的步驟，比如單元測試，大家都知道好，為什麼都不去做呢？）；
單元測試：
一般研發部門的領導都是要求開發人員編寫單元測試代碼，因為領導憑著自己的經驗能夠意識到單元測試的重要性，基本上每個小的功能都要編寫單元測試。雖然是測試，也不一定非得在編寫完代碼之後編寫，因為單元測試有其特殊性，在開發某個功能之前，毫無疑問，工程師已經對模塊中每個小功能的實現做了詳細的思考和規劃，一個功能應該怎麼實現，心中了如指掌，在這個前提下完全可以預先編寫單元測試用例，而且編寫單元測試，同時也是全面分析某個功能可能出現的任意bug的過程（這是一次很重要的分析過程，從而會在很大程度上避免一些錯誤，而在現實中，這種問題出現的太多了，給人的感覺是程序員只是一味地實現功能，而不去考慮功能實現的完整性、健壯性），如此，編寫好的程序只要一運行，就能利馬知道這段代碼的好壞；另外一個好處是，單元測試能“監聽”以後開發中的代碼改動、模塊銜接所出現的大多錯誤，從而最大程度的避免了新的bug，是這就是磨刀不誤砍柴工吧；
集成測試：
以前總是以為書上說的大道理不如實際應用中的經驗來的實在，走過一段路後發現，其實不然；我的總結是，當你的成長遇到瓶頸時，理論就開始起作用了，我想說的是“軟件工程”裡說的內聚與耦合得概念。初學時不理解他的真正含義，如今用到時才感到他的重要性。對於模塊的開發者而言，就像要建造一架飛機，程序員的的工作就是生產一個飛機翅膀或者制作一個飛機輪子。假如說你制作的輪子的主要實現還是靠了機身本身的主干結構，而模塊本身並沒有太多的新東西，只是改改顏色，增加點花紋什麼的，可以看出，這個輪不能從飛機身上摘下來，或者摘下來很費勁，並且不能使用，失去了本身的意義；它的核心再機身，而不是輪子本身，又假如你制作的輪子，整個功能的主題都在輪子上，飛機使用時，只需要掛在上去即可，如果飛機不想使用，摘下來換別的即可；這就正好類似程序模塊見的內聚、耦合概念，讓每個模塊在不影響使用的前提下盡量的提高內聚性，降低模塊之間的耦合性，這樣的好處是，利於模塊的重用，方便問題的定位，有利於程序整體結構的工整；（個人認為類的思想也有這樣的好處，另外類的一個作用是重用，重用以減少代碼量）；在軟件測試時，集成測試是耗時最長，重復最多的、最重要的環節；大部分bug再這個階段被發現，我再測試過程中感受最多的就是，模塊之間的耦合性處理的不好，造成了改動一個模塊的功能，間接觸發其他模塊的功能發生錯誤（沒有完整的程序需求和詳細設計，是產生這類bug很重要的因素），而且修改時程序員總是很難意識到這類問題的發生，因此也造成了bug定位難的情況。
這個階段的回歸測試，是個比較累人的重復流程，每次程序的改動後，為了避免造成關聯模塊的bug，改動完後都要進行相關的回歸測試，回歸的深度基本上設計所有相關模塊，因此這種測試，使用自動化測試配合手動測試比較具有實際意義；
系統測試：
程序提交前的最後一輪測試，實際上這輪測試可以想想成工業上的“試車”，就是現場調試。涉及到了程序使用的各個方面，因為是在現場的環境中測試，因此這個階段測試出來的bug更具有實際意義；一般來說這個環節就是在實際環境中做更復雜的集成測試的步驟，避免出現bug的因素主要是需求的准確性；這個階段出現較多的bug一般為，網絡方面的，一般都會涉及到網絡後台、網絡的穩定性，而這點在集成測試時往往會忽略。
侃了會老生長談的東西，大約每個測試人員都不怎麼陌生這三個環節，也作了一些規避這些bug產生的研究，避免一些低級bug的產生。然而，現實讓人淚奔；
為什麼要這樣說？（網友）
1、是公司重效益，輕測試
2、程序規模小，不需要系統測試
3、程序員基本沒有養成做單元測試的習慣
4、團隊管理沒有強硬的原則
5、有些程序根本沒有需求規格說明書，何談，需求分析
一般的外包程序，都是簡單測試一下，連提交bug的必要都沒有，一邊測試一邊改正（到底這樣的程序是否需要做bug管理，我自己也不知道），沒有需求規格說明書，沒有需求分析；我在想對於開發周期比較小的程序如果做完整的開發測試流程，是否會在時間上得不償失，因為小程序bug還是相對部較少的。任何流程規則的制定，看來要以現實為依據才是最好的，沒必要可以的遵守固有的原則，好用萬歲！大型程序，還是需要做完整流程的；
以什麼為標准來決定是否需要做bug管理呢？
成本與質量之間的一個權衡
