什么是自動化測試系統(tǒng)
　　首要理清自動化測驗的概念，廣義上來講，自動化包含全部經(jīng)過東西（程序）的辦法來替代或輔助手藝測驗的行為都能夠看做自動化，包含功用測驗東西（loadrunner、jmeter）,或自己所寫的一段程序，用于生成1到100個測驗數(shù)據(jù)。狹義上來講，通東西記載或編寫腳本的辦法模仿手藝測驗的進程，經(jīng)過回放或運轉腳正本履行測驗用例，然后替代人工對體系的功用進行驗證。
　　當然，咱們更遍及的知道把“自動化測驗”看做“ 根據(jù)產品或項目UI層的自動化測驗”

　　分層的自動化測驗
　　這個概念最近曝光度比較高，傳統(tǒng)的自動化測驗更重視的產品UI層的自動化測驗，而分層的自動化測驗倡議產品的不同階段（層次）都需求自動化測驗。
　　信任測驗同學對上面的金字塔并不陌生，這不就是對產品開發(fā)不同階段所對應的測驗么！咱們需求規(guī)范的來做單元測驗相同需求相應的單元測驗結構，如java的Junit、testNG，C#的NUnit ，python 的unittest、pytest 等，簡直一切的主流言語，都會有其對應的單元測驗結構。
　　集成、接口測驗對于不少測驗新手來說不太簡單了解，單元測驗重視代碼的完成邏輯，例如一個if 分支或一個for循環(huán)的完成；那么集成、接口測驗重視的一是個函數(shù)、類（辦法）所供給的接口是否可靠。例如，我界說一個add()函數(shù)用于核算兩個參數(shù)的成果并回來，那么我需求調用add()并傳參，并比較回來值是否兩個參數(shù)相加。當然，接口測驗也可所以url的方法進行傳遞。例如，咱們經(jīng)過get辦法向服務器發(fā)送請求，那么咱們發(fā)送的內容做為URL的一部分傳遞到服務器端。但比方 Web service 技能對外供給的一個公共接口，需求經(jīng)過soapUI 等東西對其進行測驗。
　　UI層的自動化測驗，這個咱們應該再了解不過了，大部分測驗人員的大部分工作都是對UI層的功用進行測驗。例如，咱們不斷重復的對一個表單提交，成果查詢等功用進行測驗，咱們能夠經(jīng)過相應的自動化測驗東西來模仿這些操作，然后解放重復的勞作。UI層的自動化測驗東西非常多，比較主流的是QTP，Robot Framework、watir、selenium 等。
　　為什么要畫成一個金字塔形，則不是長方形 或倒三角形呢？ 這是為了表明不同階段所投入自動化測驗的份額。假如一個產品從沒有做單元測驗與接口測驗，只做UI層的自動化測驗是不科學的，然后很難從本質上確保產品的質量。假如你妄圖完成全面的UI層的自動化測驗，那更是一個勞民傷財?shù)男袨?，投入了很多人力時刻，終究取得的收益可能會遠遠低于所付出的本錢。由于越往上層，其保護本錢越高。尤其是UI層的元素會時常的發(fā)作改變。所以，咱們應該把更多的自動化測驗放在單元測驗與接口測驗階段進行。
　　已然UI層的自動化測驗這么勞民傷財，那咱們只做單元測驗與接口測驗好了。NO! 由于不論什么樣的產品，終究出現(xiàn)給用戶的是UI層。所以，測驗人員應該更多的精力放在UI層。那么也正是由于測驗人員在UI層投入很多的精力，所以，咱們有必要經(jīng)過自動化的辦法協(xié)助咱們“部分解放”重復的勞作。
　　在自動化測驗中最怕的是改變，由于改變的直接成果就是導致測驗用例的運轉失利，那么就需求對自動化腳本進行保護；怎么操控失利，下降保護本錢對自化的成敗至關重要。反過來講，一份永久都運轉成功的自動化測驗用例是沒有價值。