產品在迭代更新之際，每個迭代周期發布的時候，都會有個“驗收”的過程，那么要如何做好這個驗收環節呢？本文總結了相關思路以及問題處理的步驟，希望對你有所幫助。

產品的每個迭代周期發布之前，都會有一個“驗收”環節，針對不同的產品管理/項目管理模式，產品驗收的過程會略有差異。

但作為一個從“設計”到看見“實物”的時刻，仍然需要產品團隊把好最后一關。

作為測試入行的我，這些年也經歷了很多驗收測試，如果團隊真的能夠重視驗收測試，并將其標準化、規范化，能識別很多潛在風險，也能讓原本80分的系統快速提升為90分。

所以，今天就來聊一聊我理解的產品驗收測試。

一、驗收測試的階段

從標準的項目管理過程來看，一個項目自立項開始，基本可以分為：需求階段、設計階段、開發階段、測試階段、上線及試運行階段。

而測試階段可以分為：單元測試（有些團隊會歸到開發階段）、冒煙測試、SIT測試（系統集成測試）、UAT測試（用戶/產品驗收測試）。

自研類產品，驗收測試一般會由產品團隊主導，而項目制的產品，驗收測試一般由甲方的業務方、需求提出方主導，或者由甲方委派第三方測試團隊開展驗收測試工作。

這里就會存在一個問題：驗收測試人員，并非用戶的實際使用者。這個問題下文再展開。

二、驗收測試的準入條件

一個標準的測試管理流程中，每一個階段都需要建立“準入”條件，否則一方面浪費測試人員的時間，另一方面也會降低上一階段人員的執行標準。

比如為什么開發人員交付的功能，測試人員在正式開始測試時要進行冒煙測試？一個連主流程都有問題的功能，異?？刂颇茏龅绞裁闯潭饶?？

因此，去年為了提升產品團隊的驗收效率，我也制定了一些準入標準，各位同行可以結合自身團隊情況維護一套自己的“驗收準入條件”。

1、上一階段的測試報告

上一個階段大多是系統集成測試，測試完成后的測試報告將作為一個基礎的條件。

而這份報告重點關注什么？或者說從測試完成到出具報告可能存在幾天的延遲，這時我們就干等著嗎？

其實我們需要的并非“報告”這個形式，而是其中的關鍵結果：測試通過率。并且關注一下未通過、遺留的缺陷是什么情況，是否會阻礙驗收進度，影響用戶的場景閉環。

當然，一個正常的團隊，各個角色之間的溝通應該是很通暢的，大多數問題在準入前，測試和產品之間應該會有多次的討論，只不過在真正要啟動驗收時，還需要重點關注一下。

2、驗收賬號

在測試環境下，測試賬號是一個非常重要，但又經常被大家忽略的問題。如果能有一個合適的測試賬號，維護一套合理的測試數據，將會為測試階段的提效帶來質的改變。

因此，在正式開始驗收測試之前，我們需要基于測試用例圍繞的場景，提前準備好測試賬號，并且最好能掌握一些基礎的數據庫操作，能夠自己維護、設計測試賬號，而不是每次找測試人員或開發人員。

時間久了，不僅會浪費對方的時間，也會讓對方覺得你，很不專業。

一個新的測試階段開始時，大多數系統都要清理測試數據，盡量讓系統與剛上線時的狀態一致。然而，想必很多人也體會過，數據清一次，系統崩一次。

所以關于測試數據的問題，需要協調技術負責人整理一份健壯的數據清理腳本，并在系統集成測試階段經受住考驗。

3、驗收測試用例

上一條提到，驗收測試開始前需要設計好測試用例，準入條件滿足之后即可開始驗收。

而測試用例的準備及評審，可以放在項目設計階段，或者集成測試中期。具體時間大家可以結合實際情況確定。

我的習慣是在需求評審階段引入測試用例的宏觀設計，設計評審階段開始進行測試用例的編寫，設計評審結束后，進行測試用例的評審（系統集成測試），集成測試用例評審結束后，進行驗收用例的評審。

這樣做的好處，一方面可以使后置階段提前介入，從而保證業務由粗到細的順序拆解。

另一方面也能夠將“敏捷迭代”的管理思路融入各階段協作過程中，以降低交接、單線程工作等待的資源消耗。

4、什么時候開始啟動？

按照上述的思路，產品驗收雖然是最后一個環節，但它的啟動階段可以前置到“設計階段末期”或“開發階段初期”，提前將驗收的目標、用例、評審幾個環節達成一致，等到正式進入驗收測試后，直接做執行即可。

其實就是以敏捷的思維交叉協同。

三、驗收測試階段的人員分工

驗收階段主要涉及三類角色：產品（業務）、測試、開發。

產品：是本階段的主導人，負責具體執行、決策、協調、結果產出等相關事項。

當然在此過程大概率會涉及UI或UE方面的調整，根據公司的團隊組成不同而略有差異，在此我將這些分工都納入產品團隊。

測試：協助產品維護測試環境和測試數據、定位問題、分析問題、協調開發資源等。

開發：負責缺陷修復工作，以及對復雜問題的分析、設計工作。

四、驗收測試的側重點

驗收測試的目標與集成測試有很多區別，所以側重點也有很多不同。

另外，基于參與驗收測試的人員特性，在測試過程中看待問題的角度和決策方向都有較大差異。

1、核心業務流程

本階段的測試重點在核心業務流程和用戶體驗層面，對后臺處理邏輯的合理性、性能等不會過度關注。

比如在頁面上輸入A，經過處理輸出B，我們只需要確認A、B的結果沒有問題即可。至于是A->C->D->E->B，還是A->F->B，大多數驗收測試不會關注。后臺的處理過程應該在設計階段、集成測試階段進行驗證。

比如報表查詢的等待時間是3秒還是3.5秒，對于業務人員也不會關注，只要不超過一定的“閾值”即可。而真正的性能測試、安全測試等，都有相應的測試階段“專項攻克”。

所以本階段最關鍵的內容，依然是核心業務流程，即主干+分支，或者是核心場景+輔助場景。

我們需要從用戶的角度來評估，這些功能是否能夠解決預期問題，是否能夠為原有流程帶來效率提升。

術業有專攻，如是而已。

2、關鍵用戶體驗

另外，驗收測試的重點是用戶體驗測試。這里包含了平臺體驗一致性、易用性、交互效率、合理性等，根據不同的產品類型，還包含創新性、趣味性等。

很多產品在前期并不重視用戶體驗，最終呈現了一個看似什么問題都能解決，但沒有用戶使用的“殘次品”，很多問題也是出現在了驗收測試階段。

這里著重強調一個“用戶思維”。無論是哪類人員進行驗收測試，都要站在目標用戶群體的畫像上，試著以他們的角度、認知、習慣來審視當下的產品功能，而非利用自己的習慣進行評判。

舉個不恰當的例子：假設這款產品是為視力較差且不戴眼鏡的用戶設計的，字體就要放大，布局就要稀松。而驗收測試的人即便視力正常，也要遵循目標用戶的操作習慣。

或者產品是為年輕女性提供的，驗收人是中年男性，則更需要站在目標用戶的習慣下審視這些功能。

而且，本身驗收測試人員對互聯網軟件工程的理解比較淺，因此更要發揮自己的優勢，以用戶、場景、業務為導向，在此階段中發現潛在的操作問題。

3、驗收的準出標準

驗收測試的結束，意味著產品達到上線標準。但達到上線標準并不代表沒有缺陷，所以我認為驗收測試的準出原則主要有以下幾個：

（1）新一輪驗收測試中，主流程+輔助流程的缺陷修復率達到100%；

（2）遺留缺陷在不影響系統正常運行前提下，多方達成一致確認可后續迭代優化；

（3）產品整體的視覺體驗驗證通過；

（4）對于升級類產品，對于原有功能的影響度測試完成；

最后，形成驗收測試報告，將本次測試的結果寫清楚。

五、驗收測試的問題處理

1、交叉驗收

我最初的想法，是讓團隊內的人員進行“交叉驗收測試”，即張三負責的需求，驗收測試由李四做；李四負責的需求，驗收測試由王五做。

這樣交叉驗收的好處是：一方面組內同學都可以相互了解產品的業務全貌，避免形成思維壁壘；另一方面也是做了一層保障，讓新同學測試，更容易找到用戶視角。

但前提都要以團隊內的資源情況和工程進度為基準，適度調整。

2、缺陷處理機制

大部分缺陷，直接找到測試人員或開發人員進行驗證、修復即可。

但有時會遇到不太好改的問題，或者隨著時間推移導致政策變動、用戶預期及偏好變動、市場變動等情況，讓業務人員發現本版并不能滿足業務要求。

此時，如何做決策？

每個團隊的決策影響因素都不一樣，在此我僅分享兩個曾經使用的原則：

（1）少量極端場景下存在等級為高級的缺陷要進行需求變更

若需求變更程度小于10%且工作量在1周內的本版本解決，可以進行需求變更；若需求變更范圍影響涉及比例超過原需求10%則延至下一版本，并確定延期交付的時間。

（2）經過產品評審會討論，此功能不再驗收（忽略）。

有些問題雖然存在，但為特殊場景下的低頻偶發情況，經過評審會討論后，將其忽略。

3、驗收輪次

正常來講，產品驗收測試做兩輪即可，如果遇到交付質量較高的版本，一次測試直接通過也可以。

但我也遇到過驗收測試做了多輪的情況，大多是因為前期流程控制和交接的問題，在本階段出現了需求變更、需求蔓延等，導致后續的過程異常艱難。

也有一些集成測試質量較差的，導致驗收測試一直在關注細節。

其實每個測試階段要進行幾輪，并沒有一個明確的規范，我們可以結合當下版本的大小、風險的高低、資源配置情況等，制定不同的要求。

但千萬要注意，每當新一輪測試伊始，經常會出現一些稀奇古怪的問題，這些問題一定要引起團隊的重視，因為在軟件層面，任何一個問題的出現都不是偶然。

很多稀奇古怪的問題，恰恰反映了當下團隊的項目過程管理體系的缺失。

寫在最后

今天的分享，基本框架是去年我在團隊中構建的產品驗收流程，然而隨著我的離開，也沒有機會驗證此流程的效果，這不得不說是一種遺憾。

一份流程的建立不僅需要對現狀和目標的考量，更需要牽頭人的督導和推動，在面對多重阻礙時適度調整，最終經過幾個周期的迭代，讓各個角色都形成一種習慣。

而這個周期，大概率要以“季”或“年”為單位衡量，確實很難，但我相信一定有團隊在做，或已經做出了成果。

最后總結一句：

產品團隊要站好最后一班崗，既要為自己的設計方案負責，更要為自己的交付結果負責。