          分級測試與測試建模DevOps體系培訓

1 測試發展趨勢
1.1 互聯網與數字化的發展要求
1.2 DevOps時代來臨
1.3 測試目前發展趨勢，是否可以解決當前問題
1.4 測試是否拖累當前所有的進度，問題有哪些
1.5 測試 模型：金字塔、紡錘、冰淇淋等
1.6 部分傳統方法是否可以解決當前問題
2 測試發展的誤區
2.1 測試跟隨著開發的模式
2.2 測試想跟隨需求，但落地方法錯誤
2.3 變更，無法跟上節奏感
2.4 傳統企業，面臨的雙峰挑戰（穩態+敏態）
2.5 團隊與人員的阻礙
2.6 文檔的更新模式
2.7 DevOps是否可以解決問題
3 測試模式的根源挖掘與適用場景
3.1 國外的業務發展模式與國內的區別
3.2 BDD的適應場景，團隊與人員要求
3.3 TDD的適應場景，團隊與人員要求
3.4 ATDD的適應場景，團隊與人員要求
3.5 關鍵字的適應場景，團隊與人員要求
3.6 敏捷測試的適應性與發展限制
3.7 分級測試的提出與互聯網應對
3.8 微服務下契約測試的提出與團隊要求
4 復雜業務測試問題的根源分析
4.1 雙峰挑戰下的測試模式
4.2 傳統企業，為何無法適應上述測試模式（國外引入水土不服）
4.3 持續集成帶來的持續測試，是否解決了根本性問題？
4.4 人才發展的限制與團隊瓶頸
5 CI/CD下的分層測試
5.1 測試標準化構建和構建通訊
5.2 1-5-15-60分級質量模型
5.3 分層測試說明和規范
5.4 CD/CD構建簡要介紹
5.5 度量數據驅動改進
6 分層自動化
6.1 目的
6.2 大型系統持續交付難點
6.3 分層自動化的構成
6.4 分成自動化的過程管理實踐舉例
6.5 分層自動化實現舉例
6.6 其他有效參考
7 自動化測試嵌入到持續集成中
7.1 持續集成工具Jenkins
7.2 Jenkins的使用與原理
7.3 Jenkins構建
7.4 使用Jenkins提高代碼質量
7.5 鏈接Jenkins到各端的自動化測試
8 測試思維的切換：測試建模
8.1 思路：業務需求+技術需求+監管需求+旁路影響分支需求
8.2 需求—>開發—>測試：傳統為階乘式增長，無法維護
8.3 測試建模的方法與原理，對應解決的問題
8.4 DevOps只是工具鏈的建立，測試建模真正解決測試端的問題
8.5 曾經的彎路：微軟測試建模走偏
8.6 測試建模，本質上解決了維護性代價的問題，但為何無法成功實施
9 測試建模的分析
9.1 分析：舊有模式仍然為離散式的跟蹤，跟隨開發
9.2 拋棄工具綁定的思想
9.3 1vs1的思路，跟蹤需求（業務+技術+監管+旁路）
9.4 需求端直接生成用例與腳本，真正為TDD
9.5 作者在美國4年和中國5年的構建實例
10 測試建模的落地構建方案
10.1 前置：統一需求矩陣的建立
10.2 有限狀態機的演化：與等價類、邊界值的窮舉結合
10.3 核心：測試建?！?gt;與需求的1對1標準匹配（業務、技術、監管）
10.4 邊界建模：流程數據集中營，來應對不同的開發架構：巨石、SOA、微服務或者復合型
10.5 工具淪落到外層非核心，隨意更換適配引擎
10.6 解決問題：變更的快捷定位、準確性、可追蹤與回溯、易于重構
10.7 解決問題：易于重構、不關聯和影響開發技術、不被工具綁架
10.8 解決問題：重寫了TDD與BDD模式，但適合復雜業務流程
10.9 解決問題：知識的規則化沉淀，自動驅動與融合
11 測試建模平臺落地方案與演示Demo
11.1 整體架構
11.2 笛卡爾乘積的構建
11.3 有限狀態機的構建
11.4 中間存儲矩陣構建
11.5 統一的展現平臺，外接不同的引擎
11.6 傳統平臺的功能：權限管理、項目管理、報表分析等等
11.7 植入監控與反饋
11.8 鏈接到DevOps平臺，與需求對接，映射開發
12 測試建模應用化工具模型
12.1 接口測試
12.2 GUI測試
12.3 安全性測試接入
12.4 行業性監管要求加入
12.5 不同行業的要求
12.6 與傳統模式的效率對比
13 所需團隊能力與投入
14 可能的風險與不適應性