课程简介
当前时代已经进入到DevOps的自动化测试时代，由于运维的快速持续交付，开发的敏捷化开发与持续集成，让交付速度越来越快。 但是在越来越快的交付下，手工测试无法进行满足交付速度，而传统的自动化测试，也无法覆盖需求和应对快速的需求变更。
BDD、TDD、ATDD对于简单业务可以做到快速覆盖与需求对应的快速变更，但是，复杂的业务模式下，如金融、电信、能源、汽车、ERP、甚至复杂的互联网需求，BDD与ATDD等无法应对需求的快速变更。
所以，本次课程通过3个阶段：测试建模（测试用例自我生成），自我构建关系链路（测试场景自匹配）、工具胶水层与适配层（接入各种自动化测试工具），来描述在复杂业务模式下，当需求变更，如何应对并产生自适应的自动化测试规则与脚本。
目标收益
1. 掌握需求建模方式
2. 掌握复杂业务的测试建模
3. 掌握如何构建场景的自我生成关系
4. 掌握胶水层概念
5. 掌握接入框架的模式
培训对象
相关测试人员
课程大纲
| 测试发展趋势 |
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、行政风险 |
|
测试发展趋势 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、行政风险 |
近期公开课推荐
