教學優勢
曙海教育的課程培養了大批受企業歡迎的工程師。大批企業和曙海
建立了良好的合作關系。曙海集團的課程在業內有著廣泛的美譽度和響亮的知名度。
秉承二十幾年積累的教學品質，本課程以真實項目實戰為導向,授課工程師將會與您分享設計的全流程及工具的綜合使用技巧、經驗。
| 測試發展趨勢 | 1、互聯網與數字化的發展要求 2、DevOps時代來臨 3、測試目前發展趨勢，是否可以解決當前問題 4、測試是否拖累當前所有的進度，問題有哪些 5、測試 模型：金字塔、紡錘、冰淇淋等 6、部分傳統方法是否可以解決當前問題 |
| 測試發展的誤區 | 1、測試跟隨著開發的模式 2、測試想跟隨需求，但落地方法錯誤 3、變更，無法跟上節奏感 4、傳統企業，面臨的雙峰挑戰（穩態+敏態） 5、團隊與人員的阻礙 6、文檔的更新模式 7、DevOps是否可以解決問題 |
| 測試模式的根源挖掘與適用場景 | 1、國外的業務發展模式與國內的區別 2、BDD的適應場景，團隊與人員要求 3、TDD的適應場景，團隊與人員要求 4、ATDD的適應場景，團隊與人員要求 5、關鍵字的適應場景，團隊與人員要求 6、敏捷測試的適應性與發展限制 7、分級測試的提出與互聯網應對 8、微服務下契約測試的提出與團隊要求 |
| 復雜業務測試問題的根源分析 | 1、雙峰挑戰下的測試模式 2、傳統企業，為何無法適應上述測試模式（國外引入水土不服） 3、持續集成帶來的持續測試，是否解決了根本性問題？ 4、人才發展的限制與團隊瓶頸 |
| 測試思維的切換：測試建模 | 1、思路：業務需求+技術需求+監管需求+旁路影響分支需求 2、需求—>開發—>測試：傳統為階乘式增長，無法維護 3、測試建模的方法與原理，對應解決的問題 4、DevOps只是工具鏈的建立，測試建模真正解決測試端的問題 5、曾經的彎路：微軟測試建模走偏 6、測試建模，本質上解決了維護性代價的問題，但為何無法成功實施 |
| 測試建模的分析 | 1、分析：舊有模式仍然為離散式的跟蹤，跟隨開發 2、拋棄工具綁定的思想 3、1vs1的思路，跟蹤需求（業務+技術+監管+旁路） 4、需求端直接生成用例與腳本，真正為TDD 5、作者在美國4年和中國5年的構建實例 |
| 測試建模的落地構建方案 | 1、前置：統一需求矩陣的建立 2、有限狀態機的演化：與等價類、邊界值的窮舉結合 3、核心：測試建模—>與需求的1對1標準匹配（業務、技術、監管） 4、邊界建模：流程數據集中營，來應對不同的開發架構：巨石、SOA、微服務或者復合型 5、工具淪落到最外層非核心，隨意更換適配引擎 6、解決問題：變更的快捷定位、準確性、可追蹤與回溯、易于重構 7、解決問題：易于重構、不關聯和影響開發技術、不被工具綁架 8、解決問題：重寫了TDD與BDD模式，但適合復雜業務流程 9、解決問題：知識的規則化沉淀，自動驅動與融合 |
| 測試建模平臺落地方案與演示Demo | 1、整體架構 2、笛卡爾乘積的構建 3、有限狀態機的構建 4、中間存儲矩陣構建 5、統一的展現平臺，外接不同的引擎 6、傳統平臺的功能：權限管理、項目管理、報表分析等等 植入監控與反饋 7、鏈接到DevOps平臺，與需求對接，映射開發 |
| 測試建模應用化舉例 | 1、接口測試 2、GUI測試 3、行業性監管要求加入 4、不同行業的要求 5、與傳統模式的效率對比 |
| 所需團隊能力與投入 | 1、構建核心框架/平臺的團隊能力與投入 2、項目過程中，人員能力與投入 3、維護階段團隊要求與投入 |
| 可能的風險與不適應性 | 1、項目規模與投入 2、人員能力影響 3、技術風險 4、行政風險 |
