1.什么是测试架构
从基本的观点看，测试架构师由软件系统技术架构和软件测试结构构建的需求而定。
2.测试领域架构
2.1.功能测试
(1).在功能测试中，不仅要完成业务逻辑的验证，还要进行用户界面和输入空间的验证。我们常用的黑盒测试中的等价类、边界值、决策表、因果图等方法，实际上都只是功能测试的冰山一角，仅为对输入空间的验证。
(2).在功能测试中，不光要进行不同层次的测试，还要针对不同空间或领域进行相应的测试。如下图所示：
(3).功能测试架构图：
备注：有限状态机(FSM)，形式规格说明(ForS)，功能规格说明(FunS)
2.2.非功能测试
(1).非功能测试可以看做两部分组成，一是设计验证，二是系统验证。
3.自动化测试架构之说
3.1.良好的自动化测试框架应该具有的特点：
(1).提供非常有效的测试工作流程模型
我的理解，就是一套完整的测试流程，从测试任务的准备、执行、测试报告。一套流程的元素都应该具备。
(2).支持多种脚本语言的录制、编辑、调试和回放等集成开发环境
(3).完成各类测试任务的执行
我的理解，选择测试任务时应该是支持多选，且存在固定的测试集，如冒烟测试场景集、回归测试场景集，前者是提供执行者按需选择执行模块(次数每个模块应该相互独立，才能方便自由组合)，后者是为了满足快速测试。
(4).有良好的扩充能力，如和第三方插件、工具的集成
我的理解，比如第三方监控工具，可以在开始测试任务时开启，做到测试过程资源监控。
(5).具有数据驱动、关键字驱动等脚本模式的支持
(6).具有分布式处理、远程调用的不同的运行方式
(7).能获取测试覆盖率。
我的理解，该出应该体现在测试报告中，包含总体测试覆盖情况(测试累计时长、测试模块)，单一模块执行情况(执行时长、检查点通过情况、失败检查点有失败结果)等
3.2.公用的对象、方法、环境或数据因素处理
(1).公用的对象。构建对象库，封装公用的对象，并建立实体对象和逻辑对象之间的映射。
(2).公用的方法。
我的理解，以上两种的要求是尽可能多的封装、公用。且利于维护。
(3).公用的环境或数据。将不同的测试环境或数据封装起来，和测试用例灵活的组合，以增强脚本执行的灵活性。
我的理解，一般情况下，自动化测试平台应该至少支持两套环境(测试环境、生产环境)，例如接口测试，两套环境需要准备IP、端口、头文件。两套环境应该都有封装，在配置文件中决定使用哪套环境基数。
(1).综合而管理平台：统一的web发布页面，管理所有环节
(2).脚本开发IDE：
我的理解，为关键字驱动的测试用例场景，此处编写的测试用例，可直接被控制中心作为任务模块子元素组合操作。
(3).任务安排：
我的理解，此处的任务就是一个组合执行过程，可包括立即执行、定时执行、加入执行队列等待执行
(4).监控测试资源：在测试过程中，能够及时发现问题，发出警告，并保留相关数据。
3.3 测试自动化框架的基本构成
4.测试架构师
4.1 对软件测试架构师的要求
(1).测试架构师是测试团队的技术带头人，在系统非功能特性的测试、自动化测试框架等方面发挥着主导作用，对开发团队具有很好的沟通能力和影响力。
(2).测试架构师应该具有较强的抽象能力和创新能力，通过一个全局的观点、宏观的视角来理解软件系统作为一个整体是如何工作的，可以将具体问题抽象为一个模型，从而解决一类问题，并通过不断创新，找到解决问题的新方法，推广新的测试技术。同时，测试架构师作为测试技术带头人，就是为测试团队梳理技术标杆，提供技术指导、做好技术决策。
4.2 测试架构师职责
4.3 测试架构师产物
