qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

初窥chromium中的自动化测试设计

性能方面的项目有:

  test_support_ui_project:

  提供一些UI的基本操作(功能)和性能相关内容,主要是性能,收集几种最终要的性能数据;

  realibility_test_project:

  封装test_support_ui中的性能测试内容,对chrome进行稳定性测试,包括稳定性测试,crash收集,报告等;

  执行相关有:

  pyautolib_project:

  chrome相关的pythonUI测试框架,将uitest的C++导成python然后进行执行;

  webdriver_project/chromedriver_project:

  为外部网站测试提供支持,比如selenium,webdriver等;

  还有三个我觉得不错的和自动化有关的部分:

  breakpad的引入:

  crash的收集报告框架,在测试框架中引用它,对测试过程中出现的crash进行dump收集,并统一分析;

  IAccessible的实现:

  使用代理方式在views库中封装IAccessible的接口,共外部进行界面相关的获取;实现方式和我在MASS实现中提到的一样,继承统一基类,注册,然后分别实现自己的UI支持;

  memory_watch:

  chrome中的内存检监测小工具。

  大概先看了一个雏形,感觉里面的自动化架构设计很漂亮,虽然涉及到的部分很多,也很碎,但是看样子chrome都已经分而治之了。界面的功能和 性能,页面的功能和性能,js的功能和性能,后台数据的获取和安全,页面的渲染,插件的稳定,性能数据的获取和分析,dump的采集和报告,基本上每一个 部分都能深入去了解。有时间了慢慢的再研究一下。

chromium开源项目部分的自动化测试,对于学习自 动化测试很有帮助,自动化能涉及到的部分,或多或少都有覆盖。对于像浏览器这样的产品,尤其chrome(chromium)这样的新概念浏览器,投入在 里面的自动化测试,力度非常大。好不容易赶上一个不加班的周末,简单的研究了一下;对一个产品来说项目工程不小,只能按自己的理解去关注自动化的部分。

  白盒部分:

  和很多国外的产品一样,白盒测试部分比重很大,整个chromium中的自动化测试,白盒部分超过25%或者更多(没有具体计算这个数字),白盒测试大概可以分为两个类别,单元测试和交互测试,它们的测试框架不同,分别是gtest和google mock。

  核心工程:

   核心自动化工程是automation,在chromium/src/chrome/test/下面,包含大部分自动化测试的代理部分,所有内部测试通 过ENABLE_AUTOMATION进行编译的开关。这个代理架构上,是两个UI相关的的架构,一个是对外的chrome界面的自动化操作,一个是内部 view的界面库测试。代理的提供者在其他的自动化项目中,automation下面的代理和非代理部分都有各自的提供者。chromium中的自动化其 实是一套很不错的C++自动化架构,准确来说不是一套,但是大思路一致。其中:

  automation_proxy.h/.cc:

  自动化的总代理,用来和提供者automation_provider.h/.cc进行信息的交互,并且包含其他具体代理;代理是ipc的方式;

  browser_proxy.h/.cc:

  browser的代理,主要用来和browser的automation_provider进行交互,测试chrome界面的主要部分,包括tab的处理等;

  tab_proxy.h/.cc:

  tab的代理,用来和tab的provider进行交互,测试的应该是固定tab页内的js相关;

  automation_json_request.h/.cc:

  Json格式的数据传输,很多数据都是Json方式传输的;

  window_proxy.h/.cc:

  同样的道理,window相关的代理。

  主要自动化测试工程分为三类,功能、性能和执行,其中:

  功能包含:

  chrome_frame_project:

  chrome frame相关,主要是插件方面;

  browser_project:

  chrome主界面的测试相关;

 性能方面的项目有:

  test_support_ui_project:

  提供一些UI的基本操作(功能)和性能相关内容,主要是性能,收集几种最终要的性能数据;

  realibility_test_project:

  封装test_support_ui中的性能测试内容,对chrome进行稳定性测试,包括稳定性测试,crash收集,报告等;

  执行相关有:

  pyautolib_project:

  chrome相关的pythonUI测试框架,将uitest的C++导成python然后进行执行;

  webdriver_project/chromedriver_project:

  为外部网站测试提供支持,比如selenium,webdriver等;

  还有三个我觉得不错的和自动化有关的部分:

  breakpad的引入:

  crash的收集报告框架,在测试框架中引用它,对测试过程中出现的crash进行dump收集,并统一分析;

  IAccessible的实现:

  使用代理方式在views库中封装IAccessible的接口,共外部进行界面相关的获取;实现方式和我在MASS实现中提到的一样,继承统一基类,注册,然后分别实现自己的UI支持;

  memory_watch:

  chrome中的内存检监测小工具。

  大概先看了一个雏形,感觉里面的自动化架构设计很漂亮,虽然涉及到的部分很多,也很碎,但是看样子chrome都已经分而治之了。界面的功能和 性能,页面的功能和性能,js的功能和性能,后台数据的获取和安全,页面的渲染,插件的稳定,性能数据的获取和分析,dump的采集和报告,基本上每一个 部分都能深入去了解。有时间了慢慢的再研究一下。

posted on 2013-05-24 11:47 顺其自然EVO 阅读(375) 评论(0)  编辑  收藏


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年5月>
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜