Contenu connexe Similaire à UnitTest.pptx (20) UnitTest.pptx4. 寫測試的好處:
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。
Notes de l'éditeur 查看簡報 下拉 找筆記 f11 全螢幕 軟體測試其實就是有一套自視的規範只要程式符合規範則完成測試
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(依賴倒置原則):依賴抽象,而非具體實現。此原則指出高層策略性程式碼不應該依賴實現的程式碼,相反,那些底層實現應該依賴於高層策略程式碼。
那測試到底要怎麼寫呢?其實只要實作這三點,測試就不會太難寫
開發就以實作測試為基礎,其實就達到測試驅動開發 TTD
1. Red:寫個能表達你打算如何使用那段code的測試,還有你期待它做什麼。這個測試會失敗。很多介面會用紅色訊息來表示它。
2. Green:寫出足夠的code來讓那個測試成功,但別多寫。如果你想寫更多code,像是檢查某些錯誤的話,那就先另寫一個測試表達它。當下只要寫剛好夠的code去通過測試即可。
3. Refactor 綠肥特:把多餘的code清理一下,然後改善整體設計。之後再跑一次測試,確保沒弄壞什麼地方。 上面不多獎 WIKI 能查到更多細節
這邊可以大致上看一下比較表,開發人員主要還是以單元測試與整合測試為主
通常 run 一次的時間較長,整個專案中佔的比例較少 代表兩個模組都沒問題,但互動上出了問題,
整合測試需要整理相對於單元測試更完整的環境來完成測試工作,
在專案中比例相較於單元測試數量較少。 照畫面講 C# 有許多單元測試的框架可以實作單元測試,目前看比較表 NUnit 是提供最多功能的,但實際上並不會用到那麼多標籤,所以三種其實差不多
主要就是以往 mstest 功能比較不完善,所以大家都用 ntest,到現在基本功能都差不多了,一般開發其實都夠用 通常是在現有的方案附加測試專案
痾瑞居 安排所有必要的前提條件和輸入。
欸可特 對被測對像或方法採取行動。
痾色特 斷言已發生預期的結果。
右鍵偵錯測試,斷點看哪錯 註解 最後成功
檢視測試畫面 explorer 偵錯 然後講解 結果跟時間等等 (看畫面講) 然後 解 bug ( 密碼 ) 然後繼成功 秀
最後帶到 create 單子 環境必須跟 開發環境或是真實執行環境相同 config 必須要對 依賴注入的資料要注入 等等 需要考慮的環節更多
使用情境 流程較複雜時可以 幫忙產測試資料