第十一章應用軟件設計與開發技術BasicsofComputerSoftware答辯人：XXX目錄軟件工程概述1軟件總體設計2軟件詳細設計3編碼測試與調試技術45隊列軟件工程概述PART01軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型02軟件維護如何對現有軟件進行后期的維護01軟件需求一個是如何滿足日益增長的軟件需求軟件危機是指在計算機軟件開發和維護過程中所遇到的一系列嚴重問題和矛盾，主要包括了兩方面的問題：軟件危機的概念軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型1對軟件開發成本和進度的估計常常很不準確2用戶對“已完成的”軟件系統不滿意的現象經常發生3軟件產品的質量往往靠不住4軟件常常是不可維護的5軟件沒有完整的文檔資料，導致矛盾在后期開發集中暴露，為整個開發過程帶來毀滅性的后果6軟件成本在計算機系統總成本中所占的比例逐年上升7軟件開發生產率提高的速度，遠遠跟不上計算機應用的速度8缺乏完整規范的資料，軟件測試不充分，造成軟件質量與效率低下，運行中出現大量問題軟件危機的具體表現軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型用戶對軟件需求的描述不準確，甚至在開發過程中，還提出各方面的修改要求需求不明確軟件開發人員和用戶對軟件需求的理解有差異，導致開發出的軟件產品與用戶要求不一致不同人員對需求理解不同協作開發時，管理人員和開發人員的信息交流不及時、不準確、就會產生誤解。信息交流不暢軟件項目開發人員不能有效地、獨立自主地處理大型軟件的全部關系和各個分支，因此容易產生疏漏和錯誤疏漏和錯誤缺乏有力的方法學和工具方面的支持，過分地依靠程序設計人員在軟件開發過程中的技巧和創造性，加劇軟件產品的個性化方法學和工具的限制軟件產品的特殊性和人類智力的局限性，導致人們無力處理“復雜問題”復雜問題的處理能力產生軟件危機的原因軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型軟件工程的定義：用工程、科學和數學的原則與方法研究、維護計算機軟件的有關技術及管理方法，是研究用工程化方法構建和維護有效、實用和高質量的軟件的一門學科方法為軟件開發提供“如何做”的技術，它包括多方面的任務，如項目計劃與估算、需求分析、總體設計、編碼、測試以及維護等工具為軟件工程方法提供自動的或半自動的軟件支撐環境過程定義了方法使用的順序、要求交付的文檔資料、保證質量和協調變化所需的管理，以及軟件開發各個階段完成的里程碑軟件工程的組成三要素軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型1用分階段的生存周期計劃嚴格管理2堅持進行階段評審，以確保軟件產品質量，不能等編碼結束后再進行質量檢測3實行嚴格的產品控制（如評審批準后才能改），以適應軟件規格的變更4釆用現代程序設計技術5結果應能清楚地審查6開發小組的人員應該少而精7承認不斷改進軟件工程實踐的必要性，積極主動地采納新技術、不斷總結經驗教訓軟件工程技術具有規范化和文檔化兩個明顯特點可以看出軟件工程的基本原理軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型軟件定義軟件開發運行和維護1軟件定義確定軟件的總體目標、可行性、成本估計、制定進度表，又稱系統分析，包括：問題定義、可行性研究和需求分析三個子階段2軟件開發具體設計和實現在前一個階段定義的軟件，它是整個軟件項目實施的關鍵時期，包括：總體設計、詳細設計、編碼和單元測試、綜合測試、確認測試等階段3軟件運行和維護軟件將被安裝在特定用戶本地的運行環境中，以發揮其應有的作用，此時可能對軟件產品進行修改和升級，包括改正性維護，適應性維護、完善性維護3類。軟件生命周期的三大階段軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型02正確回答要解決的問題是什么？01問題定義確定要開發軟件系統的總目標1.軟件定義：問題定義軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型1給出功能、性能、可靠性以及接口等方面的要求2完成該軟件任務的可行性研究3估計可利用的資源

(硬件，軟件，人力等)、成本、效益、開發進度4探討解決問題的可能方案5制定出完成開發任務的實施計劃，連同可行性研究報告，提交管理部門審查6包括技術可行性、操作可行性、經濟可行性可行性研究的任務不是解決問題，而是確定問題是否可解，是否值得去解1.軟件定義：可行性研究軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型1對用戶提出的要求進行分析并給出詳細的定義2編寫軟件需求說明書或系統功能說明書及初步的系統用戶手冊3提交管理機構評審此階段必須回答的關鍵問題是：目標系統必須做什么？主要是確定目標系統必須具備哪些功能？1.軟件定義：需求分析總體設計（概要設計）根據軟件需求規格說明建立系統的總體結構和模塊間的關系，以結構設計和數據設計開始，建立程序的模塊結構，定義接口并創建數據結構。此外，要使用一些設計準則來判斷軟件的質量。必須回答的問題是：應該怎樣實現目標系統？軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型2.軟件設計：總體設計詳細設計進行各模塊的詳細設計和詳細規格說明書的編制。模塊詳細設計包括對模塊的詳細功能、所用算法、采用的數據結構和模塊間的接口信息等設計，并擬訂模塊測試方案，為源程序編寫打下基礎經過評審后，把每個細化的過程性描述加入設計規格說明中。軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型2.軟件設計：詳細設計軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型2.軟件設計：編碼和單元測試02單元測試查找各模塊在功能和結構上存在的問題并加以糾正01編碼階段把軟件設計轉換成計算機可以接受的程序代碼，即寫成以某一種特定程序設計語言表示的“源程序清單”寫出的程序應當是結構良好、清晰易讀的，且與設計相一致的綜合測試又稱組裝測試，將已測試過的模塊按一定順序組裝起來，同時測試模塊功能和接口。按規定的各項需求，逐項進行有效性測試，決定已開發的軟件是否合格，能否交付用戶使用軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型2.軟件設計：綜合測試確認測試確認測試檢查所有需求是否得到滿足。

在每個測試步驟之后，要進行調試，以診斷并糾正軟件的故障。

軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型2.軟件設計：確認測試軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型3.軟件運行和維護02維護軟件的維護是為了改正錯誤、適應環境變化及增強功能而進行的一系列修訂活動01運行軟件將被安裝在特定用戶本地的運行環境中，以發揮其應有的作用軟件的維護有時也分為六個部分：項目計劃、需求分析、軟件設計、程序編碼、軟件測試、軟件維護軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型改正性維護運行中發現了軟件中的錯誤需要修正適應性維護為了適應變化了的軟件工作環境，需做適當變更完善性維護為了增強軟件的功能需做變更軟件維護的類型軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型瀑布模型軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型其他瀑布模型軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型瀑布模型的優點1強調開發的階段性，并嚴格地規定了每個階段必須提交的文檔2降低了軟件開發的復雜程度，而且提高了軟件開發過程的透明性和可管理性3強調早期計劃及需求調查4可強迫開發人員采用規范的方法（例如，結構化技術）。5要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證

是缺乏靈活性、無法通過開發活動明確尚未確定的軟件需求瀑布模型的缺點軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型瀑布模型存在的問題1階段和階段劃分完全固定，階段間產生大量的文檔，極大地增加了工作量2依賴于早期進行的需求調査，不能適應需求的變化，模型的風險控制能力較弱3模型缺乏靈活性，特別是無法解決軟件需求不明確或不準確的問題軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型適用使用瀑布模型開發的項目1有穩定的產品定義和很容易理解的技術解決方案2技術風險低且業務復雜的項目，因為可以按順序的方法來解決復雜的問題3項目開發隊伍經驗不足4開發初始系統沒有明確的需求的大中型項目5系統需求呈動態變化或者高風險性較高的項目不適用使用瀑布模型開發的項目軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型快速原型模型圖快速原型法的基本思想1投入大量的人力、物力之前，在限定時間內，用最經濟的方法構造一個系統原型，然后將原型交給用戶使用，使用戶盡早看到未來系統的概貌2通過用戶的使用原型，啟發用戶進一步明確需求，在系統原型的實際運行中與用戶一起發現問題，據此對原型進行修改3這樣不斷完善修改，直至最后完成一個滿足用戶需求的系統軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型快速原型法的類型探索型用于開發的需求分析階段，主要目的是要明確用戶的需求、產品特性、可行性。針對的目標是開發目標模糊，用戶與開發者對項目都缺乏相應經驗的情況實驗型主要在設計階段使用，測試實現方案是否合適，能否可以實現。如果開發團隊對設計方案沒有把握時，可以使用這種原型用來證實設計方案的正確性演化型用于初始向用戶提交一個原型系統，該原型系統可以包含系統的框架或主要功能，在得到用戶的認可后，將原型系統不斷擴充演變為最終的軟件系統。軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型原型法的開發步驟1調查用戶的基本需求（不是全部需求）2按基本需求快速開發一個“系統原型”3將原型交用戶使用，啟發用戶提出新的要求4按新的要求改進原型，然后再將原型交給用戶使用1234軟件危機軟件工程概念軟件生命周期瀑布模型快速原型模型原型法的優點1它是一種支持用戶的方法，使得用戶在系統生命周期的設計階段就能起到積極的作用2對大型項目的開發，對項目需求的分析難以一次完成，用原型法能減少系統開發的風險3原型法的概念既適用于系統的重新開發，也適用于對系統的修改4原型法可與傳統的生命周期法結合使用，這樣會擴大用戶參與各階段活動的機會，加深對系統的理解快速原型法特別適合于軟件產品需求大量的用戶交互、產生大量的可視輸出、設計一些復雜的算法等場合軟件總體設計PART02設計過程設計原理模塊獨立性啟發式規則

總體設計過程1設想供選擇的方案2選取合理的方案3推薦最佳方案4功能分解5設計軟件結構6設計數據庫7制定測試計劃8書寫文檔9審查和復審設計過程設計原理模塊獨立性啟發式規則

這里所說的設計原理是指在軟件設計過程中應該遵循的基本原理和相關概念抽象抽出事物的本質特性而暫時不考慮它們的細節。軟件工程過程的每一步，都是對軟件解法的抽象層次的一次細化信息隱蔽和局部化模塊所包含的信息對于其他模塊來說應該是隱蔽的在修改期間所造成的影響就可以局限在一個或幾個模塊內部，不至波及到軟件的其他部分模塊化（1）可以使軟件結構清晰（2）使軟件容易測試和調試，從而提高軟件可靠性。（3）能夠提高軟件的可修改性（4）有助于軟件開發的組織管理逐步求精求精實際上是細化過程，抽象與求精是一對互補的概念，求精則幫助設計者在設計過程中逐步揭示出低層細節。模塊的獨立性是軟件質量的關鍵：（1）模塊化程度較高的軟件容易開發；（2）模塊化程度較高的軟件也比較容易測試和維護。模塊的獨立性的度量標準：耦合和內聚設計過程設計原理模塊獨立性啟發式規則

耦合是軟件結構中各個模塊之間相互關聯程度的度量。設計原則：盡量使用數據耦合，少用控制耦合，限制公共耦合的范圍，避免使用內容耦合。設計過程設計原理模塊獨立性啟發式規則

耦合當出現下列情況之一時就為內容耦合：在內容耦合的情形，被訪問模塊的任何變更，或者用不同的編譯器對它再編譯，都會造成程序出錯。這種耦合是模塊獨立性最弱的耦合設計過程設計原理模塊獨立性啟發式規則

耦合：1.內容耦合1一個模塊直接訪問另一個模塊的內部數據2一個模塊不通過正常入口轉到另一個模塊內部3兩個模塊有一部分程序代碼重疊4一個模塊有多個入口

公共耦合：若一組模塊訪問同一個公共數據環境。如公共數據結構、通訊區、內存的公共覆蓋區等設計過程設計原理模塊獨立性啟發式規則

耦合：2.公共耦合外部耦合：一組模塊都訪問同一全局簡單變量而不是同一全局數據結構，而且不是通過參數表傳遞該全局變量的信息。同(2)類似，但又不同。設計過程設計原理模塊獨立性啟發式規則

耦合：3.外部耦合控制耦合：一個模塊通過傳遞開關、標志、名字等控制信息，明顯地控制性選擇另一模塊中的功能。這種耦合的實質是在單一接口上選擇多功能模塊中的某項功能。因此，對被控制模塊的任何修改，都會影響控制模塊。另外，控制耦合也意味著控制模塊必須知道被控制模塊內部的一些邏輯關系，這些都會降低模塊的獨立性設計過程設計原理模塊獨立性啟發式規則

耦合：4.控制耦合標記耦合：一組模塊通過參數表傳遞記錄信息。事實上，這組模塊共享了某一數據結構的子結構，而不是簡單變量。要求這些模塊都必須清楚該記錄的結構，并按結構要求對記錄進行操作。設計過程設計原理模塊獨立性啟發式規則

耦合：5.標記耦合數據耦合：一個模塊訪問另一個模塊時，彼此之間是通過數據參數來交換輸入、輸出信息的。它是松散耦合，模塊間的獨立性較強。如：max（x，y）函數。設計過程設計原理模塊獨立性啟發式規則

耦合：6.數據耦合非直接耦合：兩個模塊之間沒有直接關系，它們之間的聯系完全是通過主模塊的控制和調用來實現的，這就是非直接耦合。這種耦合的模塊獨立性最強。模塊之間的連接越緊密，聯系越多，耦合性就越高，而其模塊獨立性就越弱。設計過程設計原理模塊獨立性啟發式規則

耦合：7.非直接耦合內聚：模塊內部各個元素彼此結合的緊密程度的度量。內聚程度高的模塊應當只做一件事。設計時應該力求做到高內聚設計過程設計原理模塊獨立性啟發式規則

內聚巧合內聚又稱偶然內聚:幾個模塊內湊巧有一些程序段代碼相同，又沒有明顯地表現出獨立的功能，而把這些代碼獨立出來建立的模塊即為巧合內聚模塊。設計過程設計原理模塊獨立性啟發式規則

內聚：1.巧合內聚偶然內聚是最差的內聚情況，故一般是不采用的1很可能在某種情況下一個調用模塊需要對它修改而別的模塊不需要，這時就很難處理2這種模塊的含義也不易理解，甚至難以為他去一個合適的名字3偶然內聚的模塊也難于測試。偶然內聚的模塊存在的問題：邏輯內聚這種模塊把幾種相關的功能組合在一起，每次被調用時，由傳送給模塊的控制型參數來確定該模塊應執行哪一種功能。設計過程設計原理模塊獨立性啟發式規則

內聚：2.邏輯內聚1修改困難,調用模塊中有一個要對其改動,還要考慮到其他調用模塊2模塊內需要增加開關,判斷是誰調用3實際上每次調用只執行模塊中的一部分,其他部分也被裝入了內存,因而效率不高邏輯內聚的模塊存在的問題：時間內聚又稱經典內聚，這種模塊大多為多功能模塊，但模塊的各個功能必須在同一時間段內執行。例如初始化模塊。一般，各部分可以以任意的順序執行。設計過程設計原理模塊獨立性啟發式規則

內聚：3.時間內聚過程內聚：把流程圖中的某一部分劃出組成模塊，就得到過程內聚模塊。內聚：4.過程內聚通信內聚：一個模塊內各功能部分都使用了相同的輸入數據，或產生了相同的輸出數據，則稱之為通信內聚模塊。設計過程設計原理模塊獨立性啟發式規則

內聚：5.通信內聚順序內聚：一個模塊中各個處理元素都密切相關于同一功能且必須順序執行,前一功能元素的輸出就是下一功能元素的輸入。設計過程設計原理模塊獨立性啟發式規則

內聚：6.順序內聚功能內聚：模塊中各個部分都是為完成一項具體功能而協同工作、緊密聯系、不可分割的，則稱該模塊為功能內聚模塊。功能內聚模塊是內聚性最強的模塊。內聚：7.功能內聚設計過程設計原理模塊獨立性啟發式規則

一個模塊內部各個元素之間的聯系越緊密，則它的內聚性就越高，相對地，它與其他模塊之河的耦合性就會減低，而模塊獨立性就越強。因此，獨立性比較強的模塊應是高內聚低耦合的模塊。模塊的耦合性和內聚性之間的關系力求降低模塊得耦合性和提高模塊得內聚性改進軟件結構提高模塊獨立性60行以內模塊規模應該適中控制的層數、同一層模塊數、直接控制的模塊數目、被調用模塊數不宜過多深度、寬度、扇出和扇入都應適當使作用域是控制域的子集模塊的作用域應該在控制域之內如一元二次方程的解力爭降低模塊接口的復雜程度從頂部進入模塊并且從底部退出來設計單入口單出口的模塊啟發式規則只要輸入的數據相同就產生同樣的輸出模塊功能應該可以預測設計過程設計原理模塊獨立性啟發式規則由經驗總結得出了一些啟發式規則：軟件詳細設計PART03軟件詳細設計的主要工具設計過程設計原理模塊獨立性啟發式規則程序流程圖盒圖PAD圖判定表判定樹過程設計語言程序流程圖中常用的符號程序流程圖程序流程圖三種基本結構順序結構分支結構循環結構程序流程圖例：輸出2000到2500年間的所有閏年程序流程圖流程圖的缺點1流程圖本質上不支持隨著軟件開發而不斷的完善設計，對軟件整體結構考慮不足2流線轉移方向任意，缺少對程序員必要的限制，不符合結構化程序設計的要求3流程圖不能清晰的表示數據結構和模塊調用關系4對于大型軟件而言，流程圖過于瑣碎，不容易閱讀和修改N-S圖N-S圖的基本控制結構N-S圖N-S圖的主要特點1N-S圖所有的程序結構均用方框表示程序結構的作用域比程序流程圖清晰2滿足單入口單出口的結構化程序設計要求，控制不能任意轉移（如，不能描述GOTO語句）3嵌套、層次結構清晰，易于確定局部和全局的數據工作區4盒圖形象直觀，設計意圖容易理解，方便編程、復查、測試、維護5容易確定局部數據和全局數據的作用域6盒圖簡單，易學易用7對于復雜處理的繪制不如流程圖方便、靈活[例]閏年判斷的N-S圖N-S圖PAD圖PAD圖的基本控制結構PAD圖PAD圖的主要優點1PAD圖表達的程序過程呈樹狀結構，這種樹型圖可以較為順利的翻譯成程序代碼2用PAD圖表達程序邏輯，清晰明了，開發者易讀、易懂、易記3PAD圖描繪的程序結構清晰度和結構化程度都很高，設計出的程序必定是結構化的程序4PAD圖示是程序的第一層結構，程序中的層數就是PAD圖中的縱線數5PAD圖可以描述程序，也可以描繪數據結構6PAD圖完全支持自頂向下、逐步求精的結構化方法7利用軟件工具可以將問題分析圖轉換成高級語言程序,進而提高了軟件的可靠性和生產率例：對下面的PAD圖，試分析其功能PAD圖一張判定表由四部分組成：（1）左上部列出所有條件；（2）左下部是所有可能做的動作；（3）右上部為各種可能組合條件，其中每一列表示一種可能組合；（4）右下部的每一列是和每一種條件組合所對應的應做的工作。判定表123456789國內乘客TTTTFFFF頭等艙TFTFTFTF殘疾乘客FFTTFFTT行李重量W《30KGTFFFFFFFF免費X（W-30）X2X（W-30）X3X（W-30）X4XX（W-30）X6XX（W-30）X8X（W-30）X12X左上部列出所有條件左下部是所有可能做的動作右上部為各種可能組合條件其中每一列表示一種可能組合右下部的每一列是和每一種條件組合所對應的應做的工作判定表

12345教授

TFFF副教授

FTFF講師

FFTF助教

FFFT講座TFFFF50×

30

×

25

×

20

×

15

×例：某校制定了教師的講課課時津貼標準。對于各種性質的講座，無論教師是什么職稱，每課時津貼費一律是50元；而對于一般的授課，則根據教師的職稱來決定每課時津貼費：教授30元，副教授25元，講師20元，助教15元。判定表教師課時津貼判定樹判定樹PDL是一種用于描述功能模塊的算法設計和加工細節的語言，是所有非正文形式的過程設計工具的統稱，一般叫作設計程序用語言，是一種偽碼。PDL用正文形式表示數據和處理過程的設計工具，是一種“混雜語言”，它使用一種語言的詞匯（通常就是某種自然語言，如中文，英語），同時卻使用另一種語言（某種結構化的程序設計語言，如PHP，C語言）的語法。六、

過程設計語言PDL語言PDL語言的特點1PDL與高級程序設計語言非常類似，很容易轉換成源程序代碼，在詳細設計階段很受歡迎2用PDL寫出的程序，既可抽象，又可具體。因此，容易實現自頂向下、逐步求精的設計原則3PDL描述同自然語言很接近，易于理解4PDL描述可以直接作為注釋插在源程序中，成為程序的內部文檔，對提高程序可讀性非常有益5PDL描述同程序結構相似，因此利用自動產生程序比較容易6PDL不使用專業工具，用普通的文字處理系統，就能完成PDL的書寫和編輯工作

PDL的缺點是不如圖形描述形象直觀，因此常常將PDL描述與一種圖形描述結合起來使用PDL語言的缺點編碼、測試與調試技術PART04編碼把軟件設計結果翻譯成用某種程序設計語言書寫的程序，是對設計的進一步具體化測試軟件測試的目的是盡可能多地發現程序中的錯誤調試調試的目的是確定錯誤的原因和位置，并改正錯誤編碼、測試與調試技術編碼測試調試編碼規則源程序代碼的邏輯簡明清晰、易讀易懂是好程序的一個重要標準，為了做到這一點，應該在以下幾個方面遵循相關的規則。1程序內部的文檔包括恰當的標識符、注解和程序的視覺組織等，如選取含義鮮明的名字，縮進格式2數據說明（1）數據說明的次序應該標準化（例如按照數據結構或數據類型確定說明的次序）。有次序就容易查閱，因此能夠加速測試、調試和維護的過程。（2）當多個變量名在一個語句中說明時，應該按字母順序排列這些變量。（3）如果設計時使用了一個復雜的數據結構，則應該用注解說明用程序設計語言實現這編碼測試調試編碼規則3語句構造構造語句時應該遵循的原則是，每個語句都應該簡單而直接。為此，應遵循以下規則。（1）不要為了節省空間而把多個語句寫在同一行。（2）盡量避免復雜的條件測試。（3）盡量減少對“非”條件的測試。（4）避免大量使用循環嵌套和條件嵌套。（5）利用括號使邏輯表達式或算術表達式的運算次序清晰直觀。編碼測試調試編碼規則4輸入輸出在設計和編寫程序時應該考慮下述有關輸入輸出風格的規則。（1）對所有輸入數據都進行檢驗。（2）檢查輸入項重要組合的合法性。（3）保持輸入格式簡單。（4）使用數據結束標記，不要要求用戶指定數據的數目。（5）明確提示交互式輸入的請求，詳細說明可用的選擇或邊界數值。（6）當程序設計語言對格式有嚴格要求時，應保持輸入格式一致。（7）設計良好的輸出報表。（8）給所有輸出數據加標志。編碼測試調試編碼規則5效率效率主要指處理機時間和存儲器容量兩個方面，編程時應考慮下述規則。（1）寫程序之前先簡化算術的和邏輯的表達式。（2）仔細研究嵌套的循環，以確定是否有語句可以從內層往外移。（3）盡量避免使用多維數組。（4）盡量避免使用指針和復雜的表。（5）使用執行時間短的算術運算。（6）不要混合使用不同的數據類型。（7）盡量使用整數運算和布爾表達式。（8）在效率是決定性因素的應用領域，盡量使用有良好優化特性的編譯程序，以生成高效代碼。（9）提高執行效率的技術通常也能提高存儲器效率，提高存儲器效率的關鍵同樣是“簡單”。（10）簡單清晰同樣是提高人機通信效率的關鍵。（11）如果“超高效的”輸入輸出很難被人理解，則不應采用這種方法。測試的定義：為了發現程序中的錯誤而執行程序的過程。測試貫穿整個實現階段，包括單元測試、綜合測試和確認測試，甚至在維護階段也要進行各種測試。具體地說，軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計出一批測試用例，并利用測試用例來運行程序，以發現程序錯誤的過程。編碼測試調試測試的概念判斷正誤：測試是為了證明程序是正確的成功的測試是沒有發現錯誤的測試成功的測試是發現了至今尚未發現的錯誤的測試編碼測試調試測試的概念編碼測試調試測試的三個重要特征1挑剔性測試的目的是為了發現錯誤,一個好的測試在于能發現至今未發現的錯誤2完全測試的不可能性很多情況下，不可能窮舉所有情況的所有案例進行測試，即不可能做到完全測試3測試的經濟性為了保證質量而又不能進行完全測試，所以應該在重要性及用途和測試所花的代價之間進行權衡編碼測試調試軟件測試的準則1所有測試都應該追溯到用戶需求2應該遠在測試之前就應該制定出測試計劃380%的錯誤是由20%的模塊造成的4應該從小規模逐步到大規模測試5窮舉測試是不可能的6應該由獨立的第三方從事測試工作7應該制定測試計劃并按照計劃嚴格執行，排除隨意性編碼測試調試軟件測試的準則8不應測試自己開發的程序9設計測試用例時，不僅有確定的輸入數據，還有確定的輸出數據10測試用例不僅有合理的，也要有非合理的11除了檢查程序是否做完了它應該做的事，還要檢查它是否做了不應該做的事12保留全部測試用例，作為軟件的組成部分13程序中存在錯誤的概率與在該段程序中已發現的錯誤數成正比編碼測試調試軟件測試的分類1靜態分析：不執行程序，分為討論和走查2動態分析：用測試用例運行程序3自動測試工具中、大型軟件一般都是由若干個子系統組成，每個子系統又由許多模塊組成編碼測試調試軟件測試的流程單元測試又稱模塊測試。每個程序模塊完成一個相對獨立的子功能，所以可以對該模塊進行單獨的測試。由于每個模塊都有清晰定義的功能，所以通常比較容易設計相應的測試方案，以檢驗每個模塊的正確性。在這個測試步驟中所發現的問題，一般為編碼和詳細設計中錯誤編碼測試調試軟件測試的流程：單元測試1模塊接口（1）所測模塊的形式參數和調用該模塊的實際輸入參數在參數數目、屬性和順序上是否匹配；（2）是否修改了只做輸入用的形式參數；（3）輸出給被調用模塊的參數在數目、屬性和順序上是否正確；（4）全程變量的定義和用法在各個模塊中是否一致。若模塊中有外部的I/O操作，還應該進行以下的測試項目：（5）文件屬性是否正確；（6）打開文件語句和關閉語句是否正確；（7）格式說明書與輸入／輸出語句是否一致；（8）緩沖區的大小與記錄長度是否匹配；（9）使用文件之前是否先打開了文件；（10）文件操作結束后是否關閉了文件；（11）是否進行了輸入／輸出錯誤檢查并進行了相應的處理。編碼測試調試1軟件測試的流程：單元測試模塊的局部數據結構是常見的錯誤來源，測試者應該仔細設計測試用例，以便發現這樣一些類型的錯誤：錯誤的變量名；錯誤的或不一致的數據類型說明；使用尚未賦值或尚未初始化的變量；錯誤的初始值或錯誤的缺省值；數據類型不相容；上溢、下溢或地址異常。如果有可能的話，在單元測試期間除了局部數據結構之外，還應該檢查全程數據對模塊的影響。局部數據結構編碼測試調試2軟件測試的流程：單元測試選擇適當測試用例，對模塊中的最有代表性、最可能發現錯誤的執行路徑進行測試。重要的執行路徑編碼測試調試3軟件測試的流程：單元測試程序在運行中出錯往往是不可避免的。因而好的程序設計應該能預見可能出現的各種出錯情況，并且設置相應的出錯處理，以便在出現錯誤時執行相應的操作。在單元測試時也應該對模塊中的出錯處理部分進行測試，進行這一部分測試時可能存在的錯誤主要有：（1）對錯誤的描述難于理解，或者是描述過于簡單；（2）顯示的錯誤信息與實際錯誤不相符；（3）在對錯誤進行處理之前，錯誤條件已經引起系統的干預；（4）對錯誤的處理不正確。出錯處理編碼測試調試4軟件測試的流程：單元測試我們知道，軟件常常在它的邊界上失效。例如，處理n元數組的第一個元素或最后一個元素時，在n次循環中的第n次重復時，往往會發生錯誤。因此，使用剛好小于、等于或大于最大值或最小值的數據結構、控制量和數據值的測試方案時，很可能會發現軟件中的錯誤。邊界條件編碼測試調試5軟件測試的流程：單元測試在單元測試完成后，要考慮將模塊集成為系統的過程中可能出現的問題，例如，模塊之間的通信和協調問題，所以在單元測試結束之后還要進行集成測試。這個步驟著重測試模塊間的接口，子功能的組合是否達到了預期要求的功能，全程數據結構是否有問題等。2．集成測試編碼測試調試軟件測試的流程：集成測試2集成測試的兩種主要方法編碼測試調試軟件測試的流程：集成測試02漸增式測試方法把下一個要測試的模塊同已經測試好的模塊結合起來進行測試，測試完以后再把下一個應該測試的模塊結合進來測試01非漸增式測試方法先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序1.非漸增式測試方法需要編寫的軟件較多，工作量較大；漸增式測試方法開銷小。2.漸增式測試方法發現模塊間接口錯誤早；而非漸增式測試方法晚。3.非漸增式測試方法發現錯誤，較難診斷；而使用漸增式測試方法，如果發生錯誤則往往和最近加進來的那個模塊有關。4.漸增式測試方法測試更徹底5.漸增式測試方法需要較多的機器時間6.使用非漸增式測試方法，可以并行測試。編碼測試調試集成測試的兩種主要方法比較軟件測試的流程：集成測試在實際測試中，應該將兩種方法有機集合起來當使用漸增式測試方法時，具體有自頂向下和自底向上兩種方法。編碼測試調試軟件測試的流程：集成測試02自底向上集成測試從“原子”模塊（即在軟件結構最低層的模塊）開始組裝和測試01自頂向下集成采用這種組裝方式時，是從主控制模塊開始，沿著軟件的控制層次向下移動，從而逐漸把各個模塊都結合起來其結合過程如下：（1）用主控制模塊作為測試驅動模塊，所有直接下屬于主控制模塊的模塊用存根模塊代替，對主模塊進行測試；（2）根據選定的結合策略(深度優先或寬度優先)，每次用一個實際模塊替換一個存根模塊，對新結合進來的模塊的直接下屬模塊，用新的存根模塊代替；（3）對結合進來的模塊進行相應的測試；（4）為了保證新加入的模塊不引入新的錯誤，可以進行回歸測試，即重復以前進行過的部分測試或全部測試。從第（2）步開始，不斷重復進行上述過程，直到所有模塊都結合進來為止。編碼測試調試自頂向下集成測試采用自頂向下的結合策略的好處：在測試過程中能夠較早地對主要的控制或關鍵的判斷點進行檢驗。因為在一個功能劃分合理的軟件結構中，關鍵的判斷點常常出現在較高的層次里，所以能夠較早碰到。如果主要控制存在問題，及早發現這類問題并盡快想辦法解決是十分重要的，這樣可以大大減少后面的工作量。如果選擇的是深度優先結合方法，可以首先實現并驗證軟件的一個比較完整的功能，這樣對增強開發人員和用戶雙方的信心是很有意義的。編碼測試調試自頂向下集成測試采用自頂向下的結合策略的不足：可能會遇到邏輯上的問題。當我們為了充分地測試較高層次的功能時，可能需要較低層次上處理的信息，但是我們采用自頂向下的方法時，存根模塊代替了低層次的模塊，若高層模塊需要低層模塊返回的信息不僅數量大，而且種類也很多時，存根模塊有可能很難完全滿足這個要求，因而，這種方法有一定的局限性。為了解決這個問題，可以采用以下解決辦法：（1）把許多測試推遲到用實際模塊替換了存根模塊以后再進行。采用這種方法也有一定的缺陷：由于我們對一些特定的測試和組裝與特定模塊間的對應關系失去了某些控制，從而在確定錯誤原因時會發生困難。（2）由層次系統的底部向上組裝軟件。這種方法就是下面要介紹的自底向上結合方法。編碼測試調試自頂向下集成測試自底向上集成測試的具體策略是：（1）把低層模塊組合成實現某個特定的軟件子功能的族。（2）寫一個驅動程序（用于測試的控制程序），協調測試數據的輸入和輸出。（3）對由模塊組成的子功能族進行測試。（4）去掉驅動程序，沿軟件結構自下向上移動，把子功能族組合起來形成更大的子功能族。（5）循環(2)-(4)步編碼測試調試自底向上集成測試編碼測試調試自底向上集成測試02主要缺點直到最后一個模塊結合進來以前，程序作為一個整體始終不存在。也就是說，對主要的控制直到最后才接觸到。01主要優點不需要設計存根模塊，而設計測試驅動模塊一般比建立存根模塊要容易，同時比較容易設計測試用例，并且可以實現多個模塊的并行測試，從而提高測試效率自底向上集成測試的優缺點3．有效性測試任務是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。對軟件的功能和性能要求在軟件需求規格說明書中已經明確規定。它包含的信息就是軟件確認測試的基礎。編碼測試調試軟件測試的流程34．系統測試系統測試是把通過有效性測試的軟件，作為基于計算機系統的一個整體元素，與整個系統的其他元素結合起來，在實際運行環境下，對計算機系統進行一系列的集成測試和有效性測試。編碼測試調試軟件測試的流程4驗收測試測試內容和系統測試基本類似，但是要有用戶的參與，主要使用實際數據。目的是驗證系統確實能滿足用戶的需求。發現的往往是需求說明書中的錯誤又稱確認測試編碼測試調試軟件測試的流程56.平行運行（1）可以在準生產環境中運行而又不冒險（2）用戶能有一段熟悉新系統的時間（3）可以驗證用戶指南和使用手冊等文檔（4）能夠以準生產模式對新系統進行全負荷測試，可以用測試結果驗證性能指標編碼測試調試軟件測試的流程6編碼測試調試軟件測試的方法02黑盒測試又稱功能測試，即把程序看作一個黑盒子，完全不考慮程序的內部結構和處理過程，也就是根據程序的功能或程序的外部特性設計測試用例01白盒測試又稱為結構測試或邏輯測試，即把程序看成裝在一個透明的白盒子里，測試者完全知道程序的結構和處理算法。白盒測試技術通過在不同點檢查程序的狀態，確定實際的狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。軟件人員使用白盒測試方法，主要想對程序模塊進行如下的檢查：

對程序模塊的所有獨立的執行路徑至少測試一次；對所有的邏輯判定，取“真”與取“假”的兩種情況都至少測試一次；在循環的邊界和運行界限內執行循環體；測試內部數據結構的有效性，等。編碼測試調試白盒測試技術編碼測試調試白盒測試技術運行被測程序，使得每一可執行語句至少執行一次語句覆蓋又稱為分支覆蓋。使得程序中每個判斷的取真和取假分支至少經歷一次。從而使程序的每一個分支至少都通過一次。判定覆蓋使得判定表達式中每個條件的各種可能的值至少出現一次，且每個語句也至少執行一次條件覆蓋使得判定表達式中的每個條件的所有可能取值至少出現一次，并使每個判定表達式所有可能的結果也至少出現一次判定／條件覆蓋使得每個判定表達式中條件的各種可能的值的組合都至少出現一次。是比較強的覆蓋標準條件組合覆蓋覆蓋被測程序中所有可能的路徑路徑覆蓋常見白盒測試(A>1)

and

(B=0)(A=2)

or

(X>1)X=X/AX=X+1TTFFabdce編碼測試調試白盒測試技術共有4條路徑：L1(ace)條件：{(A>1)and(B=0)}and{(A=2)or(X/A>1)}

測試用例：[(2,0,4)，(2,0,3)]L2(abd)條件：

not{(A>1)and(B=0)}andnot{(A=2)or(X>1)}測試用例：

[(1,1,1)，(1,1,1)]L3(abe)條件：not{(A>1)and(B=0)}and{(A=2)or(X>1)}測試用例：

[(2,1,1)，(2,1,1)]L4(acd)條件：

{(A>1)and(B=0)}andnot{(A=2)or(X/A>1)}測試用例：

[(3,0,3)，(3,1,1)]編碼測試調試白盒測試技術L1(ace)（1）.語句覆蓋語句覆蓋就是設計若干個測試用例，運行被測程序，使得每一可執行語句至少執行一次。在圖例中，正好所有的可執行語句都在路徑L1上，所以選擇路徑L1設計測試用例，就可以覆蓋所有的可執行語句。(2,0,4)，(2,0,3)]覆蓋ace[L1]編碼測試調試白盒測試技術L1(ace)L2(abd)(2).判定覆蓋判定覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的取真分支和取假分支至少經歷一次。判定覆蓋又稱為分支覆蓋。對于圖例，如果選擇路徑L1和L2，就可得滿足要求的測試用例:(2,0,4)，(2,0,3)]覆蓋ace[L1](1,1,1)，(1,1,1)]覆蓋abd[L2]編碼測試調試白盒測試技術(3).條件覆蓋條件覆蓋就是設計若干個測試用例，運行被測程序，使得程序中每個判斷的每個條件的可能取值至少執行一次，且每個語句至少執行一次。在圖例中，我們事先可對所有條件的取值加以標記。例如

對于第一個判斷：條件A＞1取真為T1，取假為T1條件B＝0取真為T2，取假為T2測試用例覆蓋分支條件取值[(2,0,4),(2,0,3)]L1(c,e) T1T2T3T4[(1,0,1),(1,0,1)]L2(b,d) T1

T2

T3T4[(2,1,1),(2,1,2)]

L3(b,e) T1T2

T3

T4或[(1,0,3),(1,0,4)]L3(b,e) T1

T2T3

T4[(2,1,1),(2,1,2)]L3(b,e) T1

T2T3

T4

對于第二個判斷：

條件A＝2取真為T3，取假為T3

條件X＞1取真為T4，取假為T4編碼測試調試白盒測試技術(4).判定－條件覆蓋

判定－條件覆蓋就是設計足夠的測試用例，使得判斷中每個條件的所有可能取值至少執行一次，每個判斷中的可能取值至少執行一次。測試用例 覆蓋分支條件取值[(2,0,4),(2,0,3)]L1(c,e)

T1T2T3T4[(1,1,1),(1,1,1)]L2(b,d)

T1T2T3T4編碼測試調試白盒測試技術記①A＞1,B＝0作T1T2

②A＞1,B≠0作T1

T2

③A≯1,B＝0作

T1

T2④A≯1,B≠0作T1T2(5).條件組合覆蓋條件組合覆蓋就是設計足夠的測試用例，運行被測程序，使得每個判斷的所有可能的條件取值組合至少執行一次。⑤A＝2,X＞1作T3T4

⑥A＝2,X≯1作T3

T4

⑦A≠2,X＞1作T3

T4

⑧A≠2,X≯1作T3T4測試用例覆蓋條件覆蓋組合【(2,0,4),(2,0,3)】(L1) ①,⑤【(2,1,1),(2,1,2)】(L3) ②,⑥【(1,0,3),(1,0,4)】(L3) ③,⑦【(1,1,1),(1,1,1)】(L2) ④,⑧編碼測試調試白盒測試技術(6).路徑覆蓋選取足夠多測試數據，使程序的每條可能路徑都至少執行一次（如果程序圖中有環，則要求每個環至少經過一次）。但是，為了做到路徑覆蓋只需考慮每個判定表達式的取值，并沒有檢驗表達式中條件的各種可能組合情況。

測試用例

通過路徑

覆蓋條件【(2,0,4),(2,0,3)】ace(L1)

T1T2T3T4【(1,1,1),(1,1,1)】abd(L2)T1T2T3T4【(2,1,1),(1,1,3)】abe(L3)T1T2T3

T4【(3,0,3),(3,0,1)】acd(L4) T1T2

T3T4編碼測試調試白盒測試技術

黑盒測試：是一種常用的軟件測試方法，它將被測軟件看作一個打不開的黑盒，主要根據功能需求設計測試用例，進行測試。黑盒測試著重測試軟件功能編碼測試調試黑盒測試技術力圖發現以下錯誤編碼測試調試黑盒測試技術1功能不正確或遺漏了功能2界面錯誤3數據結構錯或外部數據庫訪問錯4性能錯誤5初始化或終止錯誤黑盒測試應考慮的問題編碼測試調試黑盒測試技術1怎樣測試功能的有效性2哪些類型的輸入可構成好的測試用例3系統是否對特定的輸入值敏感4怎樣劃定輸入類的邊界5系統能承受怎樣的數據率和數據量6數據的特定組合將對系統運行產生什么影響編碼測試調試黑盒測試技術邊界值分析實踐說明：程序往往在處理邊界情況時發生錯誤，處理邊界情況時，程序最容易發生錯誤因果圖是通過畫因果圖，把用自然語言描述的功能說明轉換為判定表，最后為判定表的每一列設計一個測試用例。等價類劃分把所有可能的輸入數據劃分成若干個等價的子集，使得每個子集中的一個典型值在測試中的作用與這一子集中所有其他值的作用相同錯誤推測在測試程序時，人們可能根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例黑盒測試法的四種常用測試法等價類劃分：把所有可能的輸入數據劃分成若干個等價的子集，使得每個子集中的一個典型值在測試中的作用與這一子集中所有其他值的作用相同。例如：輸入的數據范圍是1-999，我們可以劃分三類：x<1，1<=x<999，x>=999編碼測試調試黑盒測試技術：等價劃分等價類劃分的啟發式規則如果規定了輸入值的范圍，則可劃分出一個有效的等價類兩個無效的等價類。如果規定了輸入數據個數，則可劃分出一個有效的等價類和兩個無效的等價類如果規定了輸入數據的一組值，而且程序對不同輸入值做不同處理，則每個允許的輸入值是一個有效的等價類，此外還有一個無效的等價類如果規定了輸入數據必須遵循的規則，則可以劃分出一個有效的等價類（符合規則）和若干個無效的等價類（從各種不同角度違反規則）如果規定了輸入數據為整型，則可以劃分出正整數、零和負整數等三個有效類；如果程序的處理對象是表格，則應該使用空表，以及含一項或多項的表編碼測試調試黑盒測試技術：等價劃分123456如果輸入條件規定了取值范圍，則對邊界和邊界附近設計測試用例。如果輸入條件規定了數據的個數，則要對值的最大個數、最小個數、稍大于最大個數、稍小于最小個數情況進行設計測試用例。針對規格說明中的每個輸出條件同樣可使用(1)，(2)。如果規格說明中提到的輸入和輸出域是有序的集合，則應選取第一個和最后一個元素作為測試用例。實踐說明：處理邊界情況時，程序最容易發生錯誤。例如：輸入數據的值的范圍是：-1.0至1.0，則可選-1.0，1.0，-1.001，1.001等數據作為測試數據。編碼測試調試黑盒測試技術：邊界值分析等價類劃分的啟發式規則1234通過經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性設計測試用例。錯誤推測法在很大程度上靠直覺和經驗進行。它的基本想法是列舉出程序中可能有的錯誤和容易發生錯誤的特殊情況，對于程序中容易出錯的情況也有一些經驗總結出來，例如，輸入數據為零或輸出數據為零往往容易發生錯誤；在一段程序中已經發現的錯誤數目往往和尚未發現的錯誤數成正比。編碼測試調試黑盒測試技術：錯誤推測法因果圖能有效地檢測輸入條件的各種組合可能引起的錯誤。通過畫因果圖，把用自然語言描述的功能說明轉換為判定表，最后為判定表的每一列設計一個測試用例通常在因果圖中，用C表示原因，E表示結果，其基本符號如圖所示。各結點表示狀態，可取值“0”或“l”。“0”表示某狀態不出現，“l”表示某狀態出現。編碼測試調試黑盒測試技術：因果圖分析利用因果圖生成測試用例的基本步驟是(5步)：確定軟件規格(需求)中的原因和結果確定原因和結果之間的邏輯關系畫出因果圖確定因果圖中的各個約束畫出因果圖并轉換為判定表（決策表）根據判定表設計測試用例編碼測試調試黑盒測試技術：因果圖分析12345【案例分析】自動售貨機產品說明書：有一個處理單價為1元5角錢的盒裝飲料的自動售貨機軟件。若投入1元5角硬幣，按下“可樂”、“雪碧”、或“紅茶”按鈕，相應的飲料就送出來。若投入的是2元硬幣，在送出飲料的同時退還5角硬幣。編碼測試調試黑盒測試技術：因果圖分析（1）確定需求中的原因與結果原因：C1:投入1元5角硬幣C2:投入2元硬幣C3：按“可樂”按鈕C4：按“雪碧”按鈕C5：按“紅茶”按鈕結果：E1：退還5角硬幣E2：送出“可樂”飲料E3：送出“雪碧”飲料E4：送出“紅茶”飲料編碼測試調試黑盒測試技術：因果圖分析（2）確定原因與結果的邏輯關系C1與C2需要一個中間結果Cm1,C3、C4、C5需要一個中間結果Cm2.（3）確定因果圖中的約束C1與C2是或的關系,C3、C4、C5是或的關系。（4）畫出因果圖并轉化為決策表VC1C2C3C4C5Cm1Cm2E1E2E3E4VVVVV編碼測試調試黑盒測試技術：因果圖分析（5）決策表

將原因C1、C2、C3、C4、C5按二進制由小到大分別取值，并分析中間結果的成立與否，進而得出下面的簡化版（即中間結果Cm1、Cm2成立的情況）原因中間結果編號C1C2C3C4C5Cm1Cm21000002000013000104000115001006001017001108001119010001001001111101010111201011130110011140110115011101601111原因中間結果編號C1C2C3C4C5Cm1Cm21710000181000111191001011201001121101001122101012310110241011125110002611001271101028110112911100301110131111103211111簡化版原因中間結果結果編號C1C2C3C4C5Cm1Cm2Ef1Ef2Ef3Ef410100111TFFT20101011TFTF30110011TTFF41000111FFFT51001011FFTF61010011FTFF編號輸入數據預期輸出實際輸出判定1投入2元硬幣、按下紅茶退還5角、送出紅茶2投入2元硬幣、按下雪碧退還5角、送出雪碧3投入2元硬幣、按下可樂退還5角、送出可樂4投入1.5元硬幣、按下紅茶送出紅茶5投入1.5元硬幣、按下雪碧送出雪碧6投入1.5元硬幣、按下可樂送出可樂【補充習題】自動售貨機有一個處理單價為5角錢的飲料的自動售貨機軟件測試用例的設計。其規格說明如下：“若投入5角錢或1元錢的硬幣，押下“橙汁”或“啤酒”的按鈕，則相應的飲料就送出來。若售貨機沒有零錢找，則一個顯示“零錢找完”的紅燈亮，這時在投入1元硬幣并押下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示“零錢找完”的紅燈滅，在送出飲料的同時退還5角硬幣?！本幋a測試調試黑盒測試技術：因果圖分析軟件調試是在進行了成功的測試之后才開始的工作。它與軟件測試不同，調試的任務是進一步診斷和改正程序中潛在的錯誤。調試活動由兩部分組成編碼測試調試調試技術02改錯對程序(