课程简介
框架可以是被重用的基础平台;框架也可以是组织架构类的东西。我认为,框架就是一系列基础设施,这些设施起到一个基础工具的作用,是一个创建别的工具的工具。自动化测试框架是一个能够进行自动化测试的程序,其本质也是一堆“按照特定结构组织”的代码
使用自动化测试可提供代码的可复用性、可维护和可扩展性。框架设计比较灵活,并没有通用的标准来规定框架必须具备什么结构或功能,框架的最终目的只有一个,就是提高测试效率,降低测试成本。
课程收益
1.了解测试发展的误区,掌握应对方法;
2.剖析复杂业务测试问题的根源分析;
3.全面学习了解测试建模原理和模式,掌握测试建模的落地方案。
受众人群
测试工程师,测试开发工程师和测试技术骨干成员、测试技术负责人,测试经理和测试总监、测试架构师、DevOps资深工程师和技术负责人、工程效能团队负责人和工程效能研发工程师、开发工程师,开发技术经理,开发技术负责人、技术创新团队的工程师。
课程周期
2天(12H)
课程大纲
课程主题 | 课程大纲 |
测试发展的误区 | 测试跟随着开发的模式 |
测试想跟随需求,但落地方法错误 | |
变更,无法跟上节奏感 | |
传统企业,面临的双峰挑战(稳态+敏态) | |
团队与人员的阻碍 | |
文档的更新模式 | |
DevOps是否可以解决问题 | |
复杂业务测试问题的根源分析 | 双峰挑战下的测试模式 |
传统企业,为何无法适应上述测试模式(国外引入水土不服) | |
持续集成带来的持续测试,是否解决了根本性问题? | |
人才发展的限制与团队瓶颈 | |
测试思维的切换:测试建模 | 思路:业务需求+技术需求+监管需求+旁路影响分支需求 |
需求—>开发—>测试:传统为阶乘式增长,无法维护 | |
测试建模的方法与原理,对应解决的问题 | |
DevOps只是工具链的建立,测试建模真正解决测试端的问题 | |
曾经的弯路:微软测试建模走偏 | |
测试建模,本质上解决了维护性代价的问题,但为何无法成功实施 | |
测试建模的分析 | 分析:旧有模式仍然为离散式的跟踪,跟随开发 |
抛弃工具绑定的思想 | |
1vs1的思路,跟踪需求(业务+技术+监管+旁路) | |
需求端直接生成用例与脚本,真正为TDD | |
作者在美国4年和中国5年的构建实例 | |
测试建模的落地构建方案 | 前置:统一需求矩阵的建立 |
有限状态机的演化:与等价类、边界值的穷举结合 | |
核心:测试建模—>与需求的1对1标准匹配(业务、技术、监管) | |
边界建模:流程数据集中营,来应对不同的开发架构:巨石、SOA、微服务或者复合型 | |
工具沦落到最外层非核心,随意更换适配引擎 | |
解决问题:变更的快捷定位、准确性、可追踪与回溯、易于重构 | |
解决问题:易于重构、不关联和影响开发技术、不被工具绑架 | |
解决问题:重写了TDD与BDD模式,但适合复杂业务流程 | |
解决问题:知识的规则化沉淀,自动驱动与融合 | |
测试建模平台落地方案与演示Demo | 整体架构 |
笛卡尔乘积的构建 | |
有限状态机的构建 | |
中间存储矩阵构建 | |
统一的展现平台,外接不同的引擎 | |
传统平台的功能:权限管理、项目管理、报表分析等等 | |
植入监控与反馈 | |
链接到DevOps平台,与需求对接,映射开发 | |
测试建模应用化举例 | 接口测试 |
GUI测试 | |
行业性监管要求加入 | |
不同行业的要求 | |
与传统模式的效率对比 | |
所需团队能力与投入 | 构建核心框架/平台的团队能力与投入 |
项目过程中,人员能力与投入 | |
维护阶段团队要求与投入 | |
可能的风险与不适应性 | 项目规模与投入 |
人员能力影响 | |
技术风险 | |
行政风险 |
Arthur
百林哲咨询(北京)有限公司专家团队成员
Arthur
百林哲咨询(北京)有限公司专家团队成员
Arthur
百林哲咨询(北京)有限公司专家团队成员
Arthur
百林哲咨询(北京)有限公司专家团队成员
Arthur
百林哲咨询(北京)有限公司专家团队成员
Arthur
百林哲咨询(北京)有限公司专家团队成员
Arthur
百林哲咨询(北京)有限公司专家团队成员