《新編計算機文化基礎》12 軟件工程基礎

第１２章軟件工程基礎1243352.1軟件工程的基本概念12.2結構化分析方法12.3結構化設計方法

12.4軟件測試12.5程序調(diào)試

下一頁返回第１２章軟件工程基礎612.6軟件維護上一頁返回12.1軟件工程的基本概念12.1.1軟件的概念與特點軟件是由計算機程序演變而形成的一個概念，它是程序和程序設計發(fā)展到規(guī)?；蜕唐坊笏饾u形成的概念。軟件是程序、數(shù)據(jù)與相關文檔的完整集合。其中，程序是按既定算法，用某種計算機語言規(guī)定的指令或語句編寫的指令或語句的集合。數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結構。文檔是與程序開發(fā)、維護和使用有關的圖文材料。相對于計算機硬件而言，軟件是邏輯產(chǎn)品而不是物理產(chǎn)品，是計算機的無形部分。與硬件相比，軟件的特點包括：（１）軟件是一種邏輯實體，具有抽象性。（２）軟件的生產(chǎn)與硬件不同，它沒有冥想的制造過程。（３）軟件的使用和運行過程中，不存在磨損和老化的問題。下一頁返回12.1軟件工程的基本概念（４）軟件的開發(fā)和運行與計算機系統(tǒng)之間具有相關性，對計算機系統(tǒng)有著不同程度的依賴。（５）軟件的開發(fā)基本上還處于針對需求定做的手工開發(fā)階段。（６）軟件的復雜性高，成本相當昂貴。（７）軟件開發(fā)工作涉及社會因素。軟件按照功能可以分為系統(tǒng)軟件、支撐軟件和應用軟件。系統(tǒng)軟件用于管理計算機自身的資源，協(xié)調(diào)計算機軟硬件工作的軟件。例如，操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、設備驅動程序等。支撐軟件是協(xié)助用戶開發(fā)軟件的工具軟件，分為開發(fā)工具和開發(fā)管理工具，例如，文件編輯程序、設計分析程序、測試覆蓋檢驗程序等。應用軟件是為特定應用領域而開發(fā)的，具有特定服務的軟件。上一頁下一頁返回12.1軟件工程的基本概念12.1.2軟件危機二十世紀５０年代到６０年代，人們把軟件當成是按照自己意圖創(chuàng)造的“藝術品”，以追求通篇使用程序技巧為榮，所編寫出的程序很難讓別人看懂。當時的軟件開發(fā)基本上依賴于開發(fā)人員的個人技能，沒有可遵循的原理、原則和方法，也缺乏有效的工程化的管理、協(xié)調(diào)手段。由于人類智力在處理大型、復雜問題方面的局限性，人們對大型軟件項目的開發(fā)往往力不從心。軟件開發(fā)的成本失控，提交時間延遲，軟件質(zhì)量難以保證，維護困難，可移植性差，類似軟件之間很少能夠重用。許多重要的大型軟件項目在消耗了大量人力物力之后，由于距預定目標甚遠而不得不宣告失敗。這便產(chǎn)生了所謂的“軟件危機”，并進一步達到了難以容忍的程度。具體來說軟件危機表現(xiàn)在以下幾個方面：上一頁下一頁返回12.1軟件工程的基本概念（１）軟件開發(fā)的成本及進度無法控制。（２）開發(fā)過程缺乏規(guī)范的原則和方法論的指導，缺乏適當?shù)奈臋n資料，使得在軟件常常是不可維護的。（３）軟件開發(fā)過程缺乏質(zhì)量保證技術（審查、復審和測試等），造成軟件產(chǎn)品的質(zhì)量沒有保證。（４）軟件需求沒有充分分析，往往對需求一知半解便開始編程，造成開發(fā)后期矛盾的集中暴露。（５）軟件產(chǎn)品“供不應求”，軟件開發(fā)生產(chǎn)率提高的速度遠遠跟不上計算機應用迅速普及并深入的趨勢。上一頁下一頁返回12.1軟件工程的基本概念要解決這些問題，既要有技術措施（方法和工具），又要有必要的組織管理措施。只有端正了對軟件的認識，真正抓住了它的特點和發(fā)展趨勢，才能逃出危機，走上軟件發(fā)展的正確道路。軟件工程正是按工程化的原則和方法組織軟件開發(fā)工作，從管理和技術兩方面研究如何運用工程學的基本原理和方法來更好地開發(fā)和維護計算機軟件的一門新興學科。上一頁下一頁返回12.1軟件工程的基本概念12.1.3軟件工程的定義“軟件工程”一詞是１９６８年北大西洋公約組織（ＮＡＴＯ）在聯(lián)邦德國召開的一次會議上首次提出的。它的中心思想是把軟件當作一種工業(yè)產(chǎn)品，而不是某種個體或小作坊的神秘技巧，要求“采用工程化的原理與方法對軟件進行計劃、開發(fā)和維護”。這樣做的目的，不僅是為了實現(xiàn)按預期的速度和經(jīng)費完成軟件生產(chǎn)計劃，也是為了提高軟件的生產(chǎn)率與可靠性。上一頁下一頁返回12.1軟件工程的基本概念軟件工程是采用工程化的方法開發(fā)和維護軟件的工程學科。把經(jīng)過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術和方法結合起來，以便經(jīng)濟地開發(fā)出高質(zhì)量的軟件并有效地維護它。軟件工程包括３個要素，分別是方法、工具和過程。（１）軟件工程的方法為軟件開發(fā)提供了“如何做”的技術。它包括了多方面的任務，如項目計劃與估算、軟件系統(tǒng)需求分析、數(shù)據(jù)結構、系統(tǒng)總體結構的設計、算法過程的設計、編碼、測試以及維護等。（２）軟件工具為軟件工程方法提供了自動的或半自動的軟件支撐環(huán)境。目前，已經(jīng)推出了許多軟件工具，這些軟件工具集成起來，建立起稱之為計算機輔助軟件工程（ＣＡＳＥ）的軟件開發(fā)支撐系統(tǒng)。上一頁下一頁返回12.1軟件工程的基本概念ＣＡＳＥ將各種軟件工具、開發(fā)機器和一個存放開發(fā)過程信息的工程數(shù)據(jù)庫組合起來形成一個軟件工程環(huán)境。（３）軟件工程的過程則是將軟件工程的方法和工具綜合起來以達到合理、及時地進行計算機軟件開發(fā)的目的。過程定義了方法使用的順序、要求交付的文檔資料、為保證質(zhì)量和協(xié)調(diào)變化所需要的管理，及軟件開發(fā)各個階段完成的里程碑。雖然每一個從事軟件開發(fā)的機構都有自己的軟件工程過程，就算是同一個軟件開發(fā)機構，對不同的軟件項目也可能有不同的軟件工程，但是無論存在怎樣的差別，軟件工程都具有以下四個基本過程活動：（１）軟件規(guī)格說明：規(guī)定軟件的功能及其運行的限制；上一頁下一頁返回12.1軟件工程的基本概念（２）軟件開發(fā)：產(chǎn)生滿足規(guī)格說明的軟件；（３）軟件確認：確認軟件能夠完成客戶提出的要求；（４）軟件演進：為滿足客戶的變更要求，軟件必須在使用的過程中演進。自從提出“軟件工程”這一術語以來，研究軟件工程的專家學者們陸續(xù)提出了１００多條關于軟件工程的準則或信條。美國著名的軟件工程專家Ｂｏｅｈｍ綜合這些專家的意見，并總結了ＴＲＷ公司多年的開發(fā)軟件的經(jīng)驗，于１９８３年提出了軟件工程的七條基本原理。上一頁下一頁返回12.1軟件工程的基本概念（１）用分階段的生命周期計劃嚴格管理。這一條是吸取前人的教訓而提出來的。統(tǒng)計表明，５０％以上的失敗項目是由于計劃不周而造成的。在軟件開發(fā)與維護的漫長生命周期中，需要完成許多性質(zhì)各異的工作。這條原理意味著，應該把軟件生命周期分成若干階段，并相應制定出切實可行的計劃，然后嚴格按照計劃對軟件的開發(fā)和維護進行管理。Ｂｏｅｈｍ認為，在整個軟件生命周期中應指定并嚴格執(zhí)行６類計劃：項目概要計劃、里程碑計劃、項目控制計劃、產(chǎn)品控制計劃、驗證計劃、運行維護計劃。上一頁下一頁返回12.1軟件工程的基本概念（２）堅持進行階段評審。統(tǒng)計結果顯示：大部分錯誤是在編碼之前造成的，大約占６３％。錯誤發(fā)現(xiàn)的越晚，改正它要付出的代價就越大，要差２到３個數(shù)量級。因此，軟件的質(zhì)量保證工作不能等到編碼結束之后再進行，應堅持進行嚴格的階段評審，以便盡早發(fā)現(xiàn)錯誤。（３）實行嚴格的產(chǎn)品控制。開發(fā)人員最痛恨的事情之一就是改動需求。但是實踐告訴我們，需求的改動往往是不可避免的。這就要求我們要采用科學的產(chǎn)品控制技術來順應這種要求。也就是要采用變動控制，又叫基準配置管理。當需求變動時，其他各個階段的文檔或代碼隨之相應變動，以保證軟件的一致性。上一頁下一頁返回12.1軟件工程的基本概念（４）采納現(xiàn)代程序設計技術。從六、七十年代的結構化軟件開發(fā)技術，到近的面向對象技術，從第一、第二代語言，到第四代語言，人們已經(jīng)充分認識到：采用先進的技術既可以提高軟件開發(fā)的效率，又可以減少軟件維護的成本。（５）結果應能清楚地審查。軟件是一種看不見、摸不著的邏輯產(chǎn)品。軟件開發(fā)小組的工作進展情況可見性差，難于評價和管理。為更好地進行管理，應根據(jù)軟件開發(fā)的總目標及完成期限，盡量明確地規(guī)定開發(fā)小組的責任和產(chǎn)品標準，從而使所得到的標準能清楚地審查。上一頁下一頁返回12.1軟件工程的基本概念（６）開發(fā)小組的人員應少而精。開發(fā)人員的素質(zhì)和數(shù)量是影響軟件質(zhì)量和開發(fā)效率的重要因素，應該少而精。這一條基于兩點原因：高素質(zhì)開發(fā)人員的效率比低素質(zhì)開發(fā)人員的效率要高幾倍到幾十倍，開發(fā)工作中犯的錯誤也要少得多；當開發(fā)小組為N人時，可能的通訊信道為N（N－１）／２，可見隨著人數(shù)N的增大，通信開銷將急劇增大。（７）承認不斷改進軟件工程實踐的必要性。遵從上述六條基本原理，就能夠較好地實現(xiàn)軟件的工程化生產(chǎn)。但是，它們只是對現(xiàn)有的經(jīng)驗的總結和歸納，并不能保證趕上技術不斷前進發(fā)展的步伐。因此，Ｂｏｅｈｍ提出應把承認不斷改進軟件工程實踐的必要性作為軟件工程的第七條原理。上一頁下一頁返回12.1軟件工程的基本概念根據(jù)這條原理，不僅要積極采納新的軟件開發(fā)技術，還要注意不斷總結經(jīng)驗，收集進度和消耗等數(shù)據(jù)，進行出錯類型和問題報告統(tǒng)計。這些數(shù)據(jù)既可以用來評估新的軟件技術的效果，也可以用來指明必須著重注意的問題和應該優(yōu)先進行研究的工具和技術。上一頁下一頁返回12.1軟件工程的基本概念12.1.4軟件生命周期軟件工程采用的生命周期方法學就是從時間角度對軟件開發(fā)和維護的復雜問題進行分解，把軟件生存的漫長周期依次劃分為上述階段，每個階段有相對獨立的任務，然后逐步完成各個階段的任務。這里所說的“軟件生存的漫長周期”是指從提出軟件產(chǎn)品開始，直到該軟件產(chǎn)品被淘汰的全過程。研究軟件生命周期是為了更科學地、有效地組織和管理軟件的生產(chǎn)、維護，從而使軟件產(chǎn)品更可靠，更經(jīng)濟。上一頁下一頁返回12.1軟件工程的基本概念軟件生命周期是指軟件定義、開發(fā)、使用、維護到報廢為止的整個過程，可分為３個時期：計劃期、開發(fā)期和運行期。計劃期又分為問題定義和可行性研究兩個階段；開發(fā)期分為４個階段：需求分析階段、設計階段（總體設計、詳細設計）、編碼階段和測試階段；運行期即維護階段，軟件生命周期的模型示意圖如圖１２-１所示。１．問題定義階段問題定義階段的任務是要確定軟件系統(tǒng)所要解決的任務。分析人員在與用戶和部門負責人交流之后，應提出關于問題性質(zhì)、工程目標和規(guī)模的書面報告，即軟件系統(tǒng)目標與范圍的說明。上一頁下一頁返回12.1軟件工程的基本概念為了成功地完成問題定義階段的任務，需要硬件人員和軟件人員的共同參與，這一階段是軟件生存周期中較短的階段。２．可行性研究階段（１）可行性研究的任務?？尚行匝芯康哪康脑谟谟米钚〉拇鷥r確定在問題定義階段確定的系統(tǒng)目標和規(guī)模是否現(xiàn)實，所確定的問題是否可以解決，系統(tǒng)方案在經(jīng)濟上、技術上和操作上是否可以接受?？尚行匝芯恐乜紤]以下幾個方面：①經(jīng)濟可行性。估計開發(fā)費用以及新系統(tǒng)可能帶來的收益，將兩者進行權衡，看結果是否可以接受。上一頁下一頁返回12.1軟件工程的基本概念②技術可行性。對要求的功能、性能以及限制條件進行分析，看是否能夠做成一個可接受的系統(tǒng)。所考慮的因素通常還應包括開發(fā)的風險，是否能夠得到需要的軟件和硬件資源，以及一個熟練的有能力的開發(fā)隊伍，另外與系統(tǒng)開發(fā)有關的技術是否足以支持系統(tǒng)的研制。技術可行性的估計，需要有經(jīng)驗的人員去完成。③操作可行性。判斷系統(tǒng)的操作方式在該用戶組織內(nèi)是否可行。（２）推薦方案。根據(jù)可行性研究結果要做出的決定是：是否繼續(xù)按預定目標進行開發(fā)?？尚行苑治鋈藛T必須清楚地表明他對這個關鍵性決定的建議。如果認為值得繼續(xù)進行這項開發(fā)工程，則應提供一種最好的解決方案，并說明理由。上一頁下一頁返回12.1軟件工程的基本概念（３）軟件開發(fā)計劃。分析人員應該為推薦的系統(tǒng)草擬一份軟件開發(fā)計劃。軟件開發(fā)計劃是根據(jù)用戶提出的功能性要求，開發(fā)時間和費用的限制而制定的，它要說明該項目需要的硬件資源和軟件資源，需要的開發(fā)人員的層次和數(shù)量，項目開發(fā)費用的估算，開發(fā)進度的安排等。軟件開發(fā)計劃的閱讀者可以包括軟件主管部門、用戶和技術人員。所確定的成本與進度可供主管部門復審。軟件開發(fā)計劃同時也給出了整個軟件生存周期的基本預算和進度安排。３．需求分析階段上一頁下一頁返回12.1軟件工程的基本概念需求分析就是對待開發(fā)軟件提出的需求進行分析并給出詳細的定義。這一階段的基本任務是：用戶和分析人員雙方共同來理解系統(tǒng)的需求，并將共同理解形成一份文件，即軟件需求說明書。該階段是面向用戶問題的，它主要是對用戶的業(yè)務活動進行分析，明確在用戶的業(yè)務環(huán)境中軟件系統(tǒng)應該“做什么”。需求分析階段是用戶與軟件人員雙方討論協(xié)商的階段，由用戶提出問題，軟件開發(fā)人員給出問題的解答。用戶的業(yè)務活動和業(yè)務環(huán)境對軟件開發(fā)人員來說是不熟悉的，要想在短期內(nèi)搞清楚是不太可能的；用戶只熟悉本身的業(yè)務活動和業(yè)務環(huán)境，不熟悉計算機技術。因而，用戶必須對軟件功能和性能提出初步要求，并澄清一些模糊概念；上一頁下一頁返回12.1軟件工程的基本概念軟件分析人員則要認真了解用戶的要求，細致地進行調(diào)查分析，把用戶“做什么”的要求最終轉換成一個完全的、精細的軟件邏輯模型并寫出軟件的需求說明書，準確地表達用戶的要求。需求說明書主要有三個作用：作為用戶和軟件開發(fā)人員之間的合同；作為開發(fā)人員進行設計和編程的根據(jù)；作為軟件開發(fā)完成后驗收的依據(jù)。編寫需求說明書時，應該完整、一致、精確、無二義性，同時又要簡明、易懂、易修改。它越精確，以后出現(xiàn)錯誤、混淆、反復的可能性就越小。如“系統(tǒng)查詢等待時間很短”等詞語，是含糊不清的描述，驗收時無法檢查，而“查詢等待時間不超過５秒”就是精確的描述，驗收時就可檢查是否達到這個要求。上一頁下一頁返回12.1軟件工程的基本概念需求分析的最后一步是需求分析評審，它可以作為需求分析階段工作的復查手段，對功能的正確性、完整性和清晰性，以及其他需求給予評價，評審的主要內(nèi)容包括看系統(tǒng)定義的目標是否與用戶的要求一致，開發(fā)的技術風險是什么，是否詳細制定了檢驗標準，有沒有遺漏、重復或不一致的地方，軟件開發(fā)計劃中的估算是否受到了影響等。４．軟件設計階段在軟件需求分析階段已經(jīng)弄清楚了軟件的各種需求，解決了軟件“做什么”的問題，并使用軟件需求說明書對需求進行了詳細充分的闡述，接下來就是要解決“怎么做”的問題了。上一頁下一頁返回12.1軟件工程的基本概念通常，可以將設計定義為“應用各種技術和原理，對設備、過程或系統(tǒng)做出足夠詳細的定義，使之能夠在物理上得以實現(xiàn)”。而軟件設計則是根據(jù)需求說明書提供的軟件需求、功能需求及性能需求，采用某種設計方法進行數(shù)據(jù)設計、系統(tǒng)結構設計和過程設計。數(shù)據(jù)設計側重于數(shù)據(jù)結構的定義。系統(tǒng)結構設計定義軟件各主要成分之間的關系。過程設計則是把結構成分轉換成軟件的過程性描述。從工程管理的角度來看，軟件設計可以分為總體設計和詳細設計兩個步驟，如圖１２-２所示上一頁下一頁返回12.1軟件工程的基本概念（１）總體設計。總體設計是為軟件系統(tǒng)定義一個邏輯上一致的結構：進行模塊劃分，建立模塊層次結構及模塊間的調(diào)用關系，設計全局數(shù)據(jù)結構及數(shù)據(jù)庫，設計系統(tǒng)接口及人機界面等。總體設計的方法有許多種。在早期有模塊化方法，功能分解方法，這都屬于常用的方法，在２０世紀６０年代后期提出了面向數(shù)據(jù)流的設計方法，面向數(shù)據(jù)結構的設計方法，近年來又提出面向對象的設計方法等。（２）詳細設計。詳細設計是根據(jù)每個模塊的功能描述，選擇某種過程的表達形式來描述每個模塊的算法，以及這些算法的邏輯控制流程，并設計出這些模塊所需的局部數(shù)據(jù)結構。上一頁下一頁返回12.1軟件工程的基本概念詳細設計的方法主要有結構程序設計方法。詳細設計的表示工具有圖形工具和語言工具，圖形工具有程序流程圖、ＰＡＤ（ＰｒｏｂｌｅｍＡｎａｌｙｓｉｓＤｉａｇｒａｍ）圖、ＮＳ圖，語言工具有偽碼和ＰＤＬ（ＰｒｏｇｒａｍＤｅｓｉｇｎＬａｎｇｕａｇｅ）等（３）文檔。設計階段結束要交付的文檔是設計說明書。設計說明書前面部分在總體設計后完成，后面部分是詳細設計后寫出。設計說明書有兩個作用：對于編程和測試，它提供了一個指南；軟件交付使用后，為維護人員提供幫助。設計說明書的框架和內(nèi)容如下：①概述。描述設計工作總的范圍，包括系統(tǒng)目標、功能、接口等。上一頁下一頁返回12.1軟件工程的基本概念②系統(tǒng)結構。用軟件結構圖說明本系統(tǒng)的模塊劃分，扼要說明每個模塊的功能，分層次地給出各模塊之間的控制關系。③數(shù)據(jù)結構及數(shù)據(jù)庫設計。對整個系統(tǒng)使用的數(shù)據(jù)結構及數(shù)據(jù)庫進行設計，包括概念結構設計、邏輯結構設計、物理設計。用相應的圖形和表格把設計結果描述出來。④接口設計。要進行人機界面設計，說明向用戶提供的命令以及系統(tǒng)的返回信息；要進行外部接口設計，說明本系統(tǒng)與外界的所有接口安排，包括軟件與硬件之間的接口，本系統(tǒng)與支持軟件之間的接口關系。⑤模塊設計。這是詳細設計的結果，根據(jù)模塊的功能，用詳細設計表示工具描述每個模塊的流程，描述每個模塊用到的數(shù)據(jù)結構。上一頁下一頁返回12.1軟件工程的基本概念（４）復審。軟件設計的最終目標就是要取得最佳方案?！白罴选笔侵杆泻蜻x方案中，就節(jié)省開發(fā)費用，降低資源消耗，縮短開發(fā)時間的條件，選擇能夠贏得較高的生產(chǎn)率、較高的可靠性和可維護性的方案。在整個設計的過程中，各個時期的設計結果需要經(jīng)過一系列的設計質(zhì)量的復審，以便及時發(fā)現(xiàn)和及時解決在軟件設計中出現(xiàn)的問題，防止把問題帶到開打的后續(xù)階段，造成后患。在復審以后，必須針對評審中發(fā)現(xiàn)的問題，對設計的結果進行必要的修改。復審方法有兩種：一種是非正式的遍查，由一個通曉全部設計的高級技術人員實施，復查者與設計者一起開會來復查所有技術文檔；另一種是正式的結構化審查，要組織一個審查小組，事先查看設計文檔，由設計者介紹情況，然后進行評價，使用正式的審查表，正式的錯誤報告。上一頁下一頁返回12.1軟件工程的基本概念５．編碼階段軟件開發(fā)的最終目標，是產(chǎn)生能在計算機上執(zhí)行的程序。分析階段和設計階段產(chǎn)生的文檔，都不能在計算機上執(zhí)行，只有到了編程階段，才產(chǎn)生可執(zhí)行的代碼，把軟件的需求真正付諸實踐。所以編程階段也稱為實現(xiàn)階段。編程的任務是為每個模塊編寫程序，也就是將模塊的邏輯描述轉換成某種程序設計語言編寫的程序。編程階段應交付的文檔就是程序。對于程序編碼需要注意以下幾個原則：（１）采用結構換程序設計的原則，就是使用語言中的順序、選擇、重復等有限的基本控制結構表示程序邏輯，嚴格限制ｇｏｔｏ語句的使用。上一頁下一頁返回12.1軟件工程的基本概念（２）程序設計采用自頂向下，逐步求精的思想，把一個模塊的功能逐步分解，細化為一系列具體的步驟，進而翻譯成一系列用某種程序設計語言寫成的程序。（３）注意數(shù)據(jù)結構的合理化，即數(shù)據(jù)結構訪問的規(guī)范化和標準化問題。（４）使用規(guī)范的程序設計風格，提高程序的條理性和可閱讀性，以方便軟件開發(fā)及維護。（５）設計高效率的程序。程序效率是指程序的執(zhí)行速度及程序占用的存儲空間。源程序的效率與詳細設計階段確定的算法的效率直接有關，因而要提高算法的效率，應選擇可生成較短目標代碼且存儲壓縮性能優(yōu)良的編譯器。上一頁下一頁返回12.1軟件工程的基本概念６．測試階段軟件測試是在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼的最終復審，是軟件質(zhì)量保證的關鍵步驟?？梢赃@么定義軟件測試：它是根據(jù)軟件開發(fā)各階段的規(guī)格說明書和程序的內(nèi)部結構而精心設計一批測試用例（即輸入數(shù)據(jù)及其預期的輸出結果），并利用這些測試用例去運行程序，以發(fā)現(xiàn)程序錯誤的過程。軟件測試分為以下幾個階段：測試階段分為以下幾個步驟：（１）模塊測試。又稱單元測試，檢查每個模塊是否有錯誤，主要發(fā)現(xiàn)編程和詳細設計階段的錯誤；（２）組裝測試。又稱綜合測試，檢查模塊之間的接口的正確性，主要用于發(fā)現(xiàn)總體設計階段的錯誤；上一頁下一頁返回12.1軟件工程的基本概念（３）確認測試。檢查程序系統(tǒng)是否滿足用戶的功能性能要求，主要用于發(fā)現(xiàn)需求分析階段的錯誤。７．維護階段軟件交付使用以后便進入正常運行階段，也是軟件生存周期中的最后一個段，即維護階段。目前還沒有一種能夠確認軟件中不存在錯誤的技術，在這個階段不可避免會出現(xiàn)錯誤，加上用戶需求的不斷改變，對軟件要不斷改進，這些工作只有通過對軟件的維護來解決。之所以需要進行軟件維護，主要是原因有：運行中發(fā)現(xiàn)了軟件中的錯誤需要修正；為了適應變化了的軟件工作環(huán)境，需要做適當?shù)淖兏?；為了增強軟件的功能需做變更。上一頁下一頁返?2.1軟件工程的基本概念12.1.5軟件工具與軟件開發(fā)環(huán)境軟件工具是一種軟件，為提高軟件生產(chǎn)率和改進軟件的質(zhì)量，輔助和支持其他軟件開發(fā)、維護、模擬、移植或管理而研制的程序系統(tǒng)。軟件開發(fā)環(huán)境是一組相關的軟件工具的集合，將它們組織在一起，為特定的領域所使用，以支持整個軟件生命周期的計算機輔助開發(fā)程序系統(tǒng)。上一頁返回12.2結構化分析方法12.2.1結構化分析概述結構化分析（ＳｔｒｕｃｔｕｒｅｄＡｎａｌｙｓｉｓ，ＳＡ）是面向數(shù)據(jù)流進行需求分析的方法。２０世紀７０年代末由ＹｏｕｒｄｏｎＥ．，ＣｏｎｓｔａｎｔｉｎｅＬ．，ＤｅＭａｒｃｏＴ．等人提出發(fā)展，至今仍得到廣泛地應用。ＳＡ是一種建?；顒?，該方法使用簡單易讀符號，根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞和變換的關系，以數(shù)據(jù)流圖和數(shù)據(jù)字典為主要工具，自頂向下逐步分解，建立系統(tǒng)的邏輯模型。下一頁返回12.2結構化分析方法結構化分析方法適合于數(shù)據(jù)處理類型軟件的需求分析。當面對一個復雜的問題時，分析人員不可能一開始就考慮到問題的所有方面和全部細節(jié)，采用的策略往往是分解，把一個復雜的問題劃分成若干小問題，然后分別解決，將問題的復雜性降低到人們可以掌握的程度。此外，在解決復雜問題時，還可以先暫時忽略細節(jié)，只考慮問題的本質(zhì)，然后細化到最詳細的內(nèi)容，這就是“抽象”。結構化分析方法的基本思想正是運用了“分解”和“抽象”這兩個基本手段，采用“自頂向下，逐步分解”的分析思路。根據(jù)ＤｅＭａｒｃｏ的論述，結構化分析方法使用以下幾個工具：上一頁下一頁返回12.2結構化分析方法（１）數(shù)據(jù)流圖（ＤａｔａＦｌｏｗＤｉａｇｒａｍ，ＤＦＤ）。一種最常用的結構化分析工具，描述系統(tǒng)由哪幾部分組成，各部分之間有什么聯(lián)系等。（２）數(shù)據(jù)字典（ＤａｔａＤｉｃｔｉｏｎａｒｙ，ＤＤ）。定義了數(shù)據(jù)流圖中每一個圖形元素，使得用戶和系統(tǒng)分析員對于輸入、輸出、存儲成分和中間結果有共同的理解。（３）判定樹（ＤｅｔｅｒｍｉｎａｔｉｏｎＴｒｅｅ）。從問題定義的文字描述中分清哪些是判定的條件，哪些是判定的結論，根據(jù)描述材料中的連接詞找出判定條件之間的從屬關系、并列關系、選擇關系，根據(jù)它們構造判定樹。上一頁下一頁返回12.2結構化分析方法（４）判定表（ＤｅｔｅｒｍｉｎａｔｉｏｎＴａｂｌｅ）。與判定樹類似，當數(shù)據(jù)流圖中的加工要依賴多個邏輯條件的取值時，即完成該加工的一組動作是由于某一組條件取值的組合而引發(fā)的，使用判定表描述比較合適。使用ＳＡ方法進行軟件需求分析時，可按如下步驟進行：（１）建立當前系統(tǒng)的物理模型。即理解當前的現(xiàn)實環(huán)境，獲得當前系統(tǒng)的物理模型。當前系統(tǒng)的物理模型就是現(xiàn)實環(huán)境的真實寫照，在理解了當前系統(tǒng)是怎樣做的情況下，用數(shù)據(jù)流圖等形式將現(xiàn)實環(huán)境表達出來。（２）建立當前系統(tǒng)的邏輯模型。通過對物理模型的分析，找到本質(zhì)性的因素，抽象出當前系統(tǒng)的功能和性能，建立當前系統(tǒng)的邏輯模型。上一頁下一頁返回12.2結構化分析方法（３）建立目標系統(tǒng)的邏輯模型。首先要清楚所建立的目標系統(tǒng)的功能，進一步分析與當前系統(tǒng)邏輯模型的差別，將當前系統(tǒng)的數(shù)據(jù)流圖分成兩部分，一部分是與目標系統(tǒng)相同的部分，另一部分是與目標系統(tǒng)不同的即變化的部分。將變化的部分重新分析和設計，建立一個目標系統(tǒng)的邏輯模型。（４）為目標系統(tǒng)的邏輯模型作補充。為了對一個軟件系統(tǒng)做出完整的說明，需對已得到的結果作一些補充。如說明目標系統(tǒng)的人機邊界，即確定系統(tǒng)的范圍。還要說明系統(tǒng)邏輯模型中未詳細考慮的一些細節(jié)問題，如出錯處理，系統(tǒng)如何啟動和結束，系統(tǒng)輸入輸出格式，系統(tǒng)性能方面的其他要求（如響應時間、存儲容量）等。上一頁下一頁返回12.2結構化分析方法12.2.2數(shù)據(jù)流圖數(shù)據(jù)流圖（ＤａｔａＦｌｏｗＤｉａｇｒａｍ，ＤＦＤ）也稱為ＢｕｂｂｌｅＣｈａｒｔ或ＤａｔａＦｌｏｗＧｒａｐｈ，它用來描繪系統(tǒng)的邏輯模型，從數(shù)據(jù)傳遞和加工的角度，以圖形的方式描繪數(shù)據(jù)在系統(tǒng)中流動和處理的過程，反映系統(tǒng)必須完成的邏輯功能。由于數(shù)據(jù)流圖是系統(tǒng)邏輯的圖形表示，即使不是專業(yè)的計算機技術人員也容易理解，所以是極好的交流信息的工具。此外，數(shù)據(jù)流圖只考慮系統(tǒng)必須完成的邏輯功能，完全不考慮如何具體實現(xiàn)，所以它也是很好的軟件設計的出發(fā)點。上一頁下一頁返回12.2結構化分析方法１．數(shù)據(jù)流圖的基本圖形符號首先，請看如圖１２-３所示的學生管理系統(tǒng)的數(shù)據(jù)流圖。學生通過提交登記表，經(jīng)過建檔處理，生成學生信息保存到學生檔案文件中；學生科可以通過修改處理來修改學生的信息，也可以提出統(tǒng)計要求經(jīng)過統(tǒng)計處理生成報表；各系處可以提出查詢條件給查詢處理，而得到所需的學生信息。從圖１２-３中，我們可以看出數(shù)據(jù)流圖的基本圖形符號有４種，如圖１２-４所示上一頁下一頁返回12.2結構化分析方法（１）數(shù)據(jù)流。數(shù)據(jù)流是沿箭頭方向傳送數(shù)據(jù)的通道，是一組確定的數(shù)據(jù)在系統(tǒng)內(nèi)傳播的路徑。數(shù)據(jù)流的流向由箭頭方向指出，可從加工流向加工，也可以從加工流向數(shù)據(jù)存儲或從數(shù)據(jù)存儲流向加工，還可以從源點流向加工或從加工流向終點。如圖１２-３所示，從源點“學生”到加工“建檔”之間就有數(shù)據(jù)流“登記表”。在數(shù)據(jù)流圖中，除了與數(shù)據(jù)存儲之間的數(shù)據(jù)流不用命名之外，數(shù)據(jù)流應該對應一個唯一的名字。多個數(shù)據(jù)流可以指向同一個加工，也可以從一個加工散發(fā)出許多數(shù)據(jù)流。上一頁下一頁返回12.2結構化分析方法

（２）加工。加工又稱為數(shù)據(jù)處理，對數(shù)據(jù)流進行某些操作或變換，它把輸入的數(shù)據(jù)變成輸出的數(shù)據(jù)流。每個加工要有名字，通常是動詞短語，簡明地描述完成什么加工。在分層的數(shù)據(jù)流圖中，加工還應編號。（３）數(shù)據(jù)存儲。數(shù)據(jù)存儲又稱文件，是存儲數(shù)據(jù)的工具，它是數(shù)據(jù)流在加工過程中產(chǎn)生的臨時文件或加工過程中需要查找的信息，它可以使數(shù)據(jù)庫文件或任何形式的數(shù)據(jù)組織。指向文件的數(shù)據(jù)流可以看成是寫入文件或查詢文件，從文件中引出的數(shù)據(jù)流可以理解為從文件讀取數(shù)據(jù)或得到查詢結果。數(shù)據(jù)流反映了系統(tǒng)中流動的數(shù)據(jù)，表現(xiàn)出動態(tài)數(shù)據(jù)的特征；數(shù)據(jù)存儲反映了系統(tǒng)中靜態(tài)的數(shù)據(jù)，表現(xiàn)出靜態(tài)數(shù)據(jù)的特征上一頁下一頁返回12.2結構化分析方法

（４）數(shù)據(jù)源點和終點。數(shù)據(jù)源點和終點是系統(tǒng)外部環(huán)境中的實體（包括人員、組織或其他軟件），統(tǒng)稱為外部實體，表示系統(tǒng)中數(shù)據(jù)的來源或歸宿。它在數(shù)據(jù)流圖中僅僅是一個符號，并不需要以軟件的形式進行設計和實現(xiàn)。在圖１２-３中，學生是一個數(shù)據(jù)源點、學生科和各系處既是數(shù)據(jù)源點，也是數(shù)據(jù)終點。２．數(shù)據(jù)流與加工之間的關系在數(shù)據(jù)流圖中，如果有兩個以上數(shù)據(jù)流指向一個加工，或者是從一個加工中引出兩個以上的數(shù)據(jù)流，這些數(shù)據(jù)流之間往往存在一定關系。使用如圖１２-５所示的符號來表示。其中“”表示相鄰的一對數(shù)據(jù)流同時出現(xiàn)；“”表示相鄰的兩個數(shù)據(jù)流只取其一。上一頁下一頁返回12.2結構化分析方法３．分層的數(shù)據(jù)流圖對于復雜的實際問題，采用一個數(shù)據(jù)流圖是不夠的，需要按照實際問題的層次結構進行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結構關系。在多層數(shù)據(jù)流圖中，先把整個數(shù)據(jù)處理看成是一個加工，稱為頂層流圖，然后將其進行細化，得到若干中間層流圖，最后得到無法在劃分的底層流圖。層次上處于上面的稱為父圖，由父圖推導出來的圖稱為子圖。頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)，它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)的輸出數(shù)據(jù)。頂層流圖的作用在于表明被開發(fā)系統(tǒng)的范圍，以及它和周圍環(huán)境的數(shù)據(jù)交換條件。底層流圖是指其加工不須再做分解的數(shù)據(jù)流圖，其加工稱為“原子加工”。上一頁下一頁返回12.2結構化分析方法中間層流圖則表示對其上層父圖的細化，它的每一加工可以繼續(xù)細化，形成子圖。中間層次的多少視系統(tǒng)的復雜程度而定。４．數(shù)據(jù)流圖的畫法畫數(shù)據(jù)流圖的基本步驟概括地說，就是自外向內(nèi)，自頂向下，逐層細化，求善求精。需要先對給定的問題進行分析，確定系統(tǒng)的邊界或范圍；然后考慮系統(tǒng)內(nèi)部，鮮花加工的輸入和輸出，再畫加工的內(nèi)部，具體步驟如下。（１）識別系統(tǒng)的輸入和輸出，畫出基本系統(tǒng)模型基本系統(tǒng)模型也成為頂層圖，它只包含一個加工，用以表示被開發(fā)的系統(tǒng)。在系統(tǒng)分析初期，系統(tǒng)的功能需求等還不很明確，為了防止遺漏，不妨先將范圍定得大一些。上一頁下一頁返回12.2結構化分析方法系統(tǒng)邊界確定后，越過邊界的數(shù)據(jù)流就是系統(tǒng)的輸入或輸出，將輸入與輸出用加工符號連接起來，并加上輸入數(shù)據(jù)來源和輸出數(shù)據(jù)去向就形成了頂層圖。頂層圖的作用在于標明被開發(fā)系統(tǒng)的范圍及其周圍環(huán)境的數(shù)據(jù)交換關系。（２）把頂層圖細化為系統(tǒng)的功能級數(shù)據(jù)模型不再分解的加工稱為基本加工。一般將層號從０開始編號，采用自頂向下的原則，描繪系統(tǒng)的主要功能。畫０層數(shù)據(jù)流圖時，分解頂層的系統(tǒng)為若干子系統(tǒng)（加工），決定每個子系統(tǒng)間的數(shù)據(jù)接口和活動關系。（３）對功能級數(shù)據(jù)流圖中描繪的主要功能進一步細化上一頁下一頁返回12.2結構化分析方法同樣運用“由外向里”方式對每個加工進行分析，如果在該加工內(nèi)部還有數(shù)據(jù)流，則可將該加工分成若干個子加工，并用一些數(shù)據(jù)流把子加工連接起來，即可畫出二級細化圖。二級細化圖可在一級細化圖的基礎上畫出，也可單獨畫出該加工的二級細化圖，二級細化圖也稱為該加工的子圖。（４）在畫出了每個層次的子圖后，應當進行檢查和修改，主要應當注意以下幾個方面。①數(shù)據(jù)流圖上所有圖形符號只限于前述的四種基本圖形元素，缺一不可。②命名。圖上每一個元素都必須有名字，使用能夠反映功能特點的名字來命名。上一頁下一頁返回12.2結構化分析方法③畫數(shù)據(jù)流而不是控制流。數(shù)據(jù)流反映系統(tǒng)“做什么”，不反映“如何做”，因此箭頭上的數(shù)據(jù)流名稱只能是名詞或名詞短語，整個圖中不反映加工的執(zhí)行順序。④每個加工至少有一個輸入數(shù)據(jù)流和一個輸出數(shù)據(jù)流，反映出此加工數(shù)據(jù)的來源與加工的結果。⑤編號。如果一張數(shù)據(jù)流圖中的某個加工分解成另一個數(shù)據(jù)流圖時，則上層圖為父圖，直接下層圖為子圖。子圖及其所有的加工都應編號，如圖１２-６所示。上一頁下一頁返回12.2結構化分析方法⑥父圖與子圖的平衡。子圖的輸入／輸出數(shù)據(jù)流與父圖相應加工的輸入／輸出數(shù)據(jù)流必須一致，即父圖與子圖的平衡。⑦局部數(shù)據(jù)存儲。當某層數(shù)據(jù)流圖中的數(shù)據(jù)存儲不是父圖中相應加工的外部接口，而只是本圖中某些加工之間的數(shù)據(jù)接口時，稱這些數(shù)據(jù)存儲為局部數(shù)據(jù)存儲。⑧提高數(shù)據(jù)流圖的易懂性。注意合理分解，要把一個加工分解成幾個功能相對獨立的子加工，這樣可以減少加工之間的輸入、輸出數(shù)據(jù)流的數(shù)據(jù)，增加數(shù)據(jù)流圖的可理解性。上一頁下一頁返回12.2結構化分析方法12.2.3數(shù)據(jù)字典數(shù)據(jù)字典的任務是對于數(shù)據(jù)流圖中出現(xiàn)的所有被命名的圖形元素在數(shù)據(jù)字典中作為一個詞條加以定義，使得每一個圖形元素的名字都有一個確切的解釋。數(shù)據(jù)字典是關于數(shù)據(jù)信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素定義的集合，是數(shù)據(jù)流圖的補充工具。數(shù)據(jù)流圖與數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型，是需求規(guī)格說明書的主要組成部分。在數(shù)據(jù)字典的定義中，可以使用下面的符號，其中Ａ、Ｂ、Ｃ都是數(shù)據(jù)元素。上一頁下一頁返回12.2結構化分析方法Ａ＝Ｂ＋ＣＡ由Ｂ和Ｃ構成Ａ＝［Ｂ｜Ｃ］Ａ由Ｂ或Ｃ構成Ａ＝（Ｂ）Ｂ在Ａ中可以出現(xiàn)，也可以不出現(xiàn)Ａ＝｛Ｂ｝Ａ有０個或多個重復的Ｂ構成數(shù)據(jù)字典中的所有定義應是嚴密的、精確的，不可有半點模糊，不能有二義性。在數(shù)據(jù)字典中，通常有四類條目，即數(shù)據(jù)流、數(shù)據(jù)元素、數(shù)據(jù)存儲、加工邏輯和源點及終點。（１）數(shù)據(jù)流。數(shù)據(jù)流條目給出了ＤＦＤ中數(shù)據(jù)流的定義，通常列出該數(shù)據(jù)流的各組成數(shù)據(jù)項。數(shù)據(jù)流條目包含的主要內(nèi)容有數(shù)據(jù)流名、數(shù)據(jù)流別名、說明、數(shù)據(jù)流來源、數(shù)據(jù)流趨向、數(shù)據(jù)流組成、數(shù)據(jù)流流通量等。上一頁下一頁返回12.2結構化分析方法（２）數(shù)據(jù)元素。數(shù)據(jù)元素是不可再分割的數(shù)據(jù)單元，它直接反映事物的某一特征。對于這些數(shù)據(jù)元素必須在數(shù)據(jù)字典中進行描述。數(shù)據(jù)元素條目主要包括數(shù)據(jù)元素名、類型、長度、取值范圍和相關的數(shù)據(jù)元素及數(shù)據(jù)結構。（３）數(shù)據(jù)存儲。數(shù)據(jù)存儲是數(shù)據(jù)結構保存的地方。數(shù)據(jù)存儲條目主要包含數(shù)據(jù)存儲名、簡要描述、輸入數(shù)據(jù)、輸出數(shù)據(jù)、組成、存儲方式和存儲頻率等。上一頁下一頁返回12.2結構化分析方法（４）加工邏輯。加工邏輯條目用來說明數(shù)據(jù)流圖中基本加工的處理邏輯，由于上層的加工時由下層的基本加工組合而來的，只要有了基本加工的說明，就可以理解其他的加工了。加工邏輯條目主要包括加工名、加工編號、簡要描述、輸入數(shù)據(jù)流、輸出數(shù)據(jù)流、加工邏輯等。（５）源點及終點。對于一個數(shù)據(jù)處理系統(tǒng)來說，源點和終點應當少一些比較好。如果過多就缺乏獨立性，人機界面太復雜，這是要考慮減少一些，以提高系統(tǒng)的獨立性。源點及終點條目一般包括外部實體名、簡要描述、有關數(shù)據(jù)流、數(shù)目等。上一頁下一頁返回12.2結構化分析方法12.2.4軟件需求規(guī)格說明書軟件需求規(guī)格說明書作為產(chǎn)品需求的最終成果，必須具有綜合性，包括所有的需求。軟件需求規(guī)格說明書主要有三個作用：作為用戶和軟件開發(fā)人員之間的合同；作為開發(fā)人員進行設計和編程的根據(jù)；作為軟件開發(fā)完成后驗收的依據(jù)。編寫軟件需求規(guī)格說明書時，應該完整、一致、精確、無二義性，同時又要簡明、易懂、易修改。它越精確，以后出現(xiàn)錯誤、混淆、反復的可能性就越小。如“系統(tǒng)查詢等待時間很短”等詞語，是含糊不清的描述，驗收時無法檢查，而“查詢等待時間不超過５秒”就是精確的描述，驗收時就可檢查是否達到這個要求。上一頁下一頁返回12.2結構化分析方法軟件需求規(guī)格說明書最終要得到用戶的認可，所以用戶要能看得懂，并且還發(fā)現(xiàn)和指出其中的錯誤。由于用戶往往不是一個人，而是企業(yè)中各個部門的若干人，他們可能提出相互沖突的要求，這就需要協(xié)調(diào)和解決這些沖突，在需求說明書中用戶要求的應該是一致的、無二義性的。軟件需求說明書的內(nèi)容和推薦書寫參考格式如下。（１）引言。包括以下部分：①編寫目的：說明編寫需求規(guī)格說明書的目的，指明讀者。②項目背景：包括項目的委托單位、開發(fā)單位和主管單位；該系統(tǒng)軟件與其他系統(tǒng)的關系。上一頁下一頁返回12.2結構化分析方法③定義：列出文檔中所用到的各種術語及縮寫的含義。④參考資料：列出項目的各種核準批文、項目開發(fā)計劃，文檔所引用的資料、標準和規(guī)范；列出資料的作者、標題、編號、發(fā)表日期、出版單位或資料來源等。（２）任務概述：主要包括目標、運行環(huán)境、條件和限制等。（３）數(shù)據(jù)描述：主要包括靜態(tài)數(shù)據(jù)、動態(tài)數(shù)據(jù)、數(shù)據(jù)庫描述、數(shù)據(jù)流圖、數(shù)據(jù)字典、系統(tǒng)接口說明和內(nèi)部接口等。上一頁下一頁返回12.2結構化分析方法（４）功能需求：主要包括功能劃分和功能描述。（５）性能需求：主要包括數(shù)據(jù)精確度、時間特性（如響應時間、更新處理時間、數(shù)據(jù)轉換與傳輸時間、運行時間等）、適應性等。（６）運行需求：主要包括用戶界面（如屏幕格式、報表格式、菜單格式、輸入輸出時間等）、硬件接口、軟件接口和故障處理。（７）其他需求：如可使用性、安全保密、可維護性和可移植性等。上一頁返回12.3結構化設計方法12.3.1軟件設計概述１．軟件設計的基礎軟件設計的基本目標是用比較抽象概括的方式確定目標系統(tǒng)如何完成預定的任務，也就是說，軟件設計是確定系統(tǒng)的物理模型。軟件設計是開發(fā)階段最重要的步驟。從工程管理的角度來看可分為兩步：（１）總體設計：將軟件需求轉化為軟件體系結構、確定系統(tǒng)及接口、全局數(shù)據(jù)結構或數(shù)據(jù)庫模式。（２）詳細設計：確立每個模塊的實現(xiàn)算法和局部數(shù)據(jù)結構，用適當方法表示算法和數(shù)據(jù)結構的細節(jié)。下一頁返回12.3結構化設計方法從技術觀點來看，軟件設計包括軟件結構設計、數(shù)據(jù)設計、接口設計、過程設計等４個步驟。（１）結構設計：定義軟件系統(tǒng)各主要部件之間的關系。（２）數(shù)據(jù)設計：將分析時創(chuàng)建的模型轉化為數(shù)據(jù)結構的定義。（３）接口設計：描述軟件內(nèi)部、軟件和協(xié)作系統(tǒng)之間以及軟件與人之間如何通信。（４）過程設計：把系統(tǒng)結構部件轉換成軟件的過程描述。２．軟件設計的基本原理和原則軟件設計過程中應該遵循的基本原理和原則如下：上一頁下一頁返回12.3結構化設計方法（１）模塊化。模塊化就是把軟件劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求。模塊化是為了把復雜的問題自頂向下逐層分解成許多容易解決的問題，原來的問題也就容易解決了。模塊化是程序結構清晰，容易閱讀、理解、測試和調(diào)試。模塊的劃分需要合理，避免劃分地過多或過少。（２）抽象。抽象是人類在認識復雜現(xiàn)象的過程中使用的最強有力的思維工具。抽象就是抽出事物的本質(zhì)特征，將相似的方面集中和概括起來，而暫時不考慮它們的細節(jié)，暫時忽略它們之間的差異。在軟件設計時，可以有不同層次的抽象。上一頁下一頁返回12.3結構化設計方法在最高的抽象層次上，可以使用問題所處環(huán)境的語言概括地描述問題的解法。而在較低的抽象層次上，則采用過程化的方法，使用能夠直接實現(xiàn)的方式來描述算法。（３）信息隱藏。應用模塊化原理時，自然會產(chǎn)生的一個問題是“為了得到最好的一組模塊，應該怎樣分解軟件呢？”。信息隱藏原理指出：設計和確定模塊時，應使得一個模塊內(nèi)包含的信息（過程和數(shù)據(jù)）對于不需要這些信息的模塊來說，是不能訪問的。通過抽象，可以確定組成軟件的過程或信息實體，而通過信息隱藏，則可定義或實施對模塊的過程細節(jié)和局部數(shù)據(jù)的存取限制。（４）模塊獨立性。模塊獨立性是指每個模塊完成一個相對獨立的特定子功能，并且和其他模塊之間的關系很簡單。上一頁下一頁返回12.3結構化設計方法模塊獨立性的高低是設計好壞的關鍵，而設計又是決定軟件質(zhì)量的關鍵環(huán)節(jié)。模塊的獨立程度額可以有兩個定性標準衡量，即內(nèi)聚性和耦合性。內(nèi)聚性指對模塊功能強度的度量。若一個模塊內(nèi)各元素（語句之間、程序段之間）聯(lián)系越緊密，則它的內(nèi)聚性就越高。圖１２-７給出了內(nèi)聚的分類及它們之間內(nèi)聚程度的排列順序。內(nèi)聚性指對模塊功能強度的度量。若一個模塊內(nèi)各元素（語句之間、程序段之間）聯(lián)系越緊密，則它的內(nèi)聚性就越高。圖１２-７給出了內(nèi)聚的分類及它們之間內(nèi)聚程度的排列順序。上一頁下一頁返回12.3結構化設計方法耦合性指對軟件系統(tǒng)結構中的各模塊間相互聯(lián)系緊密程度的一種度量。模塊之間聯(lián)系越緊密，其耦合性就越強，模塊的獨立性則越差。圖１２-８給出了耦合的分類以及它們之間耦合性強弱的順序。一般來說，要求模塊之間的耦合盡可能弱，即模塊盡可能獨立，且要求模塊的內(nèi)聚程度盡可能高。內(nèi)聚性和耦合性是一個問題的兩個方面，耦合性程度弱的模塊，其內(nèi)聚程度一定高。因而，劃分模塊的時候，盡量做到高內(nèi)聚低耦合，提高模塊的獨立性。上一頁下一頁返回12.3結構化設計方法12.3.2總體設計１．總體設計基本任務總體設計也稱概要設計，它指把需求分析階段所得到的系統(tǒng)功能的層次結構組合起來成為一個系統(tǒng)。具體來說，總體設計階段的基本任務如下。（１）設計軟件系統(tǒng)結構。通常把總體設計分成兩個主要的階段，即系統(tǒng)設計和結構設計。其中系統(tǒng)設計用于確定系統(tǒng)的具體實現(xiàn)方案；結構設計用于確定軟件結構，也就是確定系統(tǒng)中每個程序是由哪些模塊組成的，以及這些模塊之間的關系，其設計過程如圖１２-９所示。上一頁下一頁返回12.3結構化設計方法（２）數(shù)據(jù)結構及數(shù)據(jù)庫設計。數(shù)據(jù)設計師實現(xiàn)需求定義和規(guī)格說明中提出的數(shù)據(jù)對象的邏輯表示。（３）編寫總體設計文檔。總體設計階段的文檔有總體設計說明書、數(shù)據(jù)庫設計說明書和集成測試計劃等。（４）總體設計評審。在文檔編寫完成后，要對設計部分是否完整地實現(xiàn)了需求中規(guī)定的功能、性能等要求，設計方案的可行性，關鍵的處理以及內(nèi)外部接口定義正確性、有效性，各部分之間的一致性等進行評審，以免在以后的設計中出現(xiàn)大的問題而返工。２．總體設計的圖形工具—結構圖上一頁下一頁返回12.3結構化設計方法在結構化設計方法中，常用結構圖（ＳｔｒｕｃｔｕｒｅＣｈａｒｔ，ＳＣ），也稱為程序結構圖，它是由Ｙｏｒｄｏｎ提出的進行軟件結構設計的圖形工具。其基本圖形符號及含義，見表１２-１。根據(jù)結構化設計思想，結構圖構成的基本形式有三種，即順序結構、選擇結和循環(huán)結構，如圖１２-１０所示。圖１２-１０（ａ）是最基本的調(diào)用形式，順序結構。此外還有一些附加的符號，可以表示模塊的選擇調(diào)用或循環(huán)調(diào)用。圖１２-１０（ｂ）表示當模塊Ｍ中某個判定為真時調(diào)用模塊Ａ，為假時調(diào)用模塊Ｂ。圖１２-１０（ｃ）表示模塊Ｍ循環(huán)調(diào)用模塊Ａ。上一頁下一頁返回12.3結構化設計方法結構圖有４種模塊類型，即傳入模塊、傳出模塊、變換模塊以及協(xié)調(diào)模塊。如圖１２-１１所示。傳入模塊：從下級模塊取得數(shù)據(jù)，經(jīng)處理再將其傳送給上級模塊。傳出模塊：從上級模塊取得數(shù)據(jù)，經(jīng)處理再將其傳送給下屬模塊。變換模塊：從上級模塊取得數(shù)據(jù)，進行特定的處理，轉換成其他形式，再傳送給上級模塊。協(xié)調(diào)模塊：對所有下屬模塊進行協(xié)調(diào)和管理。３．總體設計的方法上一頁下一頁返回12.3結構化設計方法總體設計采用結構化設計方法（ＳＤ），它是從整個程序結構出發(fā)，突出程序模塊的一種設計方法。它對確定結構采用了面向貫穿系統(tǒng)的數(shù)據(jù)流的方法，因此也稱為“面向數(shù)據(jù)流的設計”。該方法由美國ＩＢＭ公司Ｌ．Ｃｏｎｓｔａｎｔｉｎｅ和Ｅ．Ｙｏｒｄｏｎ等人于１９７４年提出，與結構化分析（ＳＡ）銜接，構成完整的結構化分析與設計技術，是目前使用最廣泛的軟件設計方法之一。（１）數(shù)據(jù)流圖的類型。面向數(shù)據(jù)流的設計方法把數(shù)據(jù)流圖映射成軟件結構，要把數(shù)據(jù)流圖（ＤＦＤ）映射為軟件結構，首先必須研究ＤＦＤ的類型。對于各種軟件系統(tǒng)，不論ＤＦＤ如何龐大和復雜，一般都可分為變換型和事務型。上一頁下一頁返回12.3結構化設計方法①變換型數(shù)據(jù)流圖。變換型數(shù)據(jù)流圖由輸入流、變換流和輸出流組成。在輸入流中，信息由外部數(shù)據(jù)轉換為內(nèi)部形式進入系統(tǒng)；在變換流中，對內(nèi)部形式的信息進行一系列加工處理，得到內(nèi)部形式的結果；在輸出流中，信息由內(nèi)部形式的結果轉換為外部形式的數(shù)據(jù)流出系統(tǒng)，如圖１２-１２所示。②事務型數(shù)據(jù)流圖。事務型數(shù)據(jù)流是一個數(shù)據(jù)流經(jīng)過某個加工后，有若干平行數(shù)據(jù)流流出，此輸入數(shù)據(jù)流稱為事務流，此加工稱為事務中心，若干平行數(shù)據(jù)流稱為事務路徑。當事務流中的事務送到事務中心后，事務中心分析每一事物，確定其類型，根據(jù)事物類型選擇一個事物路徑繼續(xù)進行處理，如圖１２-１３所示。上一頁下一頁返回12.3結構化設計方法（２）面向數(shù)據(jù)流的結構化設計過程①首先研究、分析和審查數(shù)據(jù)流圖。從軟件的需求規(guī)格說明書中弄清數(shù)據(jù)流加工的過程。②然后根據(jù)數(shù)據(jù)流圖決定問題的類型。數(shù)據(jù)處理問題典型的類型有兩種：變換型和事務型。針對兩種不同的類型分別進行分析處理。③由數(shù)據(jù)流圖推導出系統(tǒng)的初始結構圖。④利用一些試探性原則來改進系統(tǒng)的初始結構圖，知道得到符合要求的結構圖為止。⑤修改和補充數(shù)據(jù)字典。⑥制定測試計劃。上一頁下一頁返回12.3結構化設計方法（３）結構化設計的準則。大量實踐表明，以下的設計準則可以借鑒為設計的指導和對軟件結構圖進行優(yōu)化的條件。①提高模塊獨立性。模塊獨立性是結構設計好壞的最重要指標。設計出軟件的初步結構以后，應該分析這個結構，通過模塊分解或合并，力求降低耦合提高內(nèi)聚。②模塊規(guī)模應該適中。過大的模塊往往是由于分解不充分；模塊過小，則開銷大于有效操作，而且模塊數(shù)目過多將使系統(tǒng)接口復雜。③深度、寬度、扇出和扇入都應適當。深度表示軟件結構中控制的層數(shù)，寬度值最大模塊的層的控制跨度，扇入指調(diào)用一個給定模塊的模塊個數(shù)，扇出指由一個模塊直接調(diào)用的其他模塊數(shù)。上一頁下一頁返回12.3結構化設計方法④模塊的作用域應該在控制域之內(nèi)。在一個設計得很好的系統(tǒng)中，所有受判斷影響的模塊應該都從屬于做出判定的那個模塊，最好局限于做出判斷的那個模塊本身及它的直屬下級模塊。⑤降低模塊之間接口的復雜程度。應當仔細設計模塊接口，使得信息傳遞簡單并且與模塊的功能相適應。⑥設計單入口單出口的模塊，不要使模塊之間出現(xiàn)內(nèi)容耦合。⑦模塊功能應該可以預測。如果一個模塊可以當作一個黑盒，即只要輸入數(shù)據(jù)同時就產(chǎn)生同樣的輸出，這個模塊的功能就是可以預測的。上一頁下一頁返回12.3結構化設計方法12.3.3詳細設計詳細設計的根本任務是確定每個模塊的內(nèi)部特征，即確定每個模塊內(nèi)部的執(zhí)行過程。也就是說，經(jīng)過這個階段的工作，應該得出對系統(tǒng)目標的精確描述，從而在編程階段可以把這個描述直接翻譯成某種高級程序設計語言書寫的程序。在總體設計中，不但建立了軟件結構，還為每個模塊確定了它應完成的功能，定義了模塊與其他模塊的外部接口，設計了關鍵性的算法。詳細設計以總體設計的設計說明書為依據(jù)，針對每個模塊進行設計，確定每個模塊的內(nèi)部特征，即每個模塊內(nèi)部的執(zhí)行過程。通過這樣的設計過程，就為編程制定了一個周密的計劃，然后就可以直接過渡到編程階段。詳細設計階段的產(chǎn)品就是詳細設計說明書，它是編程階段的依據(jù)。上一頁下一頁返回12.3結構化設計方法理論研究和大量實踐表明，采用自頂向下、逐步求精的策略和單入口、單出口的控制結構設計程序是完全可行的，而且有一系列重要優(yōu)點。因此，結構化程序設計是實現(xiàn)上述目的的基本保證，是進行詳細設計的邏輯結構。結構化程序設計（ＳｔｒｕｃｔｕｒｅｄＰｒｏｇｒａｍｍｉｎｇ，ＳＰ）的概念最早由Ｅ．Ｗ．Ｄｉｊｋｓｔｒａ提出。１９６６年，Ｂｏｈｍ和Ｊａｃｏｐｉｎ證明了只用“順序”“選擇”“循環(huán)”三種基本控制結構就能實現(xiàn)任何單入口、單出口的程序。１．結構化程序設計方法的基本要點上一頁下一頁返回12.3結構化設計方法（１）采用自頂向下、逐步求精的程序設計方法。在需求分析、總體設計中，都采用了自頂向下、逐步求精的方法。求精過程只適用順序、選擇、循環(huán)三種控制結構，其他的控制結構均可由這三種結構組合而得到，它們的流程圖如圖１２-１４所示。２．詳細設計的常用工具（１）程序流程圖（ＰＦＤ）。程序流程圖又稱為程序框圖，是使用得最廣泛然而也是使用最混亂的一種描述程序邏輯結構的工具。使用結構化流程圖具有結構清晰，易于理解和修改的優(yōu)點，也存在只能描述執(zhí)行過程而不能描述有關的數(shù)據(jù)的缺點。對于流程圖的介紹，在本書的前一章已有詳細的介紹。上一頁下一頁返回12.3結構化設計方法（２）盒圖（ＮＳ）。盒圖（ＮＳ圖）是一種強制使用結構化構造的圖示工具，也稱為方框圖。圖１２-１５給出了盒圖的基本圖符。盒圖具有如下特點：①功能域明確；②不可能任意轉移控制；③易于確定局部和全局數(shù)據(jù)的作用域；④易于表示嵌套關系及模塊的層次關系。上一頁下一頁返回12.3結構化設計方法（３）問題分析圖（ＰＡＤ）。問題分析圖是一種改進的圖形描述方式，可以用來取代程序流程圖，比程序流程圖更直觀，結構更清晰。最大的優(yōu)點是能夠反映和描述自頂向下、逐步求精的歷史和過程。ＰＡＤ是日本日立公司于１９７９年提出的一種算法描述工具，它是一種由左向右展開的二維樹型結構。ＰＡＤ圖的控制流程為自上而下，從左到右地執(zhí)行。ＰＡＤ提供了５種基本控制結構的圖示，并允許遞歸使用，如圖１２-１６所示。圖１２-１５（ａ）中為順序結構，表示執(zhí)行Ａ，再執(zhí)行Ｂ；圖１２-１５（ｂ）中Ｐ是判定條件，Ｐ取真時執(zhí)行上面的Ａ框，取假時執(zhí)行下面的Ｂ框；圖１２-１５（ｃ）表示ＣＡＳＥ型選擇。上一頁下一頁返回12.3結構化設計方法當條件Ｐ＝１時，執(zhí)行Ａ１，當Ｐ＝２時，執(zhí)行Ａ２，當Ｐ＝３時，執(zhí)行Ａ３；圖１２-１５（ｄ）表示ＤＯＷＨＩＬＥ型循環(huán)，ｓ表示循環(huán)體；圖１２-１５（ｅ）表示ＤＯＵＮＴＩＬ循環(huán)，ｓ表示循環(huán)體。（４）過程設計語言（ＰＤＬ）。ＰＤＬ也可稱為偽碼或結構化語言，它用于描述模塊內(nèi)部的具體算法，以便開發(fā)人員之間比較精確地進行交流。語法是開放式的，其外層語法是確定的，而內(nèi)層語法則不確定。外層語法描述控制結構，它用類似于一般編程語言控制結構的關鍵暗自表示，所以是確定的。內(nèi)層語法描述具體操作，考慮到不同軟件系統(tǒng)的實際操作種類繁多，內(nèi)層語法因而不確定，它可以按系統(tǒng)的具體情況和不同的設計層次靈活選用，實際上任意英語語句都可以用來描述所需的具體操作。上一頁下一頁返回12.3結構化設計方法用它來描述詳細設計，工作量比畫圖小，又容易轉化成真正的代碼。ＰＤＬ可以作為注釋直接插在源程序中，可以使用普通的文本編輯工具或文字處理工具產(chǎn)生和管理，可以使用自動處理程序實現(xiàn)自動由ＰＤＬ生成程序代碼。ＰＤＬ不足之處在于不如圖形工具形象直觀，描述復雜的條件組合與動作之間對應關系時，不如判定表、判定樹清晰簡單。上一頁返回12.4軟件測試12.4.1軟件測試概述軟件測試就是在軟件投入運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤。軟件測試時保證軟件質(zhì)量、可靠性的關鍵步驟。它是對軟件規(guī)格說明、設計和編碼的最后復審。通常，軟件測試的工作量往往占軟件開發(fā)總工作量的４０％以上。軟件測試在軟件生存期中橫跨兩個階段：通常在編寫每一個模塊之后就對它做必要的測試（稱為單元測試）。編碼與單元測試屬于軟件生存期的同一個階段。在結束這個階段之后，對軟件系統(tǒng)還要進行各種綜合測試，這是軟件生命期中一個獨立的階段，稱為測試階段。下一頁返回12.4軟件測試１．軟件測試的目的Ｇｒｅｎｆｏｒｄ．Ｊ．Ｍｙｅｒｓ給出了軟件測試的目的。（１）軟件測試時為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程。（２）好的測試用例（ｔｅｓｔｃａｓｅ）能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤。（３）一次成功的測試是能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤。因此，測試階段的基本任務應該是根據(jù)軟件開發(fā)階段的各種文檔資料和程序的內(nèi)部結構，精心設計一組測試用例（程序運行時需要數(shù)據(jù)，為測試設計的數(shù)據(jù)稱為測試用例），利用這些用例執(zhí)行程序，找出軟件中潛在的各種錯誤和缺陷。上一頁下一頁返回12.4軟件測試由于軟件測試的目的是為了暴露軟件中的錯誤，從心理學的角度來看，由程序的編寫者進行測試是不恰當?shù)?。一次，在綜合測試階段通常由其他人員組織來完成測試工作。此外，即使經(jīng)過了最嚴格的測試，可能仍然還有沒發(fā)現(xiàn)的錯誤藏在程序中，測試只能找出程序中的錯誤，不能證明程序中沒有錯誤。２．軟件測試的原則根據(jù)軟件測試的目的，為了能設計出有效地測試方案，以及好的測試用例，軟件測試人員必須深入理解并正確運用一下軟件測試的基本原則。上一頁下一頁返回12.4軟件測試（１）所有測試都應該追溯到用戶需求；（２）在測試之前制定測試計劃，并嚴格執(zhí)行；（３）充分注意測試中的群集現(xiàn)象；（４）避免由程序的編寫者測試自己的程序；（５）妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護提供方便。上一頁下一頁返回12.4軟件測試12.4.2測試的主要方法軟件測試方法有很多種，一般可分為兩大類：動態(tài)測試方法和靜態(tài)測試方法。其中動態(tài)測試方法又根據(jù)測試用例的設計方法不同，分為黑盒測試和白盒測試兩類；靜態(tài)測試包括代碼檢查、靜態(tài)結構分析和代碼質(zhì)量度量等。１．靜態(tài)測試靜態(tài)測試是指被測試程序不能在機器上運行，也就是不執(zhí)行程序，而只是對程序文本進行檢查，通過閱讀和討論，分析和發(fā)現(xiàn)程序中的錯誤。２．動態(tài)檢查上一頁下一頁返回12.4軟件測試動態(tài)檢查的關鍵是使用設計高效、合理的測試用例。測試用例就是為測試設計的數(shù)據(jù)，由測試輸入數(shù)據(jù)和預期的輸出結果兩部分組成。測試用例的設計方法般分為兩類：黑盒測試和白盒測試。（１）黑盒測試。黑盒測試把被測試對象看成一個黑盒子，測試人員完全不考程序的內(nèi)部結構和處理過程，只在軟件的接口處進行測試，依據(jù)需求規(guī)格說明書，檢查程序是否滿足功能要求。因此，黑盒測試又稱為功能測試或數(shù)據(jù)驅動測試。通過黑盒測試主要發(fā)現(xiàn)以下錯誤：是否有不正確或遺漏了的功能；在接口上，能否正確地接受輸入數(shù)據(jù)，能否產(chǎn)生正確地輸出信息；訪問外部信息是否有錯；性能上是否滿足要求等。上一頁下一頁返回12.4軟件測試用黑盒測試發(fā)現(xiàn)程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查程序是否都能產(chǎn)生正確的輸出。（２）白盒測試。白盒測試又稱為結構測試或邏輯驅動測試，是對軟件的過程性細節(jié)做細致的檢查。該方法把測試對象看作一個打開的盒子，測試人員必須了解程序的內(nèi)部結構和處理過程，以檢查處理過程的細節(jié)為基礎，對程序中盡可能多的邏輯路徑進行測試，檢查內(nèi)部控制結構和數(shù)據(jù)結構是否有錯，實際的運行狀態(tài)與預期的狀態(tài)是否一致。上一頁下一頁返回12.4軟件測試白盒測試主要應對程序模塊進行如下檢查：對程序模塊的所有獨立的執(zhí)行路徑至少測試一次；對所有的邏輯判斷，取“真”和取“假”的兩種情況至少測試一次；在循環(huán)的邊界和運行線內(nèi)執(zhí)行循環(huán)體；測試內(nèi)部數(shù)據(jù)結構的有效性等。在測試階段是無法進行窮舉測試的，為了節(jié)省時間和資源，提高測試效率，想要通過有限的測試來發(fā)現(xiàn)盡可能多的錯誤，還需要精心設計測試用例。上一頁下一頁返回12.4軟件測試12.4.3測試用例設計１．白盒測試的測試用例設計白盒測試允許測試人員利用程序內(nèi)部的邏輯結構及有關信息來設計或選擇測試用例，對程序所有的邏輯路徑進行測試。白盒測試是在程序內(nèi)部進行，主要用于完成軟件內(nèi)部操作的驗證。白盒測試的主要技術有邏輯覆蓋測試、基本路徑測試等。（１）邏輯覆蓋測試。邏輯覆蓋測試泛指一系列以程序內(nèi)部的邏輯結構為基礎的測試用例設計技術。程序中的邏輯表示主要有判斷、分支、條件等三種表示方式。上一頁下一頁返回12.4軟件測試①語句覆蓋。語句覆蓋是指選擇足夠多的測試用例，使被測試程序中的每語句至少執(zhí)行一次。例如在圖１２-１７所示的流程圖中，有一個判斷語句，從而形成了兩個語句分支，為了使每個語句都執(zhí)行一次，可以設計一下測試用例：測試用例１：輸入（i，j）＝（５，５），則輸出（i

，j，x）＝（５，５，５）測試用例２：輸入（i

，j）＝（５，１０），則輸出（i

，j，x）＝（５，１０，１０）語句覆蓋是邏輯覆蓋中基本的覆蓋，尤其對單元測試來說。但是語句覆蓋往往沒有關注判斷中的條件有可能隱含的錯誤。上一頁下一頁返回12.4軟件測試②路徑覆蓋。路徑覆蓋是指執(zhí)行足夠的測試用例，使程序中所有可能的路徑至少執(zhí)行一次。例如在圖１２-１８所示的流程圖中，存在４條路徑：ａｃｅ，ａｂｄ，ａｂｅ，ａｃｄ。要對這四條路徑進行測試，可以設計下面的用例。測試用例１：［（Ａ＝４，Ｂ＝１，Ｘ＝３），（輸出略）］，則可測試路徑ａｃｅ測試用例２：［（Ａ＝１，Ｂ＝１，Ｘ＝１），（輸出略）］，則可測試路徑ａｂｄ測試用例３：［（Ａ＝３，Ｂ＝２，Ｘ＝１），（輸出略）］，則可測試路徑ａｂｅ上一頁下一頁返回12.4軟件測試測試用例４：［（Ａ＝２，Ｂ＝１，Ｘ＝１），（輸出略）］，則可測試路徑ａｃｄ③判定覆蓋。判定覆蓋是指使測試用例每個判斷的每個取值分支（Ｙ或Ｎ）至少經(jīng)歷一次。根據(jù)判斷覆蓋的要求，如圖１２１８所示的程序，如果其中包含條件i≥j的判斷為真值和為假值的程序執(zhí)行路徑至少經(jīng)歷一次，仍然可以用語句覆蓋中的測試用例３和測試用例４。程序每個判斷中若存在多個聯(lián)立條件，僅保證判斷的真假值往往會導致某些單個條件的錯誤不能被發(fā)現(xiàn)。例如，某判斷“x＜１或狔＞５”，其中只要一個條件取值為真，無論另外一個條件是否錯誤，判斷的結果都為真。這說明，僅有判斷覆蓋還無法保證能查出判斷條件的錯誤，需要更強的邏輯覆蓋。上一頁下一頁返回12.4軟件測試④條件覆蓋。條件覆蓋是指設計用例保證程序中每個判斷的每個條件的可取值至少執(zhí)行一次。例如圖１２-１９所示的程序，可以設計以下測試用例來進行條件覆蓋測試。測試用例１：輸入（i，j）＝（５，４），則輸出（i，j，x）＝（５，４，５）測試用例２：輸入（i，j）＝（６，９），則輸出（i，j，x）＝（６，９，９）按照條件測試的測試要求，圖１２-１８所示程序判斷框中的條件i≥j和條件j＜５，通過上面的測試用例，就能保證該條件取真值和假值的情況至少執(zhí)行一次。上一頁下一頁返回12.4軟件測試條件覆蓋深入到判斷中的每個條件，但是可能忽略全面的判斷覆蓋的要求。有必要考慮判斷—條件覆蓋。⑤判斷—條件覆蓋。判斷—條件覆蓋是指設計足夠的測試用例，使判斷中每個條件所有可能取值至少執(zhí)行一次，同時每個判斷的所有可能取值分支至少執(zhí)行一次。對圖１２-２０所示的程序設計以下測試用例進行判斷—條件覆蓋。測試用例１：輸入（i，j，x）＝（４，３，１），則輸出（i，j，x）＝（４，３，１）上一頁下一頁返回12.4軟件測試測試用例２：輸入（i，j，x）＝（９，５，０），則輸出（i，j，x）＝（９，５，９）測試用例３：輸入（i，j，x）＝（３，９，０），則輸出（i，j，x）＝（３，９，９）按照判斷—條件覆蓋的要求，該程序的兩個判斷框的每個取值分支至少經(jīng)歷次，同時兩個判斷框中的３個條件的所有可能取值至少執(zhí)行了一次。（２）基本路徑測試?；韭窂綔y試的思想和步驟是：根據(jù)軟件過程性描述中的控制流程確定程序的環(huán)路復雜性度量，用此度量定義基本路徑集合，并由此導出一組測試用例對每一條獨立執(zhí)行路徑進行測試。如圖-２１所示的程序，確定環(huán)路復雜度的方法是：環(huán)路復雜度＝程序流程圖中的判斷框個數(shù)＋１上一頁下一頁返回12.4軟件測試環(huán)路復雜度的值即為要設計測試用例的基本路徑數(shù)，該程序的環(huán)路復雜度為３，所以設計３個測試用例，覆蓋的基本路徑是ａｂｆ、ａｃｅｆ、ａｃｄｆ。測試用例１：［（Ａ＝１，Ｂ＝０），（輸出略）］，則可測試路徑ａｂｆ測試用例２：［（Ａ＝３，Ｂ＝１），（輸出略）］，則可測試路徑ａｃｅｆ測試用例３：［（Ａ＝３，Ｂ＝３），（輸出略）］，則可測試路徑ａｃｄｆ２．黑盒測試的測試用例設計上一頁下一頁返回12.4軟件測試黑盒測試方法又稱功能測試或數(shù)據(jù)驅動測試，著重測試軟件功能。白盒測試在測試過程的早期階段進行，而黑盒測試主要用于軟件的確認測試。黑盒測試完全不考慮程序內(nèi)部的邏輯結構和處理過程，黑盒測試時在軟件接口處進行，檢查和驗證程序的功能是否符合需求規(guī)格說明書的功能說明。常用的黑盒測試方法和技術有：等價類劃分法、邊界值分析法、錯誤推測法和因果圖等。（１）等價類劃分法。等價類劃分法是一種常用的黑盒測試法，這種方法是先把程序的所有可能的輸入劃分成若干個等價類，然后根據(jù)各等價類取相應的測試用例。上一頁下一頁返回12.4軟件測試每個等價類中各個輸入數(shù)據(jù)度發(fā)現(xiàn)程序中錯誤的幾率幾乎是相同的。因此，從每個等價類中只取一組數(shù)據(jù)作為測試數(shù)據(jù)，這樣選取的測試數(shù)據(jù)最有代表性，最可能發(fā)現(xiàn)程序中的錯誤，并且大大減少了需要的測試數(shù)據(jù)的數(shù)量。（２）邊界值分析法。邊界值分析法是對各種輸入、輸出范圍的邊界情況設計測試用例的方法。大量的實踐表明，程序在處理邊界值時容易出錯，因此設計一些測試用例，程序運行在邊界情況附近，這樣揭露程序中錯誤的可能性更大。選取的測試數(shù)據(jù)應該剛好等于、小于和大于邊界值。上一頁下一頁返回12.4軟件測試也就是說，按照邊界值分析法，應該選取剛好等于、稍小于和稍大于等價類邊界值的數(shù)據(jù)作為測試數(shù)據(jù)，而不是選取每個等價類內(nèi)的典型值或任意值作為測試數(shù)據(jù)。通常設計測試方案時總是把等價劃分和邊界值分析法結合使用。（３）錯誤推測法①錯誤推測法概念。錯誤推測法是一種憑直覺和經(jīng)驗推測某些可能存在的錯誤，從而針對這些可能存在的錯誤設計測試用例的方法。這種方法沒有機械的執(zhí)行過程，主要依靠直覺和經(jīng)驗。錯誤推測法針對性強，可以直接切入可能的錯誤，直接定位，是一種非常實用、有效的方法，但是需要非常豐富的經(jīng)驗。上一頁下一頁返回12.4軟件測試②錯誤測試法實施步驟。首先對被測試軟件列出所有可能出現(xiàn)的錯誤和易錯情況表，然后基于該表設計測試用例。例如，輸入數(shù)據(jù)位０或輸出數(shù)據(jù)為０往往容易發(fā)生錯誤；如果輸入或輸出的數(shù)據(jù)允許變化，則輸入或輸出的數(shù)據(jù)為０和１的情況是容易出錯的情況。測試者可以設計輸入值為０或１的測試情況，以及使輸出強迫為０或１的測試情況。上一頁下一頁返回12.4軟件測試12.4.4軟件測試策略軟件開發(fā)經(jīng)歷了分析、設計和編程等階段，每個階段都可能產(chǎn)生各種各樣的錯誤。為了發(fā)現(xiàn)各階段的錯誤，測試過程應該與開發(fā)過程類似，分步進行，后一個步驟在邏輯上是前一個步驟的繼續(xù)。圖１２-２２給出了開發(fā)過程和測試過程的對應關系。一個軟件系統(tǒng)的測試需要從個體到局部再到整個系統(tǒng)。軟件測試的步驟分為單元測試（模塊測試）、組裝測試（集成測試）、確認測試和系統(tǒng)測試。軟件開發(fā)的過程是自頂向下的，測試則整好相反，采用自底向上、逐步集成的方法上一頁下一頁返回12.4軟件測試１．單元測試針對每個模塊進行的測試可以從程序的內(nèi)部結構出發(fā)設計測試用例，多個模可以平行、同時地測試。單元測試主要用于發(fā)現(xiàn)詳細設計和編程時的錯誤，需要依據(jù)詳細設計說明書和源程序清單，了解該模塊的Ｉ／Ｏ條件和模塊的邏輯結構，主要采用白盒測試，輔之以黑盒測試。由于被測試的模塊往往不是獨立的程序，它處于整個軟件結構的某一層位置上，被其他模塊調(diào)用或調(diào)用其他模塊，其本身不能進行單獨運行，因此在單元測試時，需要為被測模塊設計驅動（Ｄｒｉｖｅｒ）模塊和樁（Ｓｕｂ）模塊。上一頁下一頁返回12.4軟件測試驅動模塊的作用是用來模擬被測模塊的上級調(diào)用模塊，功能要比真正的上級模塊簡單得多，它只完成接收測試數(shù)據(jù)，以上級模塊調(diào)用被測模塊的格式驅動被測模塊，接收被測模塊的測試結果并輸出。樁模塊用來代替被測模塊所調(diào)用的模塊，它的作用是返回被測模塊所需的信息。在模塊測試期間，主要評價模塊的下述５個特性。（１）模塊接口：在其他測試開始之前，需要首先測試模塊接口，檢查數(shù)據(jù)能否正確地通過模塊。如果數(shù)據(jù)不能正確地通過模塊，其他測試就無法進行。（２）局部數(shù)據(jù)結構：說明不正確或不一致；初始化或默認值錯誤；變量名未定義或拼寫錯誤；數(shù)據(jù)類型不相容；上溢、下溢或地址錯誤等。上一頁下一頁返回12.4軟件測試（３）重要的執(zhí)行路徑：重要模塊要進行基本路徑測試，仔細地選擇測試路徑是單元測試的一項基本任務。（４）錯誤處理：主要測試程序對錯誤處理的能力，應檢查是否存在以下問題：不能正確處理外部輸入錯誤或內(nèi)部處理引起的錯誤；對發(fā)生的錯誤不能正確描述，內(nèi)容難以理解；在錯誤處理之前，系統(tǒng)已進行干預等。（５）邊界條件：程序最容易出錯的地方就在邊界上，如輸入／輸出數(shù)據(jù)的等價類邊界、選擇條件和循環(huán)條件的邊界、復雜數(shù)據(jù)結構的邊界等都應進行測試。２．集成測試上一頁下一頁返回12.4軟件測試集成測試是在單元測試的基礎上，根據(jù)模塊結構圖將各模塊連接起來，必須精心計劃，應提交集成測試計劃、集成測試規(guī)格說明書和集成測試分析報告。主要目標是發(fā)現(xiàn)與接口有關的問題。集成測試可以發(fā)現(xiàn)總體設計時犯下的錯誤。集成測試的方法有兩種，即非漸增式測試和漸增式測試。（１）