UI自动化框架的选择
　　在之前做过的一个Android自动化项目中选用了calabash，很喜欢BDD的风格，函数库够多的时候写起自动化来像是把用例的中文翻译成英语，so easy~
　　但是也是之前使用calabash的经历发现ruby的库实在是不够丰富，虽然语言本身更喜欢ruby一些，没办法，为了没那么多幺蛾子这次还是换成python吧。。。
　　python的BDD框架并不多，比较出名的是behave和lettuce，对比过后选择了behave。
　　好吧，其实没有真正对比试用过，是被behave主页上对其他工具的恶毒攻击洗脑了~~
　　http://pythonhosted.org/behave/comparison.html

　　与Phantomjs的集成
　　简单来讲phantomjs是一个没有UI的浏览器，可以与selenium webdriver完美集成。
　　为什么要选用它：
　　快，没有GUI的浏览器比起chrome，firefox这些webdriver来执行速度要快很多
　　要测试的是内部的配置平台，没有那么多花哨的js，css，更加注重功能，phantomjs足够使用
　　是想在linux下干活，但是我的server并没有UI。。。
　　behave中使用phantomjis
from behave import *
from selenium import webdriver
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities
def before_scenario(context，scenario):
context.dr = webdriver.PhantomJS('phantomjs'，service_args=['--ignore-ssl-errors=yes'])
context.dr.set_window_size(1360， 900)
...
from behave import *
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.action_chains import ActionChains
from selenium.webdriver.common.alert import Alert
@given('I open test portal')
def step_impl(context):
context.dr.get(context.index)
assert_that(context.dr.current_url，matches_regexp('7030/cas/login')，"not auth page")
...
　　behave用例示例
@1887204
Scenario: 1887204-3
Given I open test portal
when I input username and login
then I move to release rule page
when I reset cfp cp-center log
when I reset cfp carrier-center log
then I create new release rule "autotest" "正常订购" "1" "diy" within "180"s
| id | equal | value |
| 运营商： | = | 中国联通 |
| 套餐： | = | lt_50m_qg_suc |
| 客户账号： | = | autotest |
then I check cfp cp-center log within "30"s for "release order success.*target release count:1"
...
　　测试数据隔离怎么做
　　正常来说，到上面为止框架已经有了，后面可以填用例了~
　　但是我想让自动化更加健壮一些，希望每个用例运行时都是干净的独立的环境。
　　这需要我们对每次测试后的环境进行清理，而behave对于单个case并没有对应teardown这样一个专门清理的函数，这使得错误发生后没有办法很好的还原环境。
　　开始我们考虑在behave的after_scenario()方法中根据失败用例的tag进行特定的清理。
　　这样可以work，但是额外的清理会浪费较多时间，而且UI测试哪里有的事情，清理过程中的一点问题可能造成了之后用例的大片失败，这让我们如履薄冰。
　　在这个时候docker进入了我们视野。
　　如果我们每个case都重启下docker数据源容器，每个用例的环境能保证一致，那测试人员只需要专注编写核心功能的自动化。
　　而docker启动一个容器很快，装有PG，redis的容器只需要几秒钟能正常运行。
　　好 那试试吧~