自动化工具调研
? ? ? 最近公司組織架構調整，我從服務組的測試人員，調到了質量管理部做客戶端的質量管理。想著自己工作經驗善淺而且實際工作項目能力并不優秀的情況下，我跟上級領導提出了換崗位的要求，我希望自己還能做一個一線的測試人員，能深入的了解自己經手的每個項目，但是也提出了自己的要求，希望能轉做灰盒接口測試，能看懂代碼的業務邏輯，能找一個合適的工具輔助自己做接口測試，然后跟進代碼的業務邏輯，測試需求讓自己更深入的進行測試。然后能根本上保證服務器的測試工作的有效性，高質量性，有針對性。
? ? ? 換了老大后，新的老大給予了大量充分的時間讓我去研究接口自動化測試。公司的客戶端和服務器的協議是私有的。協議私有的意思是：在原有的tcp協議上，在會話層加了一層自己的東西，而且在傳輸數據包的時候做了加密操作。那么現在常用的自動化工具哪些適合呢？下面是我做的最基礎的自動化方面的調研。
自動化測試框架簡介
?? ?自動化測試框架：能被重用的基礎測試平臺的應用骨架。測試框架可以分成2類：一類基礎功能測試框架：提供可重用的基礎自動化測試模塊，如：selenium?、watir等；它們主要提供最基礎的自動化測試功能，比如打開一個程序，模擬鼠標和鍵盤來點擊或操作被測試對象，最后驗證被測對象的屬性以判斷程序的正確性；一類是管理執行框架：提供自動化測試執行和管理功能的架構模塊，如：Phoenix Framework，robot?，STAF?等；它們本身不提供基礎的自動化測試支持，只是用于組織、管理和執行那些獨立的自動化測試用例，測試完成后統計測試結果。通常情況都是把第二類測試框架集成在第一類測試框架中。如：robot框架就可以集成selenium??框架，Phoenix Framework集成的也是selenium框架。
? ? ? ? ? ? ? ?
分層的自動化測試
???? 這個概念最近曝光度比較高，傳統的自動化測試更關注的產品UI層的自動化測試，而分層的自動化測試倡導產品的不同階段（層次）都需要自動化測試。
?
? ? ? UI測試：對用戶界面中各個類別的控件的測試，即編寫測試用例或者點檢表，對每個按鈕的響應情況進行測試，是否符合概要設計所規定的條件等。例如：我們不斷重復的對一個表單提交，結果查詢等功能進行測試，我們可以通過相應的自動化測試工具來模擬這些操作，從而解放重復的勞動。UI層的自動化測試工具非常多，比較主流的是QTP，Robot?Framework、watir、selenium? 等。
? ? ? 接口測試: 接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。比較主流的有：SoapUI, LoadRunner。
? ? ? 單元測試：關注代碼的實現邏輯，例如一個if?分支或一個for循環的實現；集成、接口測試關注的一是個函數、類（方法）所提供的接口是否可靠。比較主流的有：XUnit系列，TestNG, GTest
? ? ??為什么是一個金字塔形呢？?因為不同階段所投入自動化測試的比例不同。如果一個產品從沒有做單元測試與接口測試，只做UI層的自動化測試是不科學的，從而很難從本質上保證產品的質量。如果妄圖實現全面的UI層的自動化測試，那更是一個勞民傷財的舉動，投入了大量人力時間，最終獲得的收益可能會遠遠低于所支付的成本。因為越往上層，其維護成本越高。尤其是UI層的元素會時常的發生改變。所以，我們應該把更多的自動化測試放在單元測試與接口測試階段進行。至于在金字塔中三種測試的比例要根據實際的項目需求來劃分。在《google?測試之道》一書，對于google產品，70%的投入為單元測試，20%為集成、接口測試，10%?為UI層的自動化測試。
?
常用的四種自動化測試框架模式
第一類：數據驅動測試框架
?
概念：將測試數據從測試腳本中分離出來，測試框架中較簡單的一類。
優點：測試數據可以單獨維護；測試人員維護測試數據；測試開發人員維護測試腳本（必須懂自動化編程和業務邏輯）。
缺點：測試程序更改導致需要修改測試腳本代碼。維護成本很高。
典型示例： web端接口測試：webService（XFire）+ TestNG
?
第二類： 測試腳本模塊化框架
???
?
?概念：一個測試腳本包含模塊中涉及到的控件識別和業務邏輯，外部測試數據的調用。
?優點：能針對模塊進行測試和維護；測試人員維護測試數據；測試開發人員維護測試腳本（必須懂自動化編程和業務邏輯）。
?缺點：??控件識別和業務邏輯本身屬于不同的領域，沒有很好進行抽象封裝；控件和業務邏輯一旦發生變化，要進行修改和維護的是底層的測試腳本。
?典型示例：selemium自動化測試模塊的簡單使用。
?
第三類：??測試庫構架框架
?
概念：將所有的針對測試系統本身的控件識別和控件支持的操作封裝在測試庫中，?測試腳本調用測試庫的同時傳遞外部的測試數據
優點：被測試系統無論是哪層發生變化，只需要相應的人員進行變更維護即可，完成了控件識別操作和業務邏輯的抽象分離；（測試庫：掌握的自動化測試開發工程編寫；測試腳本：對也業務較熟悉的測試開發）
缺點：變更引起的工作量還是附加在自動化測試開發工程師身上
典型示例：自動化測試模塊的高級使用，懂得業務分層處理。
?
第四類：?關鍵字驅動框架
?
概念：當對象庫添加完成后，測試case步驟的組織就相當于是在關鍵字試圖中選擇控件 ??Control），動作（Action），參數（Parameters）。
優點：極大的減少了自動化開發工程師維護量，畢竟在測試團隊中，自動化開發工程師占的比較少；普通測試工程師，可以很好的維護自身負責的模塊中涉及的測試case和測試數據（腳本可由有一定經驗的測試開發維護即可）
缺點：框架的抽象程度比較高，對自動化測試工程師的開發能力比較高
典型示例：QTP
?
常用測試工具
第一類：QTP。
?
?
用途：使用QTP的目的是想用它來執行重復的自動化測試，主要是用于回歸測試和測試同一軟件的新版本.采用關鍵字驅動的理念以簡化測試用例的創建和維護。它讓用戶可以直接錄制屏幕上的操作流程，自動生成功能測試或者回歸測試用例。
優點：更適合做UI測試，屬于基礎功能測試框架。屬于對測試人員編程能力要求不高。
缺點：關鍵字的框架，靈活度差。對flex等的支持差。一旦應用于企業自動化測試框架，必然需要購買正版，價格的問題比較貴。適合測試人員做自動化測試學習，一般很少能真正推廣應用到實際項目。
類似產品：?RFT（Rational?Functional Tester，IBM），ranorex，WinRunner，SilkTest
?
第二類：Ant+Selenium+Testng+Jenkins。
?
用途：是一套基于WEB應用的驗收測試工具，直接運行在瀏覽器中，模擬客戶操作。它抽象出一系列命令來模塊用戶操作，比如open命令表示打開一個URL,click命令表示點擊某個按鈕。Selenium實際上將這些命令轉化成實際的HTTP請求在瀏覽器中運行
優點：更適合做UI測試，屬于基礎功能測試框架。適合做java web 測試。一般公司的java web測試都會選擇考慮使用該框架，靈活性強，開源，學習資料很多。
缺點：對測試的開發能力有較高的要求，需要會J2EE開發。最好能做到控件識別和業務邏輯的分層，整個項目會存在大量的代碼重用現象，需要高度進行抽離。
類似產品：AdventNet?，TestPartner
?
第三類：SoapUI
?
用途：soapUI是一個開源測試工具，通過soap/http來檢查、調用、實現Web Service的功能/負載/符合性測試，能夠模仿Web Services，并創建/運行對他們的功能和負載測試，即使在系統部署前，這些也能夠開展。
優點：可以完成多種web Service的測試場景，也可以做壓力測試，能集成多種工具（ant），使用廣泛，且對測試人員的開發要求不高，常用于接口測試。
缺點：不支持外部新增新的協議機制，不支持JMS協議或私有協議。
類似產品：LoadRunner接口測試
?
第四類：Mcafe。
用途：百度內部使用的一套自動化測試框架。包含了虛擬機的集成分配，自動化測試執行，測試用例管理。
?
轉載于:https://www.cnblogs.com/loleina/p/5213600.html
總結
- 上一篇： OC第八节 内存管理高级
- 下一篇： [转]DICOM医学图像处理：Decon