想從零基礎學(xué)習軟件測試到成為測試工程師詳細了解南京自動(dòng)化測試開(kāi)發(fā)前途

1.圖形界面自動(dòng)化測試的前途在哪里?

降低自動(dòng)化測試的門(mén)檻是很多自動(dòng)化測試工具提供商努力的目標。尤其是對于圖形界面的自動(dòng)化測試，就更是這樣。 于是，“錄制與回放”就成了圖形界面自動(dòng)化測試的主流。不論是 Web 界面的，還是基于 Windows API 界面的，還是 Java GUI 界面的，“錄制與回放”的工具，不論是商用的，還是開(kāi)源的，都不少。在技術(shù)上，大家也在“錄制”上下足了功夫。 錄制就需要先識別?，F在 Web 頁(yè)面的顯示技術(shù)在向基于客戶(hù)端的軟件的界面靠攏，于是工具要識別各種動(dòng)態(tài)界面的不同組件，不同編程語(yǔ)言實(shí)現的動(dòng)態(tài)效果。你能夠適應 .NET 和 ASP 編寫(xiě)的界面，我可以使用動(dòng)態(tài)的 , AJAX。 Web 的動(dòng)態(tài)顯示技術(shù)層出不窮，先是基于服務(wù)器端的動(dòng)態(tài)頁(yè)面顯示，再后來(lái)又可以把代碼傳送并放到客戶(hù)端來(lái)由瀏覽器解釋了再動(dòng)態(tài)顯示，現在又可以局部更新頁(yè)面的部分信息，很多頁(yè)面又開(kāi)始使用 Flash 等等。于是，如何自動(dòng)識別這些動(dòng)態(tài)的顯示技術(shù)，并保證錄制與回放的正確，就成了各個(gè)自動(dòng)化測試工具廠(chǎng)商最求的目標。也就是基本上是在跟著(zhù)動(dòng)態(tài)顯示技術(shù)發(fā)展的屁股后面跑。然而“錄制與回放”有一個(gè)大問(wèn)題，就是“錄制”下來(lái)的腳本的維護問(wèn)題。Web 界面的變化是非常頻繁的。通常市場(chǎng)*的一個(gè)反饋，界面就要做比較大的調整，而這個(gè)調整，會(huì )導致之前“錄制”好的腳本的重用性變得很差。 需要維護。 如果不想維護，再錄制一遍的話(huà)也會(huì )造成人力的浪費。 畢竟，腳本和真正的程序代碼雖然都是編程的產(chǎn)物，但人家代碼是公司研發(fā)的最終產(chǎn)品，是可以賣(mài)錢(qián)的;腳本只是測試的一個(gè)中間環(huán)節，腳本執行的結果才是我們測試人員想得到的東西，花費很大力氣來(lái)維護一個(gè)中間產(chǎn)品，任何一個(gè)研發(fā)部分都要好好考慮一下投入與產(chǎn)出是否值得了?？删S護性差是“錄制與回放”技術(shù)需要攻克的技術(shù)難題。而解決這個(gè)難題，需要兩方面的努力:腳本良好的封裝，與 API (關(guān)鍵字)接口的完整定義 開(kāi)發(fā)人員對于界面元素賦予*標示的 ID。 解決圖形界面自動(dòng)化腳本的可維護性，還需要開(kāi)發(fā)的幫助，為界面元素提供*的標識。這樣，不論以后界面如何變化，只要標識不變，之前的腳本一樣可以復用。而良好的腳本封裝是“錄制與回放”幾乎難以逾越的一座技術(shù)大山?！颁浿啤睕Q定了前期很少進(jìn)行軟件設計，腳本也是順序執行的。這與預先設計完整的 API 接口，再進(jìn)行腳本開(kāi)發(fā)的流程是相違背的。從長(cháng)遠考慮，每一個(gè)軟件開(kāi)發(fā)企業(yè)在圖形界面的自動(dòng)化測試上，都應該力求向關(guān)鍵字編程靠攏，而不是過(guò)度的依賴(lài)自動(dòng)化測試工具廠(chǎng)商的“錄制與回放”技術(shù)。 這，才應該是圖形界面測試自動(dòng)化的未來(lái)。

2.糾結:做自動(dòng)化測試有前途嗎？

做自動(dòng)化測試有前途。自動(dòng)化測試現在還蠻熱門(mén)的，一般公司都會(huì )用到。而且會(huì )比手工測試高級一些的，畢竟薪資門(mén)檻擺在那里。

想了解軟件測試學(xué)習課程，費用以及時(shí)間了解圖形界面自動(dòng)化測試的前途在哪里?，糾結:做自動(dòng)化測試有前途嗎？??