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

產(chǎn)品的每個迭代周期發(fā)布之前，都會有一個“驗收”環(huán)節(jié)，針對不同的產(chǎn)品管理/項目管理模式，產(chǎn)品驗收的過程會略有差異。

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

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

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

一、驗收測試的階段

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

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

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

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

二、驗收測試的準入條件

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

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

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

1、上一階段的測試報告

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

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

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

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

2、驗收賬號

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

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

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

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

所以關于測試數(shù)據(jù)的問題，需要協(xié)調(diào)技術負責人整理一份健壯的數(shù)據(jù)清理腳本，并在系統(tǒng)集成測試階段經(jīng)受住考驗。

3、驗收測試用例

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

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

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

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

另一方面也能夠?qū)ⅰ懊艚莸钡墓芾硭悸啡谌敫麟A段協(xié)作過程中，以降低交接、單線程工作等待的資源消耗。

4、什么時候開始啟動？

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

其實就是以敏捷的思維交叉協(xié)同。

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

驗收階段主要涉及三類角色：產(chǎn)品（業(yè)務）、測試、開發(fā)。

產(chǎn)品：是本階段的主導人，負責具體執(zhí)行、決策、協(xié)調(diào)、結果產(chǎn)出等相關事項。

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

測試：協(xié)助產(chǎn)品維護測試環(huán)境和測試數(shù)據(jù)、定位問題、分析問題、協(xié)調(diào)開發(fā)資源等。

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

四、驗收測試的側(cè)重點

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

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

1、核心業(yè)務流程

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

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

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

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

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

術業(yè)有專攻，如是而已。

2、關鍵用戶體驗

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

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

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

舉個不恰當?shù)睦樱杭僭O這款產(chǎn)品是為視力較差且不戴眼鏡的用戶設計的，字體就要放大，布局就要稀松。而驗收測試的人即便視力正常，也要遵循目標用戶的操作習慣。

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

而且，本身驗收測試人員對互聯(lián)網(wǎng)軟件工程的理解比較淺，因此更要發(fā)揮自己的優(yōu)勢，以用戶、場景、業(yè)務為導向，在此階段中發(fā)現(xiàn)潛在的操作問題。

3、驗收的準出標準

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

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

（2）遺留缺陷在不影響系統(tǒng)正常運行前提下，多方達成一致確認可后續(xù)迭代優(yōu)化；

（3）產(chǎn)品整體的視覺體驗驗證通過；

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

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

五、驗收測試的問題處理

1、交叉驗收

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

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

但前提都要以團隊內(nèi)的資源情況和工程進度為基準，適度調(diào)整。

2、缺陷處理機制

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

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

此時，如何做決策？

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

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

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

（2）經(jīng)過產(chǎn)品評審會討論，此功能不再驗收（忽略）。

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

3、驗收輪次

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

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

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

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

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

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

寫在最后

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

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

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

最后總結一句：

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