起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何對產品功能進行案例測試，確保產品功能穩健運作？
本文筆者將帶領大家一同了解單項產品的測試結構，再用一個框架來介紹一下：如何生成多項產品測試？最后，再通過一個示例進一步學習。
作為產品經理，我們不僅負責開展客戶研究和記錄用戶體驗，還負責產品的性能和表現，確保產品正常運行雖然變得日益困難但越來越重要。
因此，有關產品新設計功能表現情況的信息已經成為了產品規范記錄中不可或缺的一部分。
進行案例測試是確保你了解產品預期表現的最佳方法之一。畢竟如果你了解一種產品在多種條件下的表現狀況的話，你的產品將會更加穩健。所以，在我們制定產品規范的時候應該如何考慮案例測試呢？
首先，我們應該了解單項產品的測試結構。然后，我將用一個框架來介紹一下：如何生成多項產品測試？之后，我們會一起通過示例進行學習。
那么就讓我們開始吧！
案例測試結構
案例測試究竟是什么樣的呢？為什么說它很重要？
案例測試可以模擬用戶和產品之間所有的交互方式。它應該包括這一流程的開端，到達終端所走的路徑，以及在這一流程中可能出現的預期結果。
這樣的話，一種在線購物產品的案例測試結構看起來也許會是這樣的：
這樣很容易就可以看出：在購物車添加商品時是存在問題的，而在購物車檢查用戶登錄情況上是沒有問題的。
記錄清晰的案例測試，可以確保你的開發團隊知道自己在向成功的方向邁進。
既然我們已經知道了單項案例測試是什么樣的，那么，接下來就讓我們思考一下：一種產品新的設計功能都需要哪些相關測試呢？
案例測試的框架
單項的案例測試是遠遠不夠的，我們需要考慮用戶在使用產品時可能遇到的所有情況并對其進行測試。
如果我們只有少量的案例測試，我們也許無法預料到極端案例中可能出現的結果。但如果我們進行太多的案例測試，我們可能在將大量的時間用來研究一些永遠不可能出現的情況，這便是對稀缺資源的一種低效使用。?
那么，我們怎么才能知道哪些案例測試是我們真正需要的呢？
我們可以從考慮現有的產品表現開始，考慮一下：我們的產品目前可以做什么？
我們應該先查詢一下產品有沒有任何案例測試記錄在案，如果沒有的話，現在便是構建記錄和進行案例測試的最佳時機。
之后，我們應該考慮將來引入新功能后產品的表現；考慮一下你吸引了哪些新的客戶流，哪些已有的客戶流是經過調整的并且它們是如何相互影響的；還要考慮一下哪些現有的客戶流會因為產品的改變而流失。
還是像之前說過的那樣，案例測試都應該代表用戶和產品之間所有的交互方式。換句話說就是你不應該只進行單向測試，而是對產品和客戶之間端到端的流程進行測試。
每當我們構建產品設計功能時，我們需要考慮其依賴性，并且測試已有功能與新功能之間的依賴性關系。
當新建的設計功能獨立于其他功能時，我們只需要進行單項測試即可，也就是說不需要將二者共同進行測試。
例如：當你構建新的反饋流程時，你可能并不需要測試付款功能，因為二者是相互獨立的。
但是，如果你的反饋選項只有在完成付款之后才會出現的話，你就需要將二者組合共同進行測試了。
示例
我已經模擬創建了一些示例，希望這樣可以幫助我們更好地理解案例測試。
我將會過一遍這種假設產品現有設計的表現，并且假設出該產品新的設計功能，之后再細致詳盡地一一進行解釋。
現有功能的表現
假設我正在研究現有的反饋功能。
目前，這一設計只有兩種界面，第一個如下圖所示：
用戶可以選擇“是”和“否”兩個選項，當然他們也可以選擇跳過這一問題然后回到產品之前的界面上。
如果用戶選擇“否”，那么他們會被轉到產品界面。
但是，如果用戶選擇“是”，就會跳出來接下來這個界面：
就是這樣，一種非常簡單的設計。
新設計功能的提議
假設根據客戶研究，我們得到了如下的反饋。
當客戶想向朋友推薦這款產品時，他們會因為沒有辦法迅速分享鏈接而感到沮喪。
當客戶表示并不喜歡這一款產品，或者表示并不會向朋友推薦這款產品時，他們會因為沒有辦法提供直接的產品反饋而感到無奈。
根據這樣一種需求，我的團隊就構建出了這樣一種新的設計功能。
如果用戶表示他們愿意向朋友們推薦這款產品，我們就會彈出如下所示的第三種界面：
如果用戶表示不喜歡該產品，或者表示他們不會向其他人推薦產品的話，我們則會提供第四種界面，如下所示：
要測試這項新的設計功能有多困難呢？
你一定會對答案特別驚訝，因為我們剛才并沒有暴露問題的復雜性。
接下來，我們就逐個進行分析。
案例測試
讓我們回過頭來考慮最初的設計功能。首先，我需要測試以下這些流程：
當我加入了“分享到社交網站”這項功能之后，我的案例測試可能看起來就成了如下的樣子：
這么一來不僅生成了兩條新路徑，還修改了一條已有的路徑。
當我再加入“反饋”功能的時候，我的案例測試就成了如下的樣子：
這么一來我又引入了兩條新的路徑，并且修改了兩條已有的路徑。
但到目前為止，我們都還沒有提到過對“反饋功能”本身進行測試。
例如：如果有人在反饋框中輸入了非英文字符該怎么辦？如果有人試圖提交空白的反饋該怎么辦？甚至說如果有人試圖在反饋框中輸入惡意代碼怎么辦？
此外，當我們進行測試時，我們不僅要測試設計功能，還要考慮接收到的數據是否儲存得當。
我們是否正確接收了用戶的反饋？我們是否正確地跟進了用戶分享的內容，又是通過哪些渠道呢？如果用戶跳過了當前界面，我們是否要深入了解他們究竟跳過的是哪一界面呢？
在此，我還有最后一個想法。每當新界面引入后，我經?？吹饺藗儠雎詼y試“跳過”這一設計功能。雖然“跳過”功能并不是必須的，但是新流程可能會影響“跳過”這一設計功能的實際作用。
總結
優秀的產品經理不僅要了解用戶使用產品時遇到的問題，還要了解因設計功能更改而日益增加的產品系統的復雜性。優秀的產品經理可以從了解產品影響中不斷優化產品。
當構建新的產品設計功能時，團隊需要將因其而產生的新路徑記錄和儲存下來。然后，確保每條路徑都是經過測試的，手動測試還是自動化檢測均可。此外，切記要測試之前的設計路徑，因為我們經?？吹叫碌脑O計功能無法返回上一步。
時刻注意設計功能的復雜性，并且編寫和記錄案例測試可以保證用戶對我們的產品有很好的體驗！
原作者：Clement Kao
原文鏈接：https://www.productmanagerhq.com/2019/04/test-cases/
翻譯：「即能」小程序，公眾號：「即能Upskill」
本文由 @即能 翻譯發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
感謝分享