【課程背景】
你是否有過這樣的感覺:
l 當你在浩如煙海的網(wǎng)頁中企圖搜索單元測試的文章時,發(fā)現(xiàn)滿眼看到的卻只是一些測試模板或空洞的測試理論
l 當你期望能在大師的指點下找到單元測試的門道,然而看完他們的文章,你感到似乎懂了卻又感覺什么都沒有學到
l 當你希望能將單元測試技巧融入實戰(zhàn)時,卻發(fā)現(xiàn)周圍的例子都還停留Calculator的原始時代
l 當你希望在快速迭代的研發(fā)潮流之中找到單元測試如何引入到組織時,看到只是一些陳詞濫調(diào)和老生常談,而看不到實際的成熟案例
今天,大多數(shù)人都已經(jīng)承認單元測試是開發(fā)者的職責,而不是QA職責. 比如Google就將單元測試推到上游的、以及內(nèi)建質(zhì)量的意識，優(yōu)秀的自動化測試實踐成為我們的榜樣。然而現(xiàn)在我們天天討論單元測試,試圖將單元測試引入組織流程時.卻會面臨一系列的問題? 單元測試價值究竟何在? 什么是好的單元測試? 如何設(shè)計單元測試用例? 單元測試覆蓋率到底應(yīng)該多少? 這么多的依賴怎么才能編寫單元測試? 怎樣提高設(shè)計與代碼的可測試性? 歷史遺留系統(tǒng)代碼還有必需去寫單元測試嗎?單元測試真是我們的銀彈嗎? 怎樣才能堅持編寫單元測試？
在該課程之中，我們將揭開這些問題的背后的原因。本課程不單單是單元測試基本概念的技能講解，而是把技能和問題的場景結(jié)合，關(guān)注如何應(yīng)用單元測試解決問題，尤其關(guān)注需要通過經(jīng)驗積累的高級技能。課程中的理論和經(jīng)驗來自于對大量開發(fā)人員常犯錯誤與所遇問題的歸納、分析與總結(jié)，有針對性的給出解決方法，課程將重現(xiàn)這些問題的典型案例，通過實例講解，并對應(yīng)到學員的實際工作問題，使學員能夠把傳授的經(jīng)驗和自己的問題結(jié)合起來，有效的啟發(fā)思路、激發(fā)興趣、并掌握解決問題的基本方法。
【培訓對象】
各類軟件研發(fā)機構(gòu)的軟件研發(fā)管理者、架構(gòu)師，軟件設(shè)計師、程序員。對于懷有設(shè)計疑問和問題，需要梳理解答的團隊和個人，效果更佳。
單元測試的初級人員:通過課程的學習可以了解測試的基本概念,測試框架的使用,基礎(chǔ)的單元測試用例如何設(shè)計
單元測試中級人員:通過課程可以學習,對象依賴如何通過stub/mock等解除依賴,mock框架的學習,什么好的單元測壞死,如何提高單元測試的可讀性, 可維護性,穩(wěn)定可靠性
單元測試高級人員:通過課程可以學習到如何提高設(shè)計與代碼的可測試性, 測試覆蓋率的設(shè)計,復(fù)雜企業(yè)應(yīng)用系統(tǒng)如何測試不同的層(UI/controller/Service/DB層),如何使用測試驅(qū)動開發(fā)(TDD)?
軟件研發(fā)的管理者:如何在組織里引入單元測試? 如何評價和考核開發(fā)人員的單元測試質(zhì)量? 如何設(shè)計合適的測試覆蓋率?復(fù)雜遺留系統(tǒng)如何引入單元測試? 單元測試與持續(xù)集成如何結(jié)合? 驗收測試如何和單元測試結(jié)合?
備注：傳統(tǒng)的手工測試人員，和不寫代碼的測試工程師不建議參加，該課程主要面向開發(fā)人員而不是一般的測試工程師。
【學員要求】
學員學習本課程應(yīng)具備下列基礎(chǔ)知識：
1) 了解Java/C#/C++/C語言(建議了解面向?qū)ο蠡靖拍?span>)；
2) 簡單了解XUnit框架的任何一種；熟悉一種開發(fā)工具IDE下單元測試環(huán)境(比如JUnit/Nunit/MSTest/CppUnit/TestNG/GoogleTest等,我們課程不關(guān)注具體的工具的使用)。
【課程大綱】
|
主題 |
授課內(nèi)容 |
|
單元測試基礎(chǔ) |
內(nèi)容一：理解單元測試 1. 什么是單元測試？ 2. 為什么要寫單元測試，為什么不寫單元測試 3. 理解單元測試--第一個單元測試案例 4. 好的測試是什么樣子的，為什么要寫"好"的單元測試 5. 單元測試的維護成本 6. 單元測試與自動化測試 7. 分析真實項目,如何做單元測試 8. 通過案例分析，了解基本的單元測試
|
|
理解單元測試框架—XUnit工具 |
內(nèi)容一：理解單元測試XUnit 框架使用—（以Junit為案例介紹，其他簡單介紹） 1. Junit設(shè)計目標 2. 探索JUnit核心 3. 參數(shù)化測試 4. 測試異常 5. 超時測試 6. 引入Hamcrest匹配器 7. JUnit的測試運行器 8. 用Suite來組合測試 9. Junit與IDE，Ant，Maven集成運行 10. JUnit與持續(xù)集成工具結(jié)合 11. 通過案例分析，Junit的典型實踐
|
|
單元測試設(shè)計 |
內(nèi)容一：構(gòu)思單元測試 1. 單元測試模型的設(shè)計 2. 單元測試用例設(shè)計 3. 為系統(tǒng)運行起來而設(shè)計 4. 為正向測試而設(shè)計用例 5. 為逆向測試而設(shè)計用例 6. 為滿足特殊需求而設(shè)計用例 7. 為代碼覆蓋而設(shè)計用例 8. 通過案例分析單元測試編程前的測試用例的設(shè)計
內(nèi)容二：單元測試設(shè)計—黑盒測試 1. 單元測試黑盒設(shè)計 2. 等價類設(shè)計法 3. 邊界值分析法 4. 判定表（決策表）驅(qū)動化 5. 狀態(tài)轉(zhuǎn)移測試設(shè)計 6. 結(jié)對測試 7. 分類樹設(shè)計方法 8. 用例/場景測試 9. 動態(tài)分析法 9. 通過大量案例分析，如何應(yīng)用各種黑盒測試設(shè)計技術(shù)，進行設(shè)計單元測試
內(nèi)容三：單元測試設(shè)計—白盒測試 1. 單元測試白盒設(shè)計 2. 標識單元測試點 3. 語句覆蓋 4. 判定覆蓋 5. 基本路徑測試法 6. 白盒測試綜合策略 7. 測試覆蓋準則 8. 通過大量案例分析，如何應(yīng)用各種白盒測試設(shè)計技術(shù)，進行設(shè)計單元測試
|
|
單元測試壞味道 |
內(nèi)容一：測試代碼壞味道 1. 模糊測試(也稱為長測試、復(fù)雜測試、冗長測試) 2. 條件測試邏輯(也稱為縮排的測試碼) 3. 難以測試的代碼 4. 測試碼復(fù)制 5. 產(chǎn)品中的測試邏輯 6. 通過案例分析測試代碼的壞味道，癥狀，原因，重構(gòu)等
內(nèi)容二：測試行為的壞味道 1. 斷言滾輪 2. 不穩(wěn)定測試 3. 脆弱性測試 4. 手工干預(yù)測試(指必須手工設(shè)置測試環(huán)境，調(diào)整測試代碼) 5. 緩慢測試 6. 通過案例分析以上每種行為壞味道，癥狀，原因，重構(gòu)等
內(nèi)容三：測試項目的壞味道 1. 缺陷測試壞味道 2. 開發(fā)人員沒有寫測試 3. 高維護成本的單元測試 4. 通過案例分析以上每種行為壞味道，癥狀，原因，重構(gòu)等
|
|
測試覆蓋 |
內(nèi)容一：邏輯覆蓋 1. 實施邏輯覆蓋的原因 2. 語句覆蓋 3. 判定覆蓋 4. 條件覆蓋 5. 條件覆蓋 6. 條件判定組合覆蓋 7. 多條件覆蓋 8. 修正條件判定覆蓋 9. 結(jié)合案例分析，邏輯覆蓋的度量
內(nèi)容二：統(tǒng)計測試覆蓋--（以Junit為案例分析） 1. 使用clover為junit單元測試做覆蓋率分析 2. 使用Cobertura統(tǒng)計JUnit測試覆蓋率 3. 結(jié)合案例分析，通過測試覆蓋率工具，分析覆蓋率
|
|
單元測試模式 |
內(nèi)容一：單元測試結(jié)果驗證模式 1. 狀態(tài)驗證模式-基于狀態(tài)的測試 2. 行為驗證模式-交互測試 3. 自定義斷言—預(yù)約斷言 4. Delta斷言 5. 哨兵斷言 6. 根據(jù)案例分析結(jié)果的驗證模式
內(nèi)容二：單元測試替身模式 1. Test Stub模式 2. Test Spy模式 3. Mock Object模式 4. Fake Object模式
|
|
單元測試之中如何解耦依賴 |
內(nèi)容一：利用Stub解除依賴關(guān)系 1. 利用Stub解除依賴關(guān)系 2. Stub的案例 3. Extract and Override: The Universal Pliers 4. Isolate And Test Around 5. How Much Code To Extract? 6. Why You Should NOT Use Extract And Override 7. Why You SHOULD Use Extract And Override 8. 分析真實項目,如何使用Stub
內(nèi)容二：通過Mock對象交互測試 1. 基于狀態(tài)的測試與交互測試 2. 使用Mock的例子 3. 手工Mock測試 4. 自動化Mock測試 5. 分析真實項目,如何使用Mock， 以及相關(guān)問題
內(nèi)容三：Mock與Stub區(qū)別 1. Mock與Stub的區(qū)別 2. 同時使用Mock和Stub 3. 每個測試只使用一個Mock 4. 改進代碼設(shè)計，利于應(yīng)用Mock和Stub 5. Mock和Stub的局限性 6. 結(jié)合多個案例項目進行分析,什么時間使用Mock ，什么時間使用Stub， 如何權(quán)衡
|
|
增強設(shè)計與代碼的可測試性 |
內(nèi)容一：設(shè)計和代碼的可測試性 1. 抽取接口，容許替換底層實現(xiàn) 2. 在被測類中注入樁對象 3. What’s testable design? 4. Modular design 5. SOLID design principles 6. Modular design in context 7. Test-driving toward modular design 8. Testability issues 9. Can’t instantiate a class 10. Can’t invoke a method 11. Can’t observe the outcome 12. Can’t substitute a collaborator 13. Can’t override a method 14. Guidelines for testable design 15. Avoid complex private methods 16. Avoid final methods 17. Avoid static methods 18. Use new with care 19. Avoid logic in constructors 20. Avoid the Singleton 21. Favor composition over inheritance 22. Wrap external libraries 23. Avoid service lookups 24. 結(jié)合多個大型案例項目進行分析,如何通過重構(gòu)代碼，實現(xiàn)可測試性
|
|
企業(yè)級系統(tǒng)的單元測試 |
內(nèi)容一：企業(yè)級系統(tǒng)的單元測試典型實踐 1. 企業(yè)應(yīng)用系統(tǒng)特點 2. 企業(yè)應(yīng)用典型場景 3. 系統(tǒng)分層架構(gòu)與分層的單元測試 4. 一個案例的分析 5. 單元測試特點 6. UI層單元測試測試 7. Ctroller層單元測試 8. Service層單元測試 9. 數(shù)據(jù)庫層單元測試 10. 容器內(nèi)的測試 11. 通過企業(yè)應(yīng)用案例項目進行分析單元測試的構(gòu)建典型實踐
|
|
編寫好的單元測試 |
內(nèi)容一：好的單元測試測試標準-A-TRIP 1. 單元測試的自動化-Automatic 2. 單元測試更佳的-Thorough 3. 單元測試可重復(fù)-Repeatable 4. 單元測試獨立的-Independent 5. 單元測試專業(yè)的-Professional 6. 通過案例分析，分析好的單元測試標準
內(nèi)容二：如何編寫好的單元測試測試 1. 單元測試中的壞味道 2. 如何編寫容易被看懂的模式 3. 如何編寫容易維護的模式 4. 如何編寫更好的模式 5. 重構(gòu)單元測試，改進代碼設(shè)計 6. 結(jié)合多個案例項目進行分析,分析什么是好的單元測試
|
|
|
