產(chǎn)品經(jīng)理干貨：基于用戶使用場景的產(chǎn)品測試

0 評論 9635 瀏覽 10 收藏 10 分鐘

　　產(chǎn)品測試一般都是圍繞需求為主的產(chǎn)品需求設(shè)計說明書PRD文檔來展開測試的，針對每個功能點編寫測試用例，去驗證功能的正確性和完整性。這種方式在正常的開發(fā)上線進度下都不會有問題，相反是一種很好的驗證功能需求實現(xiàn)的方式。但在敏捷開發(fā)模式或者因為趕進度的原因，造成產(chǎn)品測試時間非常緊的情況下，用這種方式就會有點捉襟見肘。
　　以用戶為中心的產(chǎn)品設(shè)計已經(jīng)逐漸的深入人心，產(chǎn)品主題功能要能滿足用戶的某種訴求或者解決用戶的某個痛點，也有說成是以用戶痛點為中心的產(chǎn)品設(shè)計。在這種大背景下，產(chǎn)品開發(fā)完成后，如果測試時間非常緊，在不能保證產(chǎn)品沒有問題但卻必須要按時上線的時候，就必須保證產(chǎn)品在用戶使用的場景下沒有問題，也就是說優(yōu)先保證用戶使用產(chǎn)品的整個流程當(dāng)中不會出現(xiàn)問題，這就是基于用戶使用場景的產(chǎn)品測試法。
　　在實際的測試過程當(dāng)中，最常見的還是基于產(chǎn)品功能的測試，那基于用戶使用場景的產(chǎn)品測試兩者之間有什么區(qū)別呢？區(qū)別一是后者的測試范圍更小，忽略了一部分產(chǎn)品后臺功能的測試或隱性的功能測試，即只是測試了表面操作性的過程，沒有測試底層的功能；區(qū)別二是后者的測試是把產(chǎn)品功能轉(zhuǎn)化成實際用戶使用場景下來測試，這就要求測試人員要從普通用戶的操作角度出發(fā)，而不能受開發(fā)人員的影響，以一個初次使用產(chǎn)品的用戶角度，來驗證產(chǎn)品的功能是否可以在使用過程中提供正常的服務(wù)。

　　這里需要注意的一點是，在時間進度允許的情況下，還是要基于產(chǎn)品功能的測試，以求測試可以覆蓋到產(chǎn)品的方方面面，確保產(chǎn)品可以提供完善的服務(wù)。本文所闡述的基于用戶使用場景的產(chǎn)品測試都是建立在測試時間非常緊的前提下的，因為本身這種測試方法因為測試的不夠全面，有一定的風(fēng)險性在里面，對產(chǎn)品而言不一定是好的，只是為了保證產(chǎn)品的發(fā)布時間，而采取的一種較為折中的測試方法。這種測試方法的使用需要有以下兩個要素，否則最好還是做全面的產(chǎn)品功能測試。

　　測試時間非常緊

　　其實這種場景非常的常見，項目進度安排了之后，往往因為需求分析的時間超長了，或者開發(fā)的時間延誤了，導(dǎo)致最后留給測試人員的時間非常少，這時如果必須保證項目上線進度的話，就無法完成全面的產(chǎn)品功能測試，只能優(yōu)先測試用戶操作流程當(dāng)中所需使用的各個產(chǎn)品的功能模塊的流程。有的時候也是因為測試資源的不足所導(dǎo)致的測試時間緊迫，測試人員在這些情況下可以考慮基于用戶使用場景的測試，但必須與項目經(jīng)理或者主管領(lǐng)導(dǎo)說明清楚，是為了確保項目進度而采取的優(yōu)先測試用戶使用產(chǎn)品流程的功能。

　　從傻瓜用戶的角度測試

　　基于這種方式的測試，測試人員就必須從用戶的角度出發(fā)，而不是從開發(fā)人員或者產(chǎn)品經(jīng)理的角度。也即測試人員必須保持相對的純粹性，可以參加產(chǎn)品功能需求的review，但就不應(yīng)該參加開發(fā)人員的系統(tǒng)設(shè)計review了，否則會受到開發(fā)人員實現(xiàn)方式的影響，而導(dǎo)致后續(xù)的測試不準確。應(yīng)該是在保證理解產(chǎn)品功能需求的基礎(chǔ)上，盡量從普通用戶的使用場景出發(fā)，找出使用過程的問題，以便開發(fā)人員優(yōu)先解決，這時候測試人員也不需要和開發(fā)人員去討論問題，只需告訴問題發(fā)生的場景即可，以便盡可能的不受外界信息的影響。
　　在上述兩個要素滿足的條件下，測試人員還要拋開自己的計算機專業(yè)素養(yǎng)，把自己當(dāng)成一個大眾化的用戶，以使測試的結(jié)果更接近真實的使用場景。由于該種測試方法并未覆蓋產(chǎn)品的全部功能，會造成產(chǎn)品發(fā)布后有一定的風(fēng)險性，既然知道有這樣的風(fēng)險，就需要去盡量的避免或者降低相應(yīng)的風(fēng)險，這就需要整個產(chǎn)品團隊的配合，也需要測試人員自身有一套完整的測試體系。
　　開發(fā)人員的自測和Code Review
　　開發(fā)人員在開發(fā)完成之后，需要有一輪自測，以降低代碼風(fēng)險和功能缺陷，減少后續(xù)測試驗證和改BUG的時間。自測的過程當(dāng)中，需要與產(chǎn)品經(jīng)理的需求相結(jié)合，以實現(xiàn)第一輪的功能驗證，一旦出現(xiàn)問題及時解決。開發(fā)人員也是最熟悉底層結(jié)構(gòu)的人員，一些底層的功能問題可以在自測過程當(dāng)中去發(fā)現(xiàn)解決，盡可能保證沒有大的問題遺留到測試階段。自測也是開發(fā)人員自身能力水平提升的一個很好的機會，提升代碼質(zhì)量的同時，也是提高對自身編寫代碼責(zé)任度的一種方式。自測是需要基于開發(fā)人員自身的能力水平的，此外還可以借助團隊的配合，如敏捷開發(fā)模式當(dāng)中就很強調(diào)開發(fā)團隊內(nèi)部的Code Review，一個開發(fā)人員編寫的代碼，由另外兩個經(jīng)驗較深的開發(fā)人員來共同把關(guān)，這樣也可以在很大程度上減少代碼缺陷，盡早的發(fā)現(xiàn)問題。

　　從用戶使用的角度去測試

　　基于用戶使用場景的測試不能保證產(chǎn)品沒有問題，但必須保證產(chǎn)品在用戶使用過程當(dāng)中沒有問題，這就要求測試人員必須從用戶的角度出發(fā)，真正按用戶的操作流程去操作測試產(chǎn)品的功能。再就是把編寫測試用例的時間，留出來用于理解產(chǎn)品的功能需求，以便在測試的過程當(dāng)中及時發(fā)現(xiàn)不滿足需求的功能點，因為這類功能點在測試的時候并不會出錯，但卻不是需求說明書中所設(shè)計的那樣，這就需要測試人員充分的理解需求。也不是說測試用例就不需要編寫了，而是在測試的過程當(dāng)中，依賴測試工具去記錄測試的過程，后期再來整理這部分用例。因為這個測試階段結(jié)束了之后，后續(xù)還是要繼續(xù)驗證產(chǎn)品的整體功能的，包括底層的功能，這時可以一起編寫測試用例文檔。
　　從用戶的使用場景出發(fā)去測試需要測試人員對用戶使用產(chǎn)品的方式有一定的了解，比如說財務(wù)系統(tǒng)和普通的業(yè)務(wù)系統(tǒng)在操作的時候差異就比較大，原因是財務(wù)系統(tǒng)受國外成熟財務(wù)系統(tǒng)產(chǎn)品的影響比較大。這需要測試人員去更多的了解用戶的使用，當(dāng)然這個過程也還是要基于產(chǎn)品自身的功能結(jié)構(gòu)設(shè)計，不排除有一些需要培養(yǎng)用戶使用習(xí)慣的功能，這種功能就需要產(chǎn)品經(jīng)理做一些特別的說明，以使測試人員理解產(chǎn)品設(shè)計的意圖，最好可以提供一份產(chǎn)品操作使用手冊。
　　前面也都提到了這種測試方式是存在風(fēng)險的，這就要求在發(fā)布上線之后要繼續(xù)進行剩余功能的測試，而不是測試過程就終止了。在后續(xù)的測試過程當(dāng)中，可以一并驗證之前遺留的問題，并在接下來的一個快速迭代中上線解決掉，這樣就可以將產(chǎn)品的功能風(fēng)險降到最低，使產(chǎn)品提供穩(wěn)定的服務(wù)。
　　基于用戶使用場景的測試目前應(yīng)用的還不是很多，在創(chuàng)業(yè)型產(chǎn)品的快速迭代中，或者敏捷開發(fā)模式下的敏捷測試當(dāng)中，會有一些應(yīng)用。這種方式雖然有一定的缺陷，但卻是一種非常好的備選方案，可以在保證項目進度的情況下，也能保證用戶在使用產(chǎn)品的時候不出問題，使產(chǎn)品在用戶手上沒有問題，這也是發(fā)布產(chǎn)品的一個目的，符合產(chǎn)品發(fā)布的要求。

文章來源：IT民工

更多精彩內(nèi)容，請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
人人都是產(chǎn)品經(jīng)理
產(chǎn)品經(jīng)理和運營的成長社區(qū)
1381篇作品 28344997總閱讀量
03-243190 瀏覽
QQ音樂和網(wǎng)易云音樂其實都一樣，對著用戶猛薅羊毛
09-191030 瀏覽
三個市場端都做的產(chǎn)品經(jīng)理，該怎么并行工作（一）
07-133380 瀏覽
Keep是一家“互聯(lián)網(wǎng)平臺公司”嗎？我不這么認為
11-234142 瀏覽
今天把肯德基Crazy Thursday App設(shè)計爆改一通
11-061734 瀏覽
字節(jié)跳入混戰(zhàn)
評論
評論請登錄
  1. 目前還沒評論，等你發(fā)揮！