在我們的測試工作中,是不是經常遇到這樣的情形,發生了線上問題,產品、研發或者測試同學一拍腦袋:當時怎么沒有想到,怎么給漏掉了呢?明明是一個非常簡單的事情,用大拇指都能想到的驗證場景,為何當時就漏測了呢?但實際情況是,逃逸到線上的缺陷,疑難雜癥式的極端異常的問題很少,大部分都不復雜且可以在設計和開發中規避,或者在測試過程中被識別出來。針對此類問題,從測試覆蓋度的角度,本文試圖解釋一下為何會發生這樣的事情,以及如何有效規避。
一. 為什么經常會發生測試場景覆蓋不全的問題
高質量的測試覆蓋率是確保產品質量和用戶體驗的關鍵因素,但為何會經常發生測試場景覆蓋不全的問題,這里面既有主觀因素的缺失,也有客觀因素的限制,具體包括:
1. 主觀原因
?粗心大意:認為需求非常簡單,沒有認真分析驗證場景及異常流程、分支流程,沒有識別隱藏的細節,或者對于存在的風險,存在僥幸心理,不去進一步求證或驗證。
?經驗主義:思維固化,認為老辦法同樣可以解決新問題,沒有進一步思考測試場景、測試數據、驗證方式的不同之處。
?需求理解不充分:測試用例只覆蓋到了產品PRD里的顯式功能,沒有覆蓋隱性需求,只進行了黑盒測試或者黑盒測試覆蓋的場景不足。
?業務知識不足:只看到了需求本身,沒有看到背后隱藏的業務的真正訴求,知其然不知其所以然。
?開發知識欠缺:無法熟讀代碼,無法通過參加代碼評審識別出研發代碼改動之處及可能影響的范圍,望碼興嘆,無法熟練進行白盒測試,或者自動化測試代碼健壯性較差,無法起到自動化回歸的作用。
?信息互通不到位:與項目組其他成員溝通不到位,遺漏重要信息或沒有對齊顆粒度,你以為的實際不是你以為,導致遺漏重要驗證場景。
?用例顆粒度太大:編寫用例的過程也是自己梳理信息的過程,用例顆粒度大,自然梳理的過程就不會太精細,自然遺漏驗證場景的幾率就會更大(雖然探索式測試的理念是不要求編寫詳細的測試用例,而是在測試過程中不斷調整、優化或細化,但很多需求不太適合探索式測試,這些需求要求快速上線,排期被嚴重擠壓,很難有充足的時間進行探索式測試)。
?測試專業技能薄弱:測試專業技能、經驗不足,力所不及,自然無法保證測試的充分性及驗證場景的全面性。
2. 客觀原因
?項目周期緊湊:目前很多需求都無法按照研發測試的正常排期進行交付,倒排期和趕工是常態,測試很難有充分的時間思考驗證場景,新功能的測試往往只能覆蓋主要路徑,而忽略了一些邊界情況和異常場景。
?需求變更頻繁:迭代快、變更快也是產品常態,往往一期還沒有上線,二期三期就要評審了,沒有經過線上真實環境、數據和客戶的反饋,產品方案、技術方案存在的缺陷可能無法暴露和識別。
?投放渠道眾多:尤其是針對C端用戶的拉新和促活活動,投放渠道非常多,涉及到不同的承接環境,如App環境(iOS、安卓、鴻蒙)、H5環境、小程序環境,同時涉及到不同設備、不同環境、不同操作系統版本、不同瀏覽器的打開、回流、引導下載等操作,兼容性測試覆蓋不足可能導致無法識別到特定設備下的功能或體驗問題。
?流量情況懸殊:各個投放渠道流量差異較大,若上線前沒有對各渠道的流量有充分的預估,沒有進行壓測,在高并發、大數據量或復雜業務場景下,性能問題可能無法被及時發現,從而導致線上問題。
?測試環境仿真度低:目前很多系統之間存在測試環境未打通、測試環境數據不全等問題,導致測試環境的仿真度較低,可能出現測試環境無法模擬真實環境或測試環境無法覆蓋全部驗證場景的情況。
二. 如何提升測試覆蓋度
為了盡量避免因測試場景覆蓋不足所導致的線上問題,需要針對以上客觀和主觀原因進行分析,并制定行之有效的對策??偨Y來說,在測前、測中及測后,提升"內因",把控“外因”,避免“三拍”。
??
?
1. 內因
提升測試覆蓋度,“內因”是關鍵,即可以通過積極的質量策略以及專業能力的提升,大大減少測試覆蓋度不足的情況。
?測前:充分理解,不盲目拍胸脯保證。
?測試工作不是始于測試執行之時,而應前置到需求階段,測試同學應具備基本的業務Know-How,充分理解業務邏輯及研發邏輯,面對具體的業務需求,不僅停留在功能實現層面,更應理解此需求背后的業務訴求。在前置編寫及評審測試用例的時候,與產品、研發充分溝通產品邏輯及技術實現方案是否與業務邏輯及真正的業務訴求保持一致,充分討論業務風險和技術風險??傊?,絕不能不求甚解、掉以輕心,應不懂就問,多溝通,多討論風險,敢于發問,敢于質疑。
?在測試專業能力方面,采用靈活的質量策略,如進行代碼覆蓋率分析,實施精準測試和探索式測試,維護貼近生產的測試環境和測試數據、更高覆蓋率的的自動化測試,以及適合業務特點的測試工具等等。
?測中:充分識別,不草率拍腦袋決策。按照我們前置測試用例的邏輯,大部分需求的測試用例在開發階段或開發之前就已經編寫并評審完畢,但隨著交付進度的進行,各方對需求的理解不斷加深,即使進入到測試階段,仍可能會識別出新的范圍、風險或問題,因此,應不斷就驗證范圍、風險、異常場景等進行確認,并標注出核心驗證點以及測試過程中可能存在的問題和風險,及時調整和改進測試策略。還應共識雙向的影響范圍,即該需求是否影響了其他業務功能或技術模塊,其他功能或技術模塊是否影響該需求。
?測后:充分總結,不驚慌拍大腿懊悔。測試完成并上線不是終點,除了配合業務進行線上驗證及觀察線上數據、進行線上巡檢之外,還應花點時間回顧一下交付的過程,總結經驗教訓,主動分享。對于核心的用例,看能否沉淀為自動化的回歸及巡檢用例。萬一出現了線上問題,先盡快恢復業務,再分析原因,進行復盤,總結教訓和改進方案。
2. 外因
提升測試覆蓋度,“外因”是基礎,即通過流程機制的約束及全流程的質量把控、層層把關、互相補位,從機制上降低測試場景遺漏發生的概率。通過規范化的質量活動對需求交付的各個階段進行質量準入和準出,步步為營,形成強制性的“七道關卡”,即上圖所示的用例前置、單元測試、冒煙演示、測試執行、產品驗證、運營驗收及線上灰度驗證。嚴格遵守這套流程機制,上一道關卡遺漏下來的問題,大概率會在后面的關卡被識別出來,因此,遺漏驗證場景的從而導致缺陷逃逸到線上的概率會被大大降低。(關于本段內容,可以參閱《產品需求交付質量保證的“七重門”》)。
?
總結一下,針對如何提升測試覆蓋度,“內因”是關鍵,基本可以解決上述“主觀原因”導致的測試覆蓋不足的問題,“外因”是基礎,基本可以解決上述“客觀原因”導致的測試場景覆蓋不足的問題。
三. 綜述
總結來說,防止線上問題不能停留在口頭上,或者簡單粗暴地要求測試同學提升測試覆蓋度,應該給與更加具體的要求、指導及評價的標準。其關鍵要素是流程機制確?;镜馁|量,專業能力進一步提升質量,主觀能動性構建持續的高質量,只有不斷提升“內因”并把控好“外因”,才能有效防范“漏測”問題的發生,持續交付穩定可靠的產品,并提供更好的用戶體驗。
審核編輯 黃宇
-
測試
+關注
關注
8文章
5278瀏覽量
126600 -
仿真
+關注
關注
50文章
4071瀏覽量
133552
發布評論請先 登錄
相關推薦
評論