<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          軟件測試培訓分享自動化測試定位及實踐分析

          • 發布:軟件測試培訓
          • 來源:51Testing軟件測試網
          • 時間:2018-06-26 18:36

          達內軟件測試培訓今天為大家解讀的是自動化測試的定位及實踐分析,希望大家能夠學有所獲!

          大家對自動化的理解,首先是想到WebUI自動化,這就為什么我一說自動化,公司一般就會有很多人反對,因為自動化的成本實在太高了,其實自動化是分為三個層面的(UI層自動化、接口自動化、單元測試),不是每個層面的自動化都是遙不可及的,以下標示一下這三個層面的難易程度(也叫這個為自動化金字塔):

          自動化測試金字塔

          三個層面的自動化測試

          基本上可以肯定的是,單元測試是成本最低的,也是最容易推廣,見效最大的,但是很多公司不會投入這塊,原因是因為現在大部分公司都是人才短缺,特別是成手的研發人員。你說投入到項目實際開發工作的人員都嫌不夠,怎么可能抽出相關人力去做單元測試。而以目前大部分公司的測試團隊人員構成來說,能做單元測試的基本沒有(有也被抽去做開發了),這也是大家一致認為單元測試屬于開發職責的原因(除了他們自己沒人能做了)。

          單元測試如果做不了,那么接口(API或Service)自動化測試能做不?這個只要有一定的技術基礎還是能做的,至少有一部分測試人員是能夠做接口測試的(話說性能測試就屬于一種接口自動化),如果能自主開發或直接引進一套像樣的接口自動化工具或框架(工具上來說,市面上也不少),那么就可以開展這部分的工作,我相信大部分公司能做好的自動化測試,應該也是基于這一層的(所以我們建議有條件的話,自動化測試可以先在這一層面開層,當然前提是真有那么多接口或服務需要測試)。接口自動化測試框架應該具有以下功能,根據復雜度和各自需求而定:

          1、校驗

          這個很好了解,如果沒有校驗,單純的執行接口的話,那就談不上測試了。所以支持對返回值校驗是一個必須的功能。

          2、數據隔離

          數據隔離就是指具體的請求接口、參數、校驗等數據做到與代碼相隔離,便于維護,一旦需要調整接口用例、新增接口用例時可很快速的找到位置,隔離的另一個好處就是可復用,框架可以推廣給其他團隊,使用者可以使用相同的代碼,只需要根據要求填寫各自用例即可測試起來。

          3、數據傳遞

          做到數據隔離可維護后,數據傳遞是另外一個更重要的需求。

          數據傳遞是指接口用例之間可以做到向下傳參,例如我們通過創建訂單接口創建一個訂單,該接口會返回一個訂單號,接下來我們要進行調用查詢訂單的接口,從返回的數據中與創建訂單用例中的數據進行校驗,此時第二個接口的請求數據是需要從第一個接口用例中的返回中提取的。這樣的例子比比皆是,所以支持數據傳遞是又一個必不可少的功能。

          4、動態函數

          實際用例場景中我們可能會有隨機生成一個手機號、字符串加密等需求,在數據與代碼隔離之后,此時我們就需要代碼可以支持做到識別對應關鍵字時可以執行對應的函數進行填充。例如在數據中填寫nowTime()時,具體執行時會被替換成當前時間,填寫random(5)時,會被替換成一個五位的隨機數等等。

          5、可配置

          有時,我們的需求是用例不單單只能在一個環境上執行,可能需要同一份接口用例可以在QA、預發、線上等多個環境都可以執行。所以框架需要做到可配置,便于切換,調用不同的配置文件可以在不同的環境執行。

          6、日志

          日志包含執行的具體執行接口、請求方式、請求參數、返回值、校驗接口、請求時間、耗時等關鍵信息,日志的好處一來是可以便于在新增用例有問題時快速定位出哪里填寫有問題,二來是發現bug時方便向開發反饋提供數據,開發可以從觸發時間以及參數等信息快速定位到問題所在。

          7、可視化報告

          用例執行后,就是到了向團隊展示結果的時候了,一個可視化的報告可以便于團隊成員了解到每次自動化接口用例執行的成功數、失敗數等數據。

          8、用例驅動

          (1)用例的驅動模式,涉及到怎么存放測試數據,怎么描述用例,又如何復用;

          (2)考慮到效率的話還要支持并發;

          (3)當然測試報告不能光記錄成功和失敗,還有用例執行耗時、接口調用耗時、場景的通過率等各項數值的統計。

          說完單元測試、接口測試的自動化,我們現在來說說UI層自動化測試,這也是一直很火并且也是自動化概念先入為主的一塊,畢竟市面上有不少成熟的自動化工具,如QTP、Selenium等。這塊自動化一定是會有測試團隊參與的,就算自動化框架是由開發來完成,那么具體測試工作也是由Tester全程參與的。UI層自動化測試真的不容易推行,無論有多么完善的自動化框架,在這一塊維護的成本也是非常高的,特別是懂開發的人不懂測試,懂測試的人不懂開發,這一矛盾現象所帶來的內部消耗就不少,再加上項目需求和UI層都在頻繁變動,而且Web UI技術越來越復雜和多元化(UI層自動化需要基于對象識別技術),這些都導致很多公司不愿意投入這一塊。即使這樣,做為一個有上進心的測試人員,我們也是需要多想想這一塊,畢竟這是離我們測試最近的一塊“技術沃土”了(之一)。

          現在我們來重點來談下Web UI自動化測試(目前的系統大都通過Web UI來展示),一般成熟一點的自動化工具方案大體是這樣:

          1、開發語言:PythonJava;

          2、開源測試框架:Selenium WebDriver;

          3、Web元素定位:Xpath+cssSelector+findElement或findElements方法;

          具體實施細節來講重點是針對Web UI自動化測試的特點,將各層包裝,分而治之的思想,各自相互獨立,職責定義清楚,下面簡要說明下:

          1、測試用例業務流操作實現及測試數據分離管理;

          2、頁面元素定位及頁面元素的操作分離;

          3、可視化的日志查詢系統;

          4、跨瀏覽器支持如:IE,Firefox,Chrome;

          5、可視化的的測試報告,可以具體查詢到日志/截圖等;

          6、實現了通過Excel的數據驅動管理;

          7、郵件發送管理,可以自定義具體時間及接受者等。

          以上是一般Web UI自動化測試的一些實踐要求,當然也是相對簡易的,復雜的就是實現平臺化管理,每天測試工程師,只需要選擇具體項目、所測的測試用例集,然后執行,輸出測試報告,郵件自動發送到相關開發/測試,框架的開發維護上也能夠持續集成。

          優先開展自動化測試的思考

          說完了這三個層面的自動化測試,那么我們再來分析一下,到底應該優先開展哪個層面的自動化測試,到底是哪個投入產出比最高。

          眾所周知,軟件測試的邊際成本會隨著缺陷探測率的提高而提高,這就是軟件測試的基本公理之一"測試的不可窮盡性"的經濟學體現。這一規律也適用于自動化測試,也就是說隨著自動化覆蓋率的提升,自動化的成本也呈現指數式上升。按照這個思路進行拓展,可以分析下單元測試,集成測試和UI測試的自動化成本曲線如圖2所示。與通常理解的一致,為了達到相同的自動化率(x0),UI的成本最高、其次是API,Unit則最低。

          經濟學中有另外一個著名的理論叫做邊際效益遞減。當做一項投資,隨著投資量的增加,單位投資增量所帶來的單位收益是越來越少的,甚至在某個臨界點之后,這個收益有可能是負數。而這個零界點,就是投資收益最大的點。在這個點之前的所有投資,都可以擴大總收益,而在超過之后繼續進行投資,就不那么明智了。

          自動化成本/收益曲線

          圖2 自動化成本/收益曲線

          按照這個思路,在圖2上,針對三種不同類型的自動化測試,可以獲得三個零界點。而總收益最大的點在接口測試上,隨后是單元測試,UI測試則最低。

          如果從測試效果上看,接口測試和UI/單元測試相比,有很多優勢。 對于單元測試來說,通常單元測試是針對代碼進行的測試,而接口測試是在測試一個活的,經過部署的系統。 另外,單個接口測試與單個單元測試用例相比,也可以覆蓋更多的代碼。更重要的是,接口測試也可以是面向業務的測試,通過接口進行業務層面的測試。

          而相比UI自動化用例,接口測試更加的簡單直接,執行效率更高。 除了部分如企業級應用軟件,可能很多業務在前端進行之外,很多情況下,絕大部分通過UI完成的業務操作完全可以通過API端完成。某些情況下,API(接口)的測試條件覆蓋率甚至可以多過UI。

          總結

          綜合上述的分析,筆者認為在自動化測試的初級階段,適合奔小康的測試團隊的自動化模式應該是中間層的接口最大,兩端的UI和Unit測試適度實施。從圖形上看,就是一個橄欖型(中間的接口測試效益比最高)。如果再加上一部分的手工測試,那就是一個不倒翁了。(接口測試可以由開發團隊來做,也可交由測試團隊去開展)

          按照這個模式,將大部分自動化投資用于接口測試,可以獲得最高的投資回報。再結合持續測試與持續集成等最佳實踐,在團隊之間彼此共享測試用例、測試框架或者平臺,通過接口測試這一承上啟下的測試類型,可以自下而上地逐步翻越過紙杯蛋糕模式中的那堵墻。(備注:紙杯蛋糕模式,是一種反金字塔的自動化模式,開發和測試各自為政,線性的開展測試,無法并行協同測試,相當于有道部門墻,開發的自測環節和測試開展的測試環節,沒有建立關聯和資源共享---重復測試、度量目標不一致、過度自動化)。

          恭喜你閱讀完了本文,通過對自動化測試定位以及實踐的分析,你已經理解了什么是自動化測試金字塔,三個層面的難易程度是怎樣的以及Web UI自動化測試的方案是怎樣的,如果你還有更多相關的問題,歡迎你來達內軟件測試培訓機構進行咨詢。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:了解這些軟件測試專業術語,入門更簡單!
          下一篇:詳細解讀軟件測試中的性能測試,將要點一網打盡!

          軟件測試必備的數據庫知識有哪些?(終)

          日志在快速定位自動化腳本故障中的重要性研究

          測試慣例是什么?怎么打破測試慣例?

          “用鼠標點點點”的測試,未來還有機會嗎?

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2018 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>