《網(wǎng)絡測試技術與應用》課件網(wǎng)絡測試與應用(第一部分)

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

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

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

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

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

開發(fā)前期出現(xiàn)錯誤的擴展計劃需求分析設計編碼測試AAB

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

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

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

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

232×232

＝264

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

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

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

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

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

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

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

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

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

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