2020年軟件測試趨勢報道：徹底實現持續測試（上）

看到國內外不少機構在總結：“2020年最好的持續測試工具”，比如：

https://www.softwaretestinghelp.com/contin...
https://www.katalon.com/resources-center/b...

還有的機構或公司試圖給出“什么是持續測試？”的定義，比如：

https://www.guru99.com/continuous-testing....
https://www.tricentis.com/products/what-is...

這說明，隨著敏捷開發和devops的推廣，持續測試這個概念確實越來越火。但同時也發現大家對于持續測試的理解并不一致，列舉的持續測試工具也五花八門。因此覺得有必要講一講“持續測試”這一2020年重要趨勢。

什么是持續測試？

持續測試的概念有廣義和狹義兩種理解。廣義上來說，持續交付是敏捷開發、DevOps的目標，為了實現這一目標，軟件測試就要盡早測、按需測、頻繁測，這體現的是軟件測試在敏捷和DevOps中采取的測試策略。持續測試就是從產品發布計劃開始，直到交付、運維，測試融于其中、并與開發形影不離，隨時暴露出產品的質量風險，隨時了解產品質量狀態，從而滿足持續交付對測試、質量管理所提出的新要求。從這個角度上來說，敏捷、DevOps中的一切測試活動都可以算成是持續測試，既包括測試左移，也包括測試右移；既包括持續集成中的測試活動，也包括持續集成之后、上線部署前的測試活動；既包括測試分析和設計，也包括測試執行和結果呈現/報告。

圖1 敏捷、DevOps的目標：持續交付

狹義的持續測試指的是一次軟件迭代開發中的主要測試活動，測試之所以會成為持續交付的瓶頸，就是因為沒能做到持續測試。設計評審、單元測試、用戶故事實現的驗證、集成測試等，也包含持續的新功能測試和持續的回歸測試，以及性能測試、安全性測試、兼容性測試等針對軟件質量屬性的專項測試，如圖2所示。

圖2 Scrum 模式下的敏捷測試流程

持續測試不等同于自動化測試，也包括手工測試，比如每次迭代中的新功能的測試采用手工（探索式測試）測試更快，因為人更靈活，更智能。再比如人工的需求評審、設計評審和代碼評審（Code Review）也必不可少，這些測試左移中的測試活動幫助團隊在早期預防缺陷，讓隨后的研發活動更順利。采用自動化的方式盡量提高回歸測試的覆蓋率也非常必要，以手工測試為主肯定不可持續，要么為了趕進度，測試不充分，漏測的缺陷會越來越多，產品質量越來越差，團隊會被技術債慢慢拖垮，越做越慢。要么為了測試充分，就需要大量時間，交付速度會受影響。兩種情況都會讓測試成為敏捷開發的瓶頸。采用自動化回歸測試與手工探索式測試相結合的方式，兩種測試都持續進行，才能達到質效合一。

持續測試不等同于全面測試，即使自動化測試達到很高的覆蓋率，要想在每一個發布的版本上進行全面測試，也是件不可能的事情，首先是軟件測試無法窮盡每條業務路徑，其次也沒有必要，要想做得既快又好，不僅要做加法：盡可能提高自動化測試覆蓋率，讓測試左移，盡可能提高單元測試、API測試的覆蓋率，更要做減法，擁抱基于風險的測試策略，精準測試就是一個好例子，基于對代碼變更的分析和其它信息，選擇正確的測試范圍，既不多測，也不少測。

持續測試不等同于持續測試工具化，持續測試需要優秀的測試工具鏈的支持，這個我們稍后會講，但持續測試不能只靠工具來實現，更重要的是如何從道、法、術、器各個層面讓持續交付變得無障礙。比如開發和測試的徹底融合，讓溝通協作變得無障礙；比如奧地利的軟件測試公司Tricentis提出的基于業務風險的測試分析方法，對產品需求根據業務風險進行量化，排序；再比如，我們可以運用各種測試設計方法以更少的測試用例覆蓋更多業務風險。

持續測試是敏捷化、DevOps化的需要

和持續集成、持續部署、持續運維一樣，持續測試同樣是保證企業面向敏捷和DevOps轉型成功的關鍵因素。敏捷開發和DevOps的目標是實現持續交付，而只有實現持續測試才可能實現持續交付。敏捷開發中的一切測試活動都屬于持續測試，甚至可以說，敏捷測試就是持續測試。

在持續交付流水線中，相比持續集成、持續部署等，持續測試的建設相對落后，這也是為什么大家認為軟件測試是影響持續交付主要瓶頸。持續測試作為一個主題在國內被討論的還不多，但是在國外已經成為促進敏捷和DevOps轉型的焦點之一。展望軟件測試的未來，持續測試必定是未來幾年里最具確定性的趨勢之一。

要說起來，持續測試也不是一個新的概念，只是目前所能實現的持續測試和理想中的持續測試還有一定差距，僅僅是測試自動化一項在實踐中就碰到很多問題，很多時候想快也快不起來，想連續也連續不起來，很多節點還需要靠手工完成，以便接續上后面的任務。因此，大家更加期待在不久的將來能夠實現真正的、徹底的持續測試。

持續測試工具鏈

持續測試工具鏈的作用是支持測試過程能夠平滑有序的進行，不僅支持各種類型的測試，而且針對對測試全過程的支持，充分體現測試的服務化，讓測試想測就測、有始有終，過程無障礙。

持續測試對測試工具的需求包含三個層次：

• 首先，測試工具可以支持各種類型（功能、性能、安全性…）的自動化測試。
• 其次，從測試用例創建、測試執行到結果分析、測試報告生成，測試工具向著平臺化的方向發展，將自動化擴展到整個測試生命周期，并且提供功能、性能測試服務或提供與這類工具的集成，即持續測試平臺。
• 第三，測試工具或平臺與DevOps工具鏈進行集成，這樣才能實現和持續構建、持續集成、持續部署融為一體的持續測試。

這樣來說，持續測試工具包含的范圍很廣，只要符合這三個層次的任何一個都可以稱為持續測試工具。甚至DevOps工具鏈中和測試相關的工具/框架都可以算是持續測試工具。這也是為什么有人認為Jenkins、Jira、Docker這些工具也是DevOps的持續測試工具。

用單一的工具/平臺支持所有的測試類型，全生命周期管理非常困難，我們應該關注的不是哪一個測試工具是持續測試工具，而是應該關注在持續測試工具鏈里有哪些優秀的測試工具。同時，測試工具本身也逐漸擴展到平臺化、DevOps化，這也是測試工具目前的趨勢。

下面就來列舉一些測試工具中所包含的促進持續測試的趨勢和優秀實踐：

先說說持續測試工具。API（接口測試）工具代替UI自動化測試工具成為焦點。對于有條件采用API或接口測試的產品和團隊，應該多開展接口測試，不僅覆蓋單個接口的測試，還覆蓋系統端到端的功能測試、性能測試。目前有的測試工具致力于針對API測試提供更完善的支持，為了完成API測試，我們常常需要使用Postman進行接口調試，使用WireMock等Mock工具來模擬接口響應數據，使用像Karate、Jmeter這類測試工具做接口自動化測試。這樣就需要維護不同的工具，而且工具之間維護數據一致性的工作量也比較大。

這里介紹下API Fortress，這個工具（其實也是一個測試平臺，這里只介紹其對于API測試的支持）對于微服務架構的軟件系統提供了接口測試的持續測試解決方案。我們來看一下它提供了哪些功能，同時又怎樣解決了當前自動化測試的上述痛點：

• 無代碼化的自動化測試，從Web UI界面點擊操作、規范文檔或錄制的流量中自動創建API功能測試的測試腳本。
• 可以支持API的各種測試類型，包括單個API的功能測試，壓力測試，性能測試，以及API性能監控。
• 在研發早期通過自帶的Mock功能隔離不穩定的API依賴對象對API進行測試。
• 支持和多種CI/CD工具以及測試管理工具的集成，比如Jenkins、GitLab、axway（API管理工具）、Zephyr（測試用例管理工具）、Jira等。

即使是UI自動化測試工具，很多UI測試工具也致力于提供模塊化、無代碼化的自動化測試，并且也開始把自身功能擴展到API測試。

再說說持續測試平臺。測試管理平臺中有一些被定位為持續測試平臺，這里列舉兩個，

• 一個是國內飛致云公司的開源持續測試平臺MeterSphere，覆蓋測試用例管理、測試計劃到測試執行、測試報告分析等；支持接口的自動化測試，兼容JMeter支持分布式性能測試。

• 一個是Tricentis公司開發的持續測試平臺Tricentis Tosca。Tricentis 公司的測試自動化產品在Gartner 魔力四象限（Magic Quadrant）中處于“LEADERS”的位置，如圖3所示。

圖3 測試自動化產品的Gartner 魔力四象限

Tricentis Tosca支持以下功能：

• 支持基于模型的UI和API自動化測試
• 支持服務虛擬化：通過模擬第三方系統組件為自動化測試創造一個穩定的測試環境，并且覆蓋更多的異常測試場景
• 支持基于風險的測試需求分析，這是這個平臺最具亮點之處。簡單來說，用戶可以在平臺界面上為每個產品需求（Epic、用戶故事）從兩個維度（用戶使用頻率和失效后的影響）進行評分，然后根據評分計算每個需求的風險權重和風險貢獻率。這會作為進一步進行測試用例設計，優化測試覆蓋率，按照風險權重確定測試優先級，以及評估測試結果進行軟件發布決策的基礎。

接：2020年軟件測試趨勢報道：徹底實現持續測試（中）