Publicidad
Publicidad

Más contenido relacionado

Último(20)

Publicidad

UnitTest.pptx

  1. 單元測試 Allen liu 2021-09-05
  2. 大綱 1. 理論概念簡介 2. 為什麼不寫測試 / 寫測試好處 3. 測試有哪些分類 4. UnitTest .Net MSTest 專案實作
  3. 理論概念簡介 軟體測試: 在規定的條件下對程式進行操作,以發現程式錯誤,衡量軟體品質, 並對軟體是否能滿足設計要求,進行評估的過程。 開發團隊寫測試,通常有三種模式: 1. 先寫測試再開發。2. 開發完成再寫測試。3. 無招勝有招—不寫測試(誤)。 TDD 測試驅動開發:是一種開發流程,白話就是先寫測試再開發。
  4. 寫測試的好處: 1. 測試幫助檢查代碼正確性,減少 bug。2. 節省現在的時間,快速定位 bug。 3. 提高代碼質量,重構更簡單。 4. 減少調試時間,買未來的時間。 為什麼不寫測試: 1. 框架對單元測試不友好。 2. 代碼耦合性太高。 ( 可能未確實設計模式 S.O.L.I.D / OOP / FP,越確實測試越好寫 ) 3. 業務繁重時間、人手不足。 4. 需求不確定、價值性不高。
  5. Kent Beck 在《Test Driven Development By Example》書中提到, 3個步驟: 1. Red。2. Green。3. Refactor。 重複這些步驟直到功能做完。 那測試到底要怎麼寫呢?
  6. 測試方法分類 進程 ( aplpha / beta ) 、方法 ( 黑箱 / 白盒 ) 、類型 ( 功能 / 系統 / 極限值 / 效能 / 壓力 )階 段 ( 單元 / 整合 / 系統 / 回歸 ) ... 程式分類 ( Unit Test ) 單元測試 / ( Integration Test ) 整合測試 / ( End to End Test ) 端對端 驗收測試 整合測試 單元測試 角度 使用端角度、驗證系統功能 黑箱測試角度、驗證服務或模組 呼叫物件方法角度、驗證物件 粒度 最粗 中等 最細 環境 擬真或真實環境 含外部資源的測試環境 獨立環境、不需外部資源 需求異動穩定性 最低 中等 最高 開發成本 最低 低 最高 執行速度 最慢 中等 最快 測試案例撰寫角色 PO、SA、QA 為主開發人員為輔 QA、開發人員為主 開發人員為主 例子 登入頁面 身分驗證服務 雜湊演算法物件
  7. ( End to End Test ) 端對端測試 以 User 的角度去做測試,需要模擬最完整的環境去做測試, e.g. 商業邏輯 PASS / 資料庫連結 PASS / MVC 使用者介面 由 User 登入介面測試所有的功能是否處理好了, 通常交由專職測試工程師處理。 例如可由 E2E Test Framework Selenium 一鍵執行多個動作。
  8. ( Integration Test ) 整合測試 多個單元互相整合再一起做測試,主要針對不同模組互動去做測試。 e.g. ( 資料連接模組 / 商業邏輯模組 ) 互動測試,看會產生什麼結果, 如果 Unit Test 都 Pass 但 Integration Test Fail, 提早發現問題則可以盡快改正程式碼。
  9. ( Unit Test ) 單元測試 以最小單位進行測試,範圍小數度快,在測試專案中是比例最多的。 最小單位在不同場合有不同做法,以 A Class 內的所有 Method 做測試, 或甚至是一個個的 Method 是否有符合 input / output。
  10. 單 元 測 試 實 作 比較表 討論 比較 程式碼
  11. 單元測試實 作
  12. https://blog.miniasp.com/post/2019/02/18/Unit-testing-Integration-testing-e2e-testing https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-with-mstest https://www.youtube.com/watch?v=vjiFZCNl3YE&ab_channel=HiSKIO https://xdite.gitbooks.io/rspec-101/content/chapters/chapter-1-1-extra-1.html https://www.jondjones.com/architecture/unit-testing/nunit/ms-test-vs-nunit-vs-xunit-which-ones-the-best-you-decide/ https://www.huanlintalk.com/2018/04/test-projects-in-visual-studio-2017.html https://blog.turn.tw/?p=2821 https://www.jianshu.com/p/fa41fb80d2b8 https://xdite.gitbooks.io/rspec-101/content/contents/why-test/ https://juejin.im/post/6844904032264273934 https://tw.alphacamp.co/blog/tdd-test-driven-development-example https://www.google.com/search?sxsrf=ALeKk02w8VuJHv7g0W6XmCn-jmWUgVhU8A%3A1603257519826&ei=r8SPX7CPMvCOr7wPmK- gyA4&q=MSTest%E3%80%81NUnit%E3%80%81+xUnit+%E5%B7%AE%E5%88%A5&oq=MSTest%E3%80%81NUnit%E3%80%81+xUnit+%E5%B7%AE%E5%88%A5&gs_lcp=CgZwc3ktYWIQAzoFCAAQzQI6BQ ghEKABULMOWNtCYPREaAtwAHgAgAFgiAH7BpIBAjE1mAEAoAEBqgEHZ3dzLXdpesABAQ&sclient=psy-ab&ved=0ahUKEwjwos_X98TsAhVwx4sBHZgXCOkQ4dUDCA0&uact=5 https://www.youtube.com/watch?v=0bLBv5KL7aE&t=94s&ab_channel=HiSKIO https://www.slideshare.net/kingkongbruce/ss-51063660 參考

Notas del editor

  1. 查看簡報 下拉 找筆記 f11 全螢幕
  2. 軟體測試其實就是有一套自視的規範只要程式符合規範則完成測試
  3. 1. 可能要寫比現在要開發的程式量乘倍數的測試 Code 這邊除了程式需要確實 SOLID 物件導向設計 物件導向程式設計 (Object-oriented programming) 函数式编程(Functional Programming, FP) 再來則是時間與 需求明確度與價值 ----- 可以在下一個版本的 Code 時 run 測試,可以馬上知道代碼的正確性 --- Single responsibility principle(單一職責原則):指一個類模組包甚至系統都應該有單一的原則。 Open-closed principle(開閉原則):你應該能夠擴充套件類的行為,而不需要修改它。 Liskov substitution principle(里氏替換原則):簡答理解就是如果想要可替換的元件來構建軟體系統,那麼這些元件就必須遵守共同一個約定,以便讓這些元件可以相互替換。 Interface segregation principle(介面隔離原則):使細粒度介面特定於客戶端,主要告誡設計師應該在設計中避免不必要的依賴。 Dependency Inversion Principle(依賴倒置原則):依賴抽象,而非具體實現。此原則指出高層策略性程式碼不應該依賴實現的程式碼,相反,那些底層實現應該依賴於高層策略程式碼。
  4. 那測試到底要怎麼寫呢?其實只要實作這三點,測試就不會太難寫 開發就以實作測試為基礎,其實就達到測試驅動開發 TTD 1. Red:寫個能表達你打算如何使用那段code的測試,還有你期待它做什麼。這個測試會失敗。很多介面會用紅色訊息來表示它。 2. Green:寫出足夠的code來讓那個測試成功,但別多寫。如果你想寫更多code,像是檢查某些錯誤的話,那就先另寫一個測試表達它。當下只要寫剛好夠的code去通過測試即可。 3. Refactor 綠肥特:把多餘的code清理一下,然後改善整體設計。之後再跑一次測試,確保沒弄壞什麼地方。
  5. 上面不多獎 WIKI 能查到更多細節 這邊可以大致上看一下比較表,開發人員主要還是以單元測試與整合測試為主
  6. 通常 run 一次的時間較長,整個專案中佔的比例較少
  7. 代表兩個模組都沒問題,但互動上出了問題, 整合測試需要整理相對於單元測試更完整的環境來完成測試工作, 在專案中比例相較於單元測試數量較少。
  8. 照畫面講
  9. C# 有許多單元測試的框架可以實作單元測試,目前看比較表 NUnit 是提供最多功能的,但實際上並不會用到那麼多標籤,所以三種其實差不多 主要就是以往 mstest 功能比較不完善,所以大家都用 ntest,到現在基本功能都差不多了,一般開發其實都夠用
  10. 通常是在現有的方案附加測試專案 痾瑞居 安排所有必要的前提條件和輸入。 欸可特 對被測對像或方法採取行動。 痾色特 斷言已發生預期的結果。 右鍵偵錯測試,斷點看哪錯 註解 最後成功 檢視測試畫面 explorer 偵錯 然後講解 結果跟時間等等 (看畫面講) 然後 解 bug ( 密碼 ) 然後繼成功 秀 最後帶到 create 單子 環境必須跟 開發環境或是真實執行環境相同 config 必須要對 依賴注入的資料要注入 等等 需要考慮的環節更多 使用情境 流程較複雜時可以 幫忙產測試資料
Publicidad