接口用例之好用例和壞用例

　　自動化測試的重要性顯而易見，但自動化測試又沒法解決全部問題，因此說徹底依賴自動化是不可能的，但徹底沒有自動化是萬萬不能。在軟件開發項目中，重度依賴人力進行持續迴歸是一件很是枯燥的重複工做。企業須要花費大量的時間和金錢來維持這樣一支隊伍以保證產品質量，而隊伍中的同窗在天天重複勞動的工做之下，也絲毫得不到成長，看不到方向。
　　儘管自動化測試不能解決全部問題，可是卻擁有一個優點：「Once」 Written, Run Anytime as Desired（一旦寫好，便可隨意重複執行）。因此，自動化測試一般都會跟持續集成系統（好比Jenkins）配合使用，就像「良辰美景」要配上「月光杯」纔算的上是極致。這樣咱們能夠避免在軟件上線或交付的最後一刻，還深陷軟件問題的泥潭中。固然，這也是敏捷開發的關鍵所在，把問題消滅在過程當中，只需持續關注增量內容。另外，在持續集成中，能夠根據本身的需求來肯定自動化測試的觸發頻次和時間，好比「代碼提交」、「定時觸發」等。
　　萬物皆有陰陽兩面，自動化測試有這麼多優點，固然也有它的劣勢。因此，至今仍然有不少公司自動化水平不高。咱們分析一下這些劣勢，主要有如下幾方面：
對測試人員要求相對較高。
　　測試用例須要根據版本迭代進行更新，有必定維護成本。
　　測試結果不必定可靠，測試用例也分「好」、「壞」。

　　前面兩點也是你們公知的問題，每一個公司各有本身的狀況判斷，今天也不作贅述。今天我主要討論第三個問題，也就是：怎麼保證咱們花了時間和精力去作的自動化測試，其結果是有效的、是可以反映被測代碼質量的？

1、 測試用例也分好壞

　　對於標題，你可能會有疑問，測試用例居然也有好壞？的確，測試用例也有好壞之分，那麼什麼是壞用例？什麼是好用例？那要先從測試用例的特徵提及：
自動化測試或者測試用例的根本目的就是judge（判斷）被測系統是否有問題，是以衡量被測產品的「標尺」存在的。因此，它具有一個重要的特徵：在測試腳本和被測代碼都保持不變的狀況下，測試結果應該是穩定的、不變的。
根據這個原則，「壞用例」並非指測試不經過的用例，更不是測試經過的用例，而是指那些在相同條件下，偶爾經過、偶爾不經過的測試用例。反之，「好用例」則是表現穩定的用例。
　　爲何說「壞用例」破壞性大？由於若是用例自己不具有穩定的結果輸出，就沒法準確的衡量被測產品是代碼的問題仍是用例自己的問題。若是每次測試結果都不能直接說明問題，須要進行反覆分析，將直接致使你們對測試用例失去信心。也就是說，測試同窗和開發同窗會把測試用例的不經過，當成「Warning」而非「Error」,這樣的最終效果就是自動化測試慢慢被拋棄。

2、 測試用例的生命週期

　　有了「好用例」、「壞用例」的區分，測試用例就是「鮮活」的了。事實上，咱們也能夠規劃處一個測試用例從生到死的生命週期。

　　通常狀況下，咱們能夠以測試用例經過率或經過次數來爲其劃分「好/壞」。隨着執行次數的增多，測試用例能夠切換「好/壞」狀態，當「壞用例」持續一段時間以後，咱們能夠把它標記爲「垃圾用例」，並從自動化執行的序列中剔除。「壞用例」和「垃圾用例」能夠被開發或者測試同窗修復，而後進入「未知狀態」。「未知狀態」中的應用隨着執行次數的增長，不斷的在這個生命週期裏循環往復。

3、 如何消滅壞用例

　　至此，咱們明白了測試用例的「好/壞」之分，也瞭解了測試用例的生命週期。那麼，咱們如何保證用例質量，「消滅壞用例」呢？

　　1，經過「CI」（Continuous Integration持續集成）發現「壞用例」
　　「壞用例」指的是偶爾不經過、偶爾經過的用例。因此，你會發如今本地運行的時候很難發現「壞用例」，由於「壞用例」須要被執行不少次才能被檢測出來。執行不少次的過程能夠很是好地經過CI系統來幫助實現，因此，若是你尚未使用CI系統，也依然建議使用持續集成工具進行屢次的執行用例，即使你的工程量很小。另一點，CI系統能夠在一天不一樣的時刻執行用例，而時間也是一個「壞用例」產生的可能屬性。
固然，成熟的CI系統（好比Jenkins）均可以知足絕大部分人的業務需求

　　2，防微杜漸
　　可能你們都聽過「破窗理論」：當房子上的一扇窗戶的玻璃被打破，若是不及時修復，將會有破壞者破壞更多的窗戶。「壞用例」現象也是同樣的，當出現一個「壞用例」時，若是不抓緊修復，整個測試用例集甚至自動化測試結果的可信度都將快速下滑。
對「壞用例」採起零容忍的態度，有助於總體自動化水平和質量的提高。能夠創建測試或開發人員「壞用例」檔案，並自動追蹤每個「壞用例」的來源，督促負責人跟進解決。

　　3，避免執行環境差別
　　例如，保證本地用例執行時的環境與CI執行用例環境是一致的。

　　4，使用異步等待
　　一般，一個測試用例多個測試步驟組合而成，每個測試步驟都須要特定的執行時間，因此，你們寫測試用例通常的作法就是等待特定的時長，好比5秒。可是相同的測試步驟在每次用例執行過程當中的時長並不相同，而且有時差別還會很大。這每每會致使上一步還未完成，下一步就開始執行，致使「壞用例」的產生。
另外，即使是步驟執行沒有超時，但依然可能形成時間上的浪費，好比一個步驟等待5s，但實際執行只用了2s，就有3s的時間浪費。
理論上，解決這個問題有兩種方式：回調、輪詢。回調是指，上一步執行完成後，通知執行測試用例的進程/線程繼續下一步。但這種方式在實際中並不採用，由於它須要緊耦合被測系統，可能爲被測系統帶來新的問題和維護成本。因此，實際中，更多的採用的是以「觀察者」身份存在的輪詢。好比說，以很小的時間間隔來不斷查詢是否到達下一步執行的狀態。這樣就可以避免必定程度的「壞用例」的產生。

　　5，解決並行執行的問題
　　若是測試用例存在並行執行的狀況，請確保多個測試用例之間不會由於相互對被測系統的影響致使衝突，從而使用例變成「壞用例」。好比，在全部測試用例執行過程當中，數據庫相關操做都採起事務的方式，用例執行完成後，就當即進行回滾。

　　6，避免測試用例互相依賴
　　若是一個用例集中的測試用例時相互依賴的，那若是其中有一個「壞用例」出現，將會致使整個用例集不穩定。因此，儘可能保證用例集中的每個用例沒有相互依賴關係，每個均可以獨立執行驗證。

　　7，避免測試腳本太長
毫無疑問，一個測試用例的步驟越多，可能變成「壞用例」的機率越高，因此，通常狀況下，一個App的測試用例不超過在30步最好。

　　8，提升測試用例代碼水平
一個「好用例」除告終果足夠穩定以外，還須要具有良好的結構設計，以及良好的可讀性、可維護性。這一點對測試用例編寫人員要求較高，固然，經過多讀、多思、多寫，可以很快的提升本身的自動化用例編寫能力。

本文轉自：https://testerhome.com/topics/5921，做者：vividly