[开发测试]RobotFramework测试框架组织结构

总体架构

先介绍每个文件夹的功能和结构：

Env: 存放运行时环境变量，即同一套测试用例在同一个产品不同sp下运行时。

如 千里眼产品的两个常用测试SP ： sp1 和 Ecogateway

FunctionalTests：存放各产品的功能测试用例，即BFT，除冒烟测试和验收测试之外的用例，适用于每天执行一次

如下结构，由测试人员自行组织，
1）可以根据功能分成几个文件夹，用文件夹区分几个大的功能模块，文件夹中的文件来覆盖不同的子模块
2) 直接用不同的文件名区分同一功能模块下的子模块

Keywords： 存放于产品逻辑相关的用户关键字，都是resource文件，只做用户关键字被测试用例直接调用，并不能作为测试用例执行

1）不同的文件夹区分不同的产品
2）每个产品，每个大的功能模块对应一个resource文件，存放与业务逻辑相关的基本用户操作，如点击xx元素，输入xx，验证操作正确性等原子操作，是测试用例中的一个步骤
3）Base.resource是对selenium2library做的二次封装，即除了这个库，任何其他的文件不直接导入selenium2library库，使用其关键字
主要封装了一些基本的操作，点击元素，输入文本，浏览器操作等，添加的等待元素出现，等待关键字执行成功的操作
尽量不要私自修改这个文件
4）Login.resource是对sso登录的封装，目前都有千里眼产品的痕迹，其他产品可自己写一个登录的资源文件。 尽量不要私自修改

Library：存放编程语言写的第三方库。用来扩展官方的第三方库。比如对Selenium2Library库做扩展的WebElementHelper

还可以添加操作数据库的库（验证UI操作对数据库的更新是正确的），操作CSV的库，用来组织测试数据，做数据驱动等

SanityCheck：存放冒烟测试和验收测试的用例，这些用例数量不要太多，保证系统的最小可用，主要用于部署前后端代码最后阶段测试系统的最小可用

1）Acceptation_Pop 验证各页面没有白屏
2) Loginxxx 验证基本的登录操作

Variables：存放环境变量和元素locator，防止在资源文件或者用例中对元素locator硬编码，增强可读性，也方便元素locator的集中管理

1. Env 存放初始化相关的变量，如浏览器类型，url等
2. Login.py 存放登录相关变量，因为是sso登录，所有产品的登录界面是一致的，因此统一管理，当然也可以每个产品维护自单独的文件
3. 与keywords中的目录结构基本一致，每个产品对应一个文件夹，文件夹中的一个py文件对应一个resource文件。