持續測試 | 讓測試更自由：在 CODING 中實踐自動化執行用例

本文做者：程勝聰 - CODING 產品經理

自動化測試是持續測試的基礎

在 DevOps 的高頻交付場景下，團隊容易陷入在速度和質量之間「二選一」的困境：爲了擁抱需求變動，採用較短的交付週期，而後變動頻繁致使問題變多，因而開發提測延遲，最後致使測試時間被壓縮、難以進行充分的測試。面對這樣的狀況，團隊該如何提高測試的執行效率呢？你們第一個會想到的應該就是自動化測試——經過自動化測試來替代重複性的手工測試，執行更快從而節省測試時間。此外，因爲自動化每次執行時間相對固定，並且程序預設的測試行爲帶來了高一致性，讓測試的穩定性和可重複性達到很高的標準，可以很好的實現「快速重現軟件缺陷」的目標。

若是說在測試時間相對充足的傳統瀑布模式下，針對迴歸測試場景而投入的自動化測試所體現的最大價值是在節約人力成本方面，那麼在敏捷和 DevOps 時代，自動化測試的更大價值則體如今頻繁驗證而且提供快速反饋方面。能夠說持續測試實踐的基礎就是自動化測試，只有自動化程度足夠高，纔可以知足持續交付的高頻發版需求。

自動化測試策略

自動化測試有很重要的價值，但不表示咱們應該無限制投入到各類類型的自動化測試當中。自動化測試是爲了驗證既定邏輯是否符合預期，在需求變動頻繁的場景下，自動化代碼的維護成本巨大。因此，咱們須要合適的策略來指引自動化的實現——金字塔模型。

出自《The Test Automation Pyramid: Your essential guide for test automation》

自動化測試金字塔最先由 Mike Cohn 於 2009 年在《Succeeding with Agile: Software Development using Scrum》中提出，當時從上到下的三層分別是 UI、Service 和 Unit。以後隨着敏捷測試實踐的落地，業內逐漸造成的認知是從上到下分別爲用戶界面測試（UI Tests）、接口集成測試（API Tests）、單元測試（Unit Tests），再加上頂部的手動探索性測試，進一步豐富爲測試金字塔（包括自動化和手工）。這個上窄下寬的三角形爲咱們在各層的自動化投入提供了形象的指引：底層的單元測試最多，接口測試居中，UI 測試最少。

如金字塔模型所示，下層的單元測試/接口測試比起上層的 UI 測試優勢有：因爲更接近生產代碼因此更容易編寫並定位到代碼的缺陷；因爲測試對象的粒度更小、依賴更少，因此執行效率更高；因爲測試對象更加穩定因此維護的成本更低等等，固然越接近上層的測試的優勢就在於，由於更加反映業務需求，因此更容易讓人看到測試的價值。那麼在 DevOps 時代，基於對速度和質量的平衡，中間層的接口集成測試由於既能保持相對低的維護成本，又能兼具反映業務邏輯的價值，應該成爲咱們重點投入的部分，尤爲是在自動化各方面還處於初級階段的時候。

測試金字塔發源于敏捷實踐，以之做爲參考對咱們的自動化測試投入進行持續的調整，團隊的測試用例和執行情況就會逐步造成良好的平衡。

精準測試的價值

雖然從近幾年行業的調查報告能夠看出，隨着對 DevOps 的承認，企業對自動化測試的投入在持續提高，帶來的直接結果就是自動化測試的代碼愈來愈多。可是有了數量快速增長的自動化代碼，自動化就能達到咱們預期的效果嗎？

從現實效果來看，企業並無因爲自動化測試覆蓋率的提高而得到預期中的價值，由於自動化代碼的執行並無咱們想象中的那麼「自由」，每每在於兩方面的緣由：

1. 通常團隊會把自動化代碼執行看成 CI 的一個環節，也只是被做爲迴歸場景使用，可是全量回歸的耗時過長限制了執行的頻率不會過高；
2. 搭建流水線和在這基礎上搭配相應的工具仍是存在技術門檻，再加上這些操做自己須要的工做量，也致使了難以作到每一個人都能隨時執行自動化測試。

這就致使隨着自動化覆蓋率的提高，迴歸測試的執行時間反而變得愈來愈長，因而自動化測試的執行頻率只能下降，最後自動化代碼的價值受到質疑。其實除了提高自動化覆蓋率以外，咱們還須要改變「每次測試執行覆蓋的用例越多越好」的理念：咱們不該該由於「不放心」而讓測試集變得過度冗餘，而是須要基於業務風險優化測試覆蓋範圍，以期在有限的範圍內實現較高的測試投入產出比，實現精準測試。

CODING 讓測試執行更加自由

爲了讓測試執行更加「自由」，CODING 打造了雲端自動化執行的能力，指望解決自動化測試的「最後一千米」問題，從而實現：

1. 每次執行都有靈活選擇用例子集的自由；
2. 全部人都擁有執行測試的自由。

接下來，讓咱們看看如何在 CODING 測試管理實現「自由」地執行測試：

1. 首先，在 CODING 自動化用例庫中進行自動化代碼登記，肯定自動化代碼已經存在於代碼託管中，對已經存在的自動化代碼庫進行登記，並設置相關的語言/框架。

2. 解析自動化代碼庫的測試函數列表，並創建用例管理中的功能用例與自動化函數的匹配關係，得出自動化覆蓋率。經過匹配自動化代碼和功能用例，能夠幫助咱們對自動化代碼產生的價值創建直觀感覺，作到「內心有數」。

3. 建立執行方式爲自動化執行的測試計劃，圈選用例。

選取適合的自動化測試子集是須要業務測試知識的，而執行固定範圍的全迴歸測試耗時過長，或者反覆機械性執行冒煙測試並不能及時反映新需求的測試狀況，這是自動化測試覆蓋率的提高以後仍然未能達到預期中的價值的緣由。CODING 提供按需圈選測試子集的方式來建立測試計劃，精準執行相關的自動化代碼子集、快速反饋結果，從而解除了自動化運行時長的顧慮，讓團隊努力生產的自動化代碼價值獲得最大化。

4. 執行該測試計劃，已經匹配上的自動化用例在後臺執行並更新對應功能用例的執行結果。自動化執行完畢後，能夠對未測或者未經過的用例進行手工驗證、並更新用例任務狀態。

5. 點擊生成測試報告，系統將自動根據採集到的數據進行質量分析和評價。測試可追溯讓測試報告更使人信服，幫助團隊將風險控制到較低水平。