軟件測試工程師必看的基礎(chǔ)知識要點(diǎn)

什么是測試用例？----------------------------------------------------測試用例（TestCase）是為某個(gè)特殊目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個(gè)程序路徑或核實(shí)是否滿足某個(gè)特定需求。測試用例（TestCase）目前沒有經(jīng)典的定義。比較通常的說法是：指對一項(xiàng)特定的軟件產(chǎn)品進(jìn)行測試任務(wù)的描述，體現(xiàn)測試方案、方法、技術(shù)和策略。內(nèi)容包括測試目標(biāo)、測試環(huán)境、輸入數(shù)據(jù)、測試步驟、預(yù)期結(jié)果、測試腳本等，并形成文檔。測試用例（TestCase）是將軟件測試的行為活動(dòng)做一個(gè)科學(xué)化的組織歸納．目的是能夠?qū)④浖y試的行為轉(zhuǎn)化成可管理的模式； 同時(shí)測試用例也是將測試具體量化的方法之一．灰盒測試灰盒測試，確實(shí)是介于白盒測試與黑盒測試之間的，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性，同時(shí)也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運(yùn)行狀態(tài)，有時(shí)候輸出是正確的，但內(nèi)部其實(shí)已經(jīng)錯(cuò)誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會(huì)很低，因此需要采取這樣的一種灰盒的方法?；液袦y試結(jié)合了白盒測試和黑盒測試的要素.它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評價(jià)應(yīng)用軟件的設(shè)計(jì)?；液袦y試由方法和工具組成，這些方法和工具取材于應(yīng)用程序的內(nèi)部知識和與之交互的環(huán)境，能夠用于黑盒測試以增強(qiáng)測試效率、錯(cuò)誤發(fā)現(xiàn)和錯(cuò)誤分析的效率。灰盒測試涉及輸入和輸出，但使用關(guān)于代碼和程序操作等通常在測試人員視野之外的信息設(shè)計(jì)測試。什么是測試計(jì)劃？測試計(jì)劃包含項(xiàng)目范圍內(nèi)的測試目的和測試目標(biāo)的有關(guān)信息。此外，測試計(jì)劃確定了實(shí)施和執(zhí)行測試時(shí)使用的策略，同時(shí)還確定了所需資源。定義一個(gè)測試項(xiàng)目的過程，以便能夠正確的度量和控制測試軟件測試類型有哪些？軟件測試是指使用人工或者自動(dòng)的手段來運(yùn)行或測定某個(gè)軟件產(chǎn)品系統(tǒng)的過程， 其目的是在于檢驗(yàn)是否滿足規(guī)定的需求或者弄清預(yù)期的結(jié)果與實(shí)際結(jié)果的區(qū)別。本文主要描述軟件測試的類型。軟件測試類型有哪些？-----------------------------------------------------------------------軟件測試是指使用人工或者自動(dòng)的手段來運(yùn)行或測定某個(gè)軟件產(chǎn)品系統(tǒng)的過程，的是在于檢驗(yàn)是否滿足規(guī)定的需求或者弄清預(yù)期的結(jié)果與實(shí)際結(jié)果的區(qū)別。本文主要描述軟件測試的類型。

其目1.數(shù)據(jù)和數(shù)據(jù)庫完整性測試數(shù)據(jù)與數(shù)據(jù)庫完整測試是指測試關(guān)系型數(shù)據(jù)庫完整性原則以及數(shù)據(jù)合理性測試。數(shù)據(jù)庫完整性原即：主碼完整性：主碼不能為空；外碼完整性：外碼必須等于對應(yīng)的主碼或者為空。數(shù)據(jù)合理性指數(shù)據(jù)在數(shù)據(jù)庫中的類型，長度，索引等是否建的比較合理。在項(xiàng)目名稱中，數(shù)據(jù)庫和數(shù)據(jù)庫進(jìn)程應(yīng)作為一個(gè)子系統(tǒng)來進(jìn)行測試。在測試這些子系統(tǒng)時(shí)，不應(yīng)將測試對象的用戶界面用作數(shù)據(jù)的接口。對于數(shù)據(jù)庫管理系統(tǒng)(DBMS)，還需要進(jìn)行深入的研究，以確定可以支1持測試的工具和技術(shù)。比如，有兩張表：部門和員工。部門中有部門編號，部門名稱，部門經(jīng)理等字段，主碼為部門編號；員工表中有員工編號，員工所屬部門編號，員工名稱，員工類型等字段，主碼為員工編號，外碼為員工所屬部門編號，對應(yīng)部門表。如果在某條部門記錄中部門編號或員工記錄員工編號為空，他就違反主碼完整性原則。如果某個(gè)員工所屬部門的編號為##，但是##在部門編號中確找不到，這就違反外碼完整性原則。Int

員工類型如下定義：0：職工，1：職員，2：實(shí)習(xí)生。但數(shù)據(jù)類型為占有4個(gè)字節(jié)，如果定義成char(1).就比原來節(jié)約空間。

Int，我們都知道2.白盒測試白盒測試是基于代碼的測試， 測試人員通過閱讀程序代碼或者通過使用開發(fā)工具中的單步調(diào)試來判斷軟件的質(zhì)量，一般黑盒測試由項(xiàng)目經(jīng)理在程序員開發(fā)中來實(shí)現(xiàn)。白盒測試分為動(dòng)態(tài)白盒測試和靜態(tài)白盒測試2.1靜態(tài)白盒測試?yán)醚劬?，瀏覽代碼，憑借經(jīng)驗(yàn)，找出代碼中的錯(cuò)誤或者代碼中不符合書寫規(guī)范的地方。比如，代碼規(guī)范中規(guī)定，函數(shù)必須為動(dòng)賓結(jié)構(gòu)。而黑盒測試發(fā)現(xiàn)一個(gè)函數(shù)定義如下：FunctionNameGet(){.}這是屬于不符合開發(fā)規(guī)范的錯(cuò)誤。有這樣一段代碼:if(i<0)&(i>=0)這段代碼交集為整個(gè)數(shù)軸， IF語句沒有必要I=0;while(I>100){J=J+100;T=J*PI;}在循環(huán)體內(nèi)沒有 I的增加,bug產(chǎn)生。2.2動(dòng)態(tài)白盒測試?yán)瞄_發(fā)工具中的調(diào)式工具進(jìn)行測試。比如一段代碼有 4個(gè)分支，輸入 4組不同的測試數(shù)據(jù)使4組分支都可以走通而且結(jié)果必須正確?？匆欢未aif(I<0){P1}else{P2}在調(diào)試中輸入 I=-1,P1程序段通過， P2程序段未通過，屬于動(dòng)態(tài)黑盒測試的缺陷3.功能測試功能測試指測試軟件各個(gè)功能模塊是否正確，邏輯是否正確。對測試對象的功能測試應(yīng)側(cè)重于所有可直接追蹤到用例或業(yè)務(wù)功能和業(yè)務(wù)規(guī)則的測試需求。這種測試的目標(biāo)是核實(shí)數(shù)據(jù)的接受、處理和檢索是否正確，以及業(yè)務(wù)規(guī)則的實(shí)施是否恰當(dāng)。此類測試基于黑盒技術(shù)，該技術(shù)通過圖形用戶界面(GUI)與應(yīng)用程序進(jìn)行交互，并對交互的輸出或結(jié)果進(jìn)行分析，以此來核實(shí)應(yīng)用程序及其內(nèi)部進(jìn)程。功能測試的主要參考為類似于功能說明書之類的文檔。比如一個(gè)對電子商務(wù)系統(tǒng)，前臺用戶瀏覽商品-放入購物車-進(jìn)入結(jié)賬臺，后臺處理訂單，配貨，付款，發(fā)貨，這一系列流程必須正確無誤的走通，不能存在任何的錯(cuò)誤。4.UI測試UI測試指測試用戶界面的風(fēng)格是否滿足客戶要求， 文字是否正確，頁面美工是否好看，文字，圖片組合是否完美，背景是否美觀，操作是否友好等等用戶界面 (UI)測試用于核實(shí)用戶與軟件之間的交互。 UI測試的目標(biāo)是確保用戶界面會(huì)通過測試對象的功能來為用戶提供相應(yīng)的訪問或?yàn)g覽功能。另外， UI測試還可確保 UI中的對象按照預(yù)期的方式運(yùn)行，并符合公司或行業(yè)的標(biāo)準(zhǔn)。包括用戶友好性，人性化，易操作性測試。UI測試比較主觀，與測試人員的喜好有關(guān)比如：頁面基調(diào)顏色刺眼；用戶登入頁面比較難于找到，文字中出現(xiàn)錯(cuò)別字，頁面圖片范圍太廣等都屬于 UI測試中的缺陷，但是這些缺陷都不太嚴(yán)重。5.性能測試性能測試主要測試軟件測試的性能，包括負(fù)載測試，強(qiáng)度測試，數(shù)據(jù)庫容量測試，基準(zhǔn)測試以及基準(zhǔn)測試5.1負(fù)載測試負(fù)載測試是一種性能測試指數(shù)據(jù)在超負(fù)荷環(huán)境中運(yùn)行，程序是否能夠承擔(dān)。在這種測試中，將使測試對象承擔(dān)不同的工作量，以評測和評估測試對象在不同工作量條件下的性能行為，以及持續(xù)正常運(yùn)行的能力。負(fù)載測試的目標(biāo)是確定并確保系統(tǒng)在超出最大預(yù)期工作量的情況下仍能正常運(yùn)行。此外，負(fù)載測試還要評估性能特征，例如，響應(yīng)時(shí)間、事務(wù)處理速率和其他與時(shí)間相關(guān)的方面。比如，在B/S結(jié)構(gòu)中用戶并發(fā)量測試就是屬于負(fù)載測試的用戶，可以使用

webload

工具，模擬上百人客戶同時(shí)訪問網(wǎng)站，看系統(tǒng)響應(yīng)時(shí)間，處理速度如何？5.2強(qiáng)度測試強(qiáng)度測試是一種性能測試，他在系統(tǒng)資源特別低的情況下軟件系統(tǒng)運(yùn)行情況。這類測試往往可以書寫系統(tǒng)要求的軟硬件水平要求。實(shí)施和執(zhí)行此類測試的目的是找出因資源不足或資源爭用而導(dǎo)致的錯(cuò)誤。 如果內(nèi)存或磁盤空間不足，測試對象就可能會(huì)表現(xiàn)出一些在正常條件下并不明顯的缺陷。而其他缺陷則可能由于爭用共享資源（如數(shù)據(jù)庫鎖或網(wǎng)絡(luò)帶寬）而造成的。強(qiáng)度測試還可用于確定測試對象能夠處理的最大工作量。比如：一個(gè)系統(tǒng)在內(nèi)存 366M下可以正常運(yùn)行，但是降低到

258M

下不可以運(yùn)行，告訴內(nèi)存不足，這個(gè)系統(tǒng)對內(nèi)存的要求就是 366M。5.3數(shù)據(jù)庫容量測試數(shù)據(jù)庫容量測試指通過存儲(chǔ)過程往數(shù)據(jù)庫表中插入一定數(shù)量的數(shù)據(jù)，

看看相關(guān)頁面是否能夠及時(shí)顯示數(shù)據(jù)。數(shù)據(jù)庫容量測試使測試對象處理大量的數(shù)據(jù)，以確定是否達(dá)到了將使軟件發(fā)生故障的極限。容量測試還將確定測試對象在給定時(shí)間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。例如，如果測試對象正在為生成一份報(bào)表而處理一組數(shù)據(jù)庫記錄，那么容量測試就會(huì)使用一個(gè)大型的測試數(shù)據(jù)庫，檢驗(yàn)該軟件是否正常運(yùn)行并生成了正確的報(bào)表。做這種測試通常通過書寫存儲(chǔ)過程向數(shù)據(jù)庫某個(gè)表中插入一定數(shù)量的記錄，計(jì)算相關(guān)頁面的調(diào)用時(shí)間。比如，在電子商務(wù)系統(tǒng)中，通過 insertcustomer 往user表中插入10000數(shù)據(jù)，看其是否可以正常顯示顧客信息列表頁面， 如果要求達(dá)到最多可以處理 100000個(gè)客戶，但是顧客信息列表頁面不能夠在規(guī)定的時(shí)間內(nèi)顯示出來，就需要調(diào)整程序中的 SQL查詢語句；如果在規(guī)定的時(shí)間內(nèi)顯示出來，可以將用戶數(shù)分別提高到 20000,50000,100000進(jìn)行測試。5.4基準(zhǔn)測試基準(zhǔn)測試與已知現(xiàn)有的系統(tǒng)進(jìn)行比較，主要檢驗(yàn)是否與類似的產(chǎn)品具有競爭性的一種測試。如果你要開發(fā)一套財(cái)務(wù)系統(tǒng)軟件并且你已經(jīng)獲得用友財(cái)務(wù)系統(tǒng)的性能等數(shù)據(jù)， 你可以測試你這套系統(tǒng)，看看哪些地方比用友財(cái)務(wù)系統(tǒng)好，哪些地方差？以便改進(jìn)自己的系統(tǒng)，也可為產(chǎn)品廣告提供數(shù)據(jù)。5.5競爭測試軟件競爭使用各種資源（數(shù)據(jù)紀(jì)錄，內(nèi)存等），看他與其他相關(guān)系統(tǒng)對資源的爭奪能力。比如：一臺機(jī)器上即安裝您的財(cái)務(wù)系統(tǒng)，又安裝用友財(cái)務(wù)系統(tǒng)。當(dāng)CPU占有率下降后，看看是否能夠強(qiáng)過用友財(cái)務(wù)系統(tǒng)，而是自己的系統(tǒng)能夠正常運(yùn)行？安全性和訪問控制測試安全性和訪問控制測試側(cè)重于安全性的兩個(gè)關(guān)鍵方面：應(yīng)用程序級別的安全性，包括對數(shù)據(jù)或業(yè)務(wù)功能的訪問系統(tǒng)級別的安全性，包括對系統(tǒng)的登錄或遠(yuǎn)程訪問。6.1應(yīng)用程序級別的安全性可確保：在預(yù)期的安全性情況下，主角只能訪問特定的功能或用例，或者只能訪問有限的數(shù)據(jù)。例如，可能會(huì)允許所有人輸入數(shù)據(jù)，創(chuàng)建新賬戶，但只有管理員才能刪除這些數(shù)據(jù)或賬戶。如果具有數(shù)據(jù)級別的安全性，測試就可確?！坝脩纛愋鸵弧蹦軌蚩吹剿锌蛻粝ⅲòㄘ?cái)務(wù)數(shù)據(jù)），而“用戶二”只能看見同一客戶的統(tǒng)計(jì)數(shù)據(jù)。比如B/S系統(tǒng)，不通過登入頁面，直接輸入 URL,看其是否能夠進(jìn)入系統(tǒng)？6.2系統(tǒng)級別的安全性可確保只有具備系統(tǒng)訪問權(quán)限的用戶才能訪問應(yīng)用程序，而且只能通過相應(yīng)的網(wǎng)關(guān)來訪問。比如輸入管理員賬戶，檢查其密碼是否容易猜取，或者可以從數(shù)據(jù)庫中獲得？7.故障轉(zhuǎn)移和恢復(fù)測試故障轉(zhuǎn)移和恢復(fù)測試指當(dāng)主機(jī)軟硬件發(fā)生災(zāi)難時(shí)候，備份機(jī)器是否能夠正常啟動(dòng)，使系統(tǒng)是否可以正常運(yùn)行，這對于電信，銀行等領(lǐng)域的軟件是十分重要的。故障轉(zhuǎn)移和恢復(fù)測試可確保測試對象能成功完成故障轉(zhuǎn)移，并能從導(dǎo)致意外數(shù)據(jù)損失或數(shù)據(jù)完整性破壞的各種硬件、軟件或網(wǎng)絡(luò)故障中恢復(fù)。故障轉(zhuǎn)移測試可確保：對于必須持續(xù)運(yùn)行的系統(tǒng)，一旦發(fā)生故障，備用系統(tǒng)就將不失時(shí)機(jī)地“頂替”發(fā)生故障的系統(tǒng)，以避免丟失任何數(shù)據(jù)或事務(wù)。恢復(fù)測試是一種對抗性的測試過程。在這種測試中，將把應(yīng)用程序或系統(tǒng)置于極端的條件下（或者是模擬的極端條件下），以產(chǎn)生故障（例如設(shè)備輸入/輸出(I/O)故障或無效的數(shù)據(jù)庫指針和關(guān)健字）。然后調(diào)用恢復(fù)進(jìn)程并監(jiān)測和檢查應(yīng)用程序和系統(tǒng)，核實(shí)應(yīng)用程序或系統(tǒng)和數(shù)據(jù)已得到了正確的恢復(fù)。一定要注意主備定時(shí)備份比如電信系統(tǒng)，突然主機(jī)程序發(fā)生死機(jī)，備份機(jī)器是否能夠啟動(dòng)，使系統(tǒng)能夠正常運(yùn)行，從而不影響用戶打電話？8.配置測試又叫兼容性測試。配置測試核實(shí)測試對象在不同的軟件和硬件配置中的運(yùn)行情況。在大多數(shù)生產(chǎn)環(huán)境中， 客戶機(jī)工作站、網(wǎng)絡(luò)連接和數(shù)據(jù)庫服務(wù)器的具體硬件規(guī)格會(huì)有所不同?？蛻魴C(jī)工作站可能會(huì)安裝不同的軟件例如，應(yīng)用程序、驅(qū)動(dòng)程序等而且在任何時(shí)候，都可能運(yùn)行許多不同的軟件組合，從而占用不同的資源。（如瀏覽器版本，操作系統(tǒng)版本等）軟件測試 V模型－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－模型是最具有代表意義的測試模型V模型是軟件開發(fā)瀑布模型的變種，它反映了測試活動(dòng)與分析和設(shè)計(jì)的關(guān)系 。從左到右，描述了基本的開發(fā)過程和測試行為，非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系 。左邊依次下降的是開發(fā)過程各階段，與此相對應(yīng)的是右邊依次上升的部分，即各測試過程的各個(gè)階段。用戶需求 驗(yàn)收測試需求分析和系統(tǒng)設(shè)計(jì) 確認(rèn)測試和系統(tǒng)測試概要設(shè)計(jì) 集成測試詳細(xì)設(shè)計(jì) 單元測試編碼模型問題：1.測試是開發(fā)之后的一個(gè)階段。2.測試的對象就是程序本身。3.實(shí)際應(yīng)用中容易導(dǎo)致需求階段的錯(cuò)誤一直到最后系統(tǒng)測試階段才被發(fā)現(xiàn)。4.整個(gè)軟件產(chǎn)品的過程質(zhì)量保證完全依賴于開發(fā)人員的能力和對工作的責(zé)任心，而且上一步的結(jié)果必須是充分和正確的，如果任何一個(gè)環(huán)節(jié)出了問題，則必將嚴(yán)重的影響整個(gè)工程的質(zhì)量和預(yù)期進(jìn)度模型由Evolutif公司公司提出，相對于V模型，W模型增加了軟件各開發(fā)階段中應(yīng)同步進(jìn)行的驗(yàn)證和確認(rèn)活動(dòng)。W模型由兩個(gè)V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。模型強(qiáng)調(diào)：測試伴隨著整個(gè)軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設(shè)計(jì)等同樣要測試，也就是說，測試與開發(fā)是同步進(jìn)行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后， 測試人員就應(yīng)該參與到對需求的驗(yàn)證和確認(rèn)活動(dòng)中，以盡早地找出缺陷所在。同時(shí)，對需求的測試也有利于及時(shí)了解項(xiàng)目難度和測試風(fēng)險(xiǎn)，及早制定應(yīng)對措施，這將顯著減少總體測試時(shí)間，加快項(xiàng)目進(jìn)度。 但W模型也存在局限性。在 W模型中，需求、設(shè)計(jì)、編碼等活動(dòng)被視為串行的，同時(shí)，測試和開發(fā)活動(dòng)也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個(gè)階段工作。這樣就無法支持迭代的開發(fā)模型。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，模型并不能解除測試管理面臨著困惑。什么是開發(fā)的缺陷管理 ?軟件中的缺陷(Defect或BUG)是軟件開發(fā)過程中的“副產(chǎn)品”。通常，缺陷會(huì)導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要。每一個(gè)軟件開發(fā)團(tuán)隊(duì)都必須知道如何妥善處理軟件中的缺陷，這關(guān)系到軟件生存、發(fā)展的質(zhì)量根本?？蛇z憾的是，并非所有的軟件開發(fā)團(tuán)隊(duì)都知道如何有效地管理軟件中的缺陷。軟件缺陷管理是在軟件生命周期中為確保缺陷被跟蹤和管理所進(jìn)行的活動(dòng)。狹義地講，BUG是寫程序過程中造成的錯(cuò)誤。廣義地講， BUG是影響客戶正常使用的任何問題。就是說，BUG不僅僅是編程中出現(xiàn)的問題，還包括客戶需求和功能規(guī)范等方面。(1)缺陷管理的目標(biāo)一般而言，缺陷的跟蹤和管理需要達(dá)到以下兩個(gè)目標(biāo)：一是確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠被解決，二是收集缺陷數(shù)據(jù)并根據(jù)缺陷趨勢曲線識別和預(yù)防缺陷的頻繁發(fā)生。在談到缺陷管理時(shí)，一般人都會(huì)只想到如何修正缺陷，而對根據(jù)缺陷分析進(jìn)行有效預(yù)防缺陷卻很容易忽視。其實(shí)，在一個(gè)運(yùn)行良好的項(xiàng)目開發(fā)中，缺陷數(shù)據(jù)的收集和分析是很重要的，從缺陷數(shù)據(jù)中可以得到很多與軟件質(zhì)量相關(guān)的數(shù)據(jù)。例如通過缺陷趨勢曲線來確定測試過程是否結(jié)束是常用并且較為有效的一種方式。常見的的缺陷數(shù)據(jù)統(tǒng)計(jì)圖表包括缺陷趨勢圖、缺陷分布圖、缺陷及時(shí)處理情況統(tǒng)計(jì)表等。(2)缺陷管理重在預(yù)防缺陷正如我們所知，BUG應(yīng)該盡早地在開發(fā)過程中被發(fā)現(xiàn)。修正處于開發(fā)階段的BUG的成本遠(yuǎn)遠(yuǎn)低于修正處于驗(yàn)收階段的BUG，而相對與修正已經(jīng)發(fā)布給客戶的產(chǎn)品BUG的成本更是可以忽略不計(jì)。因此，越晚修正 BUG，需要重做的事情就越多。對很多人來說，零缺陷的軟件產(chǎn)品似乎是不切實(shí)際的。因此，我們總是聽到許多軟件開發(fā)人員說：“軟件永遠(yuǎn)有BUG”。軟件產(chǎn)品含有BUG并不奇怪，不幸的是發(fā)布一個(gè)包含很多BUG的產(chǎn)品給客戶仍然不讓人感到驚訝，這就是一件值提深思的事情了。事實(shí)上，每個(gè)軟件開發(fā)團(tuán)隊(duì)都可以通過一些簡單的方法，在不增加額外資源的情況下預(yù)防BUG。為了能夠預(yù)防 BUG，我們首先需要了解 BUG的來源。軟件BUG可以分為幾個(gè)類別：第一類BUG可能是隨機(jī)的，它們通常是因?yàn)橐粫r(shí)的疏忽造成的。盡管這些BUG可能由于其隨機(jī)性很難預(yù)防。但是，適當(dāng)?shù)姆治鰧⒂兄诒苊膺@些BUG。另一類的BUG來自于需求誤解、開發(fā)環(huán)境的錯(cuò)誤或者純粹由于缺乏解決問題的相關(guān)技術(shù)，這類BUG共同的特點(diǎn)是都來自于開發(fā)人員。但有一個(gè)好消息是，軟件中的BUG往往傾向于重復(fù)出現(xiàn)，即使是一個(gè)隨機(jī)出現(xiàn)的 BUG。軟件BUG的不斷出現(xiàn)不僅表現(xiàn)在同一個(gè)開發(fā)人員的工作上，而且表現(xiàn)在同一個(gè)項(xiàng)目上。這當(dāng)然不是說項(xiàng)目中的每一個(gè)開發(fā)人員都會(huì)犯同樣的錯(cuò)誤。但是，至少其中一些的錯(cuò)誤足以成為經(jīng)常性出現(xiàn)的問題。因此， BUG的預(yù)防尤為重要。缺陷管理的核心：缺陷分析缺陷預(yù)防的著眼點(diǎn)在于缺陷的共性原因 (CommonCause)。通過尋找、分析和處理缺陷的共性原因，實(shí)現(xiàn)缺陷預(yù)防。 BUG預(yù)防并不是一個(gè)不切實(shí)際的目標(biāo)，但是不能期望它在一夜之間發(fā)生。我們在開發(fā)過程中應(yīng)該積極為開發(fā)小組提供缺陷分析，使 BUG逐漸改善。因此，缺陷管理的最終目標(biāo)是預(yù)防 BUG，不斷提高整個(gè)開發(fā)團(tuán)隊(duì)的技能和實(shí)踐經(jīng)驗(yàn)，而不只是修正它們。BUG預(yù)防策略非常簡單和容易實(shí)現(xiàn)，策略是發(fā)現(xiàn)BUG，找出BUG的根源，然后尋找一個(gè)方法來預(yù)防類似的BUG在將來出現(xiàn)。這策略并不需要昂貴的花費(fèi)，但是卻可帶來極大的額外價(jià)值。(1)BUG記錄BUG分析的第一步是記錄 BUG，值得注意的是記錄 BUG不應(yīng)該滿足于記錄 BUG的表面癥狀。測試的一個(gè)重要職責(zé)就是試圖發(fā)現(xiàn) BUG的根本原因，在測試時(shí)不應(yīng)將產(chǎn)品看作一個(gè)黑盒，而應(yīng)該像開發(fā)人員那樣了解產(chǎn)品的內(nèi)在，包括深入源代碼，理解產(chǎn)品的設(shè)計(jì)和實(shí)現(xiàn)。(2)利用BUG分析了解開發(fā)質(zhì)量趨勢對于測試出來的 BUG進(jìn)行缺陷分類，找出那些關(guān)鍵的缺陷類型，進(jìn)一步分析其產(chǎn)生的根源，從而針對性的制定改進(jìn)措施。缺陷分析非常關(guān)鍵的一步就是尋找一個(gè)預(yù)防類似缺陷再次發(fā)生的方法。這一方法不僅涉及到開發(fā)、測試人員，還涉及到不直接負(fù)責(zé)代碼編寫的資深開發(fā)人員。利用這一階段的實(shí)踐成果，開發(fā)人員可以預(yù)防 BUG的發(fā)生，而不僅僅是修正這些BUG。BUG預(yù)防分析是整個(gè) BUG分析過程的核心。這一階段總結(jié)出的實(shí)踐可以在更廣泛的范圍內(nèi)預(yù)防潛在的缺陷。由于分析結(jié)果的廣泛應(yīng)用性，分析某個(gè)具體 BUG的投入將很容易被收回。在這個(gè)時(shí)候，BUG分析提供了兩個(gè)非常重要的參數(shù)，一個(gè)是缺陷數(shù)量的趨勢，另一個(gè)是缺陷修復(fù)的趨勢。缺陷趨勢就是將每月新生成的缺陷數(shù)、每月被解決的缺陷數(shù)和每月遺留的缺陷數(shù)標(biāo)成一個(gè)趨勢圖表。一般在項(xiàng)目的開始階段發(fā)現(xiàn)缺陷數(shù)曲線會(huì)呈上升趨勢， 到項(xiàng)目中后期被修復(fù)缺陷數(shù)曲線會(huì)趨于上升，而發(fā)現(xiàn)缺陷數(shù)曲線應(yīng)總體趨于下降。同時(shí)處于OPEN狀態(tài)的缺陷也應(yīng)該總體呈下降趨勢，到項(xiàng)目最后，三條曲線都趨向于零。項(xiàng)目經(jīng)理可通過持續(xù)觀察這張圖表，確保項(xiàng)目開發(fā)健康發(fā)展。同時(shí)，通過分析預(yù)測項(xiàng)目測試缺陷趨于零的時(shí)間，以制定產(chǎn)品質(zhì)量驗(yàn)收和發(fā)布的時(shí)間。實(shí)際上，BUG分析圖表會(huì)告訴我們很多有價(jià)值的信息。比如說，可分析開發(fā)和測試在人力資源的配比上是否恰當(dāng)，可以分析出某個(gè)嚴(yán)重的缺陷所造成的項(xiàng)目質(zhì)量的波動(dòng)。對于異常的波動(dòng)，如本來應(yīng)該越測試越收斂的，卻到了某個(gè)點(diǎn)發(fā)現(xiàn)的故障數(shù)反而呈上升趨勢，那么意味著往往有一些特殊事件的發(fā)生。通過對測試缺陷分析，能夠給予我們很多改進(jìn)研發(fā)和測試工作的信息。什么是軟件測試中的缺陷度量？-------------------------------------------------------------------缺陷度量缺陷度量是軟件度量的一部分，其本身并不能發(fā)現(xiàn)缺陷、剔除缺陷，但是有助于這些問題的解決。另外，當(dāng)正確、持續(xù)地進(jìn)行了缺陷度量時(shí)，產(chǎn)品以及過程的質(zhì)量屬性的數(shù)據(jù)為實(shí)施和管理過程改進(jìn)活動(dòng)提供了有效的基礎(chǔ)。數(shù)據(jù)的質(zhì)量等因素，我們在本章 7.4節(jié)中已經(jīng)考慮了，這里仍將遵循。什么是缺陷度量軟件產(chǎn)品質(zhì)量度量，主要集中在軟件的缺陷度量上。缺陷度量就是對項(xiàng)目過程中產(chǎn)生的缺陷數(shù)據(jù)進(jìn)行采集和量化，將分散的缺陷數(shù)據(jù)統(tǒng)一管理，使其有序而清晰，然后通過采用一系列數(shù)學(xué)函數(shù)，對數(shù)據(jù)進(jìn)行處理，分析缺陷密度和趨勢等信息，從而提高產(chǎn)品質(zhì)量和改進(jìn)開發(fā)過程。一般來說，在軟件質(zhì)量保證過程中，需要度量的缺陷數(shù)據(jù)包括6大類缺陷發(fā)現(xiàn)手段發(fā)現(xiàn)的所有缺陷。如測試相關(guān)的缺陷，需要度量包括測試投入的工作量和成本數(shù)據(jù)、測試任務(wù)完成情況、測試規(guī)模數(shù)據(jù)、測試結(jié)果數(shù)據(jù)（包括缺陷數(shù)據(jù)、覆蓋率數(shù)據(jù)）等。1）組織級缺陷度量，目的是了解組織的整體缺陷情況，了解客戶對組織的質(zhì)量滿意度，建立組織基線，確定改進(jìn)活動(dòng)。2）項(xiàng)目級缺陷度量，目的是了解項(xiàng)目實(shí)時(shí)質(zhì)量情況（很多項(xiàng)目只在最后度量，包括那些迭代式開發(fā)的項(xiàng)目，實(shí)際上為時(shí)已晚），預(yù)測缺陷造成的發(fā)布后維護(hù)工作量，了解客戶對項(xiàng)目的質(zhì)量滿意度。3）個(gè)體缺陷度量，目的是了解個(gè)體缺陷產(chǎn)生的詳細(xì)原因，并實(shí)施行動(dòng)進(jìn)行改進(jìn)。前兩種度量大家接觸較多，但第三種度量常常被忽略。這常常導(dǎo)致：●項(xiàng)目反復(fù)得到關(guān)于自己的質(zhì)量評價(jià)，但很難了解如何去提高；●測試組常常能做一些改進(jìn)（如增加測試覆蓋、延長測試周期）來提高缺陷排除效率，但開發(fā)組沒有降低缺陷產(chǎn)生數(shù)量的有效措施；●軟件開發(fā)遵循了編碼規(guī)范，但似乎對提高質(zhì)量沒有太多幫助。什么是灰盒測試？------------------------------------------------------------------灰盒測試，確實(shí)是介于黑盒測試和白盒測試二者之間的，可以這樣理解，灰盒測試關(guān)注輸出對于輸入的正確性，同時(shí)也關(guān)注內(nèi)部表現(xiàn)，但這種關(guān)注不象白盒那樣詳細(xì)、完整，只是通過一些表征性的現(xiàn)象、事件、標(biāo)志來判斷內(nèi)部的運(yùn)行狀態(tài)，有時(shí)候輸出是正確的，但內(nèi)部其實(shí)已經(jīng)錯(cuò)誤了，這種情況非常多，如果每次都通過白盒測試來操作，效率會(huì)很低，因此需要采取這樣的一種灰盒的方法?；液袦y試結(jié)合了白盒測試盒黑盒測試的要素 .它考慮了用戶端、特定的系統(tǒng)知識和操作環(huán)境。它在系統(tǒng)組件的協(xié)同性環(huán)境中評價(jià)應(yīng)用軟件的設(shè)計(jì)?；液袦y試由方法和工具組成，這些方法和工具取材于應(yīng)用程序的內(nèi)部知識盒與之交互的環(huán)境，能夠用于黑盒測試以增強(qiáng)測試效率、錯(cuò)誤發(fā)現(xiàn)和錯(cuò)誤分析的效率。灰盒測試涉及輸入和輸出，但使用關(guān)于代碼和程序操作等通常在測試人員視野之外的信息設(shè)計(jì)測試。軟件測試用例設(shè)計(jì)綜合策略--------------------------------------------------------------------Myers提出了使用各種測試方法的綜合策略：1)在任何情況下都必須使用邊界值分析方法，經(jīng)驗(yàn)表明用這種方法設(shè)計(jì)出測試用例發(fā)現(xiàn)程序錯(cuò)誤的能力最強(qiáng)。2)必要時(shí)用等價(jià)類劃分方法補(bǔ)充一些測試用例。3)用錯(cuò)誤推測法再追加一些測試用例。4)對照程序邏輯，檢查已設(shè)計(jì)出的測試用例的邏輯覆蓋程度，如果沒有達(dá)到要求的覆蓋標(biāo)準(zhǔn)，應(yīng)當(dāng)再補(bǔ)充足夠的測試用例。5)如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法。2.測試用例的設(shè)計(jì)步驟1)構(gòu)造根據(jù)設(shè)計(jì)規(guī)格得出的基本功能測試用例；2)邊界值測試用例；3)狀態(tài)轉(zhuǎn)換測試用例；4)錯(cuò)誤猜測測試用例；5)異常測試用例；6)性能測試用例；7)壓力測試用例。3.優(yōu)化測試用例的方法1)利用設(shè)計(jì)測試用例的 8種方法不斷的對測試用例進(jìn)行分解與合并；2)采用遺傳算法理論進(jìn)化測試用例；3)在測試時(shí)利用發(fā)散思維構(gòu)造測試用例。什么是軟件測試框架------------------------------------------------------------------------測試框架是一組自動(dòng)化測試的規(guī)范、測試腳本的基礎(chǔ)代碼，以及測試思想、慣例的集合。可用于減少冗余代碼、提高代碼生產(chǎn)率、提高代碼重用性和可維護(hù)性。測試框架的好處在于：提高開發(fā)速度，提升測試代碼的執(zhí)行效率；提高軟件代碼質(zhì)量，同時(shí)引入重構(gòu)概念，讓代碼更干凈和富有彈性；提升系統(tǒng)的可信賴度，作為回歸測試的一種實(shí)現(xiàn)方法支持修復(fù)后“再測試”，確保代碼的正確性。常用的測試框架分類包括自動(dòng)化測試框架和單元測試框架。根據(jù)所用開發(fā)平臺不同，也可使用不同的測試框架展開測試。什么是靜態(tài)測試--------------------------------------------------------------------靜態(tài)測試，英文是 StaticTesting。靜態(tài)測試指測試不運(yùn)行的部分，例如測試產(chǎn)品說明書，對此進(jìn)行檢查和審閱 .。靜態(tài)方法是指不運(yùn)行被測程序本身，僅通過分析或檢查源程序的文法、結(jié)構(gòu)、過程、接口等來檢查程序的正確性。靜態(tài)方法通過程序靜態(tài)特性的分析，找出欠缺和可疑之處，例如不匹配的參數(shù)、不適當(dāng)?shù)难h(huán)嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計(jì)算等。靜態(tài)測試結(jié)果可用于進(jìn)一步的查錯(cuò)，并為測試用例選取提供指導(dǎo)。靜態(tài)測試常用工具有： Logiscope、PRQA；靜態(tài)測試技術(shù) --代碼走查、代碼審查和技術(shù)評審---------------------------------------------------------------------靜態(tài)測試又可分為代碼走查（ Walkthrough），代碼審查(Inspection)，技術(shù)評審(Review)。代碼走查（Walkthrough）開發(fā)組內(nèi)部進(jìn)行的，采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。代碼審查 (Inspection)開發(fā)組內(nèi)部進(jìn)行的，采用講解、提問并使用編碼模板進(jìn)行的查找錯(cuò)誤的活動(dòng)。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。技術(shù)評審(Review)開發(fā)組、測試組和相關(guān)人員(QA、產(chǎn)品經(jīng)理等)聯(lián)合進(jìn)行的，采用講解、提問并使用編碼模板進(jìn)行的查找錯(cuò)誤的活動(dòng)。一般有正式的計(jì)劃、流程和結(jié)果報(bào)告。實(shí)際工作，我們完全不必要被概念所束縛住，根據(jù)項(xiàng)目的實(shí)際情況來決定采取什么的靜態(tài)測試形式，不用嚴(yán)格去區(qū)分到底是代碼走查，代碼審查和還是技術(shù)評審。靜態(tài)分析往往需要借助白盒測試工具（如 Logiscope,C++Test）來自動(dòng)檢測。什么是代碼走查------------------------------------------------------------------代碼走查(codewalkthrough)和代碼審查(codeinspection)是兩種不同的代碼評審方法 ,代碼審查是一種正式的評審活動(dòng)，而代碼走查的討論過程是非正式的。最近對項(xiàng)目組進(jìn)行代碼評審，發(fā)覺需要對代碼評審中找到的問題進(jìn)行一下分類，大概可以分成以下幾類問題：1.Comment注釋沒寫，或者格式不對，或者毫無意義2.CodingStandard沒遵守代碼規(guī)范3.ExistingWheel重復(fù)現(xiàn)成的代碼，或者是開源項(xiàng)目，或者公司已有代碼4.BetterpracticeJava或者開源項(xiàng)目，有更好的寫法5.PerformancebottleandImprovement性能瓶頸和提高6.CodeLogicError代碼邏輯錯(cuò)誤7.BusinessLogicError業(yè)務(wù)邏輯錯(cuò)誤代碼審查列出問題的類型，并有解決情況報(bào)告首先我們要明確為什么要進(jìn)行代碼走查活動(dòng)，我以為其目的主要有：1）、通過代碼走查活動(dòng)，及時(shí)了解程序員編寫的代碼是否符合設(shè)計(jì)要求以及編碼規(guī)范；2）、通過代碼走查活動(dòng)，及時(shí)了解程序員在編碼過程中遇到的問題，并給以協(xié)助，從而達(dá)到有效、透明地掌控項(xiàng)目進(jìn)度的目的；3）、通過代碼走查活動(dòng)，及時(shí)了解代碼中可以重用的代碼，并將其提取為公共方法或模塊，提高代碼的可重用性以彌補(bǔ)當(dāng)前人員設(shè)計(jì)能力不足的現(xiàn)狀。要滿足上面的三個(gè)目的，顯然僅僅依靠工具是不能夠滿足要求的。那么如何執(zhí)行代碼走查活動(dòng)才會(huì)有效呢？首先，在系統(tǒng)設(shè)計(jì)階段，我們需要明確系統(tǒng)架構(gòu)、編碼規(guī)范等技術(shù)要求，來制定出代碼走查活動(dòng)需要的 Checklist（對于編碼規(guī)范，當(dāng)可以利用工具來進(jìn)行檢查時(shí)， 準(zhǔn)備的Checklist中就不需要將工具可以檢查的要點(diǎn)再逐一列出來。）下圖就是一個(gè) Checklist的示例。第二步是確定代碼走查時(shí)發(fā)現(xiàn)問題的記錄方式?？梢允褂梦臋n的方式來記錄（這在很多項(xiàng)目中使用），也可以使用缺陷跟蹤系統(tǒng)來記錄。當(dāng)準(zhǔn)備工作完成，且項(xiàng)目進(jìn)入 Coding階段后，我們就可以正式開始執(zhí)行代碼走查活動(dòng)了。為了改變以前那種事后檢查的弊端，我們將代碼走查活動(dòng)前移到與程序員的 Coding同步進(jìn)行。這樣做就是為了及時(shí)發(fā)現(xiàn)問題及時(shí)解決問題。實(shí)施的步驟如下：1）、負(fù)責(zé)代碼走查的人員從建構(gòu)庫中獲取需要走查的代碼；2）、閱讀代碼，并根據(jù)前面準(zhǔn)備好的 Checklist對代碼進(jìn)行檢查，看代碼是否符合相關(guān)的技術(shù)要求，以及是否滿足業(yè)務(wù)需求，發(fā)現(xiàn)的問題及時(shí)記錄下來；TIPS:通常可以在閱讀代碼之前或者閱讀完代碼之后，利用工具來進(jìn)行必要的 Check。可以利用的工具有： Checkstyle,CodePro,FindBugs,Metrics,JDepend等等。3）、閱讀代碼的過程中，如果發(fā)現(xiàn)有可供提取的可重用方法或模塊，及時(shí)記錄并通報(bào)給項(xiàng)目的架構(gòu)負(fù)責(zé)人，由其負(fù)責(zé)可重用方法的編寫；4）、及時(shí)向程序員通報(bào)代碼走查的結(jié)果，并由程序員對發(fā)現(xiàn)的問題進(jìn)行修改。必要時(shí)對代碼走查中發(fā)現(xiàn)的問題需及時(shí)向程序員進(jìn)行講解和指導(dǎo)；5）、跟蹤代碼走查中發(fā)現(xiàn)的問題的解決進(jìn)展，直到問題均關(guān)閉；6）、每日重復(fù)以上的步驟，直到所有功能的編碼全部結(jié)束為止。通過以上代碼走查活動(dòng)的說明，可看出代碼走查人員在項(xiàng)目中承擔(dān)著比較重要的角色。因此安排合適的人來進(jìn)行代碼走查也顯得格外重要，可以說直接關(guān)系著代碼走查活動(dòng)的最終成效。通常我們可考慮安排功能的設(shè)計(jì)者來負(fù)責(zé)該功能的代碼走查。這樣有幾個(gè)好處：一是功能的設(shè)計(jì)者對于功能的業(yè)務(wù)需求比較清楚，這樣在做代碼走查時(shí)就容易了解程序員編寫的代碼是否能夠滿足設(shè)計(jì)的要求和業(yè)務(wù)需求。其實(shí)從另外一個(gè)角度來看也是對設(shè)計(jì)的一種檢查；二是通常功能的設(shè)計(jì)者都是較資深的人員，可以為程序員提供有效地指導(dǎo)和協(xié)助，從另外一個(gè)角度也是對程序員的On-JobTraining。在實(shí)施代碼走查的過程中，我們還需要借助工具來提高我們的效率，但切忌過分依賴工具或者僅僅只靠工具。同時(shí)也需要轉(zhuǎn)變?yōu)榱舜a走查而代碼走查的傾向，因?yàn)槟菢泳筒荒馨l(fā)揮代碼走查的作用，并最終達(dá)到代碼走查的目的。從實(shí)踐來看，代碼走查時(shí)記錄問題的方式也影響到代碼走查的效率。這里向大家介紹一個(gè)在Eclipse中進(jìn)行代碼走查的插件——Jupiter。它提供了一種簡單而便捷的方式來記錄和跟蹤代碼走查時(shí)發(fā)現(xiàn)的問題。Jupiter將走查結(jié)果以 XML文件的形式存入 SCM系統(tǒng)中，并且每條代碼走查的意見直接關(guān)聯(lián)對應(yīng)代碼，可以做方便的代碼跳轉(zhuǎn)。最新的安裝包可以在 Jupiter的網(wǎng)站上下載到：/tools/jupiter下圖是Eclipse中安裝Jupiter后的界面。在項(xiàng)目中使用

Jupiter時(shí)，需要先進(jìn)行配置。所有配置信息都保存在一個(gè)

.jupiter

文件中，并需將之提交到

SCM系統(tǒng)。配置完成后，可按照以下步驟來使用：1）、個(gè)人走查（IndividualPhase）代碼走查者在本地對代碼進(jìn)行走查，然后建立相關(guān)的ReviewIssue。走查結(jié)果會(huì)自動(dòng)保存在一個(gè)以.review為擴(kuò)展名的XML文件中。該文件保存在Eclipse項(xiàng)目所在目錄的某個(gè)子目錄下，通常是項(xiàng)目根目錄下的Review子目錄。走查完畢，走查者需將.review文件提交到SCM系統(tǒng)。2）、團(tuán)隊(duì)走查（

TeamPhase）個(gè)人更新本地工程以獲得其他走查者的

.review

文件，然后選擇“

TeamPhase”。這樣，所有在個(gè)人走查階段建立的

ReviewIssue都將會(huì)在本地呈現(xiàn)。此階段主要完成問題的分析與指派。 最后，將修改后的全部.review文件重新提交到 SCM系統(tǒng)。3）、修改階段（ReworkPhase）被查代碼的所有者，根據(jù)走查者的意見對代碼做出修改，然后修改 ReviewIssue的狀態(tài)。由于使用Jupiter建立境下，相比較而言，我們記錄相對應(yīng)。

ReviewIssue是可以與代碼關(guān)聯(lián)的，并且是在 Eclipse的集成環(huán)Issue就會(huì)更加方便，而修改代碼時(shí)也更容易將 Issue與代碼按照以上介紹的方法來進(jìn)行代碼走查的項(xiàng)目，在代碼品質(zhì)上都有了普遍地提高。那么，你所在的項(xiàng)目呢？行動(dòng)起來，相信代碼走查這個(gè)錦囊能夠?yàn)槟愕捻?xiàng)目走向成功奠定一個(gè)很好的基礎(chǔ)。根據(jù)有關(guān)職位統(tǒng)計(jì)資料顯示，在國外大多數(shù)軟件公司， 1個(gè)軟件開發(fā)工程師就需要輔有 2個(gè)軟件測試工程師。目前，軟件測試自動(dòng)化技術(shù)在我國則剛剛被少數(shù)業(yè)內(nèi)專家所認(rèn)知，而這方面的專業(yè)技術(shù)人員在國內(nèi)更是鳳毛麟角。根據(jù)對近期網(wǎng)絡(luò)招聘 IT人才情況的了解，許多正在招聘軟件測試工程師的企業(yè)很少能夠在招聘會(huì)上順利招到合適的人才。隨著中國IT行業(yè)的發(fā)展，產(chǎn)品的質(zhì)量控制與質(zhì)量管理正逐漸成為企業(yè)生存與發(fā)展的核心。從軟件、硬件到系統(tǒng)集成，幾乎每個(gè)中大型 IT企業(yè)的產(chǎn)品在發(fā)布前都需要大量的質(zhì)量控制、測試和文檔工作，而這些工作必須依靠擁有嫻熟技術(shù)的專業(yè)軟件人才來完成。而軟件測試工程師就是其中之一。據(jù)了解，由于軟件測試工程師處于重要崗位，所以必須具有電子、電機(jī)類相關(guān)專業(yè)知識背景，并且還應(yīng)有兩年以上的實(shí)際操作經(jīng)驗(yàn)。他們應(yīng)熟悉中國和國際軟件測試標(biāo)準(zhǔn)，熟練掌握和操作國際流行的系列軟件測試工具，能夠承擔(dān)比較復(fù)雜的軟件分析、測試、品質(zhì)管理等任務(wù)，并能獨(dú)立擔(dān)任測試、品質(zhì)管理部門的負(fù)責(zé)人。一般情況，軟件測試工程師可分為測試工程師、高級測試工程師和資深測試工程師三個(gè)等級。在具體工作過程中，測試工程師的工作是利用測試工具按照測試方案和流程對產(chǎn)品進(jìn)行功能和性能測試，甚至根據(jù)需要編寫不同的測試工具，設(shè)計(jì)和維護(hù)測試系統(tǒng)，對測試方案可能出現(xiàn)的問題進(jìn)行分析和評估。對軟件測試工程師而言，必須具有高度的工作責(zé)任心和自信心。任何嚴(yán)格的測試必須是一種實(shí)事求是的測試，因?yàn)樗P(guān)系到一個(gè)產(chǎn)品的質(zhì)量問題，而測試工程師則是產(chǎn)品出貨前的把關(guān)人，所以，沒有專業(yè)的技術(shù)水準(zhǔn)是無法勝任這項(xiàng)工作的。同時(shí)，由于測試工作一般由多個(gè)測試工程師共同完成，并且測試部門一般要與其他部門的人員進(jìn)行較多的溝通，所以要求測試工程師不但要有較強(qiáng)的技術(shù)能力而且要有較強(qiáng)的溝通能力。什么是軟件性能-----------------------------------------------------------------------------------------------------------軟件的性能是軟件的一種非功能特性，它關(guān)注的不是軟件是否能夠完成特定的功能，而是在完成該功能時(shí)展示出來的及時(shí)性。由于感受軟件性能的主體是人，不同的人對于同樣的軟件能有不同的主觀感受，而且不同的人對于軟件性能關(guān)心的視角也不同。由于目前網(wǎng)絡(luò)應(yīng)用非常普遍，因此下面將介紹網(wǎng)絡(luò)應(yīng)用軟件性能的指標(biāo)和軟件性能的視角。1.軟件性能的指標(biāo)（1）響應(yīng)時(shí)間響應(yīng)時(shí)間是指系統(tǒng)對請求作出響應(yīng)的時(shí)間。直觀上看，這個(gè)指標(biāo)與人對軟件性能的主觀感受是非常一致的，因?yàn)樗暾赜涗浟苏麄€(gè)計(jì)算機(jī)系統(tǒng)處理請求的時(shí)間。由于一個(gè)系統(tǒng)通常會(huì)提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應(yīng)時(shí)間也不盡相同，甚至同一功能在不同輸入數(shù)據(jù)的情況下響應(yīng)時(shí)間也不相同。所以，在討論一個(gè)系統(tǒng)的響應(yīng)時(shí)間時(shí)，人們通常是指該系統(tǒng)所有功能的平均時(shí)間或者所有功能的最大響應(yīng)時(shí)間。當(dāng)然，往往也需要對每個(gè)或每組功能討論其平均響應(yīng)時(shí)間和最大響應(yīng)時(shí)間。對于單機(jī)的沒有并發(fā)操作的應(yīng)用系統(tǒng)而言，人們普遍認(rèn)為響應(yīng)時(shí)間是一個(gè)合理且準(zhǔn)確的性能指標(biāo)。需要指出的是，響應(yīng)時(shí)間的絕對值并不能直接反映軟件的性能的高低，軟件性能的高低實(shí)際上取決于用戶對該響應(yīng)時(shí)間的接受程度。對于一個(gè)游戲軟件來說，響應(yīng)時(shí)間小于100毫秒應(yīng)該是不錯(cuò)的，響應(yīng)時(shí)間在1秒左右可能屬于勉強(qiáng)可以接受，如果響應(yīng)時(shí)間達(dá)到3秒就完全難以接受了。而對于編譯系統(tǒng)來說，完整編譯一個(gè)較大規(guī)模軟件的源代碼可能需要幾十分鐘甚至更長時(shí)間，但這些響應(yīng)時(shí)間對于用戶來說都是可以接受的。（2）系統(tǒng)響應(yīng)時(shí)間和應(yīng)用延遲時(shí)間雖然軟件性能指標(biāo)本身只涉及軟件性能的度量，但考慮到軟件性能測試的主要目的是測試和改善所開發(fā)軟件的性能，對于復(fù)雜的網(wǎng)絡(luò)化的軟件而言，簡單地用響應(yīng)時(shí)間進(jìn)行度量就不一定合適了?？紤]一個(gè)普通的網(wǎng)站系統(tǒng)。開發(fā)該網(wǎng)站系統(tǒng)時(shí)，軟件開發(fā)實(shí)際上只集中在服務(wù)器端，因?yàn)榭蛻舳说能浖菢?biāo)準(zhǔn)的瀏覽器。雖然用戶看到的響應(yīng)時(shí)間時(shí)使用特定客戶端計(jì)算機(jī)上的特定瀏覽器瀏覽該網(wǎng)站的響應(yīng)時(shí)間，但是在討論軟件性能時(shí)更關(guān)心所開發(fā)網(wǎng)站軟件本身的“響應(yīng)時(shí)間”。也就是說，可以把用戶感受到的響應(yīng)時(shí)間劃分為“呈現(xiàn)時(shí)間”和“系統(tǒng)響應(yīng)時(shí)間”，前者是指客戶端的瀏覽器在接收到網(wǎng)站數(shù)據(jù)時(shí)呈現(xiàn)頁面所需的時(shí)間，而后者是指客戶端接收到用戶請求到客戶端接收到服務(wù)器發(fā)來的數(shù)據(jù)所需的時(shí)間。顯然，軟件性能測試更關(guān)心“系統(tǒng)響應(yīng)時(shí)間”，因?yàn)椤俺尸F(xiàn)時(shí)間”與客戶端計(jì)算機(jī)和瀏覽器有關(guān)，而與所開發(fā)的網(wǎng)站軟件沒有太大的關(guān)系。如果仔細(xì)分析這個(gè)例子，還可以把“系統(tǒng)響應(yīng)時(shí)間”進(jìn)一步分解為“網(wǎng)絡(luò)傳輸時(shí)間”和“應(yīng)用延遲時(shí)間”，其中前者是指數(shù)據(jù)（包括請求數(shù)據(jù)和響應(yīng)數(shù)據(jù)）在客戶端和服務(wù)器端進(jìn)行傳輸?shù)臅r(shí)間，而后者是指網(wǎng)站軟件實(shí)際處理請求所需的時(shí)間。類似的，軟件性能測試也更關(guān)心“應(yīng)用延遲時(shí)間”。實(shí)際上，這種分解還可以繼續(xù)下去，如果該網(wǎng)站系統(tǒng)使用了數(shù)據(jù)庫，我們可以把“數(shù)據(jù)庫延遲時(shí)間”分離出來，如果該網(wǎng)站系統(tǒng)使用了中間件，還可以把“中間件延遲時(shí)間”也分離出來。以上的時(shí)間分解實(shí)際上有兩方面的目的。首先，人們通常希望把與所開發(fā)軟件直接相關(guān)的延遲時(shí)間和與所開發(fā)軟件愛你不直接相關(guān)的延遲時(shí)間分離開，因?yàn)楦纳魄罢咄枰_發(fā)人員修改程序代碼，而改善后者不需要開發(fā)人員修改代碼，很多時(shí)候，開發(fā)人員對后者甚至是無能為力的。其次，詳細(xì)的分解有助于開發(fā)人員分析哪些部分是影響軟件性能的主要因素，以便于實(shí)時(shí)性能改善方案。(3)吞吐量吞吐量是指系統(tǒng)在單位時(shí)間內(nèi)處理請求的數(shù)量。對于無并發(fā)的應(yīng)用系統(tǒng)而言，吞吐量與響應(yīng)時(shí)間成嚴(yán)格的反比關(guān)系，實(shí)際上此時(shí)吞吐量就是響應(yīng)時(shí)間的倒數(shù)。前面已經(jīng)說過，對于單用戶的系統(tǒng)，響應(yīng)時(shí)間（或者系統(tǒng)響應(yīng)時(shí)間和應(yīng)用延遲時(shí)間）可以很好地度量系統(tǒng)的性能，但對于并發(fā)系統(tǒng)，通常需要用吞吐量作為性能指標(biāo)。對于一個(gè)多用戶的系統(tǒng)，如果只有一個(gè)用戶使用時(shí)系統(tǒng)的平均響應(yīng)時(shí)間是 t，當(dāng)有你n個(gè)用戶使用時(shí)，每個(gè)用戶看到的響應(yīng)時(shí)間通常并不是 n×t，而往往比n×t小很多（當(dāng)然，在某些特殊情況下也可能比n×t大，甚至大很多）。這是因?yàn)樘幚砻總€(gè)請求需要用到很多資源，由于每個(gè)請求的處理過程中有許多不走難以并發(fā)執(zhí)行，這導(dǎo)致在具體的一個(gè)時(shí)間點(diǎn)，所占資源往往并不多。也就是說在處理單個(gè)請求時(shí)，在每個(gè)時(shí)間點(diǎn)都可能有許多資源被閑置，當(dāng)處理多個(gè)請求時(shí)，如果資源配置合理，每個(gè)用戶看到的平均響應(yīng)時(shí)間并不隨用戶數(shù)的增加而線性增加。實(shí)際上，不同系統(tǒng)的平均響應(yīng)時(shí)間隨用戶數(shù)增加而增長的速度也不大相同，這也是采用吞吐量來度量并發(fā)系統(tǒng)的性能的主要原因。一般而言，吞吐量是一個(gè)比較通用的指標(biāo)，兩個(gè)具有不同用戶數(shù)和用戶使用模式的系統(tǒng)，如果其最大吞吐量基本一致，則可以判斷兩個(gè)系統(tǒng)的處理能力基本一致。（4）并發(fā)用戶數(shù)并發(fā)用戶數(shù)是指系統(tǒng)可以同時(shí)承載的正常使用系統(tǒng)功能的用戶的數(shù)量。與吞吐量相比，并發(fā)用戶數(shù)是一個(gè)更直觀但也更籠統(tǒng)的性能指標(biāo)。實(shí)際上，并發(fā)用戶數(shù)是一個(gè)非常不準(zhǔn)確的指標(biāo)，因?yàn)橛脩舨煌氖褂媚Ｊ綍?huì)導(dǎo)致不同用戶在單位時(shí)間發(fā)出不同數(shù)量的請求。一網(wǎng)站系統(tǒng)為例，假設(shè)用戶只有注冊后才能使用，但注冊用戶并不是每時(shí)每刻都在使用該網(wǎng)站，因此具體一個(gè)時(shí)刻只有部分注冊用戶同時(shí)在線，在線用戶就在瀏覽網(wǎng)站時(shí)會(huì)花很多時(shí)間閱讀網(wǎng)站上的信息，因而具體一個(gè)時(shí)刻只有部分在線用戶同時(shí)向系統(tǒng)發(fā)出請求。這樣，對于網(wǎng)站系統(tǒng)我們會(huì)有三個(gè)關(guān)于用戶數(shù)的統(tǒng)計(jì)數(shù)字：注冊用戶數(shù)、在線用戶數(shù)和同時(shí)發(fā)請求用戶數(shù)。由于注冊用戶可能長時(shí)間不登陸網(wǎng)站，使用注冊用戶數(shù)作為性能指標(biāo)會(huì)造成很大的誤差。而在線用戶數(shù)和同事發(fā)請求用戶數(shù)都可以作為性能指標(biāo)。相比而言，以在線用戶作為性能指標(biāo)更直觀些，而以同時(shí)發(fā)請求用戶數(shù)作為性能指標(biāo)更準(zhǔn)確些。（5）資源利用率資源利用率反映的是在一段時(shí)間內(nèi)資源平均被占用的情況。對于數(shù)量為

1的資源，資源利用率可以表示為被占用的時(shí)間與整段時(shí)間的比值；對于數(shù)量不為

1的資源，資源利用率可以表示為在該段時(shí)間內(nèi)平均被占用的資源數(shù)與總資源數(shù)的比值。2.軟件性能的視角（1）用戶視角對用和而言，性能就是響應(yīng)時(shí)間。用戶甚至不關(guān)心響應(yīng)時(shí)間中哪些是軟件造成的，哪些是硬件造成的。但用和感受到的響應(yīng)時(shí)間既有客觀成分，也有主觀成分，甚至是心理因素。（2）管理員視角管理員需要使用軟件提供的管理功能等手段來方便普通用戶使用。 這類用戶首先關(guān)注普通用戶感受到的軟件性能。其次，管理員需要進(jìn)一步關(guān)注如何利用管理功能進(jìn)行性能調(diào)優(yōu)。（3）開發(fā)人員視角開發(fā)人員的視角與管理員的視角基本一致，但開發(fā)人員需要更深入地關(guān)注軟件性能。在開發(fā)過程中，開發(fā)人員希望能夠盡可能地開發(fā)出高性能的軟件。什么是軟件的性能測試----------------------------------------------------------------性能測試是通過自動(dòng)化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試。負(fù)載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進(jìn)行。通過負(fù)載測試，確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)各項(xiàng)性能指標(biāo)的變化情況。壓力測試是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。性能測試在軟件的質(zhì)量保證中起著重要的作用，它包括的測試內(nèi)容豐富多樣。中國軟件評測中心將性能測試概括為三個(gè)方面：應(yīng)用在客戶端性能的測試、應(yīng)用在網(wǎng)絡(luò)上性能的測試和應(yīng)用在服務(wù)器端性能的測試。通常情況下，三方面有效、合理的結(jié)合，可以達(dá)到對系統(tǒng)性能全面的分析和瓶頸的預(yù)測。·應(yīng)用在客戶端性能的測試應(yīng)用在客戶端性能測試的目的是考察客戶端應(yīng)用的性能，測試的入口是客戶端。它主要包括并發(fā)性能測試、疲勞強(qiáng)度測試、大數(shù)據(jù)量測試和速度測試等，其中并發(fā)性能測試是重點(diǎn)。并發(fā)性能測試是重點(diǎn)并發(fā)性能測試的過程是一個(gè)負(fù)載測試和壓力測試的過程，即逐漸增加負(fù)載，直到系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，通過綜合分析交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)并發(fā)性能的過程。負(fù)載測試（ LoadTesting）是確定在各種工作負(fù)載下系統(tǒng)的性能，目標(biāo)是測試當(dāng)負(fù)載逐漸增加時(shí)，系統(tǒng)組成部分的相應(yīng)輸出項(xiàng)，例如通過量、響應(yīng)時(shí)間、 CPU負(fù)載、內(nèi)存使用等來決定系統(tǒng)的性能。負(fù)載測試是一個(gè)分析軟件應(yīng)用程序和支撐架構(gòu)、模擬真實(shí)環(huán)境的使用，從而來確定能夠接收的性能過程。壓力測試（ StressTesting）是通過確定一個(gè)系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。并發(fā)性能測試的目的主要體現(xiàn)在三個(gè)方面：以真實(shí)的業(yè)務(wù)為依據(jù)，選擇有代表性的、關(guān)鍵的業(yè)務(wù)操作設(shè)計(jì)測試案例，以評價(jià)系統(tǒng)的當(dāng)前性能；當(dāng)擴(kuò)展應(yīng)用程序的功能或者新的應(yīng)用程序?qū)⒁徊渴饡r(shí)，負(fù)載測試會(huì)幫助確定系統(tǒng)是否還能夠處理期望的用戶負(fù)載，以預(yù)測系統(tǒng)的未來性能；通過模擬成百上千個(gè)用戶，重復(fù)執(zhí)行和運(yùn)行測試，可以確認(rèn)性能瓶頸并優(yōu)化和調(diào)整應(yīng)用，目的在于尋找到瓶頸問題。什么是數(shù)據(jù)驅(qū)動(dòng)測試----------------------------------------------------------------------黑盒測試（Black-boxTesting，又稱為功能測試或數(shù)據(jù)驅(qū)動(dòng)測試）是把測試對象看作一個(gè)黑盒子。利用黑盒測試法進(jìn)行動(dòng)態(tài)測試時(shí)，需要測試軟件產(chǎn)品的功能，不需測試軟件產(chǎn)品的內(nèi)部結(jié)構(gòu)和處理過程。采用黑盒技術(shù)設(shè)計(jì)測試用例的方法有：等價(jià)類劃分、邊界值分析、錯(cuò)誤推測、因果圖和綜合策略。黑盒測試注重于測試軟件的功能性需求，也即黑盒測試使軟件工程師派生出執(zhí)行程序所有功能需求的輸入條件。黑盒測試并不是白盒測試的替代品，而是用于輔助白盒測試發(fā)現(xiàn)其他類型的錯(cuò)誤。黑盒測試試圖發(fā)現(xiàn)以下類型的錯(cuò)誤：1）功能錯(cuò)誤或遺漏；2）界面錯(cuò)誤；3）數(shù)據(jù)結(jié)構(gòu)或外部數(shù)據(jù)庫訪問錯(cuò)誤；4）性能錯(cuò)誤；5）初始化和終止錯(cuò)誤。黑盒測試的測試用例設(shè)計(jì)方法：·等價(jià)類劃分方法·邊界值分析方法·錯(cuò)誤推測方法·因果圖方法·判定表驅(qū)動(dòng)分析方法·正交實(shí)驗(yàn)設(shè)計(jì)方法·功能圖分析方法什么是容量測試-------------------------------------------------------------------通過性能測試，如果找到了系統(tǒng)的極限或苛刻的環(huán)境中系統(tǒng)的性能表現(xiàn)，在一定的程度上，就完成了負(fù)載測試和容量測試。容量還可以看作系統(tǒng)性能指標(biāo)中一個(gè)特定環(huán)境下的一個(gè)特定性能指標(biāo)，即設(shè)定的界限或極限值。容量測試的目的是通過測試預(yù)先分析出反映軟件系統(tǒng)應(yīng)用特征的某項(xiàng)指標(biāo)的極限值（如最大并發(fā)用戶數(shù)、數(shù)據(jù)庫記錄數(shù)等），系統(tǒng)在其極限狀態(tài)下沒有出現(xiàn)任何軟件故障或還能保持主要功能正常運(yùn)行。容量測試還將確定測試對象在給定時(shí)間內(nèi)能夠持續(xù)處理的最大負(fù)載或工作量。軟件容量的測試能讓軟件開發(fā)商或用戶了解該軟件系統(tǒng)的承載能力或提供服務(wù)的能力，如某個(gè)電子商務(wù)網(wǎng)站所能承受的、同時(shí)進(jìn)行交易或結(jié)算的在線用戶數(shù)。知道了系統(tǒng)的實(shí)際容量，如是不能滿足設(shè)計(jì)要求，就應(yīng)該尋求新的技術(shù)解決方案，以提高系統(tǒng)的容量。有了對軟件負(fù)載的準(zhǔn)確預(yù)測，不僅能對軟件系統(tǒng)在實(shí)際使用中的性能狀況充滿信心，同時(shí)也可以幫助用戶經(jīng)濟(jì)地規(guī)劃應(yīng)用系統(tǒng)，優(yōu)化系統(tǒng)的部署。什么是嵌入式測試--------------------------------------------------------------------通常嵌入式系統(tǒng)對可靠性的要求比較高。嵌入式系統(tǒng)安全性的失效可能會(huì)導(dǎo)致災(zāi)難性的后果，即使是非安全性系統(tǒng)，由于大批量生產(chǎn)也會(huì)導(dǎo)致嚴(yán)重的經(jīng)濟(jì)損失。這就要求對嵌入式系統(tǒng)，包括嵌入式軟件進(jìn)行嚴(yán)格的測試、確認(rèn)和驗(yàn)證。隨著越來越多的領(lǐng)域使用軟件和微處理器控制各種嵌入式設(shè)備，對門益復(fù)雜的嵌入式軟件進(jìn)行快速有效的測試愈加顯得重要。軟件測試的目的是保證軟件滿足需求規(guī)格說明。系統(tǒng)失效是系統(tǒng)沒有滿足—個(gè)或多個(gè)正式需求規(guī)范中所要求的需求項(xiàng)。嵌入式軟件有其特殊的失效判定準(zhǔn)則，但是，嵌入式軟件測試的日的與非嵌入式軟件是相同的。在嵌入式系統(tǒng)設(shè)計(jì)中，軟件正越來越多地取代硬件，以降低系統(tǒng)的成本，獲得更大的靈活性，這就需要使用更好的測試方法和工具進(jìn)行嵌入式和實(shí)時(shí)軟件的測試。軟件性能測試的步驟---------------------------------------------------------------在每種不同的系統(tǒng)架構(gòu)的實(shí)施中，開發(fā)人員可能選擇不同的實(shí)現(xiàn)方式，造成實(shí)際情況紛繁復(fù)雜。我們不可能對每種技術(shù)都詳細(xì)解說，這里只是介紹一種方法提供給你如何選擇測試策略，從而幫助分析軟件不同部分的性能指標(biāo)，進(jìn)而分析出整體架構(gòu)的性能指標(biāo)和性能瓶頸。由于工程和項(xiàng)目的不同，所選用的度量,評估方法也有不同之處。不過仍然有一些通用的步驟幫助我們完成一個(gè)性能測試項(xiàng)目。步驟如下1．制定目標(biāo)和分析系統(tǒng)2．選擇測試度量的方法3．學(xué)習(xí)的相關(guān)技術(shù)和工具4．制定評估標(biāo)準(zhǔn)5．設(shè)計(jì)測試用例6．運(yùn)行測試用例7．分析測試結(jié)果·制定目標(biāo)和分析系統(tǒng)每一個(gè)性能測試計(jì)劃中第一步都會(huì)制定目標(biāo)和分析系統(tǒng)構(gòu)成。 只有明確目標(biāo)和了解系統(tǒng)構(gòu)成才會(huì)澄清測試范圍，知道在測試中要掌握什么樣的技術(shù)。目標(biāo)：1．確定客戶需求和期望2．實(shí)際業(yè)務(wù)需求3．系統(tǒng)需求系統(tǒng)組成系統(tǒng)組成這里包含幾方面含義：系統(tǒng)類別，系統(tǒng)構(gòu)成，系統(tǒng)功能等。了解這些內(nèi)容的本質(zhì)其實(shí)是幫助我們明確測試的范圍，選者適當(dāng)?shù)臏y試方法來進(jìn)行測試。系統(tǒng)類別：分清系統(tǒng)類別是我們掌握什么樣的技術(shù)的前提，掌握相應(yīng)技術(shù)做性能測試才可能成功。例如：系統(tǒng)類別是bs結(jié)構(gòu),需要掌握http協(xié)議，java，html等技術(shù)。或者是cs結(jié)構(gòu)，可能要了解操作系統(tǒng)，winsock，com等。所以甄別系統(tǒng)類別對于我們來說很重要。系統(tǒng)構(gòu)成：硬件設(shè)置，操作系統(tǒng)設(shè)置是性能測試的制約條件，一般性能測試都是利用測試工具模仿大量的實(shí)際用戶操作，系統(tǒng)在超負(fù)荷情形下運(yùn)作。不同的系統(tǒng)構(gòu)成性能測試就會(huì)得到不同的結(jié)果。系統(tǒng)功能：系統(tǒng)功能指系統(tǒng)提供的不同子系統(tǒng)，辦公管理系統(tǒng)中的公文子系統(tǒng)，會(huì)議子系統(tǒng)等，系統(tǒng)工能是性能測試中要模擬的環(huán)節(jié)，了解這些是必要的。·選擇測試度量的方法經(jīng)過第一步，將會(huì)對系統(tǒng)有清醒的認(rèn)識。接下來我們將把精力放在軟件度量上，收集系統(tǒng)相關(guān)的數(shù)據(jù)。度量的相關(guān)方面：制定規(guī)范制定相關(guān)流程,角色，職責(zé)制定改進(jìn)策略制定結(jié)果對比標(biāo)準(zhǔn)·學(xué)習(xí)的相關(guān)技術(shù)和工具性能測試是通過工具，模擬大量用戶操作，對系統(tǒng)增加負(fù)載。所以需要掌握一定的工具知識才能進(jìn)行性能測試。大家都知道性能測試工具一般通過winsock,http等協(xié)議紀(jì)錄用戶操作。而協(xié)議選擇是基于軟件的系統(tǒng)架構(gòu)實(shí)現(xiàn)（web一般選擇http協(xié)議,cs選擇winsock協(xié)議），不同的性能測試工具，腳本語言也不同，比如rationalrobot中vu腳本用類c語言實(shí)現(xiàn)。開展性能測試需要對各種性能測試工具進(jìn)行評估，因?yàn)槊恳环N性能測試工具都有自身的特點(diǎn)，只有經(jīng)過工具評估，才能選擇符合現(xiàn)有軟件架構(gòu)的性能測試工具。確定測試工具后，需要組織測試人員進(jìn)行工具的學(xué)習(xí)，培訓(xùn)相關(guān)技術(shù)?！ぶ贫ㄔu估標(biāo)準(zhǔn)任何測試的目的都是確保軟件符合預(yù)先規(guī)定的目標(biāo)和要求。性能測試也不例外。所以必須制定一套標(biāo)準(zhǔn)。通常性能測試有四種模型技術(shù)可用于評估：線性投射：用大量的過去的，擴(kuò)展的或者將來可能發(fā)生的數(shù)據(jù)組成散布圖，利用這個(gè)圖表不斷和系統(tǒng)的當(dāng)前狀況對比。分析模型：用排隊(duì)論公式和算法預(yù)測響應(yīng)時(shí)間，利用描述工作量的數(shù)據(jù)和系統(tǒng)本質(zhì)關(guān)聯(lián)起來模仿：模仿實(shí)際用戶的使用方法測試你的系統(tǒng)基準(zhǔn)：定義測試和你最初的測試作為標(biāo)準(zhǔn)，利用它和所有后來進(jìn)行的測試結(jié)果進(jìn)行對比·設(shè)計(jì)測試用例設(shè)計(jì)測試用例是在了解軟件業(yè)務(wù)流程的基礎(chǔ)上。設(shè)計(jì)測試用例的原則是受最小的影響提供最多的測試信息，設(shè)計(jì)測試用例的目標(biāo)是一次盡可能的包含多個(gè)測試要素。這些測試用例必須是測試工具可以實(shí)現(xiàn)的，不同的測試場景將測試不同的功能。因?yàn)樾阅軠y試不同于平時(shí)的測試用例，盡可能把性能測試用例設(shè)計(jì)的復(fù)雜，才有可能發(fā)現(xiàn)軟件的性能瓶頸?！み\(yùn)行測試用例通過性能測試工具運(yùn)行測試用例。同一環(huán)境下作的性能測試得到的測試結(jié)果是不準(zhǔn)確的，所以在運(yùn)行這些測試用例的時(shí)候，需要用不同的測試環(huán)境，不同的機(jī)器配置上運(yùn)行?！し治鰷y試結(jié)果運(yùn)行測試用例后，收集相關(guān)信息，進(jìn)行數(shù)據(jù)統(tǒng)計(jì)分析，找到性能瓶頸。通過排除誤差和其他因素，讓測試結(jié)果體現(xiàn)接近真實(shí)情況。不同的體系結(jié)構(gòu)分析測試結(jié)果的方法也不同，bs結(jié)構(gòu)我們會(huì)分析網(wǎng)絡(luò)帶寬，流量對用戶操作響應(yīng)的影響，而 cs結(jié)構(gòu)我們可能更關(guān)心會(huì)系統(tǒng)整體配置對用戶操作的影響。什么是代碼審查--------------------------------------------------------------代碼審查(codereview)是軟件開發(fā)過程的一個(gè)階段，在這個(gè)階段中，代碼創(chuàng)造者和審查人員，可能還有質(zhì)量保證(QA)測試人員，一起進(jìn)行代碼審查。代碼審查(codereview)是軟件開發(fā)過程的一個(gè)階段，在這個(gè)階段中，代碼創(chuàng)造者和審查人員，可能還有質(zhì)量保證(QA)測試人員，一起進(jìn)行代碼審查。能在該階段中就找出并更正存在的錯(cuò)誤，相對來說比較合理，因?yàn)槿绻陂_發(fā)軟件后面的階段或者軟件交付給用戶后才來處理、查找和修改程序缺陷的話，會(huì)要花費(fèi)更多成本。審查人員需要很仔細(xì)地檢查代碼，包括：缺陷或者潛在缺陷和整個(gè)程序設(shè)計(jì)的一致性評論的質(zhì)量遵守編碼標(biāo)準(zhǔn)代碼審查通常能很好地檢測出安全漏洞問題。 有一些專門的應(yīng)用程序可以幫助進(jìn)行代碼審查。自動(dòng)代碼審查系統(tǒng)可以有效地系統(tǒng)化地檢測源代碼的潛在問題，如緩沖區(qū)溢出、競態(tài)條件、內(nèi)存泄露、代碼塊大小問題和重復(fù)語句等。另外，代碼審查也常用于檢測補(bǔ)丁質(zhì)量。什么是可用性測試--------------------------------------------------------------------------可用性測試是指，讓一群有代表性的用戶嘗試對產(chǎn)品進(jìn)行典型操作，同時(shí)觀察員和開發(fā)人員在一旁觀察，聆聽，做記錄。該產(chǎn)品可能是一個(gè)網(wǎng)站，軟件，或者其他任何產(chǎn)品，它可能尚未成型。測試可以是早期的紙上原型測試，也可以是后期成品的測試。你能從可用性測試獲得什么 ?在每一輪的可用性測試中，你都應(yīng)該先明確具體的測試問題和目標(biāo)，針對這些目標(biāo)進(jìn)行測試。舉例來說，項(xiàng)目剛剛起步，你可以對定量的指標(biāo)時(shí)間，錯(cuò)誤率和滿意度 )進(jìn)行測試，為日后修改網(wǎng)站提供參照。再例如，如果你已經(jīng)設(shè)定了可測量的可用性目標(biāo)，你可以看看你的產(chǎn)品是否切合這些目標(biāo)。對于一個(gè)典型的可用性測

(如試，你可以：找出該產(chǎn)品的任何的可用性問題從測試參與者的表現(xiàn)收集定量數(shù)據(jù)確定該產(chǎn)品的用戶滿意度可用性測試和以用戶為中心的設(shè)計(jì)的關(guān)系?可用性測試是以用戶為中心的設(shè)計(jì)的一個(gè)重要組成部分。用戶為本的設(shè)計(jì)過程本身就應(yīng)該包括對性能和偏好進(jìn)行評價(jià)的一系列測試。什么時(shí)候該做可用性測試?盡早做，經(jīng)常做?？捎眯詼y試可以讓設(shè)計(jì)師和開發(fā)團(tuán)隊(duì)在產(chǎn)品成形之前盡早發(fā)現(xiàn)問題。問題越早發(fā)現(xiàn)和彌補(bǔ)，所造成的損失就越低。這些問題是找到并固定好，越昂貴的補(bǔ)丁程序。隨著項(xiàng)目的進(jìn)展，對設(shè)計(jì)主體進(jìn)行改動(dòng)會(huì)變得越來越困難和昂貴。你測試的越多，并就相應(yīng)測試進(jìn)行改進(jìn)，你就可以更加確信你的網(wǎng)站沒有偏軌，確信它是符合您的目標(biāo)和用戶的需要的。迭代開發(fā)過程——開發(fā)原型，測試用戶，分析結(jié)果，隨之修改原型，然后再重復(fù)測試、分析、修改周期——是開發(fā)一個(gè)成功的網(wǎng)站或軟件的最好方式?；鶞?zhǔn)測試------------------------------------------------------------------------基準(zhǔn)測試的關(guān)鍵是要獲得一致的、可再現(xiàn)的結(jié)果。可再現(xiàn)的結(jié)果有兩個(gè)好處：減少重新運(yùn)行測試的次數(shù)；對測試的產(chǎn)品和產(chǎn)生的數(shù)字更為確信。使用的性能測試工具可能會(huì)對測試結(jié)果產(chǎn)生很大影響。假定測試的兩個(gè)指標(biāo)是服務(wù)器的響應(yīng)時(shí)間和吞吐量，它們會(huì)受到服務(wù)器上的負(fù)載的影響。服務(wù)器上的負(fù)載受兩個(gè)因素影響：同時(shí)與服務(wù)器通信的連接（或虛擬用戶）的數(shù)目，以及每個(gè)虛擬用戶請求之間的考慮時(shí)間的長短。很明顯，與服務(wù)器通信的用戶越多，負(fù)載就越大。同樣，請求之間的考慮時(shí)間越短，負(fù)載也越大。