测试发展趋势

互联网与数字化的发展要求

DevOps时代来临

测试目前发展趋势，是否可以解决当前问题

测试是否拖累当前所有的进度，问题有哪些

测试 模型：金字塔、纺锤、冰淇淋等

部分传统方法是否可以解决当前问题

测试发展的误区

测试跟随着开发的模式

测试想跟随需求，但落地方法错误

变更，无法跟上节奏感

传统企业，面临的双峰挑战（稳态+敏态）

团队与人员的阻碍

文档的更新模式

DevOps是否可以解决问题

测试模式的根源挖掘与适用场景

国外的业务发展模式与国内的区别

BDD的适应场景，团队与人员要求

TDD的适应场景，团队与人员要求

ATDD的适应场景，团队与人员要求

关键字的适应场景，团队与人员要求

敏捷测试的适应性与发展限制

分级测试的提出与互联网应对

微服务下契约测试的提出与团队要求

复杂业务测试问题的根源分析

双峰挑战下的测试模式

传统企业，为何无法适应上述测试模式（国外引入水土不服）

持续集成带来的持续测试，是否解决了根本性问题？

人才发展的限制与团队瓶颈

CI/CD下的分层测试

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

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

3. 分层测试说明和规范

4. CD/CD构建简要介绍

5.度量数据驱动改进

分层自动化

1. 目的

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

3. 分层自动化的构成

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

5. 分层自动化实现举例

6. 其他有效参考

自动化测试嵌入到持续集成中

持续集成工具Jenkins

Jenkins的使用与原理

Jenkins构建

使用Jenkins提高代码质量

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

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

思路：业务需求+技术需求+监管需求+旁路影响分支需求

需求—>开发—>测试：传统为阶乘式增长，无法维护

测试建模的方法与原理，对应解决的问题

DevOps只是工具链的建立，测试建模真正解决测试端的问题

曾经的弯路：微软测试建模走偏

测试建模，本质上解决了维护性代价的问题，但为何无法成功实施

测试建模的分析

分析：旧有模式仍然为离散式的跟踪，跟随开发

抛弃工具绑定的思想

1vs1的思路，跟踪需求（业务+技术+监管+旁路）

需求端直接生成用例与脚本，真正为TDD

作者在美国4年和中国5年的构建实例

测试建模的落地构建方案

前置：统一需求矩阵的建立

有限状态机的演化：与等价类、边界值的穷举结合

核心：测试建模—>与需求的1对1标准匹配（业务、技术、监管）

边界建模：流程数据集中营，来应对不同的开发架构：巨石、SOA、微服务或者复合型

工具沦落到最外层非核心，随意更换适配引擎

解决问题：变更的快捷定位、准确性、可追踪与回溯、易于重构

解决问题：易于重构、不关联和影响开发技术、不被工具绑架

解决问题：重写了TDD与BDD模式，但适合复杂业务流程

解决问题：知识的规则化沉淀，自动驱动与融合

测试建模平台落地方案与演示Demo

整体架构

笛卡尔乘积的构建

有限状态机的构建

中间存储矩阵构建

统一的展现平台，外接不同的引擎

传统平台的功能：权限管理、项目管理、报表分析等等

植入监控与反馈

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

测试建模应用化工具模型

接口测试

GUI测试

安全性测试接入

行业性监管要求加入

不同行业的要求

与传统模式的效率对比

所需团队能力与投入

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

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

维护阶段团队要求与投入

可能的风险与不适应性

项目规模与投入

人员能力影响

技术风险

行政风险