2020年軟件測試趨勢報道：徹底實現持續測試（中）
2020年軟件測試趨勢報道：徹底實現持續測試（上），介紹了什么是持續測試和持續測試工具鏈。這一篇側重介紹持續測試的實現框架，這或許是大家更為關心，基于實現框架，持續測試才能落地。
在介紹持續測試的實現框架之前，交待一下“什么是持續測試”，它具有下列三個特點：
測試可以隨時開展起來，且具有連續性，平滑有序地打通整個測試過程，從測試左移到測試右移，從單元測試到端到端的系統測試，從靜態測試到動態測試，從測試分析到測試報告
測試和開發、運維能很好地融合、匹配和同步起來，**打通整個DevOps過程，讓測試融合到DevOps的各個環節**，融入到DevOps的整個基礎設施，相互促進，最終能夠實現徹底的持續交付
以最少的測試、最快的速度覆蓋交付所面臨的業務風險，整個測試過程要快，不管是研發階段中每個迭代的測試活動，還是產品發布后對于缺陷修復的代碼變更的驗證，有變更，就有驗證，就能夠快速提供驗證結果
之所以特別強調持續測試，是因為軟件測試常常是實現DevOps的最大障礙，軟件測試常常面臨如下問題：
盡管自動化測試已經推行很多年，但在大多數企業中主要的測試方式還是手工測試。
即使在自動化水平較高的組織中，測試人員仍然花費平均17%的工作時間分析由于各種不穩定因素造成的測試結果的誤報，還會花費14%的時間維護自動化腳本。
超過一半的測試人員每周會花費5-15小時準備和管理測試數據。
84%的測試人員都遭遇過因為測試環境的問題而造成的測試任務的延遲。
一套自動化回歸測試集平均需要16.5天執行一遍，但是敏捷開發的一次迭代時間普遍要求是兩周。
一個軟件應用平均要和52個第三方系統組件進行交互，這些第三方系統組件包括其它的微服務和接口，以及各式各樣的移動設備。
實現徹底的持續測試，就是為了解決上述問題，各個擊破，在正確的時間執行正確的測試，該精簡測試范圍的時候給予科學合理的精簡，給決策者提供快速的質量反饋，這一切就依賴持續測試的實現框架。
持續測試實現框架
持續測試的實現框架如圖1所示，分為三個模塊：實現基礎、中間過程、技術手段/方法。實現基礎包括三個方面：測試數據管理、服務虛擬化、和DevOps的集成；中間過程包括基于風險的測試分析和測試影響分析；實現的技術手段和方法包括探索式測試、測試自動化、測試設計方法，總共有8個方面（中篇講4個方面，下篇再講另外4個方面+ 持續測試成熟度）。
圖1 持續測試的實現框架
1. 測試數據管理（TDM）
測試數據的準備和管理是軟件測試中重要的環節，也是自動化測試中的非常重要的環節，系統端到端的自動化回歸測試需要測試數據管理功能的支持。持續測試需要考慮如何縮短測試數據的創建和維護所需要的時間。
有兩種測試數據的主要來源，一種是使用生產數據，但需要對數據進行脫敏，以滿足GDPR（通用數據保護條例，General Data ProtectionRegulation）的要求；另一種是生成需要的測試數據。在測試中常常需要綜合利用兩種方式來滿足不同的測試需要：經過脫敏處理的生產數據可以更快速的覆蓋常見的測試場景，而生成的測試數據可以實現更廣泛的覆蓋范圍，比如一些異常場景需要的數據在生產環境中難以發現，
另外，測試數據管理服務還需要考慮如何隔離測試數據的使用，避免多個測試任務修改測試數據造成的互相干擾；哪些數據可以事先準備，哪些數據需要在測試執行中實時生成。
2. DevOps工具鏈集成
隨著DevOps工具鏈的形成和日益豐富，企業可以選擇各種各樣的工具建設自動化的軟件交付流水線。這些工具的集成和協同越有效，團隊成員的工作和協作就越高效。測試工具與CI系統的集成是將測試活動無縫融合到持續交付流水線的基礎，這也是對于現代測試工具的基本要求。
測試工具應該具備直接集成到CI環境中的能力，或者先連接到一個專門的測試管理平臺，該平臺可以協調測試管理、跟蹤和報告，另外，在需要時利用加速測試執行的技術，如分布式測試執行、故障恢復等，可以幫助團隊在限定的時間內完成更多的測試。
3. 服務虛擬化
服務虛擬化是一種模擬（Mock）技術，即使被測試對象依賴的系統組件（API、第三方應用等）不能被正常訪問，測試也可以自動運行。服務虛擬化的目標是保證測試環境不影響測試的速度、準確性，和完整性，測試可以達到業務期望的質量和效能。
現代軟件應用系統越來越錯綜復雜，搭建測試環境也變得越來越具有挑戰，因此有的測試干脆直接在生產環境中進行，但不可能把所有研發階段的測試全部右移。當被測試對象需要與所依賴的系統組件交互時，被依賴的系統組件如果處于下列狀態就變得不可用：
- 還在開發中的、不可靠的第三方組件
- 超出所在研發團隊的控制范圍的第三方組件
- 使用時容量或時間有限制
- 在測試環境中難以配置或部署
- 不同團隊需要同時設置不同的測試數據而引起沖突
越復雜的場景往往依賴更多的系統組件，因此端到端的自動化回歸測試就會有更多的限制。服務虛擬化可以消除被依賴的系統組件的不穩定，把測試和與之相互作用的各種依賴性隔離開來，為自動化測試提供穩定的環境。當測試失敗時，可以排除與之相關的測試環境問題，更方便進行問題定位，也可以為復現缺陷和驗證修復提供穩定可靠的測試環境。
另外，服務虛擬化還提供了一種簡單方法來模擬測試環境中的邊緣情況和錯誤條件下的行為，以便覆蓋更多的測試場景。例如，驗證被測系統在不同的依賴組合在關閉、延遲時的狀態。
4. 基于業務風險的測試分析
在敏捷開發和DevOps環境中，軟件發布的決策需要快速制定，最好是直觀的、自動的、實時的。傳統的，基于測試用例數量的測試結果已經不能滿足快速決策的要求。為什么這樣說呢？很多團隊在測試結束后提交的測試結果常常是這樣的：
- 總共有10,000條測試用例，測試覆蓋率為95%
- 90%的測試用例（9,000）執行成功
- 5%的測試用例（500）執行失敗，相關的功能模塊包括……
- 5%的測試用例（500）沒有執行，相關的功能模塊包括……
組織的決策團隊面臨的問題是，很難基于上述報告直觀判斷一個軟件是否可以發布。他們常常會有很多疑問：沒有覆蓋到的需求是不是有很大風險？失敗的和沒有執行的測試用例所關聯的功能特性是不是關鍵的業務功能？對于用戶會造成什么影響？
因此，幾乎總是需要組織發布前的評審會來了解測試結果背后的細節，才能做出判斷。這不僅會浪費時間，還會因為主觀和倉促的判斷錯誤估計了質量風險。以測試覆蓋率為例，測試覆蓋率只告訴我們一個應用的功能點被測試用例覆蓋的百分比，例如，如果一個應用總共有100個功能點，測試了其中95個，那么測試覆蓋率為95%。如果每個功能點都同樣重要，這個指標是有意義的，但實際上并非如此，例如，一個在線教育APP的聽課功能肯定比課程推廣功能更重要。如果5%沒有被測試覆蓋的功能點正好包括聽課功能，那相應的軟件版本還能發布嗎？
為了解決上述痛點，Tricentis公司提出了一種新的數字化測試范圍優化方法，其過程如圖2所示，主要包括以下幾點：
- 對需求進行業務風險的量化評估、排序。
- 設計測試用例對業務風險進行有效的覆蓋。
- 建立需求與測試用例之間的映射關系，把需求的量化風險關聯到測試用例。
- 根據給定的測試執行時間和業務風險確定測試范圍和優先級。
- 在測試結果的報告中，采用業務風險覆蓋率代替傳統的測試覆蓋率。根據業務風險覆蓋率進行軟件發布決策。
圖2 基于業務風險的測試范圍優化過程
這個方法的亮點在于需求風險的量化評估和根據風險覆蓋率進行發布決策。
首先介紹需求風險的量化評估，這里需要解釋幾個術語：需求的業務風險（Business Risk）、風險權重、風險貢獻率、風險覆蓋率（Risk Coverage）。
業務風險，用來量化一個需求，即Epic或用戶故事對業務產生負面影響的可能性，公式如下：
業務風險 = 使用頻率 x 失效危害（Risk = Frequency x Damage）
其中，使用頻率和失效危害的定義如下：
使用頻率（Frequency），是對需求對應的功能特性用戶使用頻率的度量。如果用戶經常使用一個功能，那么這個功能通常比較關鍵。
失效危害（Damage），是對需求對應的功能特性失效可能導致的損失進行的度量。會不會造成核心功能的癱瘓，還是只是造成使用上的不便？是否會造成重大的財務損失？有沒有監管違規？
某個功能特性的用戶使用頻率越高，并且一旦失效可能造成的損害越大，業務風險就越高。
風險絕對權重（Absolute Weight），是根據每個需求的Frequency和Damage按照下面的公式計算出來的：
用戶故事的風險權重按照上面的公式直接計算，Epic的風險權重是對其包含的用戶故事的風險權重求和。
風險相對權重（Relative Weight），是指每個需求相對于同一層級中其它需求的業務風險權重百分比。例如，在某個Epic下面一共有3個用戶故事，風險的絕對權重分別是256、128、128，那么用戶故事的風險相對權重分別為50%、25%、25%。
風險貢獻率（Risk Contribution），是指每個需求占所有需求的風險貢獻百分比。
下面是對需求進行業務風險量化評估、排序的推薦流程：
- 項目關鍵干系人承諾參加一個歷時一天半的會議，參與風險評估。
- 對于Epic、用戶故事等需要測試的業務需求進行簡要評審。如果軟件系統非常復雜，建議一開始把注意力放在Epic級別，而不是用戶故事級別。
- 按照每個需求實際或者預期的使用頻率對需求進行風險排序，從選擇最常用的需求開始，將其列為5級。接下來，將最不常用的需求列為1級。隨后，把其它的需求與最常用和最不常用的進行比較，每個級別的頻率應該加倍，例如，2級需求的使用頻率是1級的兩倍，3級需求是2級的兩倍。接下來對造成的損害重復相同的過程：如果這個需求對應的功能失效，可能導致的損害級別。先對每個Epic級別的需求進行排序，然后對每個Epic包含的用戶故事進行排序。
- 排序完成后，給與其它相關方評審風險評級結果的機會。
- 計算每個用戶故事和Epic的風險絕對權重、相對權重，以及風險貢獻率。
我們以一個在線教育App的用戶故事為例，表1列出了用戶故事和Epic的風險分析結果。其中，賬戶管理、課程購買，和課程學習這三個Epic的業務風險最高，分別貢獻了30.19%的業務風險，課程發現和課程分享這兩個Epic的業務風險較低。而Epic“賬戶管理“中，用戶故事“注冊登錄”貢獻了94.12%的業務風險，遠遠高于另一個用戶故事“充值”的業務風險。
表1 在線教育App需求風險評估表
到這里，我們對業務需求的風險評估就完成了，對被測軟件應用的風險也有了一個清晰、量化的認識。
未完待續，敬請期待“2020年軟件測試趨勢報道：測試實現持續測試（下）”。
