上一篇主要講了產品實施環節的幾大元素，這期主要講下產品測試的重要性和意義所在，以及產品經理該如何與測試人員協調。提前表明一點：產品人員必須要嚴格進行測試或協調測試，才能使得產品盡可能流暢使用，因此了解測試工作是非常必要，下面進入主題：

先從測試的基礎講起，軟件測試是在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程（名詞釋義）。通俗點來說，測試更多是去發現產品相關的bug，幫助產品完善相應的漏洞。更像一個質檢員一樣，最為質量把控的重要一員，往往帶有極強的專業性和對產品效果的嚴謹，其環節關鍵性自然重要。從兩個緯度談起：測試流程和測試協調。

一、測試流程

我們先來看看測試工作做的是什么，首先根據產品需求文檔了解整體的邏輯，然后根據需求寫明詳細的測試用例，后通過各種手段（白盒、黑盒等）去檢測，基本上也是產品上線的最后幾關。在這過程中，更重要的是發現問題，提交相關實施人員。事實而言，這種流程模式只是最基本的測試工作，會是合格的標準。那么真正的測試是什么呢？分為三部分：

1. 根據文檔或用例測試軟件相關bug，提交工程師或設計師；
2. 分析問題產生的原因和趨勢，幫助開發者發現當前軟件開發中的缺陷；
3. 會從用戶體驗的角度去思考產品體現的概念，提出可行性改進意見。

第一點主要是最基礎性的工作。測試人員首先會根據prd等產品開發文檔編寫詳細的測試用例，在這期間往往會提出一些嚴謹或極端的用例，如數據崩潰現象，字符最大值等問題，這些元素有些會在需求文檔中說明，有些則沒有。雖是細節性的問題，但往往可能因為其中一點而使得軟件使用變得很差勁。如果我們從整體角度看待，產品做的會偏重于整塊的工作，測試會注重流程和細節反饋問題。因此好的測試環節必然少不了對整塊需求的理解。從整個行業來看，至少一半以上的工作量都在于發現軟件問題，提交并再次檢驗，保證軟件質量。

到了第二點，基本上是一個測試工作的提升環節。我們從一個產品的本質上去思考，為什么會測出各種各樣的問題，測試往往是對代碼結果檢驗。只是盡可能地發現錯誤與問題，畢竟不會存在百分百無漏洞的軟件。即便是最專業的測試水準，從大眾的不同角度看來，也存在不同的問題。因此從測試中找出問題的成因會更加重要。因為這往往會帶動一些開發過程中的效率和質量保證。舉個例子，程序開發往往會注重實施的結果，通過不同的方法編寫代碼，達到產品需求的實現。但從個人意識去判斷，很難發現代碼自身的問題，很多時候也是因為時間的緊張。因此測試若能分析一些漏洞產生的原因，自然會對整個流程體系把握更加到位，甚至在很大程度上告訴開發者的問題，以便達到再次開發的過程優化。

第三點說的是產品結果層，程序開發實現了效果，但到了用戶層面可能是另外一種傳遞概念。除了產品人員要親臨現場外，測試往往也會從一線的角度去思考，畢竟測試從整體角度來看稱作第一用戶也沒有錯。目前來看，整個測試環境達到這一點的并不是很多，像類似于一些成熟的體系如谷歌等在這一塊做的恰到好處。在《谷歌軟件測試之道》中，測試工作從最基礎的環節到了最高層的環節基本就是用戶體驗測試層。這也很好理解，測試人員面對開發者是發現代碼結果問題，面向用戶則是使用問題的記錄。軟件最終面向的是一線用戶，用戶所提的問題需要發現對的點去加以改正。因此以用戶的角度去看待測試會使得軟件測試工作更加順暢，同時產品也會因為測試的直接進入盡快得到優化反饋。

總之，測試工作不僅僅是提出bug，同時也是對開發和產品設計改進的重要一步。

二、測試協調

測試協調主要是測試工作在產品、設計、研發等不同層面的協調和完成交付樣本。與產品工作可看作是前后互補，產品對文檔負責，協調各個資源；測試看重開發結果，指出各個環節問題。因此除了專業的規范性外，充分理解各個環節模塊也是有必要的。

現在常常有一種說法，軟件測試往往從開發中甚至是開發后才開始介入，這明顯是有問題的。從整體上來說，一個產品只要各個環節充分了解才可能到達策劃方案的效果，不僅研發、設計如此，測試人員更應該如此去實施。充分了解需求是最基本的工作。從個體角度看，如果測試人員在中期后介入，往往很難明確各個模塊的業務線，對于重點測試的模塊也較難把握。因此，測試至少在開發前就要介入進來，甚至是需求策劃或評審時。

在產品實施中，測試該怎么樣達到完美的狀態呢？首先來說，一個產品在開發后的結果拆分就三種：業務邏輯、產品數據、視覺效果，分別對應前端、后端和設計層面。對于前端而言，測試需要判斷業務邏輯和功能的準確性，如模塊劃分，反饋信息是否按照文檔中去走。如果存在不合理的地方要立即記錄下來。數據則是后臺返回的數據，如數組排序、字段是否準確，此時往往通過極限測試發現很多問題，再次進行記錄。對于視覺而言，看標注圖與布局是否與實現效果一致，是否有對需求改動的地點，有誤的地方也要記錄出來。

實際的工作也就兩條線，一是對需求充分理解后，根據用例對功能、設計、數據等層面整理出存在問題的地方，二是通過測試工具記錄相應的問題并進行問題解決后的再次記錄。

把握先記錄，再與產品需求對比，而后統一提交各個人員。這樣也不會耽誤別人的思路，如果遇到問題就提肯定是影響效率的。同時在正式測試期間，不能一開始就陷入細節，如按鈕顏色、話術等問題。一定要保證邏輯和功能的完全再去記錄細節。從軟件開發而言，做業務處理、模塊邏輯關系往往是復雜的，細節問題可以隨時改動，甚至花一整天時間全部修改。

很多情況下，團隊中往往沒有測試人員，產品人員會兼任。因此產品策劃者了解測試會顯得尤為重要，在不確定資源的情況下，盡可能做到了解總不會有錯。如果沒有專業的測試人員，則需要多考慮一些產品反饋、性能體驗等問題。對于需求文檔會更加細分嚴格，實際上本該如此，畢竟口頭說的很難形成記錄和最終的結果對比。在有測試人員的情況下，產品人士要充分理解測試含義，對于其提出的問題，不能一概而否，從需求的角度看是否正確，需要進行合理對的采納，畢竟專業的人做專業的事情。

產品經理必須充分了解測試的意義所在，相互協調，最終使得產品效果達到滿意化的狀態。

#專欄作家#

Oneto，人人都是產品經理專欄作家，專注于分享優質的原創信息，關注互聯網、文化、知識等領域，只為傳遞好的見解。個人博客：www.oneto.top，一點時代。愿以大家一同發現互聯網的價值信息，共同進步！?興趣：下棋、讀書，研究好的產品。

轉載請保留上述作者信息并附帶本文鏈接