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测试哪里有100%的事情，清理过程中的一点问题可能就造成了之后用例的大片失败，这让我们如履薄冰。
就在这个时候docker进入了我们视野。
如果我们每个case都重启下docker数据源容器，每个用例的环境就能保证一致，那测试人员就只需要专注编写核心功能的自动化。
而docker启动一个容器很快，装有PG,redis的容器只需要几秒钟就能正常运行。
好 那就试试吧~
