第一篇：iPhone App自動化測試工具總結
iPhone App自動化測試工具總結
無線客戶端的發展很快，特別針對是android和ios兩款無線操作系統的客戶端應用，相應的測試工具也應運而生，這里主要給大家介紹一些針對iPhone App的自動化測試工具。
首先，我們把這些測試框架分為三大類：接口測試工具、注入式UI測試工具、錄放式UI測試工具。
一、接口測試工具，主要在iphone SDK提供的單元測試框架的基礎上，完成代碼的接口功能測試。
這類工具用的比較多的是SDK本身提供的test unit，以及google的google-toolbox-for-mac工具。google的GTM工具是在test unit上做了一層封裝，可以簡單、快速的完成測試腳本編寫，提供完善的測試日志和報告，并提供部分簡單的UI測試功能。
詳細的文檔可以參考這里：http://code.google.com/p/google-toolbox-for-mac/wiki/iPhoneUnitTesting
二、注入式UI測試工具，可以完成對被測應用的UI功能測試，需要在源代碼中加入一些必須的測試代碼。優點是可以模擬用戶的操作，測試被測應用 的相關功能，可以覆蓋比較全的應用功能。缺點是因為在源代碼中插入了必須的測試代碼，而這些應用發布時需要去除，引入了被測應用和發布應用不一致的風險。
UISpec,提供了用例運行前的準備和運行的恢復功能，UIQuery功能，以及較為完善的校驗功能，但該工具的使用比較復雜，腳本的編寫也很繁瑣，雖然對UI可以query，但無法方便、清晰、直觀的查看應用控件的屬性。
詳細的文檔可以參考這里：http://code.google.com/p/uispec/wiki/Documentation
Bromine,腳本編寫簡單，對控件的操作，完全模擬touch事件實現，但控件的定位通過對控件重畫，并插入定位需要的信息，xpath的描述串也稍顯復雜，校驗功能相對較弱。
詳細的文檔可以參考這里：http://code.google.com/p/bromine/
三、錄放式UI測試工具，主要通過錄制用戶的操作行為，通過回放來完成對被測應用的功能測試，這類工具對UI的功能測試相對是比較弱的。
比較常用的有Instrument、FoneMonke。
Instrument，是iOS提供的主要用于分析應用的性能和用戶行為的工具，利用它可以完成對被測應用的簡單的UI測試。
FoneMonke，是國外提供的一個開源的，免費的錄制/回放工具。網站：http://www.tmdps.cn/fonemonkey
以上是了解的一些針對iPhone App的自動化測試工具，大家感興趣的可以了解了解，歡迎交流、學習！
第二篇：Android自動化測試工具常用ADB命令總結
自動化測試常用ADB命令操作總結
自動化測試基本操作命令：
模擬點擊操作：adb shell input tap 500 500(點擊手機（500，500）坐標)模擬滑動屏幕操作：adb shell input swipe 200 500 400 500 模擬輸入文本信息：adb shell input text helloworld 模擬按鍵命令：
adb shell input keyeventKEYCODE_VOLNME_DOWN按音量下鍵 adb shell input keyeventKEYCODE_VOLNME_UP
按音量上鍵 adb shell input keyevent 自動化測試中日志分析截圖命令：
數據線連接手機截圖：adb shell /system/bin/screencap–p /sdcard/screenshot.png 將截圖復制到電腦盤中：adb pull /sdcard/screenshot.png E:download 輸出所有已經安裝應用： adb shell pm list package –f 查看預安APK adb shell pm list package-3 安裝應用程序：
adb install –r 應用程序.apk 文件傳輸：
獲取模擬器中的文件：adb pull
常用的發送鍵盤事件：
命令格式：adb shell input keyevent“value” 其中value以及對應的key code如下：
KeyEventValueKEYCODE 0 KEYCODE_UNKNOWN 1 KEYCODE_MENU 2 KEYCODE_SOFT_RIGHT 3 KEYCODE_HOME 4 KEYCODE_BACK 5 KEYCODE_CALL 6 KEYCODE_ENDCALL 7 KEYCODE_0 8 KEYCODE_1 9 KEYCODE_2 10 KEYCODE_3 11 KEYCODE_4 12 KEYCODE_5 13 KEYCODE_6 14 KEYCODE_7 15 KEYCODE_8 16 KEYCODE_9 17 KEYCODE_STAR 18 KEYCODE_POUND 19 KEYCODE_DPAD_UP 20 KEYCODE_DPAD_DOWN 21 KEYCODE_DPAD_LEFT 22 KEYCODE_DPAD_RIGHT 23 KEYCODE_DPAD_CENTER 24 KEYCODE_VOLUME_UP 25 KEYCODE_VOLUME_DOWN 26 KEYCODE_POWER 27 KEYCODE_CAMERA 28 KEYCODE_CLEAR 29 KEYCODE_A 30 KEYCODE_B 31 KEYCODE_C 32 KEYCODE_D 33 KEYCODE_E 34 KEYCODE_F 35 KEYCODE_G 36 KEYCODE_H 37 KEYCODE_I 38 KEYCODE_J 39 KEYCODE_K 40 KEYCODE_L 41 KEYCODE_M 42 KEYCODE_N 43 KEYCODE_O 44 KEYCODE_P 45 KEYCODE_Q 46 KEYCODE_R 47 KEYCODE_S 48 KEYCODE_T 49 KEYCODE_U 50 KEYCODE_V 51 KEYCODE_W 52 KEYCODE_X 53 KEYCODE_Y 54 KEYCODE_Z 55 KEYCODE_COMMA 56 KEYCODE_PERIOD 57 KEYCODE_ALT_LEFT 58 KEYCODE_ALT_RIGHT 59 KEYCODE_SHIFT_LEFT 60 KEYCODE_SHIFT_RIGHT 61 KEYCODE_TAB 62 KEYCODE_SPACE 63 KEYCODE_SYM 64 KEYCODE_EXPLORER 65 KEYCODE_ENVELOPE 66 KEYCODE_ENTER 67 KEYCODE_DEL 68 KEYCODE_GRAVE 69 KEYCODE_MINUS 70 KEYCODE_EQUALS 71 KEYCODE_LEFT_BRACKET 72 KEYCODE_RIGHT_BRACKET 73 KEYCODE_BACKSLASH 74 KEYCODE_SEMICOLON 75 KEYCODE_APOSTROPHE 76 KEYCODE_SLASH 77 KEYCODE_AT 78 KEYCODE_NUM 79 KEYCODE_HEADSETHOOK 80 KEYCODE_FOCUS 81 KEYCODE_PLUS 82 KEYCODE_MENU 83 KEYCODE_NOTIFICATION 84 KEYCODE_SEARCH 85 TAG_LAST_KEYCODE
第三篇：自動化測試經驗分享
一、測試的困惑
以前我時常反思，測試組的工作多嗎？我的回答是多。測試小組的工作成果的好壞和工作任務的多少成正比嗎？最終的回答卻并非成正比。我們的測試工作成果往往并不理想，甚至是差。那么為什么事倍功半？這問題很難找到清晰的答案。
參與了外部培訓之后，發現了自己在對測試的工作有了新層次的理解。對之前工作成果差的問題思考也有了新的方向。“測試的最高境界是找出所有BUG嗎？不是，測試的最高境界是不需要進行測試。為什么不需要進行測試？是因為所有的問題都已經在軟件各階段中介入的測試工作中給預防解決了。由此引申，測試的定位并不是找出BUG，而是預防BUG。” 這是我培訓報告中的一部分。如果測試的出發點只為是發現BUG，那么測試工作將會如何？辛苦的發現了一個BUG，之后開發針對性的修正了這個BUG，再回重新測試的過程，又會有多少人會重新被卷入，又會有多少BUG因此而產生，又需要花費多少時間，答案可想而知。這就是我們忙又不見成果的主要原因。所以改善這個問題的出發點就是改變對測試工作的認識——測試的目標并不是為了找出BUG，而是預防BUG的出現。
如何理解正確的測試目標是預防BUG的出現。首先可以從軟件測試的階段劃分來看。軟件測試的階段劃分為需求、設計、編碼、測試、驗收。但按此劃分來定位測試是錯誤的。假如在編碼階段完成后測試出的BUG屬于設計問題（這也是我們測試工作中經常遇到的情況），那么我們已經編碼完成的產品就要面臨著傷筋動骨的修改，這樣的修改會帶出多少個新的BUG出現？為這個修改我們又要重復的測試我們的新提交版本多少次？想必都有很深刻及慘痛的答案了。由此可以說明需求設計階段的測試比編碼階段測試重要的多。在需求上出現的BUG就很有可能足以推翻整個產品。那么如果在需求設計階段測試人員就能發現產品設計的BUG，那么就可以避免了因此而衍生的產品BUG，達到預防BUG這種測試理念的目標。
那么又如何能做好以預防BUG為目標的測試工作。“測試工作不只是一種技術，也不僅是一種活動。測試工作的成功也不能取決于測試成果，測試的BUG越多并不能證明測試工作做的好，所以由此引申，測試工作要站在團隊的高度來開展，在團隊中做好測試，而不是在測試小組中做好測試。”這是我培訓報告中的另一部分。要做好以預防BUG為目標的測試工作，首先要盡早的參與到項目中，其次就是需要各部門及小組的大力支持，與業務、項目、代碼人員共同形成團隊，在團隊中影響其他小組提高產品質量，更好的完成以預防產品出現BUG為目標的測試活動。
總結來看，我個人覺得擁有這樣的測試理念可以解開我們的疑惑，帶領我們走出目前的困境。
二、自動化測試迷失
隨著工作、發展、提高等等多方面的需要，我接到了開展自動化測試的研究工作。概念上來說自動化測試是一種測試度量體系。現實點來說，自動化測試可以為我們自動、無誤的運作完成大量且需要重復執行的測試用例。這是多么讓人振奮的概念。甚至可以解開我上文所提到的有關測試工作的困惑。我很興奮的去展開研究目前最流行的自動化測試工具之一QTP。甚至設計出了管理中心的三個重要功能的自動化測試腳本，并且運行無誤在自動化測試討論會上興奮的向大家演示。之后還用工具按鍵精靈設計出了前端的A類測試用于實際的測試。但很讓人沮喪的是最終這些腳本全被遺棄在電腦硬盤的角落，再也沒派上用場。為什么？因為他們維護起來很困難，因為他們編寫它們的時間與實現的價值并沒有超過手工測試。這就是自動化測試嗎？怎么不可行啊，我有點不太相信這種結局，所以我再一次困惑了。
外部培訓的老師這樣告訴我們：“我們并沒有理性的看待自動化測試，自動化測試并不是我們看上去的那樣美。首先自動化測試能直接的節約成本、讓測試人員變輕松的想法是一個誤區。因為原本用于手工測試的時間用來編寫及維護測試腳本了，而完善的自動化測試腳本編寫或維護的時間很可能會超過手工測試的時間。再者自動化測試腳本用例是測試人員所編寫，自動化測試只能是沿著該測試人員的“足跡”前進。所以用自動代測試來發現更多軟件產品問題的想法也是一個誤區。其次并不是所有的測試都能自動化，測試的自動化也不一定是解決問題的最佳手段。”
聽完這些，原本困惑的我又多了份驚訝，一方面驚嘆產述的這些狀況與我之前的自動化測試的試行失敗是相近的。另一方面又猜疑這自動化測試該不會像共產主義社會那般吧！隨著培訓內容的展開，我終于解開了困惑，何為理性的看待自動化測試。
“如同不能指望原始社會擁有了汽車就能進入現代社會一樣，自動化測試工具永遠都不能主導測試實現自動化”（出自國信培訓文檔）。我們錯誤的把自動化測試看成了一種測試工具或測試手段。自動化測試是一種理念，它要發揮它真正的作用就需要這種理念轉變為一種體系——自動化測試體系。
“引入自動化測試的前提是已經建立了合適的自動化測試體系，如果沒有這些，而片面的追求自動化，無異于緣木求魚。自動化測試體系是指能夠適用某種環境的測試工具、過程、人員結構、方法的綜合，運用于整個項目團隊”。回到我之前的對QTP研究失敗的原因，首先我開始就覺得因為研發的設計、編碼實現并沒有考慮到自動化，而導致自動化腳本的編寫非常吃力。比如產品頁面項目的命名不規范，導致自動化測試工具很難捕捉這些頁面對像。其次就是測試腳本的方向迷失，我在研究QTP的時候就發現了這個問題。隨著我一點點的在編寫著腳本，我不斷的發現自己在的測試腳本的編寫方向上出現了迷失。這段腳本我編寫的目標本來是功能測試，但隨著我的補充卻接近于開發級的單元測試。而另一段本屬于功能性測試的腳本，因為功能的重點需要，我又補充了部分腳本導致整個測試腳本測試目標變成了完整關聯性測試。而做為單元測試的腳本卻并沒有在開發的角度上來設計，根本做不到函數、類等代碼級的測試，根本不能達到要求。做為完整性測試的腳本也無法模擬接口功能中幾何倍數級的各種條件輸入對應的輸出測試。而功能測試腳本算是碩果僅存，但隨著開發對產品的代碼大規模調整（這些調整當然不會考慮對已經實現的腳本的影響）而直接“報廢”。如果需要腳本繼續工作，那么就要花時間來修改調整它。這些腳本的結局又再一次可想而知了。
所以首先我們要理性的看待自動化測試，不要片面的去追求它。對不同的項目要開展不同自動化策略。參考如下
（1）評審項目中特定的部分作為應用自動化的候選對像。
（2）從項目中高度冗余的任務或場景重點考慮自動化。
（3）將乏味且人工容易出錯的工作重點考慮自動化。
（4）將回歸測試經常需要“照顧”到的部分重點考慮自動化。
（5）自動化開始時要首先關注開發成熟、理解透徹、相對穩定的且不易變的部分優先考慮自動化
其次，自動化所實現的最大價值目標是可不間斷的、可重復的自動執行對需求、設計、代碼全面覆蓋的大量測試用例從而預防bug的產生的一套質量保障機制。所以自動化測試的重點在于測試自動化作為一個體系，要運用于整個項目團隊。項目組要討論它（策略、時間、成本等）、研發需要參與它（編碼方向、自動化支撐、以及代碼單元測試自動化的計劃和執行等）、測試要引導及推進它（策略、方法、執行、跟進、維護等），各團隊共同形成體系，才能讓自動化測試工具真正的成為一種質量保證的有力武器。
第四篇：Web測試工具小結
Web測試工具小結
單元測試方面：（對開發人員比較有用）J-Unit工具。
功能測試方面：E-test是個不錯的選擇，功能很強大，由于不是采用Post URL的方式回放腳本，所以可以支持多內碼的測試數據（當然要程序支持）。基本上可以應付大部分的Web Site。
如果只是利用腳本回放代替手工勞動，或者做對頁面響應數的性能測試，Microsoft Web Application Stress Tool是個不錯的選擇。
另外，在性能測試方面，PureLoad也是一個不錯的工具，完全用Java寫成，可以測試各種C/S程序，如SMTP Server等。這兩個工具都是使用Post URL的方法測試Web Application的。對大量使用JavaScript的頁面不太適合。當然，如果程序在Unix，linux下面運行的話，可以直接編寫Shell腳本程序，更加方便。
另外，還有很多專門的工具，比如說Linkbot是專門作頁面鏈接測試的。
另外，測試流程管理工具也有不少，個人用過也一直在用的是Test Plan Control，短小精悍，不錯。
至于WinRunner和LoadRunner之類，因為沒有License，所以都沒怎么用過，慚愧。不過我看過一篇英國人評價英國測試市場上最流行的五個軟件的文章。WinRunner得分最高。
測試工具從測試的方法上可以分為兩種：白盒測試和黑盒測試
白盒測試工具主要有：
內存資源泄漏檢查：Numega中的bouncechecker,Rational的Purify等
代碼覆蓋率檢查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等
代碼性能檢查：Numega中的truetime,Rational的Quantify等
代碼靜態度量分析質量檢查工具：logiscope和Macabe等
黑盒測試工具主要有：
客戶端功能測試：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等
服務器端壓力性能測試： MI公司的winload,compuware的qaload,Rational的SQA load等等
Web測試工具：MI公司的Astra系列，rsw公司的e-test suite等等
測試管理工具：rational的test manager,compuware的qadirector等等，此外還有缺陷跟蹤工具 trackrecord等。
數據庫測試工具:TestBytes
黑盒測試工具：QACenter、SQATeamTest，Rational Viaual Test。
回歸測試工具：Rational TeamTest，WinRunner（MI公司）
WEB系統測試工具：TEST，Workberch，Web Appication Stress Tool（WAS）
白盒測試工具：Numega、PuRe、軟件糾錯工具（Rational Purity）。
嵌入式測試工具：Logiscope（靜態測試工具）、CodeTest。
系統負荷測試工具：RationalPerformance
涵蓋測試工具范圍評估工具
軟件性能測試工具：LoadRunner（MI產品）、Rational Visual Qantify
測試管理工具：TestDirector（MI產品支持整個生命周期中測試流程管理）
第五篇：軟件(自動化)測試工作總結
2012年工作總結
2012年自動化測試工作嚴格按照要求，保質保量完成客戶指派的任務。截止目前，已完成話費收取、賬單查詢、產品變更、營銷活動等137項關鍵業務測試用例、105個自動化回歸測試場景設計，范圍涵蓋個人業務、家庭業務、集團業務、賬務管理、營銷活動及各類常用查詢功能。陜西公司在大型版本上線時均進行關鍵業務自動化回歸測試，降低了新版本上線風險，保證了新版本上線后關鍵業務和常用業務正常受理。累計已進行新需求上線前后回歸測試68次，運行業務腳本13100余次，發現系統原有缺陷38個，新需求缺陷69個，進行業務規則梳理146個，為新需求影響范圍分析提供了數據依據，較大程度的提高了上線成功率，降低了上線后系統的缺陷率，提高了系統的穩定性。
從2012年5月份入職到現在的多半年時間內，主要對系統，業務的深入理解，學習。對工作中所運用到得工具熟練掌握，每次上線都能按照要求，獨立完成分配的任務。對自動化腳本進行重新整理改進，發現問題及時聯系局方人員進行協商，處理。
主要工作內容是負責自動化測試這塊，自動化測試的目的在于保障在新業務上線后，能正確的把控新上線內容對整個生產環境的影響。確保在新業務上線過程中，及早發現關鍵業務的情況，判斷其是否受到影響，同時確定新上線業務是否滿足要求，達到預期的功能目的。每次上線加班，嚴格按照要求進行測試，仔細記錄測試中發現的BUG，當天尋找開發或相關負責人進行解決，每次按時到達工作現場，認真對待工作，至今沒有由于個人原因出現嚴重過錯。其他時間，對測試環境，測試數據和腳本進行維護，管理。領導每次分配的任務認真對待，按時保質完成。
工作中存在還需要以后改進的幾點：
1、對業務的熟悉度更進一步了解，拓展。
2、對腳本進行改進，創新，能夠更全面的覆蓋測試面，爭取最大限度的找出問題所在。
3、在測試工具，軟件，腳本等方面進行創新，提高測試正確度，測試效率，真正達到自動化測試的目的。
以后主要對自動化更深一步的了解，學習，還有對移動業務龐大的系統進行深入了解，經過這樣緊張有序的一年，我感覺自己工作技能上了一個新臺階，做每一項工作都有了明確的計劃和步驟，行動有了方向，工作有了目標，心中真正有了底！基本做到了忙而不亂，條理清楚，從根本上擺脫了剛參加工作時只顧埋頭苦干，不知總結經驗的現象。針對個人和工作上存在的不足，我會不斷的去改善，好的習慣繼續保持，同時也會不斷更新自己的知識庫。
點擊咨詢 