什么是產(chǎn)品測試？測試可歸為兩點：程序做了它應(yīng)該做的事情；程序沒有做它不該做的事情。

1、寫在前面

文章主要涉及產(chǎn)品經(jīng)理工作上經(jīng)常接觸到的基礎(chǔ)的測試知識，包括測試的定義、測試何時進行、產(chǎn)品經(jīng)理應(yīng)該懂的測試概念、產(chǎn)品經(jīng)理如何測試驗收產(chǎn)品。

2、為什么產(chǎn)品經(jīng)理需要懂測試

產(chǎn)品每個階段都有驗收標準，比如需求評審階段驗收、開發(fā)階段驗收，所以每個階段都需要測試。產(chǎn)品經(jīng)理盡管不是專業(yè)的測試人員，但產(chǎn)品經(jīng)理作為最熟悉產(chǎn)品的人，理應(yīng)對產(chǎn)品每個階段都進行相應(yīng)的測試驗收產(chǎn)品，比如功能測試、可用性測試、用戶體驗測試，確保符合需求文檔的要求，所以產(chǎn)品經(jīng)理應(yīng)該懂得相應(yīng)的測試知識。

產(chǎn)品經(jīng)理懂測試，在相應(yīng)的測試方式中驗收產(chǎn)品的時候，能更清楚的系統(tǒng)地記錄產(chǎn)品的每個問題，然后用產(chǎn)品思維去思考如何解決這些問題。

可以用極簡主義去思考如何把選擇復(fù)雜的問題簡單化減少用戶的選擇，比如刻意顯示引導(dǎo)用戶選擇的功能按鈕或隱藏用戶很少用到的功能，比如微信用戶很少用到的朋友圈停用的功能，使用路徑刻意加深隱藏。

可以用可用性原則的思維去思考如何去引導(dǎo)用戶更好的完成產(chǎn)品使用，比如頁面說明該頁面所處的位置狀態(tài)，比如微信的朋友圈頁面頂部顯示朋友圈的位置說明。

可以用情感化設(shè)計的思維去思考如何超出用戶的期望，比如微信聊天窗口發(fā)送我想你了會落下滿天星星的效果超出用戶的期望。

可以用可行性的思維去思考如何用現(xiàn)有的資源解決產(chǎn)品的問題，比如前端工程師人數(shù)少的情況下可以直接借助前端開源框架快速開發(fā)MVP，比如借助bootstrap。

還可以去和開發(fā)人員溝通如何解決app使用卡頓啟動難加載緩慢等產(chǎn)品本身的性能問題，比如使用網(wǎng)易新聞app滑動時卡頓，開發(fā)人員會告訴你其中的一個原因是因為每個頁面上承受的控件過多，app一個頁面看起來的效果是一個平面，但app中一個頁面的組成由webview或者文本框等多個控件布局疊加的，控件過多會占用內(nèi)存，導(dǎo)致使用卡頓，這時你可以思考如何去平衡控件數(shù)量和卡頓體驗問題。

所以懂得測試，產(chǎn)品經(jīng)理能更好地溝通，能更好地測試驗收產(chǎn)品確保符合產(chǎn)品需求文檔，能更好地解決和優(yōu)化產(chǎn)品。

產(chǎn)品經(jīng)理不應(yīng)該只為一個產(chǎn)品設(shè)計而不為一個產(chǎn)品測試。

補充說明：網(wǎng)易新聞app使用卡頓的原因之控件

以android為例，首先打開顯示布局邊界，在開發(fā)者選項里可以找到顯示布局邊界，打開。然后再打開網(wǎng)易新聞，如下圖，你會看到界面布滿各種邊界，每個邊界都是一個控件，控件可以包括控件，所以你會看到大邊界包括小邊界。如下圖所示：

當然有些為了使用流暢度，會采用webview控件，就相當于調(diào)用一個網(wǎng)頁顯示內(nèi)容的控件，但是也影響使用用戶體驗，內(nèi)容加載慢，目前利用cache緩存技術(shù)提供離線功能，預(yù)加載。新聞詳情的大邊界就是一個webview，如下圖所示：

一些建議：

原生UI應(yīng)用場景：

• 流暢度體驗要求高的
• UI樣式相對固定
• 交互復(fù)雜

webview的HTML5頁面應(yīng)用場景：

• 活動運營的頁面需求，可重復(fù)調(diào)用
• 交互簡單

3、測試的定義

測試，顧名思義就是測試程序保證其可正確運行。而早期的測試定義就是如此，即對程序能夠按預(yù)期運行建立起一種信心。隨著技術(shù)的發(fā)展，目前測試的經(jīng)典定義是，在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)程序錯誤，衡量軟件質(zhì)量，并對其是否能滿足設(shè)計要求進行評估的過程。即運行程序發(fā)現(xiàn)錯誤。

目前普遍使用行業(yè)標準IEEE/ANSI的測試定義：使用人工或自動的手段來運行或測定某個軟件系統(tǒng)的過程，其目的在于檢驗它是否滿足規(guī)定的需求或弄清預(yù)期結(jié)果與實際結(jié)果之間的差別。目的是為了檢驗軟件系統(tǒng)是否滿足需求。

從以上我們可以看出，不管怎么定義，測試既需要程序能符合需求文檔的要求運行，也不能產(chǎn)生錯誤，測試可以歸為兩點：程序做了它應(yīng)該做的事情；程序沒有做它不該做的事情。

注意，軟件測試不等于程序測試，測試的對象包括文檔、數(shù)據(jù)、程序。

4、測試何時進行

我們看看一張發(fā)現(xiàn)缺陷的時間和缺陷修復(fù)成本的關(guān)系圖，下圖，其中，橫軸表示項目開發(fā)周期時間階段，縱軸表示缺陷占比。如下圖所示：

從圖中，我們可以看出越后期修復(fù)缺陷的成本就越高，且指數(shù)增長，而缺陷主要是開發(fā)前期引入的，且前期缺陷修復(fù)成本很低，所以我們應(yīng)該知道，測試越早越好。

前面說過，測試的對象包括文檔、數(shù)據(jù)、程序，即測試貫穿軟件開發(fā)開發(fā)周期，從需求開始到編碼到驗收測試結(jié)束，包括但不限于對需求、概要設(shè)計、詳細設(shè)計、源碼、可運行程序、運行環(huán)境的測試。所以，產(chǎn)品經(jīng)理應(yīng)該從需求開始階段就進行測試產(chǎn)品，當然，專門的測試人員也應(yīng)該從需求開始階段就參與測試，產(chǎn)品的相關(guān)人員越早參與進來，對產(chǎn)品的需求理解就越透徹，還可以對需求二次分析補充。

當然這里我們主要講產(chǎn)品程序可運行后的相關(guān)測試，畢竟編碼前的需求評審、原型、UE、UI的測試，這是每個產(chǎn)品經(jīng)理必須具備的技能，編碼期間的單元測試集成測試主要是開發(fā)人員實施，所以我們主要是討論產(chǎn)品程序可運行后的相關(guān)測試。

產(chǎn)品程序可運行后開發(fā)人員交付build給產(chǎn)品經(jīng)理和測試人員的測試流程一般為用例測試（是否符合需求文檔）、探索測試（是否存在隱患bug）、其他測試（兼容性、安全性……）。

補充說明：編碼前的需求評審、原型、UE、UI的測試重點：

• 需求評審：定位、用戶畫像、說明規(guī)則是否明確；
• 原型：頁面是否完整，信息架構(gòu)是否清晰；
• UE：業(yè)務(wù)流程是否舒適；
• UI：視覺設(shè)計是否干凈，風(fēng)格是否一致；

這些編碼前的測試一定要驗收，因為會直接影響到產(chǎn)品開發(fā)的后續(xù)，比如UI測試的視覺設(shè)計，直接影響到目標產(chǎn)品的整個生命周期的視覺效果。

5、產(chǎn)品經(jīng)理應(yīng)該懂的測試概念

產(chǎn)品經(jīng)理和測試人員溝通需求或者反饋產(chǎn)品的bug時，經(jīng)常聽到測試人員說的腳本錄制及自動化測試的一些測試概念上名詞，經(jīng)常會說什么這個功能模塊采用黑盒測試的流程分析法就知道bug的位置了，這個時候產(chǎn)品經(jīng)理就懵逼，感覺溝通不下去了，產(chǎn)品做不下去了。

產(chǎn)品經(jīng)理懂得崗位的相關(guān)上下游知識，可以更好的處理好工作，比如和測試人員溝通需求時，測試人員會說文檔測試通過了嗎，或者說這個等到集成測試后再系統(tǒng)測試驗證這個問題吧，這些測試上的名詞，如果你懂的話，那么溝通起來就會很順利，你就不會去問什么是文檔測試，什么是集成測試，既節(jié)約時間，更主要可以讓產(chǎn)品的相關(guān)人員都能清楚地理解需求。

所以，這里我們講講產(chǎn)品經(jīng)理一般接觸到的測試概念。

測試一般是隨著項目開發(fā)周期進行，根據(jù)開發(fā)模型對應(yīng)相應(yīng)的測試模式，比如瀑布開發(fā)模型的測試模式。測試分類有多個維度分類，比如根據(jù)測試階段、測試手段、測試模塊的維度分類，每個測試分類都有相應(yīng)的測試辦法，比如系統(tǒng)測試、白盒測試、黑盒測試、自動化測試。

目前，我們最常用的開發(fā)模型是V模型，如下圖所示：

所以我們主要是根據(jù)V模型講講解測試知識。

V模型是按測試階段來分類測試，分為單元測試、集成測試、系統(tǒng)測試、驗收測試，這也是根據(jù)開發(fā)進度進行的測試分類。

單元測試：又稱模塊測試，是針對軟件設(shè)計的最小單位 ─ 程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。由開發(fā)人員實施，用以檢驗所開發(fā)的代碼功能符合設(shè)計要求。單元測試是其他測試的基礎(chǔ)，單元測試用例代碼和函數(shù)一對一，便于維護和實現(xiàn)條件覆蓋與路徑覆蓋，可以盡早發(fā)現(xiàn)缺陷和利于重構(gòu)，但一行代碼需要3-5行測試代碼才能完成單元測試，支出較大，典型的空間換取利益，所以需要權(quán)衡。

單元測試有相應(yīng)的測試框架，比如Xunit、Junit、PHPunit。我們平時接觸的敏捷開發(fā)比較強調(diào)TDD（測試驅(qū)動開發(fā)），即在開發(fā)功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什么產(chǎn)品代碼。這樣能保證功能代碼的正確性，也能保證對需求的二次確認和理解，對需求設(shè)計有個清晰的認識。

集成測試：也稱聯(lián)合測試，將程序模塊采用適當?shù)募刹呗越M裝起來，對系統(tǒng)的接口及集成后的功能進行正確性檢測的測試工作。其主要目的是檢查軟件單位之間的接口是否正確，集成測試的對象是已經(jīng)經(jīng)過單元測試的模塊。

集成測試的主要實施方案：一次性集成方法（big bang），即一次性把所有模塊組裝起來測試；增殖式集成方式，即一個個模塊持續(xù)集成測試，最后把所有模塊組裝起來。

系統(tǒng)測試：通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認測試。系統(tǒng)測試的目的在于通過與系統(tǒng)（軟件）的需求定義作比較， 發(fā)現(xiàn)軟件與系統(tǒng)（軟件）的定義不符合或與之矛盾的地方。即把可運行的軟件安裝在真實環(huán)境下操作使用，測試軟件的功能和性能，比如某功能能否正常運行，軟件在該平臺下能否正常運行。

系統(tǒng)測試主要是從業(yè)務(wù)角度驗證產(chǎn)品是否符合需求文檔，所以，產(chǎn)品經(jīng)理測試產(chǎn)品是否符合需求文檔和設(shè)計的要求，一般都是在系統(tǒng)測試階段。當然，測試人員主要針對的也是系統(tǒng)測試階段。

驗收測試：也稱交付測試，以用戶為主的測試，由用戶參加設(shè)計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試，確定軟件是否滿足驗收標準，是否接受系統(tǒng)軟件。

驗收測試驅(qū)動開發(fā)，是TDD的延伸，也就是定義好用戶故事，驗收標準，再去開發(fā)功能，功能通過驗收標準，功能滿足用戶故事。

從上面的定義，我們知道產(chǎn)品經(jīng)理測試驗收產(chǎn)品一般是在系統(tǒng)測試階段，系統(tǒng)測試主要包括功能測試、界面測試、可靠性測試、易用性測試、兼容性測試、性能測試。 功能測試主要針對包括功能可用性、功能實現(xiàn)程度（功能流程&業(yè)務(wù)流程、數(shù)據(jù)處理&業(yè)務(wù)數(shù)據(jù)處理）方面測試。其中功能測試是最主要的一種測試類型，一般說測試就是功能測試。

功能測試：對產(chǎn)品的各功能進行驗證，根據(jù)功能測試用例，逐項測試，檢查產(chǎn)品是否達到用戶要求的功能。測試人員會借助一些功能測試工具，比如QTP winrunner，主要是測試業(yè)務(wù)流程。

界面測試：也稱UI測試，測試用戶界面的功能模塊的布局是否合理、整體風(fēng)格是否一致、各個控件的放置位置是否符合客戶使用習(xí)慣，此外還要測試界面操作便捷性、導(dǎo)航簡單易懂性，頁面元素的可用性，界面中文字是否正確，命名是否統(tǒng)一，頁面是否美觀，文字、圖片組合是否完美等。

可靠性測試：對軟件或者硬件的一種質(zhì)量測試，用來檢測產(chǎn)品是否存在不可靠因素，比如硬件老化。

易用性測試：指用戶使用軟件時是否感覺方便，主要特點為易理解性、易學(xué)性、易操作性、吸引性、易用的依從性，比如是否最多點擊鼠標三次就可以達到用戶的目的。易用性和可用性存在一定的區(qū)別，可用性是指是否可以使用，強調(diào)軟件可運行性，而易用性是指是否方便使用，強調(diào)用戶體驗，是交互的適應(yīng)性、功能性和有效性的集中體現(xiàn)。

兼容性測試：主要測試軟件是否能在不同的操作系統(tǒng)平臺上兼容，是否能在不同的設(shè)備上兼容；軟件本身能否向前或向后兼容；軟件能否與其他相關(guān)的軟件兼容；數(shù)據(jù)是否兼容，主要是指數(shù)據(jù)能否共享等。

性能測試：通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標進行測試。負載測試和壓力測試都屬于性能測試，兩者可以結(jié)合進行。通過負載測試，確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時，系統(tǒng)各項性能指標的變化情況。壓力測試是通過確定一個系統(tǒng)的瓶頸或者不能接受的性能點，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。

性能測試主要分為：

• 應(yīng)用在客戶端性能的測試：主要并發(fā)性能測試，利用自動化工具通過模擬成百上千用戶重復(fù)執(zhí)行和運行應(yīng)用進行黑盒測試，比如loadrunner。一般測試人員進行性能測試就是應(yīng)用在客戶端性能的測試。
• 應(yīng)用在網(wǎng)絡(luò)上性能的測試：主要網(wǎng)絡(luò)應(yīng)用性能監(jiān)控、網(wǎng)絡(luò)應(yīng)用性能分析和網(wǎng)絡(luò)預(yù)測的測試，目的是準確展示網(wǎng)絡(luò)帶寬、延遲、負載和TCP端口的變化是如何影響用戶的響應(yīng)時間的，性能的問題根源位置，會借助一些工具，比如Application Expert。
• 應(yīng)用在服務(wù)器性能的測試：目的是實現(xiàn)服務(wù)器設(shè)備、服務(wù)器操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、應(yīng)用在服務(wù)器上性能的全面監(jiān)控。

性能測試目的是驗證軟件系統(tǒng)是否能夠達到用戶提出的性能指標，同時發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，優(yōu)化軟件，最后起到優(yōu)化系統(tǒng)的目的。

補充說明：兩個插件YSlow、page speed，靜態(tài)評估網(wǎng)頁性能的插件，可以評估網(wǎng)頁性能并獲得有關(guān)如何改進性能的建議，有興趣的產(chǎn)品經(jīng)理可以了解，后期優(yōu)化產(chǎn)品時可以有底氣地和開發(fā)人員溝通。當然也有APM（應(yīng)用性能管理）對企業(yè)系統(tǒng)即時監(jiān)控以實現(xiàn)對應(yīng)用程序性能管理和故障管理的系統(tǒng)化的解決方案，比如聽云官網(wǎng)。

軟件經(jīng)過上述主要的測試后提交bug修改bug后，需要再次測試檢驗軟件是否能正常運行，也就是所謂的回歸測試。

回歸測試：修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或?qū)е缕渌a產(chǎn)生錯誤。在整個軟件測試過程中占有很大的工作量比重，軟件開發(fā)的各個階段都會進行多次回歸測試，且盡量實現(xiàn)自動化，作為自動化測試的優(yōu)先級。測試重心在關(guān)鍵模塊和重點功能模塊上。

產(chǎn)品經(jīng)理測試驗收產(chǎn)品時，主要是采用手工測試以用戶視角來測試產(chǎn)品，根據(jù)用戶需求，采用事件驅(qū)動，輸入和輸出，測試軟件系統(tǒng)的界面和功能，主要測試方向為功能、可用性、用戶體驗，所以主要是進行系統(tǒng)測試的功能測試、界面測試、可靠性測試、易用性測試、兼容性測試。而性能測試、安全測試等自動化測試由專門的測試人員實施。

另外，應(yīng)該知道測試原則的幾個主要特點：軟件測試不能保證百分百沒有缺陷，缺陷具有群集特性（即缺陷主要出現(xiàn)在有缺陷的模塊，重點關(guān)注），測試的二八原則（80%時間用在20%的重點模塊上，提升效率和資源使用率），測試活動依賴測試背景（依賴軟件的應(yīng)用背景，比如銀行金融軟件，側(cè)重安全，所以更偏向于安全性測試）。

補充說明：目前互聯(lián)網(wǎng)公司大多強調(diào)敏捷開發(fā)，所以我們講講敏捷開發(fā)及敏捷測試的知識。

敏捷開發(fā)：以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。也就是需求一直在變更，我們需要擁抱變更。主張的價值觀：溝通、簡單、反饋、勇氣、謙遜。

敏捷宣言：個體和交互 勝過 過程和工具；可以工作的軟件 勝過 面面俱到的文檔；客戶合作 勝過 合同談判；響應(yīng)變化 勝過 遵循計劃。每項對比中，雖然后者也有價值，但我們認為前者更有價值。

敏捷測試是遵循敏捷宣言的一種測試實踐：

• 強調(diào)從客戶的角度，即從使用系統(tǒng)的用戶角度，來測試系統(tǒng)。
• 重點關(guān)注持續(xù)迭代地測試新開發(fā)的功能，而不再強調(diào)傳統(tǒng)測試過程中嚴格的測試階段。
• 建議盡早開始測試，一旦系統(tǒng)某個層面可測，比如提供了模塊功能，就要開始模塊層面的單元測試，同時隨著測試深入，持續(xù)進行回歸測試保證之前測試過內(nèi)容的正確性。
• 強調(diào)持續(xù)反饋，預(yù)防缺陷勝過發(fā)現(xiàn)缺陷。

敏捷開發(fā)的好處：開發(fā)和測試人員是緊密合作，大家都有責(zé)任對軟件負責(zé)，所以產(chǎn)品更能符合需求文檔的要求。核心系統(tǒng)集成和高頻集成是敏捷開發(fā)的比較常用的測試方法。

6、產(chǎn)品經(jīng)理如何測試驗收產(chǎn)品

講完測試概念，就應(yīng)該到實踐了，即如何測試驗收產(chǎn)品。

產(chǎn)品經(jīng)理測試一個產(chǎn)品，不能用產(chǎn)品思維去測試一個產(chǎn)品，因為產(chǎn)品經(jīng)理是最熟悉產(chǎn)品的人，產(chǎn)品每一功能每一個步都知道操作流程，所以往往只能發(fā)現(xiàn)一些不符合產(chǎn)品需求功能上的bug，而會忽略真實用戶去使用的問題，比如某個功能點的使用路徑過深，導(dǎo)致用戶找不到，用戶產(chǎn)生挫敗感。

所以產(chǎn)品經(jīng)理測試驗收產(chǎn)品，除了驗收是否符合產(chǎn)品需求外，還需要發(fā)現(xiàn)產(chǎn)品的可用性、可行性、情感化設(shè)計的用戶體驗問題。因此，測試產(chǎn)品過程中，產(chǎn)品經(jīng)理需要跳出產(chǎn)品思維，轉(zhuǎn)為用戶思維，甚至轉(zhuǎn)為測試人員的思維，更廣度和深度的測試驗收。

那么如何轉(zhuǎn)為測試人員的思維呢？首先需要了解測試人員的職責(zé)及工作，這樣才能更好地了解到測試人員使用到的測試思維，才能更好地轉(zhuǎn)為測試人員的思維。

下面來看看拉勾的騰訊的測試工程師的招聘的職位要求，如下圖所示：

拋開技術(shù)層面，只從測試思維考慮，從職位要求可以看出，所以測試工程師的核心能力在于有耐心地提出挑戰(zhàn)性的相關(guān)問題，從不同的角度，驗證產(chǎn)品的可行性，善于找出錯誤讓程序不能正常運行的問題。因為帶著問題，才能發(fā)現(xiàn)問題，比如他們會問，產(chǎn)品的目的，產(chǎn)品主要在什么平臺上使用，如果不符合的數(shù)據(jù)輸入會不會發(fā)生程序崩潰，會從各種實用場景中發(fā)現(xiàn)問題。

從各種場景發(fā)現(xiàn)問題，也就是要求我們要多使用，多問“如果…會怎么樣“”為什么”的問題，畢竟找到關(guān)鍵問題的最好辦法就是提問。因為多問為什么，發(fā)散思維，也使得測試人員會從不同的用戶角度（交叉測試）去思考問題，包括毫無經(jīng)驗的用戶、很有經(jīng)驗的用戶、愛好者、黑客、競爭對手等等，產(chǎn)品的受眾越多，不同類型的用戶就越多，就需要從更多的用戶去思考問題，當然，用戶越多，其操作行為和工作流程就越多，比如隨意輸入、隨意點擊。

隨意輸入、隨意點擊，不斷和系統(tǒng)交互，帶著問題測試，也就是所謂的探索性測試，探索產(chǎn)品未被發(fā)現(xiàn)的bug的存在隱患。探索性測試，完全拋開測試腳本的測試，是一種測試風(fēng)格、思維而不是一種測試技術(shù)，分為局部性測試和全局性測試，局部性測試主要是對某個模塊進行輸入輸出的測試，全局性測試主要是像游客一樣使用軟件系統(tǒng)。

探索性測試，自由靈活會增加發(fā)現(xiàn)新的bug的可能性，執(zhí)行與設(shè)計（思考）并行，減少在簡單、繁復(fù)上用例的無謂編寫時間，不斷和系統(tǒng)交互，帶著問題測試，但更依賴系統(tǒng)完成可用的情況下才能交互使用探索，且難協(xié)調(diào)和控制，所以一般都是測試工程師采用monkey自動化測試進行探索性測試。

從上面的職責(zé)和測試人員的測試工作，我們不難看出，測試的主要思維就是帶著問題以不同用戶的不同操作流程去使用產(chǎn)品達到發(fā)現(xiàn)bug。

了解了測試思維，那么還需要了解測試的流程是怎樣的，畢竟流程是規(guī)范性的要求，保證測試能有序有目的的進行。測試的流程主要為測試計劃-測試用例-測試執(zhí)行-測試報告。

測試用例主要是測試人員根據(jù)PRD、流程圖、原型圖、UI、收集的資料來編寫，通過需求文檔了解需求背景，用戶畫像、使用場景、用戶故事，通過流程圖、原型圖了解功能需求，站在用戶角度和項目實情去思考，盡可能地覆蓋全面使用路徑。測試用例編寫之前，產(chǎn)品經(jīng)理都是最熟悉產(chǎn)品，知道產(chǎn)品的目的，即用戶故事同理心，知道產(chǎn)品主要是在什么系統(tǒng)、平臺運行，知道數(shù)據(jù)是什么類型，知道調(diào)用哪些外部的接口，知道哪些是關(guān)鍵模塊，知道產(chǎn)品的規(guī)劃，可以更快速地測試是否符合產(chǎn)品需求文檔的要求，所以產(chǎn)品經(jīng)理應(yīng)該和測試人員詳細地宣講產(chǎn)品，也就是所謂的必須進行的產(chǎn)品宣講，這樣測試人員能好地理解編寫測試用例，產(chǎn)品經(jīng)理也能借助測試人員的經(jīng)驗更好地進行測試驗收產(chǎn)品。

編寫好測試用例時，根據(jù)需求文檔的需求優(yōu)先級和風(fēng)險級別定義測試優(yōu)先級別，重點測試核心模塊，比如電商網(wǎng)站的搜索瀏覽商品和下單的完整流程是優(yōu)先級別的測試模塊。開始測試產(chǎn)品過程中，詳細寫好步驟和具體問題，問題很多類型，所以記好問題類型，當然很多問題是可以被預(yù)先確定和測試的，所以注意操作步驟及操作環(huán)境，比如是否按照正常流程操作，用戶是否打開數(shù)據(jù)網(wǎng)絡(luò)。

產(chǎn)品經(jīng)理一般是根據(jù)測試用例來測試驗收產(chǎn)品，符合驗收標準即可。測試用例可以從測試人員那里要，或者自己根據(jù)誰、怎么做、結(jié)果的用戶操作流程編寫一個符合規(guī)則的測試用例去測試，最后去思考問題的原因和解決方案，以及把測試的問題反饋給測試人員跟進和開發(fā)人員解決。測試模塊盡量獨立，覆蓋全面，減少耦合。

這里我們以微信手機號登錄功能模塊的功能測試為測試案例，講講測試步驟和測試用例。當然，不同公司的測試步驟和測試用例會有些不一樣，不過相差不大。

測試前需要準備一些測試的硬性需求，比如測試的相關(guān)數(shù)據(jù)（比如是否后臺創(chuàng)建測試賬號）、測試設(shè)備（比如iphone5、6、7）、測試需要的軟件（比如操作系統(tǒng)，瀏覽器）。

這里微信登錄功能測試的需求：數(shù)據(jù)（一個已注冊的用戶賬號密碼，一個未注冊的手機號碼），設(shè)備（一部手機），需要的軟件（android/ios）。

根據(jù)帶著問題以不同用戶的不同操作流程去使用產(chǎn)品達到發(fā)現(xiàn)bug的測試思維，編寫測試用例。

首先用腦圖列出模塊的不同用戶的不同操作流程，這樣可以覆蓋功能全面路徑。這里只列舉主要使用場景，如下圖所示：

根據(jù)PRD的用戶故事或者原型圖的規(guī)則說明列出每個功能點的驗收標準，列出每個操作流程的驗收標準，即預(yù)期結(jié)果（預(yù)期結(jié)果以微信實操的結(jié)果模擬，吐槽一下微信手機號碼輸入框沒限制號碼長度的等一系列的低級體驗問題）。在操作流程的腦圖基礎(chǔ)上補上每個故事點的驗收標準，如下圖所示：

最后根據(jù)上述的腦圖，我們可以寫出大概的測試用例列表，當然，測試列表需要補充說明一些相關(guān)信息。如下圖所示：

編寫完測試用例后，我們就可以根據(jù)測試用例逐項測試產(chǎn)品，并根據(jù)測試結(jié)果填寫測試用例列表中的測試結(jié)果，并根據(jù)預(yù)期結(jié)果和測試結(jié)果的差異，填寫是否存在缺陷，并反饋給測試人員和開發(fā)人員進行跟進和修改缺陷。至此，一個模塊功能測試就完整了，當然，修改缺陷后跟進還需要回歸測試。

補充說明：上述的基礎(chǔ)測試知識只是產(chǎn)品經(jīng)理經(jīng)常涉及到的測試知識，測試還有很多概念，比如冒煙測試、AB測試、自動化測試，測試的未來會自動化，對技術(shù)要求越來越高，所以測試是一門大學(xué)問，如果有興趣學(xué)習(xí)的產(chǎn)品經(jīng)理，可以找套教程學(xué)學(xué)。

作者：鉛筆小葵（微信號：gaokaikui ?知乎專欄：鉛筆小葵），產(chǎn)品經(jīng)理，負責(zé)產(chǎn)品從0到1的開發(fā)，曾任Java工程師，參與后臺開發(fā)。歡迎大家互相交流關(guān)注。

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