自動化測試框架不難，難的是細節（總結片）

 

1、自動化測試

一、自動化測試腳本大體可劃分爲：

　　|、線性腳本：經過錄制直接產生的線性可執行的腳本

　　|、結構化腳本：具備順序、循環、分支等結構的腳本

　　|、可共享腳本：能夠被多個用例使用，被其餘腳本調用的腳本（即模塊化腳本）

　　|、數據驅動腳本：測試數據跟業務流程控制分離的腳本，經過讀入數據文件驅動流程進行的腳本

　　|、關鍵詞驅動腳本：腳本、數據、業務分離、數據和關鍵詞在不一樣的數據表中，經過關鍵詞來驅動測試業務邏輯，關鍵詞的特色是，它更像是描述一個測試用例在作什麼，而不是如何作

　　|、混合型腳本：以上任意兩種及以上

　　|、敏捷自動化測試腳本/框架：這一塊等我有了成功經驗再補充=。=

 

二、自動化測試執行：

　　（1）無人值守的測試：環境搭建，部署與配置；自動化測試用例與測試腳本相互綁定；自動化測試用例執行順序排列與組合

　　（2）異常處理與場景恢復

 

 

三、自動化測試的難點（界面的變更性和腳本的維護性）：

①公共自動化用例的維護

②公共UI方法維護

③穩定性和效率提高：

　　|、異常處理封裝

　　|、分層測試

　　|、創建共享對象庫/測試庫

　　|、第三方插件引入

　　|、GUI業務流程解耦拆分、儘可能避免太長的端到端UI測試(例如web到移動端的業務流測試)

　　|、引入mock/接口測試代替部分環節的測試，從而銜接到要執行自動化測試，提升自動化測試穩定和效率

　　|、web處理一些不可識別第三方控件。儘量採用js來處理，更顯示穩定和高效

　　|、uiautomator監聽處理android系統不肯定的系統級別彈窗

④自動化測試實施項目選取策略：

　　|、重複性高且有必要的測試流程

　　|、項目週期長，系統版本不斷，而且需求不會頻繁變動項目

⑤自動化測試框架包括：

　　|、測試用例分佈式執行：seleniumGrid

　　|、腳本模塊化：分層

　　|、數據驅動:mysql存儲數據，testng的數據提供者

　　|、日誌分析：本地log4用例執行信息

　　|、錯誤截圖：監聽截圖

　　|、報表回收：測試數據存儲mysql數據庫等

　　|、共享對象庫/公共函數庫：UI元素信息管理/UI元素操做方法維護

　　|、環境配置：chromedriver/adb/IEdrver/Firefoxdriver

　　|、用例統一設計模式：基類(測試用例beforeclass/afterclass)，多用例集中於一個需求/模塊裏

　　|、異常處理：testngListenter監聽，UIwater處理系統級彈窗

　　|、接口和mock結合介入

　　|、第三方工具引入：adb/shell/redis

　　|、用例執行方式(分佈式測試seleniumGrid、device多併發測試)

自動化廣義總結：
一、自動化測試工做不復雜但也不簡單，其須要自動化測試人員既懂業務也懂技術。
二、對自動化測試見解太低以及對自動化測試要求過高，都是由於其盲目性，一個懂產品技術和自動化測試技術的工程師，是很快能定位其自動化測試需求和開展的方法。
三、每一個公司有每一個公司本身的特色，調研和需求分析很重要。
四、自動化測試框架不難，難的是細節。
五、自動化平臺很重要，沒有一個平臺，不方便推廣，其自動化測試只能流於形式。

 補充：

自動化測試框架找對象：

一般每種框架都應該支持動態跟靜態兩種找對象的方式，靜態找就涉及到對象庫，包括對象庫的讀、寫、合併、維護等一系列問題，這些均可以交給框架作；

關於動態查找，我舉個RFT的例子，大家意會一下：

Two types of find API in Rational Functional Tester:

• find(Subitem Properties).
• find(Subitem Properties, Boolean mappableOnly).

       Subitems can be either atChild() or atDescendant() or atList().

• atChild: One or more properties that must be matched against the direct child of the starting TestObject.
• atDescendant: One or more properties that can be matched against any child of the starting TestObject
• atList: A sequential list of properties to match against. Valid subitems for atList are atChild, atDescendant, and atProperty.
• mappableOnly: Arguments that limit the search. If it is set to true, the search for children will be limited to those test objects that are mappable, otherwise non-mappable test objects are also searched.

 

先測試工具會提供動態查找的接口或者方法，RFT裏面提供的是find方法，調用這些接口或者方法便可實現動態查找。

動態查找的好處是能夠採用「相對路徑」來定位對象，而相對的，對象庫則採用的是「絕對路徑」。若是一旦對象的一些屬性改變，靜態查找的方式可能會找不到對象，固然了，如今的自動化測試愈來愈智能，已經能夠作到選取匹配度最高的對象返回。動態查找還有個好處是它找到的對象是「代碼」，你能夠進一步在框架裏去對這些對象進行處理，而對象庫裏的每個對象都是一個獨立的對象，你可使用它們，可是很難改變它們。

一般如今的自動化測試框架都是採用動靜結合的方式，即兩種找對象的方式都會兼顧，由於通常來講，靜態查找的方式速度更快，效率更高。可是靜態查找帶來的問題也是顯著的，主要集中在對象的維護管理以及合併上，如何共享對象，避免重複加對象等。此時，規範對象命名就顯得很重要了。以往我作的自動化測試項目中，這些都是坑。