DevOps下的测试方法：基于需求的测试建模，自动化实现

教练：J.W

文思海辉

汪珺，Exin DevOps Master TTT首批认证授权讲师（中国区共7人）， 凤凰项目沙盘认证授权教练（共8人），挑战埃及沙盘认证权限讲师（共3人），原HP金牌讲师，经历Kuwo、HP、Fannie Mae（两房）、交通银行、兴业银行、浦发银行、美国航空、星巴克等大型测试项目，并在多家外包公司前后经历多达百计的不同类型测试项目，在项目管理、敏捷、体系建设与质量建设、架构、测试和安全等有丰富的十多年实战经验与授课经验。 目前专注于将测试体系和技术融入到DevOps生态链中。

主题

内容

测试发展趋势

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、行政风险