任你选择
课程大纲
天数 | 范围 | 内容 |
Day 1 | 测试发展趋势 | 互联网与数字化的发展要求 |
DevOps时代来临 | ||
测试目前发展趋势，是否可以解决当前问题 | ||
测试是否拖累当前所有的进度，问题有哪些 | ||
测试 模型：金字塔、纺锤、冰淇淋等 | ||
部分传统方法是否可以解决当前问题 | ||
测试发展的误区 | 测试跟随着开发的模式 | |
测试想跟随需求，但落地方法错误 | ||
变更，无法跟上节奏感 | ||
传统企业，面临的双峰挑战（稳态+敏态） | ||
团队与人员的阻碍 | ||
文档的更新模式 | ||
DevOps是否可以解决问题 | ||
测试模式的根源挖掘与适用场景 | 国外的业务发展模式与国内的区别 | |
BDD的适应场景，团队与人员要求 | ||
TDD的适应场景，团队与人员要求 | ||
ATDD的适应场景，团队与人员要求 | ||
关键字的适应场景，团队与人员要求 | ||
敏捷测试的适应性与发展限制 | ||
分级测试的提出与互联网应对 | ||
微服务下契约测试的提出与团队要求 | ||
复杂业务测试问题的根源分析 | 双峰挑战下的测试模式 | |
传统企业，为何无法适应上述测试模式（国外引入水土不服） | ||
持续集成带来的持续测试，是否解决了根本性问题？ | ||
人才发展的限制与团队瓶颈 | ||
测试思维的切换：测试建模 | 思路：业务需求+技术需求+监管需求+旁路影响分支需求 | |
需求—>开发—>测试：传统为阶乘式增长，无法维护 | ||
测试建模的方法与原理，对应解决的问题 | ||
DevOps只是工具链的建立，测试建模真正解决测试端的问题 | ||
曾经的弯路：微软测试建模走偏 | ||
测试建模，本质上解决了维护性代价的问题，但为何无法成功实施 | ||
测试建模的分析 | 分析：旧有模式仍然为离散式的跟踪，跟随开发 | |
抛弃工具绑定的思想 | ||
1vs1的思路，跟踪需求（业务+技术+监管+旁路） | ||
需求端直接生成用例与脚本，真正为TDD | ||
作者在美国4年和中国5年的构建实例 | ||
Day 2 | 测试建模的落地构建方案 | 前置：统一需求矩阵的建立 |
有限状态机的演化：与等价类、边界值的穷举结合 | ||
核心：测试建模—>与需求的1对1标准匹配（业务、技术、监管） | ||
边界建模：流程数据集中营，来应对不同的开发架构：巨石、SOA、微服务或者复合型 | ||
工具沦落到最外层非核心，随意更换适配引擎 | ||
解决问题：变更的快捷定位、准确性、可追踪与回溯、易于重构 | ||
解决问题：易于重构、不关联和影响开发技术、不被工具绑架 | ||
解决问题：重写了TDD与BDD模式，但适合复杂业务流程 | ||
解决问题：知识的规则化沉淀，自动驱动与融合 | ||
测试建模平台落地方案与演示Demo | 整体架构 | |
笛卡尔乘积的构建 | ||
有限状态机的构建 | ||
中间存储矩阵构建 | ||
统一的展现平台，外接不同的引擎 | ||
传统平台的功能：权限管理、项目管理、报表分析等等 | ||
植入监控与反馈 | ||
链接到DevOps平台，与需求对接，映射开发 | ||
测试建模应用化举例 | 接口测试 | |
GUI测试 | ||
行业性监管要求加入 | ||
不同行业的要求 | ||
与传统模式的效率对比 | ||
所需团队能力与投入 | 构建核心框架/平台的团队能力与投入 | |
项目过程中，人员能力与投入 | ||
维护阶段团队要求与投入 | ||
可能的风险与不适应性 | 项目规模与投入 | |
人员能力影响 | ||
技术风险 | ||
行政风险 | ||
Day 3 | 后台服务自动化测试 | 比较与匹配模式介绍 |
场景设计介绍 | ||
搭建方法及应用 | ||
注意事项与技巧 | ||
接口信息 | ||
虚拟硬件串口信息模拟 | ||
嵌入式前端自动化测试产品介绍 | 业务场景分析（前端、后端、待机等） | |
测试指标分析 | ||
原理介绍，含输入与比较匹配项 | ||
工具介绍，自定义工具，可使用三种方式：机器臂点击式、硬件信号仿真式、纯软方式（接口驱动式） | ||
工具使用方法介绍 | ||
脚本编写模式 | ||
分析与报告 | ||
如何自我构建嵌入式自动化测试框架 | 工具原理 | |
架构方式与功能特性分析 | ||
调用OCR识别方法，如Google的OCR识别 | ||
封装驱动方法 | ||
构建注意事项 | ||
讨论 | ||
其他可能性模式 |
