軟件測試技術交流羣
: 429183023
偶然看到的一篇自動化測試小散文，覺得不錯
原文：http://blog.csdn.net/u013970991/article/details/54928922
如果說“生活不只有眼前的苟且，還有詩和遠方”的話，那麼自動化測試可以說是很多測試人員心中的“詩和遠方”。
“詩和遠方”OR“禁果”
測試自動化，需要持續改進。但由於其本身是一種過於激動人心的想法：用程序去測試程序——解放了測試人員的生產力，節省大量的人力成本，這就有點“禁果”的意思了。
一個常見的行動模式是：在實施自動化測試時，設定一些量化指標，例如根據業務、接口、模塊設置的覆蓋率。技術團隊在完成指標的過程中，以完成指標爲中心而忘記了爲什麼要進行自動化測試。其結果是各項指標都完成了，但是沒人能說清自動化測試的效果和價值，而技術人員也沒有熱情再繼續下去。最終，自動化測試只能“被完成”了。
那如何避免自動化測試的誘惑，或者降低誘惑的影響呢？
三觀，你的三觀要正
自動化測試，有開發的過程，有測試的過程，說到底，依然是測試的過程。所以自動化測試，依然遵循測試活動的基本內涵：反饋信息——它是幫助技術團隊獲得關於軟件產品質量信息的反饋手段，這是實施自動化測試的中心。評判自動化測試是否有效的標準，就是自動化是否能夠幫助技術團隊獲取質量信息，其關鍵就在於自動化測試的測試分析與設計。
沒錯，自動化測試的測試分析與設計
什麼？自動化測試也需要進行測試分析與設計嗎？不是就把手動執行的用例自動化就可以了嗎？
確實，自動化測試實施的一個常見的活動模式是：選擇工具或者腳本語言、確定哪些手工執行的用例需要執行，錄製或編寫執行的腳本，配置測試數據，執行測試。這個模式中就沒有自動化的測試分析和設計。而對工具的研究學習通常是開展自動化測試的第一步，特別是對於以往做功能測試的同學而言，掌握工具比測試分析和設計是更顯而易見的技能加分項。但工具卻不是自動化測試的能否有效的關鍵。
測試分析與設計是測試活動能否有效的關鍵，自動化測試也不例外。例如，在數據庫表結構變更的場景中，我們需要分析如何確認需要進行驗證的數據特徵？如何構造這些測試數據？如何驗證數據結構變更前後，程序對數據新老數據的處理是符合需求的？這些都可以使用自動化的達到手工測試不同的效果。
但這好像和我們認爲的自動化測試不太一樣呀。是的，自動化測試並非是將手動執行的用例自動化，它有自己的測試領域，像生成大量的測試數據、多組合的測試數據、發起大量的請求、觸發資源競爭、執行嚴格的結果檢查、快速報告結果等等，它在幫助你完成手工難以完成的事，而不是幫你完成手工可以完成的事。你的每一次測試活動，如果有手工無法完成的事，那麼你就應該考慮自動化測試，並對自動化進行測試分析和設計。而如果沒有手工無法完成的事，我們則需要考慮是不是遺漏了什麼。
那把手動執行的用例自動化作爲迴歸測試不可行嗎？
“啪啪啪”，有可能是打臉
看情況。自動化是否用於迴歸測試？用例是否自動化？等等，選擇一個合適的自動化測試策略，需要關注：測試需求、軟件系統結構、人員能力。對於需要從業務的角度進行的迴歸測試而言，更需要關注產品的迭代節奏或者生命週期。畢竟複雜的業務邏輯、修改已失效的測試的時間成本，通常都會給認爲自動化測試能夠節省人力成本的人狠狠的一記耳光。
但這並非說業務測試的迴歸就不能自動化，其關鍵在於劃定業務範圍。一個經驗是使用“業務邏輯－失效風險”的分析，將業務邏輯按照功能失效後帶來的風險進行分析後，圈定高風險業務邏輯進行自動化，嚴格保證高風險業務的可靠性。另一種方法則可以使用冪律分佈，我們常說的2/8原則就是其一個體現：根據生產業務的使用情況，將常用業務邏輯進行自動化，保證其可靠性。
這裏我們依然堅持的理念是讓自動化幫助我們完成我們手工做不了的，而不是替代手工測試。
“沒有兩片相同的葉子”，也沒有兩次相同的手工測試
測試，給人的一個錯覺就是重複性，包括有些公司在招測試人員的時候會有一條叫“能夠勝任重複性工作”。但試問，誰會手工運行N次相同的測試呢？一個測試人員，他在執行什麼測試不重要，他爲什麼要執行這個測試——背後的分析思考才重要。自動化的測試，能夠替代的是相同的執行，卻無法替代人的分析與思考。而軟件產品在研發迭代的過程，是團隊不斷地把新的分析思考注入其中的過程。測試工作面對的是始終在不斷變化的測試需求。所以測試的分析思考，包括手工和自動化的測試也需要不斷地迭代改善。
“只有改善，沒有成功與失敗”
對於有專門自動化測試的小組而言，通常會以項目的形式開展自動化，制定任務的行動計劃表或者里程碑等進行跟蹤管理。而個人實施自動化，則相對自由寬鬆。但無論小組還是個人，爲了能夠保持持續改善的動力，最重要的一點是讓每一步工作是有效的，實施團隊或個人能夠從自動化測試的過程中及時得到正向反饋。對於小組的負責人而言，這是讓團隊保持動力的關鍵。一個經驗是，任務拆解細化，參考OODA環，週期性進行回顧調整。另一個負責人必須關心的事是，需要週期告知自動化測試的利益相關方目前的情況，例如技術團隊、領導層、上下游合作方等。讓大家看到一個持續改進的過程，樹立對自動化測試的信心。
“生活不只有眼前的苟且，還有遠方的苟且”
聊到這，很多人已經感到自動化測試並非是“詩和遠方”，更像是“遠方的苟且”——沒有美感、沒有情懷。對，我們所面臨的都是一個一個具體的問題，拆開看很挫，很細碎，需要有勇氣去面對。
參禪打坐3分鐘
無論發生什麼都要認真對待，這就是工作的真諦。［1］
［1］摘自《零售的哲學》