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

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