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的容器只需要几秒钟能正常运行。
  好 那试试吧~