基于JAVA實作的WEB端UI自動化 -自動化測驗簡單介紹

1 - Web自動化測驗簡介

• 軟體測驗領域技術不斷創新
• 手工測驗重復性作業量較大
• 技術革新，通過使用工具或者腳本代碼讓計算機幫助測驗人員完成一些簡單操作

1.1 自動化測驗的本質

• 其本質是把手工測驗轉化成使用計算機、軟體、程式來測驗產品的程序，在設計
  測驗用例并通過評審之后，由測驗人員根據測驗用例中描述的步驟來一步一步執 行測驗代碼，得到的實際結果與期望結果進行比較，

• 重復姓的測驗作業在時間緊迫的情況下會有范圍遺漏，為了節省人力、時間、資 源、提高測驗效率，保證測驗范圍，引入了自動化測驗概念，

1.2 自動化真的具有絕對的高效性？

• 自動化并不是絕對的完全高效率，
• 在產品需求變更頻繁，專案周期較短，開發人員代碼不夠規范的情況下，給自動化腳本的撰寫也帶來大量的修改，甚至因為開發人員撰寫的代碼的問題從而提升 了自動化腳本撰寫的難度，需要花費大量的時間去解決一些腳本撰寫程序中遇到 的一些未知的問題，那么這種情況下，手工測驗往往要比自動化測驗要更有效率，

1.3 手工測驗與自動化測驗的比較

• 通常情況下，測驗的作業量會占據整個專案的的40%-60%的開發時間，甚至有的
  時候開發作業還沒有開始，測驗人員就已經介入了專案，
  測驗程序中，許多的程序是重復性、非智力性、非創造性、并要求做準確細致的作業，這個時候計算機就是最適合代替人工去完成這樣任務的角色，
• 自動化測驗是相對手工測驗而存在的，主要是通過軟體測驗工具、腳本等來實作的，自動化測驗腳本具有良好的可操作性、可重復利用性和效率高等特點，

1.4 手工測驗的局限性與自動化測驗的優勢

手工測驗的局限性：

• 手工測驗無法覆寫所有的代碼路徑
• 簡單的功能性測驗用例在每一輪的測驗中都不能少，而且具有一定的機械性、重 復性，作業量較大，影響效率，
• 舉例：如果有大量（幾千）的用例，短時間內，手工測驗往往是做不到的，

自動化測驗的優勢：

• 縮短軟體開發測驗周期，可以讓產品更快的投放市場，
• 測驗效率高，可以充分利用硬體測驗資源
• 節省人力資源，降低測驗成本
• 增強測驗的穩定性和可靠性
• 提高軟體測驗的的準確度和精確度，從而增加軟體的信任度
• 使測驗作業相對比較容易，但能產生更高質量的測驗結果

附：自動化測驗絕不是因為厭倦了重復的測驗作業，想要取代掉手工測驗，相反的 是因為測驗作業的需要，更準確的說是為了回歸測驗和系統測驗的需要，

1.5 自動化測驗介入的場景

那么問題來了，自動化能否取代手工測驗？

首先，我們要考慮的是，什么樣的專案適合自動化？

• 決定專案能否采用自動化測驗，通常從以下幾個方面考慮：
  • 需求的變更有計劃性，且變更的頻率不高
  • 專案的周期較長，硬體軟體人工資源配置豐富，
  • 自動化腳本的重復使用率高
  • 開發人員代碼撰寫的規范性

在確定了什么樣的專案可以使用自動化之后，身為測驗人員還要考慮在專案中， 那些部分適合自動化，

• 普遍的觀點是：很多人認為自動化更適合回歸測驗和API測驗，手工測驗更 適合做驗收測驗和GUI測驗，

• 其實正確的觀點：區分手工測驗和自動化測驗的，實際上與API還是GUI，回歸測驗還是功能測驗都沒有關系，應該從代碼是業務邏輯相關還是基礎性代碼這兩個方面出發考慮，

  • 業務邏輯代碼：對應終端用戶使用的哪些功能，是實際完成作業的，

  • 基礎性代碼：確保業務邏輯代碼運行在合適的環境中，起支撐作用而彼此之間又相對獨立，并不存在業務關系，

  • 兩種代碼都要測驗，手工測驗更適合測驗業務邏輯，

• 手工測驗適合成為領域專家，他們可以把想當復雜的業務邏輯存在最強力的測驗工具—大腦里，而且手工測驗速度比較慢，測驗人員就有時間可以觀察分析細微的邏輯問題，速度雖然慢，但是比較容易，

• 自動化測驗勝在測驗底層的細節，自動化可以測驗錯誤回傳值、回傳碼、例外和記憶體使用等等，速度快但是也困難些，相對業務邏輯進行自動化測驗比較困難， 風險也略大，

1.6 自動化測驗的流程

需求分析>>>自動化測驗規劃>>>自動化測驗腳本撰寫>>>測驗執行>>>測驗總結

自動化測驗規劃：功能>>>自動化>>>安全（滲透）>>>性能

關于"安全（滲透）"這一塊的"自動化"16年在寫這一份檔案的時候僅僅停留在字面的概念上，隨著近兩年學習從事安全領域以及所做的一些漏洞挖掘之后對這一塊有了很深刻的印象，比如圈內一些很厲害的白帽子師傅通過自己撰寫的自動化腳本以及POC、EXP然后進行全網的掃描[此時已經不僅僅是局限于某個產品端了],可以挖掘大量的高危漏洞甚至可以直接getshell，

需要說明的是 “安全（滲透）測驗” 雖然也是"測驗"，但與傳統意義上的軟體測驗還是有很大區別的，就我個人的理解 “安全（滲透）測驗” 是一門領域性的技能和應用場景，雖然在某些方面有些許的重疊，比如安全領域的"邏輯漏洞" 與測驗人員測出的功能上的BUG ，但是其還是有本質上的區別的，

1.7 適合自動化測驗的工具

• 支持腳本化語言(Scripting Language)
• 對程式界面中物件的識別能力
• 支持函式的可重用性
• 支持外部函式庫
• 抽象層—將程式界面中的物件物體映射成邏輯物件
• 支持資料驅動測驗(Data-Driven Test)
• 錯誤處理
• 除錯器(Debugger)
• 源代碼管理
• 支持腳本的命令列(Command Line)方式

2 - 常用的自動化測驗工具

2.1 QTP

• QTP是由HP提供的側重于功能的回歸自動化測驗工具；提供了好很多插件，如.NET的，Java的，SAP的，Terminal Emulator的等等，分別用于格子型別 的產品測驗，默認提供Web，ActiveX和VB，【講道理,目前我所接觸的專案還沒有使用該工具的前幾年從朋友那里了解到 交行與東航貌似還在使用該工具，不過該工具的最新版本已經叫 “UTF” 了,下文有介紹】

• QTP 的腳本語言是VBScript，這對于測驗人員來說，感覺要“舒服”的多，VBscript畢竟是一種松散的、被閹割的、普及面很廣的語言，【其實就是弱型別語言】

• QTP支持錄制和回放的功能，
  錄制產生的腳本，可以用來作為自己撰寫的template，
  錄制時還支持lower lever功能，該功能用于QTP不易識別的物件使用，不 過它是使用坐標來標識的，對于坐標位置頻繁變動的物件，此種方法不可取，
  QTP編輯器：Keyword模式與Expert模式，
  Keyword模式：類似RobotFrameWork的表格視圖，
  Expert模式：代碼視圖，

2.2 Selenium(Webdriver)

• 價格：開源、免費
  相較于QTP而言（商業版、收費的、一個lessons大概價格100萬美金左右）
  絕大多數的公司在商業版軟體上更愿意選擇使用Selenium完成同樣作業的高級自動化測驗人才，畢竟大多數的公司的最終目的還是以營利為主，【插句題外話,商業版的軟體往往在報告輸出上做的非常完善，】

• 應用領域：基于瀏覽器的Web端自動化測驗，Selenium僅支持Web頁面的測驗作業；
  QTP不僅支持Web界面的測驗作業，還支持Client方面的測驗，這一點上是 Selenium的不足之處，

• 功能方面：
  錄制功能方面，QTP要強于Selenium，
  QTP錄制回放成功率很高，但是Selenium的錄制回放功能成功率就非常的低， 所以我們在測驗程序中也不會使用錄制功能，
  腳本的編輯方面，不好判斷，
  熟悉Java、Python等的人，會比較喜歡Selenium，
  熟悉VBScript就比較喜歡QTP，

• 框架處理能力：
  在資料驅動方面，QTP支持很靈活，可以通過簡單的設定就可以完成資料驅動的自動化腳本，
  Selenium需要編程來實作才可以，但是這點并不能說明Selenium在框架的處 理能力上就比QTP差，Selenium提供了更加開闊的框架處理能力給客戶看， 用戶可以根據自己的實際情況開發出更適合自己的自動化測驗腳本，
  舉例：在進行Web端頁面測驗的程序中，我們不能保證頁面就是恒定不變的， 所以這個時候，在自動化測驗平臺中就可以有一個頁面層，頁面變化了，只 需要通過修改頁面層的代碼（元素定位）來適應，而不需要去修改在頁面之 后的測驗用例代碼，這樣就可以簡化我們的代碼的作業量，

• 用戶仿真：
  Selenium在瀏覽器后臺執行，它通過修改HTML的DOM（檔案物件模型）來 執行操作，實際上是通過JavaScript來控制的，執行時視窗可以最小化，可以 在同一個機器執行多個測驗Case，
  QTP是完全模擬終端用戶，獨占螢屏，同一時間只能開啟一個獨占的實體，
  在并發性上來講，Selenium更好一些，

• UI組件支持：
  Selenium支持主要的組件，但是某些特殊事件、方法和物件屬性支持不夠
  QTP提供了良好的支持，通過收費的插件，提供了對各種組件的支持，

• 物件識別：
  QTP所見即所得，用SPY插件、物件庫的方式獲取
  Selenium提供的是各種物件識別介面來識別

• 支持的平臺：
  Selenium支持多種語言，可以跨平臺，
  QTP只使用于windows，

• 腳本創建：
  QTP視乎更容易一些
  Selenium略難，需要一定的代碼知識能力

2.3 UFT(Unified Functionnal Testing)

UFT是QTP的新名字，叫統一功能測驗框架，較QTP而言增加了一些新的功能，

• Insight智能影像識別
  影像識別一直是自動化測驗的阻礙之一，包含游戲自動化、flash動態的一些 自動化，
  附：這個影像識別比較類似sikuli的方式，以影像方式進行識別，所以對驗證 碼等的識別沒有太大的作用，（白興奮了 o(╯□╰)o）【不知道幾年過去了,UFT這方面有沒有長進】

• 多腳本除錯（個人觀點，雞肋，類似于開多個視窗進行除錯）

• PDF文本驗證點
  現在UFT可以識別PDF檔案并對他們直接進行比較，甚至可以插入文本驗證點，

• 支持開源CI（雞肋，現在大多數自動化測驗工具都支持CI）

• 支持移動設備（仍然雞肋，移動端自動化的工具也很多）

2.4 RFT(IBM Rational Functionnal Tester)

IBM的一款適合功能測驗、回歸測驗的自動化測驗工具，
它的基礎是針對于Java、.NET的物件技術和基于Web應用程式的錄制與回放，
我們可以利用它以Eclipse為核心的特點用Java腳本自行撰寫更具有靈活性的自動化測驗腳本用于日場和回歸測驗，這款自動化測驗框架是在Selenium出現之前大家認為最容易進行擴展的一個框架，
TIP：盡管RFT提供了錄制和回放的功能來開發自動化腳本，但這并不是一個很好的方法，很多測驗團隊也并沒有采用，因為錄制與回放功能對于程式運行的環境運行依賴性太大，包括了程式的位置、視窗的解析度，每個變化都將會導致腳本無法正確的運行，因此更多使用該工具的測驗團隊采用了自己手動寫腳本的方式來提高腳本的易讀性以及可維護性，

• 框架結構：
  RFT的腳本可以分別被歸類為AppObjects、Tasks和Testcases
  AppObjects：定義頁面上的元素，在測驗程序中，所有用到的頁面元素都定
  義并儲存在這一層中，這一層還包含了所有頁面上顯示的字串，
  Tasks：定義可以單元化，可重用的任務，呼叫在AppObjects中定義的元素，
  Testcases：一個case寫成一個腳本，每個測驗場景，可以寫成一個或多個腳 本，每個腳本只呼叫Tasks中定義的可重用的任務，
  附：這個架構的分層架構思路基本與WebDriver的分層架構思路一致，

• 傳播與使用范圍

  • 幫助檔案和教程很少，很不系統，而提供額API介面只有說明檔案，未 提供如何使用該檔案；提供的例子很少，
  • 環境要求較高，至少得1G記憶體才能比較順暢使用，512記憶體比較卡， 速度慢
  • 引數化只支持使用XML格式檔案來存盤測驗資料
  • 回放速度超級慢
    附：所以才有了Selenium開發以后的強勢和很多之前RFT使用者可以快速上手，

2.5 Monkeyrunner(手機自動化工具)

目前Android SDK里自帶的現成的測驗工具

Monkey和MonkeyRunner

Monkey：主要用于壓力和性能測驗上，運行該命令可以隨機地向目標程式發送各種模擬鍵盤事件流，并且可以自定義發送的次數，以此觀察被測應用程式的穩定性和可靠性，應用比較簡單，記住那幾個命令就可以了，

MonkeRunner：相比較之下更強大一些，主要用于功能測驗，回歸測驗，并且可以自定義測驗擴展，靈活性較強，測驗人員可以完全控制，

2.6 Robotium(手機自動化工具)

Robotium是一款測驗Abdroid Application的測驗框架，它使得撰寫黑盒測驗代碼更 加容易和穩定，通過使用Robotium，測驗用例開發人員能夠跨越多個Activity，開 發出功能、系統以及驗收測驗用例，
Robotium是基于Android測驗框架InstrumentTestCase2進行的2次封裝，把一些基 本操作又簡化了一遍，

也是最近比較流行和正在上升勢頭的手機自動化測驗工具，

優勢如下：

• 針對黑盒測驗
• 在測驗程序中，不必需要測驗程式的源代碼，只要apk檔案（前提是需要知 道測驗程式的package和activity）
• 可以直接運行在手機上，并通過adb端獲得運行結果，

附：在使用該工具的時候有一必須點：當編輯完測驗腳本后，會生成一個apk檔案， 將該apk安裝到手機端，并通過adb輸入一系列命令后直接運行測驗腳本，但 該apk的簽名必須要與測驗程式的apk簽名保持一致，

2.7 Sikuli(新型思路的自動化測驗工具)

創新的圖形化編程技術

Sikuli是由MIT的研究團隊發布的新型圖形化編程技術，它以影像檢索技術為基礎， 提供了一套基于Jython(Python語言在java中的完整實作)的腳本語言以及集成開發 環境，使用者可利用螢屏截圖直接參考GUI元素進行編程，完成互動操作，Sikuli 一詞取自墨西哥Huichol Indian 土著語，意為“上帝之眼”，正如其開發者所說–Sikuli 讓電腦能像人一樣“看”這個“真實世界”，

• Sikuli腳本
  Sikuli的腳本撰寫遵循Python語法規范，其本身提供了多種自定義類及其自 定義方法，其詳細介紹可參見其官方網站檔案，由于Sikuli基于Jython，其核 心代碼由Java撰寫，可在用戶自定義的Java工程中將其作為Java標準類別庫 進行參考，其官方網站亦提供了JavaDoc供參考，

• 下圖為自動打開FireFox瀏覽器，并登陸Gmail的簡單實體，快速一覽Sikuli 腳本的獨特之處，

2.8為什么選擇Selenium(Webdriver)

· 開源免費
· 使用靈活簡單
· 后期用例易于維護
· 支持多種語言
· 容易與單元測驗框架結合
· 可支持多瀏覽器同時，支持遠程啟動其他服務器
· 高度復用性
· 代碼自主掌控，對于搭建框架、平臺等有不可替代的優勢

3 - 測驗自動化和自動化測驗

3.1 什么是測驗自動化？

這是一種讓測驗程序脫離人工的一次變革，對于控制成本，控制質量，回溯 質量和減少周期都有積極影響的一種研發程序，

3.2 什么是自動化測驗？

• 通過將測驗執行部分或者全部交由機器執行的一種測驗，叫做自動化測 試，這種測驗不需要人的實時參與，同時這種測驗在小規模應用時會比手工測驗昂貴許多，

• 所以自動化測驗可以看做測驗自動化的一部分，

3.3 不同的工程師，作業不同

• 一個自動化工程師，會比較專注于測驗工具的研發，最主要的是這個工程師 會從成本的角度去考慮問題，這一點比較像PM，他所做的一切是為了減少 自己或者團隊的作業量，盡可能的將重復的，有規律可循的作業代碼化，自 動化，

• 一個自動化測驗工程師，會比較專注于測驗代碼的開發，以及測驗結果的分 析，對于被測設備本身非常感興趣，他們比較傾向于一種完美主義者，追求 的是高質量而經常忽略成本，這一點更像是開發人員

• 現在絕大多數公司都會執著于自動化測驗，而忽略測驗自動化，這一點會讓 整個AT(automation test)成本變得非常高，

3.4 自動化測驗的幾個準則：

• 并不是將測驗用例代碼化了，就可以稱之為自動化測驗了，這是現在很多公司宣稱自己做AT的一個噱頭，
• AT的代碼是有很多的要求，
• 首先就是你的覆寫面要廣，個位數case的自動化完全沒有意義，
• 第二就是你的case必須要能夠復用：軟體每天都在變，如果你的case要天天跟著軟體變，那你的case是完全不合格的
• 第三就是測驗規模要夠大：要么時間長（case多），要么測驗產品多，這樣 才能體現出來自動化測驗的優勢，

3.5 測驗自動化的幾個準則：

• 一就是要減少除工具研發部門外，其他所有測驗部門的人力成本，這就是測 試自動化追求的終極目標之一，

• 二就是提高測驗質量，不僅僅包括測驗執行的質量，還包括測驗的統計質量， 資料回溯質量等等等等，這些質量的提高可以幫助測驗團隊修正他們的測驗 方法，而不是每天將精力撲在無止境的資料收集和分析中，

• 三則是要搶出時間，某一項作業自動化后的時間，要么比人手做時間短，要 么可以在非作業的16個小時中進行，通過讓電腦OT的方法來解放工程師和專案經理，

4 - 自動化測驗三個階段

4.1 基本腳本設計階段

自動化測驗：用例代碼化
將要進行測驗的功能代碼化，能夠將線性流程通過自動化腳本完成測驗
舉例：注冊>>>登錄>>>購物>>>支付>>>確認識訓>>>退出

4.2 框架腳本設計階段

測驗自動化：繁雜的作業簡要化，使用框架設計的手段，（資料驅動、關鍵字驅動、分層架構的思想）[測驗自動化第一步]

4.3 平臺設計階段

如何開發一個自動化測驗平臺？講道理,你都能搞定自動化測驗平臺了還干啥測驗啊，產品經理、研發、架構師它不香么？等有時間了看看能不能把 "87test團隊、雷子師傅"他們的自動化平臺白嫖一個,到時候放出一個思維導圖

5 - 自動化環境搭建準備與相關工具

這里以前寫過一篇關于自動化環境搭建的檔案,找到了再放出來把，

暫時沒找到,先放一個大概通用的吧，

關于瀏覽器

瀏覽器（開發者工具使用【F12】）
Chrome（版本不要太高），同時注意驅動對應的瀏覽前版本
Firefox （版本不要太高），同時注意驅動對應的瀏覽前版本
IE9、IE10
詳見：瀏覽器版本與DriverServer對應表與資源 http://www.cnblogs.com/alisapan/p/6428695.html

Selenium IDE(火狐瀏覽器上的插件)

• 在進行元素定位操作時，可通過Selenium IDE進行捕捉元素的定位

Java環境

安裝JDK，并配置環境變數，推薦1.8

同時還需要注意JDK在Selenium 兼容上存在一定的問題，

Eclipse/IDEA

WebDriver Jar包

單元測驗框架 Testng

tetsng安裝方法：https://www.cnblogs.com/xusweeter/p/6559196.html