在我們的測試工作中，是不是經(jīng)常遇到這樣的情形，發(fā)生了線上問題，產(chǎn)品、研發(fā)或者測試同學一拍腦袋：當時怎么沒有想到，怎么給漏掉了呢？明明是一個非常簡單的事情，用大拇指都能想到的驗證場景，為何當時就漏測了呢？但實際情況是，逃逸到線上的缺陷，疑難雜癥式的極端異常的問題很少，大部分都不復雜且可以在設計和開發(fā)中規(guī)避，或者在測試過程中被識別出來。針對此類問題，從測試覆蓋度的角度，本文試圖解釋一下為何會發(fā)生這樣的事情，以及如何有效規(guī)避。

一. 為什么經(jīng)常會發(fā)生測試場景覆蓋不全的問題

高質(zhì)量的測試覆蓋率是確保產(chǎn)品質(zhì)量和用戶體驗的關鍵因素，但為何會經(jīng)常發(fā)生測試場景覆蓋不全的問題，這里面既有主觀因素的缺失，也有客觀因素的限制，具體包括：

1. 主觀原因

?粗心大意：認為需求非常簡單，沒有認真分析驗證場景及異常流程、分支流程，沒有識別隱藏的細節(jié)，或者對于存在的風險，存在僥幸心理，不去進一步求證或驗證。

?經(jīng)驗主義：思維固化，認為老辦法同樣可以解決新問題，沒有進一步思考測試場景、測試數(shù)據(jù)、驗證方式的不同之處。

?需求理解不充分：測試用例只覆蓋到了產(chǎn)品PRD里的顯式功能，沒有覆蓋隱性需求，只進行了黑盒測試或者黑盒測試覆蓋的場景不足。

?業(yè)務知識不足：只看到了需求本身，沒有看到背后隱藏的業(yè)務的真正訴求，知其然不知其所以然。

?開發(fā)知識欠缺：無法熟讀代碼，無法通過參加代碼評審識別出研發(fā)代碼改動之處及可能影響的范圍，望碼興嘆，無法熟練進行白盒測試，或者自動化測試代碼健壯性較差，無法起到自動化回歸的作用。

?信息互通不到位：與項目組其他成員溝通不到位，遺漏重要信息或沒有對齊顆粒度，你以為的實際不是你以為，導致遺漏重要驗證場景。

?用例顆粒度太大：編寫用例的過程也是自己梳理信息的過程，用例顆粒度大，自然梳理的過程就不會太精細，自然遺漏驗證場景的幾率就會更大（雖然探索式測試的理念是不要求編寫詳細的測試用例，而是在測試過程中不斷調(diào)整、優(yōu)化或細化，但很多需求不太適合探索式測試，這些需求要求快速上線，排期被嚴重擠壓，很難有充足的時間進行探索式測試）。

?測試專業(yè)技能薄弱：測試專業(yè)技能、經(jīng)驗不足，力所不及，自然無法保證測試的充分性及驗證場景的全面性。

2. 客觀原因

?項目周期緊湊：目前很多需求都無法按照研發(fā)測試的正常排期進行交付，倒排期和趕工是常態(tài)，測試很難有充分的時間思考驗證場景，新功能的測試往往只能覆蓋主要路徑，而忽略了一些邊界情況和異常場景。

?需求變更頻繁：迭代快、變更快也是產(chǎn)品常態(tài)，往往一期還沒有上線，二期三期就要評審了，沒有經(jīng)過線上真實環(huán)境、數(shù)據(jù)和客戶的反饋，產(chǎn)品方案、技術方案存在的缺陷可能無法暴露和識別。

?投放渠道眾多：尤其是針對C端用戶的拉新和促活活動，投放渠道非常多，涉及到不同的承接環(huán)境，如App環(huán)境（iOS、安卓、鴻蒙）、H5環(huán)境、小程序環(huán)境，同時涉及到不同設備、不同環(huán)境、不同操作系統(tǒng)版本、不同瀏覽器的打開、回流、引導下載等操作，兼容性測試覆蓋不足可能導致無法識別到特定設備下的功能或體驗問題。

?流量情況懸殊：各個投放渠道流量差異較大，若上線前沒有對各渠道的流量有充分的預估，沒有進行壓測，在高并發(fā)、大數(shù)據(jù)量或復雜業(yè)務場景下，性能問題可能無法被及時發(fā)現(xiàn)，從而導致線上問題。

?測試環(huán)境仿真度低：目前很多系統(tǒng)之間存在測試環(huán)境未打通、測試環(huán)境數(shù)據(jù)不全等問題，導致測試環(huán)境的仿真度較低，可能出現(xiàn)測試環(huán)境無法模擬真實環(huán)境或測試環(huán)境無法覆蓋全部驗證場景的情況。

二. 如何提升測試覆蓋度

為了盡量避免因測試場景覆蓋不足所導致的線上問題，需要針對以上客觀和主觀原因進行分析，并制定行之有效的對策?？偨Y(jié)來說，在測前、測中及測后，提升"內(nèi)因"，把控“外因”，避免“三拍”。

??

?

1. 內(nèi)因

提升測試覆蓋度，“內(nèi)因”是關鍵，即可以通過積極的質(zhì)量策略以及專業(yè)能力的提升，大大減少測試覆蓋度不足的情況。

?測前：充分理解，不盲目拍胸脯保證。

?測試工作不是始于測試執(zhí)行之時，而應前置到需求階段，測試同學應具備基本的業(yè)務Know-How，充分理解業(yè)務邏輯及研發(fā)邏輯，面對具體的業(yè)務需求，不僅停留在功能實現(xiàn)層面，更應理解此需求背后的業(yè)務訴求。在前置編寫及評審測試用例的時候，與產(chǎn)品、研發(fā)充分溝通產(chǎn)品邏輯及技術實現(xiàn)方案是否與業(yè)務邏輯及真正的業(yè)務訴求保持一致，充分討論業(yè)務風險和技術風險?？傊?，絕不能不求甚解、掉以輕心，應不懂就問，多溝通，多討論風險，敢于發(fā)問，敢于質(zhì)疑。

?在測試專業(yè)能力方面，采用靈活的質(zhì)量策略，如進行代碼覆蓋率分析，實施精準測試和探索式測試，維護貼近生產(chǎn)的測試環(huán)境和測試數(shù)據(jù)、更高覆蓋率的的自動化測試，以及適合業(yè)務特點的測試工具等等。

?測中：充分識別，不草率拍腦袋決策。按照我們前置測試用例的邏輯，大部分需求的測試用例在開發(fā)階段或開發(fā)之前就已經(jīng)編寫并評審完畢，但隨著交付進度的進行，各方對需求的理解不斷加深，即使進入到測試階段，仍可能會識別出新的范圍、風險或問題，因此，應不斷就驗證范圍、風險、異常場景等進行確認，并標注出核心驗證點以及測試過程中可能存在的問題和風險，及時調(diào)整和改進測試策略。還應共識雙向的影響范圍，即該需求是否影響了其他業(yè)務功能或技術模塊，其他功能或技術模塊是否影響該需求。

?測后：充分總結(jié)，不驚慌拍大腿懊悔。測試完成并上線不是終點，除了配合業(yè)務進行線上驗證及觀察線上數(shù)據(jù)、進行線上巡檢之外，還應花點時間回顧一下交付的過程，總結(jié)經(jīng)驗教訓，主動分享。對于核心的用例，看能否沉淀為自動化的回歸及巡檢用例。萬一出現(xiàn)了線上問題，先盡快恢復業(yè)務，再分析原因，進行復盤，總結(jié)教訓和改進方案。

2. 外因

提升測試覆蓋度，“外因”是基礎，即通過流程機制的約束及全流程的質(zhì)量把控、層層把關、互相補位，從機制上降低測試場景遺漏發(fā)生的概率。通過規(guī)范化的質(zhì)量活動對需求交付的各個階段進行質(zhì)量準入和準出，步步為營，形成強制性的“七道關卡”，即上圖所示的用例前置、單元測試、冒煙演示、測試執(zhí)行、產(chǎn)品驗證、運營驗收及線上灰度驗證。嚴格遵守這套流程機制，上一道關卡遺漏下來的問題，大概率會在后面的關卡被識別出來，因此，遺漏驗證場景的從而導致缺陷逃逸到線上的概率會被大大降低。（關于本段內(nèi)容，可以參閱《產(chǎn)品需求交付質(zhì)量保證的“七重門”》）。

?

總結(jié)一下，針對如何提升測試覆蓋度，“內(nèi)因”是關鍵，基本可以解決上述“主觀原因”導致的測試覆蓋不足的問題，“外因”是基礎，基本可以解決上述“客觀原因”導致的測試場景覆蓋不足的問題。

三. 綜述

總結(jié)來說，防止線上問題不能停留在口頭上，或者簡單粗暴地要求測試同學提升測試覆蓋度，應該給與更加具體的要求、指導及評價的標準。其關鍵要素是流程機制確?；镜馁|(zhì)量，專業(yè)能力進一步提升質(zhì)量，主觀能動性構(gòu)建持續(xù)的高質(zhì)量，只有不斷提升“內(nèi)因”并把控好“外因”，才能有效防范“漏測”問題的發(fā)生，持續(xù)交付穩(wěn)定可靠的產(chǎn)品，并提供更好的用戶體驗。

審核編輯 黃宇