摘要： 自動化測試的重要性顯而易見，但自動化測試又無法解決所有問題，所以說完全依賴自動化是不可能的，但完全沒有自動化是萬萬不能。在軟件開發項目中，重度依賴人力進行持續回歸是一件非常枯燥的重復工作。企業需要花費大量的時間和金錢來維持這樣一支隊伍以保證產品質量，而隊伍中的同學在每天重復勞動的工作之下，也絲毫得不到成長，看不到方向。

自動化測試的重要性顯而易見，但自動化測試又無法解決所有問題，所以說完全依賴自動化是不可能的，但完全沒有自動化是萬萬不能。在軟件開發項目中，重度依賴人力進行持續回歸是一件非常枯燥的重復工作。企業需要花費大量的時間和金錢來維持這樣一支隊伍以保證產品質量，而隊伍中的同學在每天重復勞動的工作之下，也絲毫得不到成長，看不到方向。

盡管自動化測試不能解決所有問題，但是卻擁有一個優勢：“Once” Written, Run Anytime as Desired（一旦寫好，即可隨意重復執行）。所以，自動化測試通常都會跟持續集成系統（比如Jenkins）配合使用，就像“良辰美景”要配上“月光杯”才算的上是極致。這樣我們可以避免在軟件上線或交付的最后一刻，還深陷軟件問題的泥潭中。當然，這也是敏捷開發的關鍵所在，把問題消滅在過程中，只需持續關注增量內容。另外，在持續集成中，可以根據自己的需求來確定自動化測試的觸發頻次和時間，比如“代碼提交”、“定時觸發”等。

萬物皆有陰陽兩面，自動化測試有這么多優勢，當然也有它的劣勢。所以，至今仍然有很多公司自動化水平不高。我們分析一下這些劣勢，主要有以下幾方面：
　　1.對測試人員要求相對較高。
　　2.測試用例需要根據版本迭代進行更新，有一定維護成本。
　　3.測試結果不一定可靠，測試用例也分“好”、“壞”。

前面兩點也是大家公知的問題，每個公司各有自己的情況判斷，今天也不做贅述。今天我主要討論第三個問題，也就是：怎么保證我們花了時間和精力去做的自動化測試，其結果是有效的、是能夠反映被測代碼質量的？

一、測試用例也分好壞

　　
對于標題，你可能會有疑問，測試用例竟然也有好壞？的確，測試用例也有好壞之分，那么什么是壞用例？什么是好用例？那要先從測試用例的特征說起：

自動化測試或者測試用例的根本目的就是judge（判斷）被測系統是否有問題，是以衡量被測產品的“標尺”存在的。所以，它具備一個重要的特征：在測試腳本和被測代碼都保持不變的情況下，測試結果應該是穩定的、不變的。

根據這個原則，“壞用例”并不是指測試不通過的用例，更不是測試通過的用例，而是指那些在相同條件下，偶爾通過、偶爾不通過的測試用例。反之，“好用例”則是表現穩定的用例。
　　
為什么說“壞用例”破壞性大？因為如果用例本身不具備穩定的結果輸出，就無法準確的衡量被測產品是代碼的問題還是用例本身的問題。如果每次測試結果都不能直接說明問題，需要進行反復分析，將直接導致大家對測試用例失去信心。也就是說，測試同學和開發同學會把測試用例的不通過，當成“Warning”而非“Error”,這樣的最終效果就是自動化測試慢慢被拋棄。

二、測試用例的生命周期

有了“好用例”、“壞用例”的區分，測試用例就是“鮮活”的了。事實上，我們也可以規劃處一個測試用例從生到死的生命周期。

一般情況下，我們可以以測試用例通過率或通過次數來為其劃分“好/壞”。隨著執行次數的增多，測試用例可以切換“好/壞”狀態，當“壞用例”持續一段時間之后，我們可以把它標記為“垃圾用例”，并從自動化執行的序列中剔除。“壞用例”和“垃圾用例”可以被開發或者測試同學修復，然后進入“未知狀態”。“未知狀態”中的應用隨著執行次數的增加，不斷的在這個生命周期里循環往復。

三、 如何消滅壞用例

至此，我們明白了測試用例的“好/壞”之分，也了解了測試用例的生命周期。
那么，我們如何保證用例質量，“消滅壞用例”呢？

1，通過“CI”（Continuous Integration持續集成）發現“壞用例”

“壞用例”指的是偶爾不通過、偶爾通過的用例。所以，你會發現在本地運行的時候很難發現“壞用例”，因為“壞用例”需要被執行很多次才能被檢測出來。執行很多次的過程可以非常好地通過CI系統來幫助實現，所以，如果你還沒有使用CI系統，也依然建議使用持續集成工具進行多次的執行用例，即便你的工程量很小。另外一點，CI系統可以在一天不同的時刻執行用例，而時間也是一個“壞用例”產生的可能屬性。

當然，成熟的CI系統（比如Jenkins）都可以滿足絕大部分人的業務需求

2，防微杜漸

可能大家都聽過“破窗理論”：當房子上的一扇窗戶的玻璃被打破，如果不及時修復，將會有破壞者破壞更多的窗戶。“壞用例”現象也是一樣的，當出現一個“壞用例”時，如果不抓緊修復，整個測試用例集甚至自動化測試結果的可信度都將快速下滑。
　　
對“壞用例”采取零容忍的態度，有助于整體自動化水平和質量的提升。可以建立測試或開發人員“壞用例”檔案，并自動追蹤每一個“壞用例”的來源，督促負責人跟進解決。

3，避免執行環境差異

4，使用異步等待　　

通常，一個測試用例多個測試步驟組合而成，每一個測試步驟都需要特定的執行時間，所以，大家寫測試用例一般的做法就是等待特定的時長，比如5秒。但是相同的測試步驟在每次用例執行過程中的時長并不相同，并且有時差異還會很大。這往往會導致上一步還未完成，下一步就開始執行，導致“壞用例”的產生。　　
另外，即便是步驟執行沒有超時，但依然可能造成時間上的浪費，比如一個步驟等待5s，但實際執行只用了2s，就有3s的時間浪費。　　
理論上，解決這個問題有兩種方式：回調、輪詢。回調是指，上一步執行完成后，通知執行測試用例的進程/線程繼續下一步。但這種方式在實際中并不采用，因為它需要緊耦合被測系統，可能為被測系統帶來新的問題和維護成本。所以，實際中，更多的采用的是以“觀察者”身份存在的輪詢。比如說，以很小的時間間隔來不斷查詢是否到達下一步執行的狀態。這樣就能夠避免一定程度的“壞用例”的產生。

5，解決并行執行的問題　　

如果測試用例存在并行執行的情況，請確保多個測試用例之間不會因為相互對被測系統的影響導致沖突，從而使用例變成“壞用例”。比如，在所有測試用例執行過程中，數據庫相關操作都采取事務的方式，用例執行完成后，就立即進行回滾。

6，避免測試用例互相依賴　　

如果一個用例集中的測試用例時相互依賴的，那如果其中有一個“壞用例”出現，將會導致整個用例集不穩定。所以，盡量保證用例集中的每一個用例沒有相互依賴關系，每一個都可以獨立執行驗證。

7，避免測試腳本太長　　

毫無疑問，一個測試用例的步驟越多，可能變成“壞用例”的概率越高，所以，一般情況下，一個App的測試用例不超過在30步最好。

8，提高測試用例代碼水平　　

一個“好用例”除了結果足夠穩定之外，還需要具備良好的結構設計，以及良好的可讀性、可維護性。這一點對測試用例編寫人員要求較高，當然，通過多讀、多思、多寫，能夠很快的提高自己的自動化用例編寫能力。

四、 MQC讓測試用例“轉”起來　　

“壞用例”的產生跟被測應用、編寫方法、測試環境等，都有非常大的關系，很難找到一個“all in one”的解決方案。但是，只要我們認真分析解決就可以讓所有測試用例達到都是“好用例”這個狀態。接下來，需要做的就是大家共同維護好這樣一個最佳狀態，避免“破窗理論”的發生。
　　
在解決“壞用例”這個問題上，阿里云測MQC提出并實施了眾多有效方案，例如，對于未通過的用例，增加N次重跑，避免“壞用例”的產生；比如“在線錄制”可以幫助用戶短時間內獲得穩定性和兼容性都很高的測試用例；比如“用例管理”可以跟蹤所有測試用例的通過率及通過次數，及早發現和處置“壞用例”；再比如，阿里云測MQC還提供了“Jenkins插件，讓大家無需關心硬件資源等問題，方便大家將MQC云上的服務添加到自己的持續集成流程中來，真正做到“Once Written, Run Anytime”。這也是為什么只有在MQC平臺上，測試用例才能真正“流轉”起來。

總結

以上是生活随笔為你收集整理的自动化测试 之 “好用例、坏用例”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。