第一篇：iPhone App自動(dòng)化測試工具總結(jié)
iPhone App自動(dòng)化測試工具總結(jié)
無線客戶端的發(fā)展很快，特別針對(duì)是android和ios兩款無線操作系統(tǒng)的客戶端應(yīng)用，相應(yīng)的測試工具也應(yīng)運(yùn)而生，這里主要給大家介紹一些針對(duì)iPhone App的自動(dòng)化測試工具。
首先，我們把這些測試框架分為三大類：接口測試工具、注入式UI測試工具、錄放式UI測試工具。
一、接口測試工具，主要在iphone SDK提供的單元測試框架的基礎(chǔ)上，完成代碼的接口功能測試。
這類工具用的比較多的是SDK本身提供的test unit，以及google的google-toolbox-for-mac工具。google的GTM工具是在test unit上做了一層封裝，可以簡單、快速的完成測試腳本編寫，提供完善的測試日志和報(bào)告，并提供部分簡單的UI測試功能。
詳細(xì)的文檔可以參考這里：http://code.google.com/p/google-toolbox-for-mac/wiki/iPhoneUnitTesting
二、注入式UI測試工具，可以完成對(duì)被測應(yīng)用的UI功能測試，需要在源代碼中加入一些必須的測試代碼。優(yōu)點(diǎn)是可以模擬用戶的操作，測試被測應(yīng)用 的相關(guān)功能，可以覆蓋比較全的應(yīng)用功能。缺點(diǎn)是因?yàn)樵谠创a中插入了必須的測試代碼，而這些應(yīng)用發(fā)布時(shí)需要去除，引入了被測應(yīng)用和發(fā)布應(yīng)用不一致的風(fēng)險(xiǎn)。
UISpec,提供了用例運(yùn)行前的準(zhǔn)備和運(yùn)行的恢復(fù)功能，UIQuery功能，以及較為完善的校驗(yàn)功能，但該工具的使用比較復(fù)雜，腳本的編寫也很繁瑣，雖然對(duì)UI可以query，但無法方便、清晰、直觀的查看應(yīng)用控件的屬性。
詳細(xì)的文檔可以參考這里：http://code.google.com/p/uispec/wiki/Documentation
Bromine,腳本編寫簡單，對(duì)控件的操作，完全模擬touch事件實(shí)現(xiàn)，但控件的定位通過對(duì)控件重畫，并插入定位需要的信息，xpath的描述串也稍顯復(fù)雜，校驗(yàn)功能相對(duì)較弱。
詳細(xì)的文檔可以參考這里：http://code.google.com/p/bromine/
三、錄放式UI測試工具，主要通過錄制用戶的操作行為，通過回放來完成對(duì)被測應(yīng)用的功能測試，這類工具對(duì)UI的功能測試相對(duì)是比較弱的。
比較常用的有Instrument、FoneMonke。
Instrument，是iOS提供的主要用于分析應(yīng)用的性能和用戶行為的工具，利用它可以完成對(duì)被測應(yīng)用的簡單的UI測試。
FoneMonke，是國外提供的一個(gè)開源的，免費(fèi)的錄制/回放工具。網(wǎng)站：http://004km.cn/fonemonkey
以上是了解的一些針對(duì)iPhone App的自動(dòng)化測試工具，大家感興趣的可以了解了解，歡迎交流、學(xué)習(xí)！
第二篇：Android自動(dòng)化測試工具常用ADB命令總結(jié)
自動(dòng)化測試常用ADB命令操作總結(jié)
自動(dòng)化測試基本操作命令：
模擬點(diǎn)擊操作：adb shell input tap 500 500(點(diǎn)擊手機(jī)（500，500）坐標(biāo))模擬滑動(dòng)屏幕操作：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 自動(dòng)化測試中日志分析截圖命令：
數(shù)據(jù)線連接手機(jī)截圖：adb shell /system/bin/screencap–p /sdcard/screenshot.png 將截圖復(fù)制到電腦盤中：adb pull /sdcard/screenshot.png E:download 輸出所有已經(jīng)安裝應(yīng)用： adb shell pm list package –f 查看預(yù)安APK adb shell pm list package-3 安裝應(yīng)用程序：
adb install –r 應(yīng)用程序.apk 文件傳輸：
獲取模擬器中的文件：adb pull
常用的發(fā)送鍵盤事件：
命令格式：adb shell input keyevent“value” 其中value以及對(duì)應(yīng)的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
第三篇：自動(dòng)化測試經(jīng)驗(yàn)分享
一、測試的困惑
以前我時(shí)常反思，測試組的工作多嗎？我的回答是多。測試小組的工作成果的好壞和工作任務(wù)的多少成正比嗎？最終的回答卻并非成正比。我們的測試工作成果往往并不理想，甚至是差。那么為什么事倍功半？這問題很難找到清晰的答案。
參與了外部培訓(xùn)之后，發(fā)現(xiàn)了自己在對(duì)測試的工作有了新層次的理解。對(duì)之前工作成果差的問題思考也有了新的方向。“測試的最高境界是找出所有BUG嗎？不是，測試的最高境界是不需要進(jìn)行測試。為什么不需要進(jìn)行測試？是因?yàn)樗械膯栴}都已經(jīng)在軟件各階段中介入的測試工作中給預(yù)防解決了。由此引申，測試的定位并不是找出BUG，而是預(yù)防BUG?！?這是我培訓(xùn)報(bào)告中的一部分。如果測試的出發(fā)點(diǎn)只為是發(fā)現(xiàn)BUG，那么測試工作將會(huì)如何？辛苦的發(fā)現(xiàn)了一個(gè)BUG，之后開發(fā)針對(duì)性的修正了這個(gè)BUG，再回重新測試的過程，又會(huì)有多少人會(huì)重新被卷入，又會(huì)有多少BUG因此而產(chǎn)生，又需要花費(fèi)多少時(shí)間，答案可想而知。這就是我們忙又不見成果的主要原因。所以改善這個(gè)問題的出發(fā)點(diǎn)就是改變對(duì)測試工作的認(rèn)識(shí)——測試的目標(biāo)并不是為了找出BUG，而是預(yù)防BUG的出現(xiàn)。
如何理解正確的測試目標(biāo)是預(yù)防BUG的出現(xiàn)。首先可以從軟件測試的階段劃分來看。軟件測試的階段劃分為需求、設(shè)計(jì)、編碼、測試、驗(yàn)收。但按此劃分來定位測試是錯(cuò)誤的。假如在編碼階段完成后測試出的BUG屬于設(shè)計(jì)問題（這也是我們測試工作中經(jīng)常遇到的情況），那么我們已經(jīng)編碼完成的產(chǎn)品就要面臨著傷筋動(dòng)骨的修改，這樣的修改會(huì)帶出多少個(gè)新的BUG出現(xiàn)？為這個(gè)修改我們又要重復(fù)的測試我們的新提交版本多少次？想必都有很深刻及慘痛的答案了。由此可以說明需求設(shè)計(jì)階段的測試比編碼階段測試重要的多。在需求上出現(xiàn)的BUG就很有可能足以推翻整個(gè)產(chǎn)品。那么如果在需求設(shè)計(jì)階段測試人員就能發(fā)現(xiàn)產(chǎn)品設(shè)計(jì)的BUG，那么就可以避免了因此而衍生的產(chǎn)品BUG，達(dá)到預(yù)防BUG這種測試?yán)砟畹哪繕?biāo)。
那么又如何能做好以預(yù)防BUG為目標(biāo)的測試工作?！皽y試工作不只是一種技術(shù)，也不僅是一種活動(dòng)。測試工作的成功也不能取決于測試成果，測試的BUG越多并不能證明測試工作做的好，所以由此引申，測試工作要站在團(tuán)隊(duì)的高度來開展，在團(tuán)隊(duì)中做好測試，而不是在測試小組中做好測試?！边@是我培訓(xùn)報(bào)告中的另一部分。要做好以預(yù)防BUG為目標(biāo)的測試工作，首先要盡早的參與到項(xiàng)目中，其次就是需要各部門及小組的大力支持，與業(yè)務(wù)、項(xiàng)目、代碼人員共同形成團(tuán)隊(duì)，在團(tuán)隊(duì)中影響其他小組提高產(chǎn)品質(zhì)量，更好的完成以預(yù)防產(chǎn)品出現(xiàn)BUG為目標(biāo)的測試活動(dòng)。
總結(jié)來看，我個(gè)人覺得擁有這樣的測試?yán)砟羁梢越忾_我們的疑惑，帶領(lǐng)我們走出目前的困境。
二、自動(dòng)化測試迷失
隨著工作、發(fā)展、提高等等多方面的需要，我接到了開展自動(dòng)化測試的研究工作。概念上來說自動(dòng)化測試是一種測試度量體系。現(xiàn)實(shí)點(diǎn)來說，自動(dòng)化測試可以為我們自動(dòng)、無誤的運(yùn)作完成大量且需要重復(fù)執(zhí)行的測試用例。這是多么讓人振奮的概念。甚至可以解開我上文所提到的有關(guān)測試工作的困惑。我很興奮的去展開研究目前最流行的自動(dòng)化測試工具之一QTP。甚至設(shè)計(jì)出了管理中心的三個(gè)重要功能的自動(dòng)化測試腳本，并且運(yùn)行無誤在自動(dòng)化測試討論會(huì)上興奮的向大家演示。之后還用工具按鍵精靈設(shè)計(jì)出了前端的A類測試用于實(shí)際的測試。但很讓人沮喪的是最終這些腳本全被遺棄在電腦硬盤的角落，再也沒派上用場。為什么？因?yàn)樗麄兙S護(hù)起來很困難，因?yàn)樗麄兙帉懰鼈兊臅r(shí)間與實(shí)現(xiàn)的價(jià)值并沒有超過手工測試。這就是自動(dòng)化測試嗎？怎么不可行啊，我有點(diǎn)不太相信這種結(jié)局，所以我再一次困惑了。
外部培訓(xùn)的老師這樣告訴我們：“我們并沒有理性的看待自動(dòng)化測試，自動(dòng)化測試并不是我們看上去的那樣美。首先自動(dòng)化測試能直接的節(jié)約成本、讓測試人員變輕松的想法是一個(gè)誤區(qū)。因?yàn)樵居糜谑止y試的時(shí)間用來編寫及維護(hù)測試腳本了，而完善的自動(dòng)化測試腳本編寫或維護(hù)的時(shí)間很可能會(huì)超過手工測試的時(shí)間。再者自動(dòng)化測試腳本用例是測試人員所編寫，自動(dòng)化測試只能是沿著該測試人員的“足跡”前進(jìn)。所以用自動(dòng)代測試來發(fā)現(xiàn)更多軟件產(chǎn)品問題的想法也是一個(gè)誤區(qū)。其次并不是所有的測試都能自動(dòng)化，測試的自動(dòng)化也不一定是解決問題的最佳手段?！?/p>
聽完這些，原本困惑的我又多了份驚訝，一方面驚嘆產(chǎn)述的這些狀況與我之前的自動(dòng)化測試的試行失敗是相近的。另一方面又猜疑這自動(dòng)化測試該不會(huì)像共產(chǎn)主義社會(huì)那般吧！隨著培訓(xùn)內(nèi)容的展開，我終于解開了困惑，何為理性的看待自動(dòng)化測試。
“如同不能指望原始社會(huì)擁有了汽車就能進(jìn)入現(xiàn)代社會(huì)一樣，自動(dòng)化測試工具永遠(yuǎn)都不能主導(dǎo)測試實(shí)現(xiàn)自動(dòng)化”（出自國信培訓(xùn)文檔）。我們錯(cuò)誤的把自動(dòng)化測試看成了一種測試工具或測試手段。自動(dòng)化測試是一種理念，它要發(fā)揮它真正的作用就需要這種理念轉(zhuǎn)變?yōu)橐环N體系——自動(dòng)化測試體系。
“引入自動(dòng)化測試的前提是已經(jīng)建立了合適的自動(dòng)化測試體系，如果沒有這些，而片面的追求自動(dòng)化，無異于緣木求魚。自動(dòng)化測試體系是指能夠適用某種環(huán)境的測試工具、過程、人員結(jié)構(gòu)、方法的綜合，運(yùn)用于整個(gè)項(xiàng)目團(tuán)隊(duì)”?；氐轿抑暗膶?duì)QTP研究失敗的原因，首先我開始就覺得因?yàn)檠邪l(fā)的設(shè)計(jì)、編碼實(shí)現(xiàn)并沒有考慮到自動(dòng)化，而導(dǎo)致自動(dòng)化腳本的編寫非常吃力。比如產(chǎn)品頁面項(xiàng)目的命名不規(guī)范，導(dǎo)致自動(dòng)化測試工具很難捕捉這些頁面對(duì)像。其次就是測試腳本的方向迷失，我在研究QTP的時(shí)候就發(fā)現(xiàn)了這個(gè)問題。隨著我一點(diǎn)點(diǎn)的在編寫著腳本，我不斷的發(fā)現(xiàn)自己在的測試腳本的編寫方向上出現(xiàn)了迷失。這段腳本我編寫的目標(biāo)本來是功能測試，但隨著我的補(bǔ)充卻接近于開發(fā)級(jí)的單元測試。而另一段本屬于功能性測試的腳本，因?yàn)楣δ艿闹攸c(diǎn)需要，我又補(bǔ)充了部分腳本導(dǎo)致整個(gè)測試腳本測試目標(biāo)變成了完整關(guān)聯(lián)性測試。而做為單元測試的腳本卻并沒有在開發(fā)的角度上來設(shè)計(jì)，根本做不到函數(shù)、類等代碼級(jí)的測試，根本不能達(dá)到要求。做為完整性測試的腳本也無法模擬接口功能中幾何倍數(shù)級(jí)的各種條件輸入對(duì)應(yīng)的輸出測試。而功能測試腳本算是碩果僅存，但隨著開發(fā)對(duì)產(chǎn)品的代碼大規(guī)模調(diào)整（這些調(diào)整當(dāng)然不會(huì)考慮對(duì)已經(jīng)實(shí)現(xiàn)的腳本的影響）而直接“報(bào)廢”。如果需要腳本繼續(xù)工作，那么就要花時(shí)間來修改調(diào)整它。這些腳本的結(jié)局又再一次可想而知了。
所以首先我們要理性的看待自動(dòng)化測試，不要片面的去追求它。對(duì)不同的項(xiàng)目要開展不同自動(dòng)化策略。參考如下
（1）評(píng)審項(xiàng)目中特定的部分作為應(yīng)用自動(dòng)化的候選對(duì)像。
（2）從項(xiàng)目中高度冗余的任務(wù)或場景重點(diǎn)考慮自動(dòng)化。
（3）將乏味且人工容易出錯(cuò)的工作重點(diǎn)考慮自動(dòng)化。
（4）將回歸測試經(jīng)常需要“照顧”到的部分重點(diǎn)考慮自動(dòng)化。
（5）自動(dòng)化開始時(shí)要首先關(guān)注開發(fā)成熟、理解透徹、相對(duì)穩(wěn)定的且不易變的部分優(yōu)先考慮自動(dòng)化
其次，自動(dòng)化所實(shí)現(xiàn)的最大價(jià)值目標(biāo)是可不間斷的、可重復(fù)的自動(dòng)執(zhí)行對(duì)需求、設(shè)計(jì)、代碼全面覆蓋的大量測試用例從而預(yù)防bug的產(chǎn)生的一套質(zhì)量保障機(jī)制。所以自動(dòng)化測試的重點(diǎn)在于測試自動(dòng)化作為一個(gè)體系，要運(yùn)用于整個(gè)項(xiàng)目團(tuán)隊(duì)。項(xiàng)目組要討論它（策略、時(shí)間、成本等）、研發(fā)需要參與它（編碼方向、自動(dòng)化支撐、以及代碼單元測試自動(dòng)化的計(jì)劃和執(zhí)行等）、測試要引導(dǎo)及推進(jìn)它（策略、方法、執(zhí)行、跟進(jìn)、維護(hù)等），各團(tuán)隊(duì)共同形成體系，才能讓自動(dòng)化測試工具真正的成為一種質(zhì)量保證的有力武器。
第四篇：Web測試工具小結(jié)
Web測試工具小結(jié)
單元測試方面：（對(duì)開發(fā)人員比較有用）J-Unit工具。
功能測試方面：E-test是個(gè)不錯(cuò)的選擇，功能很強(qiáng)大，由于不是采用Post URL的方式回放腳本，所以可以支持多內(nèi)碼的測試數(shù)據(jù)（當(dāng)然要程序支持）?；旧峡梢詰?yīng)付大部分的Web Site。
如果只是利用腳本回放代替手工勞動(dòng)，或者做對(duì)頁面響應(yīng)數(shù)的性能測試，Microsoft Web Application Stress Tool是個(gè)不錯(cuò)的選擇。
另外，在性能測試方面，PureLoad也是一個(gè)不錯(cuò)的工具，完全用Java寫成，可以測試各種C/S程序，如SMTP Server等。這兩個(gè)工具都是使用Post URL的方法測試Web Application的。對(duì)大量使用JavaScript的頁面不太適合。當(dāng)然，如果程序在Unix，linux下面運(yùn)行的話，可以直接編寫Shell腳本程序，更加方便。
另外，還有很多專門的工具，比如說Linkbot是專門作頁面鏈接測試的。
另外，測試流程管理工具也有不少，個(gè)人用過也一直在用的是Test Plan Control，短小精悍，不錯(cuò)。
至于WinRunner和LoadRunner之類，因?yàn)闆]有License，所以都沒怎么用過，慚愧。不過我看過一篇英國人評(píng)價(jià)英國測試市場上最流行的五個(gè)軟件的文章。WinRunner得分最高。
測試工具從測試的方法上可以分為兩種：白盒測試和黑盒測試
白盒測試工具主要有：
內(nèi)存資源泄漏檢查：Numega中的bouncechecker,Rational的Purify等
代碼覆蓋率檢查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等
代碼性能檢查：Numega中的truetime,Rational的Quantify等
代碼靜態(tài)度量分析質(zhì)量檢查工具：logiscope和Macabe等
黑盒測試工具主要有：
客戶端功能測試：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等
服務(wù)器端壓力性能測試： MI公司的winload,compuware的qaload,Rational的SQA load等等
Web測試工具：MI公司的Astra系列，rsw公司的e-test suite等等
測試管理工具：rational的test manager,compuware的qadirector等等，此外還有缺陷跟蹤工具 trackrecord等。
數(shù)據(jù)庫測試工具:TestBytes
黑盒測試工具：QACenter、SQATeamTest，Rational Viaual Test。
回歸測試工具：Rational TeamTest，WinRunner（MI公司）
WEB系統(tǒng)測試工具：TEST，Workberch，Web Appication Stress Tool（WAS）
白盒測試工具：Numega、PuRe、軟件糾錯(cuò)工具（Rational Purity）。
嵌入式測試工具：Logiscope（靜態(tài)測試工具）、CodeTest。
系統(tǒng)負(fù)荷測試工具：RationalPerformance
涵蓋測試工具范圍評(píng)估工具
軟件性能測試工具：LoadRunner（MI產(chǎn)品）、Rational Visual Qantify
測試管理工具：TestDirector（MI產(chǎn)品支持整個(gè)生命周期中測試流程管理）
第五篇：軟件(自動(dòng)化)測試工作總結(jié)
2012年工作總結(jié)
2012年自動(dòng)化測試工作嚴(yán)格按照要求，保質(zhì)保量完成客戶指派的任務(wù)。截止目前，已完成話費(fèi)收取、賬單查詢、產(chǎn)品變更、營銷活動(dòng)等137項(xiàng)關(guān)鍵業(yè)務(wù)測試用例、105個(gè)自動(dòng)化回歸測試場景設(shè)計(jì)，范圍涵蓋個(gè)人業(yè)務(wù)、家庭業(yè)務(wù)、集團(tuán)業(yè)務(wù)、賬務(wù)管理、營銷活動(dòng)及各類常用查詢功能。陜西公司在大型版本上線時(shí)均進(jìn)行關(guān)鍵業(yè)務(wù)自動(dòng)化回歸測試，降低了新版本上線風(fēng)險(xiǎn)，保證了新版本上線后關(guān)鍵業(yè)務(wù)和常用業(yè)務(wù)正常受理。累計(jì)已進(jìn)行新需求上線前后回歸測試68次，運(yùn)行業(yè)務(wù)腳本13100余次，發(fā)現(xiàn)系統(tǒng)原有缺陷38個(gè)，新需求缺陷69個(gè)，進(jìn)行業(yè)務(wù)規(guī)則梳理146個(gè)，為新需求影響范圍分析提供了數(shù)據(jù)依據(jù)，較大程度的提高了上線成功率，降低了上線后系統(tǒng)的缺陷率，提高了系統(tǒng)的穩(wěn)定性。
從2012年5月份入職到現(xiàn)在的多半年時(shí)間內(nèi)，主要對(duì)系統(tǒng)，業(yè)務(wù)的深入理解，學(xué)習(xí)。對(duì)工作中所運(yùn)用到得工具熟練掌握，每次上線都能按照要求，獨(dú)立完成分配的任務(wù)。對(duì)自動(dòng)化腳本進(jìn)行重新整理改進(jìn)，發(fā)現(xiàn)問題及時(shí)聯(lián)系局方人員進(jìn)行協(xié)商，處理。
主要工作內(nèi)容是負(fù)責(zé)自動(dòng)化測試這塊，自動(dòng)化測試的目的在于保障在新業(yè)務(wù)上線后，能正確的把控新上線內(nèi)容對(duì)整個(gè)生產(chǎn)環(huán)境的影響。確保在新業(yè)務(wù)上線過程中，及早發(fā)現(xiàn)關(guān)鍵業(yè)務(wù)的情況，判斷其是否受到影響，同時(shí)確定新上線業(yè)務(wù)是否滿足要求，達(dá)到預(yù)期的功能目的。每次上線加班，嚴(yán)格按照要求進(jìn)行測試，仔細(xì)記錄測試中發(fā)現(xiàn)的BUG，當(dāng)天尋找開發(fā)或相關(guān)負(fù)責(zé)人進(jìn)行解決，每次按時(shí)到達(dá)工作現(xiàn)場，認(rèn)真對(duì)待工作，至今沒有由于個(gè)人原因出現(xiàn)嚴(yán)重過錯(cuò)。其他時(shí)間，對(duì)測試環(huán)境，測試數(shù)據(jù)和腳本進(jìn)行維護(hù)，管理。領(lǐng)導(dǎo)每次分配的任務(wù)認(rèn)真對(duì)待，按時(shí)保質(zhì)完成。
工作中存在還需要以后改進(jìn)的幾點(diǎn)：
1、對(duì)業(yè)務(wù)的熟悉度更進(jìn)一步了解，拓展。
2、對(duì)腳本進(jìn)行改進(jìn)，創(chuàng)新，能夠更全面的覆蓋測試面，爭取最大限度的找出問題所在。
3、在測試工具，軟件，腳本等方面進(jìn)行創(chuàng)新，提高測試正確度，測試效率，真正達(dá)到自動(dòng)化測試的目的。
以后主要對(duì)自動(dòng)化更深一步的了解，學(xué)習(xí)，還有對(duì)移動(dòng)業(yè)務(wù)龐大的系統(tǒng)進(jìn)行深入了解，經(jīng)過這樣緊張有序的一年，我感覺自己工作技能上了一個(gè)新臺(tái)階，做每一項(xiàng)工作都有了明確的計(jì)劃和步驟，行動(dòng)有了方向，工作有了目標(biāo)，心中真正有了底！基本做到了忙而不亂，條理清楚，從根本上擺脫了剛參加工作時(shí)只顧埋頭苦干，不知總結(jié)經(jīng)驗(yàn)的現(xiàn)象。針對(duì)個(gè)人和工作上存在的不足，我會(huì)不斷的去改善，好的習(xí)慣繼續(xù)保持，同時(shí)也會(huì)不斷更新自己的知識(shí)庫。
點(diǎn)擊咨詢 