1.1軟件測(cè)試的背景與概念1、測(cè)試的背景今天我們使用的一切幾乎都包含軟件（包括嵌入式的軟件）對(duì)于關(guān)鍵場(chǎng)合的各種軟件應(yīng)用，出現(xiàn)失效是根本不能接受的除了上帝，我們都要測(cè)試！軟件是人編的—所以不完美實(shí)例：2005年9月13日，魔獸世界“腐血”問(wèn)題2003年8月14日，北美停電問(wèn)題約克郡號(hào)美國(guó)艦船事件,1997年9月21日Unix系統(tǒng)的2038年問(wèn)題2013年光大證券“8·16”烏龍事件2000年的巴拿馬城致命的輻射治療2011年溫州7.23動(dòng)車事故1）軟件未實(shí)現(xiàn)產(chǎn)品說(shuō)明書(shū)要求的功能2）軟件出現(xiàn)了產(chǎn)品說(shuō)明書(shū)指明不應(yīng)該出現(xiàn)的錯(cuò)誤3）軟件實(shí)現(xiàn)了產(chǎn)品說(shuō)明書(shū)未提到的功能4）軟件未實(shí)現(xiàn)產(chǎn)品說(shuō)明書(shū)雖未明確提到但應(yīng)該實(shí)現(xiàn)的目標(biāo)5）軟件難以理解、不易使用、運(yùn)行緩慢或者---從測(cè)試員的角度--最終用戶會(huì)認(rèn)為不好軟件測(cè)試的起源20世紀(jì)60年代以前，計(jì)算機(jī)剛剛投入實(shí)際使用，軟件設(shè)計(jì)往往只是為了一個(gè)特定的應(yīng)用而在指定的計(jì)算機(jī)上設(shè)計(jì)和編制，采用密切依賴于計(jì)算機(jī)的機(jī)器代碼或匯編語(yǔ)言，軟件的規(guī)模比較小，文檔資料通常也不存在，很少使用系統(tǒng)化的開(kāi)發(fā)方法，設(shè)計(jì)軟件往往等同于編制程序，基本上是個(gè)人設(shè)計(jì)、個(gè)人使用、個(gè)人操作、自給自足的私人化的軟件生產(chǎn)方式。60年代中期，大容量、高速度計(jì)算機(jī)的出現(xiàn)，使計(jì)算機(jī)的應(yīng)用范圍迅速擴(kuò)大，軟件開(kāi)發(fā)急劇增長(zhǎng)。高級(jí)語(yǔ)言開(kāi)始出現(xiàn)；操作系統(tǒng)的發(fā)展引起了計(jì)算機(jī)應(yīng)用方式的變化；大量數(shù)據(jù)處理導(dǎo)致第一代數(shù)據(jù)庫(kù)管理系統(tǒng)的誕生。軟件系統(tǒng)的規(guī)模越來(lái)越大，復(fù)雜程度越來(lái)越高，軟件可靠性問(wèn)題也越來(lái)越突出。原來(lái)的個(gè)人設(shè)計(jì)、個(gè)人使用的方式不再能滿足要求，迫切需要改變軟件生產(chǎn)方式，提高軟件生產(chǎn)率，軟件危機(jī)（softwarecrisis）開(kāi)始爆發(fā)。軟件危機(jī)1、軟件危機(jī)的現(xiàn)象：開(kāi)發(fā)費(fèi)用與進(jìn)度失控，引起質(zhì)量問(wèn)題可靠性差，難以維護(hù)文檔資料的缺失與不合格問(wèn)題2、產(chǎn)生軟件危機(jī)的原因：軟件本身的特點(diǎn)決定（用戶需求、軟件規(guī)模，復(fù)雜度等原因）開(kāi)發(fā)人員的弱點(diǎn)1968年在德國(guó)召開(kāi)的NATO（NorthAtlanticTreatyOrganization,北大西洋公約組織）會(huì)議上首次提出了“軟件工程”概念，希望用工程化的原則和方法來(lái)克服軟件危機(jī)。一個(gè)成熟的產(chǎn)品開(kāi)發(fā)過(guò)程至少應(yīng)該包括設(shè)計(jì)、開(kāi)發(fā)和測(cè)試3個(gè)部分，一個(gè)成熟的產(chǎn)品部門(mén)是非常重視測(cè)試環(huán)節(jié)的。測(cè)試環(huán)節(jié)做的好與壞，直接影響到產(chǎn)品的質(zhì)量和市場(chǎng)對(duì)產(chǎn)品的評(píng)價(jià)。做好測(cè)試不是一件容易的事情，有時(shí)甚至比開(kāi)發(fā)更有挑戰(zhàn)性。如何做好測(cè)試，是擺在整個(gè)測(cè)試團(tuán)隊(duì)面前的一個(gè)難題。早期測(cè)試的含義比較狹窄，往往等同于“調(diào)試”，在產(chǎn)品完成時(shí)才開(kāi)始測(cè)試70年代開(kāi)始出現(xiàn)的“第一類方法”，“試圖驗(yàn)證軟件是工作的”。70年代末GlenfordJ.Myers的第二類方法。。“測(cè)試的目的是證偽”（測(cè)試是為發(fā)現(xiàn)錯(cuò)誤而執(zhí)行的一個(gè)程序或者系統(tǒng)的過(guò)程）第二類測(cè)試方法與需求和設(shè)計(jì)沒(méi)有必然的關(guān)聯(lián)，更強(qiáng)調(diào)測(cè)試人員發(fā)揮主觀能動(dòng)性，用逆向思維方式，不斷思考開(kāi)發(fā)人員理解的誤區(qū)、不良的習(xí)慣、程序代碼的邊界、無(wú)效數(shù)據(jù)的輸入以及系統(tǒng)各種的弱點(diǎn)，試圖破壞系統(tǒng)、摧毀系統(tǒng)，目標(biāo)就是發(fā)現(xiàn)系統(tǒng)中各種各樣的問(wèn)題。這種方法往往能夠發(fā)現(xiàn)系統(tǒng)中存在的更多缺陷。

如果說(shuō)開(kāi)發(fā)者在創(chuàng)造世界，那么，測(cè)試者的任務(wù)就是要?dú)邕@個(gè)世界，當(dāng)然，毀滅是為了重生！-——目的在于提高軟件產(chǎn)品的質(zhì)量！80年帶開(kāi)始引入“軟件質(zhì)量”的概念，SQA。BillHetzel在《軟件測(cè)試完全指南》（CompleteGuideofSoftwareTesting）一書(shū)中指出：“測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)。測(cè)試是對(duì)軟件質(zhì)量的度量。”這個(gè)定義至今仍被引用。軟件開(kāi)發(fā)人員和測(cè)試人員開(kāi)始坐在一起探討軟件工程和測(cè)試問(wèn)題。軟件測(cè)試已有了行業(yè)標(biāo)準(zhǔn)（IEEE/ANSI）2、關(guān)于測(cè)試的誤區(qū)1、“測(cè)試沒(méi)有什么技術(shù)挑戰(zhàn)”干測(cè)試是因?yàn)閯e無(wú)選擇如果我做開(kāi)發(fā)，可以用給定的程序設(shè)計(jì)語(yǔ)言創(chuàng)造產(chǎn)品，這是很有意義的事情，而測(cè)試不過(guò)是例行公事和重復(fù)性的工作，不需要什么特殊技能Technologyisthemaking,usage,andknowledgeoftools,machines,techniques,crafts,systemsormethodsoforganizationinordertosolveaproblemorperformaspecificfunction所以，測(cè)試工作本身，至少在測(cè)試的起步階段，對(duì)于技術(shù)能力的要求是不高的。雖然測(cè)試本身對(duì)技術(shù)的要求越來(lái)越高，但是解決這些問(wèn)題所需要的技術(shù)技能，應(yīng)該還是比不過(guò)開(kāi)發(fā)領(lǐng)域。如果你如果對(duì)純粹的技術(shù)更加有偏好的話，你還是更應(yīng)該做開(kāi)發(fā)人員，而且最好還是做你們公司的核心的產(chǎn)品的開(kāi)發(fā)，這樣才能受到最大的鍛煉，對(duì)你的成長(zhǎng)更有幫助。1.1.2軟件測(cè)試的目的、對(duì)象與原則軟件、產(chǎn)品公司必須盡全力減少、最好消除所交付的產(chǎn)品中存在的缺陷；缺陷不可能在軟件中隱藏得太久用戶在使用軟件時(shí)，存在不可預(yù)知的“誤操作”，必須要保證軟件仍能正確運(yùn)行；1、測(cè)試的目地測(cè)試的目的是說(shuō)明程序正確地執(zhí)行它應(yīng)有的功能”

這種說(shuō)法正確嗎？例1程序Triangle，輸入三個(gè)整數(shù)，表示一個(gè)三角形的三個(gè)邊長(zhǎng)，該程序產(chǎn)生一個(gè)結(jié)果，指出該三角形是等邊三角形、等腰三角形還是不等邊三角形。為說(shuō)明其能正確執(zhí)行它的功能，可使用“測(cè)試用例”(3，4，5)，(5，5，6)，(6，6，6)，程序都能給出正確結(jié)果，是否就可認(rèn)為程序是正確的？基于不同的立場(chǎng)，存在著兩種完全不同的測(cè)試目的。從用戶的角度出發(fā)，普遍希望通過(guò)軟件測(cè)試暴露軟件中隱藏的錯(cuò)誤和缺陷，以考慮是否可接受該產(chǎn)品。從軟件開(kāi)發(fā)者的角度出發(fā)，則希望測(cè)試成為表明軟件產(chǎn)品中不存在錯(cuò)誤的過(guò)程，驗(yàn)證該軟件已正確地實(shí)現(xiàn)了用戶的要求，確立人們對(duì)軟件質(zhì)量的信心。GlenfordJ.Myers在<軟件測(cè)試之藝術(shù)>中認(rèn)為：1.測(cè)試是為了尋找錯(cuò)誤而運(yùn)行程序的過(guò)程。2.一個(gè)好的測(cè)試用例是指很可能找到迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。3.一個(gè)成功的測(cè)試是揭示了迄今為止尚未發(fā)現(xiàn)的錯(cuò)誤的測(cè)試。E.W.Dijkstra指出：“程序測(cè)試能證明錯(cuò)誤的存在,但不能證明錯(cuò)誤不存在?！薄浖y(cè)試的目的測(cè)試的目的：發(fā)現(xiàn)程序的錯(cuò)誤；任務(wù)：通過(guò)在計(jì)算機(jī)上執(zhí)行程序，暴露程序中潛在的錯(cuò)誤。糾錯(cuò)的目的：定位和糾正錯(cuò)誤；任務(wù)：消除軟件故障，保證程序的可靠運(yùn)行。軟件測(cè)試是根據(jù)軟件開(kāi)發(fā)個(gè)階段的規(guī)格說(shuō)明和程序的內(nèi)部結(jié)構(gòu)而精心設(shè)計(jì)一批測(cè)試用例（即輸入數(shù)據(jù)及其預(yù)期的輸出結(jié)果），并利用這些測(cè)試用例去運(yùn)行程序，以發(fā)現(xiàn)程序錯(cuò)誤的過(guò)程。測(cè)試肯定是促成產(chǎn)品質(zhì)量的因素之一，但是測(cè)試本身卻不能提高產(chǎn)品的質(zhì)量，對(duì)于一個(gè)好的產(chǎn)品，測(cè)試與其他階段恰當(dāng)?shù)慕换ナ潜夭豢缮俚摹?、軟件測(cè)試的對(duì)象從傳統(tǒng)意義上來(lái)說(shuō)，測(cè)試被狹義地定義為測(cè)試程序代碼。是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過(guò)程；廣義來(lái)說(shuō)，測(cè)試包含了所有生產(chǎn)優(yōu)質(zhì)產(chǎn)品的相關(guān)活動(dòng)，生產(chǎn)軟件產(chǎn)品必須有幾個(gè)階段（需求獲取，分析，設(shè)計(jì)與編碼），除此之外還有測(cè)試（即傳統(tǒng)意義的測(cè)試）

測(cè)試貫穿于全部軟件生存周期，并且不是周期結(jié)束前的最后一個(gè)活動(dòng)！測(cè)試與開(kāi)發(fā)模型軟件測(cè)試不僅僅是執(zhí)行測(cè)試，而是一個(gè)包含很多復(fù)雜活動(dòng)的過(guò)程，并且這些過(guò)程應(yīng)該貫穿于整個(gè)軟件開(kāi)發(fā)過(guò)程。在軟件開(kāi)發(fā)過(guò)程中，應(yīng)該什么時(shí)候進(jìn)行測(cè)試，如何更好地把軟件開(kāi)發(fā)和測(cè)試活動(dòng)集成到一起？其實(shí)這也是軟件測(cè)試工作人員必須考慮的問(wèn)題，因?yàn)橹挥羞@樣，才能提高軟件測(cè)試工作的效率，提高軟件產(chǎn)品的質(zhì)量，最大限度地降低軟件開(kāi)發(fā)與測(cè)試的成本，減少重復(fù)勞動(dòng)。需要了解開(kāi)發(fā)模型，瀑布、V、W、X等模型瀑布模型1970年WinstonRoyce提出了著名的"瀑布模型（WaterfallModel）"，直到80年代早期，它一直是唯一被廣泛采用的軟件開(kāi)發(fā)模型。瀑布模型它將軟件生命周期劃分為制定計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫(xiě)、軟件測(cè)試和運(yùn)行維護(hù)等六個(gè)基本活動(dòng)，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級(jí)下落。V模型20世紀(jì)80年代后期PaulRook提出了著名的軟件測(cè)試的V模型，旨在改進(jìn)軟件開(kāi)發(fā)的效率和效果。清楚的描述了這些測(cè)試階段和開(kāi)發(fā)過(guò)程期間各階段的對(duì)應(yīng)關(guān)系。V模型指出，單元和集成測(cè)試應(yīng)檢測(cè)程序的執(zhí)行是否滿足軟件設(shè)計(jì)的要求；系統(tǒng)測(cè)試應(yīng)檢測(cè)系統(tǒng)功能、性能的質(zhì)量特性是否達(dá)到系統(tǒng)要求的指標(biāo)；驗(yàn)收測(cè)試確定軟件的實(shí)現(xiàn)是否滿足用戶需要或合同的要求。但V模型存在一定的局限性，它僅僅把測(cè)試作為在編碼之后的一個(gè)階段，是針對(duì)程序進(jìn)行的尋找錯(cuò)誤的活動(dòng)，而忽視了測(cè)試活動(dòng)對(duì)需求分析、系統(tǒng)設(shè)計(jì)等活動(dòng)的驗(yàn)證和確認(rèn)的功能。W模型Evolutif公司針對(duì)V模型的缺陷，相對(duì)于V模型，提出了W模型的概念，W模型增加了軟件各開(kāi)發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)。W模型強(qiáng)調(diào)：測(cè)試伴隨著整個(gè)軟件開(kāi)發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序，需求、設(shè)計(jì)等同樣要測(cè)試，也就是說(shuō)，測(cè)試與開(kāi)發(fā)是同步進(jìn)行的。W模型有利于盡早地全面的發(fā)現(xiàn)問(wèn)題。例如，需求分析完成后，測(cè)試人員就應(yīng)該參與到對(duì)需求的驗(yàn)證和確認(rèn)活動(dòng)中，以盡早地找出缺陷所在。同時(shí)，對(duì)需求的測(cè)試也有利于及時(shí)了解項(xiàng)目難度和測(cè)試風(fēng)險(xiǎn)，及早制定應(yīng)對(duì)措施，這將顯著減少總體測(cè)試時(shí)間，加快項(xiàng)目進(jìn)度。

測(cè)試貫穿于全部軟件生存周期，并且不是周期結(jié)束前的最后一個(gè)活動(dòng)！軟件生存期各階段間需保持的正確性用戶要求用戶：我要什么?運(yùn)行結(jié)果計(jì)算機(jī)：程序運(yùn)行得到的結(jié)果源程序程序員：我要讓計(jì)算機(jī)什么做?設(shè)計(jì)說(shuō)明書(shū)設(shè)計(jì)員：我要讓軟件做什么?需求說(shuō)明書(shū)分析員：我可以提供什么?12345理解正確性表達(dá)正確性理解正確性設(shè)計(jì)正確性表達(dá)正確性理解正確性編碼正確性運(yùn)行正確性輸入正確性相符嗎?

開(kāi)發(fā)前期出現(xiàn)錯(cuò)誤的擴(kuò)展計(jì)劃需求分析設(shè)計(jì)編碼測(cè)試AAB

軟件缺陷的組成我們知道軟件缺陷是由很多原因造成的，如果把它們按需求分析結(jié)果——規(guī)格說(shuō)明書(shū)，系統(tǒng)設(shè)計(jì)結(jié)果，編程的代碼等歸類起來(lái)，比較后發(fā)現(xiàn)，結(jié)果規(guī)格說(shuō)明書(shū)是軟件缺陷出現(xiàn)最多的地方。3、測(cè)試的原則應(yīng)當(dāng)把“盡早地和不斷地進(jìn)行軟件測(cè)試”作為軟件開(kāi)發(fā)者的座右銘。程序員應(yīng)避免檢查自己的程序。pareto原則：測(cè)試發(fā)現(xiàn)的錯(cuò)誤中80%很可能起源于20%的模塊中。應(yīng)孤立這些疑點(diǎn)模塊重點(diǎn)測(cè)試。程序修改后要回歸測(cè)試窮舉測(cè)試是不可能的測(cè)試的原則檢查程序是否“未做其應(yīng)該做的”僅是測(cè)試的一半，測(cè)試的另一半是檢查程序是否“做了其不應(yīng)該做的”。計(jì)劃測(cè)試工作時(shí)不應(yīng)默許假定不會(huì)發(fā)現(xiàn)錯(cuò)誤最嚴(yán)重的錯(cuò)誤(從用戶角度)是那些導(dǎo)致軟件無(wú)法滿足需求的錯(cuò)誤。程序中的問(wèn)題根源可能在開(kāi)發(fā)前期的各階段解決、糾正錯(cuò)誤也必須追溯到前期工作。1.3軟件測(cè)試的分類軟件測(cè)試按照不同的分類標(biāo)準(zhǔn)，存在著各種各樣的測(cè)試名稱，比如按照軟件項(xiàng)目流程階段劃分，可分為單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試。如下是一個(gè)典型瀑布式軟件開(kāi)發(fā)流程：軟件測(cè)試的分類單元測(cè)試：?jiǎn)卧獪y(cè)試是對(duì)軟件中的基本組成單位進(jìn)行的測(cè)試，目的是檢驗(yàn)軟件基本組成單位的正確性。集成測(cè)試：集成測(cè)試是在軟件系統(tǒng)集成過(guò)程中所進(jìn)行的測(cè)試，目的是檢查軟件單位之間的接口是否正確。系統(tǒng)測(cè)試：是對(duì)已經(jīng)集成好的軟件系統(tǒng)進(jìn)行徹底的測(cè)試，以驗(yàn)證軟件系統(tǒng)的正確性和性能等是否滿足其規(guī)約所指定的要求。驗(yàn)收測(cè)試：是部署軟件之前的最后一個(gè)測(cè)試操作，驗(yàn)收測(cè)試的目的是確保軟件準(zhǔn)備就緒，向軟件購(gòu)買(mǎi)都展示該軟件系統(tǒng)滿足其用戶的需求。軟件測(cè)試的另一種分類法如果從測(cè)試工作對(duì)軟件代碼的可見(jiàn)程度劃分，又可分為白盒測(cè)試、黑盒測(cè)試與灰盒測(cè)試，這也是軟件測(cè)試領(lǐng)域中最基本的兩個(gè)概念。黑盒測(cè)試軟件輸入不深入代碼細(xì)節(jié)的測(cè)試方法稱為動(dòng)態(tài)黑盒測(cè)試。軟件測(cè)試員充當(dāng)客戶來(lái)使用。輸出這種方法是把測(cè)試對(duì)象看做一個(gè)黑盒子，測(cè)試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說(shuō)明書(shū)，檢查程序的功能是否符合它的功能說(shuō)明。

黑盒測(cè)試方法是在程序接口上進(jìn)行測(cè)試，主要是為了發(fā)現(xiàn)以下錯(cuò)誤：

是否有不正確或遺漏了的功能?在接口上，輸入能否正確地接受?能否輸出正確的結(jié)果?是否有數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部信息(例如數(shù)據(jù)文件)訪問(wèn)錯(cuò)誤?性能上是否能夠滿足要求?是否有初始化或終止性錯(cuò)誤?

例2：假設(shè)一個(gè)程序P有輸入量X和Y及輸出量Z。在字長(zhǎng)為32位的計(jì)算機(jī)上運(yùn)行。若X、Y取整數(shù)，按黑盒方法進(jìn)行窮舉測(cè)試：可能采用的測(cè)試數(shù)據(jù)組：

232×232

＝264

如果測(cè)試一組數(shù)據(jù)需要1毫秒，一年工作365×24小時(shí)，完成所有測(cè)試需5億年。用黑盒測(cè)試發(fā)現(xiàn)程序中的錯(cuò)誤，必須在所有可能的輸入條件和輸出條件中確定測(cè)試數(shù)據(jù)，來(lái)檢查程序是否都能產(chǎn)生正確的輸出。但這是不可能的。白盒測(cè)試白盒測(cè)試，指的是把“盒子”蓋子去掉，去研究“盒子”里面的源代碼和程序結(jié)構(gòu)。白盒測(cè)試按照程序內(nèi)部的結(jié)構(gòu)測(cè)試程序，通過(guò)測(cè)試來(lái)檢測(cè)產(chǎn)品內(nèi)部動(dòng)作是否按照設(shè)計(jì)規(guī)格說(shuō)明書(shū)的規(guī)定正常進(jìn)行，檢驗(yàn)程序中的每條通路是否都能按預(yù)定要求正確工作。靜態(tài)白盒測(cè)試即是利用眼睛，瀏覽代碼，憑借經(jīng)驗(yàn)，找出代碼中的錯(cuò)誤或者代碼中不符合書(shū)寫(xiě)規(guī)范的地方,不要求在計(jì)算機(jī)上實(shí)際執(zhí)行所測(cè)程序。動(dòng)態(tài)白盒測(cè)試通過(guò)輸入一組預(yù)先按照一定的測(cè)試準(zhǔn)則構(gòu)造的實(shí)例數(shù)據(jù)來(lái)動(dòng)態(tài)運(yùn)行程序，而達(dá)到發(fā)現(xiàn)程序錯(cuò)誤的過(guò)程。比如一段代碼有4個(gè)分支，輸入4組不同的測(cè)試數(shù)據(jù)使4組分支都可以走通而且結(jié)果必須正確?；液袦y(cè)試白盒和黑盒測(cè)試能發(fā)現(xiàn)軟件在其生命周期不同階段的不同類型的安全性隱患。而所謂的“灰盒測(cè)試”介于黑盒測(cè)試與白盒測(cè)試之間?？梢赃@樣理解，灰盒測(cè)試關(guān)注輸出對(duì)于輸入的正確性，同時(shí)也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過(guò)一些表征性的現(xiàn)象、事件、標(biāo)志來(lái)判斷內(nèi)部的運(yùn)行狀態(tài)，有時(shí)候輸出是正確的，但內(nèi)部其實(shí)已經(jīng)錯(cuò)誤了，這種情況非常多，如果每次都通過(guò)白盒測(cè)試來(lái)操作，效率會(huì)很低，因此需要采取這樣的一種灰盒的方法。1.2測(cè)試用例“測(cè)試用例”（TestCase）是為某個(gè)特殊目標(biāo)而編制的一組測(cè)試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測(cè)試某個(gè)程序是否滿足某個(gè)特定的需求。測(cè)試用例是將軟件測(cè)試的行為、活動(dòng)進(jìn)行科學(xué)化的組織和歸納，目的是能夠?qū)④浖y(cè)試的行為轉(zhuǎn)化成可管理的模式。比如，當(dāng)不同的測(cè)試工程師在相同的“環(huán)境”（指相同的被測(cè)軟件、測(cè)試環(huán)境等條件）下執(zhí)行相同的的測(cè)試用例時(shí)，可以得出相同的結(jié)果，不會(huì)因?yàn)闇y(cè)試工程師的不同到導(dǎo)致測(cè)試結(jié)果的改變，這對(duì)于經(jīng)常有測(cè)試工程師流動(dòng)的企業(yè)、公司來(lái)說(shuō)，在軟件項(xiàng)目的管理上起到了非常重要的作用。測(cè)試用例也是將測(cè)試具體量化的方法之一，不同類別的軟件或同一軟件的不同功能，測(cè)試用例都是不同的。測(cè)試用例的重要性測(cè)試用例是測(cè)試部門(mén)的基石：測(cè)試用例是測(cè)試皇冠上的寶石測(cè)試用例的地位決定其重要性：測(cè)試用例在測(cè)試執(zhí)行過(guò)程中的指導(dǎo)性：1.2.1測(cè)試用例的評(píng)估大體上，測(cè)試用例的質(zhì)量可以從兩個(gè)方面來(lái)衡量：?jiǎn)蝹€(gè)測(cè)試用例的執(zhí)行度所有測(cè)試用例的覆蓋度。單個(gè)測(cè)試用例忠實(shí)度（測(cè)試用例應(yīng)該忠實(shí)于被測(cè)設(shè)備和特性，應(yīng)該嚴(yán)格遵守相關(guān)設(shè)計(jì)文檔，標(biāo)準(zhǔn)協(xié)議和市場(chǎng)需求，這三個(gè)元素構(gòu)成了測(cè)試用例的基本來(lái)源。如果測(cè)試步驟錯(cuò)誤或者背離了產(chǎn)品設(shè)計(jì)的意圖，無(wú)疑將導(dǎo)致錯(cuò)誤的測(cè)試結(jié)果，會(huì)浪費(fèi)測(cè)試人員，開(kāi)發(fā)人員的寶貴時(shí)間）目的明確做任何事都要有目的，測(cè)試用例更是如此。整個(gè)測(cè)試用例應(yīng)該圍繞一個(gè)明確的測(cè)試目的，然后展開(kāi)測(cè)試步驟。測(cè)試目的代表了產(chǎn)品的一個(gè)測(cè)試點(diǎn)，測(cè)試目的是測(cè)試用例的中心靈魂。執(zhí)行度測(cè)試用例的執(zhí)行度代表了對(duì)產(chǎn)品特性理解的程度，測(cè)試用例越細(xì)致深入，就越有可能發(fā)現(xiàn)深層的缺陷。然而，要做到這一點(diǎn)不是容易的事情，需要對(duì)產(chǎn)品特性，協(xié)議的精確理解和長(zhǎng)期的測(cè)試經(jīng)驗(yàn)積累?？芍貜?fù)性測(cè)試用例寫(xiě)好了，可能會(huì)交給不同的測(cè)試人員，在不同的時(shí)間和場(chǎng)合執(zhí)行測(cè)試。測(cè)試用例的可重復(fù)性是指在這些不同的情況下，應(yīng)該有一致的測(cè)試結(jié)果?？勺x性如同讀文章一樣，測(cè)試用例也是在測(cè)試人員之間傳遞閱讀的。清晰的上下文關(guān)系，明確干凈的描述讓測(cè)試人員很容易理解測(cè)試的意圖和步驟，避免了對(duì)測(cè)試意圖的誤解。通常，測(cè)試用例的可讀性是容易被忽略的，然而要做好這一點(diǎn)并不困難。測(cè)試用例集合覆蓋程度Testingcoverage（測(cè)試覆蓋），指測(cè)試系統(tǒng)覆蓋被測(cè)試系統(tǒng)的程度，一項(xiàng)給定測(cè)試或一組測(cè)試對(duì)某個(gè)給定系統(tǒng)或構(gòu)件的所有指定測(cè)試用例進(jìn)行處理所達(dá)到的程度。對(duì)于產(chǎn)品測(cè)試特別是復(fù)雜龐大的產(chǎn)品，錯(cuò)過(guò)了測(cè)試點(diǎn)，就等于錯(cuò)過(guò)了產(chǎn)品缺陷。如果說(shuō)每個(gè)測(cè)試用例覆蓋了一個(gè)測(cè)試點(diǎn)，所有的這些測(cè)試點(diǎn)構(gòu)成了整個(gè)產(chǎn)品的測(cè)試覆蓋面。整個(gè)測(cè)試用例集應(yīng)該覆蓋從單一功能到復(fù)雜功能測(cè)試，系統(tǒng)測(cè)試，性能測(cè)試，兼容性測(cè)試，場(chǎng)景測(cè)試等方方面面，力圖使測(cè)試盲點(diǎn)降到最低。清晰的分層結(jié)構(gòu)產(chǎn)品是復(fù)雜的，軟件研發(fā)者面對(duì)這種復(fù)雜性采用的經(jīng)典的方法瀑布模型，也就是從上到下，逐漸細(xì)分，大模塊包括小模塊，小模塊包括更小的模塊。對(duì)于測(cè)試用例來(lái)說(shuō)，非常自然的，我們也需要考慮用這種層次化的組織結(jié)構(gòu)來(lái)管理測(cè)試用例。1.2.2測(cè)試用例的分類和要素構(gòu)成測(cè)試用例的分類說(shuō)法不一，其中一個(gè)普遍認(rèn)同的說(shuō)法是白盒測(cè)試和黑盒測(cè)試。本課程只對(duì)黑盒測(cè)試展開(kāi)闡述黑盒測(cè)試著眼于被測(cè)物外部結(jié)構(gòu)，不考慮內(nèi)部邏輯結(jié)構(gòu)。黑盒測(cè)試是以用戶的角度，從輸入數(shù)據(jù)與輸出數(shù)據(jù)的對(duì)應(yīng)關(guān)系出發(fā)進(jìn)行測(cè)試的。黑盒測(cè)試用例的分類（從測(cè)試過(guò)程來(lái)分）

單一功能測(cè)試（featuretesting）根據(jù)產(chǎn)品特征、操作描述和用戶方案，測(cè)試產(chǎn)品的一個(gè)特性和可操作行為以確定它們滿足設(shè)計(jì)需求。它只需考慮單個(gè)功能，不需要考慮整個(gè)軟件的其他模塊及代碼。集成測(cè)試（integritytesting）集成測(cè)試，也叫組裝測(cè)試或聯(lián)合測(cè)試。在單一功能測(cè)試的基礎(chǔ)上，將多個(gè)模塊按照設(shè)計(jì)要求）組裝成為子系統(tǒng)或系統(tǒng)，進(jìn)行集成測(cè)試。實(shí)踐表明，一些模塊雖然能夠單獨(dú)地工作，但并不能保證連接起來(lái)也能正常的工作。程序在某些局部反映不出來(lái)的問(wèn)題，在全局上很可能暴露出來(lái)，影響功能的實(shí)現(xiàn)。

系統(tǒng)測(cè)試(systemtesting)系統(tǒng)測(cè)試是將已經(jīng)確認(rèn)的所有模塊，包括軟件、計(jì)算機(jī)硬件、外設(shè)、網(wǎng)絡(luò)等其他元素結(jié)合在一起，進(jìn)行信息系統(tǒng)的各種組裝測(cè)試和確認(rèn)測(cè)試，其目的是通過(guò)與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開(kāi)發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方，從而提出更加完善的方案.。回歸測(cè)試(regressiontesting)在軟件生命周期中的任何一個(gè)階段，只要軟件發(fā)生了改變，就可能給該軟件帶來(lái)問(wèn)題。同樣，在有新代碼加入軟件的時(shí)候，除了新加入的代碼中有可能含有錯(cuò)誤外，新代碼還有可能對(duì)原有的代碼帶來(lái)影響。因此，每當(dāng)軟件發(fā)生變化時(shí)，我們就必須重新測(cè)試現(xiàn)有的功能，以便確定修改是否達(dá)到了預(yù)期的目的，檢查修改是否損害了原有的正常功能。為了驗(yàn)證修改的正確性及其影響就需要進(jìn)行回歸測(cè)試。黑盒測(cè)試用例的分類（從測(cè)試過(guò)程來(lái)分）

一致性測(cè)試(compatibilitytesting)又包括功能一致性和協(xié)議標(biāo)準(zhǔn)一致性。是檢驗(yàn)被測(cè)設(shè)備是否和設(shè)計(jì)要求一致，是否和標(biāo)準(zhǔn)協(xié)議一致。邊界值(boundarytesting)長(zhǎng)期的測(cè)試工作經(jīng)驗(yàn)告訴我們，大量的錯(cuò)誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內(nèi)部。因此針對(duì)各種邊界情況設(shè)計(jì)測(cè)試用例，可以查出更多的錯(cuò)誤。使用邊界值分析方法設(shè)計(jì)測(cè)試用例，首先應(yīng)確定邊界情況。通常輸入和輸出等價(jià)類的邊界，就是應(yīng)著重測(cè)試的邊界情況。應(yīng)當(dāng)選取正好等于，剛剛大于或剛剛小于邊界的值作為測(cè)試數(shù)據(jù)，而不是選取等價(jià)類中的典型值或任意值作為測(cè)試數(shù)據(jù)。黑盒測(cè)試用例的分類（從測(cè)試方法來(lái)分）

負(fù)面測(cè)試（Negativetesting）是相對(duì)于正面測(cè)試（Positivetesting）而言的。它們也是測(cè)試設(shè)計(jì)時(shí)的兩個(gè)非常重要的劃分。簡(jiǎn)單點(diǎn)說(shuō)，正面測(cè)試就是測(cè)試系統(tǒng)是否完成了它應(yīng)該完成的工作；而負(fù)面測(cè)試就是測(cè)試系統(tǒng)是否不執(zhí)行它不應(yīng)該完成的操作。形象一點(diǎn)，正面測(cè)試就象一個(gè)畢恭畢敬的小學(xué)生，老師叫我做什么，我就做什么；而負(fù)面測(cè)試就象一個(gè)調(diào)皮搗蛋的孩子，你叫我這樣做，我偏不這樣做，而且和你對(duì)著干。開(kāi)發(fā)人員也是最討厭修改此類缺陷的。執(zhí)行負(fù)面測(cè)試時(shí)，不單單要測(cè)試系統(tǒng)是否處理了用戶的異常操作，還要檢查系統(tǒng)對(duì)于這些異常操作是否給予了正確的錯(cuò)誤提示。它是系統(tǒng)對(duì)用戶進(jìn)行繼續(xù)正確操作的指引。黑盒測(cè)試用例的分類（從測(cè)試方法來(lái)分）

穩(wěn)定性測(cè)試(robusttesting)壓力測(cè)試(loadtesting)性能測(cè)試(performancetesting)測(cè)試用例的要素一個(gè)完整的測(cè)試用例應(yīng)該包含以下要素：TestID(用例編號(hào))Description（用例描述）Pre-setup（預(yù)置條件）Platform（測(cè)試平臺(tái)）Priority（優(yōu)先級(jí)）Complexity(復(fù)雜度)StepsExpectedresults(步驟/預(yù)期結(jié)果)用例描述應(yīng)該是對(duì)測(cè)試用例目的和過(guò)程的簡(jiǎn)要描述，應(yīng)該控制在幾句話的范圍內(nèi)。用例描述應(yīng)該使閱讀者迅速并清楚地知道測(cè)試的意圖，也就是測(cè)試的目的所在。對(duì)測(cè)試執(zhí)行人員和測(cè)試管理者來(lái)說(shuō)，最關(guān)注的其實(shí)就是用例描述，通過(guò)對(duì)每個(gè)用例描述的預(yù)覽，可以初步判斷整個(gè)測(cè)試集的覆蓋面和深度。測(cè)試步驟和預(yù)期結(jié)果是測(cè)試目的的展開(kāi)。簡(jiǎn)單來(lái)說(shuō)：測(cè)試步驟就是讓被測(cè)設(shè)備到達(dá)某種狀態(tài)，預(yù)期結(jié)果就是被測(cè)設(shè)備在這種狀態(tài)下應(yīng)該有的表現(xiàn)。預(yù)期結(jié)果必須和測(cè)試步驟一一對(duì)應(yīng)，用來(lái)驗(yàn)證被測(cè)設(shè)備是否正常。測(cè)試與測(cè)試用例測(cè)試的目標(biāo)是在用戶發(fā)現(xiàn)缺陷之前找到他們窮盡的測(cè)試是不可能的測(cè)試貫穿與全部的軟件開(kāi)發(fā)周期理解測(cè)試背后的原因（明白測(cè)什么，正確執(zhí)行合適的測(cè)試）測(cè)試用例應(yīng)該首先被測(cè)試測(cè)試用例需要不斷完善，不斷修訂充分注意測(cè)試中的群集現(xiàn)象。經(jīng)驗(yàn)表明，測(cè)試后程序中殘存的錯(cuò)誤數(shù)目與該程序中已發(fā)現(xiàn)的錯(cuò)誤數(shù)目成正比。缺陷成群集中出現(xiàn)，因此測(cè)試應(yīng)該關(guān)注這些缺陷。在設(shè)計(jì)測(cè)試用例時(shí)，應(yīng)包括合理的輸入條件和不合理的輸入條件。所有的測(cè)試都應(yīng)追溯到用戶需求應(yīng)長(zhǎng)期保留測(cè)試用例，直至系統(tǒng)廢棄。1.3測(cè)試工作的生命周期軟件測(cè)試不可能發(fā)現(xiàn)產(chǎn)品中的全部BUG，在現(xiàn)實(shí)的研發(fā)活動(dòng)中，提供給測(cè)試人員的資源也是極為有限的，如時(shí)間、人力資源、設(shè)備資源等。那么一項(xiàng)產(chǎn)品的開(kāi)發(fā)活動(dòng)或項(xiàng)目實(shí)施，什么時(shí)候應(yīng)該開(kāi)始測(cè)試？什么時(shí)候停止測(cè)試呢？我們一般把軟件測(cè)試周期分為如下七個(gè)階段1.3.1計(jì)劃階段這是產(chǎn)品測(cè)試概念定義的階段，定義測(cè)試標(biāo)準(zhǔn)和流程等。包含的9個(gè)方面的主要工作：1、制定測(cè)試計(jì)劃（包含測(cè)試大綱），測(cè)試周期的設(shè)定、測(cè)試的目標(biāo)、質(zhì)量參數(shù)、beta測(cè)試階段的驗(yàn)收標(biāo)準(zhǔn)等等。2、制定各個(gè)階段進(jìn)行review（評(píng)價(jià)、核實(shí)）的時(shí)間，對(duì)上階段的情況進(jìn)行分析和總結(jié)，以調(diào)整計(jì)劃。如討論測(cè)試覆蓋率、人員有無(wú)不足之類。3、制定錯(cuò)誤報(bào)告的流程，比如那些問(wèn)題要上報(bào)，那些問(wèn)題暫時(shí)不用上報(bào)，并制定書(shū)寫(xiě)的格式，跟蹤的方法，以及制定錯(cuò)誤報(bào)告的類型?！?.1.3.2分析階段分析階段是一個(gè)外部文檔階段，這個(gè)階段的主要工作是從客戶和開(kāi)發(fā)組得到的文檔并進(jìn)行分析和總結(jié)。根據(jù)獲取的信息去創(chuàng)建測(cè)試的框架和相應(yīng)的測(cè)試文檔。所以本階段主要的工作是完成分析，搭出測(cè)試框架，書(shū)寫(xiě)大綱等。包括的10個(gè)方面的主要工作（P14-15）1.3.3設(shè)計(jì)階段

完成測(cè)試內(nèi)部文檔的階段，這些文檔大部分都是在分析階段形成了大體的組織結(jié)構(gòu)和大綱的文檔，像測(cè)試用例之類的都有了一些基本的描述，本階段主要的工作就是完成這些文檔的最終書(shū)寫(xiě)。如測(cè)試計(jì)劃，測(cè)試時(shí)間表，測(cè)試數(shù)據(jù)，各種相關(guān)文檔都應(yīng)該處于完成階段。當(dāng)然，仍然可以通過(guò)設(shè)計(jì)的危機(jī)處理機(jī)制進(jìn)行更新。特別要指出的是，測(cè)試用例并不能夠在本階段完成。由于新功能的添加，具體功能的實(shí)現(xiàn)方法，修改功能等因素，測(cè)試用例只能不斷的更新。1.3.4構(gòu)建階段構(gòu)建階段，是在開(kāi)發(fā)人員編碼的同時(shí)，最終完成系統(tǒng)預(yù)先設(shè)置的各種測(cè)試用例的階段。本階段的很多工作其實(shí)在上個(gè)階段就已經(jīng)涉及到了，完成本階段的工作后，將進(jìn)入到測(cè)試的主要階段，對(duì)產(chǎn)品進(jìn)行設(shè)定的各種測(cè)試。該階段包括7個(gè)方面的工作，P161.3.5循環(huán)測(cè)試階段

循環(huán)測(cè)試階段是最花費(fèi)時(shí)間的階。按照之前制定好的計(jì)劃，利用各種資源、工具，依循完成的測(cè)試用例對(duì)系統(tǒng)進(jìn)行一輪又一輪的測(cè)試，直到代碼開(kāi)發(fā)凍結(jié)。本階段也包含了不斷設(shè)置的回歸測(cè)試。1.3.6最后測(cè)試和實(shí)施階段本階段是代碼凍結(jié)后的測(cè)試階段，這個(gè)時(shí)候需要進(jìn)行的是最后的驗(yàn)證測(cè)試，主要是完成最終的性能，壓力，文檔測(cè)試和UI等測(cè)試過(guò)程，開(kāi)始形成系統(tǒng)說(shuō)明書(shū)和用戶手冊(cè)。此時(shí)一般不在去修改主要的源代碼，只是對(duì)外觀和界面的錯(cuò)誤進(jìn)行修復(fù)。只是對(duì)現(xiàn)有的一些問(wèn)題進(jìn)行跟蹤和管理，必要的時(shí)候準(zhǔn)備發(fā)布修復(fù)版。1.3.7實(shí)施后階段

對(duì)整個(gè)項(xiàng)目進(jìn)行總結(jié)的階段。通過(guò)書(shū)寫(xiě)一些最終的報(bào)告。例如，錯(cuò)誤分析報(bào)告，包括一共有多少個(gè)，有效率是多少，分布情況如何等等。這個(gè)階段主要是將好的經(jīng)驗(yàn)總結(jié)下來(lái)，對(duì)不足進(jìn)行思考，為下個(gè)項(xiàng)目做準(zhǔn)備。1.4BUG管理什么是bugBug按照英文直譯過(guò)來(lái)叫“蟲(chóng)子”。任何事物都不是完美的，何況是需要被測(cè)測(cè)試的物體。簡(jiǎn)單的來(lái)說(shuō)，bug就是事物的缺陷?，F(xiàn)實(shí)生活中充滿了bug：人生病了，我們可以理解為有了bug；汽車拋錨了，我們可以理解為出了bug，電腦死機(jī)了，更是一個(gè)bug。如何判斷Bug但不是所有的問(wèn)題都是bug。嚴(yán)格來(lái)說(shuō)，是產(chǎn)品在規(guī)定范圍或正常操作下出現(xiàn)的錯(cuò)誤，才能稱為bug。如前面提到的汽車拋錨了，如果是因?yàn)槠囀褂媚晗蕹^(guò)了應(yīng)該的年限，或者是司機(jī)的錯(cuò)誤操作，都不能稱為bug。下面是一個(gè)bug舉例：WindowsXP支持的最大共享文件夾名長(zhǎng)度為80個(gè)英文字母或40個(gè)漢字，但設(shè)置共享文件夾名時(shí)可輸入的范圍是80個(gè)英文字符或80個(gè)漢字，如果共享文件夾名在41～80個(gè)漢字之間，系統(tǒng)會(huì)提示該共享名包含無(wú)效的字符摂。其實(shí)真正的原因是共享文件夾名超長(zhǎng)。尋找Bug的目的測(cè)試究竟是用來(lái)做什么的？bug又有什么用處？測(cè)試不是為了找bug這么簡(jiǎn)單，測(cè)試的目的是通過(guò)找bug來(lái)提高產(chǎn)品質(zhì)量，提高產(chǎn)品開(kāi)發(fā)流程，繼而滿足市場(chǎng)和客戶的要求。沒(méi)有bug的完美產(chǎn)品是不存在的，一輪接一輪的測(cè)試就是為了讓產(chǎn)品更加穩(wěn)定，讓bug被限制到盡可能小的范圍。Bug的嚴(yán)重等級(jí)是對(duì)被測(cè)設(shè)備表現(xiàn)的一個(gè)評(píng)判。被測(cè)設(shè)備錯(cuò)誤表現(xiàn)的嚴(yán)重性就決定了bug的嚴(yán)重等級(jí)。各家公司和機(jī)構(gòu)對(duì)于嚴(yán)重等級(jí)的劃分標(biāo)準(zhǔn)不一，但大體上可以按照下面的方式來(lái)定義：Priority1被測(cè)設(shè)備崩潰。被測(cè)設(shè)備重啟。內(nèi)存泄漏系統(tǒng)配置丟失（硬件類）Bug的嚴(yán)重等級(jí)Priority2功能或模塊不工作,測(cè)試就結(jié)果或行為與預(yù)期不一致，且沒(méi)有避開(kāi)BUG的替代方法。功能缺失。系統(tǒng)性能與參考值相差太大。Priority3功能或模塊不工作,測(cè)試就結(jié)果或行為與預(yù)期不一致，但有避開(kāi)BUG的替代方法。Bug的優(yōu)先級(jí)別Bug的優(yōu)先級(jí)別是從客戶需求角度來(lái)說(shuō)的，用戶認(rèn)為重要的特性出了問(wèn)題，哪怕只是小小的顯示信息錯(cuò)誤，也應(yīng)該在第一時(shí)間解決。Bug的生命歷程Bug也是有生命的，從bug的發(fā)現(xiàn)，到bug的修復(fù)。就是一個(gè)bug的生命歷程：1.4.2發(fā)現(xiàn)bugBug從那里來(lái)？一個(gè)產(chǎn)品從設(shè)計(jì)到開(kāi)發(fā)，凝聚了所有系統(tǒng)設(shè)計(jì)師，開(kāi)發(fā)人員，設(shè)計(jì)人員，管理人員的心血。從另一個(gè)方面來(lái)講，這些不同的環(huán)節(jié)和不同人的工作，卻是導(dǎo)致bug的原因。舉例來(lái)說(shuō)，可能出現(xiàn)bug的情況有：新特性的增加對(duì)設(shè)計(jì)意圖的錯(cuò)誤理解代碼的反復(fù)修改不嚴(yán)格的代碼維護(hù)開(kāi)發(fā)人員的素質(zhì)緊張的開(kāi)發(fā)進(jìn)度。。。。。。怎么找bug？找bug決不是件簡(jiǎn)單的事情。一個(gè)高素質(zhì)的測(cè)試人員應(yīng)該做好一下的工作：熟悉產(chǎn)品設(shè)計(jì)需求熟悉標(biāo)準(zhǔn)協(xié)議規(guī)范熟悉產(chǎn)品操作手冊(cè)熟悉測(cè)試工具儀器的使用有豐富的測(cè)試經(jīng)驗(yàn)當(dāng)bug出現(xiàn)時(shí)當(dāng)我們?cè)诎l(fā)現(xiàn)一個(gè)產(chǎn)品的問(wèn)題時(shí)，怎么確定就是一個(gè)bug？這也不是個(gè)簡(jiǎn)單的問(wèn)題，確定bug的過(guò)程稱為bug定位。一般來(lái)說(shuō)，可以按照一下幾步來(lái)做：排除非正確因素：需要排除的因素包括是否按照合理的測(cè)試步驟，是否在合理的測(cè)試場(chǎng)景，是否在產(chǎn)品規(guī)格范圍內(nèi)，等等。只有排除了這些正常因素，而被測(cè)設(shè)備依然會(huì)有不正常行為，才能初步定位為bug。收集bug相關(guān)信息Bug出現(xiàn)時(shí)，應(yīng)該保存好設(shè)備的配置，測(cè)試儀器的配置，設(shè)備的日志，屏幕輸出等等。這些要素都是分析bug，修復(fù)bug的重要參考。尋找重現(xiàn)步驟這是bug定位中的難點(diǎn)，特別對(duì)于多功能多模塊的系統(tǒng)測(cè)試，bug產(chǎn)生的原因會(huì)很復(fù)雜，不是簡(jiǎn)單的表面現(xiàn)象就能找到重現(xiàn)條件。尋求開(kāi)發(fā)人員的幫助Bug找到了以后需要開(kāi)發(fā)人員的確認(rèn)和修復(fù)，測(cè)試人員需要和開(kāi)發(fā)人員一起確認(rèn)bug的原因，幫助開(kāi)發(fā)人員找到bug的根源。報(bào)告bug這時(shí)找到bug需要做的最后一步，通常會(huì)有專業(yè)的bug管理軟件，如bugzilla，clearDDTS等等。/about/什么是高質(zhì)量的bug？找到了Bug的重現(xiàn)條件，從測(cè)試的角度來(lái)說(shuō)，工作就完成了一大半。重現(xiàn)條件能夠幫助開(kāi)發(fā)人員更方便地定位，甚至開(kāi)發(fā)人員會(huì)依賴于重現(xiàn)條件才能定位。找Bug的意義在于修復(fù)bug，不能重現(xiàn)的bug往往不能找到原因，更談不上修復(fù)。分析Bug趨勢(shì)圖Bug不是越多越好，在適當(dāng)?shù)臅r(shí)候發(fā)現(xiàn)適當(dāng)數(shù)量和質(zhì)量的bug才是產(chǎn)品經(jīng)理所希望看到的。如何報(bào)告bug在有些公司里，程序員幾乎會(huì)把一半的測(cè)試bug返回給測(cè)試組，因?yàn)槟切゜ug不可再現(xiàn)、發(fā)現(xiàn)bug同設(shè)計(jì)要求一致，或者bug報(bào)告根本無(wú)法操作。為了防止這類問(wèn)題，要提交好的測(cè)試bug，作為一個(gè)好的測(cè)試人員，必須遵循以下步驟：1)總結(jié)：簡(jiǎn)要描述客戶或用戶的質(zhì)量體驗(yàn)和觀察到的一些特征。2)壓縮：精簡(jiǎn)任何不必要的信息，特別是冗余的測(cè)試步驟。3)去除歧義：使用清晰的語(yǔ)言，尤其要避免使用那些有多個(gè)不同或相反含義的詞匯。4)中立：公正地表達(dá)自己的意思，對(duì)錯(cuò)誤及其特征的事實(shí)進(jìn)行描述，避免夸張或忽略的語(yǔ)句，引起過(guò)度的注意力或忽視。5)評(píng)審：至少有一個(gè)同行，最好是一個(gè)有經(jīng)驗(yàn)的測(cè)試工程師或測(cè)試經(jīng)理，在你提交測(cè)試報(bào)告或測(cè)試評(píng)估報(bào)告之前先自己讀一遍。好的測(cè)試bug描述是告訴讀者測(cè)試人員發(fā)現(xiàn)了什么，而不是測(cè)試人員做了什么。因此只需要根據(jù)上述步驟寫(xiě)下最少的必需重現(xiàn)步驟如何提交bug一個(gè)好的錯(cuò)誤跟蹤系統(tǒng)包括了錯(cuò)誤的必要信息，如果做得不好，會(huì)造成迷惑，并誤導(dǎo)讀者。

好的故障描述應(yīng)該包括十個(gè)基本部分：標(biāo)題、項(xiàng)目、所屬模塊、優(yōu)先級(jí)、重要性、異常等級(jí)、可重復(fù)性、現(xiàn)象、操作過(guò)程和附件。標(biāo)題使用一兩句話來(lái)描述錯(cuò)誤，告訴經(jīng)理、開(kāi)發(fā)人員以及其他讀者為什么應(yīng)該關(guān)心該問(wèn)題。好的標(biāo)題應(yīng)該著重于出現(xiàn)的bug現(xiàn)象。但是過(guò)于簡(jiǎn)潔易引起誤導(dǎo)，使得原本重要的問(wèn)題被忽視。因此必須應(yīng)該采用簡(jiǎn)潔、切中要害的概要，這樣才能引起讀者的重視。不重要的就描述比較輕微，例如：“聯(lián)系人的email沒(méi)有檢查合法性”；重要的就要體現(xiàn)比較嚴(yán)重，例如：“填了運(yùn)營(yíng)商仍然提示運(yùn)營(yíng)商不能為空，使得無(wú)法進(jìn)行下一步的操作”，會(huì)更容易讓開(kāi)發(fā)人員理解究竟是什么問(wèn)題及其重要性，并及時(shí)處理。②項(xiàng)目是指該錯(cuò)誤屬于哪一個(gè)項(xiàng)目，歸哪個(gè)項(xiàng)目組解決，使不同的項(xiàng)目組看到和及時(shí)定位自己項(xiàng)目的錯(cuò)誤。③所屬模塊是指準(zhǔn)確說(shuō)明發(fā)異常等級(jí)生錯(cuò)誤的模塊，切忌發(fā)生錯(cuò)誤指派模塊，導(dǎo)致后續(xù)流程錯(cuò)誤；④優(yōu)先級(jí)分為以下4級(jí)：1級(jí)：“馬上解決”，表示問(wèn)題必須馬上解決，否則系統(tǒng)根本無(wú)法達(dá)到預(yù)定的需求；2級(jí)：“高度重視”，表示有時(shí)間就要馬上解決，否則系統(tǒng)偏離需求較大或預(yù)定功能不能正常實(shí)現(xiàn)；3級(jí)：“正常處理”，即進(jìn)入個(gè)人計(jì)劃解決，表示問(wèn)題不影響需求的實(shí)現(xiàn)，但是影響其他使用方面，比如頁(yè)面調(diào)用出錯(cuò)，調(diào)用了錯(cuò)誤的數(shù)據(jù)庫(kù)等；4級(jí)：“低優(yōu)先級(jí)”，即問(wèn)題在系統(tǒng)發(fā)布以前必須確認(rèn)解決或確認(rèn)可以不予解決。⑤重要性分為以下5級(jí)：1級(jí)：“非常嚴(yán)重”，表示缺陷不修改整個(gè)系統(tǒng)流程不能繼續(xù)；2級(jí)：“比較嚴(yán)重”，表示缺陷不修改不影響系統(tǒng)其他流程，但是本模塊流程不能繼續(xù)；3級(jí)：“一般”，表示缺陷不影響流程；4級(jí)：“輕微”，表示缺陷可以延期解決；5級(jí)：“優(yōu)化”，表示修改以后流程會(huì)更好。⑥異常等級(jí)有以下5級(jí)：系統(tǒng)崩潰－指該錯(cuò)誤使得操作系統(tǒng)死機(jī)等致命性的錯(cuò)誤；應(yīng)用程序崩潰－指該錯(cuò)誤使得測(cè)試程序崩潰，即無(wú)任何反應(yīng)；應(yīng)用程序異常－指錯(cuò)誤使得應(yīng)用程序結(jié)果不符合邏輯或是最初的需求；輕微異常－指錯(cuò)誤有，但是無(wú)傷大雅，例如錯(cuò)別字等；建議－指改進(jìn)后更好，不改進(jìn)也對(duì)程序無(wú)礙。⑦可重復(fù)性是針對(duì)問(wèn)題是否通過(guò)執(zhí)行“操作步驟”就可以重新出現(xiàn)，如果是就“可再現(xiàn)”；如果這個(gè)bug只出現(xiàn)了一次，就再也不出現(xiàn)了，稱這類問(wèn)題為“不可再現(xiàn)”；其余的就是“未知”，如每隔幾天才出現(xiàn)一次；⑧現(xiàn)象是對(duì)標(biāo)題的詳細(xì)描述，因?yàn)闃?biāo)題不宜過(guò)長(zhǎng)，所以現(xiàn)象也是對(duì)標(biāo)題的具體化。⑨操作過(guò)程是指對(duì)于可重現(xiàn)的bug，執(zhí)行這些操作步驟就可以出現(xiàn)該bug；對(duì)于不可重現(xiàn)和重現(xiàn)概率為未知的bug，通過(guò)備份的數(shù)據(jù)庫(kù)和操作過(guò)程就可以重現(xiàn)該bug。⑩附件是粘貼必要的附件，如果是可重復(fù)性是“可重現(xiàn)”的bug，則可以參考步驟是否復(fù)雜，如果很復(fù)雜，則可以粘貼附件，從而使得開(kāi)發(fā)人員直接可以明白是什么問(wèn)題，提高開(kāi)發(fā)人員的修改效率；如果步驟不多有能夠重現(xiàn)，則可以不粘貼附件。如果可重復(fù)性是“不可再現(xiàn)”的，這種情況必須粘貼附件，以備份出現(xiàn)問(wèn)題后的情形；如果是未知的，也必須粘貼附件，因?yàn)殚_(kāi)發(fā)人員不可能把時(shí)間耗費(fèi)在等待bug的重現(xiàn)上1.5自動(dòng)化測(cè)試基礎(chǔ)測(cè)試生命周期測(cè)試生命周期大致有幾個(gè)階段：計(jì)劃、分析、設(shè)計(jì)、構(gòu)建、測(cè)試周期，最后測(cè)試實(shí)施，包括了測(cè)試需求的分析、測(cè)試計(jì)劃的提出、測(cè)試用例的設(shè)計(jì)、功能測(cè)試、系統(tǒng)測(cè)試、回歸測(cè)試、驗(yàn)收測(cè)試等等內(nèi)容?；貧w測(cè)試（RegressionTesting）不是一個(gè)特定的測(cè)試級(jí)別，只要對(duì)軟件代碼有修改，不論是修改錯(cuò)誤還是增加新的功能或是提高性能，原則上都要進(jìn)行回歸測(cè)試，以保證對(duì)代碼修改的正確性，確保代碼修改不會(huì)對(duì)其余部分帶來(lái)負(fù)面影響?；貧w測(cè)試作為軟件生命周期的一個(gè)組成部分，在整個(gè)軟件測(cè)試過(guò)程中占有很大的工作量比重，軟件開(kāi)發(fā)的各個(gè)階段都會(huì)進(jìn)行多次回歸測(cè)試。在極端編程方法中，更是要求每天都進(jìn)行若干次回歸測(cè)試。因此，通過(guò)選擇正確的回歸測(cè)試策略來(lái)改進(jìn)回歸測(cè)試的效率和有效性是非常有意義的。在實(shí)際工作中，回歸測(cè)試需要反復(fù)進(jìn)行，當(dāng)測(cè)試者一次又一次地完成相同的測(cè)試時(shí)，這些回歸測(cè)試將變得非常令人厭煩，而在大多數(shù)回歸測(cè)試需要手工完成的時(shí)候尤其如此，因此，需要通過(guò)自動(dòng)測(cè)試來(lái)實(shí)現(xiàn)重復(fù)的和一致的回歸測(cè)試。通過(guò)測(cè)試自動(dòng)化可以提高回歸測(cè)試效率。自動(dòng)化測(cè)試的優(yōu)勢(shì)腳本執(zhí)行的自動(dòng)化測(cè)試速度遠(yuǎn)遠(yuǎn)快于人工執(zhí)行測(cè)試的速度，縮短測(cè)試項(xiàng)目的時(shí)間。減少人力投入，保證產(chǎn)品能按時(shí)發(fā)布。甚至縮短研發(fā)周期，提前發(fā)布產(chǎn)品。并且在同樣的產(chǎn)品研發(fā)時(shí)間內(nèi)，能對(duì)