- 相關推薦
Webkit 學習技巧
篇一:Webkit 學習筆記
Webkit 主要組成
WebKit 主要包括三個部分WebCore、JavascriptCore 及Ports部分。
WebKit 專注的核心部分主要是:
分析Html,Javascript的解析,布局渲染技術。
分別在WebCore/html,JavascriptCore 和WebCore/rendering里面
1 WebCore內容
目錄結構
bindings
將Dom Binding 給JavascriptCore 方面的代碼,同時包含依據idl 接口描述文件,自動生成對應于JavascriptCore 的Binding 實現的腳本等內容
bridge
主要包含NPPlugin方面的接口訪問等內容
css
主要包括與css 方面相關的內容如解析、不同css 規則的定義與實現、css Binding 給JS的接口定義等內容;
dom
主要包括dom方面相關的內容如不同dom元素的定義與實現、dom Binding 給JS的接口定義等內容
html
關于html 方面相關的內容,如不同html 元素的定義與實現、HTMLTokenizer 及HTMLParser等內容
load
主要包括裝載資源如html頁面、css、js 及image等方面內容;
page
主要包括描述一個Web頁面所涉及的內容如page、frame、frameview、frametree、setting、history、chrome、chromeclient等內容;
rendering
主要包括如何使用樣式,組織布局、顯示html 元素等方面內
plugins
主要包括瀏覽端如何實現NPPlugin 方面的內容
svg
主要包括與svg方面相關的內
xml
主要包括與xml 方面相關的內容如xml parser、XPath、XSLT等
platform
主要包括與不同平臺或外部庫相關的內容如graphics(圖形輸出方面)、network(網絡處理方面)、image-decoders(解析不同圖片格式方面)等
主要數據結構
為了更加簡單有效的描述瀏覽網頁的內容及過程,WebKit 為了明顯區分不同方面的內容,采取了不同的namespace 如webcore、javascriptcore、webkit等,webcore 方面的主要數據結構有: webcore::page 、 webcore::frame 、
webcore::FrameLoader 、webcore::FrameView 、Document 、DOMWindow 、KJSProxy 、DocumentLoader 、ResourceHandle 、ResourceRequest 、ResouceResponse、MainResourceLoader、RenderObject、RenderView等
總的說來,WebCore 包含了瀏覽器引擎的核心部分如處理html、dom、css、svg、獲取資源、渲染頁面過程控制、回調/通知外殼程序以及與Javascript 實現的Binding等等
2 port的內容
Port 方面的主要內容在于提供不同的Port 接口供外部程序使用以及如何與外部程序交互,因為WebKit 中的其它兩部分WebCore、 Javascript 實現,從邏輯上講是不直接提供接口給外部程序使用的。同時為了完成瀏覽器的核心功能,WebKit 也需要從外部程序中通過Port 接口的方式獲取一些支持。
1 WebCore 交互接口
在 WebKit源代碼目錄結構中WebKit目錄下分別包含gtk、mac、qt、win、wx 目錄,其分別對應不同的Port 移植方式,在每一個目錄下面都包括WebCoreSupport 目錄,而在不同的WebCoreSupport目錄下分別包含有對類接口
WebCore::ChromeClient 、WebCore::ContextMenuClient 、WebCore::DragClient 、WebCore::EditorClient 、WebCore::FrameLoaderClient 、WebCore::InspectorClient 等的實現,它們代表外部程序提供給WebKit 內部使用的接口實現,其中WebCore::ChromeClient、WebCore::FrameLoaderClient非常重要。
2 連接模塊 loader
對WebCore 中的page/loader 等方面的類提供對應Port 的實現支持如
EventHandlerWin.cpp 、FrameLoaderWin.cpp 、DocumentLoaderWin.cpp、DocumentLoaderWin.cpp、WidgetWin.cpp、KeyEventWin.cpp等. Loader 是在WebKit 里面一個很重要的連接器,通過loader 發起IO下載網頁,再通過loader發起解析,已經最后的渲染功能。
3 顯示模塊WebView和WebFrame
WebView 及WebFrame 主要功能是方便外部程序嵌入WebKit不同的Port 移植對WebView 及WebFrame的定義及實現有所不同,但其與WebCore中的Page、Frame 之間的關系圖描述相一致。
4 chrome中對Port移植方面的實現
其基本上與其他Port 移植類似,其主要代碼在webkitglue 目錄中, 可重點關注帶client_impl.cc 后綴的文件、webview_impl.cc、webwidget_impl.cc 等。但是其究竟如何創建原生windows 窗口、如何創建Render 進程、 Render 進程與創建
的原生windows 窗口的關系如何等需要更進一步深入研究Chrome,如果能從上面提到的Port部分入手也許很快就可得到答案。
5 Android中對Port移植方面的實現
其實現有點特殊,由 于Andriod 將WebKit 以一個Java 類接口的方式提供給Java 環境使用(不像上面提到的Chrome、Safari 等都是將WebKit 以 一個C++動態或靜態庫的方式供C/C++外部程序調用),這樣WebKit 內部與外部即JavaVM 的交互(如上面提到的ChromeClient、FrameLoaderClient 接口實現)需要一個Bridge 類來協調處理,同時WebView、WebFrame 接口綁定給JavaVM 的jni 接口實現也需要通過這個Bridge 來支持協調處理。具體可詳細參考android源碼代碼中WebCoreplatformandroid目錄下的源文件。
篇二:webkit開發學習筆記
由于工作需要,最近在準備一個介紹webkit的PPT文檔, 我個人斷斷續續學習webkit的代碼也有一年多了,其間也閱讀了網上的一些webkit相關技術文章,但中文的資料很少,大部分都是english的,有些E文資料還需要翻墻。平常由于自已記性不好,去年看過的一些模塊今年再去翻時,竟然沒一點印象了,悲劇??
所以,借此機會,把自已對webkit的理解先做下筆記,以便于以后需要時可以方便查閱。 需要說明的是,筆記記錄的有我個人的理解,也有網上摘錄的片段和圖片,不一定正確,也會比較凌亂,希望看到的朋友及時指正,共同進步。
一.
Webkit的由來
1. 十幾年前的故事
1994年,Netscape瀏覽器曾占據整個瀏覽器市場的90%,風頭無二(也很囂張)。但隨著微軟推出win95后,把IE 1.0做為win95的插件發布,開始挑戰Netscape的霸主地位,到發布IE 4.x,短短三年時間,打敗Netscape。 這里面雖然說有與windows集成的原因,但從本身的功能上來講, IE從速度和對標準的支持上來講,已真正打敗了Netscape。
此階段的瀏覽器可稱為第一代瀏覽器。它的主要特點是單窗口型式。競爭的最主要是訪問速度、兼容性。原因:90年代都大多是用modem撥號上網,56K/S。
2.Webkit出生
Apple公司在它的Mac OS X里,集成了基于KHTML 改進型的 WebKit 引擎的瀏覽器,命名為:Safari,當年蘋果比較了 Gecko 和 KHTML 后,之所以選擇了后者,就因為它擁有清晰的源碼結構、極快的渲染速度。(KHTML是由KDE 小組開發的)
隨后, apple將它開源。
至此,第二代瀏覽器,基本上是三分天下:
Trident: IE系列, 以Trident 作為內核引擎;
Gecko: Firefox 是基于 Gecko 開發;
WebKit: Safari, Google Chrome, 搜狗雙核瀏覽器(集成IE和chrome), QQ瀏覽器5。
WebKit 內核在手機上的應用也十分廣泛,例如 Google 的手機 Gphone、 Apple 的 iPhone, Nokia’s Series 60 browser 等所使用的 Browser 內核引擎,都是基于 WebKit。
總結:
webkit是什么?
答:Webkit是一套瀏覽器排版代碼, 已開源,主要由apple公司在維護。強調: webkit僅僅是一套排版引擎,
舉個例子說明下:
google的chrome是一個瀏覽器對吧, 那chrome主要包含以下模塊: 外殼UI(多標簽,菜單,狀態欄,網址輸入欄等),讀取網絡數據的模塊,排版解析模塊,JS解析引擎。 外殼UI是google自已寫的,js引擎是google寫的V8, 讀取網絡數據模塊用的winhttp,只有排版引擎用的webkit。
不知道我說清楚了沒,呵呵。
WebKit is an open source Web content engine for browsers and other applications. We value real-world web compatibility, standards compliance, stability, performance, security, portability, usability, and relative ease of understanding and modifying the code (hackability).
二. Webkit編譯環境
Webkit的官網:/retype/zoom/5b3f590ceff9aef8941e0617?pn=4&x=0&y=0&raww=626&rawh=719&o=png_6_0_0_135_113_704_808_892.979_1262.879&type=pic&aimh=551.3099041533546&md5sum=a27dea88b29041c789cb0213818b8bbc&sign=171bf19a9b&zoom=&png=87947-148147&jpg=0-0" target="_blank">點此查看
編譯運行。在Visual Studio中設置browser工程為主工程,然后編譯?梢皂樌幾g完成,下面是運行后的效果圖。
4. 最最簡單的webkit學習環境-ISee
5. Isee是一位中國人移植的webkit, 在winxp下用vs2008直接編譯即可調試,用于學習
最好,強烈支持,也是一位同事推薦給我的,后面的代碼走讀主要基于該環境。
6. Isee還可以直接移植到wince平臺運行噢。
7. 官網:
備注:原作者已經不再維護了。所以webkit內核的版本號有點老。
8. webkit在vs2008中編譯
見 :
三. Webkit整體介紹
1. Webkit的結構圖(以ISee架構舉例):
篇三:WebKit 學習文檔
WebKit gtk+學習文檔
簡介 WebKit 是一個開源瀏覽器網頁排版引擎,與之相應的引擎有Gecko(Mozilla,Firefox 等使用的排版引擎)和Trident(也稱為MSHTML,IE 使用的排版引擎)。同時WebKit 也是蘋果Mac OS X 系統引擎框架版本的名稱,主要用于Safari,Dashboard,Mail 和其他一些Mac OS X 程序。WebKit 所包含的 WebCore 排版引擎和 JSCore 引擎來自于 KDE 的 KHTML 和 KJS開源項目,當年蘋果比較了 Gecko 和 KHTML 后,仍然選擇了后者,就因為它擁有清晰的源碼結構、極快的渲染速度。
目前使用WebKit 引擎的瀏覽器主要有:Safari(apple出品),Midori,chrome(google出品)等。
Adobe AIR也采用了WebKit渲染HTML。
一、用到的庫:
除了平臺相關的庫, WebKit 需要用到的一些主要的后臺庫有:
ICU : International Components for Unicode , 一個成熟,廣泛使用的一套為 C / C + + 和 Java 庫提供 Unicode 的 全球化支持軟件;
XSLT : eXtensible Stylesheet Language Transformation, W3C 定義的用于 XML 文檔轉換的規范; Curl : 一個利用 URL 語法的命令行數據傳輸工具,基于 libcurl 。
Sqlite : SQLite 是實現了 SQL92 標準的 SQL 數據庫引擎,它能在一個庫里組合數據庫引擎和接口 , 將所有數據存儲于單個文件 ;
Gperf :一個很完美的哈希函數生成器; Flex : Fast Lex, 快速詞法分析生成器; Bison :語法分析生成器,可以將一段帶注釋的上下文無關語法轉化成 LALR 或 GLR 語法; Enchant :一個拼寫檢查庫,提供單詞的拼寫檢查、糾錯等功能;
二、 代碼目錄結構
WebKitTools:一些測試 WebKit 實現功能的程序; WebKit:此目錄位于 WebKit 的最上層,定義了與應用相關的一些接口,因此它是平臺相關的,子目錄是對應平臺的完整實現:
WebCore: WebKit 的核心部分,定義了瀏覽相關的數據 IO 、頁面加載、腳本分析、 UI xml:提供 xml 相關的內容; 組織、事件處理、網絡分析、平臺相關的具體實現等內容。
html:提供 html 相關的內容;其下的 Canvas 目錄定義了 3D 畫布以及 WebGL 庫相關的內容;
wml: Wireless Markup Language ; css:提供 css 相關的內容; dom:提供 dom 相關的內容; editing:編輯相關的功能; page:瀏覽相關內容,并非是我們看到的一個頁面,在一次瀏覽會話中,它只有一個實例; rendering:頁面渲染相關的內容,在對頁面腳本進行 DOM 樹分析之后,需要對這些元素進行渲染和顯示;
notification:內部模塊間的事件通信; history:頁面瀏覽歷史記錄相關的內容; svg:矢量圖形功能,有選項, --svg ;
mathml: W3C 為網頁中的數學表達式制定的規范;有編譯選項, --mathml ; loader加載資源及 Cache ; :
workers:“ Web Workers 為 WEB 前端網頁上的腳本提供了一種能在后臺進程中運行的方法。一旦它被創建, Web Workers 就可以通過 postMessage() 向任務池發送任務請求,執行完之后再通過 postMessage() 返回消息給創建者指定的事件處理 程序 ( 通過 onmessage 進行捕獲 ) 。
Web Workers 進程能夠在不影響用戶界面的情況下處理任務,并且,它還可以使用 XMLHttpRequest 來處理 I/O ,無論 responseXML 和 channel 屬性是否為 null !
storage : Web Storage 相關的內容,保存頁面的數據,可以看成是 Cookie 的升級; websockets :與網絡連接相關的內容; bridge: 主要包含 NPPlugin(Netscape Plugin) 方面的接口訪問等內容; binding : Dom 與 JavaScriptCore 綁定的功能;
accessibility :提供控件的可用性相關的內容, accessibility 常用來形容對一些特殊人群的功能支持,比如殘障者、老人等;
icu :里面放了專門為 Mac OS X 10.4 編譯的 icu 相關頭文件 ; platform :提供了平臺相關的具體實現,如事件響應、本地化、網絡連接等; plugins :插件相關內容; ForwardingHeaders :頭文件;
inspector : Inspector 是 WebKit 提供的查看網頁源代碼, DOM 樹,以及調試腳本的工具,本目錄包含了實現此功能的內容;
English.lproj :本地化文件; Resources :資源,圖標;
WebCore.gyp :工程文件。 GYP ( Generate Youre Project )是 google 自己開發了一個腳本工具,這個工具也 是采用 python 編寫的。它采用了自定義的一套規則,用于生成各種工程文件;
JavaScriptGlue JavaScriptCore :有關 JavaScript 的相關內容,包括了腳本解釋器、分析器以及執行程序; PlanetWebkit: 一個比較靈活的 RSS 閱讀器; Webkit 網站上的 Planet :一站式的 Webkit 開發與動態信息;
三、體系結構
WebKit 主要包括三部分: WebKit , WebCore ,以及 JavaScriptCore ,加上所使用的庫,依托的平臺,其基本的體系結構 (Architecture) 如下所示:
注意有的模塊相對于下面的模塊有突出,這是因為此模塊與下面幾個模塊直接相關,比如 WebCore 模塊就與JavaScriptCore 、 Libraries 和 Platforms 模塊直接相關。
四、Webkit/gtk +中下層與gtk的接口
WebKit中實現網頁上所有信息的顯示一部分是由WebKit本身畫出來的,一部分是利用gtk的接口實現部分對象的顯示,其中本身畫出來的部分的代碼實現部分主要位于editing和rendering兩個目錄下,利用gtk提供的一些控件的接口實現網頁上一些對象的顯示主要集中于platform/gtk/目錄下:
./platform/gtk/RenderThemeGtk.cpp
./platform/gtk/ContextMenuGtk.cpp
./platform/gtk/FileChooserGtk.cpp
./platform/gtk/WidgetGtk.cpp
./platform/gtk/Language.cpp
./platform/gtk/PasteboardGtk.cpp
./platform/gtk/CursorGtk.cpp
./platform/gtk/ContextMenuItemGtk.cpp
./platform/gtk/ScrollbarGtk.cpp
./platform/gtk/LocalizedStringsGtk.cpp
./platform/gtk/DragImageGtk.cpp
./platform/gtk/PlatformScreenGtk.cpp
./platform/gtk/PopupMenuGtk.cpp
./platform/gtk/PasteboardHelper.cpp
./platform/gtk/GRefPtrGtk.cpp
./platform/gtk/ScrollbarThemeGtk.cpp
./platform/gtk/ScrollViewGtk.cpp
./platform/gtk/ClipboardGtk.cpp
./platform/gtk/GtkPluginWidget.cpp
./platform/network/soup/ResourceHandleSoup.cpp
./platform/graphics/gtk/IconGtk.cpp
./platform/graphics/gtk/FontPlatformDataPango.cpp
./platform/graphics/gtk/ImageGtk.cpp
./platform/graphics/cairo/FontPlatformDataCairo.cpp
./plugins/gtk/PluginViewGtk.cpp
1、
各個文件實現的功能 RenderThemeGtk.cpp
該文件主要實現了對一些基本控件的創建與屬性的設置,例如:button,Toggle,Checkbox,RadioMenuList,Text,Background,Foreground,ListBox,Container,Entry,TreeView,MediaSlider等
ContextMenuGtk.cpp 該文件主要是對文本菜單(ContextMenu)的創建 FileChooserGtk.cpp 該文件中包含兩個函數: static bool stringByAdoptingFileSystemRepresentation(gchar* systemFilename, String& result); 該函數是得到systemFilename中所包含的文件的名稱,通過result值返回
String FileChooser::basenameForWidth(const Font& font, int width) const;
通過給定文本的字形名稱,和一定的寬度,從而得到該長度下可以顯示最長文本信息 WidgetGtk.cpp
該文件主要是對widget的一些屬性的設置,例如:光標、焦點、顯示,隱藏,還有對widget自身的新建與銷毀等等
Language.cpp
該文件僅包含一個函數:
String defaultLanguage();
該函數實現返回當前默認的語言類型
PasteboardGtk.cpp
該文件主要是對剪貼板的操作,文件中所包含的函數主要有:
static void clipboard_get_contents_cb(GtkClipboard *clipboard, GtkSelectionData *selection_data, guint info, gpointer data);
得到指定剪貼板當前的內容
static void clipboard_clear_contents_cb(GtkClipboard *clipboard, gpointer data);
清空指定剪貼板中當前的內容
Pasteboard* Pasteboard::generalPasteboard();
創建一新的剪貼板
void Pasteboard::writeSelection(Range* selectedRange, bool canSmartCopyOrDelete, Frame* frame);
存儲所選內容至剪貼板中
void Pasteboard::writePlainText(const String& text);
保存純文本至剪貼板中
void Pasteboard::writeURL(const KURL& url, const String&, Frame* frame);
保存URL至剪貼板中
void Pasteboard::writeImage(Node* node, const KURL&, const String&);
保存圖片文件至剪貼板中
void Pasteboard::clear();
清除默認剪貼板中的內容
PassRefPtr
//欠缺
String Pasteboard::plainText(Frame* frame);
返回當前剪貼板中的純文本內容
CursorGtk.cpp
該文件主要實現了對各種不同光標類型的的創建
ContextMenuItemGtk.cpp
該文件主要實現了對文本菜單的一些操作,例如:
static const char* gtkStockIDFromContextMenuAction(const ContextMenuAction& action); 根據所操作的對象得到它所對應的stockID
GtkMenuItem* ContextMenuItem::createNativeMenuItem(const PlatformMenuItemDescription& menu);
創建菜單項
void ContextMenuItem::setSubMenu(ContextMenu* menu);
篇四:WebKit學習大綱
《webkit入門準備》
1. 1. C++
a) Webkit代碼風格
b)
c)
d)
e)
f)
2. 2.
a)
b)
c)
3. 3.
a)
b)
Inline Const 構造與析構 重載 繼承 泛式編程 Vector/List/HashTable Iterator 智能指針 面向對象編程 對象概念 設計模式
4. 4. 調試、測試及工具
a) Gcc及Makefile
b) Trace
c) VC
d) Gdb
e) Alert及javascript調試
f) GUN binary工具
g) JsUnit
h) Javascript框架Dojo
i) JsDoc
j) JsLint
k) HTML Validator
l) Dom inspector
m) Xml spy
n) 標準測試用例
5. 5. 性能分析
a) Gprof
6. 6. Socket
7. 7. 編譯原理
a) 詞法
b) 語法
8. 8. 操作系統
a) Linux線程
b) Linux 內存
c) 編譯與鏈接
9. 《體系結構詳解》
1. 瀏覽器功能結構
2. 瀏覽器結構
3. Webkit體系結構
4. WebKit目錄結構
5. WebKit編譯
10. 《HTML引擎詳解》
1. HTML語法
2. Dom Core
3. Dom Event
4. Dom Html
5. 焦點處理
6. HTML擴展
11. 《JS引擎詳解》
1. Javascript語法
2. JS Binding
3. JS Interpreter
4. GarbageCollect
5. javascript擴展
12. 《CSS排版詳解》
1. CSS語法
2. Dom-CSS
3. Dom-Style
4. Paint
5. CSS風格擴展
13. 《CURL、SSL詳解》
1. Loader
2. Curl
3. HTTP
4. SSL
14. 《XML引擎詳解》
1. XML
2. Ajax
15. 《TCMalloc內存管理機制》
1. 內存池
2. TcMalloc
16. 《其它》
1. WebKit外殼封裝
2. Plugin插件機制
篇五:webkit用例審核及處理方法(初稿)-leo
webkit用例審核及處理方法
1. 前言
Webkit官方用例大約有3萬,現已通過自動化方式將一半的用例添加進入日常的LayoutTests測試集中。還有一般需要人工地過濾,看不過的原因是什么。
2. 用例類型說明及舉例
按照測試用例給出的預期結果類型,可以將用例分為:文本型(TextResult)、圖片型(PixelResult)、Render樹型(RenderTreeResult)、HTML型(工具暫不支持)、其他特殊類型(例如,預期是音頻、pdf文件的用例,暫不支持)。
文本型:測試結果標注為TextResult,預期文件為-expected.txt,內容是:該用例使用瀏覽器打開后顯示的文字信息,如果有圖片,也不會出現在txt文件里的。用例源碼js有testRunner.dumpAsText()或testRunner.dumpAsText(false)調用。例如:
圖片型:測試結果標注為PixelResult,預期文件為-expected.png:該用例使用瀏覽器打開完全后的截屏文件。用例源碼js有testRunner.dumpAsText(true)調用。
Render樹型:測試結果標注為RenderTreeResult,預期文件一般會給出-expected.txt和-expected.png,目前只做txt的對比,效率較高。txt內容是該用例使用瀏覽器排版之后的RenderTree結構。用例源碼js沒有調用testRunner.dumpAsText()這樣的方法(目前還沒出錯,不知道其他不通過的用例會不會存在誤判)。例如:
Html型:暫時不支持測試,給出的預期文件是-expected.html,主要是根據預期文件類型來判斷。
其他類型:用例給出的預期文件是txt、png、html以外的其他類型,比如-expected.pdf,-expected.audio等。主要是根據預期文件類型判斷,這些特殊用例不支持測試。
更詳細的介紹說明見附件《LayoutTests測試用例編寫.docx》
3. 不通過用例處理方法和歸類
3.1處理方法
對于目前還未通過測試的15k用例建立excel表格記錄分析處理結果。表格設計如下:
測試同學目前需要做的工作:根據該文檔的說明,逐一分析未通過用例,將分析的結果填入表格。
開發同學根據表格信息快速定位,進一步分析根本原因,或者修改用例或者查內核缺陷。優先級高的問題已注明提tapd,開發優先解決這些問題。個別內核缺陷會轉給項目組其他相關開發同學跟進。
3.2歸類
對不通過的用例結果和基準對比,分析原因歸類,分為:
1、(用例在)目錄測試時crash:測試該用例目錄時,該用例必現crash,但是單獨測試該用例時并不會crash,原因應該和前后用例行為有關,需要整個目錄測試復現問題解決。處理方法:提tapd bug。
2、內核crash:用例使用瀏覽器打開過程必然crash。處理方法:提tapd bug。
3、工具crash:用例不會在瀏覽器打開過程crash,但是單獨測試時比如crash。處理方法:提tapd bug。
4、(測試用例)內核不支持:測試用例調用了某些js方法,需要內核專門支持測試而增加的,目前X5內核還不能支持。處理方法:將分析的原因填入對應的excel表格,調用的特殊js對象描述清楚,方便后期確定是否實現支持。
5、(測試用例)工具不支持:測試用例中,testRunner調用了某些js方法并未實現,例如testRunner.display()。處理方法:將分析的原因填入對應的excel表格,調用的特殊方法描述清楚,方便后期繼續跟進。
6、(測試工具)類型判斷錯誤:工具判斷出來的用例類型和用例給出的基準文件判斷的類型不一致。處理方法:將原因填入對應的excel表格。
7、內核缺陷:工具和內核對用例測試完全支持,測試結果和預期存在差異,判定為內核邏輯缺陷。處理方法:將原因填入對應excel表格。
8、html型用例:用例給出的預期文件是expected.html,工具暫不支持測試。處理方法:將原因填入對應excel表格。
9、其他類型用例:用例給出的預期文件類型不是txt、png、html(htm)之一的,工具暫不支持。處理方法:將原因填入對應excel表格。
10、其他原因:不能歸入前9類的另類原因。
4. 審核步驟、歸類及處理方法
注: 所有提tapd的bug請標題注明 LayoutTests,處理人leolincao、totorima
首先,打開目錄對應的Details.html文件,逐一審核未通過的用例。
4.1 分析Crash用例
Details.html文件中,注明是CrashedDummyResult,該用例測試過程crash。
1、單獨測試該用例是否crash,如果沒有crash,歸類為:目錄測試時crash。
2、使用瀏覽器打開該用例,如果crash,歸類為:內核crash,提tapd;否則歸類為:工具crash,提tapd。
4.2 分析Timeout用例
Details.html文件中,用例后面有黃色底色的TIMED OUT標識用例。
TIMED OUT用例大多數原因是用例調用的部分js對象方法不支持,導致js執行中止;js執行了testRunner.waitUntilDone (),但testRunner.waitUntilDone()未能執行。
1、查看用例源碼,包括html和js資源文件。
2、閱讀主要的js代碼,是否存在特殊的js對象調用。
如果存在window調用了未知的js對象(testRunner例外),歸類為:內核不支持。記錄下window調用的未知js對象名稱。
如果存在testRunner調用js方法,除了一下這些方法外,還存在其他方法,歸類為:工具不支持。記錄下testRunner調用的未知js對象名稱。testRunner支持的方法有:clearAllDatabases()、dumpAsText()(包括帶參和不帶參)、dumpChildFramesAsText()、dumpDatabaseCallbacks()、notifyDone() 、overridePreference()、setAppCacheMaximumSize()、setCanOpenWindows()、setDatabaseQuota() 、setXssAuditorEnabled()、waitUntilDone()。
3、還不能確定的歸類為:其他原因。
4.3預期文件找不到
Details.html文件中,如果測試結果Expected result欄為空(圖片類型用例PixelResult例外),可以判斷為預期文件找不到,先到platform/mac或者platform/win目錄(優先選擇mac目錄)結合用例相對路徑尋找對應expected文件(例如:fast/1.html的預期結果可能會在platform/mac/fast/或者platform/win/fast/下面),復制到用例所在目錄。然后重新測試,如果測試通過,將用例加入DB測試集,否則根據測試結果重新判斷歸類。(圖片用例的判斷有專門章節繼續說明)
預期找不到用例:
4.4類型判斷不準確
Details.html文件中,根據給出的預期結果判斷該用例測試類型(TextResult、RenderTreeResult、PixelResult),或者在用例路徑找到對應的expected文件,判斷用例類型,如果根據預期結果判斷的類型和測試結果給出的測試類型不一致,歸類為:類型判斷錯誤。
根據前面的規則判斷之后,其他的未通過用例按照類型詳細說明:
4.5圖片類型用例
Details.html文件中,被表示為PixelResult的用例。
1、在用例所在目錄尋找對應的expected文件。
2、如果不存在對應的expected文件,按照“預期文件找不到”章節處理方法處理,判斷結束。
3、根據預期文件判斷是否工具類型判斷錯誤,若是,歸類為:類型判斷錯誤。
4、人工對比預期圖片和測試生成的-actual.img,如果人工判斷一致,將生成的-actual.img代替預期圖片,加入DB測試集;否則,歸類為:內核缺陷。
4.6 RenderTree類型用例
Details.html文件中,被表示為RenderTreeResult的用例。
1、從Details.html對比分析生成的txt差異,如果整個文檔RenderTree結構一樣,個別元素差異一兩個像素,可以通過瀏覽器打開該用例查看顯示同chrome uc等瀏覽器打開頁面的顯示對比,如果一樣,可以使用生成的-actual.txt代替基準提交到DB測試集。
2、如果Details.html中對比文檔的RenderTree結構存在差異,則歸類為:內核缺陷。
4.7文本類型用例
Details.html文件中,被表示為TextResult的用例。
1、從Details.html對比分析生成的txt差異,如果對比差異僅僅是個別字段值不一致,歸類為:內核缺陷。
2、如果-actual.txt結果和預期結果相比缺少很多行內容,查看用例源碼,包括html和js資源文件。
3、閱讀主要的js代碼,是否存在特殊的js對象調用。
如果存在window調用了未知的js對象(testRunner例外),歸類為:內核不支持。記錄下window調用的未知js對象名稱。
如果存在testRunner調用js方法,除了一下這些方法外,還存在其他方法,歸類為:工具不支持。記錄下testRunner調用的未知js對象名稱。testRunner支持的方法有:clearAllDatabases()、dumpAsText()(包括帶參和不帶參)、dumpChildFramesAsText()、dumpDatabaseCallbacks()、notifyDone() 、overridePreference()、setAppCacheMaximumSize()、setCanOpenWindows()、setDatabaseQuota() 、setXssAuditorEnabled()、waitUntilDone()。
4、還不能確定的歸類為:其他原因。
4.8 html類型用例
根據預期文件判斷用例是html類型用例,歸類為:html型用例工具不支持。該類型用例后期需要支持。
【Webkit 學習技巧】相關文章:
學習技巧與考試技巧11-13
學習技巧05-30
最佳學習技巧10-05
學習技巧總結10-05
關于學習技巧10-06
學習技巧介紹10-07
德語學習技巧10-07
蛙泳的學習技巧11-13
學習韓語技巧10-11
學習隸書技巧10-11