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