自動化測試的發展趨勢.doc_第1頁
自動化測試的發展趨勢.doc_第2頁
自動化測試的發展趨勢.doc_第3頁
自動化測試的發展趨勢.doc_第4頁
自動化測試的發展趨勢.doc_第5頁
免費預覽已結束,剩余1頁可下載查看

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

自動化測試的發展趨勢 提及自動化測試,如果單純這么說,那么范圍非常廣泛。單元測試的自動化,功能測試自動化,性能測試自動化都屬于自動化測試的范疇。而我們常說的自動化測試往往指的是UI功能自動化測試。 其實,在自動化測試領域,較為成熟的應用集中在單元功能自動化測試和性能自動化測試。在單元自動化測試階段,現在產生了很多成熟的理論和方法,指導著工作的開展與展開。 在我個人的編碼過程中,也嘗試過測試驅動開發,在功能編寫之前先進行測試代碼的編寫,當然,我使用的語言往往是Python,用的是Python的白盒自動化測試框架:unittest。然后,這種模式是和語言無關的,包括各種*unit。 在后續的代碼開發和重構中,之前構建的白盒測試用例也都有效的節約了測試的勞動力,大大提高了測試的覆蓋度。 性能自動化測試工具的應用比較多。像我的工作中往往關注進程本身的CUP,內存,發展到后續的I/O,子進程數量,線程數等等。這些也都有成熟的工具可以應用。對于典型的協議層面的性能自動化測試,LR是比較成熟的工具。 曾經和一個自認為測試技術不錯的人探討過,他尊稱LR為性能測試之王,對此我深表遺憾。還有很多非常好的性能自動化測試工具。我們的產品特性讓我有機會接觸到業界的思博倫,BPS等等廠商的性能測試設備,進行二三層的測試工作。 在這些測試工具中,開放了良好的二次開發接口,可以進行自動化測試工具。 當然,包括LR,包括思博倫或者BPS等廠商的測試設備,價值不菲。還有一種比較極端的請款就是自我開發。自我開發的工作難度比較過,因為要模擬并發很難,不過在一些要求并非十分嚴格的情況下,也是一種實現方式。 說了這么多,只是想說明,當我們在探討自動化測試這個話題時,要明確其范圍,這個領域非常的廣,如果范圍不清,探討就不再有其意義。4. 關于自動化測試發展的思考: 上面談及了自動化測試的諸多領域。而我也一直在思考如果在我們實際的工作中應用自動化測試輔助我們的功能進行。 當前的UI功能自動化層面從業人員比較多,多也有回歸測試階段節約資源的觀點。但我想,現在我們是否可以打破自己的視野,將自動化測試提前到前端去,而不是簡單的后端被動應用。 首先說說UI的功能測試自動化。現在的技術發展據說有:應用為王的口號,在產品開發技術的逐漸成熟下,技術壁壘越來越低,而客戶的感知往往決定著產品的成敗。所以對于UI方面的測試重視逐步提高。 由此衍生了諸多的UI自動化測試方法的工具,QTP,Selenium,TC等等,太多了。 然后,拋開這些工具,讓我們來思考UI功能自動化測試本身,它自身的投入產出比,我們當前是否做的足夠好? 先說聽到的兩個案例吧: 1. 看到微軟的測試人員寫的一篇論文,在瀏覽器兼容性測試之前,通過編碼實現HTTP協議的GET,POST等函數,進行與后端web服務器的功能交互,驗證功能的有效性。 從這個測試模式可以看出,至少在此測試階段,弱化了UI的測試,而主要進行接口層面的功能驗證。這也體現了模塊化,解耦合的思想。后續當然也會進行UI的測試工作,但也許后續的會種感受,輕功能,當然是有相應的策略了,在此不作揣測。 2. Baidu的技術交流會,陳景衛(如果名字打錯請見諒)先生介紹百度當前的自動化測試分工,有7-2-1的劃分,貌似的意義在于七成在后臺,二成在功能,一成談UI,也不約而同的對UI的功能自動化進行了一定程度的弱化。 其實在我們綠盟,雖然我們的自動化測試投入人力有限,也一直在進行領域的探索。跟隨他們的腳步吧或者說也有同樣的認知,我們在推廣UI功能自動化的同時就進行了后臺功能測試重點推廣。爭取將自動化測試逐步推向前,而不是只在簡單的最終段。 所以,我在此想強調的是,隨著自動化測試從業人員的技術積累,所謂的在回歸測試應用自動化測試等等的觀念可以做寫改進了,我們理論上已經有能力將自動化測試應用到產品開發流程的前端。5. 我們該如何做: 既然有這樣的想法,具體如何實現才是關鍵。 回歸到底一段描述的內容,我的面試題,我們是否可以直觀的看出,這樣的測試題和所謂研發的測試題目是否還有本質的質的區別?包括我們公司現在的招聘工作,研發測試都是同樣的筆試題,也在深刻的體現一個問題: 研發測試工作界線的弱化。 首先,現在的要求是研發、測試都要有強烈的質量意識。這點其實很多研發職位的人員是有非常強烈的質量意識的。他們對于產品質量的要求甚至要比所謂的測試工作者更強。二者本應是相輔相成的互助模式,而非所謂的敵對。 便如三權分立的思想,在合作的同時,彼此制衡,來保證產品的質量。 隨著這個行業的發展,競爭逐漸激烈,門檻也會逐步提高。 在這種情況下,我們的測試人員還有理由沒有編碼能力嗎?所以,編碼能力必將成為測試從業者的基礎技能之一。 另外就是,要堅定的認識到,自動化測試的推進不再是產品測試人員的工作,需要研發測試的合力。 在產品的設計階段,留出良好的測試接口,當然,可以包含在發布代碼中,也可以調試模式或者其他方式,現在也有成熟的理論支撐,在后續的發布版本中去掉。有了良好的測試代碼接口,我們的自動化測試人員可以大幅提高開發效率,進而提高投入產品比,讓自動化測試不只停留在一個理論的階段。 同時,也要推進研發人員的白盒測試工作,當然,具體誰來執行白盒測試各公司分工不同。至少要有認識,如果他們不愿意或者排斥白盒測試的工作,你是否有能力承擔起白盒測試的工作? 相比UI的功能自動化測試工作,我一直認為白盒測試自動化和性能測試自動化相對要容易些。 對于想實現最終的自動化測試,可以逐步推進,從白盒測試自動化,到功能測試自動化,UI功能自動化到性能測試自動化。在設計層面加入一些思考,讓彼此解耦合,能夠

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論