一图了解软件测试架构师的实践模型
基本概念
1. 架构师：通俗的说就是设计师或结构设计者，致力于简化复杂度，能迅速抓住问题要害，做出关键技术决策，具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考。
建筑学有建造师，金融学有商业架构师，软件学有技术架构师，产品架构师，业务架构师，软件测试架构师。
2. 软件测试架构师：软件测试工程师发展的一个重要方向，致力于又快又准的发现系统的缺陷，做缺陷的预防，加快项目的发布进程，提高产品的质量。
软件测试架构师，需要像系统架构师一样理解产品的商业目标和用户使用场景，要从整体上把握测试节奏，为团队的关键测试活动（如测试设计，测试执行）提供辅导。要保证测试策略能够在整个团队中落地。
软件测试架构师的实践模型
1. 被测对象建模， 状态机，业务流程图，时序图等
案例：可行驶区域，简称freespace，
通过语义分割方法，将可通行区域用360个矢量点圈出（不能表征遮挡物后面的可通行情况）。
一般要给出动静态分离结果，也就是freespace边缘的点到底是运动的还是只是水泥，垃圾等静止的。
采用场景法进行业务分析：
场景业务流分析方法进行业务建模，进一步理解需求
1）正常业务流
程序从开始执行直到成功结束所经过的最短路径。
2）异常业务流
如下场景造成的异常业务流
功能丧失（即无法操作、突然失效）
功能退化（即性能随时间损失）
功能间歇（即操作随机开始/停止/开始）
部分功能丧失（即损失损失）
非预期功能（即在错误的时间操作、意外的访问、不相等的性能）
功能超范围（即超出可接受极限的操作）
功能延迟（即非预期时间间隔后的操作）
2. 根据需求分解出测试点
1. 测试流程建模
2. 测试架构建模
依据梳理的测试点、测试模型和测试层级，选择合适的测试技术/测试框架，准备测试环境。
1）选择合适的测试技术，例如台架模拟CAN信号测试
2）识别可测试性需求并提交给项目
例如HMI结果显示需求，功能开关需求，CAN/串口数据输出接口需求等。
3）识别测试设备/工具需求
4）识别测试数据需求
针对采用数据回灌方法测试的项目，需要提前梳理测试数据需求并及时提交数据采集需求
案例：
1. 设计测试用例框架
依据功能模块/测试点/测试技术/测试类型/测试环境的特点，将测试点进行抽象组合，将具有强相关的测试点划为一组，便形成了测试用例的框架。
如下三种测试用例框架模型供参考：
2. 关联测试用例设计方法
依据功能特性，选择合适的测试设计方法完成测试用例的设计
白盒测试设计：语句覆盖/判定覆盖/条件覆盖/路径覆盖等
黑盒测试设计：等价类/边界值/错误推测/场景法等
3. 进行测试场景建模
如采用场景法（ID域项目基本都需要场景法），需要完成测试场景的建模，供后续自动生成测试用例使用
案例：
备注： 自动生成测试用例工具的使用方法参见相关说明。
构建测试框架
开发测试工具/测试脚本
制定测试策略
关注点：测试范围和计划相比的偏差；本版本的测试目标；重点关注的内容；测试用例的选择；测试执行顺序；试探性的测试策略（准入）；接收测试策略（首轮）；回归测试策略；探索测试策略；自动化测试策略。跟踪测试执行
关注点：用例执行情况；每日缺陷产出情况；策略调整。
需要给出关于“能否进入下一阶段的测试”或者“发布”的结论。
1、确认测试策略中重要的质量目标是否达成；
2、测试策略中，未达成的质量目标，确定应对措施；
3、进行遗留缺陷分析。
案例：
更多关于测试架构师的知识介绍可参阅：
软件测试架构师究竟干哪些工作？
https://mp.weixin.qq.com/s/2cqneiymBDp9ZOqO7XC9Gg
