1、軟件測試軟件學院 內容提綱You are here!你在這兒！軟件測試基礎測試的概念與原則、測試文檔軟件測試活動軟件測試技術黑盒測試與白盒測試等價類劃分、邊界值分析路徑測試、基于狀態的測試面向對象的測試2驗證與確認 驗證與確認的基本概念與活動模型 靜態方法：走查、檢查 基本術語錯誤（Error）錯誤是指導致系統可能包含故障的人的行為，如輸入錯誤、需求錯誤、設計錯誤等。缺陷（Defect，Bug）缺陷是錯誤的表現，包括過錯缺陷和遺漏缺陷。故障（Fault）故障是指系統的規格說明與其行為之間的偏差，通常由一個或多個缺陷引起。3 基本術語驗證（Verification）我們是否在正確地？軟件驗證試圖

2、證明在軟件生存周期的各個階段，軟件或中間確性。是否能夠滿足客戶需求，包括一致性、完整性和正確認（Validation）我們是否在正確的？軟件確認的目的是保證所開發的最終軟件的需求。能夠符合用戶說明：驗證強調對于過程的檢驗，確認強調對于結果的檢驗。4 軟件錯誤或缺陷軟件錯誤（或軟件缺陷）的表現軟件未達到軟件出現了說明書標明的功能；說明書指明出現的錯誤；軟件功能超出了軟件未達到說明書指明的范圍；說明書雖未指出但應達到的目標；軟件測試認為軟件難以理解、不易使用、運行速度緩慢、或者最終用戶不滿意。有錯是軟件的屬性，而且是無法改變的。因此，關鍵在于如何避免錯誤的產生和消除已經產生的錯誤，使程序中的錯誤密

3、度達到盡可能低的程度。5 驗證與確認錯誤修復錯誤錯誤缺陷錯誤缺陷故障缺陷6 這是什么？7 錯誤的狀態8 算法錯誤9 機械錯誤10 處理錯誤或缺陷：驗證？11 處理錯誤或缺陷：冗余？12 處理錯誤或缺陷：特性？13 處理錯誤或缺陷：補丁？14 處理錯誤或缺陷：測試？15 另一種觀點錯誤預防（在系統發布之前實施）使用好的程序設計方法來減少復雜性使用版本來防止系統的不一致應用驗證技術來防止算法錯誤錯誤檢測（運行時實施）的方式發現錯誤測試：以事先調試：假設從意外故障著手可以找到錯誤：狀態信息，發現性能錯誤錯誤恢復（一旦系統發布后出現錯誤時實施）數據庫系統：提供從故障中恢復的基本事務處理模塊冗余：將不止

4、一個組件分配執行同一個操作恢復程序：該程序處理錯誤信息，使系統從故障中恢復過來16 驗證與確認的活動模型17 驗證與確認的活動模型需求分析與規格說明階段用例表示待的場景，有助于建立完整的系統，可以用于在后續的實現階段生成測試用例；形式化方法（如狀態機）可以自動地檢驗一致性和完整性等 特性；需求檢查、需求評審、原型方法設計階段斷言、抽象數據類型、契約設計等是詳細設計的驗證工具設計走查、設計檢查、設計評審18 驗證與確認的活動模型軟件實現階段軟件測試是一種主要的驗證與確認工具代碼走查、代碼檢查、代碼評審動態工具（如斷言的動態）驗證與確認的方式靜態方法：通過人工分析或程序正確性證明的方式來確認程序的

5、正確性，包括走查、檢查等方法；動態方法：通過動態分析和程序測試來檢查程序執行狀態，以確認程序是否有問題。19 評審評審（Review）評審是由若干開發、項目經理、測試、用戶或領域等組成一個會審小組，通過閱讀、討論和爭議，對工作 制品進行靜態分析的過程。類型：需求評審、設計評審和代碼評審。評審過程小組提前把需求規格說明、設計說明或程序代碼及有關要求、規范等分發給小組成員，作為評審的依據；在充分閱讀有關材料后召開評審會議，主要開發進行講解，其他成員提出問題并展開討論，是否錯誤；評審小組形成評審的報告。20 走查走查（Walkthrough）走設計或編程組成一個走查小組，通過閱讀一段文檔或代碼，并進

6、行提問和討論，從而發現可能的缺陷、遺漏和的地方。類型：設計走查、代碼走查。走查過程與評審過程類似，即先把材料先發給走查小組每個成員，讓他們認真研究程序，然后再開會；與評審的區別：評審通常是簡單地讀程序或對照錯誤檢查表進行檢查；走機運行一遍，并是按照所提交的測試用例，人工模仿計算跟蹤情況。21 走查走開發者的一次友好的會議，需要仔細，并有明確的目的、日程、持續時間和參與，許多小組以為走查。走幾天：召集人將收集的一些要在會上的材料（模型、文檔、程序代碼等）分發給參與者，參與者研究這些材料并在會議之前提交意見。會議期間：召集人提出大家的意見并對每一項進行討論。會議時間比較短，一般 23 小時。會議的

7、目的是查明問題，而不是干擾開發者。會議的思想是確認問題的，甚至不必去謀求問題的解決。進行解決。會后：將問題分發給相應22 檢查檢查（Inspection）檢一些經過嚴格訓練的根據評估標準，對于開發過程中的或中間制品進行檢查，發現其中的錯誤。檢查一般是按規定程序和時間計劃進行的，參與者來自開發、測試、質量保證或用戶，以37人組成小組。檢查過程檢查遵循一個嚴格的過程，標準；經過培訓，檢查過程有評估檢查過程包括計劃、會議準備、會議召開、修改錯誤、問題跟蹤等環的是獲得項目管理和質量評估的數據，并改進檢查過程本身。23 檢查檢查也是一次友好會議但要在項目管理的密切監督下完成，其目的是識別故障、驗證它們是

8、否真的失效、這些故障點并安排何時及由解決。檢查之前：可能需要安排一個較短的信息通報會，一般在檢之前一個召開。在信息通報會上，由檢查的開發者先一下主題，而且檢查材料要在通報會期間或之前交給參與者。檢議：識別、軟件故障并記下個數。會議之后：召集者要做好故障日志，驗證這些故障是否已經解決，并決定是否需要進一步檢查。24 內容提綱驗證與確認驗證與確認的基本概念與活動模型靜態方法：走查、檢查You are here!你在這兒！軟件測試技術黑盒測試與白盒測試等價類劃分、邊界值分析路徑測試、基于狀態的測試面向對象的測試25 軟件測試的概念測試的定義傳統：測試是一種旨在評估一個程序或系統的屬性或能力，確定它是

9、否符合其所需結果的活動。Myers：測試是為了發現錯誤而IEEE：測試是使用人工和自動個程序或系統的過程。來運行或檢測某個系統的過程，其目的在于檢驗系統是否滿足規定的需求或弄清預期結果與實際結果之間的差別。測試的目的測試是為了證明程序有錯，而不是證明程序無錯誤；一個好的測試用例在于能夠發現至今未發現的錯誤；一個的測試是發現了至今未發現的錯誤的測試。26 軟件測試的概念對待軟件測試的態度從用戶的角度出發 普遍希望通過軟件測試軟件中隱藏的錯誤和缺陷，以考慮是否可接受該。從軟件開發者的角度出發 希望測試成為表明軟件中不錯誤的過程，驗證該軟件已正確地實現了用戶的要求，確立人們對軟件質量的信心。一種正確

10、的態度發現錯誤時關注于改正錯誤，而不是埋怨具體的開發。27 軟件測試的概念軟件測試的原則應當把“盡早地和不斷地測試”作為軟件開發者的座右銘程序員應避免檢查的程序設計測試用例時，應包括合理的輸入和不合理的輸入，以及各種邊界條件，特殊情況下要充分注意測試中的群集現象對測試錯誤結果一定要有一個確認過程狀態和意外狀態制定嚴格的測試計劃，排除測試的隨意性注意回歸測試的關聯性，往往修改一個錯誤會引起錯誤妥善保存一切測試過程文檔，測試重現往往要靠測試文檔28 軟件測試文檔測試計劃（Test Plan）測試計劃是測試工作的指導性文檔，規定測試活動的范圍、方法、和進度；明確正在測試的項目、要測試的特性、要執行的

11、測試任務、每個任務的風險。，以及與計劃相主要內容：測試目標、測試方法、測試范圍、測試試環境和工具、測試體系結構、測試進度表、測舉例：Test Plan for VS.NET Speech SDK Beta129 軟件測試文檔測試規范（Test Specification）測試規范是從整體上規定測試案例的運行環境、測試方法、生成步驟、執行步驟以及調試和驗證的步驟。 主要內容：系統運行環境、總體測試方法、測試用例的生成步驟、測試用例的執行步驟、調試和驗證舉例：Test Specification for VS.NET Speech SDK Beta130 軟件測試文檔測試用例（Test Case）

12、測試用例是數據輸入和期望結果組成的對，其中“輸入”是對被測軟件接收外界數據的描述，“期望結果”是對于相應輸入軟件 應該出現的輸出結果的描述，測試用例還應明確指出使用具體測試案例產生的測試程序的任何限制。測試用例可以被組織成一個測試系列，即為實現某個特定的 測試目的而設計的一組測試用例。例如，一部分測試用例用來測試系統的兼容性，另一部分是用來測試系統在特定的環境中，系統的典型應用是否能夠很好地。舉例：Test Case for VS.NET Speech SDK Beta131 軟件測試文檔缺陷報告 （Bug Report）缺陷報告是編寫在需要，簡而言之，就是研究的測試過程期間發生的任何軟件缺陷

13、。主要內容：缺陷編號、題目、狀態、提出、解決、所屬項目、測試環境、缺限報告步驟、期待結果、附件在報告缺陷時，一般要講明缺陷的嚴重性和優先級。嚴重性表示軟件的惡劣程度，反映其對和用戶的影響。優先級表示修復缺陷的重要程度和應該何時修復。舉例：Bug Report for VS.NET Speech SDK Beta132 軟件測試Professional TesterProgammertoo familiar with codeAnalystTest TeamSystem DesignerUserConfiguration Management Specialist33軟件測試的綜合素質能力理想的

14、測試必須能與測試涉及到的所有人，具有與技）的交流能力。術移情能力（開發者）和（客戶、管理和系統開發有所有（用戶、開發者、管理者）都處于一種既關心又擔心的狀態中。測試必須和每一類人打交道，因此需要對每一類人都具有足夠的理解和同情，從而將測試與相關人員之間的技術能力和對抗減少到最低程度。一個測試必須既明白被測軟件系統的概念又要會使用工程中的那些工具，最好有幾年以上的編程經驗，從而有助于對軟件開發過程的較深入理解。34軟件測試的綜合素質自信心開發指責測試出了錯是常有的事，測試必須對的觀點有足夠的自信心。外交能力當你告訴他出了錯時，就必須使用一些外交方法，機智老練和外交手法有助于維護與開發幽默感之間的

15、協作關系。在遇到狡辯的情況下，一個幽默的批評將是很有幫助的。很強的記憶力理想的測試應該有能力將以前曾經遇到過的類似的錯誤從記憶深處挖掘出來，這一能力在測試過程中的價值是無法衡量的。35軟件測試的綜合素質耐心一些質量保證工作需要難以置信的耐心，有時你需要花費驚人的時間去分離、識別和分派一個錯誤。懷疑精神開發會盡他們最大的努力將所有的錯誤解釋過去，測式必每個人的說明，但他必須保持懷疑直到他自我督促看過以后。干測試工作很容易使你變得懶散，只有那些具有自我督促能力的人才能夠使洞察力每天正常地工作。一個好的測試具有“測試是為了破壞”的觀點，捕獲用戶觀點的能力，強烈的質量追求，對細節的關注能力。36 軟件

16、測試活動Subsystem CodeUnit TestTested SubsystemSystem Design SpecificationRequirement SpecificationSubsystem CodeUnit TestUser ManualTested SubsystemIntegration TestFunctional TestIntegrated SubsystemsFunctioning SystemTested SubsystemSubsystem CodeUnit Test37 軟件測試活動Functioning SystemValidated SystemAcc

17、epted SystemPerformance TestAcceptance TestInstallation TestUsable SystemSystem in Use38 軟件測試的 V 模型39 單元測試單元測試（Unit Testing）單元測試是對軟件基本組成單元進行的測試，有時也稱“組件測試”。單元測試一般由編寫該單元代碼的開發執行，該負責設計和運行一系列的測試以確保該單元符合需求。單元測試的目的驗證代碼是與設計相符的跟蹤需求和設計的實現發現設計和需求中的錯誤發現在編碼過程中引入的錯誤40 單元測試單元測試分析模塊接口局部數據結構出錯處理單元測試路徑邊界條件41 單元測試單元測試

18、環境驅動模塊：模擬被測模塊的上一級模塊樁模塊：模擬被測單元需調用的其他函數接口 單元測試的動態環境：生成測試數據測試結果被測單元樁模塊 2樁模塊 342 單元測試：Junit43 集成測試集成測試（Integration Testing）集成測試是在單元測試的基礎上，將所有模塊按照總體設計的要求組裝成為子系統或系統進行的測試。集成測試的對象是模塊間的接口，其目的是找出在模塊接口 上，包括系統體系結構上的問題。集成測試策略基于層次的集成：自頂上下與自底向上基于功能的集成：按照功能的優先級逐步將模塊加入系統中 基于進度的集成：把最早可獲得的代碼進行集成基于使用的集成：通過類的使用關系進行集成44

19、系統測試系統測試（System Testing）系統測試是將已經集成好的軟件系統作為一個元素，與計算機硬件、外設、某些支持軟件、數據和等其他元素結合在一起，在實際運行環境下進行的一系列測試。系統測試方法功能測試、協議一致性測試性能測試、測試、容量測試、安全性測試、恢復測試備份測試、GUI 測試、健壯性測試、兼容性測試、可用性測試安裝測試、文檔測試、測試、數據轉換測試45 系統測試功能測試（Functional Testing）功能測試是系統測試中最基本的測試，它不管軟件內部的實現邏輯，主要根據軟件需求規格說明和測試需求列表，驗證 的功能實現是否符合需求規格。功能測試主要發現以下錯誤：是否有不正

20、確或遺漏的功能？功能實現是否滿足用戶需求和系統設計的隱藏需求？ 能否正確地接受輸入？能否正確地輸出結果？常用的測試技術 黑盒測試方法：等價類劃分、邊界值測試46 系統測試測試（Press Testing）測試是檢查系統在超負荷情況下的表現，特別是對系統的處理時間有什么影響。測試的例子對于一個固定輸入速率（如每分鐘 120 個單詞）的單詞處理響應時間在一個非常短的時間內引入超負荷的數據容量成千上萬的用戶在同一時間從網上登錄到系統引入需要大量內存的操作測試采用邊界值和錯誤猜測方法，且需要工具的支持。47 系統測試安全性測試（Security Testing）安全性測試檢查系統對安全性測試期間，測試

21、侵入的防范能力。假扮者，采用各種辦法試圖防線。安全性測試的例子想方設法截取或破譯口令專門定做軟件破壞系統的保護機制故意導致系統失敗，企圖趁恢復之機進入試圖通過瀏覽非數據，推導所需信息48 系統測試恢復測試（Recovery Testing）恢復測試是檢驗系統從軟件或者硬件失敗中恢復的能力，即采用各種人工干預方式使軟件出錯，而不能正常工作，從而 檢驗系統的恢復能力。恢復性測試的例子當供電出現問題時的恢復恢復程序的執行對選擇的文件和數據進行恢復恢復處理日志方面的能力通過切換到一個并行系統來進行恢復49 系統測試 GUI 測試（Graphic User Interface Testing）GUI 測

22、試一是檢查用戶界面實現與設計的符合情況，二是確認用戶界面處理的正確性。GUI 測試提倡界面與功能的設計分離，其重點關注在界面層和界面與功能接口層上。GUI 自動化測試工具 WinRunner，QARun，QARobot，Visual Test常用的測試技術 等價類劃分、邊界值分析、基于狀態圖方法、錯誤猜測法50 系統測試安裝測試（Installation Testing）系統驗收之后，需要在目標環境中進行安裝，其目的是保證應用程序能夠被安裝測試應考慮地安裝。應用程序是否可以應用程序是否可以地安裝在以前從未安裝過的環境中？地安裝在以前已有的環境中？配置信息定義正確嗎？考慮到以前的配置信息嗎？ 文

23、檔安裝正確嗎？安裝應用程序是否會影響其他的應用程序嗎？安裝程序是否可以檢測到的情況并做出適當的反應？51 驗收測試驗收測試（Acceptance Testing）驗收測試是以用戶為主的測試，一般使用用戶環境中的實際數據進試。在測試過程中，除了考慮軟件的功能和性能外，還應對軟件的兼容性、可維護性、錯誤的恢復功能等進行確認。測試與測試測試與測試是在正式發布前經常進行的兩種測試； 測試是由用戶在開發環境下進行的測試； 測試是由軟件的多個用戶在實際使用環境下進行的測試。問題：微軟公司如何進行其的測試？52 回歸測試回歸測試（Regression Testing）回歸測試是驗證對系統的變更沒有影響以前的

24、功能，并且保證當前功能的變更是正確的。回歸測試可以發生在軟件測試的任何階段，包括單元測試、集成測試和系統測試，其令人煩惱的勞動。回歸測試應考慮的因素 范圍：有選擇地執行以前的測試用例；在于頻繁的重復性 自動化：測試程序的自動執行和自動配置、測試用例的管理和自動輸入、測試結果的自動和比較、測試結論的自動輸出。53 內容提綱驗證與確認驗證與確認的基本概念與活動模型靜態方法：走查、檢查軟件測試基礎測試的概念與原則、測試文檔軟件測試活動You are here!你在這兒！54 黑盒測試黑盒測試（Black Box Testing）又稱功能測試，它將測試對象看做一個黑盒子，完全不考慮程序內部的邏輯結構和

25、內部特性，只依據程序的需求規格說 明書，檢查程序的功能是否符合它的功能說明。問題：用黑盒測試發現程序中的錯誤，必須在所有可能的輸 入條件和輸出條件中確定測試數據，來檢查程序是否生正確的輸出，但這是不可能的。55 白盒測試白盒測試（White Box Testing）又稱結構測試，它把測試對象看做一個透明的盒子，它測試利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進試。問題：對一個具有多重選擇和循環嵌套的程序，不同的路徑數目可能是天文數字。56 等價類劃分等價類劃分等價類劃分是黑盒測試技術，可將測試用例數量降到最少。等價類劃分是將可能的輸入劃分成若干等價的類，每一個類

26、選擇一個測試用例，這種方法假設對于一個類的所有成員來 說，系統通常按照類似的方式運行。關鍵步驟：確定等價類和選擇測試輸入基本原則：每個可能的輸入屬于某一個等價類任何輸入都屬于多個等價類用等價類的某個成員作為輸入時，如果證明執行誤差，那么用該類的任何其他成員作為輸入，也能檢查到同樣的誤差。57 邊界值分析邊界值分析邊界值分析是等價類測試的特例，主要是考慮等價類的邊界條件，在等價類的“邊緣”選擇元素。在 R1, R2 的取值區間中，應如何選擇？等價類與邊界測試的缺點沒有考慮測試輸入數據的組合，在很多情況下程序出現故障是因為某些值的組合引起了誤差。58 舉例：Date舉例：設計 Date:incre

27、ment ( ) 的測試用例問題：你認為以下的等價類劃分是否恰當？D1 = 1day31 M1 = 1month12 Y1 = 1812year2012 59Datedd : Daymm : Month yy : YearDate(pDay : Integer, pMonth : Integer, pYear : Integer) increment()printDate() 舉例：Date另一種劃分方法D1 = 1datelast day of the month D2 = last day of the month D3 = Dec. 31 M1 = 30-day months M2 =

28、31-day months M3 = Feb. Y1 = 2000 Y2 = leap year Y3 = not leap year 60 舉例：Date61序號MonthDayYear期望輸出1234567891011122222222222221414142828282929293030302000199620022000199620022000199620022000199620022000年2月15日1996年2月15日2002年2月15日2000年2月29日1996年2月29日2002年3月 1日2000年3月 1日1996年3月 1日無效的輸入日期無效的輸入日期無效的輸入日期無效

29、的輸入日期 舉例：Date62序號MonthDayYear期望輸出1314151617181920212223246666666666661414142929293030303131312000199620022000199620022000199620022000199620022000年6月15日1996年6月15日2002年6月15日2000年6月30日1996年6月30日2002年6月30日2000年7月 1日1996年7月 1日2002年7月 1日無效的輸入日期無效的輸入日期無效的輸入日期 舉例：Date63序號MonthDayYear期望輸出25262728293031323334

30、35368888888888881414142929293030303131312000199620022000199620022000199620022000199620022000年8月15日1996年8月15日2002年8月15日2000年8月30日1996年8月30日2002年8月30日2000年8月31日1996年8月31日2002年8月31日2000年9月 1日1996年9月 1日2002年9月 1日 舉例：Date64序號MonthDayYear期望輸出37383940414243444546474812121213131333901 1131313101412000199620

31、022000199620022000199600200020022001年1月 1日1997年1月 1日2003年1月 1日無效的輸入日期無效的輸入日期無效的輸入日期無效的輸入日期無效的輸入日期無效的輸入日期無效的輸入日期無效的輸入日期無效的輸入日期 路徑測試路徑測試路徑測試是確定組件實現中錯誤的白盒測試技術，它假設通過至少一次代碼的所有可能路徑，大多數錯誤將引起故障。路徑測試是在程序流圖的基礎上，分析構造的環路復雜性，導出基本可執行路徑集合，由此設計測試用例，并保證在測試中程序的每一個可執行語句至少要次。程序流圖符號 為程序語句。流圖的一個結點，表示一個或多個無分支的源箭頭為邊，表示流的方向

32、。65 路徑測試path1：111 path2：1234510111path3：12368910111 path4：1236791011166 舉例：SelectSort舉例：函數 SelectSort ( ) 的代碼Void SelectSort( datalist & list ) for (int i=0; i<list.n-1; i+) int k=i;for (int j=i+1; j<list.n; j+)if (list.Vj.getKey() < list.Vk.getKey()k=j;if (k!=i)Swap(list.Vi, list.Vk);問

33、題：如何使用路徑測試方法設計測試用例？67 舉例：SelectSort1returni<n-135path1: 13path2: 1258 path3: 1259 path4: 1246 path5: 1247 i<>k987Vi<->Vki=i+1;68j<n4Vj<Vk6k=j;j=j+1;2k=i; j=i+1; 舉例：SelectSort測試用例Path1：取 n=1Path2：取 n=2預期結果：路徑 583 不可到達Path3：取 n=2預期結果：路徑 593 不可到達路徑1246583：取 n=2，v0=2, v1=1預期結果： k=1,

34、 v0=1, v1=2路徑1246593：取 n=2，v0=2, v1=1預期結果： k=1, 路徑 93 不可到達69 舉例：SelectSort測試用例路徑1247583：取 n=2，v0=1, v1=2預期結果： k=0, 路徑 83 不可到達路徑1247593：取 n=2，v0=1, v1=2預期結果： k=0, v0=1, v1=2說明：路徑測試技術不適合面向對象語言，例如多態性可以與不同的方法綁定，因此所有的綁定都需要確定并測試。70 基于狀態的測試基于狀態的測試基于狀態的測試主要考慮面向對象系統，它根據系統的特定狀態選擇大量的測試輸入，測試某個組件或系統，并將實際的輸出與預期的結

35、果相比較。在類環境中，從類的 UML 狀態圖中得出測試用例組成基于狀態的測試。舉例：測試 CourseOffering 類71<<entity>> CourseOfferingcourseID : String startTime : Time endTime : Time days : Enum/ numStudents : Int offeringStatus : Enum<<class>> new ()addStudent(studentS chedule : Schdule) removeStudent(studentS chedule

36、: Schdule) getNumberOfStudents() : int addProfessor(theProfessor : Professor) removeProcessor(theProfessor : Professor) offeringStillOpen() : BooleancloseRegistration() cancelOffering() closeOffering() getCourseOffering()setCourseID(courseID : String) setStartTime(startTim e : Time) setEndTime(endTi

37、me : Time) setDays(days : Enum) 舉例：CourseOffering72 舉例：CourseOffering73IDPreconditionEventPredicted Result1Initial statenew ( )offeringStatus = unassigned; numStudents = 02“unassigned” state numStudents = 0addStudent ()offeringStatus = unassigned; numStudents = 13“unassigned” state numStudents = 0re

38、moveStudent ()offeringStatus = unassigned; numStudents = 0;Display error message4“unassigned” state numStudents = 10addStudent ()offeringStatus = unassigned; numStudents = 10;Display message5“unassigned” state numStudents = 10removeStudent ()offeringStatus = unassigned; numStudents = 9;6“unassigned”

39、 stateaddProfessor ()offeringStatus = assigned7“unassigned” statecloseOffering ( )offeringStatus = cancelled 舉例：CourseOffering74IDPreconditionEventPredicted Result8“unassigned” statecloseRegistration ( )offeringStatus = cancelled9“unassigned” statecancelOffering ( )offeringStatus = cancelled10“assig

40、ned” state numStudents = 0addStudent ()offeringStatus = assigned; numStudents = 111“assigned” state numStudents = 0removeStudent ()offeringStatus = assigned; numStudents = 0;Display error message12“assigned” state numStudents = 9addStudent ()offeringStatus = full; numStudents = 10;13“assigned” state

41、 numStudents = 9removeStudent ()offeringStatus = assigned; numStudents = 8;14“assigned” stateremoveProfessor ()offeringStatus = unassigned15“assigned” stateaddProfessor ()offeringStatus = assigned; Display message 舉例：CourseOffering75IDPreconditionEventPredicted Result16“assigned” state numStudents =

42、 2closeOffering ( )offeringStatus = cancelled17“assigned” state numStudents = 3closeOffering ( )offeringStatus = committed18“assigned” state numStudents = 3closeRegistration ( )offeringStatus = committed19“assigned” statecancelOffering ( )offeringStatus = cancelled20“full” statecancelOffering ( )off

43、eringStatus = cancelled21“full” statecloseOffering ( )offeringStatus = committed22“full” statecloseRegistration ( )offeringStatus = committedYou can choose some cases for exceptional transition in any state 舉例：二進制加法器.5.Press button “C”：clear the resultPress button “0”：input 0 Press button “1”

44、：input 1 Press button “+”：addPress button “=”：display the result76 舉例：二進制加法器KeyPress( "C" ) / Op1="0":Op2="0"Enter Op1KeyPress( "1" ) / Op1="1"do/ Dis play Op1 in the resultevent KeyPress( "0" ) Op1<>"0" and Len(Op1)<20 /

45、 Add "0" after Op1 event KeyPress( "1" ) Op1<>"0" and Len(Op1)<20 / Add "1" after Op1 event KeyPress( "1" ) Op1="0 " / Op1="1"KeyPress( "0" ) / Op1="0"KeyPress( "C" ) / Op1="0":Op2="0"Display resultKeyPress( "=" ) / Op2="0"KeyPre ss( "+" ) / Op2="0"KeyPress( "+" ) / Op2="0 &quo