我的自動化軟體測試小結（2）

世上本沒有路，走的人多了，也就有了路。今天不講技術，只講感悟。

　　第一節：質量意識是自動化的前提

　　任何東西都有個價格，質量也一樣，如果在產品的戰略定位中，質量不是核心價值，那麼質量的價格自然不會高，為質量付出的代價也不會高。

　　普遍講，客戶端產品的質量要求高於Web產品，客戶端出了Bug，使用者修復很麻煩，Web產品出了Bug，可以臨時上線，或在下次上線修復；Web產品中，涉及money的質量要求高於沒有盈利模式的產品，比如：遊戲 or 購物類；還有就是使用者群體的大小和產品活躍度，等等。

　　第二節：減輕測試負擔是現實動機

　　古語有云：凡是機器可以解決的，就把它自動化吧！

　　有程式碼重構和伺服器配置變更等涉及面廣大的任務時，須要大量的迴歸測試，這時候先使用介面測試迴歸，可以速度得到反饋，確保功能無錯，再配合UI測試。

　　日常工作中，不會天天重構，但做一下每日迴歸，上線前再密集的多回歸幾個輪次，應該是比較靠譜的。

　　自動化指令碼尤其是介面測試指令碼還可以用於批量準備測試資料，偶爾用用，不亦樂乎。

　　第三節：結合產品本身的狀況是必由之路

　　額。。。這裡的水太深了。簡單講，自動化不貼合一個產品本身的特點，十有八九是舉步維艱。

　　一個比較理想狀況是，產品的發展思路比較清晰，專案流程比較規範，上線的節奏穩定有序。在這種情況下，測試比較容易和開發溝通，取得開發的協助寫用例，也比較容易確定啥時候寫用例，跑用例，維護用例，維護的用例也可以反覆利用，而不至於因為產品的頻繁變化而失效，反而拖累大家陷入維護用例的泥沼。

　　第四節：持續投入，方可見到效果

　　無論從哪個角度看，自動化發現的Bug都是很少的，自動化主要是用來回歸的。

　　用例只有十幾二十個，不會有太大的收益，沒有量的積累不會有質的變化。寫很多用例？很大的成本，而且，產品在不斷髮展，用例本身也要不斷維護，這些都是成本，看起來是個無底洞。

　　一天跑個一次兩個，搞個每日迴歸，收益不見得高，最好是搞成持續整合，密集的連續跑。但是，用例掛了誰來檢驗？誰來維護？誰來反饋？如何做到及時？這些都須要人力。

　　所以，做自動化，不做則已，一做就要有花成本的勇氣，用例要足夠，至少覆蓋所有核心的功能點，儘量做到持續整合，畢竟都是敏捷開發模式，程式碼提交的頻度很高，還要有堅持擴充，維護用例庫的恆心。

　　一個優良的自動化框架的價值主要體現在這裡：使得用例好寫，好維護，執行穩定，執行快。

　　發現Bug不是我們的目的，保證質量才是。