说起自动化测试框架的分层结构，还是先拿 RobotFramework 看一下，最明显的一个分次是
RobotFramework 与 Test Libraries 层。
从工具角度讲，这一层把测试工具与测试用例进行了分离。为什么要分离？技术上面原因前面讲过 增强用例可靠性，易于维护工具可替换等等。
实际是还有一个目的，将测试人员也进行分层。原因：
1、测试团队中，并不是所有人都具备开发测试工具的能力。（注意：不是编程能力，未来的测试团队中所有人应该都具备编程能力。单不一定都要精通开发测试工具）
2、降低团队人员成本，这也是上面原因的另一种说法。低技能人自然薪资低，比如可以用用例简单到一群实习生，培训一周，就可以干活，自然最好。这个和工厂流水线选工人是一个道理。
3、少出错与易维护，碰不到就不会错。和产品按模块开发抑或微服务和中台等等，程序结偶目的就是要，你别碰我代码。这样对于工具维护者就会更容易。
4、为保持团队和谐，你们没看错，如果自动化测试分层策略不好真的会对整个测试团队产生影像，自动化测试落地策略，无论是成熟团队与不成熟团队，测试团队成员间合作是很重要的，
由于自动化测试的特殊性，往往团队中自动化测试人员就会显得有些特殊，甚至有时候另类。再有甚还是独立团队，这样和功能测试团队产生冲突等等一系列问题埋下隐患。
===此处留个坑，原因很多大家也可以一起思考，下面说重点===
自动化测试框架的分层图，实际上大多大家比较认可的是3层结构 用例层、业务层、工具层。
我这里分层4层，是希望能和人员角色更好的说明。至于项目中应该分几层如何分，这个要具体问题具体分析。
简单来说 数量规模越核心越少，技能要求越核心越高。人员薪资越核心越高。人员需求数量越核心越少。能写工具层工具的都是技术牛人+机缘巧合，如selenium的作者Jason Huggins 、webdriver的作者 Simon Stewart 。他们两个都是根据自己工作开发了工具，后来又在google相遇，让 selenium与webdriver 结合。
驱动层：是把 工具层的工具进行一次封装以锁定项目中用例的工具，向上支撑业务层。
业务层：是根据项目具体业务对需要实现的方法进行封装。
用例层：编写具体的测试用例
举个例子：
框架分层目录结构：
testcase、keywords、driver 分别对应 用例层、业务层、驱动层、。另外工具层已经是在开源工具行列。通常使用标准方法 pip 安装到本机即可
下面是一个 登录的测试用例：
可以看到，直接调用 关键字 login 输入需要 登录的用户名密码
业务层代码：
驱动层代码：
封装 requests
熟悉python 的同学看到这里也许有个疑惑，这个用例requests 直接调用也就不超过5行代码，为什么那么麻烦？
实际就是为了自动化可落地易维护。因为上面的内容需要不同人来完成。人数以10人测试团队为例
1、用例层：团队角色，普通测试人员，技能要求：具备python基础，会写unittest。工作经验1年左右。人数：6～7人
2、业务层：团队角色，测试骨干 技能要求：熟悉python，熟悉所在项目业务，能够完成测试设计，并对关键字根据业务进行抽象 人数 2～3人
3、驱动层：团队角色：自动化测试负责人/测试开发 技能要求：熟悉python编程，熟悉各种自动化测试工具等。 人数：1人 工作内容：维护测试框架，指导和支撑测试骨干封装业务关键字，和制定自动化测试规范。
4、工具层：团队角色：自动化测试负责人。技能要求：大牛，技能越强越好。人数：0～1人
