面试自动化测试架构时必须知道的事儿
当面试的时候，面试官要问你对自动化测试架构的理解时，该如何回答呢？
其实这是一个很“大”的问题，面试者需要对如下内容进行阐述，主要包括：什么是架构、什么是架构设计思想、自动化架构设计带来的好处、有哪些核心类库以及他们的作用、结合你的实际工作谈谈遇到的架构使用问题。在这里我概述一下对于这几个问题的核心回答思路。
1.什么是架构
软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。
2.架构设计思想
用一套通用的自动化测试框架，解决不同产品线的基础服务构建工作（包括：提供日志模块，提供邮件模块，提供外部文件读写处理模块以及日志解析模块等等），通过引入框架方便公司对不同的产品线自动化实施进行整合，便于日后管理和维护。该设计方案使得不同产品的自动化业务编写人员只需专注于用例业务的实现，无需理会API中内部技术细节的实现。而架构设计人员无需对业务线的具体业务知识进行系统学习，只专注于技术细节的实现，当业务编写人员遇到技术问题时提供必要的技术支持。正所谓术业有专攻，通过对不同角色的职责划分，从整体上提升自动化测试的工作效率。
具体包括：
编码选择（用java还是python）
核心技术选择（例如：web用selenium 、移动端用appium）
提供编码规范（类、方法、变量的统一命名规范）
提供用例设计规范
代码管理方案（svn还是git）
3.为什么使用架构
核心：解决录制脚本的常见问题，使得自动化测试稳定
1.把架构编写人员（精通代码设计），用例编写人员（了解代码），以及用例执行人员（不懂代码）分开
2.把UI对象通过自定义变量的方式赋值，增强了脚本的易读性
3.通过封装Webdriver的API，使其更加健壮
4.把常用的业务场景封装成业务方法，便于常用业务的复用
5.把经常需要修改的内容（例如：登陆用户名和密码）保存在外部文件中，避免了脚本执行人员对测试脚本代码的修改
6.生成Debug级别的log，使自动化脚本调试人员方便调试程序
7.生成回归级别的测试报告，便于不懂脚本的人员查看测试结果
8.引用Suite执行多个脚本,进行运行脚本的管理
4.具体类库是如何设计的
配置文件
把经常需要修改的信息（例如：用户名，密码，环境）保留在配置文件中，好处如下：
便于执行用例的测试人员修改；
避免对代码的修改而引起的错误
日志
测试报告：向项目经理、产品经理和老板汇报
调试日志：便于自动化脚本编写人员调试代码
ObjectStore
保存页面中的元素，当UI变化时修改对应变量即可，将可读性差的UI元素按照统一规则命名
CommonLib
1.提供与Webdriver无关，但与自动化测试相关的API
包括：从外部文件读取信息，启动多种浏览器，获得当前系统时间，启动和终止某个应用程序，获得随机数等等
2.包括的方法有，从外部文件读取数据，生成随机函数，获得当前日期等等
Corelib
1.封装webdriver的api，使其更加健壮，形成自动化项目的api
2.提供断言的相关方法
3.自动化api提供详细的输出消息，便于调试
4.自动化api提供向测试报告中写入消息的方法
BusinessLib
业务方法的封装，根据Corelib中的提供的API，把常用的业务场景封装成方法便于复用
DataStore
保存输入的数据信息，作为架构与外部文件的接口
5.使用架构时遇到的问题
前面的问题回答的在好，只能证明你在理论方面对架构的理解是OK的，那么你究竟使用过架构吗？必须结合实际项目来说！主要注意以下几点
正常流程
1.你是如何利用架构里面的api设计用例的，举一个具体的场景（非常重要）
解决问题
2.当遇到ui元素变化时，你是如何更新ui变量的？核心点是更新objectstore
3.当遇到脚本执行fail时，你是如何判断是架构的api问题还是程序本身的bug的？核心点是手工复现问题，查看架构日志
4.当架构提供的api不能满足你的项目需求时，你是如何扩展api的？核心点是直接重写架构的api或者添加api；写一个新类继承架构中的Corelib，在这个 新类中完善api
5.当架构需要添加新功能时需要如何接入？核心点是写若干个类完成所需功能，然后提供调用接口在架构中使用
原创不易，如果文章帮到了你，欢迎转发点赞，让更多的朋友受益！