軟件工程綜合第一頁，共92頁。2軟件規模估算1、代碼行技術代碼行技術是從過去開發類似產品的經驗和數據出發，估算出所開發軟件的代碼行數。采用代碼行數以LOC，常用千行代碼數KLOG來度量。（1KLOG=103LOC）代碼行技術方法首先給出軟件的范圍描述；將項目分解的盡可能小，且可獨立估算的子功能，估算每一個子功能并將其代碼行累加得到整個系統的代碼行數。第二頁，共92頁。3代碼行技術方法：為了更客觀、準確，代碼行估算可以由多名有經驗的開發人員分別給出，最終計算出所有估算的平均值。開發人員還可以提出一個有代表性的估算值范圍，分別按照最佳（a）、可能（m）、悲觀（b）給出估算值。利用下列公式計算期望值：代碼行期望值：L=(a+4m+b)/6其中：a:最佳值；m：可能值；b：悲觀值軟件規模估算第三頁，共92頁。4進一步度量軟件開發的其他規模指標軟件生產率：P＝kLOC/PM，

其中：PM為軟件開發總的工作量，常用人月（PM）度量，這樣P就為每人月完成的千行代碼數。每千行代碼的平均成本：C=S/kLOC，

即：軟件每行代碼的平均成本，S用人民幣（或其它貨幣）進行表示。注意：工作量和成本是指整個軟件工程活動（包括分析、設計、編碼和測試）的工作量和成本，而不僅僅指編碼活動，文檔代碼比D=Pe/kLOC；Pe為軟件項目相關文檔頁數代碼錯誤率EQR=N/kLOC；N為代碼中的總錯誤數。軟件規模估算第四頁，共92頁。5軟件規模估算優點簡單方便，在數據可靠的情況下可以很快估算出比較準確的代碼行數。可度量軟件代碼的生成率、開發每行代碼的平均成本、文檔與代碼的比例關系、每千行代碼的軟件錯誤數等缺點需要依賴比較詳細的功能分解，難以在開發初期進行估算估算結果與所用開發語言緊密相關，無法適用于非過程語言第五頁，共92頁。6例如：某軟件公司統計發現該公司每一萬行C語言源代碼形成的源文件約為250K。某項目的源文件大小為3.75M，則可估計該項目源代碼大約為15萬行，該項目累計投入工作量為240人月，每人月費用為10000元（包括人均工資，福利,辦公費用公灘等），則該項目中1LOC的價值為：（240×10000）/150000＝16元/LOC那么，項目的人月均代碼行數為：150000/240=625LOC/人月。軟件規模估算第六頁，共92頁。7在軟件公司中，常用一個表格來記錄項目中面向規模的度量。表1軟件項目記錄表2軟件項目規模估算示例

項目工作量（人月）成本（千元）代碼行KLOC文檔頁數錯誤審計項目609002002500300書店管理24150145123089酬金管理101205585021項目代碼行KLOC每行代碼成本C文檔代碼比D代碼錯誤率EQR審計項目2004.512.51.5書店管理1451.038.480.61酬金管理552.1815.450.38軟件規模估算第七頁，共92頁。8軟件規模估算2、功能點技術：依據軟件信息域的基本特征和對軟件復雜性的估計，估算出軟件規模。軟件信息域的5個基本特征，包括：外部輸入、外部輸出、外部查詢、內部邏輯文件和外部接口。外部輸入：用戶進行添加或修改數據的屏幕或表格外部輸出：軟件為用戶產生的輸出屏幕或報表外部查詢：軟件以聯機輸出方式產生的獨立查詢內部邏輯文件：軟件修改或保存的邏輯記錄集合外部接口：與其他系統進行信息交換或共享的文件這種方法適合于在軟件開發初期進行估算，并以功能點為單位度量軟件規模。第八頁，共92頁。9功能點估計方法步驟：1)計算外部輸入、外部輸出、外部查詢、內部邏輯文件和外部接口的數目；2)每類特征劃分為簡單、中等和復雜三個等級，每一個特征在不同等級上將分配不同的加權因子。如，每類特征加權因子確定為：簡單：輸入3、輸出4、查詢3，主控文件7、接口5；中等：輸入4、輸出5、查詢4，主控文件10、接口7；復雜：輸入6、輸出7、查詢6，主控文件25、接口10然后，將這些數據進行加權乘軟件規模估算第九頁，共92頁。103)估計者根據軟件受到的多種技術因素的影響，如：性能、數據處理、可維護性等多種技術的影響，再對計算出的未調整功能點總數（UFP）進行適當的調整。如P52表列出的14種技術因素，Fi的取值為0~5，：F1:系統需要可靠的備份和恢復嗎？F2:系統需要數據通信嗎？…Fi，定義為：1：偶然影響、2：輕度影響、3：一般影響：4：重要影響、5：非常重要影響軟件規模估算第十頁，共92頁。11軟件規模估算第十一頁，共92頁。12舉例：軟件規模估算例：某公司大約有3000名員工，準備開發一個簡單的工資系統系統要求用戶從屏幕上輸入員工的基本信息（包括員工編號、基本工資、所在等級、所屬部門等）和每月的考勤情況，這兩個屏幕輸入的復雜度為“復雜”；另外，還有一個所得稅信息的輸入，其復雜度為“中等”。系統生成員工的工資單，列出工資的所有收入項和納稅扣除額，并在屏幕上顯示工資單，工資單的功能復雜度是“復雜”；另外，系統產生7個報表，每個報表的復雜度是“簡單”。系統提供20個查詢，每個查詢的復雜度是“簡單”。系統內部維護一個員工信息文件，該文件的復雜度是“復雜”。系統引用了3個數據表，包括員工基本信息、部門信息和所在等級，其中員工基本信息的復雜度是“中等”，其他兩個的復雜度是“簡單”。第十二頁，共92頁。13舉例：軟件規模估算計算未調整功能點第十三頁，共92頁。14舉例：軟件規模估算計算調整后的功能點第十四頁，共92頁。15舉例：軟件規模估算部分開發語言中一個功能點對應的代碼行數行（LOC）/功能點(FP)假設用VB開發,源程序行數SLOC＝24×138＝3312第十五頁，共92頁。16軟件成本估算軟件成本估算一般包括：專家判斷、類比估算和經驗模型等3種技術。自上而下方法對整個項目的總開發時間和總工作量做出估算，然后把它們按階段、步驟和工作單元進行分配；自下而上方法分別估算各工作單元所需的開發時間，然后匯總得出總的工作量和開發時間。第十六頁，共92頁。17專家判斷專家判斷是依靠一個或多個專家對項目成本作出估計，這是一種近似的猜測，要求專家具有專門知識和豐富的經驗。Delphi方法是最流行的專家評估技術，它鼓勵參與者就問題相互討論，互相說服對方，最終達成共識。步驟：協調人向各專家提供項目規格和估計表格；專家匿名填寫迭代表格；協調人匯總，返回專家；如估計差異較大；專家復查估計，總結、迭代，重新提交估計；重復，直到達到一個最低和最高估計的一致。軟件成本估算第十七頁，共92頁。18軟件成本估算第十八頁，共92頁。19軟件成本估算類比估算類比估算適合評估一些與項目在應用領域、環境和復雜度上相似的項目，通過新項目與項目的比較得到成本估算。類比估算的精確度取決于項目數據的完整性和準確度。步驟：整理出項目功能列表和實現每個功能的代碼行；標識出每個功能與項目的相同點/不同點；通過步驟1和2得出各個功能的估計值，產生成本的估計。注：軟件項目中的類比法，往往還要解決可重用代碼的估算問題。第十九頁，共92頁。20重用代碼量的估計:由程序員或系統分析員詳細地考查已存在的代碼。新項目可重用的代碼中需重新設計的百分比；需重新編碼或修改的百分比；需重新測試的百分比。利用計算公式計算等價新代碼行：等價代碼行=[(重新設計%+重新編碼%+重新測試%)/3]×已有代碼行

軟件成本估算第二十頁，共92頁。21例如：有10,000行代碼重用，假定30%要重新設計，50%要重新編碼，70%要重新測試，那么其等價的代碼行可以計算為：[(30%+50%+70%)/3]×10,000=5,000等價代碼行.意即：重用這10000代碼相當于編寫5000代碼行的工作量。軟件成本估算第二十一頁，共92頁。22軟件成本估算COCOMO模型結構性成本模型COCOMO（ConstructiveCostMOdel）是一種利用經驗模型進行成本估算的方法基本COCOMO模型這是一個靜態單變量模型，用一個以源代碼行數為自變量的經驗函數來計算軟件開發工作量。計算公式：E=aLbD=cEdE:開發工作量（人月），D:開發時間（月），L:千行代碼數，a,b,c與軟件系統有關。第二十二頁，共92頁。23軟件成本估算中間COCOMO模型中間COCOMO模型以基本COCOMO模型為基礎，通過對影響工作量的若干因素進行估計，確定出調節因子，再對工作量估算公式進行修正。計算公式E＝aLbFE:開發工作量（人月），F是調節因子，與計算機環境、人員和項目等因素有關，見表3－9，L:千行代碼數，a,b取值見表3－8。第二十三頁，共92頁。24軟件成本估算第二十四頁，共92頁。25舉例：軟件成本估算如：工資系統用Vb開發，代碼行數3312第二十五頁，共92頁。26軟件項目計劃軟件項目計劃是一個用來協調所有其他計劃、以指導項目實施和控制的文件，它應該隨著項目的進展和信息的補充進行定期完善。軟件項目計劃包括項目可用的資源、工作分解以及完成工作的進度安排，另外還有各種支持性計劃。質量計劃：描述質量過程和質量標準確認計劃：描述系統確認的方法、資源和進度配置管理計劃：描述配置管理的過程和結構維護計劃：預期系統維護需求和所需的成本與人力人員開發計劃：描述如何開發項目人員的技能和經驗第二十六頁，共92頁。27軟件項目計劃項目進度計劃的過程工作分解將項目整體分解成較小的、易于股哪里和控制的若干子項目或工作單元，直到可交付成果定義的足夠詳細，足以支持將來的活動第二十七頁，共92頁。28項目工作分解模板：按照項目實施過程的順序分解第二十八頁，共92頁。29甘特圖第二十九頁，共92頁。30SPMP（IEEE1058－1998）軟件項目管理計劃（SoftwareprojectManagementPlan，SPMP）用來協調所有其他計劃、以指導項目實施和控制的文件記錄計劃的假設條件以及方案選擇；確定關鍵管理審查的內容、范圍和時間；為進度評測和項目控制提供一個基線。第三十頁，共92頁。31SPMP（IEEE1058－1998）第三十一頁，共92頁。32本節掌握內容軟件項目規劃三步需求分析；分解任務、估算規模、成本，寫出計劃書規模估算代碼行技術步驟：確定范圍、分解功能、估算千行代碼數期望值：L=(a+4m+b)/6軟件生產率:P=kLOC/PM；千行代碼成本：C=S/kLOC文檔代碼比：P=Pe/kLOC；錯誤代碼率：EQR=N/kLOC功能點技術5個基本特征數：外部輸入、外部輸出、外部查詢、內部邏輯文件、外部接口步驟：計算特征數；劃分等級加權乘；Fi]第三十二頁，共92頁。33掌握內容成本估算專家判斷：Delphi方法（迭代方法）類比估算列出功能點和實現代碼行；分析不同點/相同點，估算成本重碼工作量計算COCOMO方法計算基本模型：E=aLbD=cEd修正：E＝aLbF,a,b,c,d:應用程序、實用程序編譯等；控制程序，操作系統。第三十三頁，共92頁。34內容提綱人員組織與管理軟件項目組織形式、微軟公司的開發團隊項目溝通管理醒目溝通的復雜性與活動軟件項目規劃軟件項目估算與計劃軟件風險管理風險識別、風險分析、風險規劃、風險監控軟件配置管理軟件配置管理的概念與活動第三十四頁，共92頁。35軟件風險管理項目風險是一種不確定的事件或情況，一旦的發生，就會對項目目標產生正面或負面的影響。風險分為兩類：可預見風險：可以根據開發經驗或邏輯推理來預見的，是可以計劃和管理的。不可預見風險：不能根據所擁有的資料進行預見的，是不可計劃和管理的，要求做好應急措施。風險管理是IT軟件項目減少失敗的一種重要手段。采取結構化風險管理來發現計劃中的缺陷采取行動來減少潛在問題發生的可能性和影響在危機發生之前就對它進行處理這樣就會提高項目成功的機會和減少不可避免風險所產生的后果第三十五頁，共92頁。36舉例：軟件項目的一些風險類型可能的風險技術數據庫事務處理速度不夠；擬采用的系統組件存在缺陷，影響系統功能。人員招聘不到所需技能的人員；關鍵的人員在項目的關鍵時刻生病或不在；無法進行所需的人員培訓。組織組織結構發生變化；組織財政問題導致項目預算削減。工具CASE工具生成的代碼效率低；CASE工具無法集成。需求需求變更導致主要的設計和開發重做；客戶無法理解需求變更帶來的影響。估算開發所需時間估計不足；缺陷修復估計不足；軟件規模估計不足。軟件開發項目由于自身的特點而具有極大風險第三十六頁，共92頁。37項目風險管理過程軟件風險管理是貫穿在項目開發過程中的一系列管理步驟。通過主動而系統地對項目風險進行全過程的識別、分析和監控，最大限度地降低風險對軟件開發的影響。第三十七頁，共92頁。38風險識別風險識別是試圖采用系統化的方法，識別特定項目已知的和可預測的風險，項目管理者就有可能避免這些風險，必要時控制這些風險。常用的風險識別方法頭腦風暴法由項目小組根據項目目標、項目的制約因素和假設條件，在項目具有的資料以及過去的經驗教訓等基礎上綜合判斷項目的可能風險。風險檢查表列出了所有可能的與每一個風險因素有關的提問，使項目管理者可以集中識別常見的、已知的和可預測的風險，諸如軟件規模、商業影響、客戶特性、軟件過程、開發技術、開發環境、開發人員等方面的風險。第三十八頁，共92頁。39舉例：頭腦風暴法舉例：識別舉辦短期培訓班項目的風險列出項目的工作分解結構；項目小組一起進行頭腦風暴，對每一項任務進行討論，識別所有可能的風險，防止遺漏重要的風險。第三十九頁，共92頁。40舉例：頭腦風暴法可能的風險確定培訓項目題目選擇不當，可能招不來學生，導致虧本。尋找培訓講師講師可能生病或者臨時有重要事情來不了。招生可能沒有學員報名。授課投影儀可能出問題。結束課程學員不滿意，大鬧課堂。問題：還有哪些可能的風險？第四十頁，共92頁。41舉例：風險檢查表第四十一頁，共92頁。42舉例：風險檢查表第四十二頁，共92頁。43風險分析風險分析是對已識別的風險進行估計和評價，確定風險發生的概率與后果。定性分析評估已識別出的項目風險的影響和可能性，并按照可能產生的影響進行排序。定量分析量化分析每一風險的概率及其對項目目標造成的后果，并得出每種風險的大小和嚴重程度等。軟件開發風險通常包括性能、成本、支持和進度等，這些風險對項目目標可能產生的影響可以劃分為可忽略的、輕微的、嚴重的、災難性的等四個級別。第四十三頁，共92頁。44舉例：軟件項目風險分析第四十四頁，共92頁。45風險規劃在識別和分析項目風險之后，項目管理者應該關注那些影響較大的風險，并制定出具體的風險應對策略。常用的風險應對策略包括風險規避、風險緩解、風險轉移、風險接受等。風險規避是設法降低風險出現的可能性風險緩解是設法減少風險產生的影響風險轉移是將風險轉移給第三方風險接受是采取應急方案應對風險的發生第四十五頁，共92頁。46舉例：風險應對策略第四十六頁，共92頁。47風險監控風險監控是跟蹤和監視項目的執行狀態，洞察由于人員、技術、環境等方面的變化而給項目目標實現產生的影響。監控風險發生的情況，及早發現風險事件的征兆和苗頭監控風險管理計劃的落實情況，確保該計劃的有效實施風險監控可能產生的結果隨機應變措施糾正行動變更請求修改風險應對計劃第四十七頁，共92頁。48舉例：風險監控類型潛在的跡象技術硬件或支持軟件拖延交付，許多技術問題暴露出來人員員工士氣低落，團隊成員關系不融洽，工作分配不當組織組織內流言蜚語，缺少高層管理的支持工具團隊成員不愿使用工具，抱怨CASE工具需求很多需求變更請求和客戶怨言估算無法達到規定的進度，無法消除已發現的缺陷第四十八頁，共92頁。49內容提綱人員組織與管理軟件項目組織形式、微軟公司的開發團隊項目溝通管理醒目溝通的復雜性與活動軟件項目規劃軟件項目估算與計劃軟件風險管理風險識別、風險分析、風險規劃、風險監控軟件配置管理軟件配置管理的概念與活動第四十九頁，共92頁。白盒測試及測試用例設計語句覆蓋判定覆蓋條件覆蓋判定—條件覆蓋條件組合覆蓋路徑覆蓋。常用的白盒測試方法：邏輯覆蓋測試，基本路徑測試，數據流測試，循環測試。（1）邏輯覆蓋:以程序內部的邏輯結構為基礎設計測試用例的方法，關注對程序邏輯的覆蓋程度。第五十頁，共92頁。例:PROCEDURESAMPAL(A，B：REAL；VARX：REAL);BEGINIF(A>1)AND(B=0)THENX:=X/AIF(A=2)OR(X>1)THENX:=X+1END;例：對下列子程序進行測試白盒測試及測試用例設計入口(A>1)AND(B=0)(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdce第五十一頁，共92頁。521）語句覆蓋:

被測程序中每個語句至少執行一次入口(A>1)AND(B=0)(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdce語句覆蓋是最弱的邏輯覆蓋測試數據預期結果B=0,A=2,X=4,,X=3白盒測試及測試用例設計第五十二頁，共92頁。532)判定覆蓋(分支覆蓋)：使每個判定的真假分支都至少執行一次測試數據預期結果執行路徑判定1判定2A=2,B=1,X=1x=2abeftA=3,B=0,X=3x=1acdtf兩組測試用例可覆蓋所有判定的真假分支,滿足判定覆蓋標準。

入口(A>1)AND(B=0)(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdce白盒測試及測試用例設計第五十三頁，共92頁。54入口(A>1)AND(B=0)(A=2)OR(X>1)返回X=X+1FFTTabdceX=X/A測試數據預期結果執行路徑覆蓋的條件A=2,B=0,X=1X=1.5aceA>1，B=0，A=2，X≤AA=1,B=1,X=2X=3abeA≤1，B≠0，A≠2，X>1未覆蓋d分支，條件覆蓋通常比判定覆蓋強，但有時不滿足判定覆蓋的要求，條件覆蓋不一定包含判定覆蓋，判定覆蓋也不一定包含條件覆蓋3)條件覆蓋:使每個判定的每個條件的可能取值至少執行一次A>1，B=0，A=2，X

AA

1，B0，A2，X>1白盒測試及測試用例設計第五十四頁，共92頁。.4)判定/條件覆蓋選取足夠多的測試用例，使判斷中的每個條件的所有可能取值至少執行一次，同時每個判斷本身的所有可能判斷結果至少執行一次。首先選擇路徑進行判定覆蓋測試，同時考慮條件覆蓋，這時就可能得到滿足判定/條件覆蓋標準的最少的測試用例。白盒測試及測試用例設計第五十五頁，共92頁。56測試數據預期結果執行路徑判定1判定2覆蓋的條件A=2,B=0,X=4X=3acettA>1,B=0;A=2,X>AA=1,B=1,X=1X=1abdffA≤1,B≠0;A≠2,X≤1滿足判定－條件覆蓋標準的測試用例個數總是大于等于滿足判定覆蓋標準和條件覆蓋標準的測試用例個數中的最大數。

4)判定/條件覆蓋A>1，B=0，A=2，X

≤

AA≤1，B≠0，A≠2，X>1判定1：T,F判定2：T,Fc入口(A>1)AND(B=0)(A=2)OR(X>1)返回FFTTabdeX=X/AX=X+1白盒測試及測試用例設計第五十六頁，共92頁。5)條件組合覆蓋條件組合覆蓋:選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定中的條件的所有可能組合都至少出現一次。必須注意的是，這里的條件組合是指每個判定中的條件的所有可能組合，而不是整個程序的所有條件的所有可能組合。白盒測試及測試用例設計第五十七頁，共92頁。58判定1中條件結果的所有可能組合有如下四種情況：（1）A>1，B=0；

（2）A>1，B≠0；

（3）A≤1，B=0；

（4）A≤1，B≠0；

入口(A>1)AND(B=0)(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdce白盒測試及測試用例設計5)條件組合覆蓋

第五十八頁，共92頁。59入口(A>1)AND(B=0)

(A=2)OR(X>1)返回X=X/AX=X+1FFTTabdce判定2中條件結果的所有可能組合有如下四種情況：（5）A=2,X>1(或X>A)；（6）A=2,x≤1(或X≤A)；

（7）A≠2,X>1(或X>A)；（8）A≠2,X≤1(或X≤A)。

5)條件組合覆蓋

白盒測試及測試用例設計第五十九頁，共92頁。60測試數據預期結果執行路徑判定1判定2覆蓋的條件A=2,B=0,X=4X=3acett①A>1，B=0⑤A=2，X>AA=2,B=1,X=1X=2abeft②A>1，B≠0⑥A=2，X≤1A=1,B=0,X=2X=3abeft③A≤1，B=0⑦A≠2，X>1A=1,B=1,X=1X=1abdff④A≤

1，B≠0⑧A≠2，X≤

1條件組合覆蓋是上述五種覆蓋標準中最強的一種，滿足條件組合覆蓋標準的測試用例一定也滿足判定覆蓋、條件覆蓋、判定/條件覆蓋、語句覆蓋標準。然而，條件組合覆蓋仍不能保證程序中所有可能的路徑都被覆蓋，如：acd沒有經過。第六十頁，共92頁。6)路徑覆蓋路徑覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每條可能執行到的路徑都至少經過一次（如包含環路，則每條環路至少經過一次）本例中所有可能執行的路徑有：ace（判斷1為“t”且判斷2為“t”）abd（判斷1為“f”且判斷2為“f”）abe（判斷1為“f”且判斷2為“t”）acd（判斷1為“t”且判斷2為“f”）。白盒測試及測試用例設計第六十一頁，共92頁。開始

(A>1)AND(B=0)

(A=2)OR(X>1)返回

X=X/A

X=X+1FFTTabdce測試數據預期結果執行路徑判定1判定2A=2，B=0，X=4X=3acettA=3，B=0，X=3X=1acdtfA=1，B=0，X=2X=3abeftA=1，B=1，X=1X=1abdff第六十二頁，共92頁。路徑覆蓋實際上考慮了程序中各種判定結果的所有可能組合，但它未必能覆蓋判定中條件結果的各種可能情況。它是一種比較強的覆蓋標準，但不能替代條件覆蓋、判定/條件覆蓋和條件組合覆蓋標準。6)路徑覆蓋白盒測試及測試用例設計第六十三頁，共92頁。邏輯覆蓋測試強調“運行這些測試用例時”覆蓋了被測程序的哪些判定、條件或路徑。語句覆蓋：對程序中每個語句至少執行一次；適合于簡單的順序語句；分支覆蓋：使每個判定的分支都至少執行一次，滿足語句覆蓋適合于簡單的分支語句；邏輯覆蓋小結：第六十四頁，共92頁。條件覆蓋：使每個判定的每個條件的可能取值至少執行一次條件覆蓋通常比判定覆蓋強，但條件覆蓋與判定覆蓋不一定相互包含；分支/條件覆蓋使判斷中的每個條件的所有可能取值至少執行一次，同時每個判斷本身的所有可能判斷結果至少執行一次。滿足判定/條件覆蓋的測試用例一定也滿足判定覆蓋、條件覆蓋、語句覆蓋，但條件組合欠缺邏輯覆蓋小結：第六十五頁，共92頁。條件組合覆蓋使得被測程序的每個判定中的條件結果的所有可能組合都至少出現一次。條件組合是指每個判定中的條件結果的所有可能組合，而不是整個程序的所有條件結果的所有可能組合。缺陷：沒有覆蓋所有的程序路徑。邏輯覆蓋小結：第六十六頁，共92頁。路徑覆蓋使得被測程序的每條可能執行到的路徑都至少經過一次。路徑覆蓋實際上考慮了程序中各種判定結果的所有可能組合，但它未必能覆蓋判定中條件結果的各種可能情況。它是一種比較強的覆蓋標準，但不能替代條件覆蓋、判定/條件覆蓋和條件組合覆蓋標準。邏輯覆蓋小結：根據程序代碼的情況選擇合適測試方法；根據測試的重點選擇合適的測試方法；第六十七頁，共92頁。基本路徑測試:基本路徑測試是TomMcCabe提出的一種白盒測試技術，這種方法步驟：

首先根據程序畫出控制流圖，并計算其區域數，然后確定一組獨立的程序執行基本路徑，最后為每一條基本路徑設計一個測試用例。在實際問題中，包含循環的程序其路徑數往往非常多，測試常常難以做到覆蓋程序中的所有路徑，如何把測試的程序路徑數壓縮到一定的范圍內？白盒測試及測試用例設計第六十八頁，共92頁。流圖：由節點和邊組成的一種簡單的控制流表示方法。首先，將含復合條件的設計圖轉化為只含簡單條件的設計圖a）含復合條件的設計圖a>borc>dx=1x=2tfy=0b）只含簡單條件的設計圖白盒測試及測試用例設計第六十九頁，共92頁。流圖：其次設計圖中一個連續的處理框（對應于程序中的順序語句）序列和一個判定框（對應于程序中的條件控制語句）映射成流圖中的一個節點；設計圖中的箭頭（對應于程序中的控制轉向）映射成流圖中的一條邊。設計圖中多個箭頭的交匯點映射成流圖中的一個節點：空節點把流圖中由節點和邊組成的閉合部分稱為一個區域，在計算區域數時，圖的外部部分也作為一個區域。如流圖的區域數為3在流圖中獨立路徑至少包含一條在定義該路徑之前未曾用到過的邊。在基本路徑測試時，獨立路徑的數目就是流圖的區域數。第七十頁，共92頁。例：導出程序流程圖的拓撲結構-流圖第七十一頁，共92頁。只包含獨立路徑的基本路徑集path1:1-11path1:1-2-3-4-5-10-1-11path1:1-2-3-6-8-9-10-1-11path1:1-2-3-6-7-9-10-1-11區域個數＝流圖G的環路復雜度V(G)，計算方法：V(G)=區域個數=4V(G)=邊的條數-節點個數+2=11－9＋2＝4V(G)=判定節點個數+1=3＋1＝4。第七十二頁，共92頁。等價類劃分方法就是將所有可能的輸入數據劃分成若干個等價類，然后在每個等價類中選取一個代表性的數據作為測試用例。測試用例：該子集中的每個輸入數據對發現軟件中的錯誤都是等效的，可從每個子集中選取一組數據來測試程序。等價類劃分第七十三頁，共92頁。等價類可分為：有效等價類：符合需求說明要求的合理的輸入數據集合無效等價類：不符合需求說明要求的不合理的或非法的輸入數據集合。劃分等價類的標準：覆蓋不相交代表性等價類劃分第七十四頁，共92頁。劃分等價類的規則：1)如果輸入條件規定了取值范圍，可定義一個有效等價類和兩個無效等價類。例：輸入值是學生成績，范圍是0～1000100有效等價類1≤成績≤100無效等價類成績>100無效等價類成績<0等價類劃分第七十五頁，共92頁。2)如果輸入條件規定了值的個數，則可以確定一個有效等價類（輸入值的個數等于規定的個數）和兩個無效等價類（輸入值的個數小于規定的個數和大于規定的個數）。<33>3有效等價類三角形邊數＝3無效等價類邊數>3無效等價類邊數<3等價類劃分第七十六頁，共92頁。3)如規定了輸入數據的一組值，且程序對不同輸入值做不同處理，則每個允許的輸入值都是一個有效等價類，并有一個無效等價類(所有不允許的輸入值的集合)。專科本科碩士博士專科無效等價類：碩士本科博士等價類劃分第七十七頁，共92頁。4)如果輸入條件代表的集合是某個元素，則可定義一個有效等價類和一個無效等價類。例如：某項活動截至日期是07年12月31日07年12月31日前07年12月31日后活動正常進行活動停止等價類劃分第七十八頁，共92頁。5)如果輸入條件規定了輸入值必須遵循的規則，那么可以確定一個有效等價類（符合此規則）和若干個無效等價類（從各個不同的角度違反此規則）。例如，規定變量標識符以字母開頭。有效等價類是“以字母開頭”；無效等價類有“以數字開頭”、“以標點符號開頭”、“以特殊符號開頭”……等。等價類劃分第七十九頁，共92頁。等價類設計測試用例的方法：根據軟件規格說明，對每一個輸入條件確定若干個有效等價類和若干個無效等價類。每一等價類和無效等價類規定一個唯一的編號，記錄在下表中。等價類表輸入條件有效等價類無效等價類第八十頁，共92頁。(2)設計一個測試用例，使其盡可能多的覆蓋尚未覆蓋的有效等價類；重復這一步驟，直到所有有效等價類均被測試用例所覆蓋；(3)設計一新測試用例，使其只覆蓋一個無效等價類，重復這一步驟直到所有無效等價類均被覆蓋；等價類設計測試用例的方法：第八十一頁，共92頁。例1:某報表處理系統要求用戶輸入處理報表的日期，日期限制在2005年1月至2007年12月，即系統只能對該段期間內的報表進行處理，如日期不在此范圍內，則顯示輸入錯誤信息。系統日期規定由年、月的6位數字字符組成，前四位代表年，后兩位代表月。如何用等價類劃分法設計測試用例,來測試程序的日期檢查功能？等價類設計測試用例的方法：第八十二頁，共92頁。“報表日期”輸入條件的等價類表輸入等價類等價類無效等價類報表日期的類型及長度6位數字字符(1)有非數字字符(4)少于6個數字字符(5)多于6個數字字符(6)年份范圍在2005～2007之間(2)小于2005(7)大于2007(8)月份范圍在1～12之間(3)小于1(9)大于12(10)等價類設計測試用例的方法：第一步：等價類劃分第八十三頁，共92頁。對表中編號為(1),(2),(3)的