微服务下的自动化测试体系以及复杂系统测试建模

测试质量 / 2020-04-26 12:20:23
微服务下的自动化测试体系以及复杂系统测试建模
    马上咨询

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

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

    课程背景

    当前时代已经进入到DevOps以及微服务架构下自动化测试时代，由于运维的快速持续交付，开发的敏捷化开发与持续集成，让交付速度越来越快。但是在越来越快的交付下，手工测试无法进行满足交付速度，而传统的自动化测试，也无法覆盖需求和应对快速的需求变更。BDD、TDD、ATDD对于简单业务可以做到快速覆盖与需求对应的快速变更，但是，复杂的业务模式下，如金融、电信、能源、汽车、ERP、甚至复杂的互联网需求，BDD与ATDD等无法应对需求的快速变更。所以，本次课程通过3个阶段：测试建模（测试用例自我生成），自我构建关系链路（测试场景自匹配）、工具胶水层与适配层（接入各种自动化测试工具），来描述在复杂业务模式下，当需求变更，如何应对并产生自适应的自动化测试规则与脚本。

    课程大纲

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

    最新动态

    点击阅读更多内容
    返回顶部