          分級(jí)測試與測試建模DevOps體系培訓(xùn)

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