第12章軟件測試第12章軟件測試1）軟件測試的概念2）黑盒測試和白盒測試方法3）單元測試過程4）集成測試,系統(tǒng)測試,驗收測試的基本過程掌握掌握

理解了解要求12.1軟件測試的概念1963年,美國,飛往火星的火箭爆炸,損失$10million。原因:FORTRAN循環(huán)：

DO5I=1,3誤寫為DO5I=1.3

軟件測試的工作量約占整個項目工作量的40％左右，對于要求極高的系統(tǒng)測試工作量還要成倍增加。微軟Exchange2000和Windows

2000中的人員結構

Exchange2000Windows2000項目經(jīng)理25人約250人開發(fā)人員140人約1700人測試人員350人約3200人測試人員/開發(fā)人員2:51:9軟件測試的目的？為什么需要這么多人、花這么多代價進行測試？目的何在？

“證明程序正確！”對嗎？Myers對軟件測試目的提出以下觀點：（1）軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。（2）一個好的測試用例能夠發(fā)現(xiàn)至今尚未發(fā)現(xiàn)的錯誤。（3）一個成功的測試是發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的錯誤的測試。6

通常想象的“測試是為了表明程序是正確的”，“成功的測試是沒有發(fā)現(xiàn)錯誤的測試”是不正確的。測試的目的決定了測試方案的設計。如果為了表明程序是正確的而進行測試，就會設計一些不易暴露錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設計出最能暴露錯誤的測試方案。測試決不能證明軟件是正確的，也不能證明錯誤的不存在，它只能證明錯誤的存在。測試的定義從廣義上講是指軟件產品生存周期內所有的檢查、評審和確認活動從狹義上講，軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序內部結構而精心設計的一批測試用例,用這些測試用例運行程序,以發(fā)現(xiàn)程序錯誤的過程。一個測試用例是一組輸入數(shù)據(jù)及其對應的預期輸出結果。測試的工作量一般性軟件其測試工作量大約占整個開發(fā)工作量的40%系統(tǒng)軟件或關系到人的生命財產安全的重要軟件，其測試工作量通常可能達到整個開發(fā)工作量的3—5倍軟件測試的目標優(yōu)秀的測試用例:以最小的代價、在最短的時間內，盡可能多地發(fā)現(xiàn)軟件中的錯誤。10軟件測試原則(1)

應該把測試貫穿在整個開發(fā)過程之中。事實上從需求分析階段開始，每個階段結束之前都要進行階段審查，目的是盡早發(fā)現(xiàn)和糾正錯誤。概要設計時應完成測試計劃，詳細的測試用例定義可在設計模型確定后開始，所有測試可在任何代碼被產生之前進行計劃和設計。

11軟件測試原則

軟件測試不等于程序測試。據(jù)美國一家公司統(tǒng)計，查出的軟件錯誤中，屬于需求分析和軟件設計的錯誤約占64%，屬于程序編寫的錯誤僅占36%。程序編寫的許多錯誤是“先天的”。12測試與開發(fā)前期工作的關系決定軟件與系統(tǒng)的配合關系需求分析概要設計詳細設計編碼單元測試集成測試確認測試系統(tǒng)測試13開發(fā)前期出現(xiàn)錯誤的擴展計劃需求分析設計編碼測試AB14（2）測試用例應由輸入數(shù)據(jù)和預期的輸出結果兩部分組成，并兼顧合理的輸入和不合理的輸入數(shù)據(jù)。在實際操作中可以列出一張電子表格，包括每個測試用例的編號、類型、輸入數(shù)據(jù)、預期輸出結果、實際輸出結果、出錯原因分析。15（3）窮舉測試是不可能的。所謂窮舉測試就是把程序所有可能的執(zhí)行路徑都檢查一遍的測試。例:輸入三條邊長可采用的測試用例數(shù)(設字長16位)

執(zhí)行時間:設測試一次需1ms共需一萬年.=2X2X2≈3X1016161614窮舉測試實例:設程序含5個分支,循環(huán)次數(shù)≤20,從A到B的可能路徑

執(zhí)行時間:設測試一次需2ms窮舉測試需5億年.=5+5+..+5+5≈1020121914AB18（4）程序員應該盡量避免檢查自己編寫的代碼。為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。所謂“最佳效果”是指有最大可能性發(fā)現(xiàn)錯誤的測試。開發(fā)軟件的軟件工程師（心理）并不是完成全部測試工作的最佳人選（通常他們主要承擔模塊測試工作）。測試原則續(xù)（5）在設計測試用例時，應該包括有效的、期望的輸入情況，也要包括無效的和不期望的輸入情況。即能夠驗證程序正常運行的合理輸入，也能夠驗證對異常情況處理的不合理輸入數(shù)據(jù)以及臨界數(shù)據(jù)輸入。在測試時,人們常常過多地考慮合法和期望的輸入條件,以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。用戶在使用系統(tǒng)時,輸入一些錯誤指令和參數(shù)是經(jīng)常發(fā)生的,如果軟件遇到這種情況不能做出適當?shù)姆磻?給出相應的提示信息,可能會誤導用戶,甚至會造成嚴重損失。測試原則續(xù)（6）軟件中遺留的錯誤數(shù)量與已經(jīng)發(fā)現(xiàn)的錯誤數(shù)量成正比。根據(jù)這個規(guī)律對測試中發(fā)現(xiàn)錯誤成堆的模塊更要仔細測試。例如，在某個著名的操作系統(tǒng)中，44%的錯誤僅與4%的模塊有關。（7）回歸測試的關聯(lián)性要特別引起注意，修改一個錯誤而引起更多錯誤的現(xiàn)象并不少見。測試原則續(xù)（8）嚴格執(zhí)行測試計劃。在測試之前應該有明確的測試計劃，內容包括：要測試的軟件功能和內容、測試用例和預期結果、測試的進度安排、需要的工具和資源、測試控制方式和過程等。（9）做好測試記錄，為統(tǒng)計和維護提供基礎數(shù)據(jù)軟件測試的對象軟件測試并不等于程序測試。軟件測試應貫穿于軟件定義與開發(fā)的整個期間。需求分析、概要設計、詳細設計以及程序編碼等各階段所得到的文檔，包括需求規(guī)格說明、概要設計規(guī)格說明、詳細設計規(guī)格說明以及源程序，都應成為軟件測試的對象。為把握軟件開發(fā)各個環(huán)節(jié)的正確性，需要進行各種確認和驗證工作。驗證和有效性確認驗證(Verification)：通過檢查和提供客觀證據(jù)，表明規(guī)定要求已經(jīng)滿足的認可。在軟件生存期各個階段，驗證是指檢測各個階段結束時的工作產品是否滿足對上一階段的結束后的工作產品所定義的規(guī)格的驗證過程有效性確認(Validation)：通過檢查和提供客觀證據(jù)，表明一些針對某一特定預期用途的要求已經(jīng)滿足的認可。在軟件生存周期各個階段，確認是指檢測各個階段結束時的工作產品是否滿足在軟件生存周期初期在系統(tǒng)需求文檔中描述的各項軟件規(guī)格的確認過程。都是測試活動。驗證和有效性確認驗證(Verification)：有效性確認(Validation)：都是測試活動。測試的層次和類型—層次單元測試：針對模塊代碼的測試,測試的粒度最小集成測試：把經(jīng)過單元測試的模塊組合在一起,重點測試模塊之間的接口。系統(tǒng)測試：系統(tǒng)集成后,對整個系統(tǒng)包括硬件等環(huán)境的綜合測試。驗收測試：以用戶為主,對軟件功能、性能進行全面測試。驗證軟件是否滿足需求規(guī)格說明書的要求，檢查所有的配置成份是否齊全。測試的層次和類型—類型靜態(tài)測試：主要通過代碼審查和靜態(tài)分析，檢查源代碼中存在的問題。過程：代碼審查由有經(jīng)驗的程序設計人員根據(jù)軟件詳細設計說明書，閱讀程序來發(fā)現(xiàn)源程序中類型、引用、參數(shù)傳遞、表達式等不必運行程序就能夠發(fā)現(xiàn)的錯誤。特點：這種方法不需要專門的測試工具和設備，一旦發(fā)現(xiàn)錯誤就能定位，但是此方法具有一定的局限性。靜態(tài)分析主要對程序進行控制流分析、數(shù)據(jù)流分析、接口分析和表達式分析等測試的層次和類型—類型動態(tài)測試：在指定的環(huán)境上運行被測程序，輸入測試數(shù)據(jù)，獲得測試結果，將獲得的測試結果與預期的結果進行比較，發(fā)現(xiàn)程序的錯誤。過程：設計測試用例，運行被測程序。特點：需要有程序的運行環(huán)境，必要時要編寫測試驅動程序和樁程序。測試的層次和類型—類型功能測試：驗證軟件是否提供了預期服務。過程：根據(jù)軟件需求規(guī)格說明書設計測試用例，并按照測試用例的要求運行被測程序。特點：將被測程序看成是一個黑盒子，著重驗證軟件功能和性能的正確性，其典型測試方法包括價類劃分、邊值分析、因果分析、猜測錯誤等。測試的層次和類型—類型結構測試：對程序結構的檢查，也稱為白盒測試。采用這種測試方法，測試者需要了解被測程序的內部結構。白盒測試通常根據(jù)覆蓋準則設計測試用例，有語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋和條件組合覆蓋等。測試的層次和類型—類型用戶界面測試：對軟件提供的用戶界面、系統(tǒng)接口的測試。驗證其正確性、可操作性、可理解性。性能測試：測試程序的響應時間、并發(fā)性、吞吐量、處理精度。負載測試：測試一個軟件在重負荷下的運行情況。例如，測試一個Web應用軟件在大量的負荷下，何時系統(tǒng)的響應會退化或失敗強度測試：在異乎尋常的重載下系統(tǒng)運行情況，如某個動作或輸入的不斷重復；大量數(shù)據(jù)的輸入；對一個數(shù)據(jù)庫應用系統(tǒng)大量的復雜查詢等。

測試的層次和類型—類型安全性測試：檢查系統(tǒng)對非法侵入的防范能力。測試人員假扮非法入侵者，采用各種辦法試圖突破防線。例如，截取或破譯口令、破壞系統(tǒng)的保護機制、故意導致系統(tǒng)失敗、試圖通過瀏覽非保密數(shù)據(jù)，推導所需信息等網(wǎng)絡通信測試：軟件中的網(wǎng)絡通信的速度、容量、安全性、延遲處理等方面的測試。測試的層次和類型—類型恢復測試:恢復測試主要檢查系統(tǒng)的容錯能力。當系統(tǒng)出錯時，能否在指定時間內修正錯誤并重新啟動系統(tǒng)?；謴蜏y試首先要采用各種辦法強迫系統(tǒng)失敗，然后驗證系統(tǒng)是否能盡快恢復。對于自動恢復需驗證重新初始化、數(shù)據(jù)恢復、重新啟動等機制的正確性；對于人工干預的恢復系統(tǒng)，還需估測平均修復時間，確定其是否在可接受的范圍內。測試的難點測試用例是設計者對測試對象的理解，因此，其質量很大程度上取決于設計者的分析、理解和設計能力。這是一種缺乏指導性方法的、不易制訂標準規(guī)范的、需要“技巧”的設計活動。開發(fā)組織與測試組織難一很好的配合。長期以來，大都數(shù)軟件開發(fā)人員認為測試活動是對開發(fā)人員勞動成果的不斷“挑剔”。但實際上，測試工作的出發(fā)點是確保開發(fā)人員的勞動成果成為可接收的、高品質的軟件產品。有效的測試工作需要投入足夠的人力和物力，需要對工作的難度和消耗有充分的估計。測試的產品軟件測試工作所產生的文檔、程序、服務、以及相關的文件總和稱之為軟件測試產品。測試配置包括：測試計劃；測試方案（包括測試輸入數(shù)據(jù)、測試的功能、測試預期結果）；文檔審查項列表；代碼審查項列表；軟件測試報告；軟件問題報告；軟件變更報告；軟件測試日志。35測試階段的信息流測試軟件配置結果分析測試結果排錯改正的軟件預期結果可靠性分析預測的可靠性錯誤出錯率數(shù)據(jù)測試配置測試工具需求規(guī)格說明書軟件設計說明書被測源程序

測試計劃測試用例(測試數(shù)據(jù))測試驅動程序測試數(shù)據(jù)自動生成程序、靜態(tài)分析程序、動態(tài)分析程序、測試結果分析程序、以及驅動測試的測試數(shù)據(jù)庫等。12.2設計測試用例測試用例是用于軟件測試的輸入數(shù)據(jù)及預期結果。一個好的測試用例有以下幾個特征：是最有可能發(fā)現(xiàn)錯誤的；不是重復的、多余的；通常先按黑盒測試法設計基本測試用例，發(fā)現(xiàn)軟件功能和性能上的問題，然后再用白盒測試方法補充一些測試用例，發(fā)現(xiàn)程序邏輯結構的錯誤。黑盒測試這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。黑盒測試又叫做功能測試或數(shù)據(jù)驅動測試。

黑盒測試的作用黑盒測試方法是在程序接口上進行測試，主要是為了發(fā)現(xiàn)以下錯誤:是否有不正確或遺漏了的功能?在接口上，輸入能否正確地接受?能否輸出正確的結果?是否有數(shù)據(jù)結構錯誤或外部信息(例如數(shù)據(jù)文件)訪問錯誤?性能上是否能夠滿足要求?是否有初始化或終止性錯誤?黑盒測試的局限用黑盒測試發(fā)現(xiàn)程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查程序是否都能產生正確的輸出。但這是不可能的。示例假設一個程序P有輸入量X和Y及輸出量Z。在字長為32位的計算機上運行。若X、Y取整數(shù)，按黑盒方法進行窮舉測試：可能采用的測試數(shù)據(jù)組：232×232＝264

如果測試一組數(shù)據(jù)需要1毫秒，一年工作365×

24小時，完成所有測試需5億年。黑盒測試法等價類劃分邊值分析因果分析猜測錯誤白盒測試此方法把測試對象看做一個透明的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序的狀態(tài)，確定實際的狀態(tài)是否與預期的狀態(tài)一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試的作用軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查：對程序模塊的所有獨立的執(zhí)行路徑至少測試一次；對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；在循環(huán)的邊界和運行界限內執(zhí)行循環(huán)體；測試內部數(shù)據(jù)結構的有效性，等。白盒測試的局限對一個具有多重選擇和循環(huán)嵌套的程序，不同的路徑數(shù)目可能是天文數(shù)字。給出一個小程序的流程圖，它包括了一個執(zhí)行20次的循環(huán)。包含的不同執(zhí)行路徑數(shù)達520條，對每一條路徑進行測試需要1毫秒，假定一年工作365×24小時，要想把所有路徑測試完，需3170年。白盒測試與黑盒測試對比黑盒測試白盒測試優(yōu)點適用于各測試階段從產品功能角度測試容易入手生成測試數(shù)據(jù)可以構成測試數(shù)據(jù)使特定程序部分得到測試有一定的充分性度量手段可獲得較多工具支持缺點某些代碼段得不到測試如果規(guī)格說明有誤則無法發(fā)現(xiàn)不易進行充分性度量不易生成測試數(shù)據(jù)無法對未實現(xiàn)規(guī)格說明得部分測試工作量大，通常只用于單元測試，有引用局限性質是一種確認技術，回答“我們在構造一個正確得系統(tǒng)嗎？”是一種驗證技術，回答“我們在正確地構造一個系統(tǒng)嗎？”白盒測試法語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋48發(fā)現(xiàn)錯誤的能力標準含義1(弱)語句覆蓋每條語句至少執(zhí)行一次2判定覆蓋每一判定的每個分支至少執(zhí)行一次3條件覆蓋每一判定中的每個條件，分別按“真”、“假”至少各執(zhí)行一次4判定/條件覆蓋同時滿足判定覆蓋和條件覆蓋的要求5(強)條件組合覆蓋求出判定中所有條件的各種可能組合值，每一可能的條件組合至少執(zhí)行一次

邏輯覆蓋測試的5種標準

例子func(intA,B,X){if((A>1)&&(B=0)){X:=X/A};if((A=2)||(X>1)){X:=X+1};}A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced測試覆蓋率示例（1）覆蓋標準程序結構舉例測試用例應滿足的條件語句覆蓋A^B=.T.判定覆蓋A^B=.T.A^B=.F.A^BTFA^BTF測試覆蓋率示例（2）覆蓋標準程序結構舉例測試用例應滿足的條件條件覆蓋A=.T.A=.F.B=.T.B=.F.判定/條件覆蓋A^B=.T.,A^B=.F.A=.T.A=.F.B=.T.B=.F.條件組合覆蓋A=.T.^B=.T.A=.T.^B=.F.A=.F.^B=.TA=.F.^B=.F.A^BTFA^BTFA^BTF語句覆蓋語句覆蓋：選擇足夠的測試用例，使得程序中每個語句至少都能被執(zhí)行一次。語句覆蓋例測試用例的設計格式如下【輸入的(A,B,X)，輸出的(A,B,X)】正好所有的可執(zhí)行語句都在路徑L1上測試用例【(2,0,4)，(2,0,3)】A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced54只需設計一個測試用例:

輸入數(shù)據(jù)：A=2，

B=0，

X=4

即達到了語句覆蓋。語句覆蓋是最弱的邏輯覆蓋（如：OR

寫成AND，X>1寫成X<1,查不出來）分支覆蓋分支覆蓋又稱判定覆蓋。分支覆蓋：執(zhí)行足夠的測試用例，使得程序中每個判定都獲得一次“真”值和“假”值，或者說使得程序中的每一個分支至少都通過一次。分支覆蓋例選擇路徑L1和L2【(2,0,4)，(2,0,3)】覆蓋ace【L1】【(1,1,1)，(1,1,1)】覆蓋abd【L2】

或選擇路徑L3和L4【(2,1,1)，(2,1,2)】覆蓋abe【L3】【(3,0,3)，(3,0,1)】覆蓋acd【L4】A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced條件覆蓋條件覆蓋：執(zhí)行足夠的測試用例，使得判定中的每個子條件都獲得所有可能的結果。條件覆蓋例A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced判斷條件取真值取假值判斷(一)A>1T1T1B=0T2T2判斷(二)A=2T3T3X>1T4T4設條件的取值標記

判定/條件覆蓋可選取的測試用例

如下表測試用例通過路徑條件取值覆蓋分支

【(1,0,3)，(1,0,4)】abe(L3)b,e【(2,1,1)，(2,1,2)】abe(L3)b,eT1T2T3T4T1T2T3T4判定/條件覆蓋判定/條件覆蓋：執(zhí)行足夠的測試用例，

使得判定中每個子條件取到各種可能的值，并使每個判定取到各種可能的結果。分支/條件覆蓋例A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced判斷條件取真值取假值判斷(一)A>1T1T1B=0T2T2判斷(二)A=2T3T3X>1T4T4設條件的取值標記

判定/條件覆蓋可選取的測試用例

如下表測試用例通過路徑條件取值覆蓋分支

【(2,0,4)，(2,0,3)】ace(L1)c,e【(1,1,1)，(1,1,1)】abd(L2)b,dT1T2T3T4T1T2T3T4條件組合覆蓋條件組合覆蓋：執(zhí)行足夠的測試用例，使得每個判定中各條件的所有可能的組合都出現(xiàn)一次。條件組合覆蓋例條件標記第一個判斷取真假分支

A>1B=0A>1B≠0A≯1B=

0A≯1B≠

0判斷條件取真值取假值判斷(一)A>1T1T1B=0T2T2判斷(二)A=2T3T3X>1T4T4設條件的取值標記T1T2①

取真分支T1T2T1T2②

取假分支③

取假分支④

取假分支T1T2A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced條件組合覆蓋例判斷條件取真值取假值判斷(一)A>1T1T1B=0T2T2判斷(二)A=2T3T3X>1T4T4設條件的取值標記A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced條件標記第二個判斷取真假分支

A=2X>1A=2X≯1A≠2X>1A≠2X≯1T3T4⑤

取真分支T3T4T3T4⑥

取真分支⑦

取真分支⑧

取假分支T3T4條件組合覆蓋例測試用例通過路徑條件取值覆蓋組合號

【(2,0,4),(2,0,3)】aceL1T1T2T3T4①,⑤【(2,1,1),(2,1,2)】abeL3T1T2T3T4②,⑥【(1,0,3),(1,0,4)】abeL3T1T2T3T4③,⑦【(1,1,1),(1,1,1)】abdL2T1T2T3T4④,⑧A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced路徑覆蓋路徑測試就是設計足夠的測試用例，覆蓋程序中每一條可能的執(zhí)行路徑。例子func(intA,B,X){if((A>1)&&(B=0)){X:=X/A};if((A=2)||(X>1)){X:=X+1};}A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabced路徑L1(ace)={(A>1)and(B=0)}and{(A=2)or(X/A>1)}=(A>1)and(B=0)and(A=2)or(A>1)and(B=0)and(X/A>1)=(A=2)and(B=0)

or

(A>1)and(B=0)and(X/A>1)L2(abd)=not{(A>1)and(B=0)}

andnot{(A=2)or(X>1)}={not(A>1)ornot(B=0)}and{not(A=2)andnot(X>1)}=

not(A>1)andnot(A=2)andnot(X>1)

or

not(B=0)and

not(A=2)andnot(X>1)L3(abe)=not{(A>1)and(B=0)}and{(A=2)or(X>1)}={not(A>1)ornot(B=0)}and

{(A=2)or(X>1)}=not(A>1)and(A=2)

ornot(A>1)and

(X>1)

or

not(B=0)and(A=2)

or

not(B=0)and(X>1)L4(acd)={(A>1)and(B=0)}

andnot

{(A=2)or(X/A>1)}=(A>1)and(B=0)andnot(A=2)and

not(X/A>1)路徑覆蓋例測試用例通過路徑條件取值

【(2,0,4),(2,0,3)】aceL1T1T2T3T4【(1,1,1),(1,1,1)】abdL2【(1,1,2),(1,1,3)】abeL3【(3,0,3),(3,0,1)】acdL4T1T2T3T4A>1andB=0A=2ORX>1X=X/AX=X+1YESYESNONOabcedT1T2T3T4T1T2T3T4條件測試路徑選擇當程序中判定多于一個時，形成的分支結構可以分為兩類：嵌套型分支結構和連鎖型分支結構。對于嵌套型分支結構，若有n個判定語句，需要n+1個測試用例；對于連鎖型分支結構，若有n個判定語句，需要有2n個測試用例，覆蓋它的2n條路徑。循環(huán)測試路徑選擇循環(huán)分為4種不同類型：簡單循環(huán)連鎖循環(huán)嵌套循環(huán)非結構循環(huán)(1)簡單循環(huán)①零次循環(huán)：從循環(huán)入口到出口②一次循環(huán)：檢查循環(huán)初始值③二次循環(huán)：檢查多次循環(huán)④m次循環(huán)：檢查在多次循環(huán)⑤最大次數(shù)循環(huán)、比最大次數(shù)多一次、少一次的循環(huán)例：求最小值k=i;for(j=i+1;j<=n;j++)if(A[j]<A[k])k=j;

k=i;j=i+1;j<=n?A[j]<A[k]?k=jj++fdcabe測試用例選擇(2)

嵌套循環(huán)①對最內層循環(huán)做簡單循環(huán)的全部測試。所有其它層的循環(huán)變量置為最小值；②逐步外推，對其外面一層循環(huán)進行測試。測試時保持所有外層循環(huán)的循環(huán)變量取最小值，所有其它嵌套內層循環(huán)的循環(huán)變量取“典型”值。③反復進行，直到所有各層循環(huán)測試完畢。④對全部各層循環(huán)同時取最小循環(huán)次數(shù)，或者同時取最大循環(huán)次數(shù)。連鎖循環(huán)與非結構循環(huán)(3)連鎖循環(huán)如果各個循環(huán)互相獨立，則可以用與簡單循環(huán)相同的方法進行測試。但如果幾個循環(huán)不是互相獨立的，則需要使用測試嵌套循環(huán)的辦法來處理。(4)非結構循環(huán)這一類循環(huán)應該使用結構化程序設計方法重新設計測試用例?；韭窂綔y試基本路徑測試方法把覆蓋的路徑數(shù)壓縮到一定限度內，程序中的循環(huán)體最多只執(zhí)行一次。它是在程序控制流圖的基礎上，分析控制構造的環(huán)路復雜性，導出基本可執(zhí)行路徑集合，設計測試用例的方法。設計出的測試用例要保證在測試中，程序的每一個可執(zhí)行語句至少要執(zhí)行一次。1.程序的控制流圖符號○為控制流圖的一個結點，表示一個或多個無分支的PDL語句或源程序語句。箭頭為邊，表示控制流的方向。流圖說明在選擇或多分支結構中，分支的匯聚處應有一個匯聚結點。邊和結點圈定的區(qū)域叫做區(qū)域，當對區(qū)域計數(shù)時，圖形外的區(qū)域也應記為一個區(qū)域。如果判斷中的條件表達式是由一個或多個邏輯運算符(OR,AND,...)連接的復合條件表達式，則需改為一系列只有單個條件的嵌套的判斷。2.程序環(huán)路復雜性程序的環(huán)路復雜性給出了程序基本路徑集中的獨立路徑條數(shù)，這是確保程序中每個可執(zhí)行語句至少執(zhí)行一次所必需的測試用例數(shù)目的上界。從控制流圖來看，一條獨立路徑是至少包含有一條在其它獨立路徑中從未有過的邊的路徑。例如在圖示的控制流圖中，一組獨立的路徑是

path1：1-11

path2：1-2-3-4-5-10-1-11

path3：1-2-3-6-8-9-10-1-11

path4：1-2-3-6-7-9-10-1-11路徑path1，path2，path3，path4組成了控制流圖的一個基本路徑集。3.導出測試用例導出測試用例，確?；韭窂郊械拿恳粭l路徑的執(zhí)行。根據(jù)判斷結點給出的條件，選擇適當?shù)臄?shù)據(jù)以保證某一條路徑可以被測試到—用邏輯覆蓋方法。每個測試用例執(zhí)行之后，與預期結果進行比較。如果所有測試用例都執(zhí)行完畢，則可以確信程序中所有的可執(zhí)行語句至少被執(zhí)行了一次。測試覆蓋要求對單元測試來說，語句覆蓋和分支覆蓋是最基本的要求。由于程序中錯誤（異常）處理工作的重要性以及其結構相對簡單，要求錯誤處理要做到路徑覆蓋。對質量要求高的軟件單元，可根據(jù)情況提出條件覆蓋、分支／條件覆蓋、條件組合覆蓋以及其它更高的覆蓋要求。STARTINPUT(A,B,C)//判定表達式1IFA>5THENX=10ELSEX=1ENDIF//判定表達式2IFB>10THENY=20ELSEY=2ENDIF練習//判定表達式3IFC>15THENZ=30ELSEZ=3ENDIFPRINT(X,Y,Z)STOP設計下列偽碼程序的語句覆蓋和路徑覆蓋測試用例：作業(yè)（第7章）序號判定輸入預期的輸出123ABCXYZ1FFF1111232TTT204060102030語句覆蓋的測試用例序號判定輸入預期的輸出123ABCXYZ1FFF1111232FFT116012303FTF140112034FTFF201110236TFT20160102307TTF20401102038TTT204060102030路徑覆蓋的測試用例90

黑盒測試法把程序看成一個黑盒子，完全不考慮程序的內部結構和處理過程。黑盒測試是在程序接口進行的測試，它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)產生正確的輸出信息，并且保持外部信息(如，數(shù)據(jù)庫或文件)的完整性。

黑盒測試又稱為功能測試。黑盒測試

91黑盒測試力圖發(fā)現(xiàn)下述類型的錯誤：①功能不正確或遺漏了功能；②界面錯誤；③數(shù)據(jù)結構錯誤或外部數(shù)據(jù)庫訪問錯誤；④性能錯誤；⑤初始化和終止錯誤。白盒測試在測試過程的早期階段進行，而黑盒測試主要用于測試過程的后期。黑盒測試故意不考慮程序的控制結構，而把注意力集中于信息域。黑盒測試等價類劃分邊值分析錯誤推測因果圖一.等價類劃分等價類劃分是一種典型的黑盒測試方法，使用這一方法時，完全不考慮程序的內部結構，只依據(jù)程序的規(guī)格說明來設計測試用例。使用這一方法設計測試用例要經(jīng)歷劃分等價類（列出等價類表）和選取測試用例兩步。劃分等價類所謂等價分類，就是把輸入數(shù)據(jù)的可能值劃分為若干等價類(等價類是指某個輸入域的子集合。在該集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等價的)。因此，可以把全部輸入數(shù)據(jù)合理地劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件，這樣就可以少量的代表性測試數(shù)據(jù)，來取得較好的測試結果。有效等價類和無效等價類①

有效等價類：是指對于程序的規(guī)格說明來說，是合理的，有意義的輸入數(shù)據(jù)構成的集合。②

無效等價類：是指對于程序的規(guī)格說明來說，是不合理的，無意義的輸入數(shù)據(jù)構成的集合。在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。劃分等價類等價類的原則：1如果輸入條件規(guī)定了取值范圍，或值的個數(shù)，則可以確立一個有效等價類和兩個無效等價類。例如對輸入“……項數(shù)可以從1到999……”

則有效等價類是“1≤項數(shù)≤999”兩個無效等價類是“項數(shù)＜1”或“項數(shù)＞999” 劃分等價類等價類的原則：2如果輸入條件規(guī)定了輸入值的集合，或者是規(guī)定了“必須如何”的條件，這時可確立一個有效等價類和一個無效等價類。例如在Pascal語言中對變量標識符規(guī)定為“以字母打頭的……串”所有以字母打頭的構成有效等價類不在此集合內（不以字母打頭）的歸于無效等價類。劃分等價類等價類的原則：4如果規(guī)定了輸入數(shù)據(jù)的一組值，而且程序要對每個輸入值分別進行處理。這時可為每一個輸入值確立一個有效等價類，此外針對這組值確立一個無效等價類，它是所有不允許的輸入值的集合。例如，在教師上崗方案中規(guī)定對教授、副教授、講師和助教分別計算分數(shù)，做相應的處理。因此可以確定4個有效等價類為教授、副教授、講師和助教，一個無效等價類，它是所有不符合以上身分的人員的輸入值的集合。劃分等價類等價類的原則：3如果輸入條件是一個布爾量，則可以確定一個有效等價類和一個無效等價類。

劃分等價類等價類的原則：5如果規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則，則可以確立一個有效等價類（符合規(guī)則）和若干個無效等價類（從不同角度違反規(guī)則）。例如，Pascal語言規(guī)定“一個語句必須以分號‘;’結束”。這時，可以確定一個有效等價類“以‘;’結束”，若干個無效等價類“以‘:’結束”、“以‘,’結束”、“以‘’結束”、“以LF結束”等。注意點1、劃分等價類不僅要要考慮代表“有效”輸入值的有效等價類，還需考慮代表“無效”輸入值的無效等價類。2、每一無效等價類至少要用一個測試用例，不然就可能漏掉某一類錯誤，但允許若干有效等價類合用同一個測試用例，以便進一步減少測試的次數(shù)。確立測試用例在確立了等價類之后，建立等價類表，列出所有劃分出的等價類。確立測試用例再從劃分出的等價類中按以下原則選擇測試用例：

(1)

為每一個等價類規(guī)定一個唯一編號；

(2)

設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步，直到所有的有效等價類都被覆蓋為止；

(3)

設計一個新的測試用例，使其僅覆蓋一個尚未被覆蓋的無效等價類，重復這一步，直到所有的無效等價類都被覆蓋為止。等價類劃分設計測試用例實例某一PASCAL語言版本中規(guī)定：“標識符是由字母開頭，后跟字母或數(shù)字的任意組合構成。有效字符數(shù)為8個，最大字符數(shù)為80個?！薄皹俗R符必須先說明，再使用。”“在同一說明語句中，標識符至少必須有一個。”

建立輸入等價類表覆蓋所有等價類的測試用例①VARx，T1234567：REAL；BEGINx:=3.414；T1234567:=2.732；...…(1),(2),(4),(8),(9),(12),(14)②VAR：REAL；(3)③VARx，：REAL;(5)

④VART12345678：REAL；(6)⑤VART12345......：REAL；(7)多于80個字符⑥VART$：CHAR；(10)⑦VARGOTO：INTEGER；(11)⑧VAR2T：REAL；(13)⑨VARPAR：REAL；BEGIN......PAP:=SIN(3.14*0.8)/6；(15)107

某工廠公開招工，規(guī)定報名者年齡應在16周歲至35周歲之間（到2005年4月30日止）。輸入格式為4位年份+2位月份的數(shù)字表示，如190012，出生年齡不在上述范圍內，將拒絕接受，并顯示“年齡不合格”等出錯信息。“出生年月”的等價類第一步：劃分等價類例108第二步：設計測試用例二.邊值分析長期經(jīng)驗表明：大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部邊界是指相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況使用邊界值分析方法設計測試用例，應對確定的邊界，選取正好等于，剛剛大于，或剛剛小于邊界的值做為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值做為測試數(shù)據(jù)示例在做三角形計算時，要輸入三角形的三個邊長A、B和C這三個數(shù)值應當滿足A＞0、B＞0、C＞0、A＋B＞C、A＋C＞B、B＋C＞A如果把六個不等式中的任何一個大于號“＞”錯寫成大于等于號“≥”，那就不能構成三角形問題恰出現(xiàn)在容易被疏忽的邊界附近邊值分析使用原則如果輸入條件規(guī)定了取值范圍或數(shù)據(jù)個數(shù)，則可選擇正好等于邊界值、剛剛在邊界范圍內和剛剛超越邊界外的值進行測試針對規(guī)格說明的每個輸入條件，使用上述原則對于有序數(shù)列，選擇第一個和最后一個邊界值分析法與等價類劃分法區(qū)別邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。被測試子域測試內點測試外點

如果在懸崖峭壁邊可以自信地安全行走，平地就不在話下。如果軟件在能力達到極限時能夠運行，那么在正常情況下就不會出什么問題。軟件邊界與懸崖很類似113招工年齡的邊界值分析（部分）年齡對應輸入：月份對應輸入：最大合格年齡：年月值為35周歲最小合格年齡：年月值為16周歲恰大于最大合格年齡：年月值比35周歲大1月恰小于最小合格年齡：年月值比16周歲小1月最大月份：12最小月份：01恰大于最大月份：13恰小于最小月份：00輸入條件出生日期的類型及長度1個數(shù)字字符5個數(shù)字字符7個數(shù)字字符有1個非數(shù)字字符全部是非數(shù)字字符6個數(shù)字字符顯示出錯顯示出錯顯示出錯顯示出錯顯示出錯輸入有效日期范圍月份范圍“招工年齡（6位數(shù)字字符）”邊界值分析法測試用例測試用例說明測試數(shù)據(jù)期望結果選取理由51970519700051970.5MAY---197005月份為1月月份為12月月份<1月份>12197001197012197000197013197003198904197002198905輸入有效輸入有效顯示出錯顯示出錯輸入有效輸入有效顯示出錯顯示出錯在有效范圍邊界上選取數(shù)據(jù)僅有1個合法字符比有效長度少1比有效長度多1只有1個非法字符6個非法字符類型及長度均有效最小日期最大日期剛好小于最小日期剛好大于最大日期最小月份最大月份剛好小于最小月份剛好大于最大月份115人們也可以靠經(jīng)驗和直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子。這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況，根據(jù)它們選擇測試方案。三.錯誤推測錯誤猜測法—看一個頗有啟發(fā)的故事

發(fā)生在美國通用汽車的客戶與該公司客服部間的真實故事

一天美國通用汽車公司的客服收到一封客戶抱怨信,這樣寫的：我們家有一個傳統(tǒng)的習慣,就是每天晚餐后,會吃冰淇淋甜點,我開車去買。奇怪的是每當我買香草口味的冰激凌，車子就發(fā)不動。但如果我買的是其他的口味,車子發(fā)動就順得很.難道你們的車對香草冰激凌過敏？

客服經(jīng)理心存懷疑,但他還是派了一位工程師去查看究竟。工程師與這位仁兄上車，往冰淇淋店開去，買香草口味，當回到車上后，車子起不動了。這位工程師之后又依約來了三個晚上：第1晚巧克力冰淇淋，車子沒事；第2晚草莓冰淇淋，車子也沒事；第3晚香草冰淇淋，車子又不動了。

工程師開始記下從頭到現(xiàn)在所發(fā)生的種種詳細資料，如時間、車子使用油的種類、車子開出及開回的時間……，根據(jù)資料顯示他有了一個結論，這位仁兄買香草冰淇淋所花的時間比其它口味的要少。為什么呢？原因是香草冰淇淋是所有冰淇淋口味中最暢銷的口味，店家為了讓顧客每次都能很快的取拿，將香草口味特別分開陳列在單獨的冰柜，時間比買其他口味的要快。

買其他口味冰激凌時由于時間較久，引擎有足夠的時間散熱，重新發(fā)動時就沒有太大的問題。買香草口味時，由于花的時間較短，引擎太熱以至于還無法讓“蒸氣瑣”有足夠的散熱時間。

有時問題看起來真的是瘋狂，但它是真正存在的；我們應保持冷靜的思考去找尋解決的方法。117例：數(shù)據(jù)排序程序的測試用邊界值分析法設計以下測試用例：①輸入表為空表；②輸入表中僅有一個數(shù)據(jù)；③輸入表為滿表。用錯誤猜測法補充如下用例：④輸入表已經(jīng)排好序；⑤輸入表的數(shù)據(jù)順序恰好于要求的順序相反；⑥輸入表中的數(shù)據(jù)完全相同四.因果圖法適用范圍：如果在測試時必須考慮輸入條件的各種組合，可使用一種適合于描述對于多種條件的組合，相應產生多個動作的形式來設計測試用例，這就需要利用因果圖。因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。因果圖的基本步驟(1)

分析軟件規(guī)格說明描述中，哪些是原因(即輸入條件或輸入條件的等價類)，哪些是結果(即輸出條件)，并給每個原因和結果賦予一個標識符。(2)

分析軟件規(guī)格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系?根據(jù)這些關系，畫出因果圖。(3)

由于語法或環(huán)境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。(4)

把因果圖轉換成判定表。(5)

把判定表的每一列拿出來作為依據(jù)，設計測試用例。因果圖基本符號通常在因果圖中用Ci表示原因，用Ei表示結果，各結點表示狀態(tài)，可取值“0”或“1”。“0”表示某狀態(tài)不出現(xiàn)，“1”表示某狀態(tài)出現(xiàn)。主要的原因和結果之間的關系有:因果圖基本符號表示約束條件的符號：為了表示原因與原因之間，結果與結果之間可能存在的約束條件，在因果圖中可以附加一些表示約束條件的符號。示例有一個處理單價為5角錢的飲料的自動售貨機軟件測試用例的設計。其規(guī)格說明如下：

若投入5角錢或1元錢的硬幣，押下〖橙汁〗或〖啤酒〗的按鈕，則相應的飲料就送出來。若售貨機沒有零錢找，則一個顯示〖零錢找完〗的紅燈亮，這時在投入1元硬幣并押下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示〖零錢找完〗的紅燈滅，在送出飲料的同時退還5角硬幣?！笔纠?1)分析這一段說明，列出原因和結果

原因:1.

售貨機有零錢找

2.

投入1元硬幣

3.

投入5角硬幣

4.

押下橙汁按鈕

5.

押下啤酒按鈕 建立中間結點，表示處理中間狀態(tài)

11.

投入1元硬幣且押下飲料按鈕

12.

押下〖橙汁〗或〖啤酒〗的按鈕

13.

應當找5角零錢并且售貨機有零錢找

14.

錢已付清示例

結果：21.售貨機〖零錢找完〗燈亮

22.退還1元硬幣

23.退還5角硬幣

24.送出橙汁飲料

25.送出啤酒飲料(2)畫出因果圖。所有原因結點列在左邊，所有結果結點列在右邊。

(3)由于2與3，4與5不能同時發(fā)生，分別加上約束條件E。(4)因果圖(5)轉換成判定表

因果圖方法實例某電力公司有A、B、C、D四類收費標準,并規(guī)定：居民用電<100度/月按A類收費≥100度/月按B類收費動力用電<10000度/月,非高峰,B類收費≥10000度/月,非高峰,C類收費

<10000度/月,高峰,C類收費≥10000度/月,高峰,D類收費用因果圖表明輸入和輸出間的邏輯關系1I12AB∨∧C435∧DI4I3I2∨∧∧∧∧因果<100居民動力<10000非高峰把因果圖轉換為判定表組合條件條件(原因)動作(結果)ABC123123456101100011000110000100001104101050011D000110010000測試用例為判定表每一列設計一個測試用例:1列居民電,90度/月A2列居民電,110度/月B3列動力電,非高峰,8000度/月B4列動力電,非高峰,1.2萬度/月C5列動力電,高峰,0.9萬度/月C6列動力電,高峰,1.1萬度/月D

條件測試用例預期結果組合(輸入數(shù)據(jù))(輸出動作)測試策略測試步驟測試結果分析測試大綱項目編號：第

次測試1234硬件環(huán)境運行是否正常網(wǎng)絡環(huán)境運行是否正常系統(tǒng)軟件運行是否正常防病毒處理結果模塊編號測試結果當某一測試結果為’√’時表示通過，為’×’時表示還存在錯誤。本表內容不足以記錄時，可以在附頁填寫，總頁數(shù)可用鉛筆填寫。模塊編號按模塊依據(jù)從屬關系或按層次編號。測試問題卡--測試員：項目編號：序號模塊編號錯誤現(xiàn)象等級頻率時機改否修改者簽字上表解釋“等級”是指錯誤等級，可分為A：嚴重影響系統(tǒng)運行；B：影響系統(tǒng)運行；C：不影響運行但必須修改；D：所提建議?！邦l率”指錯誤出現(xiàn)頻率，分為A：操作即出現(xiàn)；B：偶爾出現(xiàn)?！皶r機”指錯誤出現(xiàn)時機，分為A：修改后出現(xiàn)；B：已發(fā)現(xiàn)但未修改；C：首次出現(xiàn)?！案姆瘛表椨砷_發(fā)人員填寫，如果已修改該問題，填“√”，否則為空?！敖ㄗh返回時間”指要求開發(fā)人員在某時間之前，將修改后的軟件返回給測試人員重新測試。測試用例模版：測試用例編號：

項目名稱：模塊名稱

模塊編號項目開發(fā)經(jīng)理

測試負責人功能簡述操作步驟測試用例描述：測試輸入

預期結果預期時間

測試過程說明

備注：上表解釋測試用例描述：用于說明本測試用例的測試要點。操作步驟：用于描述執(zhí)行該功能的基本操作。操作過程及測試數(shù)據(jù)：用于描述測試用例的操作步驟及所使用的測試數(shù)據(jù)。此項內容根據(jù)測試用例的復雜性選擇使用，對沒有必要寫明操作步驟的此項可省略預期結果和驗證過程：這兩項內容用于記錄測試用例正確執(zhí)行應得到的結果，預期結果多用于描述界面上可見結果。驗證過程多用于界面上無可見結果但在其它操作中可驗證的過程。預期結果和驗證過程根據(jù)實際需要均可省略，但至少要有一項以明確測試結果。運行預期時間；該項對在運行時間上有要求的，或通過運行時間能反映執(zhí)行情況的測試用例使用。備注：用于記錄該測試用例執(zhí)行的一些特殊說明，如必須先運行某測試用例。12.5單元測試單元測試是軟件測試環(huán)節(jié)中最基本的測試，測試的對象是獨立的模塊。單元測試開始之前要先通過編譯程序檢查并改正語法錯誤，然后用詳細設計說明書作為指南對模塊的功能和模塊代碼中的重要執(zhí)行路徑及主要算法進行測試。單元測試可以對多個模塊同時進行。單元測試主要分為人工靜態(tài)檢查和動態(tài)執(zhí)行跟蹤兩個步驟進行。人工靜態(tài)檢查主要是保證算法代碼實現(xiàn)的正確性和高效性，代碼編寫清晰、規(guī)范。經(jīng)驗表明，使用人工靜態(tài)檢查法能夠有效的發(fā)現(xiàn)30%--70%的邏輯設計和編碼錯誤。成立一個3—4人的代碼審查小組，包括經(jīng)驗豐富的測試人員、被測程序的作者和其他程序員。被測程序的作者講述程序的邏輯結構，大家發(fā)現(xiàn)問題可隨時提問，以判斷是否存在錯誤。方法檢查算法實現(xiàn)的正確性。確定所編寫的代碼和定義的數(shù)據(jù)結構實現(xiàn)了模塊或方法所要求的功能。檢查模塊接口的正確性。檢查模塊的參數(shù)個數(shù)、類型、順序是否正確，確定返回值的正確性。調用其他方法接口的正確性。檢查實參類型、數(shù)值、個數(shù)的正確性，特別是具有多態(tài)性的方法。檢查返回值的狀態(tài)，最好對每個被調用方法的返回值用顯式代碼做正確性檢查，如果被調用方法出現(xiàn)異?；蝈e誤，程序應該給予反饋，并添加適當?shù)某鲥e處理代碼。出錯處理。模塊代碼要求能預見出錯的條件，并設置適當?shù)某鲥e處理，這種出錯處理應當是模塊功能的一部分。若出現(xiàn)下列情況之一，則表明模塊的錯誤處理功能不夠完善：出錯信息描述難以理解；錯誤信息的描述不足以對錯誤定位，不足以確定出錯原因顯示的錯誤信息與實際的錯誤原因不符；對錯誤條件的處理不正確；在對錯誤進行處理之前，錯誤條件已經(jīng)引起系統(tǒng)的干預等保證表達式、SQL語句的正確性。表達式應該保證不含二義性，對于容易產生歧義的表達式或運算符優(yōu)先級（如《、=、》、&&、||、++、--等）可以采用括號“（）”運算符避免二義性，這樣一方面能夠保證代碼的正確可靠，同時也能夠提高代碼的可讀性。檢查常量或全局變量使用是否正確。標識符定義是否規(guī)范一致。保證