看一看chromium自动化测试设计的面容

      看一看chromium自动化测试设计的面容。

　　我们来看一下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的采集和报告，基本上每一个部分都能深入去了解。

转载于:https://www.cnblogs.com/liyuchen8908/archive/2013/05/26/3100043.html