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