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

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

下圖為此系列內(nèi)容的大綱：

（此系列內(nèi)容的大綱）

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

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

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

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

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

確定測試介入時間

在瀑布流開發(fā)過程中，通常在開發(fā)完成后才進行產(chǎn)品測試。這時候，測試人員拿到的版本通常是經(jīng)過程序猿初步測試的版本。

• 優(yōu)勢：開發(fā)與測試的時間節(jié)點可控，且測試前有充足的時間進行測試準備工作。
• 劣勢：劣勢非常明顯，會大大延長了產(chǎn)品上線時間。

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

優(yōu)勢：

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

缺點：

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

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

測試前的準備工作

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

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

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

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

測試報告產(chǎn)出

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

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

注：在一部分情況下，我們會將bug內(nèi)容、重現(xiàn)步驟、結(jié)果描述寫在一起，統(tǒng)一叫做bug內(nèi)容。

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

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

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

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

系列總結(jié)

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

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

需求傳達階段

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

制定開發(fā)進度與關鍵節(jié)點階段

• 給足程序猿評估項目周期的時間，目的是讓程序猿充分了解需求，需求了解后，評估時間自然而然就出來了。
• 適當?shù)慕邮艹绦蛟车慕ㄗh，需要砍需求的時候，不要猶豫。
• 確定開發(fā)順序，為后期開發(fā)跟進與測試打好基礎。
• 明確關鍵時間節(jié)點，為項目管理提供依據(jù)。

跟進開發(fā)階段

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

產(chǎn)品測試階段

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

感謝

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

相關閱讀

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

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

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

作者：李英杰，二一教育高級產(chǎn)品經(jīng)理，主要負責題庫類產(chǎn)品的規(guī)劃與運營工作。

本文由 @李英杰 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于 CC0 協(xié)議