測試能力分層的組織架構下，一提到效率提升，可能大多數人，首先想到的是測試開發團隊，亦或是成敗在于此。假如我們也是這樣想，我想我們可以嘗試換一個角度，也許會有更多的收獲。
兩個必要問題
解決效率問題，其本身包含兩個必要問題，二者缺一不可：
1. “適不適合”做
2. “能不能夠”做
“適不適合做” 衡量的是意義價值，即必要性，引入自動化測試是為了能夠切實解決某些問題，而不是單純為了自動化而做自動化。
“能不能夠做”衡量的是能力水平，即可行性，重點關注的是具體開展過程中的自動化設計、開發、維護、使用等問題，如何通過更優雅的方式降低開發、維護成本，比如數據驅動等等。
結合以往經驗，在只解決上述問題中的其一或者二者不解決的情況下，可能會出現以下情況：
只解決“適不適合做”的問題，可能會導致：
沒有掌握完整的自動化測試技術棧，開發成本高。
沒有選擇合適的框架或解決方案，無法從整體上降低用例的編寫、維護成本，在持續投入下，投入產出比大概率為負。
只解決“能不能夠做”的問題，可能會導致：
傳統瀑布開發模式下，迭代周期長，次數少。幾個版本下來，等同測試覆蓋下，自動化測試投入可能大于手動測試投入。
頻繁的需求變更，自動化用例維護成本高，自動化測試逐漸廢棄。
“適不適合做”、“能不能夠做”的問題都不解決，可能會導致：
如果是這樣，那這只能是 “鬧著玩”，也許曇花一現、也許半途而廢。
因此，在我們的自動化開展過程中，引入了自動化需求澄清環節，主要研判的就是上述兩個問題。這個過程，業務方作為需求提出方主要研判“適不適合做“的問題，測開方作為需求承接方主要研判“能不能夠做的問題”，根據以往經驗，前者問題難度更高更復雜。
因此，我們不難發現，要做到有效的提升、這兩個問題是繞不過去。在解決這兩個問題的前提下，我們才能夠正確地明確其目標，才有了目標才能正確制定其具體實施方案。
為何而做（目標度量）
接下來，聊一聊目標，自動化測試度量指標，我們近幾年嘗試過很多種維度去度量，例如，從自動化用例數量、到覆蓋率、再到ROI、效率提升率，我們發現這些度量維度不難計算，通過自動或手動統計的方式都可以統計計算出結果，但度量數據反映的情況與實際情況存在較大的差異性（效率、質量），例如 度量數據呈現出的效率提升率在變高，但實際業務測試周期似乎沒有變化，等等。
那么這個問題出在哪里？—— 當我們與真相一步步靠近時，這其中每一步都是有意義的。
問題也許出在 “目標” 本身，目標即導向。那么效率提升的本質是不是“用例數量多“、”覆蓋率多”、”ROI高”？ 好像也并不是，差一點意思。我認為本質應該是簡單的、直接的 ：
在定時任務的背景下，快 → 時間縮短
在定量任務的背景下，快 → 人數減少
我們可以嘗試以效率提升最本質的目標作為驅動，也許將更有效、更直接。
在具體指標設定時，除了“定性”、不可避免的還要“定量”，“定量”一方面是為了度量其絕對值，另一方面是與其“定性”相互佐證。
定性： 時間縮短 → 例如，平均項目測試周期縮短 X % 。
定量： 累計節省人力投入（或累計節省額外人力投入） → 例如，累計節省額外人力投入X 人月。
如何去做
這是萬事俱備，只欠東風的一步，當然這也是最重要的一步。有一些項目可能會有疑問，上述的問題，我們都一定程度解決掉了，但自動化測試仍然沒有達到預期的效果。
大概可能是以下原因導致：
缺乏整體測試用例執行設計，用例覆蓋目的性弱，具有隨機性、隨意性，低覆蓋，無法真正的縮短執行效率。
只做到了自動執行，但沒有做到自動驗證，無法真正的在保證質量的提前下，提高執行效率。
“自動化孤島”，缺乏持續性、未引入到流程當中。
“缺乏整體測試用例執行設計”的問題 解決思路
我們在手動執行測試用例時，為了縮短執行時間，避免某些操作的重復執行，通常，我們會先設計執行場景，一個場景下，盡可能根據執行順序，覆蓋更多的測試用例。
比如，結合上述業務流程Demo,我們需要自動化測試覆蓋所有功能服務接口，我們的會怎樣設計測試用例？從單接口的角度還是場景的角度？
對于這種包含業務流程或是用戶使用場景的功能測試分析，建議從場景的角度去覆蓋，通過場景的流程分解，逐步拆分，然后對拆分后的流程環節進行測試分析，提取測試點。
最后，根據流程串聯各個環節的測試點，最大程度地復用流程，降低測試覆蓋過程的重復性操作，以覆蓋一個場景為最小有效單位。例如，1-2-4-5-7, 1-3-6-7 。
假如，我們在自動化覆蓋的時候，不按照場景的方式，單個接口逐一覆蓋，此時若“關注商品”暫時沒有進行覆蓋，還是采用手動執行的方式驗證該功能，單從自動化覆蓋率、用例數量等指標看，與場景的方式無異。但在實際手動執行時，會發現在有意或無意地在操作自動化已經覆蓋的“查詢商品”等功能，那么從提效的角度來看，手動執行自動化已經覆蓋的測試點，相當于自動化的提效作用被抵消。
因此，無論我們在冒煙測試、回歸測試的用例設計中，盡可能保障覆蓋功能點在操作上的閉環，以覆蓋一個場景為最小有效單位，這個場景的定義就是連續性操作的閉環，可能是N個功能、也可能是一個功能。
只做到了自動執行，但沒有做到自動驗證
翻閱平臺的自動化用例，不乏只有驗證響應狀態的用例出現，也許是在手動測試的時候，只是關注了下狀態，剩余的一掃而過。
一條嚴謹有效的測試用例，需要對響應內容全面覆蓋，考慮到響應內容可能存在一些非冪等性的屬性，比如當前時間，目前提供的關鍵字中，也靈活的支持過濾掉哪些屬性不校驗的功能。
避免在提升效率的過程中，忽略了質量的基本要求。這也是今年自動化平臺需要延展的功能—— 測試用例設計風險預警。
“自動化孤島”，缺乏持續性、未引入到流程當中。
這個大家應該都明白，那就是引入到持續集成中，是最直接、有效的解決方法。
同時，在流程中的提測環節、在系統集成前，做好自動化測試通過率、代碼覆蓋率的卡點。
最后
自動化測試，起初的定義是用于回歸測試等操作具備重復性，且對象具備穩定的場景中，主要考慮到功能的穩定性和投入成本的問題，前期項目功能變更的風險較高、同時周期往往緊張，自動化覆蓋存在一定的開發、維護成本。
這其中的主要矛盾是“成本問題”，試想自動化覆蓋成本在不斷降低時，矛盾在逐漸弱化，那么這個局限性就會被打破。自動化測試同樣可以用于首輪測試、甚至是在與研發功能設計有良好的契約下，在提測前也可以完成。
上述，我們在探討自動化測試如何做到有效的效率提升，除此之外，還可以去嘗試結合代碼覆蓋率，不斷提高自動化覆蓋率；結合代碼改動范圍，精準運行對應測試用例，從機器逐漸演變成智能...
看了這篇內容后，堅信以下兩件事，也會對你的自我提升有一定的幫助：
1、點贊，讓更多人能看到，同時你的認可也會鼓勵我創作更多優質內容。
2、要讓自己變得更強：想想，假如你是要在測試這個行業長期做下去，你的工作經驗和測試技術是絕對不夠的，你需要提升，你需要豐富你的技術棧！還等什么！
最后:【可能給你帶來幫助的教程】
這一些資料，對做【軟件測試】的朋友而言應該是較為完整了，這類學習資料也陪伴我走過了最艱難的路程，希望也可以幫助到你！萬事要盡早，尤其是技術行業，一定要提升技術功底。
