分層測試的思想

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

總的來說測試需要有層次感，不同層面的測試需要不同形態的測試方法來保證其質量。

分層測試的思想把測試分為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個測試用例，這樣一算投入的成本其實就不高了，加上自動化測試帶來的人員增值，實際上產出是大於投入的。

#--------------------------------------------------------------------------------華麗的分割線----------------------------------------------------------------------

嘻嘻，篇後語，希望每個測試團隊都能正視並合理運用自動化測試技術，提高效率，提升產能！！！

ui自動化測試的意義與理解