上一篇我們簡(jiǎn)要分析了研發(fā)測(cè)試，這一篇，我們來重點(diǎn)關(guān)注一下測(cè)試的工作內(nèi)容。

測(cè)試和產(chǎn)品經(jīng)理有什么關(guān)系？

1. 測(cè)試是最有可能發(fā)現(xiàn)產(chǎn)品問題的人，不管是功能 Bug、還是設(shè)計(jì)問題。
2. 測(cè)試前的準(zhǔn)備工作決定了測(cè)試是否完備。或者說，測(cè)試之前，測(cè)試點(diǎn)的整理和測(cè)試用例的撰寫決定了測(cè)試過程中是否會(huì)漏測(cè)、少測(cè)。
3. 測(cè)試過程決定了產(chǎn)品的質(zhì)量，而產(chǎn)品經(jīng)理需要對(duì)整個(gè)產(chǎn)品負(fù)責(zé)。因此，測(cè)試工作和產(chǎn)品經(jīng)理息息相關(guān)。
4. 產(chǎn)品經(jīng)理有時(shí)也需要參與測(cè)試過程，以保證產(chǎn)品的質(zhì)量。之前純銀在做「一罐」的時(shí)候，他就說自己在整理測(cè)試用例。

嗯，明白了測(cè)試的重要性，那就和我一起了解測(cè)試吧。

什么是測(cè)試？

如果我說最初的產(chǎn)品開發(fā)并沒有「測(cè)試」這個(gè)崗位，你會(huì)相信嗎？哈哈，不管你信不信，這都是事實(shí)。因?yàn)樽畛醯漠a(chǎn)品都比較簡(jiǎn)單，開發(fā)小哥哥自己就能搞定測(cè)試。慢慢地，產(chǎn)品越來越復(fù)雜，致使產(chǎn)品開發(fā)環(huán)節(jié)出現(xiàn)精細(xì)化分工，才導(dǎo)致了「專職測(cè)試」的出現(xiàn)。

測(cè)試這個(gè)崗位也被成為 QA（quality assurance），也就是質(zhì)量保障，主要的工作是比較或者說審核開發(fā)小哥哥寫的代碼的實(shí)際輸出和產(chǎn)品需求的預(yù)期輸入。

測(cè)試的工作內(nèi)容是什么？

Step 1：理解需求

熟悉并理解需求是測(cè)試工作得以順利進(jìn)行的基礎(chǔ)條件。如果一個(gè)測(cè)試人員不理解需求，那么之后所有的工作都有可能存在問題。舉個(gè)簡(jiǎn)單的例子，我們以計(jì)算器的 「加法」為例，看下測(cè)試的工作內(nèi)容。

Step 2：測(cè)試點(diǎn)整理

測(cè)試點(diǎn)可以簡(jiǎn)單理解為需要測(cè)試的地方，或者測(cè)試的框架。測(cè)試人員需要根據(jù)需求列出測(cè)試點(diǎn)，計(jì)算器加法需求的測(cè)試點(diǎn)如下所示：

（1）輸入驗(yàn)證

• 零
• 小數(shù)
• 負(fù)數(shù)
• 最大數(shù)
• 輸入「.」

（2）清除輸入項(xiàng)驗(yàn)證

• 輸入「被加數(shù)」時(shí)清除
• 輸入「加數(shù)」時(shí)清除
• 計(jì)算完成之后清除

（3）運(yùn)算結(jié)果驗(yàn)證

• 整數(shù)運(yùn)算
• 小數(shù)運(yùn)算
• 負(fù)數(shù)運(yùn)算

（4）邊界驗(yàn)證

• 最大值與最大值相加
• 空值數(shù)值操作

Step 3：整理測(cè)試用例

（1）什么是測(cè)試用例？

測(cè)試用例「test case」是為了實(shí)施測(cè)試而向被測(cè)的產(chǎn)品提供的一組集合。簡(jiǎn)單來說，就是讓測(cè)試有章可循的方法。沒有測(cè)試用例的測(cè)試，很可能會(huì)變成隨機(jī)測(cè)試，而有測(cè)試用例之后，按照測(cè)試用例測(cè)試，會(huì)讓測(cè)試變得「正規(guī)」起來。

（2）怎么整理測(cè)試用例

測(cè)試用例的集合包括以下幾個(gè)：

• 用例編號(hào)：保證唯一。可以用數(shù)字 + 字母組合，最好采用統(tǒng)一的規(guī)定，方便閱讀和理解，管理起來也很方便，比如：可以采用「產(chǎn)品編號(hào)_測(cè)試點(diǎn)名_測(cè)試點(diǎn)子項(xiàng)_編號(hào)」。
• 功能模塊（測(cè)試點(diǎn)）：可以根據(jù)需求填寫功能模塊或者測(cè)試點(diǎn)。
• 重要程度：重要程度或者優(yōu)先級(jí)均可。用「高」、「中」、「低」代表即可。「高」代表對(duì)產(chǎn)品非常重要（使用頻率較高或者是產(chǎn)品的基本功能），「低」代表可有可無、不是很重要的模塊或功能。
• 前置條件：執(zhí)行當(dāng)前測(cè)試用例的前提條件，比如：測(cè)試一部手機(jī)的功能，前置條件是「手機(jī)開機(jī)」?！盖爸脳l件」可以用文字說明，也可以用測(cè)試用例編號(hào)代替。
• 測(cè)試輸入?yún)?shù)：可以理解為測(cè)試過程中輸入的數(shù)據(jù)，比如：測(cè)試登錄時(shí)，至少需要輸入「賬號(hào)」和「密碼」兩個(gè)參數(shù)才能驗(yàn)證。
• 操作步驟：測(cè)試人員是怎樣一步一步執(zhí)行這個(gè)測(cè)試用例的，需要給出完整的操作步驟。有的時(shí)候，「測(cè)試輸入?yún)?shù)」和「操作步驟」也會(huì)合并為「操作步驟」，會(huì)寫成「輸入 0 」。
• 預(yù)期輸出：執(zhí)行操作用例時(shí)，期望的結(jié)果是什么。這個(gè)主要是用來和實(shí)際結(jié)果相比較，以判斷該測(cè)試用例是否應(yīng)該通過。輸出可以說明：（1）界面的變化；（2）數(shù)據(jù)庫的變化；（3）相關(guān)信息的變化。
• 備注：除以上信息之外的其它信息。

然后，再根據(jù)測(cè)試點(diǎn)將以上集合進(jìn)行整理，就能得到「測(cè)試用例」，如下所示：

Step 4：測(cè)試 + Bug 管理

測(cè)試過程中，難免會(huì)遇到 Bug，那為什么要叫 Bug 呢？

（1）為什么叫「Bug」？

據(jù)說，1945 年的某一天，一只小飛蛾鉆進(jìn)了計(jì)算機(jī)電路里，導(dǎo)致系統(tǒng)無法工作，一位名叫格蕾絲·赫柏的人把飛蛾拍死在工作日志上（見圖），寫道：就是這個(gè) bug（蟲子），害我們今天的工作無法完成——于是，bug 一詞成了電腦系統(tǒng)程序的專業(yè)術(shù)語，形容那些系統(tǒng)中的缺陷或問題。

—— 來源：網(wǎng)絡(luò)，如知曉來源，請(qǐng)告知。

以下內(nèi)容摘自美國海軍網(wǎng)站（Naval History & Heritage Command）：

The following image shows an organism of great historic significance, reportedly first identified and named by Lieutenant Grace Murray Hopper while she was on Navy active duty in 1947.

下面這張畫展示了一個(gè)有偉大歷史意義的生物，由格蕾絲·穆雷·霍波上尉首次確認(rèn)并命名，1947年，格蕾絲正在海軍服役。

（2）Bug 的一生——狀態(tài)流轉(zhuǎn)

當(dāng)測(cè)試發(fā)現(xiàn)一個(gè)功能不滿足需求的時(shí)候，需要判斷是否為 Bug，如果是 Bug，就需要提交 Bug。提交的時(shí)候需要通知研發(fā)或產(chǎn)品負(fù)責(zé)人，由負(fù)責(zé)人來將 Bug 分給對(duì)應(yīng)的研發(fā)。

研發(fā)接到 Bug 之后，需要人為判斷是否為 Bug：如果不是 Bug，則需要和測(cè)試、產(chǎn)品溝通，然后關(guān)閉 Bug。如果是 Bug，需要修復(fù)。修復(fù)完成之后，提交代碼，并備注 Bug 編號(hào)，然后更改 Bug 狀態(tài)為已修復(fù)。

接下來由測(cè)試人員驗(yàn)證 Bug 是否修復(fù)，如果修復(fù)，則測(cè)試人員需要關(guān)閉 Bug；如果未修復(fù)，則測(cè)試人員需要更改 Bug 狀態(tài)為「驗(yàn)證未通過」，該 Bug 重新恢復(fù)到未修復(fù)狀態(tài)。

（3）正確地提 Bug

為什么要提 Bug？

因?yàn)橐岄_發(fā)小哥哥親眼看到錯(cuò)誤。但是很多時(shí)候，做不到親自做給他們看，那就只能給他們能使程序出錯(cuò)的詳細(xì)的操作步驟，也就是提 bug。提 Bug 時(shí)，需要清楚地描述以下幾點(diǎn)：

1）Bug 標(biāo)題：【Bug 所在模塊】Bug 簡(jiǎn)要描述

2）Bug 相關(guān)信息：

• 測(cè)試設(shè)備：操作系統(tǒng)（PC 端）/ 手機(jī)型號(hào)（移動(dòng)端）
• 測(cè)試環(huán)境：瀏覽器及版本號(hào)（PC 端）/ Wi-Fi 、4G、5G（移動(dòng)端）
• 產(chǎn)品版本：版本號(hào)。到底是 1.1.0 發(fā)現(xiàn)的問題，還是 1.2.0 發(fā)現(xiàn)的問題。
• 重現(xiàn)步驟：需要闡述發(fā)現(xiàn) Bug 并復(fù)現(xiàn) Bug 的步驟，如果一個(gè) Bug 沒法復(fù)現(xiàn)，研發(fā)大概率是無法修復(fù)的。
• 截圖：如果有的畫，需要填寫。
• 復(fù)現(xiàn)概率：簡(jiǎn)單說，就是你試來幾次，出錯(cuò)了幾次。
• 預(yù)期結(jié)果：期望的結(jié)果是什么。比如，1+1 = 2，「2」就是預(yù)期結(jié)果。
• 實(shí)際結(jié)果：實(shí)際的結(jié)果是什么。比如，當(dāng)前 1+1 =3，「3」就是實(shí)際結(jié)果。

3）Bug 指派人：Bug 指派人，也就是說，這個(gè) Bug 是由誰來修復(fù)的。沒有指派人的 Bug，大概率是不會(huì)被修復(fù)的，因?yàn)樨?zé)任人不明確。

4）Bug 提交人：嗯，是的，這是一句正確的廢話。如果是用軟件來管理 Bug 的話，天然就會(huì)有 Bug 提交人。但如若不是使用軟件的話，提 Bug 的時(shí)候千萬不要忘記這一項(xiàng)。Bug 提交人的存在，方便團(tuán)隊(duì)成員在對(duì)這個(gè) Bug 有疑問的時(shí)候，能找到正確的人詢問相關(guān)細(xì)節(jié)。

（4）提完 Bug 之后？

靜待研發(fā)修復(fù)，然后逐個(gè)回歸 Bug，同時(shí)需要觀察是否還有其它 Bug。如果從 Bug 的角度來看測(cè)試，測(cè)試可以被描述為：無數(shù) Bug 從被發(fā)現(xiàn)到被解決的過程?？杀氖牵恍?Bug 會(huì)永遠(yuǎn)留在 backlog（可以理解為待辦事項(xiàng)）里無人問津。

總結(jié)

1. 測(cè)試的分類

產(chǎn)品經(jīng)理了解概念即可。

• 按測(cè)試所屬的開發(fā)階段分為：?jiǎn)卧獪y(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試。
• 按測(cè)試時(shí)是否需要查看代碼分為：黑盒測(cè)試、白盒測(cè)試、灰盒測(cè)試。
• 按測(cè)試是否手動(dòng)執(zhí)行分為：手工測(cè)試、自動(dòng)化測(cè)試。
• 按測(cè)試類型分為：功能測(cè)試、性能測(cè)試、部署測(cè)試、文檔測(cè)試、安全測(cè)試、兼容性測(cè)試、易用性測(cè)試、本地化測(cè)試、無障礙測(cè)試、可靠性測(cè)試。
• 其它測(cè)試分類：回歸測(cè)試、冒煙測(cè)試、Monkey 測(cè)試、A/B 測(cè)試

2. Bug 分類

Bug 分類每個(gè)公司的要求時(shí)不一樣的，找到適合自己的就行。常見的 Bug 分類有按優(yōu)先級(jí)分類（高、中、低）、按功能模塊分類（登錄注冊(cè)、訂單、UI、權(quán)限、數(shù)據(jù)等）、按 Bug 產(chǎn)生原因（編碼、其它、理解偏差、需求變更、需求遺漏）等。

3. 測(cè)試用例有什么用？

測(cè)試用例是測(cè)試過程的參考手冊(cè)，方便測(cè)試人員理清測(cè)試過程及測(cè)試步驟，為后續(xù)的測(cè)試提供參考依據(jù)。

試想如果沒有整理測(cè)試用例，是不是測(cè)試人員想測(cè)什么就測(cè)什么，毫無章法可言、也沒辦法向別人解釋你為啥需要這么久。同時(shí)，提供完備的測(cè)試用例，還能在你被調(diào)離或者新測(cè)試加入的時(shí)候，方便別人快速投入工作。當(dāng)然，測(cè)試用例的編寫是很消耗人力和時(shí)間的。但即便如此，我還是建議花時(shí)間編寫，畢竟「磨刀不誤砍柴工」。

測(cè)試人員每執(zhí)行一個(gè)測(cè)試用例，都需要更新測(cè)試用例的狀態(tài)，如下表所示：

至于測(cè)試用例要不要關(guān)聯(lián) Bug，因團(tuán)隊(duì)而異。

4. 寫測(cè)試用例的時(shí)候發(fā)現(xiàn)測(cè)試點(diǎn)寫漏了，怎么辦？

在不熟悉產(chǎn)品或者經(jīng)驗(yàn)不足的測(cè)試人員身上經(jīng)常會(huì)出現(xiàn)，不過，不用擔(dān)心，這都是小事！直接把測(cè)試點(diǎn)補(bǔ)上就行。隨著對(duì)產(chǎn)品越來越熟悉或者經(jīng)驗(yàn)越來越豐富，這種情況就應(yīng)該減少。

什么？做為一個(gè)工作 N 年以上的「老測(cè)試」，你還經(jīng)常出現(xiàn)？那我只能說，前面有堵墻，你去墻前邊站站吧。怎樣才能不漏測(cè)試用例，在理解需求的基礎(chǔ)上檢查，檢查，再檢查。

5. 部分 Bug 未解決，能上線嗎？

首先，問自己：

• 這個(gè) Bug 重要嗎？影響核心流程或者核心用戶嗎？
• 改這個(gè) Bug 需要多久？（修 Bug 時(shí)間 + 測(cè)試時(shí)間）* 系數(shù)。文案 Bug 的系數(shù)為 1，其它 Bug 需要視情況而定。
• 上線時(shí)間是什么時(shí)候？

最后，再做決定。如果 Bug 不重要，修復(fù)很耗時(shí)且不確定是否會(huì)引起其它 Bug，離上線時(shí)間很近，且不能延期，那只能下次改。其它沒有規(guī)則，只能產(chǎn)品經(jīng)理自己判斷。判斷錯(cuò)了怎么辦，總結(jié)經(jīng)驗(yàn)下次不要再做錯(cuò)決定就行。

6. Bug 未解決，測(cè)試的工作算完成嗎？

這個(gè)就牽扯到「工作完成的定義」，測(cè)試的工作如果從產(chǎn)品的角度來看，一個(gè)版本上線就算這個(gè)版本的工作完成。換句話說，如果這個(gè) Bug 未解決，并且產(chǎn)品經(jīng)理決定這個(gè)版本不解決，那這個(gè) Bug 就不屬于當(dāng)前版本的管理范圍。

也就是說，這個(gè) Bug 解決與否，只要產(chǎn)品按時(shí)上線，測(cè)試這個(gè)版本的工作就算完成，但是如果從 Bug 的角度來看，測(cè)試需要跟蹤 Bug 修復(fù)直至上線甚至是用戶反饋過程這個(gè)完整的流程，測(cè)試的工作才算完成。

7. Bug 無法復(fù)現(xiàn)怎么辦？

首先我們來看下，哪些原因會(huì)導(dǎo)致 Bug 無法復(fù)現(xiàn)：

• 版本：A 版本上的 Bug 在 B 版本或者 C 版本上很有可能導(dǎo)致無法復(fù)現(xiàn)，但如若該 Bug 在 B 版本上已被解決，應(yīng)當(dāng)關(guān)掉這個(gè) Bug。
• 數(shù)據(jù)：產(chǎn)品里的某些數(shù)據(jù)會(huì)導(dǎo)致 Bug 的存在，如果這些數(shù)據(jù)條件不具備，導(dǎo)致 Bug 無法復(fù)現(xiàn)。盡可能還原數(shù)據(jù)，以測(cè)試 Bug 是否仍存在。
• 代碼：編碼過程中會(huì)因?yàn)楦鞣N因素導(dǎo)致 Bug 無法復(fù)現(xiàn)，此時(shí)，需要通過 code review 來定位問題。

其次，如果以上方法都已經(jīng)嘗試過，但 Bug 仍無法復(fù)現(xiàn)。此時(shí)，需要評(píng)估 Bug 的重要性以及上線時(shí)間。如果 Bug 不重要且上線時(shí)間很緊，那么只能暫時(shí)「掛起 Bug」。

也就是說，對(duì) Bug 保持關(guān)注，如果歷經(jīng)多個(gè)版本仍沒有出現(xiàn)這個(gè)問題，那么 Bug 就能關(guān)閉了。

什么？為啥要關(guān)閉這個(gè) Bug？你沒有強(qiáng)迫癥？看著不難受？覺得無所謂？如果這些都沒有，難道你不擔(dān)心 Bug 堆成山，領(lǐng)導(dǎo)誤以為你的工作沒完成？

什么，你不在乎，那只能說“大佬，打擾了～”

下一篇我們將繼續(xù)關(guān)注「上線」，敬請(qǐng)期待。好的，今天這篇文章到這里就結(jié)束了，我們的《一個(gè)項(xiàng)目帶你走進(jìn)產(chǎn)品經(jīng)理的世界》系列文章完成進(jìn)度如下：

黃色為當(dāng)前進(jìn)度：

相關(guān)閱讀

一個(gè)項(xiàng)目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（1）：從收到一個(gè)需求談起

一個(gè)項(xiàng)目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（2）：需求分析

一個(gè)項(xiàng)目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（3）：從用戶需求到產(chǎn)品功能

一個(gè)項(xiàng)目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（4）：產(chǎn)品規(guī)劃

一個(gè)項(xiàng)目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（5）第一個(gè)版本：MVP ？MDP ？

一個(gè)項(xiàng)目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（6）：設(shè)計(jì)確認(rèn)

一個(gè)項(xiàng)目帶你走進(jìn)產(chǎn)品經(jīng)理的世界（7）：研發(fā)測(cè)試

#專欄作家#

佐珥，微信公眾號(hào)：產(chǎn)品碎月（ID：pm_lab），人人都是產(chǎn)品經(jīng)理專欄作家，專注互聯(lián)網(wǎng)產(chǎn)品，樂于通過幽默詼諧、圖文并茂、結(jié)合實(shí)際的文字分享自己的產(chǎn)品經(jīng)驗(yàn)，期望同大家一起快樂成長

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

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