課程簡介
當(dāng)前時(shí)代已經(jīng)進(jìn)入到DevOps的自動(dòng)化測(cè)試時(shí)代，由于運(yùn)維的快速持續(xù)交付，開發(fā)的敏捷化開發(fā)與持續(xù)集成，讓交付速度越來越快。 但是在越來越快的交付下，手工測(cè)試無法進(jìn)行滿足交付速度，而傳統(tǒng)的自動(dòng)化測(cè)試，也無法覆蓋需求和應(yīng)對(duì)快速的需求變更。
BDD、TDD、ATDD對(duì)于簡單業(yè)務(wù)可以做到快速覆蓋與需求對(duì)應(yīng)的快速變更，但是，復(fù)雜的業(yè)務(wù)模式下，如金融、電信、能源、汽車、ERP、甚至復(fù)雜的互聯(lián)網(wǎng)需求，BDD與ATDD等無法應(yīng)對(duì)需求的快速變更。
所以，本次課程通過3個(gè)階段：測(cè)試建模（測(cè)試用例自我生成），自我構(gòu)建關(guān)系鏈路（測(cè)試場(chǎng)景自匹配）、工具膠水層與適配層（接入各種自動(dòng)化測(cè)試工具），來描述在復(fù)雜業(yè)務(wù)模式下，當(dāng)需求變更，如何應(yīng)對(duì)并產(chǎn)生自適應(yīng)的自動(dòng)化測(cè)試規(guī)則與腳本。
目標(biāo)收益
1. 掌握需求建模方式
2. 掌握復(fù)雜業(yè)務(wù)的測(cè)試建模
3. 掌握如何構(gòu)建場(chǎng)景的自我生成關(guān)系
4. 掌握膠水層概念
5. 掌握接入框架的模式
培訓(xùn)對(duì)象
相關(guān)測(cè)試人員
課程大綱
| 測(cè)試發(fā)展趨勢(shì) |
1、互聯(lián)網(wǎng)與數(shù)字化的發(fā)展要求 2、DevOps時(shí)代來臨 3、測(cè)試目前發(fā)展趨勢(shì)，是否可以解決當(dāng)前問題 4、測(cè)試是否拖累當(dāng)前所有的進(jìn)度，問題有哪些 5、測(cè)試 模型：金字塔、紡錘、冰淇淋等 6、部分傳統(tǒng)方法是否可以解決當(dāng)前問題 |
| 測(cè)試發(fā)展的誤區(qū) |
1、測(cè)試跟隨著開發(fā)的模式 2、測(cè)試想跟隨需求，但落地方法錯(cuò)誤 3、變更，無法跟上節(jié)奏感 4、傳統(tǒng)企業(yè)，面臨的雙峰挑戰(zhàn)（穩(wěn)態(tài)+敏態(tài)） 5、團(tuán)隊(duì)與人員的阻礙 6、文檔的更新模式 7、DevOps是否可以解決問題 |
| 測(cè)試模式的根源挖掘與適用場(chǎng)景 |
1、國外的業(yè)務(wù)發(fā)展模式與國內(nèi)的區(qū)別 2、BDD的適應(yīng)場(chǎng)景，團(tuán)隊(duì)與人員要求 3、TDD的適應(yīng)場(chǎng)景，團(tuán)隊(duì)與人員要求 4、ATDD的適應(yīng)場(chǎng)景，團(tuán)隊(duì)與人員要求 5、關(guān)鍵字的適應(yīng)場(chǎng)景，團(tuán)隊(duì)與人員要求 6、敏捷測(cè)試的適應(yīng)性與發(fā)展限制 7、分級(jí)測(cè)試的提出與互聯(lián)網(wǎng)應(yīng)對(duì) 8、微服務(wù)下契約測(cè)試的提出與團(tuán)隊(duì)要求 |
| 復(fù)雜業(yè)務(wù)測(cè)試問題的根源分析 |
1、雙峰挑戰(zhàn)下的測(cè)試模式 2、傳統(tǒng)企業(yè)，為何無法適應(yīng)上述測(cè)試模式（國外引入水土不服） 3、持續(xù)集成帶來的持續(xù)測(cè)試，是否解決了根本性問題？ 4、人才發(fā)展的限制與團(tuán)隊(duì)瓶頸 |
| 測(cè)試思維的切換：測(cè)試建模 |
1、思路：業(yè)務(wù)需求+技術(shù)需求+監(jiān)管需求+旁路影響分支需求 2、需求—>開發(fā)—>測(cè)試：傳統(tǒng)為階乘式增長，無法維護(hù) 3、測(cè)試建模的方法與原理，對(duì)應(yīng)解決的問題 4、DevOps只是工具鏈的建立，測(cè)試建模真正解決測(cè)試端的問題 5、曾經(jīng)的彎路：微軟測(cè)試建模走偏 6、測(cè)試建模，本質(zhì)上解決了維護(hù)性代價(jià)的問題，但為何無法成功實(shí)施 |
| 測(cè)試建模的分析 |
1、分析：舊有模式仍然為離散式的跟蹤，跟隨開發(fā) 2、拋棄工具綁定的思想 3、1vs1的思路，跟蹤需求（業(yè)務(wù)+技術(shù)+監(jiān)管+旁路） 4、需求端直接生成用例與腳本，真正為TDD 5、作者在美國4年和中國5年的構(gòu)建實(shí)例 |
| 測(cè)試建模的落地構(gòu)建方案 |
1、前置：統(tǒng)一需求矩陣的建立 2、有限狀態(tài)機(jī)的演化：與等價(jià)類、邊界值的窮舉結(jié)合 3、核心：測(cè)試建?！?與需求的1對(duì)1標(biāo)準(zhǔn)匹配（業(yè)務(wù)、技術(shù)、監(jiān)管） 4、邊界建模：流程數(shù)據(jù)集中營，來應(yīng)對(duì)不同的開發(fā)架構(gòu)：巨石、SOA、微服務(wù)或者復(fù)合型 5、工具淪落到最外層非核心，隨意更換適配引擎 6、解決問題：變更的快捷定位、準(zhǔn)確性、可追蹤與回溯、易于重構(gòu) 7、解決問題：易于重構(gòu)、不關(guān)聯(lián)和影響開發(fā)技術(shù)、不被工具綁架 8、解決問題：重寫了TDD與BDD模式，但適合復(fù)雜業(yè)務(wù)流程 9、解決問題：知識(shí)的規(guī)則化沉淀，自動(dòng)驅(qū)動(dòng)與融合 |
| 測(cè)試建模平臺(tái)落地方案與演示Demo |
1、整體架構(gòu) 2、笛卡爾乘積的構(gòu)建 3、有限狀態(tài)機(jī)的構(gòu)建 4、中間存儲(chǔ)矩陣構(gòu)建 5、統(tǒng)一的展現(xiàn)平臺(tái)，外接不同的引擎 6、傳統(tǒng)平臺(tái)的功能：權(quán)限管理、項(xiàng)目管理、報(bào)表分析等等 植入監(jiān)控與反饋 7、鏈接到DevOps平臺(tái)，與需求對(duì)接，映射開發(fā) |
| 測(cè)試建模應(yīng)用化舉例 |
1、接口測(cè)試 2、GUI測(cè)試 3、行業(yè)性監(jiān)管要求加入 4、不同行業(yè)的要求 5、與傳統(tǒng)模式的效率對(duì)比 |
| 所需團(tuán)隊(duì)能力與投入 |
1、構(gòu)建核心框架/平臺(tái)的團(tuán)隊(duì)能力與投入 2、項(xiàng)目過程中，人員能力與投入 3、維護(hù)階段團(tuán)隊(duì)要求與投入 |
| 可能的風(fēng)險(xiǎn)與不適應(yīng)性 |
1、項(xiàng)目規(guī)模與投入 2、人員能力影響 3、技術(shù)風(fēng)險(xiǎn) 4、行政風(fēng)險(xiǎn) |
|
測(cè)試發(fā)展趨勢(shì) 1、互聯(lián)網(wǎng)與數(shù)字化的發(fā)展要求 2、DevOps時(shí)代來臨 3、測(cè)試目前發(fā)展趨勢(shì)，是否可以解決當(dāng)前問題 4、測(cè)試是否拖累當(dāng)前所有的進(jìn)度，問題有哪些 5、測(cè)試 模型：金字塔、紡錘、冰淇淋等 6、部分傳統(tǒng)方法是否可以解決當(dāng)前問題 |
|
測(cè)試發(fā)展的誤區(qū) 1、測(cè)試跟隨著開發(fā)的模式 2、測(cè)試想跟隨需求，但落地方法錯(cuò)誤 3、變更，無法跟上節(jié)奏感 4、傳統(tǒng)企業(yè)，面臨的雙峰挑戰(zhàn)（穩(wěn)態(tài)+敏態(tài)） 5、團(tuán)隊(duì)與人員的阻礙 6、文檔的更新模式 7、DevOps是否可以解決問題 |
|
測(cè)試模式的根源挖掘與適用場(chǎng)景 1、國外的業(yè)務(wù)發(fā)展模式與國內(nèi)的區(qū)別 2、BDD的適應(yīng)場(chǎng)景，團(tuán)隊(duì)與人員要求 3、TDD的適應(yīng)場(chǎng)景，團(tuán)隊(duì)與人員要求 4、ATDD的適應(yīng)場(chǎng)景，團(tuán)隊(duì)與人員要求 5、關(guān)鍵字的適應(yīng)場(chǎng)景，團(tuán)隊(duì)與人員要求 6、敏捷測(cè)試的適應(yīng)性與發(fā)展限制 7、分級(jí)測(cè)試的提出與互聯(lián)網(wǎng)應(yīng)對(duì) 8、微服務(wù)下契約測(cè)試的提出與團(tuán)隊(duì)要求 |
|
復(fù)雜業(yè)務(wù)測(cè)試問題的根源分析 1、雙峰挑戰(zhàn)下的測(cè)試模式 2、傳統(tǒng)企業(yè)，為何無法適應(yīng)上述測(cè)試模式（國外引入水土不服） 3、持續(xù)集成帶來的持續(xù)測(cè)試，是否解決了根本性問題？ 4、人才發(fā)展的限制與團(tuán)隊(duì)瓶頸 |
|
測(cè)試思維的切換：測(cè)試建模 1、思路：業(yè)務(wù)需求+技術(shù)需求+監(jiān)管需求+旁路影響分支需求 2、需求—>開發(fā)—>測(cè)試：傳統(tǒng)為階乘式增長，無法維護(hù) 3、測(cè)試建模的方法與原理，對(duì)應(yīng)解決的問題 4、DevOps只是工具鏈的建立，測(cè)試建模真正解決測(cè)試端的問題 5、曾經(jīng)的彎路：微軟測(cè)試建模走偏 6、測(cè)試建模，本質(zhì)上解決了維護(hù)性代價(jià)的問題，但為何無法成功實(shí)施 |
|
測(cè)試建模的分析 1、分析：舊有模式仍然為離散式的跟蹤，跟隨開發(fā) 2、拋棄工具綁定的思想 3、1vs1的思路，跟蹤需求（業(yè)務(wù)+技術(shù)+監(jiān)管+旁路） 4、需求端直接生成用例與腳本，真正為TDD 5、作者在美國4年和中國5年的構(gòu)建實(shí)例 |
|
測(cè)試建模的落地構(gòu)建方案 1、前置：統(tǒng)一需求矩陣的建立 2、有限狀態(tài)機(jī)的演化：與等價(jià)類、邊界值的窮舉結(jié)合 3、核心：測(cè)試建?！?與需求的1對(duì)1標(biāo)準(zhǔn)匹配（業(yè)務(wù)、技術(shù)、監(jiān)管） 4、邊界建模：流程數(shù)據(jù)集中營，來應(yīng)對(duì)不同的開發(fā)架構(gòu)：巨石、SOA、微服務(wù)或者復(fù)合型 5、工具淪落到最外層非核心，隨意更換適配引擎 6、解決問題：變更的快捷定位、準(zhǔn)確性、可追蹤與回溯、易于重構(gòu) 7、解決問題：易于重構(gòu)、不關(guān)聯(lián)和影響開發(fā)技術(shù)、不被工具綁架 8、解決問題：重寫了TDD與BDD模式，但適合復(fù)雜業(yè)務(wù)流程 9、解決問題：知識(shí)的規(guī)則化沉淀，自動(dòng)驅(qū)動(dòng)與融合 |
|
測(cè)試建模平臺(tái)落地方案與演示Demo 1、整體架構(gòu) 2、笛卡爾乘積的構(gòu)建 3、有限狀態(tài)機(jī)的構(gòu)建 4、中間存儲(chǔ)矩陣構(gòu)建 5、統(tǒng)一的展現(xiàn)平臺(tái)，外接不同的引擎 6、傳統(tǒng)平臺(tái)的功能：權(quán)限管理、項(xiàng)目管理、報(bào)表分析等等 植入監(jiān)控與反饋 7、鏈接到DevOps平臺(tái)，與需求對(duì)接，映射開發(fā) |
|
測(cè)試建模應(yīng)用化舉例 1、接口測(cè)試 2、GUI測(cè)試 3、行業(yè)性監(jiān)管要求加入 4、不同行業(yè)的要求 5、與傳統(tǒng)模式的效率對(duì)比 |
|
所需團(tuán)隊(duì)能力與投入 1、構(gòu)建核心框架/平臺(tái)的團(tuán)隊(duì)能力與投入 2、項(xiàng)目過程中，人員能力與投入 3、維護(hù)階段團(tuán)隊(duì)要求與投入 |
|
可能的風(fēng)險(xiǎn)與不適應(yīng)性 1、項(xiàng)目規(guī)模與投入 2、人員能力影響 3、技術(shù)風(fēng)險(xiǎn) 4、行政風(fēng)險(xiǎn) |
近期公開課推薦
