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