1 / 33

從 Use Case 到 Test Case

從 Use Case 到 Test Case. 彭靖灝 斯歌資訊. 課程內容. 故事： K2 blackpearl 延伸解讀 User Story 和 Use Case 測試程序和測試案例 VS 2010 的測試功能. 延伸解讀. 似曾相識 …. 開發人員設計程式 開發人員確信他的程式能夠正常編譯 開發人員登入程式碼 同樣的事情發生在其他幾位開發人員身上，為期四週 開發主管進行所有元件 的組建動作 應用程式安裝到測試環境 測試人員開始進行測試 應用程式未能通過測試 開發人員責怪測試過程. 循環. 不同的作業循環有其「完成」的定義

tate-dyer
Télécharger la présentation

從 Use Case 到 Test Case

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 從Use Case到Test Case 彭靖灝斯歌資訊

  2. 課程內容 • 故事：K2 blackpearl • 延伸解讀 • User Story 和 Use Case • 測試程序和測試案例 • VS 2010 的測試功能

  3. 延伸解讀

  4. 似曾相識… • 開發人員設計程式 • 開發人員確信他的程式能夠正常編譯 • 開發人員登入程式碼 • 同樣的事情發生在其他幾位開發人員身上，為期四週 • 開發主管進行所有元件的組建動作 • 應用程式安裝到測試環境 • 測試人員開始進行測試 • 應用程式未能通過測試 • 開發人員責怪測試過程

  5. 循環 • 不同的作業循環有其「完成」的定義 • 早點「完成」要比晚點「完成」好 Daily Build Testable Iteration Check In Story Product

  6. 取捨之間 • 推遲「完成」的代價 • 在開發過程組建的成果品質不佳 • 推遲了發現問題的時機 • 不清楚究竟留了多少尾巴 • 儘快「完成」的代價 • 人工驗證代價高容易出錯 • 自動化驗證需要大量投資─很難贏得支持 • 推遲「完成」常成為預設的選項

  7. 軟體何時完成? 當… • 程式寫好時(code complete)? • 進行組建時? • 通過單元測試時? • 通過接受度測試時? • 所有的臭蟲都修正時? • 客戶說完成時?

  8. 期望的開發模型早些完成並維持 • 開發人員撰寫程式碼並進行單元測試 • 開發人員僅在通過核心測試並能組建的情況下登入程式碼 • 對整個產品進行經常性的自動化組建作業 • 組建的結果能自動部署到測試環境 • 接受度測試是驗證產品品質的最終關卡

  9. 越早聽到壞消息越好

  10. 使用案例和使用者故事

  11. 使用者故事(User Story)

  12. 故事 • 必要元素 • 主角 • 情境、劇情 • 使用者的角度 • 未經修飾、扭曲的需求

  13. UML Use Case • 涵蓋User Story的功能 • 更進一步透過標準的符號表現情境中角色的互動關係

  14. 建立需求模型的重要性 • 專注在系統的外部行為，隔離內部設計 • 精確描述使用者的需要，避免自然語言描述上的誤差 • 定義在使用者、開發人員和測試人員之間一致的辭彙 • 減少需求間的不一致性和落差 • 減少處理需求變更產生的工作量 • 規劃要實作功能的順序 • 以模型為依據建立系統測試，讓需求和測試之間維持清晰的關係。一旦需求變更，立即能正確的修正測試。讓系統能符合需求

  15. 測試程序和測試案例

  16. 測試計劃

  17. 步驟1 : 自動化組建 • 自動化組建是推動「完成」的靈丹 • 提供最大的回報 • 既然最後要組建，何不早一點開始

  18. 步驟 2 : 持續整合(CI) • 持續的進行迴歸作業 • 持續執行組建並掌握你的「完成」等級 • 在問題被帶入當時就發現並處置

  19. 步驟3 : 自動化測試 • 自動化測試讓我們保持在「完成」的階段 • 不要只是「完成」了；要維持「完成」的狀態 • 越多 事情自動化越好 • 自動化的代價常意謂著沒發生

  20. 步驟 4 : 測試環境部署 • 應用程式能執行才是真正「完成」的關鍵 • 如果不能使用應用程式很難說是否完成 • 從組建到部署應用程式的過程常是障礙所在 • 每做一次組建都要部署一次是最大的障礙

  21. 步驟 5 : 明瞭「完成」的狀況 • 在任何時候都能掌握「完成」的狀態 • 組建的狀態 • 測試的結果 • 完成了那些使用者案例 • 還有多少臭蟲在那

  22. 傳統作業流程

  23. 自動化作業流程

  24. VS 2010的測試功能

  25. VS Ultimate & TFS 2010推動「完成」 • 自動化推進「完成」 • 提供必要的基礎建設 • 專注在應用程式特性 • 一次調整一步 • 在每一個週期強迫「完成」 • 登入原則 • 登入把關(Gated Check-in) • 持續整合 • 清楚何時「完成」 • 測試報告 • 專案資料報告 原始碼管理 組建 工作事項 TFS 執行測試 驗證層級 部署組建

  26. 步驟1 : 自動化組建 • VS & TFS 簡化自動化組建 • 自動化組建可以不用再令人生畏 • 所有在VS中建立的專案可以幾秒內有自動化組建能力 • 完全可延伸 • 整合Windows Workflow Foundation引擎 • 從單一組建機器到組建實驗室執行跨機器的組建工作

  27. 步驟 2 : 持續整合 • VS & TFS 天生支援持續整合 • 不需要額外的動作 • 只需要組建機器的作業週期 • 登入把關確保組建中斷不致發生 • TFS 會在每一次登入前先組建 (同步化CI) • 不再聽到「它在我的電腦上OK呀」 • 確保不會有不合乎最低限度「完成」條件的程式碼登入

  28. 步驟3 : 自動化測試 • VS 降低了測試自動化的障礙和代價 • 從單元測試到自動化UI 測試 • 對測試的支援是VS 2010 的投資重點 • 整合測試和組建 • 確保你的測試儘早通過 • 每一次組建都可以有測試結果

  29. 步驟 4 : 測試環境部署 • 2010 提供了視覺化實驗室管理 • 自動組合/分割實驗室環境 • 以群組為單位管理設備 • 網路隔離 • 整合組建和實驗室部署 • 自動化部署組建結果並執行測試 • 應用程式能備妥面對其他類型的測試

  30. Microsoft Test and Lab Manager • 可用來建立 • 測試計劃 • 測試套件(test suite) • 測試配置(test configuration) • 測試案例 • 內含在Ultimate版本，或在Test Element中獨立執行 • Visual Studio Premier不含Test and Lab Manager

  31. Testing Center

  32. 尾聲

  33. 提高程式品質的基本習慣 • 透過Use Case建立Test Case，開發作業一啟動，就同時著手建立測試案例 • 用測試案例做為需求把關的依據 • 對設計成果把關 • 透過Activity Diagram做為建立註解的依據，先寫註解，再寫程式碼 • 透過註解做為作業邏輯把關的依據 • 對設計過程把關 • 持續的進行Refactoring • 為程式碼的品質把關 • 讓程式碼始終處在一個易於維護的狀態

More Related