軟工 ## 5. System modeling 1. System modeling - 是一種軟件開發方法，其中將系統表示為一組可以自動轉換為可執行代碼的模型 - now almost always based on notations - 幫助分析師了解系統的功能，模型用於與客戶溝通。 2. Models of the existing system - 在需求工程中使用。它們有助於闡明現有系統的作用，並可用作討論其優勢和劣勢的基礎。然後這些導致對新系統的要求。 3. System perspectives - An external perspective - 對系統的contex或環境進行建模 - An interaction perspective - 對系統與其環境之間或系統組件之間的交互進行建模。 - A structural perspective - 對系統的組織或系統處理數據的結構進行建模。 - A behavioral perspective - 對系統的動態行為及其回覆事件的方式進行建模。 4. The Unified Modeling Language(UML) - 是一組 13 種不同的圖表類型，可用於對軟件系統建模。 - 它源於 1990 年代面向對象建模的工作 - 主要修訂版 (UML 2) 於 2004 年完成。 5. UML diagram types - Activity diagrams - which show the activities involved in a process or in data processing. - Use case diagrams - which show the interactions between a system and its environment. - Sequence diagrams - which show interactions between actors and the system and between system components. - Class diagrams - which show the object classes in the system and the associations between these classes. - State diagrams - which show how the system reacts to internal and external events. 6. Use of graphical models - 作為促進對現有或擬議系統進行討論的一種方式 - 作為記錄現有系統的一種方式 - 作為可用於生成系統實現的詳細系統描述 7. Context models - 於說明系統的operational contex，它們顯示系統邊界之外的內容。 - Social and orgainization的考慮可能會影響系統邊界定位的決定。 - 架構模型顯示系統及其與其他系統的關係。 8. System boundaries - 為了定義什麼是系統內部的，什麼是系統外部的 - 系統邊界的位置對系統需求有深遠的影響。 9. Process perspective - 流程模型揭示了正在開發的系統如何用於更廣泛的業務流程 - activity diagram 10. Interaction models - 有助於確定用戶需求 - 突出了可能出現的通信問題。 - 有助於我們了解所提議的系統結構是否可能提供所需的系統性能和可靠性。 - Use case diagrams and sequence diagrams 12. Use case modeling - 最初是為了支持需求獲取而開發的，現在被納入 UML。 - 每個use case代表一個離散的任務，涉及與系統的外部交互。 - 用例中的參與者可以是人，也可以是其他系統。 13. Sequence diagrams - 用於模擬系統中actors和object之間的交互。 - 顯示在特定use case或use case instance期間發生的交互序列。 - 所涉及的對象和參與者列在圖的頂部，並從它們垂直繪製一條虛線。對象之間的交互由帶註釋的箭頭指示。 14. Structural models - 根據構成系統的組件及其關係來顯示系統的組織。 - 可以是靜態模型，顯示系統設計的結構，也可以是動態模型，顯示系統在執行時的組織結構。 - 在討論和設計系統架構時創建系統的結構模型。 15. Class diagrams - 顯示系統中的class以及這些class之間的關聯。 16. Generalization - 我們用來管理複雜性的日常技術。 - 不需學習我們所經歷的每個實體的詳細特徵，而是將這些實體歸入更一般的類別（動物、汽車、房屋等）並學習這些類別的特徵。 - 在object-oriented languages中，如 Java，泛化是使用語言內置的類繼承機制實現的。 - 與高層類關聯的屬性和操作也與低層類關聯。 17. Behavioral models - 系統在執行時的動態行為模型。它們顯示當系統響應來自其環境的刺激時會發生什麼或應該發生什麼。 - 一些數據到達，必須由系統處理。 - 某些事件的發生會觸發系統處理。事件可能和數據有關聯。 18. Data-driven modeling - 許多業務系統都是主要由數據驅動的數據處理系統。它們由輸入到系統的數據控制，外部事件處理相對較少。 - 顯示處理輸入數據和生成相關輸出所涉及的動作序列。 - 在需求分析期間特別有用，因為它們可用於顯示系統中的端到端處理。 19. Event-driven modeling - Real-time systems 數據處理最少。 - 事件驅動建模顯示系統如何 responds to external and internal events. 。 - 系統具有有限數量的狀態，並且事件（stimuli）可能導致從一種狀態到另一種狀態的轉變。 20. State machine models - 模擬系統responds to external and internal events.的行為。 - 顯示系統對刺激的反應，因此常用於Real-time systems建模。 - 將系統狀態顯示為節點，將事件顯示為這些節點之間的弧。當事件發生時，系統從一種狀態移動到另一種狀態。 21. Model-driven engineering(MDE) - 是一種軟件開發方法，其中model是開發過程的主要輸出。 - 從模型中自動生成在硬體/軟體平台上執行的程序。 - MDE 的支持者認為，這提高了軟件工程的抽象級別，因此工程師不必再關心編程語言細節或執行平台的細節。 22. Usage of model-driven engineering - 仍處於發展的早期階段，是否會對軟件工程實踐產生重大影響尚不清楚。 - 優點 - 允許在更高的抽象層次上考慮系統 - 自動生成代碼意味著使系統適應新平台的成本更低。 - 缺點 - 抽像模型並不一定適合實施。 - 為新平台開發翻譯器的成本可能會超過生成代碼所節省的成本。 23. Model-driven architecture - 是更通用的model-driven engineering的前身 - 一種以model為中心的軟件設計和實現方法，它使用 UML 模型的子集來描述系統。 - 創建不同抽象層次的模型。從一個高級的、獨立於平台的模型，原則上可以在沒有人工干預的情況下生成一個工作程序。 24. Three type models of MDA method - A computation-independent model (CIM) - 對系統中使用的重要領域抽象進行建模。 CIM 有時稱為領域模型。 - A platform-independent model (PIM) - 在不參考其實現的情況下對系統的操作進行建模。 PIM 通常使用顯示靜態系統結構及其如何響應外部和內部事件的 UML 模型來描述。 - Platform-specific models (PSM) - 獨立於平台的模型的轉換，每個應用程序平台都有一個單獨的 PSM。原則上，可能有 PSM 層，每一層都添加一些特定於平台的細節。 25. Agile methods and MDA - MDA 的開發人員聲稱它旨在支援迭代開發方法，因此可以在敏捷方法中使用。 - 廣泛的前期建模的概念與敏捷宣言中的基本思想相矛盾，我懷疑很少有敏捷開發人員對模型驅動工程感到滿意。 - 如果轉換可以完全自動化，並且從 PIM 生成完整的程序，那麼原則上，MDA 可以用於敏捷開發過程，因為不需要單獨的編碼。 26. Adoption of MDA - 一系列因素限制了 MDE/MDA 的採用 - 將模型從一個級別轉換到另一個級別需要專門的工具支持 - 對於使用 MDA 開發的長生命週期系統，公司不願意開發自己的工具或依賴可能倒閉的小公司 - 模型是促進軟件設計討論的好方法。然而，對討論有用的抽象可能不是對實現正確的抽象。 - 對於大多數複雜系統，實現不是主要問題——需求工程、安全性、可靠性、與遺留系統的集成和測試都更為重要。 - 平台獨立性的論點只適用於大型、長壽命系統。對於軟件產品和信息系統，使用 MDA 所節省的成本可能會被其引入和工具的成本所抵消。 - 在 MDA 發展的同一時期，敏捷方法的廣泛採用轉移了人們對模型驅動方法的注意力。 ## 6.Architectural design 1. Architectural design - 理解軟件系統應該如何組織以及設計該系統的整體結構。 - 是設計和需求工程之間的關鍵環節，因為它確定了系統中的主要結構組件以及它們之間的關係。 - 輸出是一個架構模型，它描述了系統是如何組織為一組通信組件的。 2. Software architectures at two levels of abstraction - Architecture in the small - 是單個程序的架構。在這個層面上，我們關注的是將單個程序分解為組件的方式。 - Architecture in the large - 複雜企業系統的架構，包括其他系統、程序和程序組件。這些企業系統分佈在不同的計算機上，這些計算機可能由不同的公司擁有和管理。 3. Advantages of explicit architecture - Stakeholder communication - System analysis - Large-scale reuse 4. Architectural representations - Informal block diagrams 顯示實體和關係是記錄軟件架構最常用的方法。 - 缺乏語義，沒有顯示實體之間的關係類型，也沒有顯示架構中實體的可見屬性。 - 依賴於架構模型的使用。模型語義的要求取決於模型的使用方式 5. Box and line diagrams - 非常抽象——它們不顯示組件關係的性質，也不顯示子系統的外部可見屬性。 - 對於與利益相關者的溝通和項目規劃很有用。 6. Use of architectural models - 作為促進系統設計討論的一種方式 - 因為它不會被細節搞得一團糟。利益相關者可以與之相關並理解系統的抽象視圖，而不會被細節所混淆。 - 作為記錄已設計架構的一種方式 - 目的是生成一個完整的系統模型，該模型顯示系統中的不同組件、它們的接口和它們的連接。 7. Architectural design decisions - Architectural design是一個創造性的過程，因此該過程因所開發系統的類型而異。 - 多常見的決策跨越所有設計過程，這些決策會影響系統的非功能特性。 8. Architecture reuse - 同一領域中的系統通常具有反映領域概念的相似架構。 - 應用產品線圍繞核心架構構建，具有滿足特定客戶需求的變體。 - 可以圍繞多個架構模式或“樣式”之一進行設計。 9. Architecture and non-functional requirements of the system - Performance - 關鍵操作本地化並最大限度地減少通信。 - Security - 用分層架構，關鍵資產位於內層 - Safety - 在少數子系統中定位安全關鍵特性。 - Availability - 包括冗餘組件和容錯機制。 - Maintainability - 使用fine-grain、可替換的組件 10. 4 + 1 view model of software architecture - A logical view - 將系統中的關鍵抽象顯示為objects或object classes。 - A process view - 顯示在運行時系統如何由交互進程組成 - A development view - 顯示軟體是如何分解開發的。 - A physical view - 顯示系統硬件以及軟件組件如何分佈在系統中的處理器上。 - Related using use cases or scenarios 11. Representing architectural views - 有些人認為UML是描述和記錄系統架構的適當符號 - 書作者不同意這種觀點。 UML 包括適用於高級系統描述的抽象。對於過於接近實現的對像類，架構描述沒有多大用處。 - Architectural description languages (ADLs)已經開發出來，但沒有被廣泛使用 12. Architectural patterns - Patterns是一種表示、共享和重用知識的手段。 - 是對良好設計實踐的程式化描述，已經在不同的環境中進行了嘗試和測試。 - Patterns應該包括關於何時有用和何時無用的信息。 - Patterns可以使用表格和圖形描述來表示。 13. Layered architecture - 分離和獨立的概念是架構設計的基礎，因為它們允許更改被本地化。 - 將系統組織成一組layer，每一個layer提供一組服務。 - 支持不同層次子系統的增量開發。當層界面發生變化時，只有相鄰的層受到影響。 14. Repository architecture - 子系統必須交換數據。這可以通過兩種方式完成： - 共享數據保存在中央數據庫或存儲庫中，所有子系統都可以訪問 - 每個子系統維護自己的數據庫並將數據顯式傳遞給其他子系統。 - 當需要共享大量數據時，最常用的是共享的存儲庫模型，這是一種高效的數據共享機制。 15. Client-server architecture - Distributed system model 顯示數據和處理如何分佈在一系列組件中。 - 提供打印、數據管理等特定服務的獨立服務器集合。 - 調用這些服務的客戶端集合。 - 允許客戶端訪問服務器的網絡。 16. Pipe and filter architecture - 功能轉換處理輸入以產生輸出。 - 可稱為Pipe and filter model。 - 這種方法的變體非常普遍。當轉換是順序的時，這是一個批處理順序模型，廣泛用於數據處理系統。 - 不太適合interactive system 17. Application architectures - 旨在滿足組織需要。 - 由於業務有很多共同點，他們的應用系統也往往有一個反映應用需求的通用架構。 - 通用應用程序架構是一種軟件系統的架構，可以配置和調整以創建滿足特定要求的系統。 18. Use of application architectures - As a starting point for architectural design.(作為建築設計的起點) - As a design checklist.(作為設計清單) - As a way of organizing the work of the development team.(作為組織開發團隊工作的一種方式。) - As a means of assessing components for reuse.(作為評估組件重用的一種方式。) - As a vocabulary for talking about application types.(作為談論應用程序類型的詞彙。) 19. Application type examples - 兩種使用非常廣泛的通用應用程序架構是事務處理系統和語言處理系統。 - 交易處理系統 - 電子商務系統 - 預定系統 - 語言處理系統 - 編譯器 - Command interpreters 20. Transaction processing systems - 處理用戶對數據庫信息的請求或更新數據庫的請求。 21. Information systems architecture - 具有通用架構，可以組織為分層架構。 - 基於事務的系統(transaction-based systems)，因為與這些系統的交互通常涉及數據庫事務。 - 幾乎都是基於網絡的系統，用戶界面是在網絡瀏覽器中實現的。 22. Web-based information systems - 信息和資源管理系統現在通常是基於網絡的系統，用戶界面是使用網絡瀏覽器實現的。 23. Server implementation - Web 服務器負責所有用戶通信，用戶界面使用 Web 瀏覽器實現 - 應用服務器負責實現特定於應用程序的邏輯以及信息存儲和檢索請求 - 數據庫服務器將信息移入和移出數據庫並處理事務管理。 24. Language processing systems - 接受自然或人工語言作為輸入並生成該語言的其他表示形式。 - 其他語言處理系統可能會將 XML 數據描述翻譯成查詢數據庫的命令或另一種 XML 表示形式。 - 自然語言處理系統可以將一種自然語言翻譯成另一種自然語言 25. Compiler components - A lexical analyzer - 獲取輸入語言標記並將它們轉換為內部形式。 - A symbol table - 保存著被翻譯文本中使用的實體名稱（變量、類名、對象名等）的信息 - A syntax analyzer - 檢查被翻譯語言的語法。 - A syntax tree - 是表示正在編譯的程序的內部結構。 - A semantic analyzer - 用語法樹和符號表中的信息來檢查輸入語言文本的語義正確性。 - A code genarator - 它“walks(遍歷)”語法樹並生成抽像機器碼。 ## 7.Implementation 1. Design and implementation - 軟件設計和實現是軟件工程過程中開發可執行軟件系統的階段。 - 軟件設計和實現活動是相互交織的。 - 軟件設計是一種創造性活動，您可以根據客戶的要求確定軟件組件及其關係。 - 實施是將設計實現為程序的過程。 2. Build or buy - 在廣泛的領域中，現在可以購買 off-the-shelf systems(COTS)可以根據用戶需求進行調整和定制的。 - 當您以這種方式開發應用程序時，設計過程將關注如何使用該系統的配置功能來交付系統需求。 3. An object-oriented design process - design processes involve design object classes and the interrelationships between design classes. - 這些過程中的共同活動包括 - 定義系統的使用環境和模式 - 設計系統架構 - 確定主要係統對象 - 開發設計模型 - 指定對象接口 4. System context and interactions - 了解正在設計的軟件與其外部環境之間的關係對於決定如何提供所需的系統功能以及如何構建系統以與其環境進行通信至關重要。 - 了解contex還可以讓您建立系統的邊界。設置系統邊界可幫助您決定在所設計的系統中實現了哪些功能以及在其他相關係統中實現了哪些功能。 5. Context and interaction models - A system context model是一種結構模型，它演示了正在開發的系統環境中的其他系統。 - A system interaction model是一個動態模型，顯示系統在使用過程中如何與其環境交互。 6. Architectural design - 一旦了解了系統與其環境之間的交互，您就可以使用這些信息來設計系統架構。 - 您確定構成系統的主要組件及其交互，然後可以使用架構模式（例如分層或客戶端-服務器模型）組織組件。 7. Object class identification - 識別object class通常是object oriented設計的難點。 - object identification沒有“神奇公式”。它依賴於系統設計者的技能、經驗和領域知識。 - object identification是一個迭代過程。你不太可能第一次就做對。 - 用例的描述有助於識別系統中的對象和操作。 8. Approaches to identification - 使用基於系統自然語言描述的語法方法。 - 基於應用領域中有形事物的識別。 - 使用基於場景的分析。識別每個場景中的對象、屬性和方法。 9. Design models - 顯示object和object class以及這些實體之間的關係。 - 設計模型有兩種： - Structural model從對像類和關係的角度描述系統的靜態結構。 - Subsystem model 將對象的邏輯分組顯示為連貫的子系統。 - Dynamic model描述對象之間的動態交互 - Sequence model 顯示對象交互序列 - State machine model 顯示單個對像如何響應事件改變其狀態 10. Subsystem model - 顯示設計如何組織成邏輯上相關的對象組。 - 每個子系統都使用包來表示。這是一個邏輯模型。系統中每個對象的實際內部組成可能不同。 11. State diagrams - 用於展示對像如何響應不同的服務請求以及這些請求觸發的狀態轉換。 - 是有用的系統或對象運行時行為的高級模型。 - 通常不需要係統中所有對象的狀態圖。系統中的許多對像都相對簡單，狀態模型為設計增加了不必要的細節。 12. Interface specification - 必須指定對象接口，以便可以並行設計對象和其他組件。 - 設計者應避免設計界面表示，而應將其隱藏在object本身中。 - object可能有多個接口，這些接口是對提供的方法的看法。 - UML 使用class diagram來規範接口，但也可以使用Java。 13. Design patterns - 是一種重用關於問題及其解決方案的抽象知識的方法。 - Pattern描述通常利用繼承、多態等面向對象的特性。 14. Pattern elements - Name - A meaningful pattern identifier. - Problem description. - Solution description. - Not a concrete design but a template for a design solution that can be instantiated in different ways. - Consequences - The results and trade-offs of applying the pattern. 15. The Observer pattern - Name - observer - Description - Separates the display of object state from the object itself. - Problem description - Used when multiple displays of state are needed - Solution description. - Consequences - Optimizations to enhance display performance are impractical. 16. Design problems - 要在您的設計中使用模式，您需要認識到您面臨的任何設計問題都可能有一個可以應用的關聯模式。 - 告訴幾個對像一些其他對象的狀態已經改變（Observer pattern）。 - 整理一些經常增量開發的相關對象的接口（Façade 模式） - 提供一種訪問集合中元素的標準方法，而不管該集合是如何實現的（Iterator pattern）。 - 允許在運行時擴展現有類的功能(Decorator pattern) 17. Implementation issues - 這裡的重點不是編程，儘管這顯然很重要，而是編程文本中通常沒有涉及的其他實現問題： - reuse大多數現代軟件都是通過重用現有組件或系統構建的。在開發軟件時，應該盡可能多地使用現有代碼。 - Configuration management 在開發過程中，您必須跟踪配置管理系統中每個軟件組件的許多不同版本。 - Host-target development 生產軟件通常不會與軟件開發環境在同一台計算機上執行。相反，您在一台計算機（主機系統）上開發它並在另一台計算機（目標系統）上執行它。 18. Reuse - 1960-1990 - 成本和進度壓力意味著這種方法變得越來越不可行，特別是對於商業和基於 Internet 的系統。 - 出現了一種基於現有軟件重用的開發方法，現在普遍用於商業和科學軟件。 19. Reuse levels - The abstraction level - 在這個級別，您不直接重用軟件，而是在軟件設計中使用成功抽象的知識。software. - The object level在這個級別，您可以直接重用庫中的對象，而不用自己編寫代碼。 - The component level - 組件是您在應用程序系統中重用的對象和對像類的集合。 - The system level - 在這個級別，您可以重用整個應用程序系統。 20. Reuse costs - 尋找可重複使用的軟件並評估它是否滿足您的需求所花費的時間成本。 - 在適用的情況下，購買可重用軟件的成本。對於大型現成系統，這些成本可能非常高。 - 調整和配置可重用軟件組件或系統以反映您正在開發的系統的要求的成本。 - 將可重用軟件元素相互集成（如果您使用來自不同來源的軟件）以及與您開發的新代碼的成本。 21. Configuration management - 是管理不斷變化的軟件系統的一般過程的名稱。 - 目的是支持系統集成過程，使所有開發人員能夠以受控的方式訪問項目代碼和文檔，找出所做的更改，並編譯和鏈接組件以創建系統。 22. Configuration management activities - Version management - 其中提供支持以跟踪軟件組件的不同版本。 - System integration - 提供支持以幫助開發人員定義使用哪些版本的組件來創建系統的每個版本。 - Problem tracking, - 提供支持以允許用戶報告錯誤和其他問題，並允許所有開發人員查看誰在處理這些問題以及何時修復這些問題。 - Release management - 向客戶發佈軟件系統的新版本。 23. Host-target development - 大多數軟件是在一台計算機（主機）上開發的，但運行在另一台機器（目標）上。 24. Development platform tools - 集成的編譯器和語法制導編輯系統，允許您創建、編輯和編譯代碼。 - 語言調試系統。 - 圖形化編輯工具，如編輯UML模型的工具。 - 測試工具，如Junit，可以自動對新版本的程序運行一組測試。 - 支持重構和程序可視化的工具。 - 配置管理工具，用於管理源代碼版本以及集成和構建系統.. 25. Integrated development environments (IDEs) - 軟件開發工具通常被分組以創建集成開發環境（IDE） - IDE 是一組軟件工具，在一些通用框架和用戶界面內支持軟件開發的不同方面。 - 創建 IDE 以支持使用特定編程語言（例如 Java）進行開發。語言 IDE 可以是專門開發的，也可以是具有特定語言支持工具的通用 IDE 的實例。 26. Component/system deployment factors - The hardware and software requirements of a component: 如果組件是為特定硬件架構設計的，或者依賴於其他軟件系統，則顯然必須將其部署在提供所需硬件和軟件支持的平台上. - The availability requirements of the system:高可用性系統可能需要組件部署在多個平台上。這意味著，在平台出現故障的情況下，可以使用該組件的替代實現 - Component communications:如果組件之間存在高水平的通信流量，通常將它們部署在同一平台或物理上彼此靠近的平台上是有意義的。這減少了一個組件發送消息和另一個組件接收消息的時間之間的延遲。 27. Open source development - 開源開發是一種軟件開發方式，公開軟件系統的源代碼，並邀請志願者參與開發過程。源代碼不應該是專有的，而是應該始終可供用戶根據需要檢查和修改。 - 開源軟件通過使用 Internet 招募更多的志願開發人員來擴展這種想法。他們中的許多人也是代碼的用戶。 28. Open source systems - 最著名的開源產品當然是 Linux 操作系統，它被廣泛用作服務器系統，並且越來越多地用作桌面環境。 - 其他重要的開源產品有 Java、Apache 網絡服務器和 mySQL 數據庫管理系統。 29. Open source issues - 正在開發的產品是否應該使用開源組件？ - 軟件開發是否應該採用開源方式？ 30. Open source business - 越來越多的產品公司正在使用開源方法進行開發。 - 他們的商業模式不依賴於銷售軟件產品，而是依賴於銷售對該產品的支持。 - 他們認為，開放源代碼社區的參與將使軟件的開發成本更低、速度更快，並將為軟件創建一個用戶社區。 31. Open source licensing - 開放源代碼開發的一個基本原則是源代碼應該是免費的，這並不意味著任何人都可以使用該代碼為所欲為。 - 從法律上講，代碼的開發者（公司或個人）仍然擁有代碼。他們可以通過在開源軟件許可證中包含具有法律約束力的條件來限制它的使用方式。 - 一些開源開發人員認為，如果使用開源組件開發新系統，那麼該系統也應該是開源的。 - 其他人願意允許不受此限制地使用他們的代碼。開發的系統可能是專有的並作為封閉源系統出售。 32. License models - GNU General Public License (GPL)。這是所謂的“互惠”許可，這意味著如果您使用根據 GPL 許可獲得許可的開源軟件，那麼您必須將該軟件開源。 - GNU Lesser General Public License (LGPL) 是 GPL 許可證的變體，您可以在其中編寫鏈接到開源代碼的組件，而無需發布這些組件的源代碼。 - The Berkley Standard Distribution (BSD)許可證。這是一個非互惠許可，這意味著您沒有義務重新發布對開源代碼所做的任何更改或修改。您可以將代碼包含在出售的專有系統中。 33. License management - 建立開源組件下載使用信息維護系統。 - 了解不同類型的許可，並了解組件在使用前如何獲得許可。 - 了解組件的演化路徑。 - 對人們進行開源教育 - 建立審計製度。 - 參與開源社區。 ## 8.Testing 1. Program testing - 測試的目的是表明一個程序做了它應該做的事情，並在投入使用之前發現程序缺陷。 - 測試軟件時，您使用人工數據執行程序。 - 您檢查測試運行的結果是否有錯誤、異常或有關程序非功能屬性的信息。 - 您忽略的測試總是有可能發現系統的更多問題。 2. Program testing goals - 向開發人員和客戶證明軟件滿足其要求。(validation testing) - 發現軟件行為不正確、不受歡迎或不符合其規範的情況。(defect testing) 3. Validation and defect testing - The first goal leads to validation testing - 您希望系統使用一組反映系統預期用途的給定測試用例正確執行。 - The second goal leads to defect testing - 測試用例旨在暴露缺陷。缺陷測試中的測試用例可以故意模糊，不需要反映系統的正常使用情況。 4. Verification vs validation - Verification: - "Are we building the product right”. - 軟件應符合其規範 - Validation: - "Are we building the right product”. - 軟件應該做用戶真正需要的 5. V & V confidence - 目的是建立系統“適合目的”的信心。取決於系統的用途、用戶期望和營銷環境 - Software purpose - 可信度取決於軟件對組織的重要性。 - User expectations - 用戶可能對某些類型的軟件期望較低。 - Marketing environment - 儘早將產品推向市場可能比發現程序中的缺陷更重要。 6. Inspections and testing - 軟件檢查 關注靜態系統表示的分析以發現問題（static verification） - 可以通過基於工具的文檔和代碼分析來補充。 - 軟件測試 關注執行和觀察產品行為(dynamic verification) - 系統使用測試數據執行並觀察其運行行為。 7. Advantages of inspections - 在測試過程中，錯誤可以掩蓋（隱藏）其他錯誤。因為檢查是一個靜態過程，所以您不必關心錯誤之間的交互。 - 可以檢查系統的不完整版本，無需額外費用。如果程序不完整，則需要開發專門的測試工具來測試可用的部分。 - 除了尋找程序缺陷，檢查還可以考慮程序更廣泛的質量屬性，例如符合標準、可移植性和可維護性 8. Stages of testing - Development testing, - 在開發過程中對系統進行測試以發現錯誤和缺陷。 - Release testing - 一個獨立的測試團隊在系統發布給用戶之前測試一個完整的版本。 - User testing - 系統的用戶或潛在用戶在自己的環境中測試系統。 9. Development testing - 開發測試包括由開發系統的團隊執行的所有測試活動。 - unit testing - 測試單個程序單元或對像類。單元測試應該側重於測試對像或方法的功能。 - component testing - 其中集成了多個單獨的單元以創建複合組件。組件測試應側重於測試組件接口。 - system testing - 系統中的部分或全部組件被集成，系統作為一個整體進行測試。系統測試應側重於測試組件交互。 10. Unit testing - 單獨測試單個組件的過程。 - 這是一個缺陷測試過程。 - 當你測試對像類時，你應該設計你的測試來覆蓋對象的所有特性： - 測試與對象相關的所有操作 - 設置並檢查與對象關聯的所有屬性的值。 - 將對象置於所有可能的狀態。這意味著您應該模擬所有導致狀態更改的事件 11. Automated testing - 只要有可能，單元測試就應該自動化，以便在沒有人工干預的情況下運行和檢查測試。 - 在自動化單元測試中，您使用測試自動化框架（例如 JUnit）來編寫和運行您的程序測試。 - 單元測試框架提供了通用的測試類，您可以擴展這些類來創建特定的測試用例。然後，他們可以運行您已實施的所有測試，並通常通過某些 GUI 報告測試是否成功。 12. Automated test components - A set part 您可以在其中使用測試用例（即輸入和預期輸出）初始化系統。 - A call part 調用待測對像或方法。 - A assertion part 您可以在其中將調用結果與預期結果進行比較。如果斷言評估為真，則測試成功，如果為假，則測試失敗。 13. Choosing unit test cases - 這裡的“有效”意味著兩件事： - 測試用例應該表明，在正常使用條件下，被測組件應該做它應該做的事情。 - 如果組件有缺陷，應該從測試用例中明顯看出。 - 首先是反映程序運行正常，顯示元件工作正常。 - 根據測試經驗，針對出現頻率最高的問題測試另一個測試用例。示例包括故意使用不正確的輸入來測試程序是否正確處理它們而不會導致設備崩潰 14. Testing strategies - Partition testing 您可以在其中識別具有共同特徵且應以相同方式處理的輸入組。 - 您應該從每個組中選擇測試。 - Guideline-based testing 您使用測試指南來選擇測試用例。 - 這些指南反映了程序員在開發組件時經常犯的各種錯誤的以往經驗。 15. Partition testing - 程序的輸入數據和輸出結果通常可以根據一些共同的特徵分為幾組。 - 因為它們具有相同的行為，所以這些類有時被稱為等價分區或域 - 輸出的等價劃分是具有共同屬性的程序輸出。 - 識別出幾組分區後，就可以從這些分區中選取測試用例。 16. Testing guidelines (sequences) - 使用只有一個值的序列測試軟件。 - 在不同的測試中使用不同大小的序列。 - 派生測試，以便訪問序列的第一個、中間和最後一個元素。 17. General testing guidelines - 選擇強制系統生成所有錯誤消息的輸入 - 設計導致輸入緩衝區溢出的輸 - 多次重複相同的輸入或一系列輸入 - 強制生成無效輸出 - 強制計算結果太大或太小。 18. Component testing - 軟件組件通常是由多個交互對象組成的複合組件。 - 例如，在氣象站系統中，重新配置組件包括處理重新配置各個方面的對象。 - 您通過定義的組件接口訪問這些對象的功能。 - 因此，測試複合組件應該側重於顯示組件接口的行為符合其規範。 - 您可以假設已完成組件內各個對象的單元測試。 19. Interface testing - 目標是檢測由於接口錯誤或關於接口的無效假設引起的故障。 - Interface type - Parameter interfaces 數據從一種方法或過程傳遞到另一種方法或過程。 - Shared memory interfaces 內存塊在過程或函數之間共享。 - Procedural interfaces 子系統封裝了一組過程，供其他子系統調用。 - Message passing interfaces 消息傳遞接口子系統向其他子系統請求服務 20. Interface errors - Interface misuse - 調用組件調用另一個組件並在使用其接口時出錯，例如參數順序錯誤。 - Interface misunderstanding - 調用組件嵌入了關於被調用組件行為的不正確的假設。 - Timing errors - 被調用組件和調用組件運行速度不同，訪問的信息過時。 21. Interface testing guidelines - 設計測試，使被調用過程的參數處於其範圍的極端。 - 總是用空pointer測試pointer參數。 - 設計導致組件失效的測試。 - 在消息傳遞系統中使用壓力測試。 - 在共享內存系統中，改變組件被激活的順序。 22. System testing - 開發過程中的系統測試包括集成組件以創建系統版本，然後測試集成系統。 - 系統測試的重點是測試組件之間的交互。 - 系統測試檢查組件是否兼容，並在正確的時間跨接口傳輸正確的數據。 - 系統測試測試系統的緊急行為。 23. System and component testing - 系統測試與組件測試明顯重疊，但有兩個重要區別： - 在系統測試過程中，單獨開發的可重用組件和現成的系統可能會與新開發的組件集成。然後測試完整的系統。 - 由不同團隊成員或子團隊開發的組件可以在此階段集成。系統測試是一個集體而非個人的過程。 - 在一些公司，系統測試可能涉及獨立的測試團隊，沒有設計人員和程序員的參與。 24. Use-case testing - 為識別系統交互而開發的用例可以用作系統測試的基礎。 - 每個用例通常涉及多個系統組件，因此測試用例會強制發生這些交互。 25. Test cases derived from sequence diagram - 報告請求的輸入應該有相關的確認。最終應從請求中返回報告。 - 您應該創建可用於檢查報告是否正確組織的匯總數據。 - 向 WeatherStation 發送報告的輸入請求會生成匯總報告。 - 可以通過創建與您為 SatComms 測試準備的摘要相對應的原始數據並檢查 WeatherStation 對像是否正確生成此摘要來進行測試。此原始數據還用於測試 WeatherData 對象。 26. Testing policies - 詳盡的系統測試是不可能的，因此可以製定定義所需系統測試覆蓋率的測試策略。 - Examples of testing policies: - 應測試通過菜單訪問的所有系統功能。 - 必須測試通過同一菜單訪問的功能組合（例如文本格式化）。 - 在提供用戶輸入的情況下，必須使用正確和錯誤的輸入來測試所有功能。 27. Test-driven development - (TDD) 是一種程序開發方法，您可以在其中交替進行測試和代碼開發。 - 測試先於代碼編寫，“通過”測試是開發的關鍵驅動力。 ² - 逐步開發代碼，並針對該增量進行測試。在您開發的代碼通過測試之前，您不會繼續進行下一個增量。 - TDD 是作為敏捷方法（例如極限編程）的一部分引入的。但是，它也可以用於計劃驅動的開發過程。 28. TDD process activities - 首先確定所需的功能增量。這通常應該很小並且可以用幾行代碼實現。 - 為此功能編寫測試並將其實現為自動化測試。 - 運行測試，連同所有其他已實施的測試。最初，您沒有實現該功能，因此新測試將失敗。 - 實現功能並重新運行測試。 - 一旦所有測試都成功運行，您就可以繼續實現下一個功能塊 29. Benefits of test-driven development - Code coverage - 您編寫的每個代碼段都至少有一個相關的測試，因此所有編寫的代碼都至少有一個測試。 - Regression testing - 回歸測試套件隨著程序的開發而逐步開發。 - Simplified debugging - 當測試失敗時，問題所在應該很明顯。新寫的代碼需要檢查和修改。 - System documentation - 測試本身是一種文檔形式，描述了代碼應該做什麼。 30. Regression testing - 回歸測試正在測試系統以檢查更改是否沒有“破壞”以前的工作代碼。 - 在手動測試過程中，回歸測試成本高昂，但通過自動化測試，它簡單明了。每次對程序進行更改時，都會重新運行所有測試。 - 在提交更改之前，測試必須“成功”運行。 31. Release testing - 發布測試是測試系統的特定版本的過程，該版本旨在供開發團隊以外的人使用。 - 發布測試過程的主要目標是說服系統的供應商它足夠好可以使用。 - 因此，發布測試必須表明系統提供了其指定的功能、性能和可靠性，並且在正常使用期間不會出現故障。 - 發布測試通常是一個黑盒測試過程，測試僅從系統規範中導出。 31. Release testing and system testing - 發布測試是系統測試的一種形式。 - 重要區別： - 一個沒有參與系統開發的獨立團隊，應該負責發布測試。 - 開發團隊進行的系統測試應側重於發現系統中的錯誤（缺陷測試）。發布測試的目的是檢查系統是否滿足其要求並且足以供外部使用（驗證測試）。 32. Requirements based testing - 基於需求的測試涉及檢查每個需求並為其開發一個或多個測試。 - 如果已知患者對任何特定藥物過敏，則該藥物的處方應導致向系統用戶發出警告消息。 ▪ 如果處方者選擇忽略過敏警告，他們應提供忽略的原因。 33. Requirements tests - 建立沒有已知過敏症的患者記錄。為已知存在的過敏症開藥。檢查系統是否發出警告消息 - 建立已知過敏的病歷。開出患者過敏的藥物，並查看系統是否發出警告。 - 建立病歷，記錄對兩種或兩種以上藥物的過敏情況。分別開出這兩種藥物的處方，並檢查是否針對每種藥物發出了正確的警告。 - 開兩種患者過敏的藥物。檢查是否正確發出了兩個警告。 - 開出發出警告並否決該警告的藥物。檢查系統是否要求用戶提供信息來解釋警告被否決的原因。 34. Features tested by scenario - 登錄系統認證。 - 將指定的患者記錄下載和上傳到筆記本電腦。 - 家訪安排。 - 在移動設備上對患者記錄進行加密和解密。 - 記錄檢索和修改。 - 與維護副作用信息的藥物數據庫鏈接。 - 來電提示系統。 35. Performance testing - 發布測試的一部分可能涉及測試系統的緊急屬性，例如性能和可靠性。 - 測試應反映系統的使用概況。 - 性能測試通常包括規劃一系列測試，其中負載穩步增加，直到系統性能變得不可接受。 - 壓力測試是性能測試的一種形式，系統故意超載以測試其故障行為。 36. User testing - 用戶或客戶測試是測試過程中的一個階段，用戶或客戶在該階段提供有關係統測試的輸入和建議。 - 用戶測試是必不可少的，即使已經進行了全面的系統和發布測試。 - 原因是用戶工作環境的影響對系統的可靠性、性能、可用​​性和健壯性有重大影響。這些無法在測試環境中復制。 37. Types of user testing - Alpha testing 軟件用戶與開發團隊合作，在開發人員現場測試軟件。 - Beta testing 向用戶提供軟件版本，允許他們進行試驗並向系統開發人員提出他們發現的問題。 - Acceptance testing 客戶測試一個系統，以確定它是否準備好被系統開發人員接受並部署在客戶環境中。主要用於定制系統。 38. Agile methods and acceptance testing - 在敏捷方法中，用戶/客戶是開發團隊的一部分，負責就係統的可接受性做出決策。 - 沒有單獨的驗收測試過程。 - 測試由用戶/客戶定義，並與其他測試集成在一起，因為它們會在進行更改時自動運行。 - 這裡的主要問題是嵌入式用戶是否是“典型”的，是否能夠代表所有系統利益相關者的利益。