自動化測試的理解

分層測試的思想

分層測試（有的也叫測試金字塔）是最近幾年慢慢流行、火熱起來的，也逐漸獲得了你們的承認，你們應該已經比較熟悉分層測試的思想了，不太瞭解的能夠自行找一些相應的渠道去補充一下上下文的知識。

總的來講測試須要有層次感，不一樣層面的測試須要不一樣形態的測試方法來保證其質量。

分層測試的思想把測試分爲3層：

      * unit test層：能夠簡單的理解爲白盒測試層。測試的對象是代碼，測試工具通常爲相應語言對應的單元測試框架，經過各類斷言來判斷代碼的邏輯是否符合預期。

        單元測試用例通常是從代碼中演化出來，先寫代碼，再對代碼進行測試。單元測試通常是由開發來作的，測試同窗能夠作，但頗有挑戰。

      * service test層：能夠簡單理解爲接口測試，注意這個接口能夠是代碼級的接口和服務間通訊的接口，可是針對代碼的接口作的測試通常能夠理解成是白盒測試，

        能夠放在unit test層，測試同窗所作的接口測試通常指的是服務間接口的黑盒測試，從目前趨勢發展來看，這一層基本上須要自動化去實現。

      * 功能測試層：若是被測對象有ui的話，手工測試就是點來點去，自動化測試就是代替人工點來點去，而後進行斷言。這一層測試的自動化成本最高，挑戰最大。

 

自動化測試如何保證質量

      ui自動化測試的難度是最高的，實現和維護成本都很高，哪怕是用selenium來實現。

　  那麼自動化測試能不能保證項目的質量呢，答案是確定的。

　  自動化測試能夠反覆迅速的執行一些測試用例，從而下降執行的成本，提高了迴歸的速度，可讓團隊把迴歸的精力放在另外一些不合適用自動化測試去實現的測試用例上。好搞定的問題讓機器去搞定，難搞定的問題用人去搞定。

 

如何選擇自動化測試用例　　

      自動化測試用例就是功能測試用例，建議簡單的功能測試用例儘可能用自動化去實現。由於簡單的測試用例每每都有迴歸的必要，若是測試同窗老是機械的迴歸這些手工測試用例的話，那麼工做註定是痛苦的。

      因此建議核心功能，也就是用戶常常用的功能儘可能覆蓋。

      簡單的功能儘可能覆蓋。

      正常的情形儘可能都覆蓋，異常場景有選擇性的覆蓋，時間不夠能夠不用覆蓋。

 

如何衡量自動化測試的效果

      自動化測試的效果如何來衡量呢？在這裏給出兩個建議的方案：

          * 迴歸速度的對比：之前全量回歸要x天，是否有提高；

          * 核心及常規功能的線上bug遺留數：之前核心功能和常規功能的線上bug數是xx，如今是xx，是否有提高；（這裏多叨叨一句，自動化執行迴歸測試不必定能多發現bug，但能夠節約時間讓咱們測試同窗有更加充足的時間去進行新功能的測試，從而減小線上bug數）

      另外有些團隊喜歡計算自動化測試的投入和產出比，好比投入2我的花了1個月時間寫了300個測試用例，而bug數沒有明顯的下降。這是有可能的，由於自動化測試用例並不能發現新bug。因此在計算投入產出比的時候，必定要加上運行次數的計算。300個測試用例若是能運行20次就是3000個，而手工測試人員須要花2我的1個月的時間去執行6000個測試用例，這樣一算投入的成本其實就不高了，加上自動化測試帶來的人員增值，實際上產出是大於投入的。