軟件工程知識點

第一章概述1.什么是軟件危機？產生的原因。是指在計算機軟件開發(fā)和維護過程中所遇到的一系列嚴重問題.原因：軟件本身的特點、軟件開發(fā)與維護方法不正確2軟件的概念（*）：軟件是計算機系統(tǒng)中與硬件相互依存的另一部分，它包括程序、數(shù)據(jù)及相關文檔的完整集合。特點：軟件是一種邏輯實體，缺乏“可見性”。在軟件的開發(fā)過程中沒有明顯的制造過程軟件在運行和使用過程期間，沒有硬件那樣的機械磨損、老化問題。但維護一般需要修改設計軟件成本相當昂貴。文檔的作用：描述如何使用這個系統(tǒng)；描述怎么安裝和管理這個系統(tǒng)；描述系統(tǒng)需求3、軟件工程原理：1.用分階段的生命周期計劃嚴格管理軟件開發(fā)。2.堅持進行階段評審。3.實行嚴格的產品版本控制。4.采用現(xiàn)代程序設計技術。5.結果應能清楚地審查。文檔要有嚴格要求。6.開發(fā)小組的成員要少而精。7.要不斷地改進軟件工程實踐的經驗和技術。4.軟件工程方法學（傳統(tǒng)方法學、面向對象方法學）三要素：方法、工具、過程結構化方法/面向對象方法（4個要點）(*)把對象作為融合了數(shù)據(jù)及在數(shù)據(jù)上的操作行為的統(tǒng)一的軟件構件把所有的對象都劃分為類按照父類和子類的關系，把若干個相關類組成一個層次結構的系統(tǒng)對象彼此間僅能通過發(fā)送消息互相聯(lián)系在分析、設計、實現(xiàn)中用到“對象、類、繼承、消息通信”這四個基本概念，就是面向對象的方法5.軟件生存周期各階段（*）1.問題定義：要解決什么問題？2.可行性研究：有可行的方法嗎？3.需求分析：目標系統(tǒng)必須做什么？4.總體設計：怎樣實現(xiàn)目標系統(tǒng)？5.詳細設計6.編碼和單元測試：實現(xiàn)7.綜合測試：系統(tǒng)達到預定目標了嗎？8.軟件維護第二章可行性研究1.可行性研究的目的：用最少的代價在最短的時間內確定問題是否能夠解決。任務：（1）分析和澄清問題目標、規(guī)模、限制、約束（2）導出系統(tǒng)邏輯模型（3）探索可供選擇的解決方案并研究可行性技術可行性：使用現(xiàn)有的技術能實現(xiàn)這個系統(tǒng)嗎？經濟可行性：這個系統(tǒng)的經濟效益能超過它的開發(fā)成本嗎?操作可行性：系統(tǒng)的操作方式在這個用戶組織內行得通嗎?法律、社會效益可行性:要開發(fā)的項目是否存在侵權、妨礙等社會責任問題。（4）給出行動方案建議，制定初步項目計劃2.可行性研究過程（*）（1）確定系統(tǒng)的規(guī)模和目標（2）分析現(xiàn)有系統(tǒng)（3）設計新系統(tǒng)的高層邏輯模型（4）評審系統(tǒng)模型（5）設計和評價解決方案（6）制定行動方案（7）草擬開發(fā)計劃（8）書寫文檔提交審查3.方法和工具（1）系統(tǒng)流程圖符號表示略（2）數(shù)據(jù)流圖(*)p42例子（3）數(shù)據(jù)字典(*)P54.5題數(shù)據(jù)字典是關于數(shù)據(jù)的信息的集合。數(shù)據(jù)字典提供關于數(shù)據(jù)的描述數(shù)據(jù)字典內容：四類元素：數(shù)據(jù)流、數(shù)據(jù)元素、數(shù)據(jù)存儲、處理定義數(shù)據(jù)的方法：對數(shù)據(jù)進行自頂向下分解，分解為最基本的數(shù)據(jù)元素。四種基本組合方式：順序+字母字符+數(shù)字字符選擇[][字母字符|數(shù)字字符]重復{}2{a}5可選()(a)第三章需求分析1.需求分析的任務和難點書P56任務：①畫出目標系統(tǒng)的組織結構圖與列出各部門的崗位角色表(組織機構模型)②畫出目標系統(tǒng)的業(yè)務操作流程圖③畫出目標系統(tǒng)的數(shù)據(jù)流程圖，掌握業(yè)務規(guī)則，獲得初步數(shù)據(jù)模型。④列出目標系統(tǒng)的功能點列表(功能模型)⑤列出系統(tǒng)的性能點列表(性能模型)⑥列出目標系統(tǒng)的接口列表(接口模型)⑦確定目標系統(tǒng)的運行環(huán)境(環(huán)境模型)⑧目標系統(tǒng)的界面約定(界面模型)⑨對目標系統(tǒng)的開發(fā)工期、費用、開發(fā)進度、系統(tǒng)風險等問題進行分析與評估。軟件工程的兩大難點：軟件需求、項目管理2、需求過程(*)1）需求獲?、诜治鼋＂坌枨笳f明書④需求驗證需求獲取方法：訪談、調查表、學徒、搜集資料、用例分析、原型方法4、分析建模方法(*)（1）結構化分析方法（面向數(shù)據(jù)流分析）(*)：就是面向數(shù)據(jù)流自頂向下逐步求精進行需求分析的方法。（2）ER圖(*)：實體聯(lián)系模型是用戶對數(shù)據(jù)和加工的需求用實體聯(lián)系圖（即E-R圖）表達出來，明確描述應用系統(tǒng)的概念結構數(shù)據(jù)模型。實體（數(shù)據(jù)對象）：是對軟件必須理解的復合信息的抽象。復合信息：具有一系列不同性質和屬性的事物。如：外部實體、事物（例如單據(jù)、報表）、事件（存款）、角色、單位、地點等。屬性：定義了實體的性質。特殊屬性-標識符聯(lián)系：實體之間的關系。1:1,1:M,M:N聯(lián)系也可有屬性（3）數(shù)據(jù)規(guī)范化(第一二三范式)（4）狀態(tài)圖（5）用例分析5、《需求規(guī)格說明書》與需求驗證《軟件需求規(guī)格說明書》是需求分析階段的主要文檔。通常用自然語言完整、準確、規(guī)范、具體地描述系統(tǒng)的功能要求、性能要求、數(shù)據(jù)要求、約束等。軟件設計的輸入是驗收的依據(jù)。第五章總體設計1.設計的目標和任務目標：軟件設計的目標就是構造一個高內聚低耦合的軟件模型。任務：1)劃分出組成系統(tǒng)的物理元素----程序、文件、數(shù)據(jù)庫、人工過程和文檔等，但是每個物理元素仍處于黑盒子級，這些黑盒子的具體內容將在以后詳細設計。2）設計軟件的結構，也就是要確定系統(tǒng)中每個程序是由那些模塊組成的，以及這些模塊相互之間的關系。 2、總體設計過程：1）設想供選擇的方案2）選取合理的方案3）推薦最佳方案4）功能分解5）設計軟件結構6）設計數(shù)據(jù)庫7）制定測試計劃8）書寫文檔9）審查和復審3、設計原理(*)：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨立（耦合和內聚）模塊化（*）：就是將軟件系統(tǒng)劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起來構成一個整體。抽象可分為控制抽象、過程抽象、數(shù)據(jù)抽象三種。逐步求精：為了能夠集中精力解決主要問題而盡量推遲對問題細節(jié)的考慮。與抽象互補。信息隱藏和局部化：信息隱藏是一個模塊內包含的信息（過程和數(shù)據(jù)）對于不需要這些信息的模塊來說是不能訪問的。自頂向下逐步求精是進行軟件結構設計的常用途徑。局部化是指把一些關系密切的軟件元素物理地放得彼此靠近。局部化有助于實現(xiàn)信息隱藏。模塊化可使軟件結構清晰，便于理解，便于修改。模塊化有助于軟件開發(fā)工程的組織管理。模塊獨立是設計的關鍵模塊獨立性度量：耦合和內聚耦合程度由高到低（模塊獨立性由弱到強）：內容耦合、公共耦合、控制耦合、數(shù)據(jù)耦合內聚性由高到低（模塊獨立性由強到弱）：功能內聚、順序內聚、通信內聚、過程內聚、時間內聚、邏輯內聚、偶然內聚對于低內聚的模塊，可通過重新分解來實現(xiàn)模塊的修改與優(yōu)化，這樣提高了模塊內部的緊湊性，必然會降低塊間聯(lián)系，確保從整體上提高模塊的獨立性。對于高耦合度的模塊，則通過功能重組，將聯(lián)系緊密的部分組成新的模塊，這樣可以防止系統(tǒng)僵化，提高模塊的可維護性。4、軟件結構優(yōu)化的啟發(fā)式規(guī)則（*）改進軟件結構提高模塊獨立性模塊規(guī)模應該適中深度、寬度、扇出和扇入都應適當模塊的作用域應該在控制域之內力爭降低模塊接口的復雜程度設計單入口單出口的模塊模塊功能應該可以預測5、總體設計方法和工具結構化方法指導思想(*)1.改進軟件結構提高模塊獨立性2.模塊規(guī)模應該適中3.深度、寬度、扇出和扇入都應適當4.模塊的作用域應該在控制域之內5.力爭降低模塊接口的復雜程度6.設計單入口單出口的模塊7.模塊功能應該可以預測面向數(shù)據(jù)流的的設計方法(*)面向數(shù)據(jù)流的設計方法，即通常所說的結構設計法（簡稱SD方法），是根據(jù)需求階段對數(shù)據(jù)流的分析（一般用數(shù)據(jù)流圖和數(shù)據(jù)字典表示）設計軟件結構。目標是給出設計軟件結構的一個系統(tǒng)化的途徑。變換分析步驟1：復審基本系統(tǒng)模型步驟2：復審并細化數(shù)據(jù)流圖。步驟3：確定數(shù)據(jù)流圖中含有變換特征還是事務特征步驟4：確定輸入流和輸出流的邊界，從而孤立出變換中心。步驟5：完成第一級分解步驟6：完成第二級分解為每一個輸入模塊、輸出模塊、變換模塊設計它們的從屬模塊步驟7：利用設計度量和啟發(fā)式對第一次分割得到的軟件結構進一步精化。事務分析與變換分析設計步驟大部分相同或類似，主要差別僅在于由數(shù)據(jù)流圖得到軟件結構的映射方法不同。描述軟件結構的工具（可能是繪圖題詳見課本P102--104）層次圖和HIPO圖(P102--103)結構圖(P103---P104)第6章詳細設計1、詳細設計的目標和任務答：主要任務：為每一模塊確定算法；確定每一模塊使用的數(shù)據(jù)結構；確定模塊的外部接口和用戶界面；為每一模塊設計一組測試用例；編寫文檔:“詳細設計說明書”；設計的質量目標：邏輯正確、性能滿足要求、易理解、可維護結構程序設計的基本控制結構：順序結構選擇結構循環(huán)結構3.人機界面設計要解決四個設計問題：1.系統(tǒng)響應時間2.用戶幫助設施3.出錯信息處理4.命令交互人機界面設計指南：1.一般交互指南2.信息顯示指南3.數(shù)據(jù)輸入指南4.過程設計工具有：（1）程序流程圖：流程圖是用圖形化的方式，表示程序中一系列操作及執(zhí)行的順序名稱圖例說明終結符

表示流程的開始和結束處理

表示程序的計算步驟或處理過程，在方框內填寫處理的名稱或程序語句判斷

表示邏輯判斷或分支，用于決定執(zhí)行后續(xù)的路徑，在菱形框內填寫判斷的條件輸入/輸出

獲取待處理的信息（輸入），記錄或顯示已處理的信息（輸出）連線

連接其它的符號，表示執(zhí)行順序或數(shù)據(jù)流向（2）結構化流程圖（NS圖）：N-S圖是流程圖的另一種表達形式，簡稱N-S圖。與流程圖對應的三種結構：順序，分支，循環(huán)順序結構順序結構塊1塊2塊3塊4條件TF塊1塊2選擇結構CaseI=1,2,3T塊1塊2多分支選擇結構F塊3塊當條件成立時當型循環(huán)塊直到條件成立時直到型循環(huán)（3）PAD圖—問題分析圖（4）過程設計語言PDL：程序設計語言也稱結構化英語或偽代碼，它使用結構化編程語言的風格描述程序算法，但不遵循特定編程語言的語法。程序設計語言允許你在比源代碼更高的層次上進行設計，通常省略與算法無關的細節(jié)，例如，交換兩個變量的操作。（5）判定表和判定樹（*）決策表用于以緊湊的形式描述復雜的邏輯。決策表與if-else、switch-case語句類似，將條件判斷與執(zhí)行的動作聯(lián)系起來。決策表通常分成四個區(qū)域，如右圖所示。條件條件選擇動作動作選擇決策樹是決策表的圖形形式。例分房問題：1、一般職工婚后5年可參加分房

2、中級以上職稱的職工婚后3年可參加分房

3、符合正常分房條件的職工，若再符合晚婚條件可優(yōu)先分房123456說明條件婚齡>5年3-5年<3年(-)表示任意(Y)條件滿足(N)條件不滿足(*)選中的決策中級職稱-----------YN-----晚婚YNYN---------決策優(yōu)先分房**正常分房**不分房**決策樹中中級職稱不分房分房決策>5年3-5年<3年優(yōu)先分房非中級職稱正常分房正常分房晚婚非晚婚晚婚非晚婚優(yōu)先分房不分房5、程序復雜度的度量：McCabe方法：流圖（程序圖）和環(huán)形復雜度計算流圖：把程序流程圖映射成流圖；由PDL翻譯成流圖；包含復合條件的PDL計算環(huán)形復雜度的方法流圖中的區(qū)域數(shù)V(G)=E-N+2，E:邊數(shù)N：結點數(shù)V(G)=P+1,P：流圖中判定節(jié)點的數(shù)目環(huán)形復雜度的用途V(G)≦10第7章實現(xiàn)1、編碼（理解）詳見P146--148編程語言選擇的因素:系統(tǒng)用戶的要求；可以使用的編譯程序；可以得到的軟件工具；工程規(guī)模；程序員的知識；軟件可移植性要求；軟件的應用領域。編碼風格：邏輯簡明清晰、易讀易懂。2、軟件測試的目標測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程一個好的測試用例是指很可能找到迄今為至尚未發(fā)現(xiàn)的錯誤的測試用例一個成功的測試是指揭示了迄今為至尚未發(fā)現(xiàn)的錯誤的測試3、軟件測試準則（理解）1.）所有的測試都應可追溯到客戶需求2.）應該在測試工作真正開始前的較長時間就進行測試計劃3.）Pareto原則：測試中發(fā)現(xiàn)的80%的錯誤可能來自于20%的程序代碼4.）測試應從“小規(guī)?！遍_始，逐步轉向“大規(guī)?！?.）窮舉測試是不可能的6.）為了達到最有效的測試，應由獨立的第三方來承擔測試其他的測試原則：1.）在設計測試用例時，應包括合理的輸入條件和不合理的輸入條件2.）嚴格執(zhí)行測試計劃，排除測試的隨意性3.）應當對每一個測試結果做全面檢查4.）妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護提供方便5.）檢查程序是否做了應做的事僅是成功的一半，另一半是檢查程序是否做了不該做的事6.）在規(guī)劃測試時不要設想程序中不會查出錯誤4、測試方法分類：靜態(tài)/動態(tài)，黑盒/白盒，測試用例軟件測試的軟件測試的策略和方法靜態(tài)測試方法動態(tài)測試方法計算機輔助靜態(tài)分析方法白盒測試方法黑盒測試方法代碼審查1）動態(tài)測試：通過運行程序開展測試工作，即測試人員通過使用軟件來找出問題。2）靜態(tài)測試：不通過運行程序來開展測試工作。這里并不局限于直接閱讀、檢測代碼，還包括閱讀和檢測文檔。5.測試過程（理解）

答：單元測試：測試重點：模塊接口、局部數(shù)據(jù)結構、重要的執(zhí)行通路、出錯處理通路、邊界條件/測試依據(jù)：詳細設計描述和源程序清單常用測試方法：人工測試和計算機測試，主要使用白盒測試技術集成測試：測試重點：在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；一個模塊的功能是否會對另一個模塊的功能產生不利的影響；各個子功能組合起來，能否達到預期要求的父功能；全局數(shù)據(jù)結構是否有問題；單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度/測試依據(jù)：要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。/漸增式測試：首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)；在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產生的問題；通過增殖逐步組裝成為要求的軟件系統(tǒng)。主要有自頂向下和自底向上兩種集成策略。確認測試：測試重點：驗證軟件的功能和性能及其它特性是否與用戶的要求一致/測試依據(jù)：對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經明確規(guī)定。它包含的信息就是軟件確認測試的基礎。/軟件配置復查：軟件配置復查的目的是保證軟件配置的所有成分都齊全；各方面的質量都符合要求；具有維護階段所必需的細節(jié)；而且已經編排好分類的目錄。應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。6.白盒測試技術.：邏輯覆蓋(*)/基本路徑測試/環(huán)形復雜度答：邏輯覆蓋主要考察使用測試數(shù)據(jù)運行被測程序時對程序邏輯的覆蓋程度。通常希望選擇最少的測試用例來滿足所需的覆蓋標準。主要的覆蓋標準有：語句覆蓋、判定覆蓋、條件覆蓋、判定－條件覆蓋、條件組合覆蓋、路徑覆蓋。語句覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個可執(zhí)行語句都至少執(zhí)行一次。欲使每個語句都執(zhí)行一次，只需執(zhí)行路徑L1（sabcde）即可。判定覆蓋（也稱分支覆蓋）是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定的所有可能結果都至少執(zhí)行一次（即判定的每個分支至少經過一次）。欲使每個分支都執(zhí)行一次，只需執(zhí)行路徑L3（sacde，a為“f”且c為“t”）和L4（sabce，a為“t”且c為“f”）即可?；蛘?，執(zhí)行路徑L1（sabcde，a為“t”且c為“t”）和L2（sace，a為“f”且c為“f”）.滿足判定覆蓋標準的測試用例也一定滿足語句覆蓋標準。條件覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定中的每個條件的所有可能結果都至少出現(xiàn)一次。條件覆蓋通常比判定覆蓋強，但有時雖然每個條件的所有可能結果都出現(xiàn)過，但判定表達式的某些可能結果并未出現(xiàn)。判定/條件覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定的所有可能結果都至少執(zhí)行一次，并且，每個判定中的每個條件的所有可能結果都至少出現(xiàn)一次。顯然，滿足判定/條件覆蓋標準的測試用例一定也滿足判定覆蓋、條件覆蓋、語句覆蓋標準。條件組合覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每個判定中條件結果的所有可能組合都至少出現(xiàn)一次。顯然，滿足條件組合覆蓋標準的測試用例一定也滿足判定覆蓋、條件覆蓋、判定/條件覆蓋、語句覆蓋標準。條件組合覆蓋是上述五種覆蓋標準中最強的一種，然而，條件組合覆蓋仍不能保證程序中所有可能的路徑都被覆蓋。路徑覆蓋是指選擇足夠的測試用例，使得運行這些測試用例時，被測程序的每條可能執(zhí)行到的路徑都至少經過一次（如果程序中包含環(huán)路，則要求每條環(huán)路至少經過一次）。路徑覆蓋實際上考慮了程序中各種判定結果的所有可能組合，但它未必能覆蓋判定中條件結果的各種可能情況。因此，它是一種比較強的覆蓋標準，但不能替代條件覆蓋和條件組合覆蓋標準?？刂平Y構測試包括基本路徑測試、條件測試、循環(huán)測試?；韭窂綔y試是TomMcCabe提出的一種白盒測試技術，這種方法首先根據(jù)程序或設計圖畫出流圖，并計算其區(qū)域數(shù)，然后確定一組獨立的程序執(zhí)行路徑（稱為基本路徑），最后為每一條基本路徑設計一個測試用例。流圖由結點和邊組成。流圖中由結點和邊組成的閉合部分稱為一個區(qū)域（region），在計算區(qū)域數(shù)時，圖的外部部分也作為一個區(qū)域。獨立路徑是指程序中至少引進一個新的處理語句序列或一個新條件的任一路徑，在流圖中，獨立路徑至少包含一條在定義該路徑之前未曾用到過的邊。在基本路徑測試時，獨立路徑的數(shù)目就是流圖的區(qū)域數(shù)。環(huán)形復雜度定量度量程序的邏輯復雜性。有了描繪程序控制流的流圖后，可以用以下方法計算流圖中的區(qū)域數(shù)V(G)=E-N+2，E:邊數(shù)N：結點數(shù)V(G)=P+1,P：流圖中判定節(jié)點的數(shù)目7.黑盒測試技術：等價類劃分(*)/邊界值分析/錯誤推測答：等價類劃分方法將所有可能的輸入數(shù)據(jù)劃分成若干個等價類，然后在每個等價類中選取一個代表性的數(shù)據(jù)作為測試用例。等價類劃分方法把輸入數(shù)據(jù)分為有效輸入數(shù)據(jù)和無效輸入數(shù)據(jù)。在確定輸入數(shù)據(jù)等價類時，常常還要分析輸出數(shù)據(jù)的等價類，以便根據(jù)輸出數(shù)據(jù)等價類導出輸入數(shù)據(jù)等價類。等價類劃分設計測試用例的步驟：確定等價類、設計測試用例。確定等價類的規(guī)則：

(1)如果輸入條件規(guī)定了取值范圍，則可以確定一個有效等價類（輸入值在此范圍內）和兩個無效等價類（輸入值小于最小值及大于最大值）(2)如果輸入條件規(guī)定了值的個數(shù)，則可以確定一個有效等價類（輸入值的個數(shù)等于規(guī)定的個數(shù)）和兩個無效等價類（輸入值的個數(shù)小于規(guī)定的個數(shù)和大于規(guī)定的個數(shù)）(3)如果輸入條件規(guī)定了輸入值的集合（即離散值），而且程序對不同的輸入值做不同的處理，那么每個允許的值都確定為一個有效等價類，另外還有一個無效等價類（任意一個不允許的值）。(4)如果輸入條件規(guī)定了輸入值必須遵循的規(guī)則，那么可確定一個有效等價類（符合此規(guī)則）和若干個無效等價類（從各個不同的角度違反此規(guī)則）。(5)如果輸入條件規(guī)定輸入數(shù)據(jù)是整型，那么可以確定三個有效等價類（正整數(shù)、零、負整數(shù)）和一個無效等價類（非整數(shù)）。(6)如果輸入條件規(guī)定處理的對象是表格，那么可以確定有效等價類（表有一項或多項）和一個無效等價類（空表）。利用等價類設計測試用例的步驟：

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

(2)為每個無效等價類設計一個新的測試用例。邊界值分析也是一種黑盒測試方法，是對等價類劃分方法的補充。針對各種邊界情況設計測試用例，其揭露程序中錯誤的可能性就更大。由于邊值分析方法所設計的測試用例更有可能發(fā)現(xiàn)程序中的錯誤，因此經常把邊值分析方法與其它設計測試用例方法結合起來使用。邊界值分析方法選擇測試用例的規(guī)則如下：1．如果輸入條件規(guī)定了值的范圍，則選擇剛剛達到這個范圍的邊界的值以及剛剛超出這個范圍的邊界的值作為測試輸入數(shù)據(jù)。例如，規(guī)定輸入的考試成績在0～100之間，則取0，100，－1，101作為測試輸入數(shù)據(jù)。2．如果輸入條件規(guī)定了值的個數(shù)，則分別選擇最大個數(shù)、最小個數(shù)、比最大個數(shù)多1、比最小個數(shù)少1的數(shù)據(jù)作為測試輸入數(shù)據(jù)。例如，規(guī)定一個運動員的參賽項目至少1項，最多3項，那么，可選擇參賽項目分別是1項、3項、0項、4項的測試輸入數(shù)據(jù)。3．對每個輸出條件使用第1條。例如，輸出的金額值大于等于0且小于104，則選擇使得輸出金額分別為0、9999、－1、10000的輸入數(shù)據(jù)作為測試數(shù)據(jù)。4．對每個輸出條件使用第2條。例如，規(guī)定輸出的一張發(fā)票上，至少有1行內容，至多有5行內容，則選擇使得輸出發(fā)票分別有1行、5行、0行、6行內容的輸入數(shù)據(jù)作為測試數(shù)據(jù)。5．如果程序的輸入或輸出是個有序集合，例如，順序文件、表格，則應把注意力集中在有序集的第1個元素和最后一個元素上。6．如果程序中定義的內部數(shù)據(jù)結構有預定義的邊界，例如，數(shù)組的上界和下界、棧的大小，則應選擇使得正好達到該數(shù)據(jù)結構邊界以及剛好超出該數(shù)據(jù)結構邊界的輸入數(shù)據(jù)作為測試數(shù)據(jù)。例如，程序中數(shù)組A的下界是10，上界是20，則可選擇使得A的下標為10、20、9、21的輸入數(shù)據(jù)作為測試數(shù)據(jù)。7．發(fā)揮你的智慧，找出其他可能的邊界條件。錯誤推測是一種憑直覺和經驗推測某些可能存在的錯誤，從而針對這些可能存在的錯誤設計測試用例的方法。這種方法沒有機械的執(zhí)行步驟，主要依靠直覺和經驗。錯誤推測法的基本思想是：列舉出程序中所有可能的錯誤和容易發(fā)生錯誤的特殊情況，然后根據(jù)這些猜測設計測試用例。8、調試（理解）答：測試的目的是發(fā)現(xiàn)錯誤，調試（也稱排錯）的目的是確定錯誤的原因和準確位置，并加以糾正。調試方法：蠻力法、回溯法、原因排除法（可分為歸納法和演繹法）蠻力法是一種最省腦筋但又最低效的方法。它通過在程序中設置斷點，輸出寄存器、存儲器的內容，打印有關變量的值等手段，獲取大量現(xiàn)場信息，從中找出錯誤的原因。這種方法效率低，輸出的信息大多是無用的，通常在其他調試方法未能找到錯誤原因時，才使用這種方法。可以采用二分法來逐步縮小出錯的范圍回溯法是從錯誤的征兆出發(fā)，人工沿著控制流程往回跟蹤，直至發(fā)現(xiàn)錯誤的根源。這種方法適用于小型程序，對大型程序，由于回溯的路徑太多，難以徹底回溯。歸納法是一種從特殊推斷一般的系統(tǒng)化思考方法。其基本思想是：從一些線索（錯誤征兆）著手，通過分析它們之間的關系來找出錯誤的原因。演繹法從一般原理或前提出發(fā)，假設所有可能出錯的原因，排除不可能正確的假設，最后推導出結論。9、可靠性：定義，MTTFMTTR的含義答：定義：軟件可靠性是在給定的時間間隔內，按規(guī)格說明書的規(guī)定成功地運行的概率。MTTF指軟件的平均無故障時間，是一個重要的質量指標，是系統(tǒng)按規(guī)格說明書規(guī)定成功地運行的平均時間，它主要取決于系統(tǒng)中潛伏的錯誤的數(shù)目，和測試的關系十分密切。MTTR平均維修時間，是修復一個故障平均需要的時間，它取決于維護人員的技術水平和對系統(tǒng)的熟悉程度，也和系統(tǒng)的可維護性有重要關系。10、與錯誤數(shù)的關系，測試時間估算（*）平均無故障時間與單位長度程度中剩余的錯誤數(shù)成反比MTTF=1/K（ET/IT-EC(￡)/IT）ET代表測試之前程序中的錯誤總數(shù)；IT程序長度EC(￡)0至￡期間發(fā)現(xiàn)的錯誤數(shù)K為常數(shù)，它的值根據(jù)經驗選取，典型值為200.EC=ET-IT/(K*MTTF)維護軟件維護的四種類型：（1）糾錯性維護：為了改正軟件系統(tǒng)中的錯誤，使軟件能夠滿足預期的正常運行狀態(tài)的要求而進行的維護（2）適應性維護：為了使軟件適應內部或外部環(huán)境變化，而去修改軟件的過程（3）完善性維護：滿足使用過程中用戶提出增加新功能或修改已有功能的建議維護,這種維護一般占維護工作的大部分。4）預防性維護：為了提高軟件的可維護性、可靠性等，為以后進一步改進軟件打下良好基礎而修改軟件的活動。2、軟件維護的特點1）非結構化維護：如果不采用軟件工程方法開發(fā)軟件，軟件只有程序而欠缺文檔，則維護工作將變得十分困難（2）結構化維護：采用軟件工程的方法進行軟件開發(fā)，保證每個階段都有完整且詳細的文檔維護時，開發(fā)人員從分析需求規(guī)格說明開始，明白軟件功能和性能上的改變，對設計說明文檔進行修改和復查，再根據(jù)設計修改進行程序變動，并用測試文檔中的測試用例進行回歸測試，最后將修改后的軟件再次交付使用。軟件維護的問題（副作用）（1）理解別人的代碼通常是非常困難的，而且難度隨著軟件配置成分的缺失而迅速增加（2）需要維護的軟件往往沒有文檔、或文檔資料嚴重不足、或軟件的變化未在相應的文檔中反映出來（3）當軟件要求維護時，不能指望由原來的開發(fā)人員來完成或提供軟件的解釋。由于維護持續(xù)時間很長，因此當需要解釋軟件時候，往往開發(fā)人員已經不在附近了（4）絕大多數(shù)軟件在設計時沒有考慮到將來的修改問題（5）軟件維護這項工作毫無吸引力。一方面是因為軟件維護，看不到什么“成果”，但工作量很大，更重要的是維護工作難度大，軟件維護人員經常遭受挫折。4、影響軟件可維護性的因素：可維護性指理解、改正、調整和改進軟件的難易程度。對軟件可維護性影響的主要因素有：可理解性、可測試性、可修改性、可移植性、可重用性文檔程序文檔對提高程序的可理解性有著重要的作用。即使是一個相對簡單的程序，要想有效地，迅速對它進行維護，也需要編制文檔對它的目的和任務進行解釋。而對于程序的維護人員來說，要想對程序編制人員的意圖進行重新修改，并對今后可能出現(xiàn)的變化估計，缺少文檔的幫助也將很難實現(xiàn)。另一方面，對于程序文檔一定要能及時反映程序的變化，否則將對后續(xù)維護人員產生誤導?？删S護性復審，軟件配置復審目的（*）可維護性是所有軟件都應該具備的基本特點，必須在開發(fā)階段保證軟件具有可理解性、可測試性、可修改性、可移植性、可重用性。在軟件過程的每一個階段都應該考慮并努力提高軟件的可維護性，在每個階段結束前的技術審查和管理復審中，應著重對可維護性進行復審。軟件配置復審的目的是保證軟件配置的所有成分是完整的、一致的和可理解的，而且為了便于修改和管理已經編目歸檔了。面向對象方法引論1、面向對象方法學的要點（*）4個：OO=objects+classes+inheritance+communicationwithmessages2、面向對象方法學的優(yōu)點（*）（1）與人類習慣的思維方法一致。對象是對現(xiàn)實世界實體的正確抽象（2）穩(wěn)定性好?，F(xiàn)實世界中的實體是相對穩(wěn)定（3）可重用性好。創(chuàng)建類的實例,，派生新類（4）較易開發(fā)大型軟件產品（5）可維護性好3、面向對象的概念（*）：（1）對象：對象是一個封裝體，封裝了數(shù)據(jù)結構及可以施加在這些數(shù)據(jù)結構上的操作。（2）類：類是對具有相同數(shù)據(jù)屬性和相同操作的一個或一組（集合）相似對象的描述，是一個抽象的概念。（3）實例：實例就是由某個特定的類所描述的一個具體的對象，實際上類是建立對象時使用的“樣板”。（4）消息：對象之間相互請求相互協(xié)作的途徑。（5）封裝：封裝即把數(shù)據(jù)和實現(xiàn)操作的代碼放在對象內部，外界通過對象提供的接口來使用它，不需知道內部數(shù)據(jù)結構細節(jié)和實現(xiàn)操作的算法。（6）繼承：繼承指能夠直接獲得已有的性質和特征，而不必重復定義它們。是子類自動地共享基類中定義的數(shù)據(jù)和方法的機制。（7）多態(tài)：多態(tài)是指在類等級的不同層次中，相同的消息，被不同類的對象接收，產生了不同的行為。（8）重載：有兩種重載：函數(shù)重載是指在同一作用域內的若干個參數(shù)特征不同的函數(shù)可以使用相同的函數(shù)名字；運算符重載是指同一個運算符可以施加于不同類型的操作數(shù)上面。面向對象建模的三種模型及作用（*）：（1）對象模型：描述系統(tǒng)數(shù)據(jù)結構（2）動態(tài)模型：描述系統(tǒng)控制結構（3）功能模型：描述系統(tǒng)功能對象模型是最重要、最基本、最核心的。5、對象模型(*)（類圖，UML如何表達）對象模型是表示靜態(tài)的結構化的系統(tǒng)的“數(shù)據(jù)”性質。類圖描述類與類之間的靜態(tài)關系。類圖是一種靜態(tài)模型，它是創(chuàng)建其他UML圖的基礎。UML如何表達UML提供的用例圖是進行需求分析和建立功能模型的強有力工具。在UML中把用用例圖建立起來的系統(tǒng)模型稱為用例模型。用例模型描述的是外部行為者(actor）所理解的系統(tǒng)功能。用例模型的建立是系統(tǒng)開發(fā)者和用戶反復討論的結果，它描述了開發(fā)者和用戶對需求規(guī)格所達成的共識。用例模型描述外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。即待開發(fā)系統(tǒng)的功能需求。它驅動了需求分析之后各階段的開發(fā)工作,還被用于驗證和檢測所開發(fā)的系統(tǒng),影響了UML的各個模型。用例模型由若干個用例圖構成，用例圖中主要描述執(zhí)行者和用例之間的關系。在UML中,構成用例圖的主要元素是用例和執(zhí)行者及其它們之間的聯(lián)系。建立系統(tǒng)用例模型的過程就是對系統(tǒng)進行功能需求分析的過程。6、對象之間的關系：關聯(lián)/聚集/泛化/依賴(*)1）關聯(lián)是類之間的連結,分為：普通關聯(lián)、多元關聯(lián)、有序關聯(lián)、限定關聯(lián)、關聯(lián)類聚集是一種特殊的關聯(lián)，它指出類間的“整體-部分”關系。共享聚集、組合聚集3）泛化指出類之間的“一般與特殊關系”，即繼承關系。父類與子類之間構成類的分層結構。4）依賴關系描述兩個模型元素（類、用例等）之間的語義連接關系：其中一個模型元素是獨立的，另一個模型元素不是獨立的，它依賴于獨立的模型元素，如果獨立的模型元素改變了，將影響依賴于它的模型元素。7、動態(tài)模型包括四類圖：序列圖/活動圖/協(xié)作圖/狀態(tài)圖（理解）（1）狀態(tài)圖：描述某個對象，子系統(tǒng)，系統(tǒng)的生命周期。（2）活動圖：描述操作實現(xiàn)中完成的工作以及用例實例或對象中的活動，活動圖是狀態(tài)圖的一個變種。（3）順序圖：是一種交互圖，描述對象之間的動態(tài)合作關系以及合作過程中的行為次序，常用來描述一個用例的行為。（4）合作圖：用于描述相互合作的對象間的交互關系，它描述的交互關系是對象間的消息連接關系。8、功能模型：用例和用例建模，用例圖(*)（1）用例：從本質上講,一個用例是用戶與計算機之間的一次典型交互作用。在UML中,用例被定義成系統(tǒng)執(zhí)行的一系列動作（功能）。（2）用例建模技術，用于描述系統(tǒng)的功能需求。在宏觀上給出模型的總體輪廓。通過對典型用例的分析，使開發(fā)者能夠有效地了解用戶的需求。（3）用例圖實例：例1建立項目與資源管理系統(tǒng)的Usecase圖。系統(tǒng)的主要功能是：包括項目管理，資源管理和系統(tǒng)管理三大管理功能。1.項目管理包括項目的增加、刪除、更新。2.資源管理包括對資源和技能的添加、刪除和更新。3.系統(tǒng)管理包括系統(tǒng)的啟動和關閉，數(shù)據(jù)的存儲和備份等功能。說明：技能表示人力資源。過程：1.分析確定系統(tǒng)的執(zhí)行者(角色)：項目管理員、資源管理員、系統(tǒng)管理員、備份數(shù)據(jù)系統(tǒng)。2.確定用例：項目管理，資源管理和系統(tǒng)管理。3.對用例進行分解，畫出下層的Usecase圖：對上層的用例進行分解,并將執(zhí)行者分配到各層次的Usecase圖中。還應畫出相應的執(zhí)行者描述模板及用例描述模板。第十章面向對象分析1、對象模型的5個層次：主題層/類與對象層/結構層/屬性層/服務層2、建立對象模型的5種活動1、類的識別2、確定關聯(lián)3、劃分主題,包圖4、確定屬性5、識別繼承關系3、三種模型的建立過程和方法（理解）對象模型（*）動態(tài)模型/功能模型——對象模型建立過程和方法一）確定類和對象。1、找出候選的類和對象；2、篩選出正確的類和對象。方法：名詞識別法、系統(tǒng)實體識別法、利用分解與抽象技術二）確定關聯(lián)。1、初步確定關聯(lián)2、篩選3、進一步完善。方法：問題陳述中抽取可能的關聯(lián)（動詞詞組）、隱含的動詞詞組三）劃分主題。方法：按問題領域劃分主題，按照使用不同主題內的對象相互間依賴和交互最少的原則來確定主題。四）確定屬性。1、分析2、選擇、五）識別繼承關系。方法：自底向上自頂向下六）反復修改——動態(tài)模型建立過程和方法一）編寫典型交互行為的腳本。二）從腳本中提取事件，確定出發(fā)每個事件的動作對象及接受事件的目標對象。三）排列事件發(fā)生的次序，確定每個對象可能有的狀態(tài)以及狀態(tài)間的轉換關系，并用狀態(tài)圖描繪它們。四）比較各個對象的狀態(tài)圖，檢查他們之間的一致性，確保時間之間的匹配?！δ苣Ｐ偷慕⑦^程及方法一）畫出基本系統(tǒng)模型圖二）畫出功能級數(shù)據(jù)流圖。三）描述處理框功能?！捎玫腢ML圖（*）動態(tài)模型:描述系統(tǒng)的行為。動態(tài)建模用來描述系統(tǒng)的動態(tài)行為，顯示對象在系統(tǒng)運行期間不同時刻的動態(tài)交互。UML中用狀態(tài)圖、活動圖、順序圖和協(xié)作圖來建立動態(tài)模型?！^程（PPT沒有）第十一章面向對象設計設計準則（結合第5章）（*）面向對象設計面向對象分析是提取、整理用戶需求并建立問題域精確模型的過程。面向對象設計則是把分析階段得到的需求轉變成符合成本和質量要求的、抽象的系統(tǒng)實現(xiàn)方案的過程。從面向對象分析到面向對象設計是一個逐漸擴充的過程，主要是增加各種組成部分，在實際開發(fā)過程中二者的界限是模糊的。許多分析結果可以直接映射成設計結果，在設計過程中又往往加深了對系統(tǒng)的理解，進一步補充和完善分析的結果，因此分析和設計是多次反復迭代的過程。什么是優(yōu)秀的設計？1.滿足用戶需求2.易維護3.易擴充4.高質量5.總體成本低（全生命周期）面向對象設計的準則：1.模塊化2.抽象3.信息隱藏4.弱耦合5.強內聚6.可重用2、設計類結構的改進和優(yōu)化（*）（多繼承轉單繼承，繼承轉聚合，多對多關聯(lián)轉一對多）a)確定優(yōu)先級用對象實現(xiàn)關聯(lián)b)提高效率的幾項技術：1.增加冗余關聯(lián)以提高訪問效率2.調整查詢次序3.保留派生屬性——計算列c)調整繼承關系：1.抽象與具體2.為提高繼承程度而修改類定義（1）不能違背領域知識和常識（2）應該確?，F(xiàn)有類的協(xié)議（接口）不變3.利用委托實現(xiàn)行為共享3、系統(tǒng)分解分而治之面向對象設計模型由主題、類與對象、結構、屬性、服務5個層次組成。人機交互部分/問題域部分/任務管理部分/數(shù)據(jù)管理部分1）子系統(tǒng)之間的兩種交互方式(1)Client/Server(2)PeertoPeer2）組織系統(tǒng)的兩種方案(1)層次組織(2)塊狀組織3）設計系統(tǒng)的拓撲結構管道形/樹形/星形子系統(tǒng)之間的交互簡單4、各子系統(tǒng)設計過程（理解）---范式與數(shù)據(jù)庫設計設計數(shù)據(jù)管理子系統(tǒng)步驟：1、選擇數(shù)據(jù)存儲管理模式1）.文件管理系統(tǒng)2).關系數(shù)據(jù)庫管理系統(tǒng)①提供最基本的數(shù)據(jù)管理功能中斷恢復、并發(fā)、事務支持、等②標準接口和語言ODBC，JDBC，SQL③存儲和使用分離減少程序對數(shù)據(jù)依賴3).面向對象數(shù)據(jù)庫管理系統(tǒng)2、設計數(shù)據(jù)管理子系統(tǒng)1）設計數(shù)據(jù)格式（1）文件系統(tǒng)。①定義第一范式表:列出每個類的屬性表；把屬性表規(guī)范成第一范式，從而得到第一范式表的定義。②為每個第一范式表定義一個文件③測定性能和需要的存儲容量④修改原設計的第一范式，以滿足性能和存儲的需要。（2）關系數(shù)據(jù)庫管理系統(tǒng)①定義第三范式表:列出每個類的屬性表；把屬性表規(guī)范成第三范式，從而得到第三范式表的定義。②為每個第三范式表定義一個數(shù)據(jù)庫表③測定性能和需要的存儲容量④修改原設計的第一三范式，以滿足性能和存儲的需要。（3）面向對象數(shù)據(jù)庫管理系統(tǒng)2)設計相應的服務對象存儲的服務的兩種方法：（1）每個對象自己保存自己（2）由數(shù)據(jù)管理子系統(tǒng)負責存儲對象12章面向對象實現(xiàn)1、面向對象測試與傳統(tǒng)測試的不同以及對測試策略和測試用例設計的影響。面向對象的測試在許多方面需要借鑒傳統(tǒng)軟件測試方法中可適用部分，并且在軟件開發(fā)的具體實踐中，也經?；旌鲜褂妹嫦驅ο蟮拈_發(fā)方法和結構化的開發(fā)方法，因此，二者存在一些相通之處。但是，與傳統(tǒng)方法相比，面向對象開發(fā)方法和軟件又有許多新的內容和特點，從而導致二者的相異。表現(xiàn)在測試的單元不同，集成環(huán)境測試不同，系統(tǒng)構成不同三個方面。面向對象測試對測試策略和測試用例設計的影響：1、封裝對測試的影響：封裝是類的基本特性之一。封裝將類得所有數(shù)據(jù)和操作作為一個整體對待，數(shù)據(jù)本身不能被外部過程直接存取，促進了程序的模塊化，并在一定程度上簡化了類得使用，避免了不合理的操作，并能有效地阻止錯誤的擴散。但同時，它們也給程序的測試帶來了一定的問題。2、對于面向對象的測試，信息隱藏帶來的主要問題則是對象狀態(tài)的觀察問題。3、從繼承的不足可以看出，測試變得更加重要了，但對于測試來說，繼承卻增加了測試的復雜性。4、在測試時，需要考慮接口包含的行為與類的行為是否相符合。5、多態(tài)性和動態(tài)綁定使得傳統(tǒng)測試實踐中的靜態(tài)分析法遇到了不可逾越的障礙，同時它們也增加了系統(tǒng)運行中可能的執(zhí)行路徑，加大了測試用例的選取難度和數(shù)量。這種不確定性和驟然增加的路徑組合給測試覆蓋率的滿足帶來了挑戰(zhàn)。第13章軟件項目管理1、軟件質量的定義：ISO/IEC9126：與軟件產品滿足明確或隱含需求的能力有關的特征和特性的總和GB/T13423：軟件產品中能滿足給定需求的性質和特性的總和，例如符合規(guī)格說明的程度；軟件具有所期望的各種屬性的組合程度；客戶或用戶覺得軟件滿足其綜合期望的程度；軟件的綜合特性，它確定軟件在使用中將滿足客戶預期要求的程度2、McCall軟件質量要素：軟件產品的運行、修改和遷移三個方面11個軟件質量要素(書上13條)3、軟件質量保證活動：評審:走查/審查、測試、程序正確性證明軟件質量保證活動由兩類不同的角色承擔：（1）負責技術工作的軟件工程師：通過采用可靠的技術方法和措施、進行正式的技術評審、計劃周密的軟件測試來考慮質量問題，并完成軟件質量保證和質量控制活動（2）負責質量保證工作的SQA(SoftwareQualityAssurance)小組：輔助軟件工程小組得到高質量的最終產品SQA:通過確保軟件過程的質量來保證軟件產品的質量。4、SQA小組的活動(CMUSEI)：（1）為項目準備SQA計劃（2）參與開發(fā)該項目的軟件過程描述（3）評審各項軟件工程活動、對其是否符合定義好的軟件過程中的相應部分進行核實（4）審計指定的軟件工作產品、對其是否符合定義好的軟件過程中的相應部分（5）確保軟件工程及工作產品中的偏差已被記錄在案，并根據(jù)預定規(guī)程進行處理（6）記錄所有不符合的部分并報告給高級管理者。（7）此外，SQA小組還需要協(xié)調變化的控制和管理，并