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