《老王與小明的日?！废盗旭R上就要收尾了。而這篇文章，會介紹如何進行產品測試，同時也是本系列的一個總結。

太多的產品新人，甚至于工作一兩年的產品汪，在開發階段往往出現很多對接問題，影響上線進度。在此，我將程序開發階段總結為一下4個階段，并以故事的形式，分流程介紹我們該如何與開發對接。因內容較多，且需要與實際工作結合進行考慮，所以建議大家收藏下來，慢慢看。

下圖為此系列內容的大綱：

（此系列內容的大綱）

今天我們說說第4部分，產品測試。如果沒有看過前三篇文章的同學， 請點擊下面的傳送門：

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（1）》

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（2）》

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（3）》

產品測試在很多公司，都會有專門的部門進行負責。而此篇文章主要介紹的是在沒有測試人員的情況下，產品經理如何兼任測試崗位，進行產品測試。文章主要包含三部分：

確定測試介入時間

在瀑布流開發過程中，通常在開發完成后才進行產品測試。這時候，測試人員拿到的版本通常是經過程序猿初步測試的版本。

• 優勢：開發與測試的時間節點可控，且測試前有充足的時間進行測試準備工作。
• 劣勢：劣勢非常明顯，會大大延長了產品上線時間。

而在現階段大部門的互聯網公司中，大家通常將開發的功能按模塊劃分好，并確定模塊的開發順序（具體可以查看第2篇文章）。當完成某個模塊的開發，便對該模塊進行單元測試。這時候測試人員拿到的版本通常是一個產品雛形。

優勢：

• 可以將減少一部分產品測試的時間。
• 時刻跟進產品開發方向，避免程序猿開發出來的東西不是原先想要的產品。

缺點：

• 對程序猿能力要求較高，需要確保每個模塊開發出來的主流程必須是可用于測試的。
• 增加了產品在開發階段的工作量。（如果公司沒有安排測試人員的話）

以上的兩種方式，我更傾向于第2種，并且在自己日常工作中，也采用第2種方式?？纱蟠罂s短項目的開發周期。每個模塊測試一遍，上線前再完整測試一遍，基本上不會出現太大問題。當然了，每種方式均不是完美的，這需要產品經理根據項目的不同，進行選擇。

測試前的準備工作

在確定了介入時間之后，接下來我們就要做測試前的準備，測試前的需要準備的東西通常包括：測試用例、測試人員、測試環境（系統、瀏覽器等）

• 測試用例：測試人員為測試某一個功能是否滿足既定的要求，而編寫的一組測試輸入、執行與結果展現的標準文檔。目的是為了讓測試更加標準。通常情況下，一份詳細的PRD文檔也可以用來做測試用例，不需要在編寫測試用例上花費時間。
• 測試人員：大公司都有專門的測試部門用來進行產品測試工作。小公司的大多數都交給產品經理或產品助理來完成，在這個時候，我們就要協調好測試人員，保證在測試階段，有專人負責。當然在產品經理親自上陣的時候，也需要考慮到自己的手頭工作，做好工作安排。
• 測試環境：App測試的環境主要是各種手機系統與系統版本，web主要是各種瀏覽器。Pc軟件主要是操作系統。所以在進行測試前，需要將這些必要的環境搭建好

測試準備階段，根據產品的性質不同，可能還需要準備不同身份的測試賬號、材料（閱卷系統的答題卡）等物品。在此推薦大家在準備階段，列舉一個測試準備清單，并在測試前反復確認，保證測試工作的正常進行。

隨手畫的一個清單，不一定適用于大家所有的項目，僅提供參考。

測試報告產出

在測試過程中，我們需要將發現的bug記錄在測試報告中，而為了方便程序猿們的查看，我們的測試報告需要包含以下幾個要素：

• 嚴重程度：嚴重主要描述bug可能造成的影響，我們通常將嚴重程度分為4級。1為最強、4為最弱。具體的劃分1為主流程bug；2為輔助流程bug；3為交互bug；4為樣式bug。方便項目經理安排bug修復的任務。
• 修改優先級：優先級主要是為了方便指導程序猿的bug修改順序。通常我們將bug修改為3級。1代表緊急bug，需要立即修改。2代表需要上線前修改完成的bug。3代表可放在上線后進行修改的bug。
• Bug內容：主要用來描述產品bug的內容，例如“點擊登錄按鈕無反應”。問題不宜長篇大論，突出重點就可以。
• 重現步驟：標注好問題重現步驟，方便程序猿快速找出問題的原因。對上述的bug內容我們可以這樣描述“將瀏覽器內核設置為為ie9，進行賬號登錄，點擊登錄按鈕無反應”。
• 需求描述：主要描述bug需要修改成什么樣子，方便程序猿制定修改方案。例如“登錄功能需要兼容ie9內核”。結果描述要有具體的結果，不宜模棱兩可。

注：在一部分情況下，我們會將bug內容、重現步驟、結果描述寫在一起，統一叫做bug內容。

修改人、修改情況、備注說明

明確bug的修改人，修改情況與備注，可方便我們對bug修改過程進行跟蹤。通常修改人由項目經理進行分配。修改情況與備注由程序猿記性填寫，最終需要測試人員進行確認。

當1份報告需要多個用戶同時查看，excel無法實現多用戶同時在線編輯的弊端就非常明顯了。這時候如果有一款專門的協同開發工具是不是更好？

關于產品測試階段，就介紹這么多了，下面主要會將《老王與小明的日?！愤@個系列做一個總結。

系列總結

老規矩，先把圖亮出來，下面這張圖就是此系列文章的大綱：

下面這些都是此系列文章的重點總結，有疑問的小伙伴可以參考對應的文章進行查看。

需求傳達階段

• 傳達項目背景，讓程序猿認為他們是在做一款改變世界的產品。
• 有節奏的介紹需求，當然了，這里的節奏不是“啪啪啪”的節奏，而是要分清介紹的主次
• 確定關鍵性目標，讓程序猿對開發結果有個明確的目標。

制定開發進度與關鍵節點階段

• 給足程序猿評估項目周期的時間，目的是讓程序猿充分了解需求，需求了解后，評估時間自然而然就出來了。
• 適當的接受程序猿的建議，需要砍需求的時候，不要猶豫。
• 確定開發順序，為后期開發跟進與測試打好基礎。
• 明確關鍵時間節點，為項目管理提供依據。

跟進開發階段

• 模塊開發前，做好相應模塊的需求變更與需求確認。
• 明確站立會與周例會的工作職責。
• 做好支持與協調工作，為開發擺平一切困難

產品測試階段

• 確定好測試的介入時間
• 用清單的形式，做好測試準備工作
• 提交切實可用的測試報告。

感謝

一周多的時間將此系列寫完，時間確實有點緊。導致了每篇文章中都有很多地方表達不是很清楚，所以在此非常感謝小伙伴們的支持。希望這4篇文章對您的工作有一定的幫助。

相關閱讀

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（1）》

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（2）》

《小明與老王的日常：學會做這4件事，讓你的產品提前上線（3）》

作者：李英杰，二一教育高級產品經理，主要負責題庫類產品的規劃與運營工作。

本文由 @李英杰 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議