軟件技術概論與基礎第2章軟件工程學習導入在信息化時代，各行各業都離不開軟件技術的支持，軟件隨處可見，但軟件開發是一個系統工程，開發人員要熟悉軟件開發技術和管理技術。那么，軟件是怎樣被開發出來的？存在哪些開發流程？軟件質量如何控制？軟件是否也存在生命周期？等等。通過對本章內容的學習，上述問題就能迎刃而解。。思維導圖學習目標了解軟件工程的概念了解軟件生命周期及各個階段的作用了解軟件需求工程了解軟件開發模型及適用場景了解軟件測試方法、軟件測試分類、

軟件測試流程及常用軟件測試工具重點難點學習重點軟件工程概念軟件生命周期需求工程軟件開發模型軟件測試學習難點對軟件工程的理解需求分析方法與分析工具相關知識2.1軟件工程概述2.2軟件生命周期2.3需求工程2.4軟件開發模型2.5軟件測試2.1.1軟件工程的概念目前，對軟件工程（SoftwareEngineering，SE）還沒有統一的定義，很多學者、組織機構分別給出了自己的定義。BarryBoehm（巴利·玻姆）給出的定義是：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。IEEE（電氣與電子工程師協會）在軟件工程術語匯編中的定義是：軟件工程是，（1）將系統化的、嚴格約束的、可量化的方法應用于軟件的開發、運行和維護，即將工程化應用于軟件；（2）對（1）中所述方法的研究。FritzBauer在NATO會議上給出的定義是：軟件工程是建立并使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法?！队嬎銠C科學技術百科全書》中的定義是：軟件工程是應用計算機科學、數學、邏輯學及管理科學等原理開發軟件的工程。目前比較被認可的定義是：研究與應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術與當前能夠得到的最好的技術方法結合起來的學科。它涉及程序設計語言、數據庫、軟件開發工具、系統平臺、標準、設計模式等方面。一2.1軟件工程概述軟件工程包括兩方面內容：一是軟件開發技術；二是軟件工程管理。軟件開發技術包含軟件工程方法學、軟件工具和軟件開發環境；軟件工程管理包含軟件工程經濟學和軟件管理學。一2.1軟件工程概述軟件工程的目標是在給定成本、進度的前提下，開發出具有適用性、有效性、可修改性、可靠性、可理解性、可維護性、可重用性、可移植性、可追蹤性、可互操作性和滿足用戶需求的軟件產品。追求這些目標有助于提高軟件產品的質量和軟件開發效率，減少軟件產品維護的困難。一2.1軟件工程概述2.1.2軟件工程的誕生背景在20世紀60年代以前，軟件設計只是在特定的應用和指定的計算機上進行設計與編程，采用的是依賴于計算機的機器語言或匯編語言，軟件規模小，沒有文檔資料，極少使用系統化的開發方法，主要是計算機科學家們自己設計、開發并使用的一種自給自足的軟件開發方式。一1.2軟件行業的發展現狀及發展前景20世紀60年代中期后，隨著集成電路的應用，計算機硬件得到了快速發展，硬件環境相對穩定，出現了大容量、高速度的計算機，計算機的應用范圍不斷擴大，軟件開發與應用急劇增長。軟件系統的規模越來越大，復雜程度越來越高，軟件可靠性問題也越來越突出。在這個時期，軟件開發進度難以預測，開發成本難以控制，產品功能難以滿足用戶需求，產品質量無法得到保證，產品難以維護且缺少適當的文檔資料。落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一系列嚴重問題，這種現象被稱為“軟件危機”。一1.2軟件行業的發展現狀及發展前景為了應對軟件危機，在1968年的一次會議上第一次提出了“軟件工程”概念，“軟件工程”作為正式的術語被確定下來，標志著一個新學科的開始，從此軟件開發進入了軟件工程時代。一1.2軟件行業的發展現狀及發展前景軟件生命周期大致可以分成4個階段，即系統規劃階段、系統開發階段、系統運維階段、系統更新階段。一2.2軟件生命周期2.2.1系統規劃階段系統規劃階段也叫項目立項階段，是軟件開發的開始階段，該階段需要軟件開發方與軟件需求方共同討論，以確定軟件開發的目標和分析其可行性。該階段主要涉及問題定義、可行性分析和需求分析等內容。一2.2軟件生命周期問題定義是軟件定義時期的第一個階段，要弄清用戶“要解決什么問題”。可行性分析通過對項目的市場需求、技術難度、設備選型、環境影響、資金籌措、盈利能力等方面的研究。需求分析是至關重要的一步，因為它包含了獲取用戶需求與定義的信息，以及對需要解決的問題所能達到的最清晰的描述。一2.2軟件生命周期系統規劃階段的目標是制定出系統的長期發展方案，決定系統在整個生命周期內的發展方向、規模和發展進程。系統規劃階段主要形成需求規范說明書。一2.2軟件生命周期2.2.2系統開發階段系統開發階段是信息系統生命周期中最重要和最關鍵的階段，該階段又可以分為總體規劃、系統分析、系統設計、系統實施和系統驗收5個階段。一2.2軟件生命周期1.總體規劃階段系統總體規劃是系統開發的起始階段，它的基礎是需求分析。一個比較完整的總體規劃應當包括系統開發目標、總體結構、管理流程、實施計劃和技術規范等。本階段主要形成可行性研究報告。一2.2軟件生命周期2．系統分析階段系統分析階段的目標是為系統設計階段提供系統的邏輯模型。內容包括組織結構及功能分析、業務流程分析、數據和數據流程分析、系統初步方案等。本階段主要形成系統方案說明書。一2.2軟件生命周期3．系統設計階段根據系統分析階段的結果設計出系統的實施方案，內容包括系統架構設計、數據庫設計、處理流程設計、功能模塊設計、安全控制方案設計、系統組織和隊伍設計、系統管理流程設計等。本階段主要形成系統實施方案。一2.2軟件生命周期4．系統實施階段系統實施階段是將系統設計階段的結果通過編碼、調試和測試，最終在計算機和網絡上具體實現，也就是將設計文本變成能夠在計算機上運行的軟件系統，系統實施階段是對前期全部工作的具體檢驗。在本階段中，用戶的參與特別重要。一2.2軟件生命周期5．系統驗收階段系統通過試運行，系統性能的優劣及其他問題都會暴露在用戶面前，這時就進入了系統驗收階段。一1.2軟件行業的發展現狀及發展前景2.2.3系統運維階段當軟件系統通過驗收并正式移交給用戶以后，系統就進入了運維階段。1．系統維護的概念為了清除系統在運行中發生的故障和錯誤，軟件和硬件維護人員要對系統進行必要的修改與完善；為了使系統適應用戶環境的變化，滿足用戶提出的新需求，也要對原系統進行局部的更新，這些工作稱為系統維護。一2.2軟件生命周期2．系統維護的任務系統維護的任務是改正軟件系統在使用過程中發現的隱含錯誤，擴充在使用過程中用戶提出的新的功能及性能需求。3．系統維護的目的系統維護的目的是維護軟件系統的“正常運作”。4．系統維護的主要文檔系統維護階段主要形成軟件問題報告和軟件修改報告，它們用于記錄發現軟件錯誤的情況及修改軟件的過程。一2.2軟件生命周期5．系統維護的工作量系統維護的工作量一般占整個軟件生命周期的60%～80%，維護類型主要包括改正性維護、適應性維護、完善性維護和預防性維護。一2.2軟件生命周期1）改正性維護為了識別和糾正軟件錯誤、改正軟件性能上的缺陷、排除實施中的錯誤而應當進行的診斷和改正錯誤的過程稱為改正性維護。2）適應性維護在軟件的使用過程中，外部環境（軟件和硬件配置）、數據環境（數據庫、數據介質、數據格式）等可能發生變化，為使軟件能適應新的環境而進行的維護稱為適應性維護。一2.2軟件生命周期3）完善性維護在軟件的使用過程中，用戶往往會對軟件提出新的功能與性能需求，為了滿足這些需求，需要修改或再開發軟件以擴充軟件功能，增強軟件性能，改進軟件處理效率，以及提高軟件的可維護性。4）預防性維護為了提高軟件的可維護性、可靠性等，采用先進的軟件工程方法對需要維護的軟件或軟件中的某一部分進行重新設計、編制和測試，為將來軟件正常運行打下良好的基礎。一2.2軟件生命周期2.2.4系統更新階段系統更新階段也叫系統消亡階段。開發完成一個軟件系統后，想讓其一勞永逸地運行下去是不現實的，所開發的軟件系統經常會不可避免地遇到系統更新改造、功能擴展，甚至報廢重建的情況。因此，在軟件系統建設的初期就要考慮系統的消亡條件和時機，以及因此而花費的成本。一2.2軟件生命周期2.3.1需求工程概述1．需求工程的概念需求工程（RequirementsEngineering，RE）是指應用已證實有效的技術、方法進行需求分析，確定用戶需求，幫助軟件分析人員正確理解問題并定義目標系統的所有外部特征的一門學科。需求工程的結果是對待開發系統給出清晰的、一致的、精確的且無二義性的需求模型，形成需求文檔，通常以需求規格說明書的形式來定義待開發系統的所有外部特征。一2.3需求工程2．需求工程發展簡介在20世紀80年代中期，形成了軟件工程的子領域——需求工程。進入20世紀90年代后，需求工程成為人們研究的熱點。1993年，IEEE在美國加利福尼亞州的圣迭戈舉辦了第一屆需求工程國際研討會（ISRE），確定以后每兩年舉辦一次；從1994年起每兩年舉辦一次需求工程國際會議（ICRE）；1996年，世界著名科技期刊、圖書出版公司Springer-Verlag（施普林格）發行了新刊物RequirementsEngineering；同時，一些關于需求工程的工作小組相繼成立。一2.3需求工程3．需求工程的內容需求工程包括獲取、分析、定義、驗證和管理軟件需求的所有活動。需求工程分為兩類，一類是需求開發，另一類是需求管理。一2.3需求工程3．需求工程的內容一2.3需求工程（1）需求開發需求開發包括4個主要活動：需求獲取、需求分析、需求定義和需求驗證。2．需求管理需求管理包含需求分配、需求評審、變更控制和需求跟蹤。一2.3需求工程2.3.2需求分析概述1．需求分析的概念需求分析也稱軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致地調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須“做什么”的過程。一2.3需求工程2．需求分析的目標需求分析的目標是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其他系統元素的接口細節，定義軟件的其他有效性需求。一2.3需求工程3．需求分析研究的對象需求分析階段研究的對象是軟件項目的用戶要求。一方面必須全面理解用戶的各項要求，但又不能全盤接受所有的要求；另一方面，要準確地表達被接受的用戶要求。只有經過確切描述的軟件需求才能成為軟件設計的基礎。一2.3需求工程4．需求分析的任務需求分析的任務就是為原始問題及目標軟件建立邏輯模型，解決目標系統“做什么”的問題。一2.3需求工程5．需求分析的注意事項需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其他系統元素的接口細節，定義軟件的其他有效性需求。因此，在進行需求分析時，應注意一切信息與需求都是站在用戶的角度上，考慮盡量避免分析人員的主觀想法，在不對用戶進行直接指導的前提下，讓用戶進行檢查與評價，從而達到需求分析的準確性。一2.3需求工程6．需求內容GB/T9385《計算機軟件需求說明編制指南》中定義了需求的具體內容，軟件需求可以分為功能需求、性能需求、設計約束、質量屬性、外部接口需求等幾類。一2.3需求工程1）功能需求功能需求是描述軟件產品的輸入怎樣變成輸出，即軟件必須完成的基本動作。2）性能需求性能需求是軟件或人與軟件交互的靜態或動態數值需求，如支持的終端數、支持并行操作的用戶數、響應時間等。一2.3需求工程3）設計約束設計約束是受其他標準、硬件限制等方面的影響。4）質量屬性在軟件的需求中有若干個屬性，如可移植性、正確性、可維護性及安全性等。5）外部接口需求外部接口需求主要包括用戶接口、硬件接口、軟件接口、通信接口等。一2.3需求工程2.3.3需求分析方法從系統分析出發，可以將需求分析方法大致分為結構化分析法、面向對象分析法、功能分解法和信息建模法。一2.3需求工程1．結構化分析法結構化分析（StructuredAnalysis，SA）是一種面向數據流的軟件分析方法，適用于開發數據處理類型軟件的需求分析。結構化分析法的主要思想是“自頂向下，逐步分析”，描述SA結構的主要手段是數據流圖和數據字典，因此，結構化分析法又被稱為數據流法。一2.3需求工程2．面向對象分析法面向對象分析（Object-OrientedAnalysis，OOA）是在繁雜的問題域中抽象地識別出對象及其行為、結構、屬性、方法等的軟件分析方法。面向對象分析法的關鍵是識別問題域內的對象，分析它們之間的關系，并建立3類模型，即對象模型、動態模型和功能模型。一2.3需求工程3．功能分解法功能分解法是以系統需要提供的功能為中心來組織系統的。將系統作為多功能模塊的組合，各功能又可以被分解為若干個子功能及接口，子功能再繼續分解，便可得到系統的雛形，即功能分解——功能、子功能、功能接口。一2.3需求工程4．信息建模法信息建模法是從數據角度對現實世界建立模型。信息建?？啥x為實體（對象）、屬性、關系、父類型/子類型和關聯對象。信息建模法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。信息建模法的基本策略是先從現實中找出實體，再用屬性進行描述。一2.3需求工程2.3.4需求分析工具在需求分析階段，常用的圖形工具有數據流圖、E-R圖、層次方框圖、Warnier圖、用例圖、IPO圖等。一2.3需求工程1．數據流圖。數據流圖（DataFlowDiagram，DFD）是結構化分析法中使用的工具，是在需求分析階段使用的一種主要工具，它以圖形的方式表達數據處理系統中信息的變換和傳遞過程,即一個系統的邏輯輸入和邏輯輸出，以及把邏輯輸入轉換為邏輯輸出所需的加工處理。數據流圖中的基本符號包括數據流、加工、數據存儲、外部實體。一2.3需求工程1）數據流數據流是具有名字和流向的數據，在數據流圖中用標有名字的箭頭表示（→）。2）加工加工是對數據流的變換，一般用圓圈表示（○）。3）數據存儲數據存儲是可訪問的存儲信息，一般用兩條平行的細直線段表示（＝）。4）外部實體外部實體是不能由計算機處理的成分，它們分別表明數據處理過程的數據來源及數據去向，用標有名字的方框表示（□）。一2.3需求工程【案例】根據下列需求描述，畫出某學校學生檔案管理系統的數據流圖。需求描述：學生錄入個人信息建檔，未審核的數據可以重復修改，審核后的數據不允許修改，要修改數據可以向學生處申請；學生處需審核學生信息，審核后的學生信息作為權威數據保存，學生處可以查詢、修改學生信息，可以按一定條件生成統計報表，審核后的數據供院系、職能部門在權限范圍內進行學生信息查詢。一2.3需求工程根據需求分析，某學校學生檔案管理系統的數據流圖如圖所示一2.3需求工程2．E-R圖E-R圖也稱實體-聯系圖（EntityRelationshipDiagram），其提供了表示實體類型、屬性和聯系的方法，用來描述現實世界的概念模型。構成E-R圖的基本要素是實體、屬性和聯系。一2.3需求工程E-R圖中的基本符號包括矩形框、橢圓形框、菱形框、直線。 矩形框（□）：表示實體。 橢圓形框（）：表示屬性。 菱形框（

）：表示聯系。 直線：用于實體、屬性和聯系之間的連接。一2.3需求工程【案例】根據下列需求描述，畫出某學校教學管理系統的E-R圖。需求描述：一個教師最多只能教授一門課程，一門課程允許由多個教師授課；一個學生可以選修多門課程，一門課程可供不同學生選擇。一2.3需求工程【案例】根據下列需求描述，畫出某學校教學管理系統的E-R圖。需求描述：一個教師最多只能教授一門課程，一門課程允許由多個教師授課；一個學生可以選修多門課程，一門課程可供不同學生選擇。教師屬性：姓名、性別、教工號、所屬院系、所屬教研室、職稱。學生屬性：姓名、性別、學號、年級、班級、所屬院系、所屬專業。課程屬性：課程名稱、課程號、學時、學分。一2.3需求工程根據需求分析，某學校教學管理系統的E-R圖如圖所示。一2.3需求工程3．層次方框圖層次方框圖是通過樹形結構的一系列多層次的矩形框來描述復雜數據的層次結構。層次方框圖的上層框圖要包含下層框圖?！皹涓笔菍哟畏娇驁D的頂層，用一個單獨的矩形框表示，代表完整的數據結構，下面各層矩形框代表這個數據結構的子集，并且每兩層（上層與下一層）要體現包含關系，“樹葉”即最底層的各個矩形框代表組成這個數據的實際數據元素，并且是不能再分割的元素。層次方框圖存在的最大缺點是不能很好地表現同一層矩形框之間的關系。一2.3需求工程【案例】根據下列需求描述，畫出某單位員工實發工資的層次方框圖。需求描述：某單位員工的實發工資由應發工資和扣款兩部分組成，每部分又可以進一步細分；應發工資由基本工資和獎金組成；扣款由所得稅、保險、缺勤組成；基本工資由財政工資、津貼、補貼組成；獎金由全勤獎、業績獎組成；津貼、補貼、保險可以根據需要進一步細分。一2.3需求工程根據需求分析，某單位員工實發工資的層次方框圖如圖所示。一2.3需求工程4．Warnier圖Warnier圖是由法國計算機科學家Warnier（瓦尼耶）提出的一種軟件開發方法，Warnier圖是表示數據層次結構的一種圖形工具，它用樹形結構來描繪數據結構。Warnier圖中的基本符號包括花括號、異域符號、圓括號。一2.3需求工程花括號“{}”用于區分信息的層次，在一個花括號中的所有名稱都屬于一類信息。異或符號“⊕”用于表明一類信息或一個數據元素在一定條件下才出現，在這個符號的上方和下方的兩個名稱所代表的數據只能出現一次。圓括號“（）”中的數字用于表明這個名稱所代表的信息類或元素在這個數據結構中出現的次數。。一2.3需求工程【案例】根據下列需求描述，畫出某軟件公司本月為用戶提供軟件產品服務的Warnier圖。需求描述：某軟件公司本月為用戶提供軟件產品服務，軟件產品由系統軟件和應用軟件兩類構成；系統軟件中操作系統提供了20次服務，編譯系統提供了10次服務，數據庫管理系統提供了30次服務；應用軟件中辦公軟件提供了50次服務，娛樂軟件提供了100次服務，視頻軟件提供了20次服務，通訊軟件提供了10次服務，游戲軟件提供了60次服務。一2.3需求工程根據需求分析，某軟件公司本月為用戶提供軟件產品服務的Warnier圖如圖所示。一2.3需求工程5．用例圖用例圖是指由參與者、用例、系統邊界及它們之間的關系構成的用于描述系統功能的視圖。用例圖可以用來獲取需求、指導測試、引導其他工作流等，所以用例圖也是需求分析階段常用的圖形分析工具。需要注意的是，參與者不是特指人，是指系統以外的、在使用系統或與系統交互中所扮演的角色。一2.3需求工程在用例圖中，參與者用小人（）表示，用例用橢圓形框（）表示。參與者和用例之間的關系使用帶箭頭或不帶箭頭的線段來描述，箭頭表示在這一關系中哪一方是對話的主動發起者，箭頭所指方是對話的被動接受者。例如，當使用帶箭頭的線段時，箭頭所指的一方為被動接受方，另一方為主動發起方。一2.3需求工程【案例】根據下列需求描述，畫出某培訓機構培訓計劃系統的用例圖。需求描述：某培訓機構培訓計劃系統要求培訓學生注冊課程；管理員甲負責審批學生注冊信息；管理員乙負責維護課程計劃、分配培訓教室、分配指導教師、維護指導教師信息；指導教師負責確認培訓人員名單；攝像設備對培訓教室進行全程錄像。一2.3需求工程根據需求分析，某培訓機構培訓計劃系統的用例圖如圖所示。一2.3需求工程6．IPO圖IPO圖（Input/Processing/Output）是輸入/處理/輸出圖的簡稱，它是美國IBM公司提出的一種圖形工具，能夠方便地描繪輸入數據、處理數據和輸出數據之間的關系。一2.3需求工程IPO圖使用的基本符號少而簡單，因此可以很容易掌握這種工具。它的基本形式如下：（1）在左邊的框中列出有關的輸入數據。（2）在中間的框中列出主要的處理。（3）在右邊的框中列出產生的輸出數據。（4）處理框中列出了處理的順序。一2.3需求工程【案例】根據下列需求描述，畫出某注冊系統用戶注冊過程的IPO圖。需求描述：用戶在注冊頁面輸入用戶賬號、密碼和驗證碼；當輸入的信息通過驗證時，則注冊成功，并自動登錄系統；當賬號格式不符合要求時，則提示賬號格式錯誤；當賬號在系統中已存在時，則提示該賬號已被注冊；當密碼格式與系統設置要求不符時，則提示密碼格式錯誤；當驗證碼錯誤時，則提示驗證碼錯誤。一2.3需求工程根據需求分析，某注冊系統用戶注冊過程的IPO圖如圖所示。一2.3需求工程軟件開發模型（SoftwareDevelopmentModel）是指軟件開發全部過程、活動和任務的結構框架。軟件開發模型能清晰、直觀地表達軟件開發全過程，明確規定了要完成的主要活動和任務，是軟件開發項目工作的基礎。針對不同的軟件系統，可以采用不同的開發模型和開發方法；使用不同的軟件開發語言；采用不同的管理方法和手段；允許采用不同的軟件工具和不同的軟件工程環境。一2.4軟件開發模型2.4.1瀑布模型1．瀑布模型概述瀑布模型（WaterfallModel）是由溫斯頓·羅伊斯（W·Royce）在1970年提出的著名模型，是最早出現的軟件開發模型。一2.4軟件開發模型瀑布模型是一個經典的軟件生命周期模型，一般將軟件開發分為可行性分析、需求分析、軟件設計、編碼、測試和運維等階段。瀑布模型將軟件生命周期的各項活動規定為按固定順序連接的若干階段工作，并且規定了它們自上而下、相互銜接的固定次序，整個開發過程形如瀑布流水，這也是瀑布模型名稱的由來。一2.4軟件開發模型在瀑布模型中，軟件開發的各階段活動嚴格按照線性方式進行，當前階段活動接受上一階段活動的工作結果，依次實施完成所需的工作內容。在開發過程中，當前階段活動的工作結果需要進行評審驗證，如果評審驗證通過，則該結果作為下一階段活動的輸入，繼續進行下一階段活動，否則返回上一階段甚至更前階段進行修改。一2.4軟件開發模型2．瀑布模型的特點（1）固有順序。在使用瀑布模型開發軟件時，嚴格按軟件生命周期各階段的固有順序，即上一階段完成后才能進入下一階段。（2）推遲實現。在使用瀑布模型開發軟件時會盡可能推遲程序的物理實現。（3）質量保證。使用瀑布模型開發軟件的基本目標是優質、高產。一2.4軟件開發模型3．瀑布模型的優點（1）有利于大型軟件開發過程中人員的組織和管理。（2）有利于軟件開發方法和工具的研究。（3）有利于提高大型軟件項目開發的質量和效率。一2.4軟件開發模型4．瀑布模型的缺點（1）各個階段的順序固定，階段之間將產生大量的文檔，這大大增加了開發工作量。（2）對需求比較敏感，要求預先確定需求，難以滿足用戶需求變化。（3）瀑布模型是線性的，一個階段確認后才能繼續下一階段，建設周期長，增加了開發風險。（4）除提出需求以外，用戶很少參與開發工作。一2.4軟件開發模型5．瀑布模型的適用場景（1）適用于需求明確且需求很少變更的項目。（2）適用于規模較大、需求清晰的項目。（3）適用于與過去成功開發過的項目類似，但規模更大的新項目。一2.4軟件開發模型2.4.2原型模型1．原型模型概述原型模型（PrototypeModel）允許在需求分析階段對軟件的需求進行初步而非完全的分析和定義，快速設計開發出軟件系統的原型或借用已有系統作為原型模型，該原型向用戶展示待開發軟件的全部或部分功能和性能，通過對原型的不斷改進，最后的產品就是用戶所需要的。一2.4軟件開發模型使用原型模型開發軟件主要是通過向用戶提供原型來獲取用戶的反饋，使開發出的軟件能夠真正反映用戶的需求。原型模型采用逐步求精的方法完善原型，使得原型能夠“快速”開發，避免了像瀑布模型一樣，在冗長的開發過程中難以對用戶的反饋做出快速的響應。原型模型更符合人們開發軟件的習慣，是目前比較流行的一種實用軟件生命周期模型。一2.4軟件開發模型2．原型模型的開發步驟原型模型的開發步驟包括快速分析、構造原型、運行原型、評價原型、修改等。一2.4軟件開發模型3．原型模型的特點（1）快速建立初步需求。（2）快速構建可運行的軟件模型。（3）加強用戶參與與決策。一2.4軟件開發模型4．原型模型的優點原型模型克服了瀑布模型的缺點，減少了由于軟件需求不明確帶來的開發風險。5．原型模型的缺點快速建立起來的軟件系統原型加上連續的修改可能會導致軟件產品的質量低下。6．原型模型的適用場景原型模型適用于用戶需求模糊或預先不能確切定義需求的軟件系統的開發。一2.4軟件開發模型2.4.3螺旋模型1．螺旋模型概述螺旋模型（SpiralModel）是由巴利·玻姆（BarryBoehm）在1988年提出的一種軟件開發模型，它兼顧了原型模型迭代的特征與瀑布模型的系統化與嚴格監控，增加了風險分析，特別適用于大型復雜系統的開發。一2.4軟件開發模型螺旋模型可以被看作是在每個階段之前都增加了風險分析的快速原型模型。螺線的每個周期對應一個開發階段，每個開發階段可以被視為一個任務簡化的瀑布模型。一2.4軟件開發模型螺旋模型沿著螺線進行若干次迭代，圖中的4個象限代表了以下活動：（1）制訂計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件。（2）風險分析：分析、評估所選方案，考慮如何識別和消除風險。（3）實施工程：實施軟件開發和驗證。（4）客戶評價：評價開發工作，提出修正建議，制定下一步計劃。一2.4軟件開發模型2．螺旋模型的特點（1）以原型為基礎，沿著螺線自內向外旋轉。（2）每旋轉一圈都要經過制訂計劃、風險分析、實施工程、客戶評價等活動，并開發原型的一個新版本，重復這一過程。（3）在螺旋模型演進式的過程中，確定一系列的里程碑，以確保項目朝著正確的方向前進，同時減少風險。一2.4軟件開發模型3．螺旋模型的優點（1）由文檔和風險驅動，有利于提高大型項目開發的質量和效率。（2）設計上具有靈活性，有利于在項目的各個階段進行需求變更。（3）以分段來構建大型系統，有利于成本計算與控制。（4）用戶全程參與，有利于項目沿著正確方向發展。一2.4軟件開發模型4．螺旋模型的缺點項目建設周期長，而軟件技術發展快，原來技術和當前技術之間可能存在較大差距，難以滿足用戶當前需求，存在較大風險。5．螺旋模型的適用場景螺旋模型適用于需求不明確或需求經常變化的大型復雜系統的開發。一2.4軟件開發模型2.4.4演化模型1．演化模型概述演化模型（EvolutionaryModel）也叫變換模型，屬于迭代開發方法。演化模型是在快速開發一個原型的基礎上，根據用戶在調用原型的過程中所反饋的意見和建議對原型進行改進，獲得原型的新版本，重復這一過程，直到演化成最終的軟件產品。一2.4軟件開發模型演化模型可以表示為需求—設計—編碼（實現）—測試—集成—反饋等過程，該過程經過若干次迭代，最終演化成用戶所需的軟件產品。一2.4軟件開發模型2．演化模型的特點先開發系統的核心功能，再通過用戶反饋獲取用戶新的需求并進行修改，不斷完善迭代該軟件項目。一2.4軟件開發模型3．演化模型的優點（1）任何功能一經開發就能進入測試，以便驗證是否符合產品需求。（2）測試過程可以引出高質量的軟件產品。（3）對于原來提出的產品需求，可以根據現階段原型的運行而及時調整、修改。（4）用戶充分參與，能夠及時提出有價值的反饋。一2.4軟件開發模型4．演化模型的缺點（1）需求不明確且重復修改，可能影響產品質量及產品的可維護性。（2）如果缺乏嚴格的過程管理，則可能退化為一種原始的、無計劃的“試－錯－改”模式。5．演化模型的適用場景演化模型適用于事先不能完整定義需求的軟件的開發。用戶可以給出待開發系統的核心需求，并且在看到核心需求被實現后能夠有效地提出反饋，以支持系統的最終設計和實現。一2.4軟件開發模型2.4.5噴泉模型1．噴泉模型概述噴泉模型（FountainModel）是由B.H.Sollers和J.M.Edwards在1990年提出的一種新的軟件開發模型。噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面向對象的軟件開發過程。一2.4軟件開發模型噴泉模型支持軟件復用及多項開發活動的集成。噴泉模型的各個開發階段是可以重疊的，即階段與階段之間沒有明顯的邊界，當某一階段出現問題時，需返回上一階段重新修改，該模型允許多個階段并行進行。一2.4軟件開發模型2．噴泉模型的特點噴泉模型認為軟件開發過程自下而上周期的各個階段具備相互迭代和無間隙的特性。3．噴泉模型的優點（1）各個階段沒有明顯的界限，開發人員可以同步進行開發。（2）可以提高軟件項目的開發效率，節省開發時間。一2.4軟件開發模型4．噴泉模型的缺點（1）由于噴泉模型的各個開發階段是可以重疊的，因此在開發過程中需要大量的開發人員，不利于項目的管理。（2）噴泉模型要求嚴格管理文檔，使得審核的難度加大。5．噴泉模型的適用場景噴泉模型主要用于描述面向對象的軟件開發過程。一2.4軟件開發模型2.4.6V模型1．V模型概述V模型又稱快速應用開發（RapidApplicationDevelopment）模型，是軟件開發過程中的一個重要模型，由于其模型構圖形似字母V，因此被稱為V模型。一2.4軟件開發模型V模型一般將軟件開發分為需求分析、概要設計、詳細設計、軟件編碼、單元測試、集成測試、系統測試、驗收測試等階段。一2.4軟件開發模型2．V模型的特點V模型以測試為中心，為軟件生命周期的每個階段都指定了相應的測試級別：軟件編碼階段<--->單元測試，詳細設計階段<--->集成測試，概要設計階段<--->系統測試，需求分析階段<--->驗收測試。一2.4軟件開發模型3．V模型的優點（1）清楚地標識了開發和測試的各個階段，有利于縮短開發周期，提高軟件質量。（2）各個階段分工明確，有利于對整體項目的把控，提高項目的開發效率。一2.4軟件開發模型4．V模型的缺點（1）在實際項目開發中，需求經常會發生變化，從而導致V模型的各個階段被反復執行，返工量很大，靈活度較低。（2）自上而下的開發順序使得測試工作在編碼之后，會導致前期的錯誤不能及時被發現和修改。5．V模型的適用場景V模型是一種傳統的軟件開發模型，一般適用于一些傳統信息系統應用的開發，不適用于高性能高風險的系統、互聯網軟件或難以被具體模塊化的系統的開發。一2.4軟件開發模型2.4.7敏捷開發1．敏捷開發概述敏捷開發（AgileDevelopment）以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。敏捷開發是目前比較主流的開發模式之一。一2.4軟件開發模型敏捷開發的實現主要包括SCRUM（迭代式增量軟件開發過程）、XP（ExtremeProgramming，極限編程）、CrystalMethods（水晶方法）、FDD（特性驅動開發）等，其中SCRUM與XP最為流行。一2.4軟件開發模型2．敏捷開發的特點在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換句話說，就是把一個大項目分解成多個相互聯系但又可獨立運行的小項目，在此過程中，軟件一直處于可使用狀態。一2.4軟件開發模型3．敏捷開發的優點較高的開發速度是敏捷開發最顯著的優點。敏捷開發使項目很快就進入實質性開發迭代階段，使得用戶很快就可以看到一個可運行的軟件產品。敏捷開發注重快速反應能力，用戶前期滿意度高。一2.4軟件開發模型4．敏捷開發的缺點敏捷開發注重人員之間的溝通，但是忽略文檔的重要性，當項目人員不穩定時會給開發和維護帶來困難。敏捷開發對項目負責人的能力要求很高，給項目管理帶來巨大挑戰。5．敏捷開發的適用場景敏捷開發適用于需求復雜多變、希望高效地管理開發進度的項目。一2.4軟件開發模型2.5.1Bug的由來1947年9月9日，當人們測試MarkII計算機時，它突然發生了故障。在經過幾個小時的檢查后，工作人員發現一只飛蛾死在了面板F的第70號繼電器中。當把這個飛蛾取出后，機器便恢復了正常。一2.5軟件測試葛麗絲·霍普在工作手冊上登記的那只飛蛾看作計算機上第一個被記錄在文檔中的Bug，從此，軟件工程領域就開始了和“蟲子”（Bug）之間無休止的戰爭，Bug一詞也成為計算機系統程序的專業術語，用來形容系統中的缺陷或問題。一2.5軟件測試2.5.2軟件測試概述軟件測試（SoftwareTesting）是使用人工或自動的手段，在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能夠滿足設計要求進行評估的過程。一2.5軟件測試在軟件開發過程中，軟件缺陷的產生是不可避免的。軟件測試就是為了發現錯誤而執行程序的過程，它是根據軟件需求及程序內部結構而精心設計一批測試用例，并利用這些測試用例去運行程序，以發現程序錯誤的過程。軟件測試是有意識地發現軟件中存在的錯誤，驗證和確認軟件功能與性能是否符合軟件需求的重要手段之一。一2.5軟件測試軟件測試的主要過程包括設計測試用例、執行程序、分析結果找出錯誤并改正。設計測試用例的目標是選用少量但高效的測試用例盡可能多地發現軟件中的問題，因此，測試的關鍵是測試用例的設計。一2.5軟件測試軟件測試并不是在軟件開發完成后進行的一次性驗證活動，而是貫穿于整個軟件開發周期，也是對軟件開發過程質量監管的過程。軟件測試的工作量占軟件開發總工作量的40%以上，其目的是盡可能多地發現軟件產品中的錯誤和缺陷并改正。一2.5軟件測試2.5.3軟件測試方法從是否關心軟件內部結構的角度和按測試用例設計方法，可以將軟件測試方法分為白盒測試、黑盒測試和灰盒測試；從是否執行程序的角度，可以將軟件測試方法分為靜態測試和動態測試。一2.5軟件測試1．白盒測試程序被裝在透明“盒子”中，測試者完全了解程序的結構和處理過程；根據程序內部邏輯來設計測試用例，檢查邏輯通路是否都按預定的要求正確工作。白盒測試方法主要有邏輯覆蓋法、代碼檢査法、基本路徑測試法、域測試法、符號測試法等。邏輯覆蓋法是白盒測試常用的方法，邏輯覆蓋由弱到強分為語句覆蓋、判定覆蓋、條件覆蓋、條件組合、路徑覆蓋。一2.5軟件測試2．黑盒測試程序被裝在不透明“盒子”中，測試者完全不了解程序的結構和處理過程；根據需求規格說明書規定的功能來設計測試用例，檢查程序和功能是否符合需求規格說明書的要求。黑盒測試方法主要有等價類劃分法、邊界值分析法、錯誤推測法、因果圖法等。一2.5軟件測試3．灰盒測試灰盒測試是一種介于白盒測試與黑盒測試之間的測試，它結合了白盒測試和黑盒測試的要素?；液袦y試既關注輸入與輸出的正確性，也關注程序內部結構的表現。一2.5軟件測試4．靜態測試靜態測試是指被測程序不進行上機運行，而是通過人工評審軟件文檔或程序，借以發現其中的錯誤。具體方法是通過分析或檢查源程序的語法、結構、過程、接口等來檢查程序的正確性，通過查看需求規格說明書、軟件設計說明書，進行源程序結構分析、流程圖分析及符號執行等來查找錯誤。一2.5軟件測試5．動態測試動態測試是指對被測程序進行上機測試，然后對得到的運行結果與預期的結果進行比較分析，同時分析運行效率和健壯性能等的軟件測試方法。這種方法可以使程序有控制地運行，并從多種角度觀察程序的行為，以發現其中的錯誤。一2.5軟件測試2.5.4軟件測試分類常用的軟件測試類型和方法:按照軟件開發階段分類：單元測試、集成測試、確認測試、系統測試、驗收測試。按照測試實施組織分類：α（Alpha）測試、β（Beta）測試。按照測試目的分類：功能測試、性能測試。按照是否手動執行分類：手動測試、自動化測試。其他測試方法：回歸測試、冒煙測試、可用性測試、UI測試等。一2.5軟件測試1．單元測試單元測試又稱模塊測試，在編碼階段進行，是針對軟件設計的最小單位程序模塊進行正確性檢查的測試工作。單元測試需要從程序內部結構出發設計測試用例，主要用來發現編碼和詳細設計中產生的錯誤。單元測試屬于靜態測試，測試方法一般采用白盒測試。一2.5軟件測試2．集成測試集成測試又稱組裝測試，是在單元測試的基礎上，需要將所有模塊按照概要設計說明書和詳細設計說明書的要求進行組裝，對由各模塊組裝而成的模塊進行測試，檢查模塊之間的接口和通信，發現設計階段產生的錯誤。測試方法一般采用黑盒測試。一2.5軟件測試3．確認測試確認測試又稱有效性測試，其目標是驗證軟件的功能和性能及其他特性是否與用戶的要求一致。確認測試一般包括有效性測試和軟件配置復查，一般由第三方測試機構進行。測試方法一般采用黑盒測試或灰盒測試。一2.5軟件測試4．系統測試系統測試是指在實際的硬件、網絡及數據等環境中對軟件進行測試，包括對功能、性能及軟件所運行的軟件和硬件環境進行測試。測試方法一般采用黑盒測試。一2.5軟件測試5．驗收測試驗收測試是以用戶為主、以需求規格說明書為依據的測試，在用戶工作環境下，檢查軟件的功能、性能和其他特征是否與用戶的需求一致。測試方法一般采用黑盒測試。一2.5軟件測試6．α（Alpha）測試α（Alpha）測試是在開發者現場由用戶實施的測試，即由用戶在開發環境中進行的測試，或者是由開發公司內部的用戶在模擬實際操作環境下進行的測試。7．β（Beta）測試β（Beta）測試是在用戶現場由軟件最終用戶實施的測試，即由用戶在實際使用環境下進行的測試。一2.5軟件測試8．功能測試功能測試主要用于檢查輸出與需求中定義的輸入的準確性，對產品的各項功能進行驗證，檢查產品是否達到用戶要求的功能。一2.5軟件測試9．性能測試性能測試類型包括壓力測試、負載測試、并發測試、強度測試、容量測試等，主要用于檢查系統是否滿足需求規格說明書中規定的性能。一2.5軟件測試10．手動測試手動測試是由人去一個一個地輸入測試用例，然后觀察結果。復雜的業務邏輯很難用自動化測試，手動測試能夠發現一些自動化測試所不能發現的問題，所以自動化測試無法完全取代手動測試。手動測試的優勢在于可以對復雜的業務邏輯進行測試。一2.5軟件測試11．自動化測試自動化測試是在預設條件下運行軟件系統，然后評估運行結果。自動化測試的優勢在于可以對底層架構進行測試。目前，大部分測試都是手動測試和自動化測試相結合進行。一2.5軟件測試12．回歸測試回歸測試是指在發生修改之后重新測試先前的測試用例以保證修改的正確性。理論上，軟件產生新版本都需要進行回歸測試，以驗證以前發現和修復的錯誤是否在新版本中再次出現。回歸測試的目的是驗證以前出現過但已修復好的缺陷不再出現，以及確認先前的修改沒有引入新的錯誤或導致其他代碼產生錯誤。一2.5軟件測試13．冒煙測試冒煙測試源自硬件行業，對一個硬件或硬件組件進行更改或修復后，直接給設備加電，如果沒有冒煙，則該組件就通過了測試。在軟件中，“冒煙測試”這一術語描述的是在將代碼更改嵌入產品的源樹中之前對這些更改進行驗證的過程，在檢查代碼后，冒煙測試是確定和修復軟件缺陷最經濟、是有效的方法。冒煙測試用于確認代碼中的更改會按預期運行，并且不會破壞整個版本的穩定性。一2.5軟件測試14．可用性測試可用性測試的目的主要是保證代碼的提交不會對軟件產生影響。15．UI測試UI測試（UserInterfaceTesting，用戶界面測試）主要用于測試用戶界面的功能模塊的布局是否合理，整體風格是否一致，各個控件的放置位置是否符合用戶使用習慣，頁面元素（如布局、顏色、字體、大小等）是否符合用戶需求等。一2.5軟件測試2.5.5軟件測試流程軟件測試與軟件開發一樣，是一個復雜的工作過程。軟件測試流程主要包括5個步驟，即測試需求分析、制訂測試計劃、設計測試用例、執行測試用例、編寫測試報告。一2.5軟件測試1．測試需求分析軟件需求是測試軟件質量的基礎，因此要先對軟件需求進行分析，對所開發的軟件產品有一個全面的了解，從而明確測試對象及測試工作的范圍和測試重點。在進行測試需求分析時，不僅能夠發現軟件是否正確、是否滿足用戶需求，還能夠獲取大量測試數據以作為設計測試用例的依據。一2.5軟件測試2．制訂測試計劃軟件測試貫穿于軟件開發的全過程，是一項工作量巨大的工作，在進行軟件測試前，需要制訂一個詳細的測試計劃來指導軟件測試工作，但測試計劃也會隨著項目開發進度或需求變更而不斷調整、完善和優化。測試計劃一般包括確定測試范圍、制訂測試方案、配置測試資源、安排測試進度、預估測試風險等內容。一2.5軟件測試3．設計測試用例測試用例（TestCase）是一個文檔，即一套詳細的測試方案，測試用例的基本要素包括測試用例編號、測試標題、測試重要級、測試輸入、操作步驟和預期結果。測試用例常用的設計方法包括等價類劃分法、邊界值分析法、因果圖與判定表法、正交實驗設計法、邏輯覆蓋法等。一2.5軟件測試4．執行測試用例執行測試用例是軟件測試流程中最主要的活動，是整個測試過程的核心。在執行測試用例時，要根據測試用例的優先級進行。測試人員需要按測試用例的優先級執行所有的測試用例，每個測試用例都可能會發現一個或多個Bug，測試人員要做好測試記錄與跟蹤，確定缺陷等級并編寫缺陷報告。當提交的缺陷被開發人員修改之后，測試人員還需要進行回歸測試。一2.5軟件測試5．編寫測試報告測試報告是對測試過程進行歸納總結，對測試數據進行統計，對測試質量進行客觀評價，對發現的問題和缺陷進行分析，為改正軟件中的錯誤提供依據的文檔。一份完整的測試報告包括引言、測試概要、測試內容、執行情況、缺陷統計與分析、測試結論與建議等部分。一2.5軟件測試2.5.6軟件測試工具軟件測試工具分為自動化軟件測試工具和測試管理工具。1．自動化軟件測試工具自動化軟件測試是指使用軟件工具來代替人工輸入和人工測試工作。目前，市場上主流的自動化軟件測試工具有LoadRunner、Selenium、TestComplete、KatalonStudio、ApacheJMeter、LambdaTest、TestProject、Postman、Testsigma、Appium等。一2.5軟件測試2．測試管理工具測試管理工具是指在軟件測試過程中，對測試需求分析、制訂測試計劃、設計測試用例和執行測試用例等過程進行管理，對軟件缺陷進行跟蹤處理的工具。目前，市場上主流的軟件測試管理工具有ZenTaoPMS、TestCenter、TestDirector、TestLink、TestManager等。一2.5軟件測試3．測試工具介紹1）ZenTaoPMS2）LoadRunner3）Selenium4）TestComplete5）TestCenter6）Jmeter7）Postman一2.5軟件測試【案例1】軟件維護類型主要包括改正性維護、適應性維護、完善性維護和預防性維護。程序在使用過程中可能會發生錯誤，診斷和改正這些錯誤的過程稱為（）；為了給未來的改進提供更好的基礎而對軟件進行修改，這類活動稱為（）。A．完善性維護 B．改正性維護C．預防性維護 D．適應性維護一技能訓練【分析】為了滿足用戶提出的增加新功能、修改現有功能及一般性的改進要求和建議，需要進行完善性維護；程序在使用過程中可能會發生錯誤，診斷和改正這些錯誤的過程稱為改正性維護；為了給未來的改進提供更好的基礎而對軟件進行修改，這類活動稱為預防性維護；軟件在使用過程中，外部環境、數據環境等可能發生變化，為了使軟件能夠適應新的環境而進行的維護稱為適應性維護?！敬鸢浮緽、C一技能訓練【案例2】軟件需求可以分為功能需求、性能需求、設計約束、質量屬性、外部接口需求等幾類。以下選項中均屬于功能需求的是（）。①對特定范圍內進行修改所需的時間不超過2秒。②按照訂單及原材料情況自動安排生產排序。③系統能夠同時支持100個獨立站點的并發訪問。④系統可以實現對多字符集的支持，包括GBK、UTF-8等。⑤定期生成銷售分析報表。⑥系統實行同城異地雙機備份，保障數據安全。A．①② B．②⑤

C．③④⑤ D．③⑥一技能訓練【分析】對特定范圍內進行修改所需的時間不超過2秒——不超過2秒是數值需求，所以屬于性能需求。按照訂單及原材料情況自動安排生產排序——訂單及原材料情況是輸入，生產排序是輸出，所以屬于功能需求。系統能夠同時支持100個獨立站點的并發訪問——100個獨立站點并發訪問是數值需求，所以屬于性能需求。系統可以實現對多字符集的支持，包括