分级测试与复杂系统自动化测试建模实践

分级测试与复杂系统自动化测试建模实践
    马上咨询

    汪珺 开发测试架构师资深咨询师、资深培训师

    原HP中国金牌讲师、HP美国敏捷咨询师、资深咨询师、资深培训师、Exin TTT授权培训讲师(ScrumMaster、Lean、Tmap、DevOpsMaster等)。凤凰项目沙盘认证授权教练,挑战埃及沙盘认证权限讲师,敏捷和DevOps落地转型专家,解决方案专家,某跨国集团解决方案部门总监。

    课程简介

    整个课程覆盖了测试的全链路:分级测试、分层自动化、测试建模、复杂业务测试问题的根源分析、测试建模的落地构建方案等

    课程大纲(课程讲授内容比例会根据课前调查问卷,调整各模块的比例和讲解深浅度)

    测试发展趋势
    互联网与数字化的发展要求
    DevOps时代来临
    测试目前发展趋势,是否可以解决当前问题
    测试是否拖累当前所有的进度,问题有哪些
    测试 模型:金字塔、纺锤、冰淇淋等
    部分传统方法是否可以解决当前问题
    测试发展的误区
    测试跟随着开发的模式
    测试想跟随需求,但落地方法错误
    变更,无法跟上节奏感
    传统企业,面临的双峰挑战(稳态+敏态)
    团队与人员的阻碍
    文档的更新模式
    DevOps是否可以解决问题
    测试模式的根源挖掘与适用场景
    国外的业务发展模式与国内的区别
    BDD的适应场景,团队与人员要求
    TDD的适应场景,团队与人员要求
    ATDD的适应场景,团队与人员要求
    关键字的适应场景,团队与人员要求
    敏捷测试的适应性与发展限制
    分级测试的提出与互联网应对
    微服务下契约测试的提出与团队要求
    复杂业务测试问题的根源分析
    双峰挑战下的测试模式
    传统企业,为何无法适应上述测试模式(国外引入水土不服)
    持续集成带来的持续测试,是否解决了根本性问题?
    人才发展的限制与团队瓶颈
    分层测试
    1. 测试标准化构建和构建通讯
    2. 1-5-15-60分级质量模型
    3. 分层测试说明和规范
    4. CD/CD构建简要介绍
    5.度量数据驱动改进
    分层自动化
    1. 目的
    2. 大型系统持续交付难点
    3. 分层自动化的构成
    4. 分成自动化的过程管理实践举例
    5. 分层自动化实现举例
    6. 其他有效参考
    测试思维的切换:测试建模
    思路:业务需求+技术需求+监管需求+旁路影响分支需求
    需求—>开发—>测试:传统为阶乘式增长,无法维护
    测试建模的方法与原理,对应解决的问题
    DevOps只是工具链的建立,测试建模真正解决测试端的问题
    曾经的弯路:微软测试建模走偏
    测试建模,本质上解决了维护性代价的问题,但为何无法成功实施
    测试建模的分析
    分析:旧有模式仍然为离散式的跟踪,跟随开发
    抛弃工具绑定的思想
    1vs1的思路,跟踪需求(业务+技术+监管+旁路)
    需求端直接生成用例与脚本,真正为TDD
    作者在美国4年和中国5年的构建实例
    测试建模的落地构建方案
    前置:统一需求矩阵的建立
    有限状态机的演化:与等价类、边界值的穷举结合
    核心:测试建模—>与需求的1对1标准匹配(业务、技术、监管)
    边界建模:流程数据集中营,来应对不同的开发架构:巨石、SOA、微服务或者复合型
    工具沦落到最外层非核心,随意更换适配引擎
    解决问题:变更的快捷定位、准确性、可追踪与回溯、易于重构
    解决问题:易于重构、不关联和影响开发技术、不被工具绑架
    解决问题:重写了TDD与BDD模式,但适合复杂业务流程
    解决问题:知识的规则化沉淀,自动驱动与融合
    测试建模平台落地方案与演示Demo
    整体架构
    笛卡尔乘积的构建
    有限状态机的构建
    中间存储矩阵构建
    统一的展现平台,外接不同的引擎
    传统平台的功能:权限管理、项目管理、报表分析等等
    植入监控与反馈
    链接到DevOps平台,与需求对接,映射开发
    测试建模应用化举例
    接口测试
    GUI测试
    行业性监管要求加入
    不同行业的要求
    与传统模式的效率对比
    所需团队能力与投入
    构建核心框架/平台的团队能力与投入
    项目过程中,人员能力与投入
    维护阶段团队要求与投入
    可能的风险与不适应性
    项目规模与投入
    人员能力影响
    技术风险
    行政风险