2020年軟件測試趨勢報道：徹底實現持續測試（下）
上一篇文章“2020年軟件測試趨勢報道：徹底實現持續測試（中）”介紹了持續測試實現框架中的實現基礎（測試數據管理、DevOps工具鏈集成、服務虛擬化）和中間過程中的“基于風險的測試分析”。今天接著介紹實現框架中的其它內容以及持續測試成熟度模型。
持續測試實現框架（續）
5. 有效的測試用例設計方法
下一步要做的就是確定在何處添加測試為最高業務風險的需求構建可接受的測試覆蓋率，以及利用有效的測試設計方法設計測試用例，既要保證覆蓋業務風險的效果，也要效率。
首先，二八原則在這里仍然有效：測試20%的需求覆蓋80%的業務風險。那么，對業務風險最高的需求必須盡可能覆蓋。
其次，關于測試設計方法，咱們熟悉等價類劃分、邊界值分析及各種組合方法（如Pairwise、正交實驗等），而Tricentis公司特別推薦采用Linear Expansion（線性膨脹）****，可以用很少的測試用例覆蓋更多的業務風險。
假設以下簡單場景：一個車險計算器考慮15個不同輸入屬性（性別、年齡、車輛類型等），每個屬性可以有2個不同的輸入值（男/女、18-59/60+、汽車/卡車等），每個屬性之間沒有相互依賴條件。女性司機會獲得5%的折扣；60+的司機會獲得5%的折扣。
如果采用Linear Expansion方法：
首先，要定義一條“straight through”或者“happy path”測試用例，所有的輸入屬性都選擇最重要的、有效等價類的值，覆蓋包含最大風險屬性值，例如，根據統計信息，男性汽車司機覆蓋了最廣泛的投保人群，那么這條測試用例應該選擇：性別：男，車輛屬性：卡車……。這條測試用例具有最高優先級，會作為冒煙測試或持續集成中BVT的測試用例集的一部分。
然后，為每一個屬性設計一條測試用例。每個測試都有一個明確的目標：一個測試檢查針對女性司機提供折扣的功能，一個測試針對60+的司機提供折扣的功能，等等。這些測試用例會作為自動化回歸測試用例集的一部分。因為每條測試用例都有一個明確的目的，如果某一條測試用例執行失敗，很容易能夠定位到對應的軟件代碼。
你最終得到的測試用例數量為16條（針對15個屬性分別設計一條測試用例+1個“straight through”測試用例）。各種測試設計方法對比如表1所示。
表1 各種測試設計方法對比
最后，在執行測試時，根據給定的測試執行時間和業務風險確定測試范圍和優先級，目標是達到反饋速度和業務風險覆蓋率之間的平衡（就這一點，依舊有挑戰）。針對在線教育App測試用例執行情況的風險覆蓋率如表2所示。
表2 在線教育App測試執行風險覆蓋率
在每次迭代中需要更新對需求的風險評估。首先，在一個Sprint中創建一個用戶故事列表，單獨針對這些新的用戶故事進行風險評估。通常情況下，任何一個新的功能特性的業務風險都比已有功能的風險要高。在所有新的用戶故事被驗證并通過后，再把這些新的需求合并到總的需求列表中，在整個回歸測試范圍內進行整體排序。
最終，基于風險覆蓋率的測試報告如表3所示。
表3 在線教育App測試報告
從中我們可以得到以下結論：
73%的業務風險已經被測試并且通過
4%的業務風險被測試但執行失敗
16%的業務風險已經設計了測試用例但沒有執行
7%的業務風險沒有任何測試用例
我們從中可以直觀的獲得這些數字化的信息：風險覆蓋距離目標的差距，失效的功能對業務的影響，特定需求的狀態，軟件版本是否滿足發布條件。
6. 測試影響分析
在敏捷開發中持續構建的頻率很高，全面的自動化回歸測試往往需要花費幾個小時甚至幾天的時間才能完成，但是持續測試不允許這么長的反饋時間，這時就需要借助測試影響分析技術。
測試影響分析技術由慕尼黑技術大學（Technical University Munich spin-off-CQSE）首創，它通過以下兩個原則迅速暴露自上一次測試運行以來添加/修改的代碼中的缺陷：
將回歸測試用例關聯到軟件應用的代碼，在選擇回歸測試的測試范圍時，僅僅選擇與最新一輪代碼更改相關聯的測試用例，而沒必要浪費時間去執行代碼沒有修改的測試用例。
根據檢測到缺陷的可能性對這些回歸測試用例進行排序，優先執行那些最容易暴露缺陷的測試用例。研究表明，這種方法用1%的執行時間可以發現80%的錯誤構建，2%的執行時間發現90%的錯誤構建。換句話說，測試速度可以提高100倍，但仍然可以發現大多數問題，是優化持續測試的理想選擇。
7. 探索式測試
測試自動化適合反復檢查增量應用的更改是否會破環現有功能（即回歸測試），但在驗證新的功能特性方面存在不足。采用探索式測試進行新功能的驗證，可以在自動化測試之前快速的發現缺陷。探索式測試可以參考相關文獻，這里只簡單概括探索式測試在持續測試中的作用：
快速暴露缺陷，包括采用其它測試方式找不到的缺陷。充分利用了人類智慧，探索式測試可以覆蓋更廣和更深的測試范圍，包括更多的測試場景，異常場景，用戶體驗。大家一般都有這樣的體驗，如果嚴格按照基于腳本的測試用例來執行測試，往往發現不了多少缺陷，往往需要做更多的擴展測試。
組織跨職能團隊成員一起進行探索式測試，包括開發人員、產品負責人、業務分析師等等。來自不同專業領域的成員可以帶來不同的專業人士。有了一個更大、更多樣化的團隊參與測試，不僅可以在更短的時間內完成更多的測試，而且還可以暴露出更廣泛的問題，并降低了關鍵問題被忽視的風險。
在轉化為自動化測試之前快速發現缺陷。如果使用探索性測試工具自動記錄測試步驟，則發現的任何缺陷都很容易被復現。
8. 自動化測試提供快速反饋
為什么敏捷化、DevOps讓自動化測試勢在必行？軟件越來越復雜，采用分布式架構，軟件發布的速度非常快，開發時間很有限，手工測試的周期太長，如果不為每個“sprint”中的測試進行認真的設計并引入高水平的測試自動化，是不可能完成覆蓋所有需要的測試范圍的。
研發團隊期待持續的、近實時的反饋。如果不能對最新的更改帶來的影響提供快速反饋，加速交付會帶來很大的業務風險。
優秀的企業比以往更加重視質量。企業雖然期望以比以往更快的速度交付更多的創新產品，但同時也認識到，輕視質量不可避免地會導致品牌流失和客戶流失。在受監管的行業，質量不達標的后果更為嚴重。
目前在很多組織中系統端到端的功能測試自動化水平很低，為了實現連續測試，端到端的功能測試自動化率需要超過85%，而且應該集中在API或消息級別，利用服務虛擬化來模擬所依賴的API和其他組件，UI測試自動化將不再是自動化的焦點。
持續測試成熟度模型
基于上述實現框架，Tricentis公司提出了持續測試的成熟度模型，如表4所示。
表4 持續測試成熟度模型
I級：在這個階段，測試用例的數量是關鍵的度量指標。測試人員根據感覺來判斷哪些需求需要設計更多的測試來覆蓋；基本采用手工測試，或部分采用基于腳本的測試自動化方式，導致了很多測試結果的誤報，因此測試腳本需要頻繁的維護；測試人員需要手工準備和維護測試數據；需要等待測試依賴的第三方系統組件被部署到測試環境中才能進行測試。期望的效率提升： 1.3X。
II級：已經采用基于業務風險的測試分析方法指導測試的分析、設計和執行，風險覆蓋率成為測試用例設計和執行的關鍵指標；測試自動化仍然集中在UI測試自動化，但開始采用基于模型的測試自動化技術，這可以顯著的降低誤報率和維護成本；因為仍然沒有綜合的測試數據管理服務，測試數據基本在自動化測試執行時生成，自動化無法覆蓋復雜的測試場景。期望的效率提升： 3X。
III級：基于會話的探索式測試被采用；采用有效的測試用例設計方法保證測試用例覆蓋業務風險的效果和效率，例如Linear Expansion。如果軟件的功能可以通過API被訪問，測試人員會采用API進行自動化測試；當API測試不適用或者效率不高時，采用基于模型的UI自動化測試；自動化測試在CI環境中和構建、部署等工具集成在一起使用。期望的效率提升：6X。
IV級：測試數據管理服務（TDM）為測試自動化提供測試數據；在被測系統所依賴的第三方系統組件不穩定或不可用的情況下服務虛擬化確保測試可以進行；TDM和服務虛擬化的引入讓自動化測試能夠覆蓋更復雜的API測試和端到端的測試，并保證測試可以持續運行；測試作為持續交付流水線的一部分持續運行，為要發布的軟件版本提供業務風險的即時反饋。期望的效率提升：10X。
V級：綜合的測試自動化能力已經建立，并且得到更強大的服務虛擬化和測試數據服務的支持；組織建立了度量指標來監控和持續的改進軟件測試流程的有效性。期望的效率提升：20X。
徹底實現持續測試
Tricentis公司提出了一套可行的實施框架，尤其是通過量化需求和測試風險為軟件測試的數字化轉型提供了新的思路。不過，這個框架距離持續測試的理想狀態還是有一定差距，而且很大程度上是貼合其推出的商業工具Tricentis Tosca提供的功能來介紹的，可以參考但不必完全照搬。
為了實現徹底的持續測試，未來可以從以下幾個方向來思考如何完善：
對需求的業務風險的度量依賴人工評審獲得，得到的結果比較主觀，將來能不能利用AI、大數據等技術進行自動分析，實現更為徹底的數字化？
API的自動化測試、測試數據管理服務、服務虛擬化技術和測試平臺與DevOps工具鏈的集成這些手段并不能消除自動化測試的所有障礙，如何讓自動化測試做得更快、更好？也許AI技術在將來可以給出更好的答案。
新功能探索式測試、回歸測試自動化，能不能把二者融合起來，利用人工的探索式測試智能產生測試代碼，讓測試更具“持續性”？例如，任何新功能，先經過測試人員的探索式測試給AI提供訓練數據，AI一邊訓練一邊補全測試，并生成自動化測試腳本。
總之，徹底的持續測試需要通過AI技術輔助實現，相信這一天很快到來，也許就在眼前！
