本文筆者將帶領大家一同了解單項產(chǎn)品的測試結構，再用一個框架來介紹一下：如何生成多項產(chǎn)品測試？最后，再通過一個示例進一步學習。

作為產(chǎn)品經(jīng)理，我們不僅負責開展客戶研究和記錄用戶體驗，還負責產(chǎn)品的性能和表現(xiàn)，確保產(chǎn)品正常運行雖然變得日益困難但越來越重要。

因此，有關產(chǎn)品新設計功能表現(xiàn)情況的信息已經(jīng)成為了產(chǎn)品規(guī)范記錄中不可或缺的一部分。

進行案例測試是確保你了解產(chǎn)品預期表現(xiàn)的最佳方法之一。畢竟如果你了解一種產(chǎn)品在多種條件下的表現(xiàn)狀況的話，你的產(chǎn)品將會更加穩(wěn)健。所以，在我們制定產(chǎn)品規(guī)范的時候應該如何考慮案例測試呢？

首先，我們應該了解單項產(chǎn)品的測試結構。然后，我將用一個框架來介紹一下：如何生成多項產(chǎn)品測試？之后，我們會一起通過示例進行學習。

那么就讓我們開始吧！

案例測試結構

案例測試究竟是什么樣的呢？為什么說它很重要？

案例測試可以模擬用戶和產(chǎn)品之間所有的交互方式。它應該包括這一流程的開端，到達終端所走的路徑，以及在這一流程中可能出現(xiàn)的預期結果。

這樣的話，一種在線購物產(chǎn)品的案例測試結構看起來也許會是這樣的：

這樣很容易就可以看出：在購物車添加商品時是存在問題的，而在購物車檢查用戶登錄情況上是沒有問題的。

記錄清晰的案例測試，可以確保你的開發(fā)團隊知道自己在向成功的方向邁進。

既然我們已經(jīng)知道了單項案例測試是什么樣的，那么，接下來就讓我們思考一下：一種產(chǎn)品新的設計功能都需要哪些相關測試呢？

案例測試的框架

單項的案例測試是遠遠不夠的，我們需要考慮用戶在使用產(chǎn)品時可能遇到的所有情況并對其進行測試。

如果我們只有少量的案例測試，我們也許無法預料到極端案例中可能出現(xiàn)的結果。但如果我們進行太多的案例測試，我們可能在將大量的時間用來研究一些永遠不可能出現(xiàn)的情況，這便是對稀缺資源的一種低效使用。?

那么，我們怎么才能知道哪些案例測試是我們真正需要的呢？

我們可以從考慮現(xiàn)有的產(chǎn)品表現(xiàn)開始，考慮一下：我們的產(chǎn)品目前可以做什么？

我們應該先查詢一下產(chǎn)品有沒有任何案例測試記錄在案，如果沒有的話，現(xiàn)在便是構建記錄和進行案例測試的最佳時機。

之后，我們應該考慮將來引入新功能后產(chǎn)品的表現(xiàn)；考慮一下你吸引了哪些新的客戶流，哪些已有的客戶流是經(jīng)過調整的并且它們是如何相互影響的；還要考慮一下哪些現(xiàn)有的客戶流會因為產(chǎn)品的改變而流失。

還是像之前說過的那樣，案例測試都應該代表用戶和產(chǎn)品之間所有的交互方式。換句話說就是你不應該只進行單向測試，而是對產(chǎn)品和客戶之間端到端的流程進行測試。

每當我們構建產(chǎn)品設計功能時，我們需要考慮其依賴性，并且測試已有功能與新功能之間的依賴性關系。

當新建的設計功能獨立于其他功能時，我們只需要進行單項測試即可，也就是說不需要將二者共同進行測試。

例如：當你構建新的反饋流程時，你可能并不需要測試付款功能，因為二者是相互獨立的。

但是，如果你的反饋選項只有在完成付款之后才會出現(xiàn)的話，你就需要將二者組合共同進行測試了。

示例

我已經(jīng)模擬創(chuàng)建了一些示例，希望這樣可以幫助我們更好地理解案例測試。

我將會過一遍這種假設產(chǎn)品現(xiàn)有設計的表現(xiàn)，并且假設出該產(chǎn)品新的設計功能，之后再細致詳盡地一一進行解釋。

現(xiàn)有功能的表現(xiàn)

假設我正在研究現(xiàn)有的反饋功能。

目前，這一設計只有兩種界面，第一個如下圖所示：

用戶可以選擇“是”和“否”兩個選項，當然他們也可以選擇跳過這一問題然后回到產(chǎn)品之前的界面上。

如果用戶選擇“否”，那么他們會被轉到產(chǎn)品界面。

但是，如果用戶選擇“是”，就會跳出來接下來這個界面：

就是這樣，一種非常簡單的設計。

新設計功能的提議

假設根據(jù)客戶研究，我們得到了如下的反饋。

當客戶想向朋友推薦這款產(chǎn)品時，他們會因為沒有辦法迅速分享鏈接而感到沮喪。

當客戶表示并不喜歡這一款產(chǎn)品，或者表示并不會向朋友推薦這款產(chǎn)品時，他們會因為沒有辦法提供直接的產(chǎn)品反饋而感到無奈。

根據(jù)這樣一種需求，我的團隊就構建出了這樣一種新的設計功能。

如果用戶表示他們愿意向朋友們推薦這款產(chǎn)品，我們就會彈出如下所示的第三種界面：

如果用戶表示不喜歡該產(chǎn)品，或者表示他們不會向其他人推薦產(chǎn)品的話，我們則會提供第四種界面，如下所示：

要測試這項新的設計功能有多困難呢？

你一定會對答案特別驚訝，因為我們剛才并沒有暴露問題的復雜性。

接下來，我們就逐個進行分析。

案例測試

讓我們回過頭來考慮最初的設計功能。首先，我需要測試以下這些流程：

當我加入了“分享到社交網(wǎng)站”這項功能之后，我的案例測試可能看起來就成了如下的樣子：

這么一來不僅生成了兩條新路徑，還修改了一條已有的路徑。

當我再加入“反饋”功能的時候，我的案例測試就成了如下的樣子：

這么一來我又引入了兩條新的路徑，并且修改了兩條已有的路徑。

但到目前為止，我們都還沒有提到過對“反饋功能”本身進行測試。

例如：如果有人在反饋框中輸入了非英文字符該怎么辦？如果有人試圖提交空白的反饋該怎么辦？甚至說如果有人試圖在反饋框中輸入惡意代碼怎么辦？

此外，當我們進行測試時，我們不僅要測試設計功能，還要考慮接收到的數(shù)據(jù)是否儲存得當。

我們是否正確接收了用戶的反饋？我們是否正確地跟進了用戶分享的內容，又是通過哪些渠道呢？如果用戶跳過了當前界面，我們是否要深入了解他們究竟跳過的是哪一界面呢？

在此，我還有最后一個想法。每當新界面引入后，我經(jīng)?？吹饺藗儠雎詼y試“跳過”這一設計功能。雖然“跳過”功能并不是必須的，但是新流程可能會影響“跳過”這一設計功能的實際作用。

總結

優(yōu)秀的產(chǎn)品經(jīng)理不僅要了解用戶使用產(chǎn)品時遇到的問題，還要了解因設計功能更改而日益增加的產(chǎn)品系統(tǒng)的復雜性。優(yōu)秀的產(chǎn)品經(jīng)理可以從了解產(chǎn)品影響中不斷優(yōu)化產(chǎn)品。

當構建新的產(chǎn)品設計功能時，團隊需要將因其而產(chǎn)生的新路徑記錄和儲存下來。然后，確保每條路徑都是經(jīng)過測試的，手動測試還是自動化檢測均可。此外，切記要測試之前的設計路徑，因為我們經(jīng)?？吹叫碌脑O計功能無法返回上一步。

時刻注意設計功能的復雜性，并且編寫和記錄案例測試可以保證用戶對我們的產(chǎn)品有很好的體驗！

原作者：Clement Kao

原文鏈接：https://www.productmanagerhq.com/2019/04/test-cases/

翻譯：「即能」小程序，公眾號：「即能Upskill」

本文由 @即能 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議