logo头像

Edward.K Thinking

(學習DevOps系列 8) 在DevOps的測試模式

現代的軟體開發已經轉向採用快速發布的週期方式來發布產品,往往以前那種每三年或是四年發布一次版本的日子已經不存在了。尤其,在製造業中基本根本不可能有超過兩三個月才把系統交付出去的情況。現在開發人員往往被要求對於用戶的反饋要有迅速的反應,同時也要能迅速發布新的功能,另外,發布頻率也要縮短。也因此開發人員面臨不斷迭代軟體的挑戰外,還要確保系統能夠滿足高品質標準。一般來說如果想要能維持持續發布的頻率,同時又要維持品質的情況下,使用自動化測試是一個不錯的方式。


理論上自動化測試有助於開發人員提早進行測試,以確保程式的品質,並做出正確決策是否要發布產品或是系統。而進行自動化測試,必須以正確方式在正確時間點完成。不過,實務上卻不一定如此,每個團隊或組織其實因該要針對本身文化與風險接受度,擬定測試模式再而進行自動化。如何在測試與商業需求完成時間達到到平衡是很重要

自動化測試價值


做自動化測試的好處有幾點

  • 即時且快速得到反饋
    自動化測試可以替開發人員快速且即時的提供反饋,藉由這樣方式提高品質
  • 加快軟體交付速度
    自動化測試與持續交付的節奏互相搭配,手動測試方式是無法跟上DevOps持續交付的速度,手動測試會是速度上的一個瓶頸點
  • 降低成本
    自動化測試會大幅降低成本,尤其是人力成本

對於DevOps來說,持續整合和持續交付是整體的基礎,而在每個過程中的自動化單元測試都會算是持續整合的一部分

  • 可靠性
    自動化測試讓在DevOps這種快節奏發布的流程中,提供開發者對應用程式的信心度
  • 重複性
    只寫一次測試程式,然後透過不同配置或環境進行測試
  • 測試結構
    理論上為了達到早期的測試和頻繁測試,就會建立一組適合自己團隊的測試結構,來達到提升軟體品質的目標

向右移動(Shifting Right)和向左移動(Shifting Left)


為了把DevOps和測試串聯在一起,設計測試左移和測試右移的策略是重要的,這些往往不僅只是包含測試,同時,也涵蓋整個開發週期。

Shifting Right

如果今日我們把軟體開發生命週期流程當作是一系列從左到右的事件發生。在一些流程中,把測試和安全性等重要項目移置要發布前,才測試出有安全性問題或是bug,這時候就會太晚

Shifting Left

DevOps關鍵之一就是持續與主動,這意味要提前設計、監視和識別問題。提早修復Bug,這種概念就叫做向左移動。

在DevOps理論中,大多數是要關注於MTTR(平均修復時間),而使用監控和自動化測試,並非優化測試,和獲得最小化的MTBF(平均故障時間),而是要縮短MTTR。也因此,在DevOps會觀察到,很多時候的導致錯誤而更改次數會較高,但是MTTR會較低。當然停機成本也會較低,換一個角度想,就是每次小量錯誤的修改,一定比累積到一個大錯誤修改來的時間還短暫。因此,眾多成功執行DevOps的公司,相較來說比較部會注重MTBF

持續測試


在持續測試中,有下列幾個測試類型,理論上每個測試都因該被實作,但就實務來說,如同前面所提到,依照整體商業價值和風險承受度訂定適合的測試模式將會是更重要。

  • Unit tests
    可以被自動化,是所有測試中,最為簡單的一種,可以在系統中測試某一個功能或是方法,所以,單元測試可以針對方法或功能進行一種可靠性驗證
  • Integration tests
    以多種方式將兩個或是多個以上互相依賴的模組或元件合為一組進行驗證。簡單說就是把現有功能整合其他功能後,還是可以正常運作
  • Automated UI tests
    通過使用者介面進行自動化測試,在測試過程中會包含方法和元件,當然也包含了UI測試
  • Performance tests 和 load tests
    效能測試,驗證系統反應速度,吞吐量,可靠性和穩定性。負載測試要求系統在不同負載量下依舊可以維持正常行為,確定瓶頸並驗證預期性能。
  • Manual acceptance 和 exploratory tests
    手動驗收與測試,驗證功能是否符合商業要求或規格。探索性測試是讓測試人員透過本身的經歷和創造力來驗證品質、可用性、性能、體驗和其他指標。
上一篇