世上本沒有路，走的人多了，也就有了路。今天不講技術(shù)，只講感悟。
第一節(jié)：質(zhì)量意識是自動化的前提
任何東西都有個價格，質(zhì)量也一樣，如果在產(chǎn)品的戰(zhàn)略定位中，質(zhì)量不是核心價值，那么質(zhì)量的價格自然不會高，為質(zhì)量付出的代價也不會高。
普遍講，客戶端產(chǎn)品的質(zhì)量要求高于Web產(chǎn)品，客戶端出了Bug，用戶修復很麻煩，Web產(chǎn)品出了Bug，可以臨時上線，或在下次上線修復；Web產(chǎn)品中，涉及money的質(zhì)量要求高于沒有盈利模式的產(chǎn)品，比如：游戲 or 購物類；還有就是用戶群體的大小和產(chǎn)品活躍度，等等。
第二節(jié)：減輕測試負擔是現(xiàn)實動機
古語有云：凡是機器可以解決的，就把它自動化吧！
有代碼重構(gòu)和服務器配置變更等涉及面廣大的任務時，須要大量的回歸測試，這時候先使用接口測試回歸，可以速度得到反饋，確保功能無錯，再配合UI測試。
日常工作中，不會天天重構(gòu)，但做一下每日回歸，上線前再密集的多回歸幾個輪次，應該是比較靠譜的。
自動化腳本尤其是接口測試腳本還可以用于批量準備測試數(shù)據(jù)，偶爾用用，不亦樂乎。
第三節(jié)：結(jié)合產(chǎn)品本身的狀況是必由之路
額。。。這里的水太深了。簡單講，自動化不貼合一個產(chǎn)品本身的特點，十有八九是舉步維艱。
一個比較理想狀況是，產(chǎn)品的發(fā)展思路比較清晰，項目流程比較規(guī)范，上線的節(jié)奏穩(wěn)定有序。在這種情況下，測試比較容易和開發(fā)溝通，取得開發(fā)的協(xié)助寫用例，也比較容易確定啥時候?qū)懹美苡美S護用例，維護的用例也可以反復利用，而不至于因為產(chǎn)品的頻繁變化而失效，反而拖累大家陷入維護用例的泥沼。
第四節(jié)：持續(xù)投入，方可見到效果
無論從哪個角度看，自動化發(fā)現(xiàn)的Bug都是很少的，自動化主要是用來回歸的。
用例只有十幾二十個，不會有太大的收益，沒有量的積累不會有質(zhì)的變化。寫很多用例？很大的成本，而且，產(chǎn)品在不斷發(fā)展，用例本身也要不斷維護，這些都是成本，看起來是個無底洞。
一天跑個一次兩個，搞個每日回歸，收益不見得高，最好是搞成持續(xù)集成，密集的連續(xù)跑。但是，用例掛了誰來檢驗？誰來維護？誰來反饋？如何做到及時？這些都須要人力。
所以，做自動化，不做則已，一做就要有花成本的勇氣，用例要足夠，至少覆蓋所有核心的功能點，盡量做到持續(xù)集成，畢竟都是敏捷開發(fā)模式，代碼提交的頻度很高，還要有堅持擴充，維護用例庫的恒心。
一個優(yōu)良的自動化框架的價值主要體現(xiàn)在這里：使得用例好寫，好維護，運行穩(wěn)定，運行快。
發(fā)現(xiàn)Bug不是我們的目的，保證質(zhì)量才是。