为了简洁这个目标，自动化测试的设计是基于架构原则建立的，这个可以称为PATS。
PATS是如何工作的
这一节关注自动化测试系统本身，怎么样去建立一个简单，易用，支持重用模块和一点维护，换句话说，就是PATS。
工具的选择
首先需要做工具评估。必须让一个人去使用这个被评估的工具。我的建议是使用两个到三个工具，一个一个的使用，用他们创建简单的和复杂的脚本。基于衡量每个工具的易用性和使用工具重用模块的能力。值得注意的是，每个工具都有他们创建脚本的特性。最重要的一点是不要让工具告诉你怎么去测试。自动化测试策略是独立于工具的，工具是为了支撑和实现测试策略的。
一个马匹会带领你去找到水源，如果你让他去，如果你想围着湖转转这当然非常好，如果你想穿越草甸你就不会认为这是个好主意了。这个类似自动化测试工具。利用捕捉-回放手段，你可以找到野生树林-不是你想去的地方。你的自动化测试系统会最终和一个巨大的混乱交织在一起以至难以持续。这是为什么最重要的是测试方法的架构会与测试工具有关。测试工具是客人而不是主人。
自动化测试方法
可重用模块
模块的重用用来导航，操纵控制，数据验证，错误识别（软件，硬件），和输出日志。可重用模块基本组成是命令、逻辑，数据，这些必须以归并的方式呈现才有意义。在测试系统中使用通用的模块，比如初始化和安装部分，封装起来命名为体现他主要功能的名字，像“初始化”或者“安装”。其他的更具体的应用，在客户窗口对服务的控制，例如，也封装在一起，并且命名类似。
系统架构就是重用的内容被组织起来，经验表明完整的架构是组织主要的重用模块在一个应用窗口，所有的模块被客户窗口调用被组织在一个文件里或者一个library（qtp有这个library）。这样的话，就是客户界面因为任何原因被修改，更新文件只要更新一个地方。这就使在一个地方更新维护成为现实的原则。
这个争论的中心是，如果一个控制语句，例如在客户窗口的列表框，非常类似于清单屏幕，为什么不用一个适合两种情况的重用模块？这个应该比想象的要麻烦，而且复杂程度没有办法保证模块的正确。当一个模块越来越复杂，他将越来越难保持，而且会有很大的可能带来一些bug。
文章来源于领测软件测试网 https://www.ltesting.net/
