模块一：测试发展趋势

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. 人才发展的限制与团队瓶颈

模块五：CI/CD下的分层测试

1. 测试标准化构建和构建通讯

2. 1-5-15-60分级质量模型

3. 分层测试说明和规范

4. CD/CD构建简要介绍

5.度量数据驱动改进

模块六：分层自动化

1. 目的

2. 大型系统持续交付难点

3. 分层自动化的构成

4. 分成自动化的过程管理实践举例

5. 分层自动化实现举例

6. 其他有效参考

模块七：自动化测试嵌入到持续集成中

1. 持续集成工具Jenkins

2. Jenkins的使用与原理

3. Jenkins构建

4. 使用Jenkins提高代码质量

5. 链接Jenkins到各端的自动化测试

模块八：测试思维的切换：测试建模

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. 植入监控与反馈

8. 链接到DevOps平台，与需求对接，映射开发

模块十二：测试建模应用化工具模型

1. 接口测试

2. GUI测试

3. 安全性测试接入

4. 行业性监管要求加入

5. 不同行业的要求

6. 与传统模式的效率对比

模块十三：所需团队能力与投入

1. 构建核心框架/平台的团队能力与投入

2. 项目过程中，人员能力与投入

3. 维护阶段团队要求与投入

模块十四：可能的风险与不适应性

1. 项目规模与投入

2. 人员能力影响

3. 技术风险

4. 行政风险