Download to read offline
20181121 ch12 managing data ii
- 1. 優像數位媒體科技股份有限公司 PIXNET DIGITAL MEDIACORPORATION 小明 Continuous Delivery CH12 資料管理 2018.11.22
- 2. 資料理管章節 ● 資料庫腳本化 DatabaseScripting ● 增量式修改 Incremental Change ● 還原資料庫與無停機發佈 Rolling Backup Detabases and Zero-Downtime Releases ● 管理測試資料 Managing Test Data ● 資料管理和部署流水線 Data Management and Deployment Pipeline
- 3. 章節重點 可控制的輸入 被定義好的環境 測試過試避免資料被修改 注意測試順序 ✓ ✓ ✓ ✓ 快一點完成 單元測試 vs 記憶體 細心管理測試資料 盡量不要用Prod. DB Dump ✓ ✓ ✓ ✓ 測試效能 測試獨立性
- 4. 單元測試用假資料 測試替身 Test Double ●Dummy - 不會被用的假資料 ● Fake - 實作假函式 ● Stub - 會被用到的假資料 ● Mock - 只要確認函式是否有被呼 叫 ● Spy - 類似Stub，紀錄成員和SUT 互動是否正確 https://oomusou.io/jasmine/jasmine-test-double/ http://teddy-chen-tw.blogspot.com/2014/09/test-double2.html 可改用假資料庫 H2、SQLite、JavaDB
- 5. 管理測試與資料間的耦合 ● 測試獨立性 testisolation ○ 原子性 ○ 不受其他測試影響 ● 調整性測試 adaptive tests ○ 先檢查資料環境 ● 測試的順序性 test sequencing ○ 測試間有一定順序，前一個輸出為後一個輸入 推薦使用 擴展性不佳 測試間相性漸增 測試套件維護不易
- 6. 連貫測試場景 Coberent TestScenarios 測試初始資料 測試結束 復歸 測試 測試 測試 測試 結束 初始 資料 …... 復歸 1. 緊密耦合 2. 重工 3. 成功、失敗條件不易定義
- 7. 資料管理和部署流水線 ● 提交階段的測試資料 ● 驗收測試中的資料 ●容量測試的資料 ● 其他測試階段的資料
- 8. 提交階段的測試資料 ● 需快速，每增加 30s會增加很多成本? ● 防止『因疏忽大意而修改系統』之錯誤 ● 測試相依性 vs 重構 ←→ 緊密耦合 ● 解耦合 → 拆成多個獨立元件和測試 + Test Doubles ● 用最少的測試資料 → 獲得受測單元結果 ● 準備共用測試資料 資料管理和部署流水線
- 9. 驗收測試中的資料 ● 驗收測試 =系統測試 → 測試更複雜 ● 減少測試與資料的相依性 ● 多利用 API 以確定測試狀態 資料管理和部署流水線 驗收測試 專屬資料 引用資料 應用程式 專屬資料 ● 主角 ● 必須唯一 ● 必須隔離 ● 非主角，要支援 ● 屬於種子資料 ● 建立通用環境 ● 和測試無關 ● 只和應用程式有關 ● 不影響測試結果 ● 避免測試不一致 ● 資料庫重構不影響 驗收測試 ● 一併測試API
- 10. 容量測試的資料 ● 容量測試 →規模問題 ○ 輸入資料是否足夠？ ○ 適當引用資料以支援多種案例 ● 想想訂單、訂票，短時間一堆訂單 → 如何擴容 資料管理和部署流水線
- 11. 其他測試階段的資料 ● 驗收測試後的自動化測試都用相同方法 ● 行為規範（specificationsof behavior） ● 手動測試（探索性測試、使用者驗收測試） ○ 採用最小測試資料模擬程式剛起動之狀態 ○ 載入大量測試資料模擬程式執行一段時間之狀態 ● 不建議直接採用 Prod. 資料副本，雖然大部份可行 ○ 資料太多、匯入轉移過長 ● 改採用 Prod. 資料子集，或用驗收測試或容量測試後的 資料 資料管理和部署流水線
- 12. 小結 ● 管理資料的基本原則 ○ 建立資料庫 ○遷移資料庫 ● 重覆性、可靠性 ● 佈署、最小集合驗收測試、遷移 Prod. 資料子集到 Prod. 環境 → 都用相同流程（自動化） ● 盡量不要用 Prod. 資料庫副本 自動化流程
- 13. 小結 ● 使用自動化遷移流程並管理資料庫版本 ● 盡量確保DB Schema 能向前或向後修改之相容性 ● 測試資料彼此分開 ● 只保存共享且應用程式啟 動需要用到的資料，及常用的 引用資料 ● 盡量使用API ● 盡量不要用 Prod. 資料庫副本，但可採用子集合
- 14.