一個項目帶你走進產品經理的世界(8):你真的了解測試嗎?

15天0基礎極速入門數據分析,掌握一套數據分析流程和方法,學完就能寫一份數據報告!了解一下>>

上一篇我們簡要分析了研發測試,這一篇,我們來重點關注一下測試的工作內容。

測試和產品經理有什么關系?

  1. 測試是最有可能發現產品問題的人,不管是功能 Bug、還是設計問題。
  2. 測試前的準備工作決定了測試是否完備。或者說,測試之前,測試點的整理和測試用例的撰寫決定了測試過程中是否會漏測、少測。
  3. 測試過程決定了產品的質量,而產品經理需要對整個產品負責。因此,測試工作和產品經理息息相關。
  4. 產品經理有時也需要參與測試過程,以保證產品的質量。之前純銀在做「一罐」的時候,他就說自己在整理測試用例。

嗯,明白了測試的重要性,那就和我一起了解測試吧。

什么是測試?

如果我說最初的產品開發并沒有「測試」這個崗位,你會相信嗎?哈哈,不管你信不信,這都是事實。因為最初的產品都比較簡單,開發小哥哥自己就能搞定測試。慢慢地,產品越來越復雜,致使產品開發環節出現精細化分工,才導致了「專職測試」的出現。

測試這個崗位也被成為 QA(quality assurance),也就是質量保障,主要的工作是比較或者說審核開發小哥哥寫的代碼的實際輸出和產品需求的預期輸入。

測試的工作內容是什么?

Step 1:理解需求

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

Step 2:測試點整理

測試點可以簡單理解為需要測試的地方,或者測試的框架。測試人員需要根據需求列出測試點,計算器加法需求的測試點如下所示:

(1)輸入驗證

  • 小數
  • 負數
  • 最大數
  • 輸入「.」

(2)清除輸入項驗證

  • 輸入「被加數」時清除
  • 輸入「加數」時清除
  • 計算完成之后清除

(3)運算結果驗證

  • 整數運算
  • 小數運算
  • 負數運算

(4)邊界驗證

  • 最大值與最大值相加
  • 空值數值操作

Step 3:整理測試用例

(1)什么是測試用例?

測試用例「test case」是為了實施測試而向被測的產品提供的一組集合。簡單來說,就是讓測試有章可循的方法。沒有測試用例的測試,很可能會變成隨機測試,而有測試用例之后,按照測試用例測試,會讓測試變得「正規」起來。

(2)怎么整理測試用例

測試用例的集合包括以下幾個:

  • 用例編號:保證唯一。可以用數字 + 字母組合,最好采用統一的規定,方便閱讀和理解,管理起來也很方便,比如:可以采用「產品編號_測試點名_測試點子項_編號」。
  • 功能模塊(測試點):可以根據需求填寫功能模塊或者測試點。
  • 重要程度:重要程度或者優先級均可。用「高」、「中」、「低」代表即可。「高」代表對產品非常重要(使用頻率較高或者是產品的基本功能),「低」代表可有可無、不是很重要的模塊或功能。
  • 前置條件:執行當前測試用例的前提條件,比如:測試一部手機的功能,前置條件是「手機開機」。「前置條件」可以用文字說明,也可以用測試用例編號代替。
  • 測試輸入參數:可以理解為測試過程中輸入的數據,比如:測試登錄時,至少需要輸入「賬號」和「密碼」兩個參數才能驗證。
  • 操作步驟:測試人員是怎樣一步一步執行這個測試用例的,需要給出完整的操作步驟。有的時候,「測試輸入參數」和「操作步驟」也會合并為「操作步驟」,會寫成「輸入 0 」。
  • 預期輸出:執行操作用例時,期望的結果是什么。這個主要是用來和實際結果相比較,以判斷該測試用例是否應該通過。輸出可以說明:(1)界面的變化;(2)數據庫的變化;(3)相關信息的變化。
  • 備注:除以上信息之外的其它信息。

然后,再根據測試點將以上集合進行整理,就能得到「測試用例」,如下所示:

Step 4:測試 + Bug 管理

測試過程中,難免會遇到 Bug,那為什么要叫 Bug 呢?

(1)為什么叫「Bug」?

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

—— 來源:網絡,如知曉來源,請告知。

以下內容摘自美國海軍網站(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.

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

(2)Bug 的一生——狀態流轉

當測試發現一個功能不滿足需求的時候,需要判斷是否為 Bug,如果是 Bug,就需要提交 Bug。提交的時候需要通知研發或產品負責人,由負責人來將 Bug 分給對應的研發。

研發接到 Bug 之后,需要人為判斷是否為 Bug:如果不是 Bug,則需要和測試、產品溝通,然后關閉 Bug。如果是 Bug,需要修復。修復完成之后,提交代碼,并備注 Bug 編號,然后更改 Bug 狀態為已修復。

接下來由測試人員驗證 Bug 是否修復,如果修復,則測試人員需要關閉 Bug;如果未修復,則測試人員需要更改 Bug 狀態為「驗證未通過」,該 Bug 重新恢復到未修復狀態。

(3)正確地提 Bug

為什么要提 Bug?

因為要讓開發小哥哥親眼看到錯誤。但是很多時候,做不到親自做給他們看,那就只能給他們能使程序出錯的詳細的操作步驟,也就是提 bug。提 Bug 時,需要清楚地描述以下幾點:

1)Bug 標題:【Bug 所在模塊】Bug 簡要描述

2)Bug 相關信息

  • 測試設備:操作系統(PC 端)/ 手機型號(移動端)
  • 測試環境:瀏覽器及版本號(PC 端)/ Wi-Fi 、4G、5G(移動端)
  • 產品版本:版本號。到底是 1.1.0 發現的問題,還是 1.2.0 發現的問題。
  • 重現步驟:需要闡述發現 Bug 并復現 Bug 的步驟,如果一個 Bug 沒法復現,研發大概率是無法修復的。
  • 截圖:如果有的畫,需要填寫。
  • 復現概率:簡單說,就是你試來幾次,出錯了幾次。
  • 預期結果:期望的結果是什么。比如,1+1 = 2,「2」就是預期結果。
  • 實際結果:實際的結果是什么。比如,當前 1+1 =3,「3」就是實際結果。

3)Bug 指派人:Bug 指派人,也就是說,這個 Bug 是由誰來修復的。沒有指派人的 Bug,大概率是不會被修復的,因為責任人不明確。

4)Bug 提交人:嗯,是的,這是一句正確的廢話。如果是用軟件來管理 Bug 的話,天然就會有 Bug 提交人。但如若不是使用軟件的話,提 Bug 的時候千萬不要忘記這一項。Bug 提交人的存在,方便團隊成員在對這個 Bug 有疑問的時候,能找到正確的人詢問相關細節。

(4)提完 Bug 之后?

靜待研發修復,然后逐個回歸 Bug,同時需要觀察是否還有其它 Bug。如果從 Bug 的角度來看測試,測試可以被描述為:無數 Bug 從被發現到被解決的過程。可悲的是,一些 Bug 會永遠留在 backlog(可以理解為待辦事項)里無人問津。

總結

1. 測試的分類

產品經理了解概念即可。

  • 按測試所屬的開發階段分為:單元測試、集成測試、系統測試、驗收測試。
  • 按測試時是否需要查看代碼分為:黑盒測試、白盒測試、灰盒測試。
  • 按測試是否手動執行分為:手工測試、自動化測試。
  • 按測試類型分為:功能測試、性能測試、部署測試、文檔測試、安全測試、兼容性測試、易用性測試、本地化測試、無障礙測試、可靠性測試。
  • 其它測試分類:回歸測試、冒煙測試、Monkey 測試、A/B 測試

2. Bug 分類

Bug 分類每個公司的要求時不一樣的,找到適合自己的就行。常見的 Bug 分類有按優先級分類(高、中、低)、按功能模塊分類(登錄注冊、訂單、UI、權限、數據等)、按 Bug 產生原因(編碼、其它、理解偏差、需求變更、需求遺漏)等。

3. 測試用例有什么用?

測試用例是測試過程的參考手冊,方便測試人員理清測試過程及測試步驟,為后續的測試提供參考依據。

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

測試人員每執行一個測試用例,都需要更新測試用例的狀態,如下表所示:

至于測試用例要不要關聯 Bug,因團隊而異。

4. 寫測試用例的時候發現測試點寫漏了,怎么辦?

在不熟悉產品或者經驗不足的測試人員身上經常會出現,不過,不用擔心,這都是小事!直接把測試點補上就行。隨著對產品越來越熟悉或者經驗越來越豐富,這種情況就應該減少。

什么?做為一個工作 N 年以上的「老測試」,你還經常出現?那我只能說,前面有堵墻,你去墻前邊站站吧。怎樣才能不漏測試用例,在理解需求的基礎上檢查,檢查,再檢查。

5. 部分 Bug 未解決,能上線嗎?

首先,問自己:

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

最后,再做決定。如果 Bug 不重要,修復很耗時且不確定是否會引起其它 Bug,離上線時間很近,且不能延期,那只能下次改。其它沒有規則,只能產品經理自己判斷。判斷錯了怎么辦,總結經驗下次不要再做錯決定就行。

6. Bug 未解決,測試的工作算完成嗎?

這個就牽扯到「工作完成的定義」,測試的工作如果從產品的角度來看,一個版本上線就算這個版本的工作完成。換句話說,如果這個 Bug 未解決,并且產品經理決定這個版本不解決,那這個 Bug 就不屬于當前版本的管理范圍。

也就是說,這個 Bug 解決與否,只要產品按時上線,測試這個版本的工作就算完成,但是如果從 Bug 的角度來看,測試需要跟蹤 Bug 修復直至上線甚至是用戶反饋過程這個完整的流程,測試的工作才算完成。

7. Bug 無法復現怎么辦?

首先我們來看下,哪些原因會導致 Bug 無法復現:

  • 版本:A 版本上的 Bug 在 B 版本或者 C 版本上很有可能導致無法復現,但如若該 Bug 在 B 版本上已被解決,應當關掉這個 Bug。
  • 數據:產品里的某些數據會導致 Bug 的存在,如果這些數據條件不具備,導致 Bug 無法復現。盡可能還原數據,以測試 Bug 是否仍存在。
  • 代碼:編碼過程中會因為各種因素導致 Bug 無法復現,此時,需要通過 code review 來定位問題。

其次,如果以上方法都已經嘗試過,但 Bug 仍無法復現。此時,需要評估 Bug 的重要性以及上線時間。如果 Bug 不重要且上線時間很緊,那么只能暫時「掛起 Bug」。

也就是說,對 Bug 保持關注,如果歷經多個版本仍沒有出現這個問題,那么 Bug 就能關閉了。

什么?為啥要關閉這個 Bug?你沒有強迫癥?看著不難受?覺得無所謂?如果這些都沒有,難道你不擔心 Bug 堆成山,領導誤以為你的工作沒完成?

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

下一篇我們將繼續關注「上線」,敬請期待。好的,今天這篇文章到這里就結束了,我們的《一個項目帶你走進產品經理的世界》系列文章完成進度如下:

黃色為當前進度:

 

相關閱讀

一個項目帶你走進產品經理的世界(1):從收到一個需求談起

一個項目帶你走進產品經理的世界(2):需求分析

一個項目帶你走進產品經理的世界(3):從用戶需求到產品功能

一個項目帶你走進產品經理的世界(4):產品規劃

一個項目帶你走進產品經理的世界(5)第一個版本:MVP ?MDP ?

一個項目帶你走進產品經理的世界(6):設計確認

一個項目帶你走進產品經理的世界(7):研發測試

#專欄作家#

佐珥,微信公眾號:產品碎月(ID:pm_lab),人人都是產品經理專欄作家,專注互聯網產品,樂于通過幽默詼諧、圖文并茂、結合實際的文字分享自己的產品經驗,期望同大家一起快樂成長

本文原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
2人打賞
評論
歡迎留言討論~!
  1. 測試和QA不能直接劃等號,還是有區別的。

    回復
  2. 想知道小姐姐的手繪圖是用什么畫的呀?好好看!

    回復
  3. 期待后續!

    回復
  4. 在一個曾經專職做測試的人的眼中看來,你寫的已經很全面了,贊一個~~~

    回復
  5. 贊~

    回復
  6. 總結的非常好!

    回復
  7. 謝謝

    回復
  8. :mrgreen:

    回復
马总会三肖中特