2013年度持续集成实践小结[1] ?UI自动化
作者：网络转载 发布时间：[ 2013/12/12 11:37:41 ] 推荐标签：
典型的用例结构如下所示（基于TestNg与Dagger）
|
public class Demo {
BrowserEmulator be;
@BeforeClass
public void doBeforeClass() {
be = new BrowserEmulator();
}
@Test(description = "从车库进入超市")
public void step_1() {
}
@Test(description = "买牛奶"， dependsOnMethods = "step_1")
public void step_2() {
}
@Test(description = "买水果"， dependsOnMethods = "step_2")
public void step_3() {
}
@Test(description = "现金付款"， dependsOnMethods = "step_3")
public void step_4() {
}
@Test(description = "开车离开"， dependsOnMethods = "step_4")
public void step_5() {
}
@AfterClass(alwaysRun = true)
public void doAfterClass() {
be.quit();
}
}
|
实战与效果
由于对UI自动化及Jenkins轻车熟路，在极短的时间内完成了一套简易的UI自动化持续集成，整套流程的执行时间严格控制在 15分钟 以内（可开启用例并发执行模式），并且每隔30分钟执行一次：
工程代码构建 -> 测试环境部署 -> 执行UI自动化
初，一共只有10个左右的UI自动化用例，但已经基本覆盖了产品的核心功能点（没考虑各种流程的排列组合），正是这只有区区几个UI自动化用例的持续集成却发挥了不小的作用：
不少的各种低级错误（低级，不解释！）在构建阶段被拦截，并以邮件形式知会开发团队；
引起QA测试工作Block的严重问题（不一定是Bug，也可能是环境配置，脏数据，等）被及时发现；
用例数量确实不多，大家都乐意在第一时间去处理失败用例。
所以，正如古人云： 银子钞票，多多益善；持续集成，愈早愈好 ，还是尽早写几个UI自动化，配置持续集成跑起来吧，它能够发现和预防的问题比你预计的多得多！而且，只要这套持续集成跑起来了，往里面添砖加瓦轻松得多了，不再会有畏惧感，信心也会逐步增强。
现在，每次产品迭代结束之后，测试团队会及时整理一份类似上述的表格，大家一起参详下，分工下，补充用例，逐步完善。
一些结论
S产品的UI自动化是 小而美 的典型：
用例不多，维护/补充很及时；
代码冗余度很小，结构清晰；
运行稳定且快速，深合持续集成的快字诀。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系SPASVO小编(021-61079698-8054)，我们将立即处理，马上删除。
sales@spasvo.com