産品經理在項目開發中扮演的是一個連接者的角色，連接的前提是要熟悉連接對象即兼容對方，善于從對方的角度思考問題。本文将從測試的角度來總結分析産品設計，以此來提升産品設計全面性。

在蘇傑大神的博客文章中有這樣一個觀點：

産品新人如何快速上手的方法之一是寫測試用例。

測試用例是從測試的視角寫的産品描述。測試與産品的邏輯不同，産品抓大放小，測試就是要想清楚各種邊邊角角。

所以，如果團隊正好沒有TC，你來寫一遍，保證對産品的各種細節都很熟悉，也會知道背後用的技術，因為各種限制而造成的各種坑。

一、關于軟件測試

• 從測試方法來分：軟件測試分為黑盒測試、白盒測試、灰盒測試、靜态測試、動态測試、手工測試、自動化測試。
• 從測試階段來分：軟件測試分為需求測試、單元測試、集成測試、系統測試、驗收測試。

黑盒測試也叫功能性測試，在軟件測試過程中大多采用此方式。我所說的産品經理懂測試，針對的即是功能性測試，從功能性的角度做産品的需求文檔，遍曆盡可能多的功能場景。一定不能讓開發和測試找到你的漏洞，那将是産品經理最尴尬的時刻。

有數據表示：

在許多失敗的項目中，70%~85%的返工是由于需求方面的錯誤導緻的。

二、限制邊界值

如果沒有限制輸入框的長度，專業的測試分分鐘可以把開發認為沒問題的程序搞挂。

因此對輸入框的長度限制，是一個産品最底層的功能，我想這也是産品經理的基本素養。進一步的要求是對可輸入字符類型的限制，此項不至于影響到功能，但屬于産品最基本的友好性需求。

下圖是作者好不容易找的一個反面例子：

數值「0」是開發容易忽視的邊界值，在很多場景中0值其實是沒有意義的，比如金額為0元、數量為0等。自己的親身經曆：之前做過一個資金分配的功能，由于PRD沒有說明字段的規則（以為開發小哥哥用腳想想都會明白），然而在做功能驗收的時候，我成功給好友分配了0元。。。

對于這些字段的規則，其實沒有必要在文檔上一一标注，因為很多頁面的字段其實是重複的，這個方法也很容易漏掉一部分字段。一個很好的工作方法是：在全局規範中建立字段規則表。這個方法讓我想起了：大學編程的時候，會統一将全局變量的定義集中放置。

作者抛出一個輸入框對空格的處理的測試用例供大家思考：

1. 前面存在空格
2. 後面存在空格
3. 前後都存在空格
4. 中間存在空格

二、遍曆異常邏輯

正常流程隻有一個，異常流程卻異常的多。在很多PM的PRD中，僅僅陳列了正常的業務流程。

很少有開發是會替産品考慮異常邏輯的，所以為了不給自己挖坑，在寫PRD的時候，就要将所有的異常流程都描述清楚，我想在需求評審的時候會更容易通過，也會在開發的眼裡樹立權威。

有人說，無反饋是産品大忌。我想說，反饋不完全也是産品不專業的體現。對于特定事件的反饋，既然有成功的結果，必然會存在對立面——失敗。對于這些事件的總結其實很容易找到規律，很多優秀的PM都會整理一份交互設計自查表，然後會不斷的更新叠代。

善于總結是一個優秀學習者的必要品質，在項目經曆中總結積累遇到的異常情況。有句話這樣說：

“你現在經曆的每一件事，都會在未來某一時刻用上”。

登錄注冊可能是大多數PM童鞋的處女級産品功能，根據我個人的經驗：如果沒有從零到一将這個需求落地，一定是存在認知漏洞的。

我說一個場景，看大家有沒有考慮到：手機号驗證碼輸入框在同一個頁面，在手機号無誤、驗證碼輸入正确的情況下，然後更改手機号（手機号格式合法），提交之後應該如何反饋？

三、關聯性的問題

在項目中，大多數功能模塊往往不是獨立的，一般存在交集或者需要進行模塊間的數據交互。因此一個模塊如果發生了需求變更或者數據丢失，就會影響到相關聯的功能模塊。

曾經做過一個項目，由于平台新增了直營店功能，之前設計的訂單詳情就不适用了，需要融合新需求，财務管理模塊也要做字段的擴展。

關聯信息不允許删除，比如商品類别，假如商品類别是商品的必要屬性，此時就應該禁止正使用的類别被删除。還有一個很重要的關聯性問題是，正在生效的規則是不能被删除。

四 、性能的問題

性能無止境，性能的優化伴随着産品的整個生命周期。測試過程，性能測試處于功能測試之後，也就是說功能大于性能。翻越異常邏輯的大山，從性能角度設計産品，是産品經理進階的又一指标。

作者分别從數據加載、信息的篩選跨度、圖片處理三個方面總結，希望可以抛磚引玉。

關于數據加載其實是一個很大的話題，不僅涉及産品的性能，還影響用戶的使用體驗。我在這裡隻是蜻蜓點水，想要突出對産品性能的重視。

這個問題主要在數據列表等相關的信息流模塊，如果沒有做數據加載條數的限制，一個經驗不足的開發童鞋很可能一下子請求所有的曆史數據，結果可以預見：輕則加載緩慢，嚴重的話直接導緻應用崩潰。

對于信息流頁面的數據加載，一般都會限制單次加載10-20條。

與此相關的另一個問題就是：數據篩選的請求限制。像支付寶這樣大體量的産品，在篩選賬單的時候，也僅僅支持查找6個月跨度的賬單。

圖片是影響産品性能的又一大因素，在前端上傳圖片注意做圖片大小的限制，即使上傳之後技術也要做壓縮處理。圖片的壓縮分為分辨率的壓縮和大小的壓縮，根據業務需求，如果需要展示縮略圖，要在服務端自主生成。

五、寫在最後

說了這麼多，作者并沒有誤導大家把産品重心向測試的角度偏移，畢竟産品還有很多重要的事要做。

一個好的産品經理既不能技術化，也不能業務化，掌握好工作中的「度」，做好「中庸的」連接者。

當然，懂測試，能從測試的角度設計産品隻是優秀産品的一個方面。産品經理這個崗位之所以吸引人正是因為它的定位不明确，它的「難」與「坑」我想也是這個原因。

持續不斷的學習，時刻都在拓寬自己的邊界。懂技術、懂心理、懂設計、懂運營才能更好的連接。

本文由 @ 産品範 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部