什么是產品測試？測試可歸為兩點：程序做了它應該做的事情；程序沒有做它不該做的事情。

1、寫在前面

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

2、為什么產品經理需要懂測試

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

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

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

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

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

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

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

所以懂得測試，產品經理能更好地溝通，能更好地測試驗收產品確保符合產品需求文檔，能更好地解決和優化產品。

產品經理不應該只為一個產品設計而不為一個產品測試。

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

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

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

一些建議：

原生UI應用場景：

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

webview的HTML5頁面應用場景：

• 活動運營的頁面需求，可重復調用
• 交互簡單

3、測試的定義

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

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

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

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

4、測試何時進行

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

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

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

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

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

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

• 需求評審：定位、用戶畫像、說明規則是否明確；
• 原型：頁面是否完整，信息架構是否清晰；
• UE：業務流程是否舒適；
• UI：視覺設計是否干凈，風格是否一致；

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

5、產品經理應該懂的測試概念

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

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

所以，這里我們講講產品經理一般接觸到的測試概念。

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

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

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

V模型是按測試階段來分類測試，分為單元測試、集成測試、系統測試、驗收測試，這也是根據開發進度進行的測試分類。

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

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

集成測試：也稱聯合測試，將程序模塊采用適當的集成策略組裝起來，對系統的接口及集成后的功能進行正確性檢測的測試工作。其主要目的是檢查軟件單位之間的接口是否正確，集成測試的對象是已經經過單元測試的模塊。

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

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

系統測試主要是從業務角度驗證產品是否符合需求文檔，所以，產品經理測試產品是否符合需求文檔和設計的要求，一般都是在系統測試階段。當然，測試人員主要針對的也是系統測試階段。

驗收測試：也稱交付測試，以用戶為主的測試，由用戶參加設計測試用例，使用生產中的實際數據進行測試，確定軟件是否滿足驗收標準，是否接受系統軟件。

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

從上面的定義，我們知道產品經理測試驗收產品一般是在系統測試階段，系統測試主要包括功能測試、界面測試、可靠性測試、易用性測試、兼容性測試、性能測試。 功能測試主要針對包括功能可用性、功能實現程度（功能流程&業務流程、數據處理&業務數據處理）方面測試。其中功能測試是最主要的一種測試類型，一般說測試就是功能測試。

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

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

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

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

兼容性測試：主要測試軟件是否能在不同的操作系統平臺上兼容，是否能在不同的設備上兼容；軟件本身能否向前或向后兼容；軟件能否與其他相關的軟件兼容；數據是否兼容，主要是指數據能否共享等。

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

性能測試主要分為：

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

性能測試目的是驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最后起到優化系統的目的。

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

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

回歸測試：修改了舊代碼后，重新進行測試以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤。在整個軟件測試過程中占有很大的工作量比重，軟件開發的各個階段都會進行多次回歸測試，且盡量實現自動化，作為自動化測試的優先級。測試重心在關鍵模塊和重點功能模塊上。

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

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

補充說明：目前互聯網公司大多強調敏捷開發，所以我們講講敏捷開發及敏捷測試的知識。

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

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

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

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

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

6、產品經理如何測試驗收產品

講完測試概念，就應該到實踐了，即如何測試驗收產品。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

測試前需要準備一些測試的硬性需求，比如測試的相關數據（比如是否后臺創建測試賬號）、測試設備（比如iphone5、6、7）、測試需要的軟件（比如操作系統，瀏覽器）。

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

根據帶著問題以不同用戶的不同操作流程去使用產品達到發現bug的測試思維，編寫測試用例。

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

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

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

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

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

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

本文由 @鉛筆小葵 原創發布于人人都是產品經理。未經許可，禁止轉載。