課程簡介
課堂中，我們定義由開發(fā)者承擔的與代碼相關的軟件測試工作為開發(fā)者測試。從開發(fā)者測試出現(xiàn)的背景與意義、開發(fā)者所應掌握的基本和高級程序分析方法以及軟件測試技術、開發(fā)者所應掌握的軟件測試分析輔助工具、用于開發(fā)者測試教學和競賽平臺等多個方面對開發(fā)者測試進行系統(tǒng)性介紹。相信通過課程的學習，可以對開發(fā)者參與測試的必要性、開發(fā)者測試所涵蓋的內容有初步的認識和了解，同時能夠鍛煉自己的測試能力。
目標收益
培訓對象
課程大綱
| 開發(fā)者測試基礎 |
內容一：開發(fā)者測試概述 1.開發(fā)者與軟件測試 2.測試和調試 3.開發(fā)者測試 4.PIE模型 5.開發(fā)者測試方法與技術 6.靜態(tài)測試與動態(tài)測試 7.黑盒測試與白盒測試 8.失效重現(xiàn) 9.開發(fā)者測試工具 10.靜態(tài)測試掃描工具 11.測試覆蓋分析工具 12.開發(fā)者測試趨勢 13.軟件開發(fā)和運營困境 14.DevOps中的開發(fā)者測試 內容二：敏捷測試 -實際開發(fā)中的測試區(qū)別和實踐 1.敏捷測試 2.測試金字塔 3.單元測試 4.組件測試 5.集成測試 6.軟件開發(fā)之中各種測試的區(qū)別 |
| 開發(fā)者測試—代碼靜態(tài)分析 |
內容一：代碼靜態(tài)分析 1.程序靜態(tài)分析（Program Static Analysis）是指在不運行代碼的方式下，通過詞法分析、語法分析、控制流分析等技術對程序代碼進行掃描，驗證代碼是否滿足規(guī)范性、安全性、可靠性、可維護性等指標的一種代碼分析技術。 2.程序靜態(tài)分析（Program Static Analysis）可以幫助軟件開發(fā)人員、質量保證人員查找代碼中存在的結構性錯誤、安全漏洞等問題，從而保證軟件的整體質量 3.靜態(tài)分析的特點 4.代碼評審 5.結構分析 6.程序流程分析 7.控制流分析 8.數(shù)據流分析 9.符號執(zhí)行 10.靜態(tài)符號執(zhí)行 11.動態(tài)符號執(zhí)行 12.編程規(guī)范和規(guī)則 13.常用靜態(tài)分析技術 14.靜態(tài)分析實現(xiàn)方式 內容二：代碼靜態(tài)分析工具 1.代碼靜態(tài)分析工具概述 2.以Java語言代碼靜態(tài)分析工具為例介紹，該內容的思想仍然適合其他語言 a)其他語言相關代碼靜態(tài)分析工具 通過案例演示工具在項目之中的應用 |
| 開發(fā)者測試--AEP自動化錯誤預防 |
內容一：自動化預防-AEP 1.Automated Error Prevention（簡稱AEP），是指通過整個軟件開發(fā)周期中自動地預防錯誤來提高產品質量 2.自動化錯誤預防五大法則 3.應用行業(yè)最佳實踐來防止普遍錯誤并建立全方位的錯誤預防基礎---案例分析 4.按需要修改實踐來預防特殊的錯誤 5.確保每個小組正確地，始終如一地貫徹執(zhí)行AEP 6.循環(huán)漸進地采用每一個實踐 7.利用統(tǒng)計來穩(wěn)定每一個過程，讓它發(fā)揮價值 8.通過案例進行分析，某研發(fā)中心代碼自動化預防機制建立 內容二：BugDetective 1.BugDetective概述 2.BugDetective規(guī)則 3.Parasoft公司旗下產品C++Test BugDetective分析技術，該技術使用了幾種分析技巧，包括模擬應用程序執(zhí)行路徑，以識別可能觸發(fā)運行時缺陷的路徑。檢測到的缺陷包括，使用未初始化的內存、引用空指針、除數(shù)為零、內存和資源泄漏。 9.通過案例進行分析，某研發(fā)中心代碼自動化預防機制建立 |
| 理解單元測試框架—XUnit工具 |
內容一：理解單元測試 1.什么是單元測試？ 2.為什么要寫單元測試，為什么不寫單元測試 3.理解單元測試--第一個單元測試案例 4.好的測試是什么樣子的，為什么要寫"好"的單元測試 5.單元測試的維護成本 6.單元測試與自動化測試 7.分析真實項目,如何做單元測試 8.通過案例分析，了解基本的單元測試 內容一：理解單元測試XUnit 框架使用—（以Junit為案例介紹，其他簡單介紹） 1.Junit設計目標 2.探索JUnit核心 3.參數(shù)化測試 4.測試異常 5.超時測試 6.引入Hamcrest匹配器 7.JUnit的測試運行器 8.用Suite來組合測試 9.Junit與IDE，Ant，Maven集成運行 10.JUnit與持續(xù)集成工具結合 11.通過案例分析，Junit的最佳實踐 內容二：Junit5新特性 1.Junit5架構 2.Junit5新特性 3.JUnit 5 架構演進 4.JUnit 5 新注解 5.JUnit 5新的斷言 6.超時操作的測試：assertTimeoutPreemptively 7.異常測試：assertThrows 8.JUnit 5 參數(shù)化測試 9.JUnit 5 中的前置條件（assumptions） 10.JUnit 5 嵌套測試 11.JUnit 5 動態(tài)測試 12.JUnit 5 依賴注入 13.Junit5和Junit4 區(qū)別 從Junit4升級到Junit5 |
| 單元測試設計 |
內容一：構思單元測試 1.單元測試模型的設計 2.單元測試用例設計 3.為系統(tǒng)運行起來而設計 4.為正向測試而設計用例 5.為逆向測試而設計用例 6.為滿足特殊需求而設計用例 7.為代碼覆蓋而設計用例 8.通過案例分析單元測試編程前的測試用例的設計 內容二：單元測試設計與構建-基于路徑的白盒測試 1.單元測試白盒設計 2.標識單元測試點 3.語句覆蓋 4.判定覆蓋 5.基本路徑測試法 6.白盒測試綜合策略 7.測試覆蓋準則 8.通過大量案例分析，如何應用各種白盒測試設計技術，進行設計單元測試 內容三：單元測試設計與構建—基于測試數(shù)據的黑盒測試 1.單元測試黑盒設計 2.等價類設計法 3.邊界值分析法 4.判定表（決策表）驅動化 5.狀態(tài)轉移測試設計 6.用例/場景測試 7.動態(tài)分析法 9.通過大量案例分析，如何應用各種黑盒測試設計技術，進行設計單元測試 內容四：單元測試設計最佳實踐 1.單元測試的私有方法的測試 2.測試私有方法是錯誤的！ 3.私有方法重構-將私有方法變成公共方法 4.私有方法重構-抽取方法，形成新類 5.測試私有方法的例外情況 6.基于交互的測試最佳實踐 7.基于狀態(tài)的測試最佳實踐 8.基于狀態(tài)的測試利用對象內部狀態(tài)驗證執(zhí)行結果的正確性。 9.利用協(xié)作對象的完成狀態(tài)測試 內容五：單元測試設計SPIFFy原則 1.單元測試粒度 2.單元測試依賴 3.單元測試原則-SPIFFy: 4.Small: 10 lines or less, ideally 5.Precise: Checks one behavior of one class 6.Isolated: Doesn't affect other tests 7.Fast: Takes milliseconds to run 8.Frequently Run: Every time you make a change |
| 單元測試壞味道 |
內容一：測試代碼壞味道 1.模糊測試(也稱為長測試、復雜測試、冗長測試) 2.條件測試邏輯(也稱為縮排的測試碼) 3.難以測試的代碼 4.測試碼復制 5.產品中的測試邏輯 6.通過案例分析測試代碼的壞味道，癥狀，原因，重構等 內容二：測試行為的壞味道 1.斷言滾輪 2.不穩(wěn)定測試 3.脆弱性測試 4.手工干預測試(指必須手工設置測試環(huán)境，調整測試代碼) 5.緩慢測試 6.通過案例分析以上每種行為壞味道，癥狀，原因，重構等 內容三：測試項目的壞味道 1.缺陷測試壞味道 2.開發(fā)人員沒有寫測試 3.高維護成本的單元測試 4.通過案例分析以上每種行為壞味道，癥狀，原因，重構等 |
| 測試覆蓋 |
內容一：邏輯覆蓋 1.實施邏輯覆蓋的原因 2.語句覆蓋 3.判定覆蓋 4.條件覆蓋 5.條件覆蓋 6.條件判定組合覆蓋 7.多條件覆蓋 8.修正條件判定覆蓋 9.結合案例分析，邏輯覆蓋的度量 內容二：統(tǒng)計測試覆蓋--（以Junit為案例分析） 1.使用clover為junit單元測試做覆蓋率分析 2.使用Cobertura統(tǒng)計JUnit測試覆蓋率 3.結合案例分析，通過測試覆蓋率工具，分析覆蓋率 |
| 單元測試模式 |
內容一：單元測試結果驗證模式 1.狀態(tài)驗證模式-基于狀態(tài)的測試 2.行為驗證模式-交互測試 3.自定義斷言—預約斷言 4.Delta斷言 5.哨兵斷言 6.根據案例分析結果的驗證模式 內容二：單元測試替身模式 1.Test Stub模式 2.Test Spy模式 3.Mock Object模式 4.Fake Object模式 |
| 單元測試之中如何解耦依賴 |
內容一：解除依賴關系 - Extract and Override 和 Stub方法 1.反測試設計-外部依賴 2.不確定性1-時間 3.不確定性2-隨機性 4.不確定性3-外界第三方依賴 5.Extract and Override: The Universal Pliers 6. Isolate And Test Around 7.How Much Code To Extract? 8.Why You Should NOT Use Extract And Override 9.Why You SHOULD Use Extract And Override 10.利用Stub解除依賴關系 11.使用存根Stub破除依賴 12.依賴注入Stub的方式 13.多種Stub的案例 14.分析真實項目,如何使用Stub 內容二：通過Mock對象解除依賴 1.Mock模擬對象和Stub存根的區(qū)別 2.手工Mock測試 3.手工Mock模擬對象的簡單示例 4.同時使用Mock模擬對象和Stub存根 5.每個測試方法僅有一個模擬對象 6.偽對象鏈：用存根生成模擬對象或其他存根 7.手工模擬對象和存根的問題 8.分析真實項目,如何使用Mock， 以及相關問題 內容三：Mock隔離框架 1.Mock與Stub的區(qū)別 2.為什么要使用隔離框架 3.動態(tài)生成偽對象 4.動態(tài)生成模擬值 5.現(xiàn)有的隔離框架 6.隔離框架的優(yōu)缺點 7.隔離框架設計反模式 8.結合多個案例項目進行分析,什么時間使用Mock ，什么時間使用Stub， 如何權衡 內容三：Mock隔離框架(Mockito) 1.Mockito 介紹 2.Mockito實現(xiàn)原理與架構 3.Mockito資源 4.Mockito驗證行為 5.Mockito模擬我們所期望的結果 6.參數(shù)匹配和自定義參數(shù)匹配 7.連續(xù)調用和驗證確切的調用次數(shù) 8.驗證執(zhí)行順序 9.使用方法預期回調接口生成期望值（Answer結構） 10.修改對未預設的調用返回默認期望 11.Mockito如何實現(xiàn)Mock |
| 增強設計與代碼的可測試性 |
內容一：可測試性設計與可測試問題 1.什么是可測的設計 2.模塊化設計與SOLID設計原則 3.實際開發(fā)之中的可測性的問題 4.無法實例化某個類 5.無法調用某個方法 6.無法觀察到輸出 7.無法替換某個協(xié)作者 8.無法覆蓋某個方法 9.案例分析 內容二：可測試性設計最佳實踐 1.可測的設計的指南 2.抽取接口，容許替換底層實現(xiàn) 3.在被測類中注入樁對象 4.避免復雜的私有方法 5.避免final方法 6.避免static方法 7.使用new時要當心 8.避免在構造函數(shù)中包含邏輯 9.避免單例 10.組合優(yōu)于繼承 11.封裝外部庫 12.避免服務查找 13.結合多個大型案例項目進行分析,如何通過重構代碼，實現(xiàn)可測試性 |
| 企業(yè)級系統(tǒng)的單元測試 |
內容一：企業(yè)級系統(tǒng)的單元測試最佳實踐 1.企業(yè)應用系統(tǒng)特點 2.企業(yè)應用典型場景 3.系統(tǒng)分層架構與分層的單元測試 4.一個案例的分析 5.單元測試特點 6.UI層單元測試測試 7.Ctroller層單元測試 8.Service層單元測試 9.數(shù)據庫層單元測試 10.容器內的測試 11.通過企業(yè)應用案例項目進行分析單元測試的構建最佳實踐 |
| 編寫好的單元測試 |
內容一：好的單元測試測試標準-A-TRIP 1.單元測試的自動化-Automatic 2.單元測試徹底的-Thorough 3.單元測試可重復-Repeatable 4.單元測試獨立的-Independent 5.單元測試專業(yè)的-Professional 6.通過案例分析，分析好的單元測試標準 內容二：如何編寫好的單元測試測試 1.單元測試中的壞味道 2.如何編寫容易被看懂的模式 3.如何編寫容易維護的模式 4.如何編寫信得過的模式 5.重構單元測試，改進代碼設計 6.結合多個案例項目進行分析,分析什么是好的單元測試 內容三：如何編寫好的單元測試測試 1.優(yōu)秀單元測試3條準則 2.優(yōu)秀單元測試-可讀性 3.優(yōu)秀單元測試-可維護性 4.優(yōu)秀單元測試-可信賴性 5.如何編寫容易被看懂的模式 6.結合多個案例項目進行分析,分析什么是好的單元測試 |
| TDD測試驅動開發(fā)基礎 |
內容一：TDD測試驅動開發(fā) 1.TDD的節(jié)奏 2.TDD的兩個原則和TDD的目標 3.TDD與行為驅動開發(fā)（Behaviour Driven Development） 4.TDD與驗收測試驅動開發(fā)（Acceptance Test Driven Development） 5.識別代碼中的壞味道 6.重構工具及使用 7.常用重構技巧 8.重構與預先設計的區(qū)別 9.通過案例分析，TDD的最佳實踐技巧，重構的技巧，壞味道等 |
| 歷史遺留系統(tǒng)如何編寫單元測試 |
內容一：遺留系統(tǒng)代碼環(huán)境下如何編寫單元測試 1.從哪里開始添加單元測試 2.確定抉擇策略1-容易優(yōu)先測類的優(yōu)缺點 3.確定抉擇策略2-困難優(yōu)先測類的優(yōu)缺點 4.遺留代碼改動準則 5.重構前寫集成測試 6.遺留代碼整潔測試的常用工具 7.為第三方代碼做學習測試 8.復雜遺留系統(tǒng)之中，如何增加單元測試以及遇到的問題 9.通過真實案例分析，在遺留系統(tǒng)的的難度和最佳實踐 |
| 單元測試組織和管理 |
內容一：組織和管理測試 1.通過自動構建腳本運行測試 2.將測試與代碼做同源版本管理 3.根據速度和類型為測試分類 4.創(chuàng)建和維護項目的測試輔助設施 5.結合我們研發(fā)中心， 如何做單元測試管理， 已經如何組織，以及遇到的問題 |
| 在研發(fā)團隊如何引入單元測試 |
內容一：將測試引入到你的組織中 1.如何成功在組織中引入單元測試 2.為什么在組織中引入單元測試的努力會失敗 3.如何將測試集成到開發(fā)流程中 - 敏捷測試流程 4.常見的疑惑和解答? 5.通過多個研發(fā)中心咨詢經驗，分析單元測試引入的方式和最佳實踐 |
|
開發(fā)者測試基礎 內容一：開發(fā)者測試概述 1.開發(fā)者與軟件測試 2.測試和調試 3.開發(fā)者測試 4.PIE模型 5.開發(fā)者測試方法與技術 6.靜態(tài)測試與動態(tài)測試 7.黑盒測試與白盒測試 8.失效重現(xiàn) 9.開發(fā)者測試工具 10.靜態(tài)測試掃描工具 11.測試覆蓋分析工具 12.開發(fā)者測試趨勢 13.軟件開發(fā)和運營困境 14.DevOps中的開發(fā)者測試 內容二：敏捷測試 -實際開發(fā)中的測試區(qū)別和實踐 1.敏捷測試 2.測試金字塔 3.單元測試 4.組件測試 5.集成測試 6.軟件開發(fā)之中各種測試的區(qū)別 |
|
開發(fā)者測試—代碼靜態(tài)分析 內容一：代碼靜態(tài)分析 1.程序靜態(tài)分析（Program Static Analysis）是指在不運行代碼的方式下，通過詞法分析、語法分析、控制流分析等技術對程序代碼進行掃描，驗證代碼是否滿足規(guī)范性、安全性、可靠性、可維護性等指標的一種代碼分析技術。 2.程序靜態(tài)分析（Program Static Analysis）可以幫助軟件開發(fā)人員、質量保證人員查找代碼中存在的結構性錯誤、安全漏洞等問題，從而保證軟件的整體質量 3.靜態(tài)分析的特點 4.代碼評審 5.結構分析 6.程序流程分析 7.控制流分析 8.數(shù)據流分析 9.符號執(zhí)行 10.靜態(tài)符號執(zhí)行 11.動態(tài)符號執(zhí)行 12.編程規(guī)范和規(guī)則 13.常用靜態(tài)分析技術 14.靜態(tài)分析實現(xiàn)方式 內容二：代碼靜態(tài)分析工具 1.代碼靜態(tài)分析工具概述 2.以Java語言代碼靜態(tài)分析工具為例介紹，該內容的思想仍然適合其他語言 a)其他語言相關代碼靜態(tài)分析工具 通過案例演示工具在項目之中的應用 |
|
開發(fā)者測試--AEP自動化錯誤預防 內容一：自動化預防-AEP 1.Automated Error Prevention（簡稱AEP），是指通過整個軟件開發(fā)周期中自動地預防錯誤來提高產品質量 2.自動化錯誤預防五大法則 3.應用行業(yè)最佳實踐來防止普遍錯誤并建立全方位的錯誤預防基礎---案例分析 4.按需要修改實踐來預防特殊的錯誤 5.確保每個小組正確地，始終如一地貫徹執(zhí)行AEP 6.循環(huán)漸進地采用每一個實踐 7.利用統(tǒng)計來穩(wěn)定每一個過程，讓它發(fā)揮價值 8.通過案例進行分析，某研發(fā)中心代碼自動化預防機制建立 內容二：BugDetective 1.BugDetective概述 2.BugDetective規(guī)則 3.Parasoft公司旗下產品C++Test BugDetective分析技術，該技術使用了幾種分析技巧，包括模擬應用程序執(zhí)行路徑，以識別可能觸發(fā)運行時缺陷的路徑。檢測到的缺陷包括，使用未初始化的內存、引用空指針、除數(shù)為零、內存和資源泄漏。 9.通過案例進行分析，某研發(fā)中心代碼自動化預防機制建立 |
|
理解單元測試框架—XUnit工具 內容一：理解單元測試 1.什么是單元測試？ 2.為什么要寫單元測試，為什么不寫單元測試 3.理解單元測試--第一個單元測試案例 4.好的測試是什么樣子的，為什么要寫"好"的單元測試 5.單元測試的維護成本 6.單元測試與自動化測試 7.分析真實項目,如何做單元測試 8.通過案例分析，了解基本的單元測試 內容一：理解單元測試XUnit 框架使用—（以Junit為案例介紹，其他簡單介紹） 1.Junit設計目標 2.探索JUnit核心 3.參數(shù)化測試 4.測試異常 5.超時測試 6.引入Hamcrest匹配器 7.JUnit的測試運行器 8.用Suite來組合測試 9.Junit與IDE，Ant，Maven集成運行 10.JUnit與持續(xù)集成工具結合 11.通過案例分析，Junit的最佳實踐 內容二：Junit5新特性 1.Junit5架構 2.Junit5新特性 3.JUnit 5 架構演進 4.JUnit 5 新注解 5.JUnit 5新的斷言 6.超時操作的測試：assertTimeoutPreemptively 7.異常測試：assertThrows 8.JUnit 5 參數(shù)化測試 9.JUnit 5 中的前置條件（assumptions） 10.JUnit 5 嵌套測試 11.JUnit 5 動態(tài)測試 12.JUnit 5 依賴注入 13.Junit5和Junit4 區(qū)別 從Junit4升級到Junit5 |
|
單元測試設計 內容一：構思單元測試 1.單元測試模型的設計 2.單元測試用例設計 3.為系統(tǒng)運行起來而設計 4.為正向測試而設計用例 5.為逆向測試而設計用例 6.為滿足特殊需求而設計用例 7.為代碼覆蓋而設計用例 8.通過案例分析單元測試編程前的測試用例的設計 內容二：單元測試設計與構建-基于路徑的白盒測試 1.單元測試白盒設計 2.標識單元測試點 3.語句覆蓋 4.判定覆蓋 5.基本路徑測試法 6.白盒測試綜合策略 7.測試覆蓋準則 8.通過大量案例分析，如何應用各種白盒測試設計技術，進行設計單元測試 內容三：單元測試設計與構建—基于測試數(shù)據的黑盒測試 1.單元測試黑盒設計 2.等價類設計法 3.邊界值分析法 4.判定表（決策表）驅動化 5.狀態(tài)轉移測試設計 6.用例/場景測試 7.動態(tài)分析法 9.通過大量案例分析，如何應用各種黑盒測試設計技術，進行設計單元測試 內容四：單元測試設計最佳實踐 1.單元測試的私有方法的測試 2.測試私有方法是錯誤的！ 3.私有方法重構-將私有方法變成公共方法 4.私有方法重構-抽取方法，形成新類 5.測試私有方法的例外情況 6.基于交互的測試最佳實踐 7.基于狀態(tài)的測試最佳實踐 8.基于狀態(tài)的測試利用對象內部狀態(tài)驗證執(zhí)行結果的正確性。 9.利用協(xié)作對象的完成狀態(tài)測試 內容五：單元測試設計SPIFFy原則 1.單元測試粒度 2.單元測試依賴 3.單元測試原則-SPIFFy: 4.Small: 10 lines or less, ideally 5.Precise: Checks one behavior of one class 6.Isolated: Doesn't affect other tests 7.Fast: Takes milliseconds to run 8.Frequently Run: Every time you make a change |
|
單元測試壞味道 內容一：測試代碼壞味道 1.模糊測試(也稱為長測試、復雜測試、冗長測試) 2.條件測試邏輯(也稱為縮排的測試碼) 3.難以測試的代碼 4.測試碼復制 5.產品中的測試邏輯 6.通過案例分析測試代碼的壞味道，癥狀，原因，重構等 內容二：測試行為的壞味道 1.斷言滾輪 2.不穩(wěn)定測試 3.脆弱性測試 4.手工干預測試(指必須手工設置測試環(huán)境，調整測試代碼) 5.緩慢測試 6.通過案例分析以上每種行為壞味道，癥狀，原因，重構等 內容三：測試項目的壞味道 1.缺陷測試壞味道 2.開發(fā)人員沒有寫測試 3.高維護成本的單元測試 4.通過案例分析以上每種行為壞味道，癥狀，原因，重構等 |
|
測試覆蓋 內容一：邏輯覆蓋 1.實施邏輯覆蓋的原因 2.語句覆蓋 3.判定覆蓋 4.條件覆蓋 5.條件覆蓋 6.條件判定組合覆蓋 7.多條件覆蓋 8.修正條件判定覆蓋 9.結合案例分析，邏輯覆蓋的度量 內容二：統(tǒng)計測試覆蓋--（以Junit為案例分析） 1.使用clover為junit單元測試做覆蓋率分析 2.使用Cobertura統(tǒng)計JUnit測試覆蓋率 3.結合案例分析，通過測試覆蓋率工具，分析覆蓋率 |
|
單元測試模式 內容一：單元測試結果驗證模式 1.狀態(tài)驗證模式-基于狀態(tài)的測試 2.行為驗證模式-交互測試 3.自定義斷言—預約斷言 4.Delta斷言 5.哨兵斷言 6.根據案例分析結果的驗證模式 內容二：單元測試替身模式 1.Test Stub模式 2.Test Spy模式 3.Mock Object模式 4.Fake Object模式 |
|
單元測試之中如何解耦依賴 內容一：解除依賴關系 - Extract and Override 和 Stub方法 1.反測試設計-外部依賴 2.不確定性1-時間 3.不確定性2-隨機性 4.不確定性3-外界第三方依賴 5.Extract and Override: The Universal Pliers 6. Isolate And Test Around 7.How Much Code To Extract? 8.Why You Should NOT Use Extract And Override 9.Why You SHOULD Use Extract And Override 10.利用Stub解除依賴關系 11.使用存根Stub破除依賴 12.依賴注入Stub的方式 13.多種Stub的案例 14.分析真實項目,如何使用Stub 內容二：通過Mock對象解除依賴 1.Mock模擬對象和Stub存根的區(qū)別 2.手工Mock測試 3.手工Mock模擬對象的簡單示例 4.同時使用Mock模擬對象和Stub存根 5.每個測試方法僅有一個模擬對象 6.偽對象鏈：用存根生成模擬對象或其他存根 7.手工模擬對象和存根的問題 8.分析真實項目,如何使用Mock， 以及相關問題 內容三：Mock隔離框架 1.Mock與Stub的區(qū)別 2.為什么要使用隔離框架 3.動態(tài)生成偽對象 4.動態(tài)生成模擬值 5.現(xiàn)有的隔離框架 6.隔離框架的優(yōu)缺點 7.隔離框架設計反模式 8.結合多個案例項目進行分析,什么時間使用Mock ，什么時間使用Stub， 如何權衡 內容三：Mock隔離框架(Mockito) 1.Mockito 介紹 2.Mockito實現(xiàn)原理與架構 3.Mockito資源 4.Mockito驗證行為 5.Mockito模擬我們所期望的結果 6.參數(shù)匹配和自定義參數(shù)匹配 7.連續(xù)調用和驗證確切的調用次數(shù) 8.驗證執(zhí)行順序 9.使用方法預期回調接口生成期望值（Answer結構） 10.修改對未預設的調用返回默認期望 11.Mockito如何實現(xiàn)Mock |
|
增強設計與代碼的可測試性 內容一：可測試性設計與可測試問題 1.什么是可測的設計 2.模塊化設計與SOLID設計原則 3.實際開發(fā)之中的可測性的問題 4.無法實例化某個類 5.無法調用某個方法 6.無法觀察到輸出 7.無法替換某個協(xié)作者 8.無法覆蓋某個方法 9.案例分析 內容二：可測試性設計最佳實踐 1.可測的設計的指南 2.抽取接口，容許替換底層實現(xiàn) 3.在被測類中注入樁對象 4.避免復雜的私有方法 5.避免final方法 6.避免static方法 7.使用new時要當心 8.避免在構造函數(shù)中包含邏輯 9.避免單例 10.組合優(yōu)于繼承 11.封裝外部庫 12.避免服務查找 13.結合多個大型案例項目進行分析,如何通過重構代碼，實現(xiàn)可測試性 |
|
企業(yè)級系統(tǒng)的單元測試 內容一：企業(yè)級系統(tǒng)的單元測試最佳實踐 1.企業(yè)應用系統(tǒng)特點 2.企業(yè)應用典型場景 3.系統(tǒng)分層架構與分層的單元測試 4.一個案例的分析 5.單元測試特點 6.UI層單元測試測試 7.Ctroller層單元測試 8.Service層單元測試 9.數(shù)據庫層單元測試 10.容器內的測試 11.通過企業(yè)應用案例項目進行分析單元測試的構建最佳實踐 |
|
編寫好的單元測試 內容一：好的單元測試測試標準-A-TRIP 1.單元測試的自動化-Automatic 2.單元測試徹底的-Thorough 3.單元測試可重復-Repeatable 4.單元測試獨立的-Independent 5.單元測試專業(yè)的-Professional 6.通過案例分析，分析好的單元測試標準 內容二：如何編寫好的單元測試測試 1.單元測試中的壞味道 2.如何編寫容易被看懂的模式 3.如何編寫容易維護的模式 4.如何編寫信得過的模式 5.重構單元測試，改進代碼設計 6.結合多個案例項目進行分析,分析什么是好的單元測試 內容三：如何編寫好的單元測試測試 1.優(yōu)秀單元測試3條準則 2.優(yōu)秀單元測試-可讀性 3.優(yōu)秀單元測試-可維護性 4.優(yōu)秀單元測試-可信賴性 5.如何編寫容易被看懂的模式 6.結合多個案例項目進行分析,分析什么是好的單元測試 |
|
TDD測試驅動開發(fā)基礎 內容一：TDD測試驅動開發(fā) 1.TDD的節(jié)奏 2.TDD的兩個原則和TDD的目標 3.TDD與行為驅動開發(fā)（Behaviour Driven Development） 4.TDD與驗收測試驅動開發(fā)（Acceptance Test Driven Development） 5.識別代碼中的壞味道 6.重構工具及使用 7.常用重構技巧 8.重構與預先設計的區(qū)別 9.通過案例分析，TDD的最佳實踐技巧，重構的技巧，壞味道等 |
|
歷史遺留系統(tǒng)如何編寫單元測試 內容一：遺留系統(tǒng)代碼環(huán)境下如何編寫單元測試 1.從哪里開始添加單元測試 2.確定抉擇策略1-容易優(yōu)先測類的優(yōu)缺點 3.確定抉擇策略2-困難優(yōu)先測類的優(yōu)缺點 4.遺留代碼改動準則 5.重構前寫集成測試 6.遺留代碼整潔測試的常用工具 7.為第三方代碼做學習測試 8.復雜遺留系統(tǒng)之中，如何增加單元測試以及遇到的問題 9.通過真實案例分析，在遺留系統(tǒng)的的難度和最佳實踐 |
|
單元測試組織和管理 內容一：組織和管理測試 1.通過自動構建腳本運行測試 2.將測試與代碼做同源版本管理 3.根據速度和類型為測試分類 4.創(chuàng)建和維護項目的測試輔助設施 5.結合我們研發(fā)中心， 如何做單元測試管理， 已經如何組織，以及遇到的問題 |
|
在研發(fā)團隊如何引入單元測試 內容一：將測試引入到你的組織中 1.如何成功在組織中引入單元測試 2.為什么在組織中引入單元測試的努力會失敗 3.如何將測試集成到開發(fā)流程中 - 敏捷測試流程 4.常見的疑惑和解答? 5.通過多個研發(fā)中心咨詢經驗，分析單元測試引入的方式和最佳實踐 |
近期公開課推薦
