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的采集和报告,基本上每一个部分都能深入去了解。有时间了慢慢的再研究一下。